Bug#910488: lists.debian.org: web archive for debian-efi@ not updated

[Ansgar Burchardt]

Package: lists.debian.org
X-Debbugs-Cc: debian-...@lists.debian.org

The web archive for debian-efi@ at https://lists.debian.org/debian-ci/
do not seem to get updated since this month.  There have been at least two 
messages that went over the list this month, but they aren't shown in the 
archive.

Ansgar

Bug#910489: glibc: fakechroot needs glibc 2.28 for renameat2 usage by mv in coreutils

[Johannes 'josch' Schauer]

Source: glibc
Severity: normal
Control: block #909612 by -1

Hi,

currently, it is not possible to use fakechroot with mv from coreutils
in a Debian unstable chroot. Solving this issue requires an update of
glibc in Debian to at least 2.28.

Details:

If the system has the renameat2 syscall (since Linux 3.15), then 'mv'
from coreutils (since 8.30) will directly use syscall(SYS_renameat2,
...) to make use of that system call. This is bad news for fakechroot
because fakechroot cannot intercept directly made syscalls but relies on
glibc wrappers. Since glibc 2.28 such a wrapper was added and there is a
patch against coreutils [1] that makes use of the glibc function instead
of the direct syscall, if available. For this to work, we need glibc
2.28 or otherwise, that change in coreutils will have no effect in
Debian.

Thus, I'm filing this bug to track the situation, blocking the according
bug in fakechroot.

Thanks!

cheers, josch

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32796

Bug#842828: RFP: bootstrap4 -- HTML, CSS, and JS framework

[Joseph Nuthalapati]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bootstrap 4 is out of alpha and is making stable releases, the
latest one being 4.1.3. It is a good time to package this.

https://github.com/twbs/bootstrap/releases

- -- 
Regards,
Joseph Nuthalapati

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE4rQIdbX3Xc6j+BCYU5jwCi+kPDUFAlu5tbkACgkQU5jwCi+k
PDWlLA//dEUqxQ9pTSNV60Fo4KPuUMlSD83UPQC5/POvKDqzGejrOoFCjYMrUkLk
Ty8DKK1w17jwtVbQ/Hvl3DbbFzxjSMHZOeOnCKGBpB22CzWboBDQ/dPhjr88rnpd
K1j4UC9iEZoDPbJNMM6uNJ4VUHntN3kNCbkbD8X7Mb9hewY/STRauUd2FVQUCw1J
akL+RbCJy3XDCjPlzPvTy/qwgxX1a2A5S7T82v5d7hoHuV8hPN59Dlh/HAQaczOx
WeyhhEC01B3JVEiLrdFhNFcqJZ/IYJWWiYL96RMpxet6pVSEtZp++TW6zIxN23zy
4UfxBEm4jRkuK48hUr0MfDbWf2CbP7HUgZ6du8L0R8NErwEXA3gHgCbEbaP51g8+
i5v+qgdGyz2OCvWuBKGQxoaLCMDVRKeH9TDWBz3f3douNLB22pwJzHR10iAdKhxk
DHaBNgYjH8vOKdUWSDC2jkze3ms6BR1PxxVRkMzmnyp45rX2wgFitOST24O6vfOI
CWMbAvZEw0DQCR+3hwwsRrQQbQXXRrRYQwTbkRjHjRWQWyuQLmDrGS04kZEO88DU
6qbPiEUSZTCCmMUcuvm+aUU8uT8cNDXQdgUWi8tlmwPgkurtg+B8anXxnpMs6/O0
a7PdXriPNabMYNToxZ407ILSf0kzHPj8B7QND5isdzP+E7xUsxM=
=tOqk
-END PGP SIGNATURE-

Bug#910226: closed by Georges Khaznadar (Bug#910226: fixed in expeyes 4.4.4+dfsg-2)

[Georges Khaznadar]

Hello Andreas,

I shall have a look at the maintainer script, indeed.

However, have you checked whether the upgrade does work? I did it.

The version << 4.3 relied on the bad trick (declaring explicitely the
Python3 compilation), because there was no real python3-, this
package was only Provide(d), which was probably a bad practice, but
worked, since the code was compatible with both Python2 and Python3.

Since version 4.4, as quite all the computers of end-users have
distributions with Python3, we (upstream developers and I) decided to
switch definitely to Python3, so python-expeyes is no longer provided,
and replaced by pyhon3-expeyes, which becomes a plain package. When a
Conflict is declared against the version << 4.4, the old postrm script
is run and there is no interaction between the package from Stretch and
the new package from Buster.

Best regards,   Georges.

Andreas Beckmann a écrit :
> Control: found -1 4.4.4+dfsg-2
> 
> On 2018-10-05 17:54, Debian Bug Tracking System wrote:
> >* added confilcts/replaces for python3-expeyes << 4.3. Closes: #910226
> 
> I don't see how this was supposed to fix the buggy maintainer script in
> this package ...
> 
> Andreas

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#910486: ffmpeg: vaapi encoding does not work

[Sebastian Ramacher]

Control: reassign -1 i965-va-drivers 2.2.0+dfsg1-2
Control: tags -1 + moreinfo

Hi

On 2018-10-07 04:47:06, ghost wrote:
> Package: ffmpeg
> Version: 7:4.0.2-2+b1
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
>I am just following the FFmpeg wiki 
> https://trac.ffmpeg.org/wiki/Hardware/VAAPI, and things are not working as 
> documented.
> 
>* What exactly did you do
>I first tried the simplest one which should "allows the decoder to work 
> standlone to make decoding faster without any additional options", then I 
> tried to feed the vaapi pixfmt to a vaapi encoder, but both are not working 
> (see below)
> 
>* What was the outcome of this action?
>For the first one:
> $ ffmpeg -hwaccel vaapi -i cut.mp4 -c:v libx264 output.mp4 -y
> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cut.mp4':
> Metadata:
> major_brand : isom
> minor_version   : 512
> compatible_brands: isomiso2avc1mp41
> encoder : Lavf57.56.101
> Duration: 00:00:19.99, start: 0.008005, bitrate: 451 kb/s
> Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, 
> bt470bg/unknown/unknown), 640x480 [SAR 1:1 DAR 4:3], 361 kb/s, 29.97 fps, 
> 29.97 tbr, 90k tbn, 2k tbc (default)
> Metadata:
> handler_name: VideoHandler
> Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, 
> stereo, fltp, 111 kb/s (default)
> Metadata:
> handler_name: SoundHandler
> Stream mapping:
> Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
> Stream #0:1 -> #0:1 (aac (native) -> aac (native))
> Press [q] to stop, [?] for help
> [AVHWFramesContext @ 0x7fc91004d2c0] Failed to read image from surface 
> 0x418: 20 (the requested function is not implemented).

This is most certainly a bug in the i965-va-driver when disabling the non-free
parts. Does evertyhing work as expected if you replace i965-va-driver with
i965-va-driver-shaders (from non-free)?

> [h264 @ 0x55b57872fd00] Failed to transfer data to output frame: -5.
> Error while processing the decoded data for stream #0:0
> [aac @ 0x55b57872e4c0] Qavg: 1227.311
> [aac @ 0x55b57872e4c0] 2 frames left in the queue on closing
> Conversion failed!
> 
>For the second one:
> $ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i cut.mp4 -c:v 
> h264_vaapi output.mp4
>...
> Stream mapping:
> Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_vaapi))
> Stream #0:1 -> #0:1 (aac (native) -> aac (native))
> Press [q] to stop, [?] for help
> ffmpeg: i965_encoder.c:1692: intel_enc_hw_context_init: Assertion 
> `encoder_context->mfc_context' failed.

As above

> 
>* What outcome did you expect instead?
>They should work...
> 
> FWIW:
> 
> The input is a short video cut in h264. Hardware decoding looks fine:
> $ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i cut.mp4 -f null - 
>  
> ...
> Stream mapping:
> Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))
> Stream #0:1 -> #0:1 (aac (native) -> pcm_s16le (native))
> Press [q] to stop, [?] for help
> Output #0, null, to 'pipe:':
> Metadata:
> major_brand : isom
> minor_version   : 512
> compatible_brands: isomiso2avc1mp41
> encoder : Lavf58.12.100
> Stream #0:0(und): Video: wrapped_avframe, vaapi_vld, 640x480 [SAR 1:1 
> DAR 4:3], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc (default)
> Metadata:
> handler_name: VideoHandler
> encoder : Lavc58.18.100 wrapped_avframe
> Stream #0:1(und): Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s 
> (default)
> Metadata:
> handler_name: SoundHandler
> encoder : Lavc58.18.100 pcm_s16le
> frame=  542 fps=0.0 q=-0.0 Lsize=N/A time=00:00:20.08 bitrate=N/A speed= 
> 194x
> video:284kB audio:3444kB subtitle:0kB other streams:0kB global 
> headers:0kB muxing overhead: unknown
> 
> $ lspci | grep Graphic
> 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)
> 
> $ vainfo
> libva info: VA-API version 1.2.0
> libva info: va_getDriverName() returns 0
> libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
> libva info: Found init function __vaDriverInit_1_2
> libva info: va_openDriver() returns 0
> vainfo: VA-API version: 1.2 (libva 2.2.0)
> vainfo: Driver version: Intel i965 driver for Intel(R) Broadwell - 2.2.0
> vainfo: Supported profile and entrypoints
>   VAProfileMPEG2Simple: VAEntrypointVLD
>   VAProfileMPEG2Simple: VAEntrypointEncSlice
>   VAProfileMPEG2Main  : VAEntrypointVLD
>   VAProfileMPEG2Main  : VAEntrypointEncSlice
>   VAProfileH264ConstrainedBaseline: VAEntrypointVLD
>   VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
>   VAProfileH264Main

Bug#910490: libhandy: please make the build reproducible

[Chris Lamb]

Source: libhandy
Version: 0.0.3-1
Severity: wishlist
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
libhandy could not be built reproducibly. This is because it uses
@filename@ (instead of @basename@) in a header comment which varies
between builds.

Patch attached.

(The change to "foo.c.in" is not strictly required as this file is not
shipped but it makes sense to have these files have thes same headers
IMHO.)


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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-builds.diff   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-builds.diff   2018-10-07 08:50:34.078550177 
+0100
@@ -0,0 +1,26 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2018-10-07
+
+--- libhandy-0.0.3.orig/src/hdy-enums.c.in
 libhandy-0.0.3/src/hdy-enums.c.in
+@@ -7,7 +7,7 @@
+ /*** END file-header ***/
+ 
+ /*** BEGIN file-production ***/
+-/* enumerations from "@filename@" */
++/* enumerations from "@basename@" */
+ /*** END file-production ***/
+ 
+ /*** BEGIN value-header ***/
+--- libhandy-0.0.3.orig/src/hdy-enums.h.in
 libhandy-0.0.3/src/hdy-enums.h.in
+@@ -13,7 +13,7 @@ G_BEGIN_DECLS
+ 
+ /*** BEGIN file-production ***/
+ 
+-/* enumerations from "@filename@" */
++/* enumerations from "@basename@" */
+ /*** END file-production ***/
+ 
+ /*** BEGIN value-header ***/
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2018-10-07 08:50:32.846542057 +0100
@@ -0,0 +1 @@
+reproducible-builds.diff

Bug#910491: mat2: Please package the Nautilus extension

[intrigeri]

Package: mat2
Version: 0.4.0-1
Severity: wishlist

Hi,

I'm filing this bug mostly to document the current state of things.
This is currently blocked by #907591.

Cheers,
-- 
intrigeri

Bug#910492: Formatting suggestions.

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: htop
Version: 2.2.0-1+b1
Severity: wishlist

Firstly, the UID field only use 4 digits, while in UNIX UIDs can be 0-65535. If 
I have a UID greater than  the list gets misaligned like which shown in the 
screenshot. You should reserve 5 digits for that field.
Secondly, you should use the old format for IO rates (Disk R/W), like other 
fields (just a number, no "B/s").
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAQBQJbucCQCRDYtWA5RV10HwAALfQIALuDve0ncFa+TYBzuFWh
OM3oDBnmUBWtM/BsyJXR//b0jiW+T9GyXaKJHwngj8jMVeLkZGxBVrfmODE2
EgWE9ArG4pxsavCJ36/09DQrY4Bnk+mbVA0g1ShvBs62yrgreFF0l/coEpjf
0PUpZ19qiBOhHw6C3lg9RPb7klIG4tA5apaO5Xg2zf4DUcmLiwzSp6oPyHqN
SM7NsykiAANqC1DVfgmzaX0ePB2dFuFOUO1AlOVc5xzIR/GGeIVjMM3hbpUH
y3WO00xvrTytWc1ZEprA9t3I7nQdfTy0SoqyOoNiNki0/j0I1704zzOlBN/9
Apsig73eJvNzarZ5mDLjbhM=
=stqb
-END PGP SIGNATURE-



2018-10-07-160444_1600x1200_scrot.png.sig
Description: PGP signature


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature

Bug#910486: ffmpeg: vaapi encoding does not work

[Sebastian Ramacher]

Control: reassign -1 i965-va-driver 2.2.0+dfsg1-2

Now with the correct package name.

Cheers

On 2018-10-07 09:57:47, Sebastian Ramacher wrote:
> Control: reassign -1 i965-va-drivers 2.2.0+dfsg1-2
> Control: tags -1 + moreinfo
> 
> Hi
> 
> On 2018-10-07 04:47:06, ghost wrote:
> > Package: ffmpeg
> > Version: 7:4.0.2-2+b1
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> >* What led up to the situation?
> >I am just following the FFmpeg wiki 
> > https://trac.ffmpeg.org/wiki/Hardware/VAAPI, and things are not working as 
> > documented.
> > 
> >* What exactly did you do
> >I first tried the simplest one which should "allows the decoder to work 
> > standlone to make decoding faster without any additional options", then I 
> > tried to feed the vaapi pixfmt to a vaapi encoder, but both are not working 
> > (see below)
> > 
> >* What was the outcome of this action?
> >For the first one:
> > $ ffmpeg -hwaccel vaapi -i cut.mp4 -c:v libx264 output.mp4 -y
> > Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'cut.mp4':
> > Metadata:
> > major_brand : isom
> > minor_version   : 512
> > compatible_brands: isomiso2avc1mp41
> > encoder : Lavf57.56.101
> > Duration: 00:00:19.99, start: 0.008005, bitrate: 451 kb/s
> > Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), 
> > yuv420p(tv, bt470bg/unknown/unknown), 640x480 [SAR 1:1 DAR 4:3], 361 kb/s, 
> > 29.97 fps, 29.97 tbr, 90k tbn, 2k tbc (default)
> > Metadata:
> > handler_name: VideoHandler
> > Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, 
> > stereo, fltp, 111 kb/s (default)
> > Metadata:
> > handler_name: SoundHandler
> > Stream mapping:
> > Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
> > Stream #0:1 -> #0:1 (aac (native) -> aac (native))
> > Press [q] to stop, [?] for help
> > [AVHWFramesContext @ 0x7fc91004d2c0] Failed to read image from surface 
> > 0x418: 20 (the requested function is not implemented).
> 
> This is most certainly a bug in the i965-va-driver when disabling the non-free
> parts. Does evertyhing work as expected if you replace i965-va-driver with
> i965-va-driver-shaders (from non-free)?
> 
> > [h264 @ 0x55b57872fd00] Failed to transfer data to output frame: -5.
> > Error while processing the decoded data for stream #0:0
> > [aac @ 0x55b57872e4c0] Qavg: 1227.311
> > [aac @ 0x55b57872e4c0] 2 frames left in the queue on closing
> > Conversion failed!
> > 
> >For the second one:
> > $ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i cut.mp4 -c:v 
> > h264_vaapi output.mp4
> >...
> > Stream mapping:
> > Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_vaapi))
> > Stream #0:1 -> #0:1 (aac (native) -> aac (native))
> > Press [q] to stop, [?] for help
> > ffmpeg: i965_encoder.c:1692: intel_enc_hw_context_init: Assertion 
> > `encoder_context->mfc_context' failed.
> 
> As above
> 
> > 
> >* What outcome did you expect instead?
> >They should work...
> > 
> > FWIW:
> > 
> > The input is a short video cut in h264. Hardware decoding looks fine:
> > $ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i cut.mp4 -f null 
> > -  
> > ...
> > Stream mapping:
> > Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))
> > Stream #0:1 -> #0:1 (aac (native) -> pcm_s16le (native))
> > Press [q] to stop, [?] for help
> > Output #0, null, to 'pipe:':
> > Metadata:
> > major_brand : isom
> > minor_version   : 512
> > compatible_brands: isomiso2avc1mp41
> > encoder : Lavf58.12.100
> > Stream #0:0(und): Video: wrapped_avframe, vaapi_vld, 640x480 [SAR 
> > 1:1 DAR 4:3], q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn, 29.97 tbc (default)
> > Metadata:
> > handler_name: VideoHandler
> > encoder : Lavc58.18.100 wrapped_avframe
> > Stream #0:1(und): Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 
> > kb/s (default)
> > Metadata:
> > handler_name: SoundHandler
> > encoder : Lavc58.18.100 pcm_s16le
> > frame=  542 fps=0.0 q=-0.0 Lsize=N/A time=00:00:20.08 bitrate=N/A 
> > speed= 194x
> > video:284kB audio:3444kB subtitle:0kB other streams:0kB global 
> > headers:0kB muxing overhead: unknown
> > 
> > $ lspci | grep Graphic
> > 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 
> > 09)
> > 
> > $ vainfo
> > libva info: VA-API version 1.2.0
> > libva info: va_getDriverName() returns 0
> > libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
> > libva info: Found init function __vaDriverInit_1_2
> > libva info: va_openDriver() returns 0
> > vainfo: VA-API version: 1.2 (libva 2.2.0)
> > vainfo: Driver version: Intel i965 driver for Intel(R) Broadwell - 2.2.0
> > vainfo: Supported profile and entrypoints
> > 

Bug#910226: closed by Georges Khaznadar (Bug#910226: fixed in expeyes 4.4.4+dfsg-2)

[Andreas Beckmann]

On 2018-10-07 09:49, Georges Khaznadar wrote:
> Hello Andreas,
> 
> I shall have a look at the maintainer script, indeed.
> 
> However, have you checked whether the upgrade does work? I did it.

I didn't want to send the same logfile again ...

> The version << 4.3 relied on the bad trick (declaring explicitely the
> Python3 compilation), because there was no real python3-, this
> package was only Provide(d), which was probably a bad practice, but
> worked, since the code was compatible with both Python2 and Python3.

https://salsa.debian.org/georgesk/expeyes/blob/master/debian/expeyes-web.postinst#L68

This seems to be your bad trick still present in the current version.


Andreas

Bug#910493: Handle transition from MAT to MAT2

[intrigeri]

Package: mat2
Version: 0.4.0-1
Severity: normal

Hi,

let's discuss how we'll be handling the transition from MAT to MAT2
in Buster. My goal here is to avoid users keeping using the
deprecated, unmaintained MAT v1, and to nicely transition them to the
new MAT2 implementation.

As I wrote on the ITP (trimming down ideas that don't make sense
anymore):

intrigeri:
> What matters to me is the users' perspective. I think we should
> provide a clear, unambiguous transition path and avoid leaking
> technical details to users. So once MAT2 reaches feature parity with
> MAT (I think the only real blocker is the lack of a Nautilus
> extension; MAT v1's seems to be broken on sid currently but it has
> a GUI which mitigates that problem) I think we should:

>  - Have mat2 conflicts+replaces mat, remove mat from testing+sid,
>and ship a transitional package called mat that pulls mat2 in.

IMO we should do that as soon as mat2 installs the Nautilus extension
(#910491).

Does this make sense to you? Is there a better way to handle this?

Cheers!
-- 
intrigeri

Bug#910429: grub-cloud-amd64: fails to install in a chroot

[Andreas Beckmann]

On 2018-10-06 12:33, Bastian Blank wrote:
> Hi
> 
> On Sat, Oct 06, 2018 at 09:15:13AM +0200, Andreas Beckmann wrote:
>> during a test with piuparts I noticed your package failed to install.
> 
> This is more or less expected, as this package will break your
> bootloader if it finds anything useful.

The latter probably holds for all the grub-* packages.
But they are testable by piuparts.

>> per definition of the release team this makes the package too buggy for
>> a release, thus the severity.
> 
> I don't see piuparts mentioned in
> https://release.debian.org/buster/rc_policy.txt

piuparts regressions block migration for quite some time already.

BTW, you are missing Conflicts against
  grub-coreboot, grub-efi-ia32, grub-ieee1275, grub-xen
(ideally they all should make use of Provides/Conflicts/Replaces of some
virtual package for all of them shipping their version of
/etc/kernel/*.d/zz-update-grub).

Andreas

Bug#907518: wpa: problems with openssl 1.1.1

[Andrej Shadura]

On Wed, 5 Sep 2018 14:57:59 -0700 Josh Triplett 
wrote:
> On Wed, Sep 05, 2018 at 11:48:56PM +0200, Kurt Roeckx wrote:
> > The problem here is that the CA you're connecting to has an
> > insecure certificate. You should talk to your administrator
> > to generate stronger keys.
> 
> I am aware of this, and I'm in the process of doing so.
> 
> > The "ca md too weak" is because the certificate is probably using
> > SHA-1, while it should move to SHA256.
> 
> Is there a way I can easily get wpa_supplicant to log the full client
> and server certificate chain, and flag which *specific* certificate in
> that chain it has an issue with? I'm trying to present appropriate
> information to get the wireless network infrastructure improved, and
> unlike https I can't just use `openssl s_client` to get the details I
> need.
> 
> > This can be worked around by using this in your wpa config:
> > openssl_ciphers=DEFAULT@SECLEVEL=1
> 
> I don't suppose you happen to know how I could do that for a
> NetworkManager network configuration?
> 
> > There is also an "ssl_choose_client_version:version too low" message.
> > This is most likely caused by minimum TLS 1.2 version setting. I
> > can't find a way in wpa to override the default. You will have to
> > modify /etc/ssl/openssl.cnf and change:
> > MinProtocol = TLSv1.2
> > to:
> > MinProtocol = TLSv1
> 
> Good to know, thank you.
> 
> > Note that you can also change the cipher string in that file, from
> > CipherString = DEFAULT@SECLEVEL=2
> > to
> > CipherString = DEFAULT@SECLEVEL=1
> > 
> > But I recommend that you do it in the wpa config file if you can
> > instead, so that only the security of that connection is lowered.
> 
> Ideally I'd like to do that for just the one network, yeah.

I’m unsure what can be done to help resolve this issue from the wpa side.

-- 
Cheers,
  Andrej

Bug#910495: openjfx FTBFS on !x86: offlineasm: No magic values found. Skipping assembly file generation.

[Adrian Bunk]

Source: openjfx
Version: 11+26-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=openjfx&suite=sid

...
[ 69%] Generating 
../../DerivedSources/JavaScriptCore/yarr/YarrCanonicalizeUnicode.cpp
[ 69%] Generating 
../../DerivedSources/JavaScriptCore/inspector/InspectorBackendDispatchers.cpp, 
../../DerivedSources/JavaScriptCore/inspector/InspectorBackendDispatchers.h, 
../../DerivedSources/JavaScriptCore/inspector/InspectorFrontendDispatchers.cpp, 
../../DerivedSources/JavaScriptCore/inspector/InspectorFrontendDispatchers.h, 
../../DerivedSources/JavaScriptCore/inspector/InspectorProtocolObjects.cpp, 
../../DerivedSources/JavaScriptCore/inspector/InspectorProtocolObjects.h, 
../../DerivedSources/JavaScriptCore/inspector/InspectorBackendCommands.js
offlineasm: No magic values found. Skipping assembly file generation.
make[4]: *** 
[Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/build.make:107: 
DerivedSources/JavaScriptCore/LLIntAssembly.h] Error 1

Bug#910458: gnome-user-docs FTBFS: 'NoneType' object has no attribute '__getitem__'

[Adrian Bunk]

Control: reassign -1 itstool 2.0.4-1
Control: affects -1 src:gnome-user-docs

On Sat, Oct 06, 2018 at 01:01:55PM -0400, Jeremy Bicha wrote:
> On Sat, Oct 6, 2018 at 11:27 AM Adrian Bunk  wrote:
> > touch "zh_CN/zh_CN.stamp"
> > Error: Could not merge translations:
> > 'NoneType' object has no attribute '__getitem__'
> > make[2]: *** [Makefile:851: ta/ta.stamp] Error 1
> 
> Could you request a give-back? Maybe there's a parallel building problem?

80% of all attempts failed in reproducible:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gnome-user-docs.html

> It's weird because we never used to have a problem here.

After some testing the new itstool turns out to be the culprit.

> Thanks,
> Jeremy Bicha

cu
Adrian

-- 

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

Bug#894260: ITP: ghostwriter

[Sebastien Chavaux]

Hello Ghost
I tried to follow the method found on the site for a package request, I did
not understand everything, certainly because English is not my first
language.

I am still interested in this package but I admit I am not strong enough to
understand all the steps to propose the package site.

thanks for your interest

Le dim. 7 oct. 2018 08:48, ghost  a écrit :

> Hi!
>
> I think you have to send the RFS to sponsorship-requests rather than
> here, otherwise people  simply won't notice it in a pile of wnpp bugs...
>
> Your package seems already deleted on mentors.d.n, and upstream has
> released new versions since then. Are you still interested in this ITP?
>
> Thanks.
>

Bug#910135: xserver-xorg-core: Xserver crashes after update to 1.20.1-4

[Francesco Poli]

Control: found -1 xorg-server/2:1.20.0-3


On Wed, 03 Oct 2018 12:38:37 +0530 Mohammed Sadiq wrote:

[...]
> Xserver crashes everytime when the system is loaded.  The log doesn't seems to
> contain anything useful.  This was also happening in 1.20.0-3.
[...]

Personally, I am not experiencing the same issue, but it seems to me
that I don't have the same graphics hardware.

Anyway, since the bug report submitter says he was seeing the bug with
xserver-xorg-core version 2:1.20.0-3 too, I am adding this version to
the BTS version tracking data...


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


pgpNUIUhtPD30.pgp
Description: PGP signature

Bug#910497: Missing icon in about dialog

[Laurent Bigonville]

Package: gnome-multi-writer
Version: 3.30.0-1
Severity: minor

Hi,

Somehow the icon of gnome-multi-writer is missing in the about dialog,
this is ugly.

Laurent Bigonville

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages gnome-multi-writer depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.0-1
ii  libc62.27-6
ii  libcanberra-gtk3-0   0.30-6
ii  libcanberra0 0.30-6
ii  libglib2.0-0 2.58.1-2
ii  libgtk-3-0   3.24.1-2
ii  libgudev-1.0-0   232-2
ii  libgusb2 0.2.11-1
ii  libpolkit-gobject-1-00.115-1
ii  libudisks2-0 2.8.1-1

gnome-multi-writer recommends no packages.

gnome-multi-writer suggests no packages.

-- no debconf information

Bug#910496: www.debian.org: Website search box return no results for files later than the 6 October 2017

[Jean-Pierre Giraud]

Package: www.debian.org
Severity: normal

Search on https://search.debian.org/ page for words or any strings
present only in files later than the 6 October 2017 return no results,
for example "Spectre" or "3.22.3-1+deb9u1".

To reproduce:
 - use the search box for the term "Spectre" in English (or any other
language) or for "3.22.3-1+deb9u1" (stable fixed version number for
nautilus in DSA-3994-1 released on 7 October 2017). There are no
results.

It's not an issue with the web browser: I tried with firefox and
chromium. Furthermore the command line request "grep -r Spectre" in
webwml directory returns a lot of results, and likewise, "grep -r
3.22.3-1+deb9u1" returns 5 results.

-- System Information:
Debian Release: stretch
 APT prefers stable
Architecture: amd64 (x86_64)

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

Bug#898705: [Android-tools-devel] Bug#898705: android-platform-libcore 8.1 upload to unstable?

[殷啟聰 | Kai-Chung Yan]

I am going to upload the Oreo version of src:android-platform-libcore to 
`unstable` on 9 October if no one objects.

The Oreo (8.x) of this package only builds `android-platform-libcore-headers` 
and `libandroid-json-java` so the majority of the SDK don't really rely on this 
source package any more. Besides, the majority of the SDK is already removed 
from `testing`...



signature.asc
Description: OpenPGP digital signature

Bug#894260: ITP: ghostwriter

[ghost]

> English is not my first language.
Same here, I know how it feels :->

> I am still interested in this package but I admit I am not strong enough 
> to understand all the steps to propose the package site.
There are basically 2 ways when we don't know a specific mentor who can 
help to upload the package:
1. toggle the "need a sponsor" setting at mentors.d.n once you uploaded 
the package, so that it's listed on the main page.
2. send a Request for Sponsor to sponsorship-requests the same way you 
sent this ITP to wnpp.

However, since there has been new upstream releases, we need to get the 
new version into a good shape for upload. Let me know if there is 
anything I can help.

Cheers

Bug#910492: Forwarded and patched upstream

[Daniel Lange]

Control: forwarded -1 https://github.com/hishamhm/htop/issues/841
Control: tags -1 + pending patch
Control: outlook -1 bug forwarded upstream and patch available

Gong,

thank you very much for the bug report, I have forwarded and patched it
upstream. The next version in Debian will contain a fix.

Best regards,
Daniel

Bug#910498: debian-edu: autopkgtest regression: education-menus_2.10.38_amd64.deb (--unpack):, trying to overwrite '/usr/share/tasksel/descs/debian-edu-tasks.desc

[Paul Gevers]

Source: debian-edu
Version: 2.10.38
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of debian-edu the autopkgtest of debian-edu fails
in testing when that autopkgtest is run with the binary packages of
debian-edu from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
debian-edu from testing2.10.38
all others from testingfrom testing

I copied some of the output at the bottom of this report. I am surprised
that piuparts doesn't detect this. As it seems that both education-menus
and education-tasks seem to ship the same file but don't conflict.

Currently this regression is contributing to the delay of the migration
to testing [1]. Can you please investigate the situation and fix it? If
needed, please change the bug's severity.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=debian-edu

https://ci.debian.net/data/autopkgtest/testing/amd64/d/debian-edu/1104720/log.gz

Unpacking education-menus (2.10.38) ...
dpkg: error processing archive
/tmp/autopkgtest-lxc.qygzwd6g/downtmp/autopkgtest_tmp/apt-dpkg-install-O2lVGI/0782-education-menus_2.10.38_amd64.deb
(--unpack):
 trying to overwrite '/usr/share/tasksel/descs/debian-edu-tasks.desc',
which is also in package education-tasks 2.10.38
Selecting previously unselected package education-misc.




signature.asc
Description: OpenPGP digital signature

Bug#906643: transition: php7.3

[Emilio Pozuelo Monfort]

On 02/10/2018 21:00, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> Control: forwarded -1 https://release.debian.org/transitions/html/php7.3.html
> 
> On 19/08/2018 08:49, Ondřej Surý wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> Hi,
>>
>> with PHP 7.3.0~beta2, I would like to start a transition from PHP 7.2
>> to PHP 7.3, so we have the latest PHP version in Debian buster, so the
>> security support can be provided by upstream as longest as possible.
> 
> Since the transition has started, let's mark it as such.
> 
>> title = "php7.3";
>> is_affected = .depends ~ "phpapi-20170718" | .depends ~ "phpapi-20180606";
>> is_good = .depends ~ "phpapi-20180606";
>> is_bad = .depends ~ "phpapi-20170718";
> 
> I have added & ! .depends ~ "phpapi-20180606" to is_bad, so that packages that
> depend on both are marked as good and not as "partial" (both good and bad). 
> Once
> we have things rebuilt and 7.2 support is dropped from -defaults, we can 
> change
> the tracker and rebuild things again to lose 7.2 dependencies. If things don't
> take long (i.e. any ftbfs or other bugs are fixed promptly) I think we can
> finish this before the transition freeze.

Should we add phpapi-20180731 to is_good? Packages are getting that now, see 
e.g.:

https://buildd.debian.org/status/fetch.php?pkg=php-propro&arch=mipsel&ver=2.1.0%2B1.0.2-1%2Bb1&stamp=1538764097&raw=0

Emilio

Bug#910499: ITP: schroedinger-coordgenlibs -- 2D coordinate generation for chemical compounds

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: schroedinger-coordgenlibs
* URL : https://github.com/schrodinger/coordgenlibs
* License : BSD
  Programming Lang: C++
  Description : 2D coordinate generation for chemical compounds

About to be uploaded to 
https://salsa.debian.org/science-team/schroedinger-coordgenlibs

Bug#910244: geeqie: Print window disapear in version 1:1.4+git20180925-1

[Francois Mescam]

On 04/10/2018 13:38, Andreas Ronnquist wrote:

One other difference is that you need to actually show an image in
git20180925 to get an dialog when you press Ctrl+P or select the print
option from the menu. (If you try to print when the program shows the
default geeqie icon that is shown on program start, nothing happens).
In earlier version you would get the dialog, independent of if the
program shows an image you might want to print or not.

No problem with that


Which options are you using to "print a testpage" - Could you direct me
to which options you are using, and I could describe this to upstream
when forwarding this report.

In version 1:1.4+git20180820-1 when I press maj+P or select the print option
the custom print dialog open. In that dialog I choose the option "print 
test page"
and I modify the size of print images as to have multiple images in one 
page.



There is an upstream report tracking the replacement of the print
dialog with standard GTK dialog [1] - It describes "Proof print not
included" - is this maybe the same problem as what you are referring to?
It's not exactly the same but by reading that I found that there in the 
print dialog an
option "Pages by side" which give multiples images in one page but the 
previous custom

print dialog is more precise because I choose the size I want for an image.

I think with that option I have not found when I make the bug report 
that I observe only

a little regression but It's not really a bug.




1: https://github.com/BestImageViewer/geeqie/issues/160


Thank's for your help

Regards


--
Francois Mescam

Bug#909949: RFS: android-platform-system-extras/8.1.0+r23-1 (experimental)

[殷啟聰 | Kai-Chung Yan]

Hello Roger,

> 
> The problem is you didn't mention +ds or +repack in version in d/changelog.
> I guess the version need to be changed to 8.1.0+r23+ds-1 or 
> 8.1.0+r23+repack-1.
> 
> Cheers,
> 

Truth to be told, almost all packages in Debian are "repacked" either by 
applying a different compression (ZIP to TARXZ) and/or stripping out 
incompatible/unnecessary files. And as a result, almost all packages would have 
had a "+repackXX" in the version strings, which is quite unnecessary. The 
Android Tools team does not have such tradition of adding that suffix.

I repacked it manually because `uscan` (or specifically `mk-origtargz`) failed 
to do so with an error, which happens on many of our packages. It was reported 
[1] but seems the fault is on `tar`. Hans probably didn't bother to do it so he 
simply imported the original tarball anyway...

Additionally, 8.1.0+r23 is never uploaded to the archive, so adding a 
"+repackXX" suffix isn't really mandatory.

[1]: https://bugs.debian.org/831870



signature.asc
Description: OpenPGP digital signature

Bug#806535: vim-common: Please add Multi-Arch: foreign

[Elrond]

Hi,


the exact same that applied to vim-runtime now applies
also to vim-common.

Please add Multi-Arch: foreign to vim-common too.


Thanks

Elrond

Bug#910500: libqt5quick5: Sefault in applications using QWebEngineView

[Gabriele Mazzotta]

Package: libqt5quick5
Version: 5.11.1-6
Severity: important

Hi,

I have a simple Qt application that's been segfaulting ever since
libqt5quick5 has been updated to 5.11.1-6. The crash does not happen
with 5.11.1-5, so I assume the problem is caused by the unaligned
memory access fix that's been backported.

See the following example to reproduce the problem. The crash may
happen while scrolling the page, if not as soon as page is loaded.
Not all the webpages can trigger the bug.

I can provide more info in case the example is not enough to
reproduce the problem.

Regards,
Gabriele

---
$ cat main.cpp
#include 
#include 

int main(int argc, char *argv[])
{
QApplication app(argc, argv);

QWebEngineView view;
view.setUrl(QUrl("https://www.qt.io";));
view.resize(1024, 750);
view.show();

return app.exec();
}

$ cat example.pro
TEMPLATE = app

QT += webenginewidgets

SOURCES += main.cpp

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

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

Versions of packages libqt5quick5 depends on:
ii  libc6  2.27-6
ii  libqt5core5a [qtbase-abi-5-11-0]   5.11.1+dfsg-9
ii  libqt5gui5 5.11.1+dfsg-9
ii  libqt5network5 5.11.1+dfsg-9
ii  libqt5qml5 [qtdeclarative-abi-5-11-0]  5.11.1-6
ii  libstdc++6 8.2.0-7

libqt5quick5 recommends no packages.

libqt5quick5 suggests no packages.

-- no debconf information

Bug#910501: openjfx: Installs javafx.control jar for javafx.web jar

[Markus Koschany]

Package: openjfx
Version: 11+26-1
Severity: serious

OpenJFX installs the javafx.control jar for javafx.web.jar. Most
likely a copy&paste error in libopenjfx-java.poms. This means that web
related classes are missing which makes e.g. mediathekview FTBFS.

Markus

Bug#904558: What should happen when maintscripts fail to restart a service

[Simon McVittie]

Attempting to summarize what was said on this topic in the thread so
far, and at the last technical committee meeting:

It's perhaps important to note that we are not discussing ideal situations
here: any time this conversation becomes relevant, something is already
wrong. We're aiming to recommend the lesser evil, rather than something
actually desirable.

One of the points of view here is Ian and Wouter's assertion that
whenever a service fails to restart in a maintainer script, the most
important thing is to make sure the sysadmin pays attention and fixes
it before proceeding.

Julien Cristau made another point in support of "failure to restart
implies failure to configure" on IRC, namely that the only straightforward
thing for an automated upgrade to do is to look at the successful or
failed exit status of the package manager (whether that means dpkg,
apt, unattended-upgrades or whatever), and assume that exiting 0 means
everything is fine and exiting nonzero means attention is required.

At the opposite extreme, Marga's team manages thousands of desktops,
and having to do *anything* manual to any significant number of them
doesn't scale. We can think of inexperienced users' desktops as a bit
like this scenario too, except that instead of having a professional
sysadmin, they have to ask volunteers for help through channels like
debian-user and #debian (and those volunteers' help doesn't really scale
well either). It's also undesirable if the mechanism we use to escalate
the failure to the user is one that itself makes it harder to diagnose or
fix the problem, and in particular there's a concern that when packages
fail to configure, that can make it harder to use apt to install the
necessary tools to diagnose what has gone wrong; Stuart points out that in
his experience of helping people in #debian, this is a practical problem.

Ian considers it to be design flaw in apt that the actions the user
can take while a package is unconfigured are so constrained; however,
we work with the tools we have, not the tools we'd like to have.

We seem to have consensus among the technical committee that it is at
least occasionally appropriate for failure to restart to cause failure
to configure, although this might be the exception rather than the
rule. The examples given where the error path is most important were
packages that provide a system-level API to other packages, so their
failures are likely to cause other packages to fail to configure (such
as local DNS caches and authentication services like LDAP); and packages
that provide remote access, so their failures need to be fixed before a
potentially remote sysadmin logs out to prevent the sysadmin from being
locked out longer-term (like sshd).

I'm not sure whether we have a concrete example yet of packages at the
opposite extreme, that are the least important to be able to restart. I'd
like to propose the game servers that I maintain, like openarena-server,
as a concrete example here: I hope we can agree that inability to capture
the flag does not justify getting the package management system into a
problematic state? :-) (I think this is currently a bug in those packages,
but I'm not going to fix it until we have consensus here.)

There's a general feeling among the technical committee that a package
failing to configure is far from a user-friendly way to signal errors:
Phil's memorable analogy was that it's like telling a car driver that they
are low on fuel by having the wheels fall off. Historically, we had few
other ways to manage service failures, and perhaps when all you have is
a hammer, everything looks like the Failed-Config state; but in a default
Debian installation we now have a service manager that monitors the state
of all services at all times (not just when they happen to be upgraded)
and collects their stderr at all times (not just writing it to the console
during boot, and dpkg's stderr during upgrades). Even before we considered
non-sysv init systems, monitoring systems like Nagios were available.

It's perhaps also worth noting that most services, if they fail during
boot rather than during upgrade, don't cause a drastic reaction.
Historically, initscripts would (attempt to) carry on regardless from
just about any failure mode, including failure of services that ought to
be considered critical-path. With systemd as default, our default init
system does have a more dramatic response to certain failures (going
to an emergency-mode shell), but it only does that for a very limited
subset of services (fsck and mount on required filesystems, according to
the man page).

As Anthony points out, we could benefit from there being a way
for packages to report "something is wrong, but carry on anyway":
continuing to get the system into the least-degraded state possible,
but then arranging for dpkg/apt to exit with a nonzero status so that
automated systems can detect that something is not right. However,
this mechanism does not currently exist. One po

Bug#905215: CVE-2018-2941

[Markus Koschany]

Hi,

On Wed, 01 Aug 2018 16:45:30 +0200 Moritz Muehlenhoff 
wrote:
> Source: openjfx
> Severity: grave
> Tags: security
> 
> http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html
> fixed CVE-2018-2941 in JavaFX, which should affect our openjfx package.

We have recently upgraded OpenJFX to version 11. It is not listed as a
vulnerable version in Oracle's security advisory. I presume if it has
been vulnerable they would have fixed it in OpenJFX 11 too by now. Do
you have more information about this vulnerability because I can't find
any details on the web.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#910502: backport: jessie-backports is broken on arm64

[nadav.ruskin]

Package: other 
Severity: important

Dear Maintainer,

I am no longer able to use Jessie-backports to retrieve arm64 packages.

With 'deb http://ftp.debian.org/debian jessie-backports main' in my 
sources.list, I get the following trace, tested on multiple computers and in 
this case using docker:
>Step 2/24 : COPY build_tools/dockerfiles/sources.list /etc/apt/sources.list
> ---> 6081eac1de65
>Step 3/24 : RUN dpkg --add-architecture arm64 ; apt-get update ; apt-get -y 
>upgrade ; apt-get update && apt-get -y install wget gawk gperf help2man 
>texinfo gcc gperf bison flex texinfo make libncurses5-dev python-dev && 
>apt-get -y install libavcodec-dev:arm64 libavformat-dev:arm64 
>libswscale-dev:arm64 libjpeg-dev:arm64 libpng-dev:arm64 libtiff-dev:arm64 
>libdc1394-22:arm64 libdc1394-22-dev:arm64 libv4l-dev:arm64 ffmpeg:arm64 && 
>apt-get -y install --no-install-recommends libgtk2.0-dev:arm64 && apt-get 
>remove -y cmake && apt-get clean -y
> ---> Running in b5709d0760d3
>Get:1 http://ftp.debian.org jessie-backports InRelease [166 kB]
>Ign http://deb.debian.org oldstable InRelease
>Get:2 http://deb.debian.org oldstable-updates InRelease [145 kB]
>Get:3 http://deb.debian.org oldstable Release.gpg [2420 B]
>Get:4 http://deb.debian.org oldstable Release [148 kB]
>Get:5 http://ftp.debian.org jessie-backports/main amd64 Packages [1172 kB]
>Get:6 http://deb.debian.org oldstable-updates/main amd64 Packages [23.0 kB]
>Get:7 http://ftp.debian.org jessie-backports/main arm64 Packages [1115 kB]
>Get:8 http://deb.debian.org oldstable-updates/contrib amd64 Packages [20 B]
>Get:9 http://deb.debian.org oldstable-updates/non-free amd64 Packages [449 B]
>Get:10 http://deb.debian.org oldstable-updates/main arm64 Packages [22.8 kB]
>Get:11 http://deb.debian.org oldstable-updates/contrib arm64 Packages [20 B]
>Get:12 http://deb.debian.org oldstable-updates/non-free arm64 Packages [449 B]
>Get:13 http://deb.debian.org oldstable/main amd64 Packages [9098 kB]
>Get:14 http://deb.debian.org oldstable/contrib amd64 Packages [59.2 kB]
>Get:15 http://deb.debian.org oldstable/non-free amd64 Packages [101 kB]
>Get:16 http://deb.debian.org oldstable/main arm64 Packages [8593 kB]
>Get:17 http://deb.debian.org oldstable/contrib arm64 Packages [41.2 kB]
>Get:18 http://deb.debian.org oldstable/non-free arm64 Packages [68.6 kB]
>Fetched 20.8 MB in 1min 1s (340 kB/s)
>Reading package lists...
>W: Size of file 
>/var/lib/apt/lists/ftp.debian.org_debian_dists_jessie-backports_main_binary-amd64_Packages.gz
> is not what the server reported 1171578 1171626
>Reading package lists...
>Building dependency tree...
>Reading state information...
>The following packages will be upgraded:
>  linux-libc-dev
>1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>Need to get 1335 kB of archives.
>After this operation, 792 kB of additional disk space will be used.
>Get:1 http://ftp.debian.org/debian/ jessie-backports/main linux-libc-dev amd64 
>4.9.88-1+deb9u1~bpo8+1 [1335 kB]
>debconf: delaying package configuration, since apt-utils is not installed
>Fetched 1335 kB in 0s (1748 kB/s)
>(Reading database ... 19049 files and directories currently installed.)
>Preparing to unpack .../linux-libc-dev_4.9.88-1+deb9u1~bpo8+1_amd64.deb ...
>Unpacking linux-libc-dev:amd64 (4.9.88-1+deb9u1~bpo8+1) over (3.16.57-2) ...
>Setting up linux-libc-dev:amd64 (4.9.88-1+deb9u1~bpo8+1) ...
>Hit http://ftp.debian.org jessie-backports InRelease
>Get:1 http://ftp.debian.org jessie-backports/main amd64 Packages [1172 kB]
>Ign http://deb.debian.org oldstable InRelease
>Hit http://deb.debian.org oldstable-updates InRelease
>Hit http://deb.debian.org oldstable Release.gpg
>Get:2 http://ftp.debian.org jessie-backports/main arm64 Packages [1115 kB]
>Hit http://deb.debian.org oldstable Release
>Get:3 http://deb.debian.org oldstable-updates/main amd64 Packages [23.0 kB]
>Get:4 http://deb.debian.org oldstable-updates/contrib amd64 Packages [20 B]
>Get:5 http://deb.debian.org oldstable-updates/non-free amd64 Packages [449 B]
>Get:6 http://deb.debian.org oldstable-updates/main arm64 Packages [22.8 kB]
>Get:7 http://deb.debian.org oldstable-updates/contrib arm64 Packages [20 B]
>Get:8 http://deb.debian.org oldstable-updates/non-free arm64 Packages [449 B]
>Get:9 http://deb.debian.org oldstable/main amd64 Packages [9098 kB]
>Get:10 http://deb.debian.org oldstable/contrib amd64 Packages [59.2 kB]
>Get:11 http://deb.debian.org oldstable/non-free amd64 Packages [101 kB]
>Get:12 http://deb.debian.org oldstable/main arm64 Packages [8593 kB]
>Get:13 http://deb.debian.org oldstable/contrib arm64 Packages [41.2 kB]
>Get:14 http://deb.debian.org oldstable/non-free arm64 Packages [68.6 kB]
>Fetched 20.3 MB in 28s (703 kB/s)
>Reading package lists...
>Reading package lists...
>Building dependency tree...
>Reading state information...
>bison is already the newest version.
>flex is already the newest version.
>gawk is already the newest version.
>gcc is already the newest version.

Bug#910111: RFP: solid -- set of conventions and tools for building decentralized social applications based on Linked Data principles

[Adrian Bunk]

Control: retitle -1 RFP: solid-social -- set of conventions and tools for 
building decentralized social applications based on Linked Data principles

On Tue, Oct 02, 2018 at 01:20:48PM -0700, Matt Taggart wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: solid
>   Version : varies
>   Upstream Author : varies
> * URL : https://solid.mit.edu/
> * License : MIT
>   Programming Lang: node.js, etc
>   Description : set of conventions and tools for building
> decentralized social applications based on Linked Data principles
>...

The binary package name "solid" is still available, but there is already 
a completely unrelated package src:solid in Debian:
  https://tracker.debian.org/pkg/solid

This has to be sorted out if this software actually gets packaged,
I am retitling the RFP to a temporary name to make it clear that
this is something different.[1]

cu
Adrian

[1] If it builds a binary package solid there would be benefits
in renaming the other src:solid (the BTS handles binary package
in a different source package than a source package of the same
name very poorly), but this should be discussed when it becomes
relevant.

-- 

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

Bug#905215: CVE-2018-2941

[Moritz Muehlenhoff]

On Sun, Oct 07, 2018 at 01:04:38PM +0200, Markus Koschany wrote:
> Hi,
> 
> On Wed, 01 Aug 2018 16:45:30 +0200 Moritz Muehlenhoff 
> wrote:
> > Source: openjfx
> > Severity: grave
> > Tags: security
> > 
> > http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html
> > fixed CVE-2018-2941 in JavaFX, which should affect our openjfx package.
> 
> We have recently upgraded OpenJFX to version 11. It is not listed as a
> vulnerable version in Oracle's security advisory. I presume if it has
> been vulnerable they would have fixed it in OpenJFX 11 too by now. Do
> you have more information about this vulnerability because I can't find
> any details on the web.

No, unfortunately it's the same "we fix, but don't tell" bullshit policy
as with all other Oracle products.

Given that mediathekview is our only reverse dependency in stretch we
can probably mark it as ignored for stretch anyway?

Cheers,
Moritz

Bug#910503: the data source for units_cur is gone

[Marco d'Itri]

Package: units
Version: 2.17-3
Severity: important
Tags: upstream

Error connecting to currency server:
404 Client Error: Not Found for url: 
https://finance.yahoo.com/webservice/v1/symbols/allcurrencies/quote?format=json.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#905215: CVE-2018-2941

[Markus Koschany]

Am 07.10.18 um 13:16 schrieb Moritz Muehlenhoff:
[...]
> No, unfortunately it's the same "we fix, but don't tell" bullshit policy
> as with all other Oracle products.
> 
> Given that mediathekview is our only reverse dependency in stretch we
> can probably mark it as ignored for stretch anyway?
> 
> Cheers,
> Moritz

Ok. MediathekView in Stretch only uses JavaFX to create some better
integrated Panel messages or to improve performance. If I read the
advisory correctly CVE-2018-2941 affects Java Web Start or Java applets
but MediathekView is a desktop application and doesn't use those
classes, so I believe it cannot be exploited. Ignored for Stretch makes
sense.

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#910504: Long delay until kernel logs “random: crng init done” and allows eg. gdm3 to start

[Grzegorz Szymaszek]

Package: broadcom-sta-dkms
Version: 6.30.223.271-8~bpo9+2

Dell Latitude E6420 with a Dell Wireless 1530 (Broadcom BCM43228) card.

When this package is installed, there’s a long delay between systemd’s
“Startup finished” message and kernel’s “crng init done” message, around
3–4 minutes. While the SSH server is available immediately (once
connected to WiFi), GDM does not start until the latter message gets
logged.

The problem does not occur if the rng-tools package is installed.

See also .



signature.asc
Description: PGP signature

Bug#910429: grub-cloud-amd64: fails to install in a chroot

[Bastian Blank]

Control: reassign -1 release.debian.org
Control: retitle -1 piuparts not able to test grub-cloud due to missing /dev

On Sun, Oct 07, 2018 at 10:51:01AM +0200, Andreas Beckmann wrote:
> piuparts regressions block migration for quite some time already.

Well, then let's re-assign tht to release.d.o.

Bastian

-- 
We do not colonize.  We conquer.  We rule.  There is no other way for us.
-- Rojan, "By Any Other Name", stardate 4657.5

Bug#910018: RFS: hoteldruid/2.2.4-1

[Adam Borowski]

On Mon, Oct 01, 2018 at 02:24:52PM +0200, Marco M. F. De Santis wrote:
> * Package name: hoteldruid
>   Version : 2.2.4-1

> Changes since the last upload:
> 
>   * New upstream release.
>   * debian/control: updated Standards-Version
>   * debian/control: added suggest on sensible-utils for
> hoteldruid-launcher previously included in debianutils

I'm pretty sure "hoteldruid-launcher" has never been included in either
sensible-utils nor debianutils.  Care to clarify?

Besides, both packages are >= priority:important, thus a stronger dependency
has no downsides (as hoteldruid is not something that cares about cutting
every little bit of bloat from a container it runs in).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Bug#910433: thunderbird: Open hyperlink and attachments in system default applications not working

[Johannes Rohr]

I upgraded most packages to unstable, which somehow seems to have fixed it.

Bug#910505: Include can't be used with -std=c99 on aarch64

[Guido Günther]

Package: libunwind-dev
Version: 1.2.1-8
Severity: normal
Forwarded: https://github.com/libunwind/libunwind/pull/89

While building mesa I stepped on this on aarch64:

```
$ cat < bla.c
#include 

int main()
{
unw_tdep_context_t *uc = NULL;
unw_tdep_getcontext(uc);
}
EOF

# This works
$ gcc bla.c

# This does not
$ gcc -std=c99 bla.c
In file included from /usr/include/aarch64-linux-gnu/libunwind.h:7,
 from bla.c:1:
bla.c: In function ‘main’:
bla.c:6:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘asm’
 unw_tdep_getcontext(uc);
 ^~~
bla.c:6:5: error: ‘mcontext_t’ {aka ‘struct ’} has no member named 
‘regs’; did you mean ‘__regs’?
 unw_tdep_getcontext(uc);
 ^~~
bla.c:6:5: error: ‘unw_base’ undeclared (first use in this function); did you 
mean ‘unw_ctx’?
 unw_tdep_getcontext(uc);
 ^~~
bla.c:6:5: note: each undeclared identifier is reported only once for each 
function it appears in
bla.c:6:5: error: invalid lvalue in asm output 0
 unw_tdep_getcontext(uc);
 ^~~
```

See https://github.com/libunwind/libunwind/pull/89.


Cheers,
 -- Guido


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

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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)
LSM: AppArmor: enabled

Versions of packages libunwind-dev depends on:
ii  liblzma-dev  5.2.2-1.3
ii  libunwind8   1.2.1-8

libunwind-dev recommends no packages.

libunwind-dev suggests no packages.

-- no debconf information

Bug#910495: openjfx FTBFS on !x86: offlineasm: No magic values found. Skipping assembly file generation.

[Emmanuel Bourg]

Control; severity -1 important

Downgrading the severity, upstream doesn't support non x86 architectures
and the packages are only provided as a best effort.

Bug#910506: split package into architecture dependent and independent ones

[W. Martin Borgert]

Package: prosody
Version: 0.10.2-1

Currently only one, architecture dependent package is created.
However, most of prosody consists of architecture independent files.

I like to separate the few .so files into prosody-lib to save some
space on the archive.

Any objections?

Bug#910507: muffin: 3 MB per hour log entries in .xsession-errors

[Andreas]

Package: muffin
Version: 3.2.1-2
Severity: normal

Dear Maintainer,

Debian stretch is still using the buggy muffin 3.2.1, and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877026 says it was fixed only
in muffin 3.4

How can I upgrade my Debian stretch to muffin 3.4 or newer?

In "testing" there is already a 3.8 - but everywhere I look, I am discouraged
to mix -stable and -testing.

Is there something like a ...-backports for Debian stretch users? Why not?

What can I do now?

I have asked here https://github.com/linuxmint/muffin/issues/364 and the answer
was quite sarcastic: Use Linux Mint instead.

But I like my Debian, I just don't want to have my `.xsession-errors` fill up
with 3 MB / hour.


   * What led up to the situation?

unplugging my external screen.

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

opening an issue for muffin on github


   * What was the outcome of this action?

I was told to install Linux Mint instead.

   * What outcome did you expect instead?

That I am told how to upgrade muffin to a newer version - because the bug was
fixed long ago.


muffin --version
muffin 3.2.1

uname -a
Linux Dell13-5378 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u5 (2018-09-30)
x86_64 GNU/Linux

Thanks.




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

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

Versions of packages muffin depends on:
ii  libc6   2.24-11+deb9u3
ii  libcairo2   1.14.8-1
ii  libclutter-1.0-01.26.0+dfsg-3
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u2
ii  libglib2.0-02.50.3-2
ii  libgtk-3-0  3.22.11-1
ii  libmuffin0  3.2.1-2
ii  libpango-1.0-0  1.40.5-1
ii  libx11-62:1.6.4-3
ii  muffin-common   3.2.1-2
ii  zenity  3.22.0-1+b1

Versions of packages muffin recommends:
ii  cinnamon-session [x-session-manager]  3.2.0-4

Versions of packages muffin suggests:
ii  cinnamon-control-center  3.2.1-3
ii  xdg-user-dirs0.15-2+b1

-- no debconf information

Bug#910495: openjfx FTBFS on !x86: offlineasm: No magic values found. Skipping assembly file generation.

[Markus Koschany]

Am 07.10.18 um 14:31 schrieb Emmanuel Bourg:
> Control; severity -1 important
> 
> Downgrading the severity, upstream doesn't support non x86 architectures
> and the packages are only provided as a best effort.

I believe this issue is related to the patches that disable JIT
compilation.

After some searching I found this commit for chromium.

https://chromium.googlesource.com/chromium/blink/+/0f33582d630dbd3fc1c65d1373034dc932e654c8%5E!/


Perhaps the if else conditional will make a difference. I have applied a
new patch to test it while also fixing #910501.

The code that throws the error message is in asm.rb but it has more to
do with LLIntOffsetsExtractor.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#910444: Filesystems listed in /etc/fstab are no more automatically mounted since switching to OpenRC

[Adam Borowski]

On Sat, Oct 06, 2018 at 02:40:22PM +0200, Axel Beckert wrote:
> Package: openrc
> Version: 0.34-3
> Severity: grave
> Justification: renders package unusable

> Hi,
> 
> I just installed Debian Buster/Sid from scratch on a GPD Pocket 1 and
> then switched from systemd to OpenRC.
> 
> Since then, /home (on LVM on LUKS), /boot and /boot/efi (i.e. anything
> from /etc/fstab except the root file system) are no more mounted
> automatically despite they're listed in /etc/fstab and "mount -a"
> mounts them without issues.

It works for continously upgraded systems.  I can't check a fresh one anytime
soon (explanation below), but it appears that installing a new daemon[1]
doesn't properly register it for requested runlevels (you can still run
update-rc.d to fix that).  Not sure if this is the cause, would need to look
more.  Too bad, init-system-helpers didn't have an update in almost two
months so the culprit might be something else.

Benda: could you please take a look?  The package being unusable on new
systems sounds pretty urgent...

Alas, I'm currently moving and won't have my usual setup for at least a week
(likely longer).  I'm on a Pinebook right now, even my Gemini suddenly broke
and won't boot (yeah, another proof of The Conspiracy against me...); it's
not a machine to test VM installs on.  In theory I could find out how to run
qemu's gui interface remotely (as I used to do with VirtualBox before it went
apeshit), but this particular piece of technical debt is better learned in a
more confortable setting.

> Swap hasn't been activated by "mount -a", though. (Probably expected,
> just wanted to mention it.)

Sounds consistent with init scripts not having been registered.


[1]. On a real box, you'd want something totally harmless; I tested on npd6.
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Bug#891410: upstream work is already in progress

[Hein, Jochen]

Hello again,

Am 2018-07-02 21:05, schrieb Christoph Biedl:
Thanks for reminding me, it's on radar - but given the discussion 
hasn't

been finished yet I'd prefer to wait until this is part of another
clevis release. If you'd like to have it cherry-picked so people can
start playing with it, let me know.


Hm, the usptream discussion seems to have stalled.  Since the
freeze for buster is nearing I'd like to see it cherry-picked.
What do you think?

Jochen

--
The only problem with troubleshooting is that the trouble shoots back.

Bug#910507: extrapolation: 781,200 lines per day added to logfile

[Andreas]

Package: muffin
Version: 3.2.1-2
Followup-For: Bug #910507



tail .xsession-errors
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed

date +%r; wc -l .xsession-errors; ls -s --block-size=K .xsession-errors
 2:12:39 pm BST
35025 .xsession-errors
3836K .xsession-errors

date +%r; wc -l .xsession-errors; ls -s --block-size=K .xsession-errors
 2:13:27 pm BST
35459 .xsession-errors
3896K .xsession-errors

extrapolation:

781,200 lines added per day
108,000 Kbyte added per day


Please help. How to upgrade muffin in Debian stretch?

Thanks.








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

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

Versions of packages muffin depends on:
ii  libc6   2.24-11+deb9u3
ii  libcairo2   1.14.8-1
ii  libclutter-1.0-01.26.0+dfsg-3
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u2
ii  libglib2.0-02.50.3-2
ii  libgtk-3-0  3.22.11-1
ii  libmuffin0  3.2.1-2
ii  libpango-1.0-0  1.40.5-1
ii  libx11-62:1.6.4-3
ii  muffin-common   3.2.1-2
ii  zenity  3.22.0-1+b1

Versions of packages muffin recommends:
ii  cinnamon-session [x-session-manager]  3.2.0-4

Versions of packages muffin suggests:
ii  cinnamon-control-center  3.2.1-3
ii  xdg-user-dirs0.15-2+b1

-- no debconf information

Bug#910507: extrapolation: 781,200 lines per day added to logfile

[postings]

tail .xsession-errors
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed
Window manager warning: Log level 8: meta_screen_get_monitor_geometry:
assertion 'monitor >= 0 && monitor < screen->n_monitor_infos' failed

date +%r; wc -l .xsession-errors; ls -s --block-size=K .xsession-errors
 2:12:39 pm BST
35025 .xsession-errors
3836K .xsession-errors

date +%r; wc -l .xsession-errors; ls -s --block-size=K .xsession-errors
 2:13:27 pm BST
35459 .xsession-errors
3896K .xsession-errors

extrapolation:

781,200 lines added per day
108,000 Kbyte added per day


Please help.

Thanks.

Bug#910508: lxde-common: closed bug #760971 still not fixed on debian 9.5 and lxde-common 0.99.2-3

[root]

Package: lxde-common
Version: 0.99.2-3
Severity: important

Dear Maintainer,

   * What led up to the situation?

   Installing fresh minimal debian 9.5 netinstall and wanted to have a
   minimal lxde. A find that closed reported bug #760971 describes
   exactly what I experienced.

   I don't know enough to put panels and check if I can recover it.
   
   killing lxpanel gets launched again with a new PID so I cannot try to
   launch lxpnael withough --profile argument

   I tried to copy panels from /etc/xdg but it does not work but it
   could be that I'm copying things in the wrong place.

   I did an apt-get update; apt-ge upgrade to use the lastest packets
   available. Still not working.

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

Kernel: Linux 4.9.0-8-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
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)

lxde-common depends on no packages.

Versions of packages lxde-common recommends:
ii  gnome-screenshot 3.22.0-1+b1
ii  lxde-core9
ii  lxlock   0.5.3-2
ii  lxpanel  0.9.3-1
ii  lxrandr  0.3.1-1
ii  lxsession-logout 0.5.3-2
ii  lxtask   0.1.8-1
ii  openbox-lxde-session [lxde-session]  0.99.2-3
ii  pcmanfm  1.2.5-3

Versions of packages lxde-common suggests:
pn  lxlauncher  

-- no debconf information

Bug#672704: [blop] LADSPA plugins shouldn't call setlocale()

[trebmuh]

Hi all,

I can confirm that the bug is still present in the 0.2.8-6 package on 
Debian Stretch.


The way I encountered it is that I (manually by compilation since there 
is no package in Debian for it) installed cinelerra (both CV and GG 
version), then when launching it, its GUI is in English. Then, I've 
removed the blop package (with synaptic) and relaunched cinelerra and 
now, the GUI is displayed in French (my locale).


I've seen that there is a patch attached, but it seems from the comment 
above that it's not safe to apply it so I didn't try.


What would you people would recommend to move forward from here?
It could be great to have this one fixed for the next buster release.

Cheers,
Olivier

PS : note that this bug is affecting mhWaveEdit as well.

Steps to reproduce with mhWaveEdit:
1) open mhwaveedit with a French locale
2) go to Fichier -> Ouvrir... (file -> open...) and open an audio file
3) cut (ctrl-x) a part of it
4) go to Fichier -> Quitter (file -> quit)
the pop up window asking if you want to save the changes is in French. 
All good.


Then (with the blop package installed):
5) open mhwaveedit with a French locale
6) go to Fichier -> Ouvrir... (file -> open...) and open an audio file
7) got to Effets -> boite à effets...
see that a part of this new window is in English
8) push the "Fermer" button ("close")
9) cut (ctrl-x) a part of the audio file
10) go to Fichier -> Quitter (file -> quit)
the pop up window asking if you want to save the changes is now in 
English. Something is wrong here.


Then, uninstall the blop package:
11) open mhwaveedit with a French locale
12) go to Fichier -> Ouvrir... (file -> open...) and open an audio file
13) got to Effets -> boite à effets...
see that a the window is now fully in French
8) push the "Fermer" button ("close")
9) cut (ctrl-x) a part of the audio file
10) go to Fichier -> Quitter (file -> quit)
now, the pop up window asking if you want to save the changes is in 
French. All good.



PS-2: copying debian multimedia maintainer to this report

Bug#910376: mat2: Incomplete debian/copyright?

[Georg Faerber]

Hi Chris,

Thanks for reporting.

On 18-10-05 17:31:50, Chris Lamb wrote:
> I just ACCEPTed mat2 from NEW but noticed it was missing attribution
> in debian/copyright for at least a certain "Marie Rose".
> 
> This is in no way exhaustive so please check over the entire package
> carefully and address these on your next upload.

Currently, we don't ship the logo, but I'm unsure if this matters?

Cheers,
Georg


signature.asc
Description: Digital signature

Bug#910509: ITP: r-cran-emoa -- GNU R evolutionary multiobjective optimization algorithms

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-emoa
  Version : 0.5
  Upstream Author : Olaf Mersmann 
* URL : https://cran.r-project.org/package=emoa
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R evolutionary multiobjective optimization algorithms
 This GNU R package contains a collection of building blocks for
 the design and analysis of evolutionary multiobjective optimization
 algorithms.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-emoa

Bug#910510: ITP: r-cran-ggally -- GNU R extension to r-cran-ggplot2

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-ggally
  Version : 1.4.0
  Upstream Author : Barret Schloerke (author for ggpairs, ggduo, ggnostic, ggts,
* URL : https://cran.r-project.org/package=GGally
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R extension to r-cran-ggplot2
 The R package 'ggplot2' is a plotting system based on the grammar of
 graphics. 'GGally' extends 'ggplot2' by adding several functions to
 reduce the complexity of combining geometric objects with transformed
 data. Some of these functions include a pairwise plot matrix, a two
 group pairwise plot matrix, a parallel coordinates plot, a survival
 plot, and several functions to plot networks.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-ggally

Bug#910511: network-manager-openvpn: openvpn 2.4 in stable supports tls-crypt, but nm-openvpn 1.2.8 in stable doesn't

[Gijs Molenaar]

Package: network-manager-openvpn
Version: 1.2.8-2
Severity: important

Dear Maintainer,

I'm developing a UI wrapper around various platforms for an open VPN service.
Debian 9 is one of our targetted platforms. We have tls-crypt enabled for our
service, which works on Debian 9 since it is bundeled with openVPN 2.4.0. The
problem is the network-manager-openvpn package, which doesn't seem to have
support for this setting. This is a bit of a pitty, since technically it should
work. The limitation becomes apparant when you for example import a .ovpn file
in the UI with a tls-crypt statement in it. The import will fail.

It looks like network-manager-openvpn > 1.2.10 actually has support for the
tls-crypt statement.

Now i'm not sure if this is the right spot to request such a thing, but is it
somehow possible to get network-manager-openvpn > 1.2.10 into stable? Important
security features are now not available to stable users, while technically it
is supported.

Greetings,

 - Gijs




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

Kernel: Linux 4.9.0-8-amd64 (SMP w/16 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 network-manager-openvpn depends on:
ii  adduser  3.115
ii  libc62.24-11+deb9u3
ii  libglib2.0-0 2.50.3-2
ii  libnm0   1.6.2-3
ii  network-manager  1.6.2-3
ii  openvpn  2.4.0-6+deb9u2

network-manager-openvpn recommends no packages.

network-manager-openvpn suggests no packages.

-- no debconf information

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Michael Biebl]

Am 07.10.18 um 01:57 schrieb Michael Biebl:
> Am 07.10.18 um 01:06 schrieb Michael Biebl:
> 
>> We change the init script as follows:
>> - We revert most the changes from #791944, we only keep the stop
>> symlinks for rc0 and rc6 and the cleanup of /run/udev/control file on stop.
>> - We tweak the LSB headers to make sure the udev init script is called
>> before sendsigs on shutdown. This is important!
>>
>> This should ensure that udevd is properly killed and the control file
>> removed, i.e. there should be (almost) no time window where the udevd
>> daemon is not running but the control file exists.
>>
>> On the other hand, this would mean we again stop udevd earlier during
>> shutdown, but we mostly had this behaviour already in previous releases
>> where udevd is killed by sendsigs.
> 
> I have to add, that this change has the potential to significantly
> change the shutdown order or cause a conflicting ordering, in case there
> are other init scripts which declare an explicit shutdown dependency.

To answer my own question:
Adding "Should-Stop: sendsigs" to udev will not work as it creates a
dependency cycle with cryptdisks and cryptdisks-early (which have
Should-Stop: udev, so require udev to stop *after* themselves).

Trek, what was the problem with checking for /run/udev/control to
determine if the udev service is available or not?


-- 
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#910376: mat2: Incomplete debian/copyright?

[intrigeri]

Hi Georg,

Georg Faerber:
> Currently, we don't ship the logo, but I'm unsure if this matters?

We do ship the logo in the source package so it does matter :)

Cheers,
-- 
intrigeri

Bug#826214: SysV init scripts using init-d-script are not properly redirected to systemctl

[Michael Biebl]

Control: tags -1 + pending

On Thu, 11 Jan 2018 01:38:00 +0300 Mert Dirik  wrote:
> On Wed, 10 Jan 2018 22:49:17 +0300 Mert Dirik  wrote:
>  > On 01/10/18 21:20, Petter Reinholdtsen wrote:
>  > > [Mert Dirik]
>  > >> Please forgive my naivety, but simply moving the argument shift 
> part before
>  > >> sourcing /lib/lsb/init-functions seems to successfully redirect to
>  > >> systemctl.
>  > > Interesting. This seem like a very good idea. :)
>  > I'm happy to hear that.
>  > >
>  > >> The only variable leaking to /lib/lsb/init-functions is "script", 
> which can be
>  > >> easily renamed and namespaced in case of a possible problem.
>  > > Perhaps good to give it some init-d-script related prefix, to 
> reduce the
>  > > chance of a future collision?
>  > Maybe "__init_d_script_path"?
>  > >
>  > >> Is there anything wrong with this approach?
>  > > Nothing I could think of from the top of my head. :)
>  > >
>  > Great :) I'll test it again in stretch or sid and I'll post the result
>  > here. (previous test was done in jessie)
>  >
> 
> I've tested the attached patch in a sid lxc container and the issue 
> seems to be fixed there.


Thanks Mert for the patch and Petter for the review.

I've prepared an NMU with Mert's latest version of the patch and
uploaded it to DELAYED/7.
Full debdiff is attached.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
diff -Nru sysvinit-2.88dsf/debian/changelog sysvinit-2.88dsf/debian/changelog
--- sysvinit-2.88dsf/debian/changelog   2017-09-08 21:18:37.0 +0200
+++ sysvinit-2.88dsf/debian/changelog   2018-10-07 16:04:09.0 +0200
@@ -1,3 +1,15 @@
+sysvinit (2.88dsf-59.11) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Mert Dirik ]
+  * Make sure that services using init-d-script can be properly redirected to
+systemctl. (Closes: #826214)
+  * Avoid naming collisions when storing the script name in init-d-script by
+using a custom prefix.
+
+ -- Michael Biebl   Sun, 07 Oct 2018 16:04:09 +0200
+
 sysvinit (2.88dsf-59.10) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru sysvinit-2.88dsf/debian/init-d-script 
sysvinit-2.88dsf/debian/init-d-script
--- sysvinit-2.88dsf/debian/init-d-script   2017-02-12 22:55:39.0 
+0100
+++ sysvinit-2.88dsf/debian/init-d-script   2018-10-07 16:04:01.0 
+0200
@@ -1,6 +1,11 @@
 #!/bin/sh
 # See init-d-script(5) for instructions on how to use this library.
 #=
+
+# Shift arguments early to fix #826214
+__init_d_script_name="$1"
+shift
+
 # Define LSB log_* functions.
 # Depend on lsb-base (>= 3.2-14) to ensure that this file is present
 # and status_of_proc is working.
@@ -153,12 +158,10 @@
 set -x
 fi
 
-SCRIPTNAME=$1
-scriptbasename="$(basename $1)"
+SCRIPTNAME="$__init_d_script_name"
+scriptbasename="$(basename "$__init_d_script_name")"
 if [ "$scriptbasename" != "init-d-script" ] ; then
-script="$1"
-shift
-. $script
+. "$__init_d_script_name"
 else
 exit 0
 fi


signature.asc
Description: OpenPGP digital signature

Bug#910511: [Pkg-utopia-maintainers] Bug#910511: network-manager-openvpn: openvpn 2.4 in stable supports tls-crypt, but nm-openvpn 1.2.8 in stable doesn't

[Michael Biebl]

Am 07.10.18 um 15:55 schrieb Gijs Molenaar:
> Package: network-manager-openvpn
> Version: 1.2.8-2
> Severity: important
> 
> Dear Maintainer,
> 
> I'm developing a UI wrapper around various platforms for an open VPN service.
> Debian 9 is one of our targetted platforms. We have tls-crypt enabled for our
> service, which works on Debian 9 since it is bundeled with openVPN 2.4.0. The
> problem is the network-manager-openvpn package, which doesn't seem to have
> support for this setting. This is a bit of a pitty, since technically it 
> should
> work. The limitation becomes apparant when you for example import a .ovpn file
> in the UI with a tls-crypt statement in it. The import will fail.
> 
> It looks like network-manager-openvpn > 1.2.10 actually has support for the
> tls-crypt statement.
> 
> Now i'm not sure if this is the right spot to request such a thing, but is it
> somehow possible to get network-manager-openvpn > 1.2.10 into stable? 
> Important
> security features are now not available to stable users, while technically it
> is supported.

stable updates are supposed to fix security issues or grave bugs and not
add new features or add new upstream versions.

That said, 1.2.10 could be provided via stretch-backports:
https://backports.debian.org/

Would this suffice for you?



-- 
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#910276: mksh does never execute an "EXIT trap", if it is created with the "trap" command in a sub shell

[bernd]

Thank you,

your last mail helped, I think now I understand and I am happy that  
you will try to change mksh and I will try to support mksh, with my  
library.


bye,
Bernd







bin4CuTKWedLy.bin
Description: Öffentlicher PGP-Schlüssel

Bug#910512: pulseaudio: Pulseaudio takes longer to start than default systemd timeout

[Riaas Mokiem]

Package: pulseaudio
Version: 12.2-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Pulseaudio is taking longer to start up than the default 90 seconds that 
systemd allows for a service. This means that Pulseaudio does not work on 
startup and no matter how much you try to restart it (through systemd), 
it won't start up correctly. 

Not sure if this is the cause, but this happened after a recent upgrade that 
removed consolekit and upgraded the linux kernel from 4.18.0-1 to 4.18.0-2
I changed the timeout of pulseaudio.service to 5 minutes which allowed
Pulseaudio sufficient time to start up correctly. 

I have pretty decent hardware though, so I would have expected the default
timeout for Pulseaudio to be more than sufficient. It has been sufficient 
on this hardware until now. I'm not sure what's relevant for Pulseaudio, but
my system uses the motherboard's onboard sound chip (Realtek ALC S1220A) on
an AMD Ryzen system.

I'm not sure why Pulseaudio is suddenly taking so much longer to start (or maybe
systemd shortened the default timeout). But it's worth noting that for some 
reason I still had HDMI audio output, even with pulseaudio timed out. This is
something that actually hadn't worked before and I haven't really tested it
since the kernel with amdgpu dc has been available. Not sure if that's relevant.


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 4.18.0-2-amd64 (SMP w/16 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 (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)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  libasound2   1.1.6-1
ii  libasound2-plugins   1.1.6-1+b1
ii  libc62.27-6
ii  libcap2  1:2.25-1.2
ii  libdbus-1-3  1.12.10-1
ii  libgcc1  1:8.2.0-7
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-4
ii  liborc-0.4-0 1:0.4.28-3
ii  libpulse012.2-2
ii  libsm6   2:1.2.2-1+b3
ii  libsndfile1  1.0.28-4
ii  libsoxr0 0.1.2-3
ii  libspeexdsp1 1.2~rc1.2-1+b2
ii  libstdc++6   8.2.0-7
ii  libsystemd0  239-10
ii  libtdb1  1.3.16-1
ii  libudev1 239-10
ii  libwebrtc-audio-processing1  0.3-1
ii  libx11-6 2:1.6.6-1
ii  libx11-xcb1  2:1.6.6-1
ii  libxcb1  1.13-3
ii  libxtst6 2:1.2.3-1
ii  lsb-base 9.20170808
ii  pulseaudio-utils 12.2-2

Versions of packages pulseaudio recommends:
ii  dbus-user-session  1.12.10-1
ii  libpam-systemd 239-10
ii  rtkit  0.11-6

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  3.0-4
pn  pavumeter
ii  udev 239-10

-- Configuration Files:
/etc/pulse/daemon.conf changed:
; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no
; high-priority = yes
; nice-level = -11
; realtime-scheduling = yes
; realtime-priority = 5
; exit-idle-time = 20
; scache-idle-time = 20
; dl-search-path = (depends on architecture)
; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa
; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0
; resample-method = speex-float-1
; avoid-resampling = false
; enable-remixing = yes
; remixing-use-all-sink-channels = yes
enable-lfe-remixing = yes
lfe-crossover-freq = 120
flat-volumes = no
; rlimit-fsize = -1
; rlimit-data = -1
; rlimit-stack = -1
; rlimit-core = -1
; rlimit-as = -1
; rlimit-rss = -1
; rlimit-nproc = -1
; rlimit-nofile = 256
; rlimit-memlock = -1
; rlimit-locks = -1
; rlimit-sigpending = -1
; rlimit-msgqueue = -1
; rlimit-nice = 31
; rlimit-rtprio = 9
; rlimit-rttime = 20
; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000
default-sample-channels = 6
; default-channel-map = front-left,front-right
; default-fragments = 4
; default-fragment-size-msec = 25
; enable-deferred-volume = yes
; deferred-volume-safety-margin-usec = 8000
; deferred-volume-extra-delay-usec = 0


-- no debconf information
# This file i

Bug#910511: [Pkg-utopia-maintainers] Bug#910511: network-manager-openvpn: openvpn 2.4 in stable supports tls-crypt, but nm-openvpn 1.2.8 in stable doesn't

[Michael Biebl]

Am 07.10.18 um 16:15 schrieb Michael Biebl:
> That said, 1.2.10 could be provided via stretch-backports:
> https://backports.debian.org/

Fwiw, if we go the stretch-backports route, then it would probably make
sense to use the current version from testing, i.e. 1.8.4-1


-- 
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#910458: gnome-user-docs FTBFS: 'NoneType' object has no attribute '__getitem__'

[Jeremy Bicha]

Control: forwarded -1 https://github.com/itstool/itstool/issues/17
Control: severity -1 grave

On Sun, Oct 7, 2018 at 5:10 AM Adrian Bunk  wrote:
> After some testing the new itstool turns out to be the culprit.

Fedora cherry-picked a patch but I could still reproduce the bug after
applying it. (Note that the bug doesn't happen every time for me.) [1]

It looks like Arch reverted back to 2.0.2 instead. [2]

The forwarded bug suggests there is also a libxml2 bug that may still
be unfixed. The easiest way forward may be to revert to 2.0.2 or at
least revert the commits that changed itstool's behavior.

[1] https://github.com/itstool/itstool/commit/9b84c007a7
[2] https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/itstool

Thanks,
Jeremy Bicha

Bug#910514: ITP: r-cran-irace -- GNU R iterated racing for automatic algorithm configuration

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-irace
  Version : 3.1
  Upstream Author : Manuel López-Ibáñez
* URL : https://cran.r-project.org/package=irace
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R iterated racing for automatic algorithm configuration
 Iterated race is an extension of the Iterated F-race method for
 the automatic configuration of optimization algorithms, that is,
 (offline) tuning their parameters by finding the most appropriate
 settings given a set of instances of an optimization problem.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-irace

Bug#910513: cmake: Please increase timeout of tests for arch riscv64

[Manuel A. Fernandez Montecelo]

Source: cmake
Version: 3.12.1-1.1
Severity: normal
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

This package fails to build due to the timeout limit of the tests, and since
it's a very important package, we have to compile it by hand every time with
each upload, to include in the "unreleased" suite.

Some versions in the past compiled sucessfully, but I suppose that a combination
of the addition of some tests or the recent changes that decrease performance in
x86_64 play a role in this, since the buildds are running at the moment with
qemu-system.

Several tests take around and slightly over 2000 that it's the current limit.
One of them takes 3500.  But just to avoid having similar problems in the near
future, I think that it's safest to increase to 5000, to not have to modify
again in the near future.

So please consider to include this simple patch that I attach, or an equivalent
only for riscv64 if you don't want to increase the limit for other arches.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru cmake-3.12.1/debian/changelog cmake-3.12.1/debian/changelog
--- cmake-3.12.1/debian/changelog   2018-09-27 17:50:12.0 +0200
+++ cmake-3.12.1/debian/changelog   2018-10-06 15:51:48.0 +0200
@@ -1,3 +1,11 @@
+cmake (3.12.1-1.1+0.riscv64.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * riscv64: increase timeout of tests for compilation in the qemu-system
+buildds, from 2000 to 5000
+
+ -- Manuel A. Fernandez Montecelo   Sat, 06 Oct 2018 15:51:48 
+0200
+
 cmake (3.12.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cmake-3.12.1/debian/rules cmake-3.12.1/debian/rules
--- cmake-3.12.1/debian/rules   2018-05-19 10:51:17.0 +0200
+++ cmake-3.12.1/debian/rules   2018-10-06 15:51:48.0 +0200
@@ -52,7 +52,7 @@
 override_dh_auto_test:
# Pass -j1 to "make test" as a workaround, see 
https://gitlab.kitware.com/cmake/cmake/issues/17165
# The tests are still run in parallel as debhelper pass -jX as ARGS to 
ctest.
-   dh_auto_test --buildsystem=cmake -- -j1 ARGS="-E CTestTestUpload 
--timeout 2000"
+   dh_auto_test --buildsystem=cmake -- -j1 ARGS="-E CTestTestUpload 
--timeout 5000"
 
 override_dh_auto_clean:
dh_auto_clean

Bug#910376: mat2: Incomplete debian/copyright?

[Georg Faerber]

Hi all,

On 18-10-07 16:00:06, intrigeri wrote:
> Georg Faerber:
> > Currently, we don't ship the logo, but I'm unsure if this matters?
> 
> We do ship the logo in the source package so it does matter :)

Alright -- I'll fix this once the current state is clarified upstream,
see the corresponding issue over there.

Cheers,
Georg


signature.asc
Description: Digital signature

Bug#910515: ITP: r-cran-paramhelpers -- GNU R helpers for parameters in black-box optimization and tuning

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-paramhelpers
  Version : 1.11
  Upstream Author : Bernd Bischl,
* URL : https://cran.r-project.org/package=ParamHelpers
* License : BSD-2-clause
  Programming Lang: GNU R
  Description : GNU R helpers for parameters in black-box optimization and 
tuning
 Functions for parameter descriptions and operations in black-box
 optimization, tuning and machine learning. Parameters can be described
 (type, constraints, defaults, etc.), combined to parameter sets and can in
 general be programmed on. A useful OptPath object (archive) to log function
 evaluations is also provided.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-paramhelpers

Bug#898705: [Android-tools-devel] Bug#898705: android-platform-libcore 8.1 upload to unstable?

[tony mancill]

On Sun, Oct 07, 2018 at 05:38:21PM +0800, 殷啟聰 | Kai-Chung Yan wrote:
> I am going to upload the Oreo version of src:android-platform-libcore to 
> `unstable` on 9 October if no one objects.
> 
> The Oreo (8.x) of this package only builds `android-platform-libcore-headers` 
> and `libandroid-json-java` so the majority of the SDK don't really rely on 
> this source package any more. Besides, the majority of the SDK is already 
> removed from `testing`...
> 

Much appreciated!  Java JSON libraries is a bit of a hassle in Debian
due to the json.org "JSON license" being non-DFSG, which is how
libandroid-json-java came be used outside of the Android toolchain.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#910516: ITP: r-cran-mlr -- Machine learning in GNU R

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-mlr
  Version : 2.13
  Upstream Author : Bernd Bischl,
* URL : https://cran.r-project.org/package=mlr
* License : BSD-2-clause
  Programming Lang: GNU R
  Description : Machine learning in GNU R
 Interface to a large number of classification and regression
 techniques, including machine-readable parameter descriptions. There is
 also an experimental extension for survival analysis, clustering and
 general, example-specific cost-sensitive learning. Generic resampling,
 including cross-validation, bootstrapping and subsampling. Hyperparameter
 tuning with modern optimization techniques, for single- and multi-objective
 problems. Filter and wrapper methods for feature selection. Extension of
 basic learners with additional operations common in machine learning, also
 allowing for easy nested resampling. Most operations can be parallelized.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-mlr

Bug#910506: split package into architecture dependent and independent ones

[Boris Pek]

Hi Martin,

> Currently only one, architecture dependent package is created.
> However, most of prosody consists of architecture independent files.
>
> I like to separate the few .so files into prosody-lib to save some
> space on the archive.
>
> Any objections?

Yes, I have ones.

At first let's look at package size:
https://packages.debian.org/experimental/prosody
It is about 282.4 KB. And this is very small size.

Next, let's remember that each separate package increases size of list
of packages in Debian archive:
https://cdn-aws.deb.debian.org/debian/dists/unstable/main/
which will be downloaded by all Debian users even is they do not use
this package.

And the last but not least: as far as I know there are no other programs
which will use this library, even in perspective.

Thus you offer to increase complexity of source package (split on few
packages with declaration of relationships between them), possibly
increase work of ftp-masters (think about changing of SOVERSIONs in the
future, etc.) and increase of size of lists of packages just for
decreasing size of binary packages to about tens of kilobytes?

I would suggest you to reconsider all pros and cons of this decision.

Best regards,
Boris

Bug#910517: monero: FTBFS on i386: compiler runs our of memory

[Emilio Pozuelo Monfort]

Source: monero
Version: 0.12.3.0~dfsg-2
Severity: serious

Your package failed to build on i386:

cd "/<>/obj-i686-linux-gnu/contrib/epee/src" && /usr/bin/c++  
-DAUTO_INITIALIZE_EASYLOGGINGPP -DBLOCKCHAIN_DB=DB_LMDB 
-DDEFAULT_DB_TYPE=\"lmdb\" -DHAVE_EXPLICIT_BZERO -DHAVE_PCSC -DHAVE_READLINE 
-DHAVE_STRPTIME -DPER_BLOCK_CHECKPOINT 
-I"/<>/external/rapidjson/include" 
-I"/<>/external/easylogging++" -I"/<>/src" 
-I"/<>/contrib/epee/include" -I"/<>/external" 
-I"/<>/obj-i686-linux-gnu/translations" 
-I"/<>/external/db_drivers/liblmdb" -I/usr/include/PCSC  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-strict-aliasing 
-DNO_AES -std=c++11 -D_GNU_SOURCE   -Wall -Wextra -Wpointer-arith -Wundef -Wvla 
-Wwrite-strings -Wno-error=extra -Wno-error=deprecated-declarations 
-Wno-unused-parameter -Wno-unused-variable -Wno-error=unused-variable 
-Wno-error=undef -Wno-error=uninitialized -Wlogical-op 
-Wno-error=maybe-uninitialized -Wno-error=cpp -Wno-reorder 
-Wno-missing-field-initializers   -fPIC  -Wformat -Wformat-security 
-fstack-protector -fstack-protector-strong -fno-strict-aliasing   -Werror -o 
CMakeFiles/epee.dir/network_throttle.cpp.o -c 
"/<>/contrib/epee/src/network_throttle.cpp"

cc1plus: out of memory allocating 27008520 bytes after a total of 83218432 bytes
make[3]: *** [src/mnemonics/CMakeFiles/obj_mnemonics.dir/build.make:66: 
src/mnemonics/CMakeFiles/obj_mnemonics.dir/electrum-words.cpp.o] Error 1
make[3]: Leaving directory '/<>/obj-i686-linux-gnu'

Full logs at https://buildd.debian.org/status/package.php?p=monero

Emilio

Bug#871502: zotero-standalone-build: The newer Zotero is standalone only ; a reorganization is neded.

[Sébastien Villemot]

Le vendredi 05 octobre 2018 à 12:55 +0200, Félix Sipma a écrit :
> On 2018-10-02 05:50+, Trout, Diane E. wrote:
> > I was at least going to try and commit the work I did and stick on
> > salsa, but I've been busy the past couple of days. I'll try to get it
> > done in by the weekend.
> > 
> > There's some javascript packages that are needed, that aren't packaged.
> > 
> > What I had so far can only build outside of a chroot when npm can
> > download packages.
> > 
> > Would anyone be willing to help package some javascript dependencies?
> > 
> > If my d/control file is right Debian is missing these:
> > 
> > #  node-babel-plugin-transform-es2015-modules-commonjs,
> > #   node-browserify,
> > #  node-chai,
> > #  node-chai-as-promised,
> > #  node-co-mocha,
> > #  node-eslint-plugin-react,
> > #  node-mocha,
> > #  node-node-sass,
> 
> I'm not sure about the others, but at least for node-browserify, it seems like
> a pretty big one. To be honest with myself, I don't think I'll have the time 
> to
> learn how to package javascript packages and do some of the actual work before
> the freeze.
> 
> Is the possibility of bundling those dependencies still available?

Yes, even though this is not the preferred Debian way, it is possible
to do this.

> I just tried the flatpak solution proposed, and I have to admit it just worked
> great...

Same for me.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


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

Bug#908235: O: wnpp - Work-Needing and Prospective Packages

[Cédric Barboiron]

Hi,

September 7, 2018 6:42 PM, "Sebastian Tobie"  
wrote:

> Package: eggdrop
> Severity: normal
> 
> since 2011 the package eggdrop was not updated and bugs were not fixed. 2016 
> the upstream developer
> released a new minor Version where many issues which where reported to Debian 
> were fixed.

The package has been updated and reworked in 2014, with the latest and final 
1.6.x release: 1.6.21 (included in jessie).

The 1.8.x series was still in beta for etch's freeze, but an updated version 
(1.8.3 currently) has been available here: 
https://mentors.debian.net/package/eggdrop . I will definitely seek a mentor to 
upload it when the buster's freeze will approach.

If anyone with upload rights wants to adopt this package for faster updates, 
I'm totally open to the idea.

Regards
-- 
Cédric

Bug#904558: What should happen when maintscripts fail to restart a service

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

Simon> the error path is most important were packages that provide a
Simon> system-level API to other packages, so their failures are
Simon> likely to cause other packages to fail to configure (such as
Simon> local DNS caches and authentication services like LDAP); and
Simon> packages that provide remote access, so their failures need
Simon> to be fixed before a potentially remote sysadmin logs out to
Simon> prevent the sysadmin from being locked out longer-term (like
Simon> sshd).

As a maintainer of one of the more important packages (krb5-kdc and
krb5-admin-server), ;I'd like to chime in here.  krb5-kdc provides
enterprise level authentication and if it fails may well take out
authentication for an entire environment.

Even so,  I've found that causing upgrades to fail does far more harm
than good even for this package.

Here is my experience based on my own observations and based on bug
reports and helping people diagnose problems in krb5:

* The vast majority of failures are when krb5-kdc gets installed on a
  system where it is not actually needed, or where it was partially
  configured for  a test.  In these cases, breaking an kupgrade does
  much more harm than good.  It may break other services, because those
  services may end up in a half-configured state, so a service that is
  not critical for a given system may break critical services for that
  system.

* When krb5 is a critical service, it's failure is going to be quite
  obvious regardless of whatever the maint script does.

* It is almost always the case that debugging  the situation involves
  installing some package and that  the first thing I end up doing is
  walking a user through adding exit 0 at the top of postinst in
  /var/lib/dpkg/info before going forward.  Even if  I don't need some
  additional tool, I've been burned by other parts of the system being
  in half-configured state.

* Leaving large chunks of the system in half-configured states is about
  one of the worst things you can do for system stability.  It's not
  something we test very often, and the interactions are very difficult
  to predict.

If I understood the cause of an error in a maintainer script and knew
that it indicated a problem that the sysadmin needed to fix (and one
that likely indicated krb5 was important on this system) I would be open
to returning a failure in postinst.
In almost all other situations I'd rather simply let the service fail to
start.


signature.asc
Description: PGP signature

Bug#910511: [Pkg-utopia-maintainers] Bug#910511: network-manager-openvpn: openvpn 2.4 in stable supports tls-crypt, but nm-openvpn 1.2.8 in stable doesn't

[Gijs Molenaar]

Hi Michael,


Op zo 7 okt. 2018 om 16:36 schreef Michael Biebl :

> Am 07.10.18 um 16:15 schrieb Michael Biebl:
> > That said, 1.2.10 could be provided via stretch-backports:
> > https://backports.debian.org/
>
> Fwiw, if we go the stretch-backports route, then it would probably make
> sense to use the current version from testing, i.e. 1.8.4-1
>
>
Having a backport would already help a lot, so yes please! And yes, any
version greater than 1.2.10 is enough for us but it probably makes sense to
use the latest testing.

greetings,

 - Gijs

Bug#893486: reproduced with new ghc

[Joey Hess]

Now that ghc 8.4.3 is installed, this happens for me too.
I have deleted ~/.ghc ~/.cabal, and dist. Happens in all
packages I've tried to build.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#910517: monero: FTBFS on i386: compiler runs our of memory

[Holger Levsen]

On Sun, Oct 07, 2018 at 05:19:53PM +0200, Emilio Pozuelo Monfort wrote:
> Your package failed to build on i386:
 
there's also Bug#909422: RM: monero [i386] -- ANAIS; buildd OOMs during build


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#910518: hamfax: hang on dsp-rx after the transmission is completed or cancelled.

[Enrico Rossi]

Package: hamfax
Version: 0.8.1-1+b1
Severity: important

Dear Maintainer,

after start receiving via DSP everything looks normal, but if I click
cancel to stop the RX or the transmission ends normally, hamfax hang
without giving any error.
The system is using pulseaudio.

Thanks
E.

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

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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)
LSM: AppArmor: enabled

Versions of packages hamfax depends on:
ii  libasound2 1.1.6-1
ii  libaudiofile1  0.3.6-4
ii  libc6  2.27-6
ii  libgcc11:8.2.0-7
ii  libhamlib2 3.2-3
ii  libqtcore4 4:4.8.7+dfsg-17
ii  libqtgui4  4:4.8.7+dfsg-17
ii  libstdc++6 8.2.0-7

hamfax recommends no packages.

hamfax suggests no packages.

-- no debconf information

-- 
GPG key: 4096R/5E0195FAF2133176 2010-10-19 Enrico Rossi 

Bug#910519: xane: Please Build-Depend on libjpeg-dev

[Jeremy Bicha]

Source: xsane
Version: 0.999-6

Please Build-Depend on libjpeg-dev instead of libjpeg62-turbo-dev.
This would allow Ubuntu to sync xsane directly from Debian since
Ubuntu doesn't have libjpeg62-turbo-dev.

Debian has 380 packages that build-depnd on libjpeg-dev and only 2
that build-depend on libjpeg62-turbo-dev directly. (The other one is
xwallpaper and I'll submit a bug for that now too.)

Thanks,
Jeremy Bicha

Bug#893486: Info received (reproduced with new ghc)

[Joey Hess]

https://github.com/haskell/cabal/issues/5548

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#910520: xwallpaper: Please Build-Depend on libjpeg-dev

[Jeremy Bicha]

Source: xwallpaper
Version: 0.3.0-2

xwallpaper is unbuildable on Ubuntu [1] because libjpeg62-turbo-dev is
not available there. Please build-depend on libjpeg-dev instead. Note
that Ubuntu's libjpeg-dev did not have its epoch bumped so I suggest
dropping the version requirement.

Debian has 380 packages that Build-Depend on libjpeg-dev. There are
only 2 that Build-Depend on libjpeg62-turbo-dev directly: the other
one is xsane and I filed a bug for that too.

[1] https://launchpad.net/ubuntu/+source/xwallpaper/0.3.0-2/+build/14986703

Thanks,
Jeremy Bicha

Bug#903312: innoextract: bad chunk magic: iostream error on armhf

[Phil Morrell]

Hi, please apply the upstream patch to fix this issue in 1.7-1.
From 932e5fd87e559e07e7264ba9d59b01ec353319b3 Mon Sep 17 00:00:00 2001
From: Daniel Scharrer 
Date: Sat, 8 Sep 2018 01:52:18 +0200
Subject: [PATCH] slice: Fix support for slices larger than 2 GiB in 32-bit
 builds

Fixes: issue #68
---
 CHANGELOG| 5 +
 src/stream/slice.cpp | 8 +---
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/CHANGELOG b/CHANGELOG
index 20d27f0..ea9faac 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,4 +1,9 @@
 
+innoextract 1.8 (WIP)
+ - Added support for installers using an alternative setup loader magic
+ - Added support for using boost_{zlib,bzip2} when statically linking Boost
+ - Fixed extracting files from slices larger than 2 GiB with 32-bit builds
+
 innoextract 1.7 (2018-06-12)
  - Added support for Inno Setup 5.6.0 installers
  - Added support for new GOG installers with GOG Galaxy file parts
diff --git a/src/stream/slice.cpp b/src/stream/slice.cpp
index c4b3372..4ed2637 100644
--- a/src/stream/slice.cpp
+++ b/src/stream/slice.cpp
@@ -231,17 +231,19 @@ std::streamsize slice_reader::read(char * buffer, std::streamsize bytes) {
 		if(read_pos > slice_size) {
 			break;
 		}
-		std::streamsize remaining = std::streamsize(slice_size - read_pos);
+		boost::uint32_t remaining = slice_size - read_pos;
 		if(!remaining) {
 			seek(current_slice + 1);
 			read_pos = boost::uint32_t(is->tellg());
 			if(read_pos > slice_size) {
 break;
 			}
-			remaining = std::streamsize(slice_size - read_pos);
+			remaining = slice_size - read_pos;
 		}
 		
-		if(is->read(buffer, std::min(remaining, bytes)).fail()) {
+		boost::uint64_t toread = std::min(boost::uint64_t(remaining), boost::uint64_t(bytes));
+		toread = std::min(toread, boost::uint64_t(std::numeric_limits::max()));
+		if(is->read(buffer, std::streamsize(toread)).fail()) {
 			break;
 		}
 		


signature.asc
Description: PGP signature

Bug#910521: libkernlib1-gfortran: a call of a small fortran program linked with this library throws a bug like in bug-report 855929

[Michael v. Hartrott]

Package: libkernlib1-gfortran
Severity: normal

Dear Maintainer,

This small fortran program (named bug_test.for):
  PROGRAM bug_test
  CALL MZPAW(2,' ')
  END
compiled by 'gfortran -o bug_test -no-pie -lkernlib -lpacklib -lgraflib 
-lgrafX11 -lX11 bug_test.for'
and than runnig it by './bug_test' shows this error:

LOCB/LOCF: address 0x7f2f4e4e5fc8 exceeds the 32 bit address space
or is not in the data segments
This may result in program crash or incorrect results
Therefore we will stop here



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

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

Bug#910495: openjfx FTBFS on !x86: offlineasm: No magic values found. Skipping assembly file generation.

[Markus Koschany]

The patch contained a mistake but I just tried it on plummer.debian.org
(ppc64el porterbox) and it unfortunately doesn't make any difference.



signature.asc
Description: OpenPGP digital signature

Bug#910495: openjfx FTBFS on !x86: offlineasm: No magic values found. Skipping assembly file generation.

[Markus Koschany]

Am 07.10.18 um 18:21 schrieb Markus Koschany:
> The patch contained a mistake but I just tried it on plummer.debian.org
> (ppc64el porterbox) and it unfortunately doesn't make any difference.

I should have added that I still think it has something to do with the
disabled JIT. The aforementioned chromium patch mentions that


"The magic values are no longer present
when the JIT is disabled."




signature.asc
Description: OpenPGP digital signature

Bug#780433: Intent to NMU qpsmtpd to fix longstanding l10n bugs

[Helge Kreutzmann]

Hello Devin,
I intend to NMU qpsmtpd in November to fix longstanding l10n
bugs[1]. The changelog would be something like the following:

  * Non-maintainer upload.
  * Obvious lintian fixes:
-init.d-script-needs-depends-on-lsb-base
-priority-extra-is-replaced-by-priority-optional
  * Add Debconf translations:
-nl from Frans Spiesschaert (Closes: #766628)
-fr from Steve Petruzzello (Closes: #780433)
-da from Joe Dalton (Closes: #781340)
-de from Helge Kreutzmann (Closes: #815699)
-ja from Takuma Yamada (Closes: #819024)
-pt from Tiago Fernandes (Closes: #859946, #872982)

Please tell me if you are currently preparing a new release yourself
and would like me to skip the NMU.

Greetings

 Helge

[1] https://i18n.debian.org/nmu-radar/nmu_bypackage.html

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#894260: ITP: ghostwriter

[Sebastien CHAVAUX]

Ghost Good evening,

So I recommended the steps for Ghostwriter software under Debian, it is 
available on debian.Mentor https://mentors.debian.net/package/ghostwriter.


I also sent this message on bugs.debian.org:



 Package: sponsorship-requests

  Severity: normal [important for RC bugs, wishlist for new packages]

  Dear mentors,

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

 * Package name: ghostwriter
   Version : 1.7.3-1
   Upstream Author :wereturtle 

 * URL :http://wereturtle.github.io/ghostwriter/
 * License : GPLv3
   Section : editors

  It builds those binary packages:

ghostwriter - Distraction-free, themeable Markdown editor

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

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


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

dget 
-xhttps://mentors.debian.net/debian/pool/main/g/ghostwriter/ghostwriter_1.7.3-1.dsc

  More information about ghostwriter
 can be obtained fromhttp://wereturtle.github.io/ghostwriter/.

  Changes since the last upload:

  - Update to version 1.7.3:
  * Fixed segfault that occurred when changing the theme or interface style 
after opening the Preview Options dialog


  Regards,
   Sebastien CHAVAUX

cordially

Le 07/10/2018 à 11:41, ghost a écrit :

English is not my first language.

Same here, I know how it feels :->


I am still interested in this package but I admit I am not strong enough
to understand all the steps to propose the package site.

There are basically 2 ways when we don't know a specific mentor who can
help to upload the package:
1. toggle the "need a sponsor" setting at mentors.d.n once you uploaded
the package, so that it's listed on the main page.
2. send a Request for Sponsor to sponsorship-requests the same way you
sent this ITP to wnpp.

However, since there has been new upstream releases, we need to get the
new version into a good shape for upload. Let me know if there is
anything I can help.

Cheers

Bug#910524: r-cran-emoa: Incomplete debian/copyright?

[Chris Lamb]

Source: r-cran-emoa
Version: 0.5-0-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Andreas Tille , ftpmas...@debian.org

Hi,

I just ACCEPTed r-cran-emoa from NEW but noticed it was missing 
attribution in debian/copyright for at least Mike Buselli and Wessel
Dankers.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#910523: r-cran-eaf: Incomplete debian/copyright?

[Chris Lamb]

Source: r-cran-eaf
Version: 1.8-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Andreas Tille , ftpmas...@debian.org

Hi,

I just ACCEPTed r-cran-eaf from NEW but noticed it was missing 
attribution in debian/copyright for at least Wessel Dankers, Mike
Buselli, etc.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#910522: r-cran-pracma: Incomplete debian/copyright?

[Chris Lamb]

Source: r-cran-pracma
Version: 2.1.5-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Oliver Dechant , ftpmas...@debian.org

Hi,

I just ACCEPTed r-cran-pracma from NEW but noticed it was missing 
attribution in debian/copyright for at least Jonas Lundgren, Greg
von Winckel, Paul Godfrey, etc.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#894260: RFS: ghostwriter/1.7.3-1 [ITP]

[Sebastien CHAVAUX]

  Package: sponsorship-requests
  Severity: normal [important for RC bugs, wishlist for new packages]

  Dear mentors,

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

 * Package name: ghostwriter
   Version : 1.7.3-1
   Upstream Author :wereturtle 

 * URL :http://wereturtle.github.io/ghostwriter/
 * License : GPLv3
   Section : editors

  It builds those binary packages:

ghostwriter - Distraction-free, themeable Markdown editor

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

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


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

dget 
-xhttps://mentors.debian.net/debian/pool/main/g/ghostwriter/ghostwriter_1.7.3-1.dsc

  More information about ghostwriter
 can be obtained fromhttp://wereturtle.github.io/ghostwriter/.

  Changes since the last upload:

  - Update to version 1.7.3:
  * Fixed segfault that occurred when changing the theme or interface style 
after opening the Preview Options dialog


  Regards,
   Sebastien CHAVAUX

Bug#910525: courier-webadmin is dependent on CGI.pm

[Jean Louis]

Package: courier-webadmin
Version: 0.76.3-5
Severity: important

Dear Maintainer,

   * What led up to the situation?

courier-webadmin will not work if CGI.pm is not installed.




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

Kernel: Linux 4.9.0-7-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 courier-webadmin depends on:
ii  apache2 [httpd]2.4.25-3+deb9u5
ii  courier-base   0.76.3-5
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u3

courier-webadmin recommends no packages.

Versions of packages courier-webadmin suggests:
pn  courier-doc  

-- debconf information:
* courier-webadmin/install-cgi: true

Bug#910526: dkms_autoinstaller fails if run with zsh in sh compatibility mode

[Tino Calancha]

Package: dkms
Version: 2.3-2
Severity: important
Tags: patch upstream

Dear Maintainer,

When the system '/bin/sh' points to zsh shell, dkms_autoinstaller is run
with zsh in sh compatibility mode; this requires functions end
Fix syntactic error when the system shell is zsh

When the system '/bin/sh' points to the zsh shell,
then the script is run with zsh in sh compatibility mode; in that case
functions must end with either a semicolon or a newline.
(https://github.com/dell/dkms/issues/62)
* dkms_autoinstaller (log_end_msg):
Terminate the function with a semicolon.
Add missing white space in comment.

with either a semicolon or a newline.
In that case, this script fails with a parse error in function log_end_msg.

Bug reported upstream here:
--8<-cut here---start->8---
commit 9b44ee67e4a7fc4a215561c8a788a7ea66544ffb
diff --git a/dkms_autoinstaller b/dkms_autoinstaller
index 0e7f070..7fbe8f3 100755
--- a/dkms_autoinstaller
+++ b/dkms_autoinstaller
@@ -22,11 +22,11 @@ elif [ -f /etc/rc.d/init.d/functions ]; then
 . /etc/rc.d/init.d/functions
 fi
 
-#We only have these functions on debian/ubuntu
+# We only have these functions on debian/ubuntu
 # so on other distros just stub them out
 if [ ! -f /etc/debian_version ]; then
 alias log_daemon_msg=/bin/echo
-log_end_msg() { if [ "$1" = "0" ]; then echo " Done. "; else echo " 
Failed. "; fi }
+log_end_msg() { if [ "$1" = "0" ]; then echo " Done. "; else echo " 
Failed. "; fi; }
 alias log_action_begin_msg=log_daemon_msg
 alias log_action_end_msg=log_end_msg
 fi

--8<-cut here---end--->8---


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

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

Versions of packages dkms depends on:
ii  build-essential  12.3
ii  coreutils8.26-3
ii  dpkg-dev 1.18.25
ii  gcc  4:6.3.0-4
ii  kmod 23-2
ii  make 4.1-9.1
ii  patch2.7.5-1+deb9u1

Versions of packages dkms recommends:
ii  fakeroot 1.21-3.1
ii  linux-headers-amd64  4.9+80+deb9u6
ii  lsb-release  9.20161125
ii  sudo 1.8.19p1-2.1

Versions of packages dkms suggests:
pn  menu
pn  python3-apport  

-- no debconf information

Bug#909119: stretch-pu: package vagrant/1.9.1+dfsg-1+deb9u1

[Antonio Terceiro]

On Sat, Oct 06, 2018 at 05:50:33PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2018-09-18 at 10:22 -0700, Antonio Terceiro wrote:
> > vagrant from stretch currently refuses to work with VirtualBox 5.2
> > from
> > stretch-backports. This update just backports the few changes needed
> > to
> > make it work. The changes are pretty trivial.
> > 
> > VirtualBox is not in stretch, so users are getting it either from
> > stretch-backports or from upstream's .deb package; without this
> > update
> > vagrant will most likely be broken for most VirtualBox users. It
> > would
> > be nice if we can release this update.
> > 
> 
> Please go ahead.

Just uploaded, thanks.


signature.asc
Description: PGP signature

Bug#910527: courier-webadmin, password file with wrong permissions

[Jean Louis]

Package: courier-webadmin
Version: 0.76.3-5
Severity: important

Dear Maintainer,

   * What led up to the situation?

After installation the password file is installed with wrong permissions:

1) It is group readable, courierwebadmin script fails to use such, it has to be 
only owner/group readable

2) It has permission root:courier, but it should be courier:courier

Then it works.


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

Kernel: Linux 4.9.0-7-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 courier-webadmin depends on:
ii  apache2 [httpd]2.4.25-3+deb9u5
ii  courier-base   0.76.3-5
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u3

courier-webadmin recommends no packages.

Versions of packages courier-webadmin suggests:
pn  courier-doc  

-- debconf information:
* courier-webadmin/install-cgi: true

Bug#910528: gmime: unneeded configure flag arguments

[Jeremy Bicha]

Source: gmime
Version: 3.2.0-2
Severity: minor

I looked at the debian/rules for gmime and I think there are 2
unnecessary lines:

Shouldn't this be the default for dh_auto_configure already?
$(shell dpkg-buildflags --export=configure) \

Nothing sets this variable now:
$(CONFIGURE_MONO_FLAGS)

Thanks,
Jeremy Bicha

Bug#909941: rabbitmq-server: Fails to start

[Paul Gevers]

user debian...@lists.debian.org
usertags 909941 regression
affects 909941 src:debci
thanks

On Sun, 30 Sep 2018 12:54:10 +0100 Jose Antonio Ortega Ruiz
 wrote:
> This version of the server fails to start using systemd:

Yes, but until recently it worked. So this is a regression caused by
some other package.

Also the autopkgtest of debci in unstable [1] is showing this since
2018-09-27. I'll try to figure out which package update caused this and
reassign. I'm suspecting one of the erlang packages.

Paul

[1] https://ci.debian.net/packages/d/debci/unstable/amd64/



signature.asc
Description: OpenPGP digital signature

Bug#910529: courier-webadmin: wrong permissions in /etc/courier/webadmin

[Jean Louis]

Package: courier-webadmin
Version: 0.76.3-5
Severity: important

Dear Maintainer,

All permissions shall be courier:courier for /etc/courier/webadmin

Otherwise settings don't work.

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

Kernel: Linux 4.9.0-7-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 courier-webadmin depends on:
ii  apache2 [httpd]2.4.25-3+deb9u5
ii  courier-base   0.76.3-5
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u3

courier-webadmin recommends no packages.

Versions of packages courier-webadmin suggests:
pn  courier-doc  

-- debconf information:
* courier-webadmin/install-cgi: true

Bug#909488: There is a possible fix an the recent upstream version

[kinky_nekoboi]

Please build and push