Bug#914615: [Pkg-mozext-maintainers] Bug#914615: closed by Mechtilde Stehmann (reply to mechti...@debian.org) (914615-d...@bugs.debian.org)

[Mechtilde]

Hello Jeemy,
Am 25.01.19 um 23:39 schrieb Jeremy Bicha:
> On Fri, Jan 25, 2019 at 1:51 PM Debian Bug Tracking System
>  wrote:
>> From: Mechtilde Stehmann 
>> notfixed - This won't fixed in Debian.
> 
> Why?

as I described before:

there is no*tbsync package in the Ubuntu repo. there is no need to
define a dependency to xul-ext-lightning.

For your own repo you can do it yourself.
> 
> Thanks,
> Jeremy Bicha

Kind regards

-- 
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#920281: Re : Bug#920281: ntopng: Unable to finish the post-inst.

[Ludovico Cavedon]

package ntopng
severity *920281 *serious
tags *920281 + confirmed pending*
*thanks*

On Fri, Jan 25, 2019 at 10:22 AM Marc Haber 
wrote:

> On Thu, Jan 24, 2019 at 12:15:54PM -0800, Ludovico Cavedon wrote:
> > Something is going wrong with the migration I have not been able to
> > reproduce yet.
>
> I see the same issue. The cause is the line
> runuser -u ntopng -- tar xf- -C $DATA_DIR
> in postinst. The error message is a bit misleading, strace shows that
> tar is actually trying to open a file called '-C'.
>

Oh, thank you for the hint. That's an issue I thought I had fixed, but I
must have lost it somehow.
Let me upload a fix right away.

btw, in my opinion this is a release critical bug.
>
>
Agreed,
Ludovico

Bug#920490: bs1770gain: Abort with "free(): invalid next size (normal)" on mp4

[Petter Reinholdtsen]

Package: bs1770gain
Version: 0.5.2-2
Severity: important
X-Debbugs-CC: Peter Belkner 

The program aborts on a problematic file I ran into, and valgrind show
it is writing past the end of an allocated array in sox_flow_effects().
I can try to run with debugging enabled if needed.

% bs1770gain 532116/original/orig_d89dd8f3f6aa4e20a1cf28c0e6f5dcb3.mp4 
analyzing ...
  [1/1] "orig_d89dd8f3f6aa4e20a1cf28c0e6f5dcb3.mp4": 95free(): invalid next 
size (normal)
Aborted
% valgrind bs1770gain 532116/original/orig_d89dd8f3f6aa4e20a1cf28c0e6f5dcb3.mp4 
==24975== Memcheck, a memory error detector
==24975== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==24975== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==24975== Command: bs1770gain 
532116/original/orig_d89dd8f3f6aa4e20a1cf28c0e6f5dcb3.mp4
==24975== 
analyzing ...
  [1/1] "orig_d89dd8f3f6aa4e20a1cf28c0e6f5dcb3.mp4": ==24975== Invalid write of 
size 4
==24975==at 0x114FA1: ??? (in /usr/bin/bs1770gain)
==24975==by 0x1134DC: ??? (in /usr/bin/bs1770gain)
==24975==by 0x111DFF: ??? (in /usr/bin/bs1770gain)
==24975==by 0x11392D: ??? (in /usr/bin/bs1770gain)
==24975==by 0x113A1D: ??? (in /usr/bin/bs1770gain)
==24975==by 0x6251932: sox_flow_effects (in 
/usr/lib/x86_64-linux-gnu/libsox.so.3.0.0)
==24975==by 0x110777: ??? (in /usr/bin/bs1770gain)
==24975==by 0x10E7C8: ??? (in /usr/bin/bs1770gain)
==24975==by 0x10C3F2: ??? (in /usr/bin/bs1770gain)
==24975==by 0x64DB09A: (below main) (libc-start.c:308)
==24975==  Address 0x10bcb090 is 0 bytes after a block of size 32,768 alloc'd
==24975==at 0x48356AF: malloc (vg_replace_malloc.c:298)
==24975==by 0x4837DE7: realloc (vg_replace_malloc.c:826)
==24975==by 0x6244CE2: lsx_realloc (in 
/usr/lib/x86_64-linux-gnu/libsox.so.3.0.0)
==24975==by 0x6250FED: sox_flow_effects (in 
/usr/lib/x86_64-linux-gnu/libsox.so.3.0.0)
==24975==by 0x110777: ??? (in /usr/bin/bs1770gain)
==24975==by 0x10E7C8: ??? (in /usr/bin/bs1770gain)
==24975==by 0x10C3F2: ??? (in /usr/bin/bs1770gain)
==24975==by 0x64DB09A: (below main) (libc-start.c:308)
==24975== 

  integrated:  -18.35 LUFS / -4.65 LU
  [ALBUM]:
  integrated:  -18.35 LUFS / -4.65 LU
done.
==24975== 
==24975== HEAP SUMMARY:
==24975== in use at exit: 47,380 bytes in 250 blocks
==24975==   total heap usage: 17,382 allocs, 17,132 frees, 21,368,601 bytes 
allocated
==24975== 
==24975== LEAK SUMMARY:
==24975==definitely lost: 0 bytes in 0 blocks
==24975==indirectly lost: 0 bytes in 0 blocks
==24975==  possibly lost: 1,352 bytes in 18 blocks
==24975==still reachable: 46,028 bytes in 232 blocks
==24975==   of which reachable via heuristic:
==24975== newarray   : 1,536 bytes in 16 blocks
==24975== suppressed: 0 bytes in 0 blocks
==24975== Rerun with --leak-check=full to see details of leaked memory
==24975== 
==24975== For counts of detected and suppressed errors, rerun with: -v
==24975== ERROR SUMMARY: 3216 errors from 1 contexts (suppressed: 0 from 0)
% mediainfo 532116/original/orig_d89dd8f3f6aa4e20a1cf28c0e6f5dcb3.mp4
General
Complete name: 
532116/original/orig_d89dd8f3f6aa4e20a1cf28c0e6f5dcb3.mp4
Format   : MPEG-4
Format profile   : Base Media / Version 2
Codec ID : mp42 (mp42/mp41)
File size: 12.4 MiB
Duration : 34 s 320 ms
Overall bit rate mode: Variable
Overall bit rate : 3 032 kb/s
Encoded date : UTC 2009-05-05 09:37:21
Tagged date  : UTC 2009-05-05 09:37:21

Video
ID   : 1
Format   : AVC
Format/Info  : Advanced Video Codec
Format profile   : Main@L3.1
Format settings  : CABAC / 4 Ref Frames
Format settings, CABAC   : Yes
Format settings, ReFrames: 4 frames
Format settings, GOP : M=1, N=33
Codec ID : avc1
Codec ID/Info: Advanced Video Coding
Duration : 34 s 320 ms
Bit rate mode: Variable
Bit rate : 3 005 kb/s
Maximum bit rate : 6 000 kb/s
Width: 720 pixels
Height   : 576 pixels
Display aspect ratio : 1.85:1
Frame rate mode  : Constant
Frame rate   : 25.000 FPS
Standard : PAL
Color space  : YUV
Chroma subsampling   : 4:2:0
Bit depth

Bug#873857: 'Screenshot' option of Graphical installer not accessible through keyboard

[Cyril Brulebois]

Hi,

Adding debian-accessibility@ to the loop for feedback regarding possible
changes in the way people are used to using the installer:

Holger Wansing  (2019-01-26):
> Control: reassign -1 cdebconf
> Control: tags -1 + patch
> 
> 
> Holger Wansing  wrote:
> > Kaartic Sivaraam  wrote:
> > > 
> > > I recently tried to install Debian 9 using the graphical installer. Due
> > > to some unknown reason my mouse did not work in the graphical
> > > installer. It wasn't a big deal as I could manage well just with my
> > > keyboard BUT I was unable to capture a screen shot of an error as the
> > > option for taking screen shot wasn't accessible through the keyboard
> > > like the 'Continue' and 'Back' options. It would be nice to make it
> > > accessible through the keyboard as it would be helpful in situations
> > > like this.
> > 
> > Thanks for your mail.
> > This has already been reported in 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873857
> > 
> > And it turns out that this bug already exists from the very beginning in 
> > Debian 4.0, where the graphical installer was introduced ...
> 
> I have prepared a patch to fix this (attached) against cdebconf.
> (I built a netboot gtk image with this patch, and confirmed it works.)
> 
> Thus, re-assigning to cdebconf and tagging as 'patch'.
> 
> Maybe we could have this included for Buster?
> 
> IMO it's unconventional behaviour to have a button which is skipped when
> TAB-bing through the buttons. And it makes the screenshot button unavailable
> when using the graphical installer without a mouse. 
> (Some touchpads don't work with d-i, and if you don't have an usb mouse
> at hand, you may end up with using the g-i without mouse functionality).


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


signature.asc
Description: PGP signature

Bug#920489: new upstream version available

[Harald Dunkel]

Package: opensmtpd
Version: 6.0.3p1-4

Upstream provides a new version OpenSMTPD 6.4.1, see

https://opensmtpd.org/announces/release-6.4.0.txt
https://opensmtpd.org/announces/release-6.4.1.txt

3 important changes to version 6.0.3:

- requires libressl
- config file syntax has been reworked, breaking compatibility
  to old versions
- mail client included

See #754513


Regards
Harri

Bug#920488: Should have an exception for xserver-xorg-video-dummy

[Alexander E. Patrakov]

Package: reportbug
Version: 1.7.28.8-0.3+b1

(I have also checked the latest git at 
https://salsa.debian.org/debian/deborphan/)


Deborphan's --guess-dummy heuristic matches the xserver-xorg-video-dummy 
package. It is not a dummy package, despite the name, so please make an 
explicit exception.


--
Alexander E. Patrakov



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#920477: gnutls-bin: gnutls-cli benchmark outputs wrong results in 32bit arch

[Andreas Metzler]

Control: forwarded -1 https://gitlab.com/gnutls/gnutls/issues/685

On 2019-01-26 Hiroyuki YAMAMORI  wrote:
> Package: gnutls-bin
> Version: 3.6.5-2
> Severity: normal

> Dear Maintainer,

> Some fast ciphers(suites) are strange results.

> $ gnutls-cli --benchmark-ciphers
> Checking AEAD ciphers, payload size: 16384
>  AES-128-GCM 96.93 MB/sec
>  AES-128-CCM 0.31 GB/sec
>CHACHA20-POLY1305 157.18 MB/sec
> (snip)
> NULL 177.63 MB/sec
[...]
> The following code is the cause.

> "gnutls-3.6.5/src/benchmark.h" line 45

> struct benchmark_st {
> struct timespec start;
> unsigned long size;  <== 32bit in i386 arch.
[...]
> This size variable will overflow.

Thank you for report and diagnosis, I have forwarded the bug upstream.

cu Andreas

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

Bug#920487: RFS: wxmaxima/19.01.2-1

[Gunter Königsmann]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: wxmaxima
   Version : 19.01.2-1
   Upstream Author : Gunter Königsmann 
 * URL : http://wxmaxima-developers.github.io/wxmaxima/
 * License : GPL 2+
   Section : math

It builds those binary packages:

wxmaxima   - GUI for the computer algebra system Maxima

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/w/wxmaxima/wxmaxima_19.01.2-1.dsc

More information about wxmaxima can be obtained from https://www.example.com.

Changes since the last upload:

 * The newest upstream version which only contains bug fixes - but contains 
many bug fixes for the display code.


Regards,
   Gunter Königsmann

Bug#920486: rsh-client: rcp has CVE-2018-20685 similar to scp

[Hiroyuki YAMAMORI]

Package: rsh-client
Version: 0.17-19
Severity: important
Tags: security

Refer Bug #919101

Dear Maintainer,

netkit-rcp also has CVE-2018-20685 and CVE-2019-6111 similar to scp.
Source code of the problem below:

"netkit-rsh-0.17/rcp/rcp.c" line 750 (after debian patched)

while (isdigit(*cp))
size = size * 10 + (*cp++ - '0');
if (*cp++ != ' ')
SCREWUP("size not delimited");

if (targisdir) {
char *newbuf;
int need = strlen(targ) + strlen(cp) + 2;
if (need > cursize) {


Thank you,
Hiroyuki YAMAMORI


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages rsh-client depends on:
ii  libc6  2.28-5

rsh-client recommends no packages.

rsh-client suggests no packages.

-- no debconf information

Bug#873857: 'Screenshot' option of Graphical installer not accessible through keyboard

[Kaartic Sivaraam]

Hi Holger,


On 26 January 2019 05:50:32 GMT+05:30, Holger Wansing  
wrote:
>
>I have prepared a patch to fix this (attached) against cdebconf.
>(I built a netboot gtk image with this patch, and confirmed it works.)
>

Great!


>
>(Some touchpads don't work with d-i, and if you don't have an usb mouse
>at hand, you may end up with using the g-i without mouse
>functionality).
>

That's exactly how I noticed the issue.


-- 
Sivaraam

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

Bug#920485: mplayer gets signal 6 when playing ogg files

[Russell Coker]

Package: mplayer
Version: 2:1.3.0-8+b4
Severity: normal

https://archive.org/details/lca2019-Distributed_storage_is_easier_now_usability_from_Ceph_Luminous_to_Nautilus

When trying to play an OGG video from the above page I get the following error.
When I download a MP4 from the same page it works correctly.

When I load the OGV URL in question in Google Chrome it correctly plays the
video.

The same problem occurs with several other OGV files from LCA 2019.

$ mplayer 
Distributed_storage_is_easier_now_usability_from_Ceph_Luminous_to_Nautilus.ogv 
MPlayer 1.3.0 (Debian), built with gcc-8 (C) 2000-2016 MPlayer Team
do_connect: could not connect to socket
connect: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing 
Distributed_storage_is_easier_now_usability_from_Ceph_Luminous_to_Nautilus.ogv.
libavformat version 58.20.100 (external)
Mismatching header version 58.12.100
libavformat file format detected.
Invalid return value 0 for stream protocol
Invalid return value 0 for stream protocol
[lavf] stream 0: video (theora), -vid 0, Distributed storage is easier now: 
usability from Ceph Luminous to Nautilus
[lavf] stream 1: audio (vorbis), -aid 0, Distributed storage is easier now: 
usability from Ceph Luminous to Nautilus
VIDEO:  [theo]  534x300  0bpp  29.970 fps0.0 kbps ( 0.0 kbyte/s)
==
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 58.35.100 (external)
Mismatching header version 58.18.100
Selected video codec: [fftheora] vfm: ffmpeg (FFmpeg Theora)
==
Load subtitles in ./
==
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, floatle, 128.0 kbit/4.54% (ratio: 16000->352800)
Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis)
==
AO: [pulse] Init failed: Connection refused
Failed to initialize audio driver 'pulse'
[AO_ALSA] alsa-lib: pcm_hw.c:1711:(snd_pcm_hw_open) open '/dev/snd/pcmC0D0p' 
failed (-77): File descriptor in bad state
AO: [alsa] 48000Hz 2ch floatle (4 bytes per sample)
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [vdpau] 534x300 => 534x300 Planar YV12 
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [vdpau] 534x300 => 534x300 Planar YV12 
Dropping frame with size not matching configured size (534x300 vs 524x296 vs 
534x300)
Dropping frame with size not matching configured size (534x300 vs 524x296 vs 
534x300)
[VD_FFMPEG] DRI failure.
mplayer: libmpcodecs/vf.c:286: vf_get_image: Assertion `w == -1 || w >= vf->w' 
failed.


MPlayer interrupted by signal 6 in module: decode video
 [ This binary of MPlayer in Debian is currently compiled with
   '--enable-debug'; the debugging symbols are in the package
   'mplayer-dbgsym'.]

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages mplayer depends on:
ii  liba52-0.7.4  0.7.4-19
ii  libaa11.4p5-45
ii  libasound21.1.7-2
ii  libass9   1:0.14.0-2
ii  libaudio2 1.9.4-6
ii  libavcodec58  7:4.1-1
ii  libavformat58 7:4.1-1
ii  libavutil56   7:4.1-1
ii  libbluray21:1.0.2-3
ii  libbs2b0  3.1.0+dfsg-2.2
ii  libc6 2.28-5
ii  libcaca0  0.99.beta19-2+b3
ii  libcdio-cdda2 10.2+0.94+2-4
ii  libcdio-paranoia2 10.2+0.94+2-4
ii  libcdio18 2.0.0-2
ii  libdca0   0.0.6-1
ii  libdirectfb-1.7-7 1.7.7-8
ii  libdv41.0.0-12
ii  libdvdnav46.0.0-1
ii  libdvdread4   6.0.0-1
ii  libenca0  1.19-1+b1
ii  libfaad2  2.8.8-1
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libfribidi0   1.0.5-3.1
ii  libgif7   5.1.4-3
ii  libgl11.1.0-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  liblirc-client0   0.10.1-5
ii  

Bug#919742: orthanc-wsi FTBFS 'class GlobalDcmDataDictionary' has no member named 'unlock'

[peter green]

tags 919742 +patch
thanks

Since this seemed to be the last thing blocking the dcmtk transition in 
raspbian buster I decided to take a look.

It seems that orthanc-wsi has an embedded copy of an old version orthanc, it 
also build-depends on orthanc-dev,
I am not sure if the system orthanc is unused or if the embedded copy is used 
for some things and the system
copy for others.

The patches needed are the same as were needed for orthanc as documented in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919193#10

The tricky bit was actually applying them, the embedded copy of orthanc is 
shipped as a tarball which
is copied to locations where the upstream build system detects and unpacks it.

I modified debian/rules to unpack, patch and repack the tarball before copying 
it to where the
upstream build system expected it. Unfortunately the upstream build system then 
rejected
it with a md5 mismatch, so I patched the upstream build system to remove the 
md5 check
and to remove automatic downloading of the tarball (for safety since there was 
no longer any
validation of it).

While I was doing this I ran into a situation where the clean target was not 
cleaning up sufficiently
so I fixed that too.

With these changes I was able to get a succesful build in raspbian 
buster-staging, a debdiff
can be found at 
https://debdiffs.raspbian.org/main/o/orthanc-wsi/orthanc-wsi_0.5-2+rpi1.debdiff

No intent to NMU in Debian.

Bug#919637: RFS: elinks/0.13~20190114-1 [ITA]

[أحمد المحمودي]

On Mon, Jan 21, 2019 at 03:37:24PM +0100, Adam Borowski wrote:
> Alas, it still FTBFSes:
> 
> Working on: /<>/doc/manual.xml
> xmlto: /<>/doc/manual.xml does not validate (status 3)
> xmlto: Fix document syntax or use --skip-validation option
> /<>/doc/manual.xml:3993: element link: validity error : IDREF 
> attribute linkend references an unknown ID "CONFIG-SCRIPTING-SPIDERMONKEY"
> Document /<>/doc/manual.xml does not validate
> make[2]: *** [Makefile:201: manual.html-chunked] Error 13
---end quoted text---

Fixed upstream. I have re-uploaded to mentors.
-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

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

[Bill Brelsford]

With the tests removed, it builds and installs successfully.  But
during boot,

udevadm trigger --type=subsystems --action=add --wait-daemon

fails with something like

Failed to connect to udev daemon (connection refused).

It works with a 2-second sleep inserted before the udevadm call.
Sounds familiar..

Bill

Bug#920409: splitpatch: please make the build reproducible

[Eriberto Mota]

Em sex, 25 de jan de 2019 às 06:00, Chris Lamb  escreveu:
>
> forwarded 920409 https://github.com/benjsc/splitpatch/pull/10
> thanks
>
> I've forwarded this upstream here:
>
>   https://github.com/benjsc/splitpatch/pull/10


Hi Chris,

Thanks for your help. The current upstream is jaalto[1]. I will forward now.

[1] https://github.com/jaalto/splitpatch

Regards,

Eriberto

Bug#920484: stegsnow: Packaging licensing incompatible with upstream

[Joao Eriberto Mota Filho]

Package: stegsnow
Version: 20130616-3
Severity: normal

The current packaging licensing (GPL-2) is incompatible with upstream
licensing (Apache-2.0). It is a hampering condition to submit patches
from Debian to upstream.

I am adopting the package and I intent change the packaging licensing.

I will wait 10 days to know if anyone has any objection.

Thanks!

Regards,

Eriberto

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

Bug#920482: apt update fails to update from repository missing optional Contents files

[Andrew Worsley]

Now fixed by purging the apt-file package!
Big thanks to pabs on IRC #debian-apt for this solution.

Note: You need to purge the package to make sure the config file
apt-file supplies is removed to fix this problem (remove is *NOT*
enough)

Apparently apt-file no works by using apt-get to install the Contents
target for that file.
This can be configure as described in
/usr/share/doc/apt-file/README.md.gz for certain repositories via a
line like:
[target-=Contents-deb] $MIRROR/debian unstable main ...

Bug#920374: python-openssl: _ASN1_TYPE_TO_ENUM TypeError: 'type' object is not iterable

[Sandro Tosi]

control: tags -1 +unreproducible +moreinfo

> >>> from OpenSSL import crypto, SSL
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/dist-packages/OpenSSL/__init__.py", line 8, in 
> 
> from OpenSSL import crypto, SSL
>   File "/usr/lib/python2.7/dist-packages/OpenSSL/crypto.py", line 12, in 
> 
> from cryptography import x509
>   File "/usr/lib/python2.7/dist-packages/cryptography/x509/__init__.py", line 
> 8, in 
> from cryptography.x509.base import (
>   File "/usr/lib/python2.7/dist-packages/cryptography/x509/base.py", line 16, 
> in 
> from cryptography.x509.extensions import Extension, ExtensionType
>   File "/usr/lib/python2.7/dist-packages/cryptography/x509/extensions.py", 
> line 24, in 
> from cryptography.x509.general_name import GeneralName, IPAddress, 
> OtherName
>   File "/usr/lib/python2.7/dist-packages/cryptography/x509/general_name.py", 
> line 18, in 
> from cryptography.x509.name import Name
>   File "/usr/lib/python2.7/dist-packages/cryptography/x509/name.py", line 28, 
> in 
> _ASN1_TYPE_TO_ENUM = dict((i.value, i) for i in _ASN1Type)
> TypeError: 'type' object is not iterable

I cannot replicate this crash in an up-to-date chroot, are you sure
there's nothing wrong on your system?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#885200: Package gwave needs to be upgraded

[أحمد المحمودي]

Hello,

On Tue, Jan 15, 2019 at 11:39:18PM -0500, Steve Tell wrote:
> I just got a version working with guile-2.2, although its off on a side
> development branch in my sourceforge tree at the moment:
> https://sourceforge.net/p/gwave/code/HEAD/tree/branches/no-ggp-branch/
> [...]
> Anyway, I expect to make some kind of a release shortly.  I'll probably
> integrate the no-ggp branch onto the head, since that's my plan going
> forward.
---end quoted text---

I tried to build gwave 20190116, but I got this error on during 
configure phase:

configure: checking for guile 2.2
configure: found guile 2.2
checking for guile-2.2... /usr/bin/guile-2.2
checking for Guile version >= 2.2... 2.2.4
checking for guild-2.2... no
checking for guile-config-2.2... no
checking for guile-tools-2.2... no
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking for GUILE... yes
configure: error: 'guild' binary not found; please check your guile-2.x 
installation.

although guile-2.2-dev does have /usr/bin/guild !

anyways I have pushed my work to salsa:
https://salsa.debian.org/electronics-team/gwave.git


-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#920483: The keyboard layout displays “us” whatever the current layout until a key is pressed

[21naown]

Package: sddm
Version: 0.14.0-4+deb9u1
Severity: normal
Tags: upstream


For example with a French layout:
The keyboard layout displays “us” until a key is pressed, then “fr” is 
displayed.



-- System Information:
Debian Release: 9.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, '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), 
LANGUAGE= (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sddm depends on:
ii adduser 3.115
ii debconf [debconf-2.0] 1.5.61
ii libc6 2.24-11+deb9u3
ii libgcc1 1:6.3.0-18+deb9u1
ii libpam0g 1.1.8-3.6
ii libqt5core5a 5.7.1+dfsg-3+b1
ii libqt5dbus5 5.7.1+dfsg-3+b1
ii libqt5gui5 5.7.1+dfsg-3+b1
ii libqt5network5 5.7.1+dfsg-3+b1
ii libqt5qml5 5.7.1-2+b2
ii libqt5quick5 5.7.1-2+b2
ii libstdc++6 6.3.0-18+deb9u1
ii libsystemd0 232-25+deb9u8
ii libxcb-xkb1 1.12-1
ii libxcb1 1.12-1
ii qml-module-qtquick2 5.7.1-2+b2
ii x11-common 1:7.7+19
ii xserver-xorg [xserver] 1:7.7+19

Versions of packages sddm recommends:
ii libpam-systemd 232-25+deb9u8
ii sddm-theme-debian-maui [sddm-theme] 0.14.0-4+deb9u1

Versions of packages sddm suggests:
ii libpam-kwallet5 5.8.4-1+deb9u2

-- debconf information:
* shared/default-x-display-manager: sddm
sddm/daemon_name: /usr/bin/sddm

Bug#920482: apt update fails to update from repository missing optional Contents files

[Andrew Worsley]

Package: apt
Version: 1.8.0~alpha3.1
Severity: important


  I maintain a mirror via a local python script which doesn't bother to cache 
the optional
Contents files as described in
https://wiki.debian.org/DebianRepository/Format#A.22Contents.22_indices :

"They are optional indices describing which files can be found in which 
packages"

  But whilst my debian stretch box happily upgrades my stretch mirror my buster
mirror is no longer wanting to upgrade my testing box.

  If I add a URL for my mirror and an official mirror ftp.au.debian.org and do 
an update
it appears to fail to update from my mirror complaining about the missing 
Contents file:

% sudo apt update
[sudo] password for amw:
Get:1 http://azza/debs/buster buster InRelease [159 kB]
Get:2 http://azza/debs/buster buster/main amd64 Packages [10.6 MB]
Get:3 http://azza/debs/buster buster/main Translation-en [5,966 kB]
Get:4 http://azza/debs/buster buster/main amd64 Contents (deb) [36.5 MB]
Get:4 http://azza/debs/buster buster/main amd64 Contents (deb) [36.5 MB]
Get:4 http://azza/debs/buster buster/main amd64 Contents (deb) [36.5 MB]
Get:4 http://azza/debs/buster buster/main amd64 Contents (deb) [36.5 MB]
Ign:4 http://azza/debs/buster buster/main amd64 Contents (deb)
Ign:9 http://azza/debs/buster buster/contrib amd64 Contents (deb)
Ign:10 http://azza/debs/buster buster/non-free amd64 Contents (deb)
Err:4 http://azza/debs/buster buster/main amd64 Contents (deb)
  404  Not Found [IP: 10.0.0.51 80]
Ign:9 http://azza/debs/buster buster/contrib amd64 Contents (deb)
Ign:10 http://azza/debs/buster buster/non-free amd64 Contents (deb)
Hit:11 http://ftp.au.debian.org/debian buster InRelease
Fetched 159 kB in 2s (67.0 kB/s)
Reading package lists... Done
E: Failed to fetch http://azza/debs/buster/dists/buster/main/Contents-amd64  
404  Not Found [IP: 10.0.0.51 80]
E: Some index files failed to download. They have been ignored, or old ones 
used instead.

   Even though my mirror has that up to date version of the packages and the 
InRelease
   and Packages.gz files are up to date and list the new version of packages 
won't
   install it from my mirror.

% apt-cache policy vim
vim:
  Installed: 2:8.1.0549-1
  Candidate: 2:8.1.0693-2
  Version table:
 2:8.1.0693-2 500
500 http://ftp.au.debian.org/debian buster/main amd64 Packages
 *** 2:8.1.0549-1 100
100 /var/lib/dpkg/status

   It appears the Error on the Contents file prevents the azza repository 
Package data
   from being loaded?

   This appears to be a recent problem - i.e. the last couple of weeks.

   I have not changed my mirror script to start mirroring Contents file to 
confirm
   this is the key difference. If Content files are meant to be mandatory now 
could
   the Wiki page be updated?

   I tried asking on the #debian-apt IRC but got no answer so raising a 
bugreport

Thanks

Andrew

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.18\.0-3-amd64$";
APT::NeverAutoRemove:: "^linux-m

Bug#918014: Bokep

[Asep Asrp]

asepasrp3...@gmail.com

Bug#919584: man-db doesn't find subdirectories with man pages (from conda)

[Colin Watson]

On Thu, Jan 17, 2019 at 04:19:16PM +0100, Jan van Haarst wrote:
>I am trying to use a man page that is installed using conda.
> 
>If I start man like this : man -d parallel , I see this :
> 
>(unrelated info removed)
>---
>path directory /home/haars001/miniconda2/envs/isoseq/bin is not in the
>config file
>and doesn't have ../man, man, ../share/man, or share/man subdirectories
>---
>But if I do a manual lookup with ls, I get this :
>---
>ls /home/haars001/miniconda2/envs/isoseq/bin/../man
>man1  man3
>ls /home/haars001/miniconda2/envs/isoseq/bin/../share/man
>man1  man3  man5  man7  man8
>---
>As man can't find the correct subdirectory, I get the wrong man page in
>this case, or man can't find the man page in other cases.
>I hope this is user error, then it's easier to fix

Thanks for your report.  Could I please see the full output of "man -d
parallel", even if some of it looks unrelated?

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

Bug#920481: openhft-chronicle-wire: FTBFS: uses deprecated classes/methods

[Andreas Beckmann]

Source: openhft-chronicle-wire
Version: 1.16.18-1
Severity: serious
Justification: fails to build from source

Hi,

openhft-chronicle-wire/experimental recently started to FTBFS with these
errors:

C[1;31mERRORESC[m] Failed to execute goal 
ESC[32morg.apache.maven.plugins:maven-compiler-plugin:3.8.0:compileESC[m 
ESC[1m(default-compile)ESC[m on project ESC[36mchronicle-wireESC[m: 
ESC[1;31mCompilation failur
eESC[m: Compilation failure: 
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/VanillaMethodWriterBuilder.java:[20,35]
 net.openhft.chronicle.bytes.MethodWriterBuilder in net.openhft.chronicle
.bytes has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/WireType.java:[484,19]
 urlFor(java.lang.String) in net.openhft.chronicle.core.io.IOTools has been 
deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/Wires.java:[89,36]
 getProxyClass(java.lang.ClassLoader,java.lang.Class...) in 
java.lang.reflect.Proxy has bee
n deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/VanillaMethodWriterBuilder.java:[35,68]
 net.openhft.chronicle.bytes.MethodWriterBuilder in net.openhft.chronicle
.bytes has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/VanillaMethodWriterBuilder.java:[35,68]
 net.openhft.chronicle.bytes.MethodWriterBuilder in net.openhft.chronicle
.bytes has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/VanillaMethodWriterBuilder.java:[51,12]
 net.openhft.chronicle.bytes.MethodWriterBuilder in net.openhft.chronicle
.bytes has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/VanillaMethodWriterBuilder.java:[57,12]
 net.openhft.chronicle.bytes.MethodWriterBuilder in net.openhft.chronicle
.bytes has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/VanillaMethodWriterBuilder.java:[63,12]
 net.openhft.chronicle.bytes.MethodWriterBuilder in net.openhft.chronicle
.bytes has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/VanillaMethodWriterBuilder.java:[69,12]
 net.openhft.chronicle.bytes.MethodWriterBuilder in net.openhft.chronicle
.bytes has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/VanillaMethodWriterBuilder.java:[75,12]
 net.openhft.chronicle.bytes.MethodWriterBuilder in net.openhft.chronicle.bytes 
has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/VanillaMethodWriterBuilder.java:[81,12]
 net.openhft.chronicle.bytes.MethodWriterBuilder in net.openhft.chronicle.bytes 
has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/VanillaMethodWriterBuilder.java:[107,12]
 net.openhft.chronicle.bytes.MethodWriterBuilder in net.openhft.chronicle.bytes 
has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/VanillaMethodWriterBuilder.java:[112,12]
 net.openhft.chronicle.bytes.MethodWriterBuilder in net.openhft.chronicle.bytes 
has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/BinaryReadDocumentContext.java:[54,17]
 metaData(boolean) in net.openhft.chronicle.wire.DocumentContext has been 
deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/NoDocumentContext.java:[31,17]
 metaData(boolean) in net.openhft.chronicle.wire.DocumentContext has been 
deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/DefaultValueIn.java:[384,29]
 map(@org.jetbrains.annotations.NotNull 
java.lang.Class,@org.jetbrains.annotations.NotNull 
java.lang.Class,java.util.Map) in net.openhft.chronicle.wire.ValueIn 
has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/DefaultValueIn.java:[377,74]
 typedMap(@org.jetbrains.annotations.NotNull java.util.Map) in 
net.openhft.chronicle.wire.ValueIn has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/TextWire.java:[1962,24]
 typedMap(@org.jetbrains.annotations.NotNull java.util.Map) in 
net.openhft.chronicle.wire.ValueOut has been deprecated
[ESC[1;31mERRORESC[m] 
/build/openhft-chronicle-wire-1.16.18/src/main/java/net/openhft/chronicle/wire/TextWire.java:[1937,24]
 map(java.util.Map) in net.openhft.chronicle.wire.ValueOut h

Bug#920398: RM: twill -- ROM; abandoned upstream

[Arnaud Fontaine]

block 920398 by 920478 920479 920480
thanks

Hi,


There are, however, users in the archive:

Checking reverse dependencies...
# Broken Build-Depends:
flask-testing: python-twill
trac: python-twill
trac-xmlrpc: python-twill

Dependency problem found.

Please ask them to drop the build-depends and remove the moreinfo tag 
once

that is done.


I should have checked before filling this bug report, sorry about that. 
I have

thus submitted bug reports on these packages.

Cheers,
Arnaud Fontaine

Bug#920480: Build-Depends on twill going to be removed from the archive

[Arnaud Fontaine]

Package: trac-xmlrpc
Severity: normal

Hi,

For the reasons stated in #920398, as  twill maintainer I have asked for it to
be removed from  the archive. However your package Build-Depends  on it. Would
it be possible to remove it?

Cheers,
Arnaud Fontaine

Bug#820485: lynx: Cookie handling at odds with RFC 6265

[Thomas Dickey]

On Fri, Apr 08, 2016 at 03:48:20PM -0700, Andy Valencia wrote:
> Package: lynx
> Version: 2.8.9dev1-2+deb8u1
> Severity: normal
> 
> RFC 6265 cleared up some older ambiguities with respect to different
> ports on the same web server host.  Specifically:

yes but - perhaps some additional clarification is needed.  Reading the
code, the only place where Lynx appears to be paying attention to the
port for cookies is from an RFC-2965 implementation which provides
a "Port" attribute.  An RFC 6265-compliant implementation wouldn't send
that.

(In 2.9.0dev.1, Lynx will ignore the Port attribute when in RFC-6265 mode).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#920478: Build-Depends on twill going to be removed from the archive

[Arnaud Fontaine]

Source: flask-testing
Severity: normal

Hi,

For the reasons stated  in #920398, as twill maintainer I have asked for it to
be removed from  the archive. However your package Build-Depends  on it. Would
it be possible to remove it?

Cheers,
Arnaud Fontaine

Bug#920479: Builds-Depends on twill going to be removed from the archive

[Arnaud Fontaine]

Package: trac
Severity: normal

Hi,

For the reasons stated in #920398, as  twill maintainer I have asked for it to
be removed from  the archive. However your package Build-Depends  on it. Would
it be possible to remove it?

Cheers,
Arnaud Fontaine

Bug#817914: developers-reference: globally change "new maintainer" into "new member"

[Holger Wansing]

Hi,

Holger Levsen  wrote:
> > Therefore, it's of course not possible and also not useful, to substitute
> > all "maintainer" into "member" and the like (think about phrases like
> > "maintainer script" and "maintainer field in control" and ...), which are
> > still correct and will not be renamed into "member script" or "member 
> > field".
> > 
> > This only as a explanation, why not all occurrences of "maintainer" have
> > been switched to "member".
> 
> I totally agree and I also think you've done a few substituion too many,
> see below...
> 
> > (Yes, this relativizes the bug title a bit :-) )
> > I hope I got it mostly right.
> 
> in any case: many thanks for your quick response! let's get this settled
> now!
> 
> some (quick) comments, stuff I havent commented is fine IMO.
> 
> > -Given how easy it is to become a Debian Maintainer, you might want
> > +Given how easy it is to become a Debian Member, you might want
> >  to only sponsor people who plan to join. 
> 
> to become a Maintainer?

Maybe ...
But as a first step, it would be enough to only be a member.
For team maintained packages you can also do package work | package uploading
work as a member (at least these are my experiences; see below).

> > -The process of registering as a developer is a process of verifying your
> > +The process of registering as a member is a process of verifying your
> 
> ... a maintainer?

Here we refer to the NM process itself, which is officially named "New Member
process" these days.
So I think "member" is fine here.

> (maybe then we also need one paragraph explaining that developers are
> maintainers too? and developers are members, but members not necessarily
> developers nor maintainers? ;)

Yes, but question is, if we want to make it that complicated :-)
Remember it should be understandable for new people ...

> > -Therefore, we need to verify new maintainers before we can give them 
> > accounts
> > +Therefore, we need to verify new members before we can give them accounts
> >  on our servers and let them upload packages.
> 
> not sure if members can get server access. maintainers surely can. maybe
> "new developers/maintainers"? (also to answer my own question in the
> previous paragraph, maybe be explicit and say
> 'member/developer/maintainer' if we mean that?

Members have chance to get permission to access dillon :-)))
At least in my case.

I am not a developer, and I am not mentioned as a maintainer in some packages'
control file, so I assume I am a member? ;-))
And I got upload permissions for d-i packages, and I got access to dillon.
As it seems the rules are always somewhat flexible ...

> 
> > -Resources for Debian Developers and Debian Maintainers
> > +Resources for Debian Members\
> 
> see above :)

I assume that all developers and maintainers are also members (in german we
say "kleinster gemeinsamer Nenner").

As written above: maybe we should not make this more complicated as needed
and use 'member' as a cover term?

> Even if this seems a bit confusing now I'd hope it was that bad. Have
> you seen anything where you would like to rework your patch or do you
> think it should rather go in as such?
> 
> (once it goes in it will trigger translation updates so we better are
> careful...)

This is why I first thought "Huh it's maybe to late for this change now?", 
since translators maybe have only little chance to catch up...
But to not postpone this too much I prepared a patch anyway.



As a summary:
I see no strict need to do reworking on my patch IMHO.
(You can always find corner cases, where the terms are debatable, because
of historical growth of the document and the rules in Debian, as already
said. But I think it should fit this way.)


So long
Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#873857: 'Screenshot' option of Graphical installer not accessible through keyboard

[Holger Wansing]

Control: reassign -1 cdebconf
Control: tags -1 + patch


Holger Wansing  wrote:
> Kaartic Sivaraam  wrote:
> > 
> > I recently tried to install Debian 9 using the graphical installer. Due
> > to some unknown reason my mouse did not work in the graphical
> > installer. It wasn't a big deal as I could manage well just with my
> > keyboard BUT I was unable to capture a screen shot of an error as the
> > option for taking screen shot wasn't accessible through the keyboard
> > like the 'Continue' and 'Back' options. It would be nice to make it
> > accessible through the keyboard as it would be helpful in situations
> > like this.
> 
> Thanks for your mail.
> This has already been reported in 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873857
> 
> And it turns out that this bug already exists from the very beginning in 
> Debian 4.0, where the graphical installer was introduced ...

I have prepared a patch to fix this (attached) against cdebconf.
(I built a netboot gtk image with this patch, and confirmed it works.)

Thus, re-assigning to cdebconf and tagging as 'patch'.

Maybe we could have this included for Buster?

IMO it's unconventional behaviour to have a button which is skipped when
TAB-bing through the buttons. And it makes the screenshot button unavailable
when using the graphical installer without a mouse. 
(Some touchpads don't work with d-i, and if you don't have an usb mouse
at hand, you may end up with using the g-i without mouse functionality).



Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/src/modules/frontend/gtk/screenshot.c b/src/modules/frontend/gtk/screenshot.c
index 24bc3dcc..1c854f76 100644
--- a/src/modules/frontend/gtk/screenshot.c
+++ b/src/modules/frontend/gtk/screenshot.c
@@ -183,6 +183,7 @@ GtkWidget * cdebconf_gtk_create_screenshot_button(struct frontend * fe)
 {
 struct frontend_data * fe_data = fe->data;
 GtkWidget * action_box = fe_data->action_box;
+GList * focus_chain;
 GtkWidget * button;
 char * label;
 
@@ -199,8 +200,10 @@ GtkWidget * cdebconf_gtk_create_screenshot_button(struct frontend * fe)
TRUE /* expand */, TRUE /* fill */, DEFAULT_PADDING);
 gtk_button_box_set_child_secondary(GTK_BUTTON_BOX(action_box),
button, TRUE);
-/* Remove the screenshot button from the focus chain. */
-gtk_container_set_focus_chain(GTK_CONTAINER(action_box), NULL);
+gtk_container_get_focus_chain(GTK_CONTAINER(action_box), &focus_chain);
+focus_chain = g_list_prepend(focus_chain, button);
+gtk_container_set_focus_chain(GTK_CONTAINER(action_box), focus_chain);
+g_list_free(focus_chain);
 
 return button;
 }

Bug#920477: gnutls-bin: gnutls-cli benchmark outputs wrong results in 32bit arch

[Hiroyuki YAMAMORI]

Package: gnutls-bin
Version: 3.6.5-2
Severity: normal

Dear Maintainer,

Some fast ciphers(suites) are strange results.

$ gnutls-cli --benchmark-ciphers
Checking AEAD ciphers, payload size: 16384
 AES-128-GCM 96.93 MB/sec
 AES-128-CCM 0.31 GB/sec
   CHACHA20-POLY1305 157.18 MB/sec
(snip)
NULL 177.63 MB/sec

$ gnutls-cli --benchmark-tls-ciphers
Testing throughput in cipher/MAC combinations (payload: 1400 bytes)
   AES-128-GCM - TLS1.2  45.26 MB/sec
   AES-128-GCM - TLS1.3  45.01 MB/sec
   AES-128-CCM - TLS1.2  129.46 MB/sec
(snip)

The following code is the cause.

"gnutls-3.6.5/src/benchmark.h" line 45

struct benchmark_st {
struct timespec start;
unsigned long size;  <== 32bit in i386 arch.
sighandler_t old_handler;
#if defined(_WIN32)
HANDLE wtimer;
HANDLE wthread;
LARGE_INTEGER alarm_timeout;
#endif
};

This size variable will overflow.

Thank you,
Hiroyuki YAMAMORI


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

Kernel: Linux 4.19.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gnutls-bin depends on:
ii  libc62.28-5
ii  libgmp10 2:6.1.2+dfsg-4
ii  libgnutls-dane0  3.6.5-2
ii  libgnutls30  3.6.5-2
ii  libhogweed4  3.4.1~rc1-1
ii  libidn2-02.0.5-1
ii  libnettle6   3.4.1~rc1-1
ii  libopts251:5.18.12-4
ii  libp11-kit0  0.23.14-2
ii  libtasn1-6   4.13-3
ii  libunistring20.9.10-1

gnutls-bin recommends no packages.

gnutls-bin suggests no packages.

-- no debconf information

Bug#484805: marked as done (developers-reference: please make clone to tech-ctte the default)

[Holger Levsen]

On Fri, Jan 25, 2019 at 04:56:09PM -0700, Sean Whitton wrote:
> > which IMO is as good as it is. It also explicitly points to
> > http://www.debian.org/devel/tech-ctte for detailed information.
> At least for Policy bugs referred to the TC, they prefer a fresh bug
> where the first message is a summary of the situation, rather than a clone.

so you suggest a reopening of this bug?

(yes or no as an answer would be great, even greater in the case of
'yes' would obviously be a patch, but many thanks already for this
feedback, we can write the patch later, if needed?!)


-- 
tschüß,
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#920437: ITP: displaylink -- Proprietary driver for DisplayLink devices

[Ben Hutchings]

On Fri, 2019-01-25 at 14:21 -0500, Hanno Stock wrote:
> Am Fr, 25. Jan 2019, um 17:03, schrieb Ben Hutchings:
> > Please consider choosing a more specific package name.  Since we
> > have
> > free drivers for some DisplayLink devices, we should encourage
> > users to
> > use those where possible.
> 
> Ok, I see. What about displaylink-nonfree ? One could also append to
> the long description a hint which package to
> use for devices supported by the free drivers.

That seems sensible.

Ben.

-- 
Ben Hutchings
I'm not a reverse psychological virus.
Please don't copy me into your signature.




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

Bug#919540: Export my package BlastEm to the Debian Games team

[Carlos Donizete Froes]

Hi Tobias,

> Sorry, that I have again to be the game spoiler, but as I asked you
> already on diffeent software but on quite a similiar situation:
> 
> _Why_ did you fork this?
> 
> There are no obvious reasons, upstream[1] is very active (and has
> actually released a newer version than yours) and your changes to the
> source code are fixing typos, and those mostly in comments. I could not
> find any difference that. That does NOT make you the upstream author.
> 
> Maybe I was not explict enough: Such forks are damaging to the FLOSS
> ecosystem. Forks should ONLY done for severe reasons.
> 
> Forks like this one might be even seen as quite offensive, as it
> looks like that you want to take credits where credits are not due.
> 
> Work with upstream. Do not fork without *severe* reasons.
> 
> IMHO, if we include blastem, than from [1].

As the upstream is working with Mercurial, at the moment we were talking about 
migrating to my
GitLab account and the procedure to start the packaging and permission to make 
small changes to
reduce the huge amount of lintian errors and warnings.

Please follow the email contacts I had with the upstream.[1]

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919540

I'm sorry for giving you a poor opinion that I only make corrections for typos 
in my comments,
please check my comments again. :(

I do not want to be the author of the software. All the work I do, I'm always 
communicating with the
upstream. The reason is to help the upstream get their software in Debian. :)

BlastEm (0.6.2-1) found in mentors.d.o[2] is the most current one with some 
fixes for which the
upstream itself made the changes to start Debian packaging.[3][4]

[2] https://mentors.debian.net/package/blastem

[3] https://gitlab.com/coringao/blastem/commits/master

[4] https://www.retrodev.com/repos/blastem

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780


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

Bug#919982: apt-setup: preseeded installation hangs at "Use a network mirror?"

[Steve McIntyre]

Hi Wolfgang!

On Wed, Jan 23, 2019 at 11:07:29AM +0100, Wolfgang Schweer wrote:
>
>I'm pretty sure that this is due to the Debian Edu related changes to 
>debian-cd, see: 
>https://salsa.debian.org/images-team/debian-cd/commit/15b482d49e642e21e983dba27a47b4fc2d8b90b4
> 
>We proposed/did those to be able to have a BD ISO image with COMPLETE=0 
>(for the image to be small enough) with 'bluray/not_complete' instead of 
>'not_complete' written to $CDDIR/.disk/cd_type (the default for the 
>COMPLETE=0 case). The patch had been taken from the former Debian Edu CD 
>build system; obviously some more thinking about the compliance with the 
>more general case would have been good, sorry.
>
>I guess the following change could amend things:
>
>diff --git a/tools/start_new_disc b/tools/start_new_disc
>index 0b64a7e..83838d1 100755
>--- a/tools/start_new_disc
>+++ b/tools/start_new_disc
>@@ -212,11 +212,7 @@ if [ $DISKNUM = 1 ] ; then
> echo "bluray/not_complete" > $CDDIR/.disk/cd_type
> fi
> else
>-if [ "$MAXCDS"x = "1"x ]; then
>-echo "cd/single/not_complete" > $CDDIR/.disk/cd_type
>-else
>-echo "cd/not_complete" > $CDDIR/.disk/cd_type
>-fi
>+echo "not_complete" > $CDDIR/.disk/cd_type
> fi
> fi
>
>Please check.

So I've been looking through this code again, and the corresponding
code in apt-setup that uses these values. Last time I played with
apt-setup, I added a table to describe what d-i will do based on the
information in cd_type, to explain exactly what d-i expects:

# Various different image types look different here:
#
# Image Type   cd_type
###
# netinst  "not_complete"
# full CD sets (default desktop)   "full_cd"
# desktop-specific CD images   "full_cd/single"
# DVD  "dvd"
# bluray   "bluray"
# multi-arch CD/DVD"not_complete"
# live "live"
#
# It can make sense to offer to scan more media here in most cases,
# but... on live or blu-ray it's unlikely to help; the
# desktop-specific image is designed specifically to work with only a
# single image. Hopefully the following makes sense.

The changes you've imported from the debian-edu fork of debian-cd
clearly don't match up with these, and that's a problem. So *for now*
I'm reverting them so we can build a d-i alpha 5 CD/DVD release that
we're already overdue for. Apologies for not getting back to you
earlier and reviewing the suggested changes back then. That's my fault
for being too busy and not looking at this code before it was merged.

We'll come back to this again shortly. To help with that, could you
describe exactly what debian-edu is expecting here please, i.e. what
the settings in cd_type mean for the debian-edu installer? I'm worried
that we may not have a clear solution here that can match the current
expectations of both d-i and and the debian-edu setup.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?

Bug#484805: marked as done (developers-reference: please make clone to tech-ctte the default)

[Sean Whitton]

Hello,

On Fri 25 Jan 2019 at 07:21PM +00, Debian Bug Tracking System wrote:

> i'm closing this bug report because the wording has been improved
> compared to when this bug was filed. It now says:
>
> if this situation is
> unacceptable, you (or the submitter) may want to require a decision of the
> technical committee by reassigning the bug to  role="package">tech-ctte (you may use the clone command of the 
> BTS
> if you wish to keep it reported against your package).  Before doing so, 
> please
> read the recommended
> procedure.
>
> which IMO is as good as it is. It also explicitly points to
> http://www.debian.org/devel/tech-ctte for detailed information.

At least for Policy bugs referred to the TC, they prefer a fresh bug
where the first message is a summary of the situation, rather than a clone.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#816200: bitlbee: diff for NMU version 3.5.1-1.1

[Sean Whitton]

Control: tags 816200 + pending

Dear maintainer,

I've prepared an NMU for bitlbee (versioned as 3.5.1-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
Sean Whitton
diff -u bitlbee-3.5.1/debian/bitlbee-common.postinst bitlbee-3.5.1/debian/bitlbee-common.postinst
--- bitlbee-3.5.1/debian/bitlbee-common.postinst
+++ bitlbee-3.5.1/debian/bitlbee-common.postinst
@@ -34,7 +34,9 @@
 	adduser --system --group --disabled-login --disabled-password --home /var/lib/bitlbee/ bitlbee
 fi
 
-chmod 700 /var/lib/bitlbee/
+if [ -d /var/lib/bitlbee ]; then
+chmod 700 /var/lib/bitlbee/
+fi
 
 ## Can't do this in packaging phase: Don't know the UID yet. Access to
 ## the file should be limited, now that it stores passwords. Added
diff -u bitlbee-3.5.1/debian/changelog bitlbee-3.5.1/debian/changelog
--- bitlbee-3.5.1/debian/changelog
+++ bitlbee-3.5.1/debian/changelog
@@ -1,3 +1,11 @@
+bitlbee (3.5.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add existence check to chmod call in bitlbee-common.postinst
+(Closes: #816200).
+
+ -- Sean Whitton   Fri, 25 Jan 2019 16:50:34 -0700
+
 bitlbee (3.5.1-1) unstable; urgency=medium
 
   * Crash bug fix. (Closes: #853282)


signature.asc
Description: PGP signature

Bug#920476: security issue: DoS due to changing # of allowed users in root channel

[Chris Knadle]

Package: mumble
Version: 1.3.0~git20190114.9fcc588+dfsg-1
Severity: serious
Tags: security fixed-upstream pending


A vulnerability has been discovered whereby a remote unauthenticated user
connected to the server can send a crafted packet to change the number of
allowed users in the root channel to 0, thereby disallowing users to connect to
the server and causing a Denial of Service.  All version of mumble-server prior
to the fix in Mumble issue #3586 on 2019-01-25 are affected.

   https://github.com/mumble-voip/mumble/issues/3585

A new upload of mumble is being prepared to fix this issue.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us



signature.asc
Description: OpenPGP digital signature

Bug#920475: console-setup: setupcon man page on caching

[Kevin Ryde]

Package: console-setup
Version: 1.188
Severity: wishlist
File: /usr/share/man/man1/setupcon.1.gz

The setupcon man page DESCRIPTION section could helpfully have a few
words about its caching.  Maybe like, if it's actually true, and perhaps
there's more or better to say,

Keymaps, fonts, etc, for a configuration can be cached in
/etc/console-setup.  The default configuration has this so ready at
boot time.  The "--save" options can do the same for variants, for
say faster switching.  Cached data is regenerated when a
configuration file is newer than the cache.


-- System Information:
Debian Release: buster/sid
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.iso88591, LC_CTYPE=en_AU.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=en_AU:en_GB:en (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages console-setup depends on:
ii  console-setup-linux 1.188
ii  debconf 1.5.69
ii  keyboard-configuration  1.188
ii  xkb-data2.23.1-1

Bug#920462:

[Milan Kostić]

< util_blitter_generate_mipmap: Assertion `!util_format_has_stencil(desc)'
failed.

 I think debian Mesa packages should disable these assertions, that was
disabled before in 18.2.8 and earlier...

 Maybe it is leftover because of Meson build system now, that have
assertions enabled by default, so flag to disable assertions is
-Db_ndebug=true

 "
-Db_ndebug

This option controls assertions in meson projects. When set to false (the
default) assertions are enabled, when set to true they are disabled. This
is unrelated to the buildtype; setting the latter to release will not turn
off assertions.

"

https://www.mesa3d.org/meson.html

Bug#920474: console-setup: setupcon --verbose show ckbcomp run

[Kevin Ryde]

Package: console-setup
Version: 1.188
Severity: wishlist
File: /bin/setupcon

For "setupcon --verbose", it'd be good to see the ckbcomp command run,
since it's where the several options go.  It'd be good to see too the
cache filename it writes, or the cache filename used when still
up-to-date.

For maximum clarity, I think the "." could be omitted from the end of
all of the "executing" messages, to avoid confusion whether dot is part
of the command and args.


-- System Information:
Debian Release: buster/sid
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.iso88591, LC_CTYPE=en_AU.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=en_AU:en_GB:en (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages console-setup depends on:
ii  console-setup-linux 1.188
ii  debconf 1.5.69
ii  keyboard-configuration  1.188
ii  xkb-data2.23.1-1

Bug#817914: developers-reference: globally change "new maintainer" into "new member"

[Holger Levsen]

Moin Holger :)

On Fri, Jan 25, 2019 at 11:59:53PM +0100, Holger Wansing wrote:
> > yes, a patch to fix this would be awesome! Many thanks in advance! :)
> Patch is attached!

wow, that was quick! Many thanks for that!

> In fact, this member/maintainer/developer naming thing is somewhat tricky,

indeed.

> and sometimes it's also irritating IMO (at least for people being new to 
> Debian).

for everyone, I guess, to varying degrees...

> However, this is because the documents have developed over time, so the
> document has probably been written in times where only the developer role
> was existing, and later the maintainer role and then the member role has
> been introduced.

yup

> Therefore, it's of course not possible and also not useful, to substitute
> all "maintainer" into "member" and the like (think about phrases like
> "maintainer script" and "maintainer field in control" and ...), which are
> still correct and will not be renamed into "member script" or "member field".
> 
> This only as a explanation, why not all occurrences of "maintainer" have
> been switched to "member".

I totally agree and I also think you've done a few substituion too many,
see below...

> (Yes, this relativizes the bug title a bit :-) )
> I hope I got it mostly right.

in any case: many thanks for your quick response! let's get this settled
now!

some (quick) comments, stuff I havent commented is fine IMO.

> -Given how easy it is to become a Debian Maintainer, you might want
> +Given how easy it is to become a Debian Member, you might want
>  to only sponsor people who plan to join. 

to become a Maintainer?

> -The process of registering as a developer is a process of verifying your
> +The process of registering as a member is a process of verifying your

... a maintainer?

(maybe then we also need one paragraph explaining that developers are
maintainers too? and developers are members, but members not necessarily
developers nor maintainers? ;)

> -Therefore, we need to verify new maintainers before we can give them accounts
> +Therefore, we need to verify new members before we can give them accounts
>  on our servers and let them upload packages.

not sure if members can get server access. maintainers surely can. maybe
"new developers/maintainers"? (also to answer my own question in the
previous paragraph, maybe be explicit and say
'member/developer/maintainer' if we mean that?

> -Resources for Debian Developers and Debian Maintainers
> +Resources for Debian Members\

see above :)

Even if this seems a bit confusing now I'd hope it was that bad. Have
you seen anything where you would like to rework your patch or do you
think it should rather go in as such?

(once it goes in it will trigger translation updates so we better are
careful...)



-- 
tschüß,
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#920473: console-setup: setupcon re-cache on new remap.inc

[Kevin Ryde]

Package: console-setup
Version: 1.188
Severity: normal
File: /bin/setupcon

On changing /etc/console-setup/remap.inc, and when a cached keymap
exists, running "setupcon" does not apply the new remap.inc.
I hoped it might.

I see setupcon notices its cached keymap should be regenerated when
/etc/default/keyboard is newer.  Could/should it notice remap.inc newer
too, since remap.inc goes into the cache?

I struck this when adding to remap.inc and wanting to apply the result.
I know "loadkeys" can add to the existing, but I wanted also to replace.


-- System Information:
Debian Release: buster/sid
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.iso88591, LC_CTYPE=en_AU.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=en_AU:en_GB:en (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages console-setup depends on:
ii  console-setup-linux 1.188
ii  debconf 1.5.69
ii  keyboard-configuration  1.188
ii  xkb-data2.23.1-1

Bug#920472: gv: hang on geometry bigger than screen

[Kevin Ryde]

Package: gv
Version: 1:3.7.4-1+b1
Severity: normal

If gv is started with a -geometry which is bigger than the vertical
extent of the screen, and with certain -scale,

gv -geometry 600x2000 -scale=1.1 
/usr/share/doc/texlive-doc/latex/tlc2/rosette.ps

then it hangs not drawing the image or widgets and not responding to
window manager close.

It seems to be on any .ps file.  rosette.ps from texlive-lang-english
above is just an example.  The -scale is necessary to provoke the
problem for me.  If omitted or one of the builtins like -scale 2 then
it's ok.

I think this is a regression.  I struck it on a slightly too big
-geometry which I had but which worked before.


-- System Information:
Debian Release: buster/sid
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.iso88591, LC_CTYPE=en_AU.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=en_AU:en_GB:en (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gv depends on:
ii  ghostscript-x  9.26~dfsg-2
ii  libc6  2.28-5
ii  libx11-6   2:1.6.7-1
ii  libxinerama1   2:1.1.4-1
ii  libxmu62:1.1.2-2
ii  libxt6 1:1.1.5-1
ii  xaw3dg 1.5+E-18.3

Versions of packages gv recommends:
ii  xaw3dg  1.5+E-18.3

gv suggests no packages.

-- no debconf information

Bug#920470: /usr/bin/mergechanges: mergechanges: needs to merge Binary field for dpkg (>= 1.19.3)

[Mattia Rizzolo]

user devscri...@packages.debian.org
usertag 920470 mergechanges
thanks

FTR, the same needs to be done for the Description field.

On Sat, Jan 26, 2019 at 12:03 AM Simon McVittie  wrote:
>
> Package: devscripts
> Version: 2.19.2
> Severity: important
> File: /usr/bin/mergechanges
>
> dpkg 1.19.3 only populates the Binary field with the binaries that are
> actually being uploaded:
> https://salsa.debian.org/dpkg-team/dpkg/commit/4a4619831de8b8972f86b489660dc98f187cfa34.patch
>
> This means that the Binary field in a merged changes file needs to become the
> union of the Binary fields of the individual changes files. At the moment the
> first changes file's Binary field is used, leading to an incomplete list.
>
> It would probably be a good idea for mergechanges to insist that every
> field, except for the ones that it special-cases like Architecture and
> Files (and Binary after this bug is fixed), is identical in all the
> individual changes files. However, that would likely require a rewrite
> in Perl or Python.

-- 
regards,
Mattia Rizzolo

GPG Key: 4096R/B9444540 http://goo.gl/I8TMB
more about me: http://mapreri.org
Launchpad User: https://launchpad.net/~mapreri
Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo

Bug#919540: Fwd: Re: Fwd: blastem_0.6.1-1_amd64.changes is NEW

[Carlos Donizete Froes]

 Original Message 
Subject: Re: Fwd: blastem_0.6.1-1_amd64.changes is NEW
Date: 24-01-2019 20:16
From: Mike Pavone 
To: Carlos Donizete Froes 

> On January 24, 2019 at 1:50 PM Carlos Donizete Froes
>  wrote:
> 
> Hi Mike,
> 
>> By the way, I got those changes we discussed into the upstream repo
>> last night. To build with the
>> host system's zlib, config file in /etc/blastem and other files in
>> /usr/share/games/blastem you
>> would invoke make like so:
>> 
>> make HOST_ZLIB=1 CONFIG_PATH=/etc/blastem
>> DATA_PATH=/usr/share/games/blastem
>> 
>> If built with those settings, it will expect default.cfg to be in
>> /etc/blastem, it will expect
>> rom.db and gamecontrollerdb.txt to be in /usr/share/games/blastem
>> and it will expect shaders to be
>> in /usr/share/games/blastem/shaders
>> 
>> Let me know if that works for your needs.
> 
> It worked perfectly with these changes you made in your software. :)

Glad to hear it

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

Bug#920471: RFS: fathom/1.0+git.20190120.0439ca-1

[Jose G. López]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "fathom":

* Package name: fathom
  Version : 1.0+git.20190120.0439ca-1
  Upstream Author : Jon Dart
* URL : https://github.com/jdart1/Fathom
* License : MIT
  Section : libs

It builds those binary packages:

 fathom - Command-line for probing Syzygy tablebases
 libfathom-dev - Library for probing Syzygy tablebases (development files)
 libfathom1 - Library for probing Syzygy tablebases

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/fathom/fathom_1.0+git.20190120.0439ca-1.dsc

Package development is on the following repo:

https://salsa.debian.org/josgalo-guest/fathom

Changes since the last upload:

fathom (1.0+git.20190120.0439ca-1) unstable; urgency=medium

  * debian/control:
- Use debhelper compat version 12.
- Change maintainer's e-mail and upstream homepage.
  * debian/copyright:
- Update url source, copyright notices and my e-mail.
  * debian/rules:
- Add -I option to find headers.
  * debian/watch:
- Change upstream git repo.
  Use Jon Dart's fork. It has some bug fixes and enhancements.

 -- Jose G. López   Fri, 25 Jan 2019 20:39:28 +0100

Using Jon Dart's fork as it has some bug fixes and enhancements.
It has a fix for compiling on 32 bits archs.

Hope this version fix these building errors:
https://buildd.debian.org/status/package.php?p=fathom

Thanks and regards,


pgp58O20LdJkW.pgp
Description: PGP signature

Bug#919540: Fwd: Re: BlastEm for the Debian project

[Carlos Donizete Froes]

Hi,

Please follow the email contacts I had with the upstream.

Thanks!

 Original Message 
Subject: Re: BlastEm for the Debian project
Date: 18-06-2018 05:00
From: Mike Pavone 
To: Carlos Donizete Froes 

Hi Carlos


On 06/17/2018 08:34 PM, Carlos Donizete Froes wrote:
> Hi Michael,
>
> My name is Carlos, but known by the GNU/Linux communities as "coringao".
>
> I am a volunteer in the Debian packaging side, and I was very interested in 
> its
> development with the "BlastEm" emulator.
>
> I am willing to upload the debian package of this emulator, where it will 
> have a
> bigger showcase for the users of the Debian/Ubuntu/GNU/Linux based
> distributions.
That would be great
>
> I downloaded the source file on your site and put it in my GitLab account[1] 
> to
> make some simple fixes before doing the Debian packaging.
>
> [1] https://gitlab.com/coringao/blastem
I see you started from the stable release tarball. There is a pubic repo
here: https://www.retrodev.com/repos/blastem (it was down earlier today
due to an ill-timed server upgrade, but is back now). I realize
Mercurial is a bit unfashionable these days, but I believe there is a
bridge that allows git to interop with it. Pulling from the public repo
will make it easier for me to accept your changes upstream. Assuming
that's what you want anyway.

That said, I took a quick peek at some of your commits and some of them
look questionable. For instance this one:
https://gitlab.com/coringao/blastem/commit/3b201d6826be36d8f5ab37e1e979c0e3b875c4f0

arg_arr is indeed leaked in that function, but that change won't fix the
leak and will instead break the function. I've fixed it upstream (thanks
for bringing it to my attention), but I'm a little concerned about how
you're going about these.
>
> And I'd like you to follow this project and get better when you can before
> launch.
I think something may have gotten lost in translation here and I don't
understand what you're trying to say. Could you try rephrasing that?

Mike

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

Bug#919540: Fwd: Re: BlastEm for the official Debian/Ubuntu repository

[Carlos Donizete Froes]

 Original Message 
Subject: Re: BlastEm for the official Debian/Ubuntu repository
Date: 21-01-2019 16:36
From: Mike Pavone 
To: Carlos Donizete Froes 

Hi Carlos

> On January 19, 2019 at 8:21 PM Carlos Donizete Froes
>  wrote:
> 
> But in my 'BlastEm' package I noticed that the binary searches for
> 'config' in 2 different places:
> 
> * /usr/games/default.cfg
> * /home/$USER/.config/blastem/blastem.cfg
> 
> Being that the correct one would be that the binary looked for in:
> 
> * /usr/share/games/blastem/default.cfg
> 
> Is it possible to modify this root directory?

Note that the second directory BlastEm checks for is standard for a
per-user config, it's just the location of default.cfg that is not
standard. I can provide a Makefile option to change where it looks for
the default config file. That said, wouldn't /etc/blastem be a more
appropriate location for the system-wide default config?

There are probably some other files that should be moved to
/usr/share/blastem (at least on my system, /usr/share/games does not
exit and things that have executables in /usr/games just use /usr/share)
for a packaged version like the shaders and rom.db. I can make a change
to support this as well.

Another change that would probably make sense for packaging is to use
the system zlib rather than the copy I've included in the repo. I can
add an option for that as well.

Speaking of zlib, I see you attempted to fix a memory leak in the
bundled zlib source code. Regretfully, this change breaks the function
in question (gzdopen). It doesn't really matter for BlastEm since I
don't actually use that function, but it might be better if you leave
fixes of that nature to me. You can't just try to fix stuff reported by
some static analysis tool without some understanding of the code you're
changing.

Mike

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

Bug#919540: Fwd: Re: Fwd: blastem_0.6.1-1_amd64.changes is NEW

[Carlos Donizete Froes]

 Original Message 
Subject: Re: Fwd: blastem_0.6.1-1_amd64.changes is NEW
Date: 23-01-2019 17:58
From: Mike Pavone 
To: Carlos Donizete Froes 

> On January 23, 2019 at 6:20 AM Carlos Donizete Froes
>  wrote:
> 
> Hi Mike,
> 
> Follow the BlastEm overview in Debian NEW
> 
> https://ftp-master.debian.org/new/blastem_0.6.1-1.html

Cool stuff.

By the way, I got those changes we discussed into the upstream repo last
night. To build with the host system's zlib, config file in /etc/blastem
and other files in /usr/share/games/blastem you would invoke make like
so:

make HOST_ZLIB=1 CONFIG_PATH=/etc/blastem
DATA_PATH=/usr/share/games/blastem

If built with those settings, it will expect default.cfg to be in
/etc/blastem, it will expect rom.db and gamecontrollerdb.txt to be in
/usr/share/games/blastem and it will expect shaders to be in
/usr/share/games/blastem/shaders

Let me know if that works for your needs.

Mike

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

Bug#919540: Fwd: Re: BlastEm for the official Debian/Ubuntu repository

[Carlos Donizete Froes]

 Original Message 
Subject: Re: BlastEm for the official Debian/Ubuntu repository
Date: 22-01-2019 05:28
From: Mike Pavone 
To: Carlos Donizete Froes 

Hi Carlos,


On 01/21/2019 07:10 PM, Carlos Donizete Froes wrote:
> By default, public executables are installed in '/usr/games/' and arch 
> independent files are
> installed in '/usr/share/games//'.
Ah you're right, I got confused because of things like docs/manpages and
desktop entries not being in /usr/share/games, but those are obviously a
different sort of thing. Sorry

> I'm sorry, it was a bad thing on my part to try and fix something to try to 
> generate the Debian
> package. I should have communicated this to you first. :(
>
> If you have the time, you could make these changes to my GitLab account (
> https://gitlab.com/coringao/blastem).
I'm happy to make changes in my upstream repo to support packaging, but
I'm not going to commit to some git clone of my repo. Hopefully, you can
pull the changes down with whatever git-hg bridge you are using (and if
you can't, I think that's going to be a problem going forward).

> I will redo the packaging in version 0.6.1.1 or 0.6.2, but unfortunately I 
> believe this package will
> not be in this next version of Debian 10 (buster) because it has started 
> freezing and new
> transitions and big/disruptive changes are no longer acceptable.
Fair enough
> But there is time for the package to be in the next version of Ubuntu 19.04.
Cool

Mike

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀  2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

Bug#817914: developers-reference: globally change "new maintainer" into "new member"

[Holger Wansing]

Moin,

Holger Levsen  wrote:
> Hi Holger,
> 
> yes, a patch to fix this would be awesome! Many thanks in advance! :)

Patch is attached!

In fact, this member/maintainer/developer naming thing is somewhat tricky,
and sometimes it's also irritating IMO (at least for people being new to 
Debian).

However, this is because the documents have developed over time, so the
document has probably been written in times where only the developer role
was existing, and later the maintainer role and then the member role has
been introduced.

Therefore, it's of course not possible and also not useful, to substitute
all "maintainer" into "member" and the like (think about phrases like
"maintainer script" and "maintainer field in control" and ...), which are
still correct and will not be renamed into "member script" or "member field".

This only as a explanation, why not all occurrences of "maintainer" have
been switched to "member".
(Yes, this relativizes the bug title a bit :-) )
I hope I got it mostly right.


Regards
Holger




-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/beyond-pkging.dbk b/beyond-pkging.dbk
index 5051bef..bead81e 100644
--- a/beyond-pkging.dbk
+++ b/beyond-pkging.dbk
@@ -386,7 +386,7 @@ to learn them?
 
 It's also a good idea to know where they stand with respect to Debian: do
 they agree with Debian's philosophy and do they intend to join Debian?
-Given how easy it is to become a Debian Maintainer, you might want
+Given how easy it is to become a Debian Member, you might want
 to only sponsor people who plan to join. That way you know from the start
 that you won't have to act as a sponsor indefinitely.
 
diff --git a/new-maintainer.dbk b/new-maintainer.dbk
index 50392a1..6228dc5 100644
--- a/new-maintainer.dbk
+++ b/new-maintainer.dbk
@@ -4,7 +4,7 @@
%commondata;
 ]>
 
-Applying to Become a Maintainer
+Applying to Become a Member
 
 Getting started
 
@@ -75,7 +75,7 @@ that list and an experienced developer will volunteer to help.
 
 
 In addition, if you have some packages ready for inclusion in Debian, but are
-waiting for your new maintainer application to go through, you might be able
+waiting for your new member application to go through, you might be able
 find a sponsor to upload your package for you.  Sponsors are people who are
 official Debian Developers, and who are willing to criticize and upload your
 packages for you. Please read the debian-mentors FAQ at 
 
 
-Registering as a Debian developer
+Registering as a Debian member
 
 Before you decide to register with &debian-formal;, you will
 need to read all the information available at the New Members Corner.  It
 describes in detail the preparations you have to do before you can register to
-become a Debian developer.  For example, before you apply, you have to read the
+become a Debian member.  For example, before you apply, you have to read the
 Debian Social
-Contract.  Registering as a developer means that you agree with and
+Contract.  Registering as a member means that you agree with and
 pledge to uphold the Debian Social Contract; it is very important that
-maintainers are in accord with the essential ideas behind
+member are in accord with the essential ideas behind
 &debian-formal;.  Reading the GNU Manifesto would also be
 a good idea.
 
 
-The process of registering as a developer is a process of verifying your
+The process of registering as a member is a process of verifying your
 identity and intentions, and checking your technical skills.  As the number of
 people working on &debian-formal; has grown to over
 &number-of-maintainers; and our systems are used in several
 very important places, we have to be careful about being compromised.
-Therefore, we need to verify new maintainers before we can give them accounts
+Therefore, we need to verify new members before we can give them accounts
 on our servers and let them upload packages.
 
 
@@ -193,7 +193,7 @@ cryptography even for authentication is forbidden then please contact us so we
 can make special arrangements.
 
 
-To apply as a new maintainer, you need an existing Debian Developer to support
+To apply as a new member, you need an existing Debian Developer to support
 your application (an advocate).  After you have
 contributed to Debian for a while, and you want to apply to become a registered
 developer, an existing developer with whom you have worked over the past months
@@ -206,14 +206,14 @@ register on our application
 page.  After you have signed up, your advocate has to confirm your
 application.  When your advocate has completed this step you will be assigned
 an Application Manager who will go with you through the necessary steps of the
-New Maintainer process.  You can always check your status on the applications status board.
 
 
 For more details, please consult New Members Corner at the
 Debian web site.  Make sure that you are familiar with the necessary steps of
-the New Maintainer process b

Bug#920470: /usr/bin/mergechanges: mergechanges: needs to merge Binary field for dpkg (>= 1.19.3)

[Simon McVittie]

Package: devscripts
Version: 2.19.2
Severity: important
File: /usr/bin/mergechanges

dpkg 1.19.3 only populates the Binary field with the binaries that are
actually being uploaded:
https://salsa.debian.org/dpkg-team/dpkg/commit/4a4619831de8b8972f86b489660dc98f187cfa34.patch

This means that the Binary field in a merged changes file needs to become the
union of the Binary fields of the individual changes files. At the moment the
first changes file's Binary field is used, leading to an incomplete list.

It would probably be a good idea for mergechanges to insist that every
field, except for the ones that it special-cases like Architecture and
Files (and Binary after this bug is fixed), is identical in all the
individual changes files. However, that would likely require a rewrite
in Perl or Python.

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.4
ii  fakeroot  1.23-1
ii  file  1:5.35-2
ii  gnupg 2.2.12-1
ii  gpgv  2.2.12-1
ii  libc6 2.28-5
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-1
ii  patchutils0.3.4-2
ii  perl  5.28.1-3
ii  pseudo [fakeroot] 1.9.0+git20180920-1
ii  python3   3.7.2-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.0~beta1
ii  at  3.1.23-1
ii  curl7.63.0-1
ii  dctrl-tools 2.24-3
ii  debian-keyring  2018.12.24
ii  dput1.0.3
ii  equivs  2.2.0
ii  libdistro-info-perl 0.20
ii  libdpkg-perl1.19.4
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.15-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.5.124
ii  man-db  2.8.5-1
ii  patch   2.7.6-3
ii  python3-apt 1.7.0
ii  python3-debian  0.1.34
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.20.0-2
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-4
ii  strace  4.26-0.2
ii  unzip   6.0-21
ii  wget1.20.1-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
ii  adequate  0.15.1
ii  autopkgtest   5.8
pn  bls-standalone
ii  bsd-mailx [mailx] 8.1.2-0.20180807cvs-1
ii  build-essential   12.5
ii  check-all-the-things  2017.05.20
pn  cvs-buildpackage  
ii  debhelper 12
pn  devscripts-el 
ii  diffoscope108
pn  disorderfs
pn  dose-extra
pn  duck  
ii  faketime  0.9.7-3
ii  gnuplot   5.2.6+dfsg1-1
ii  gnuplot-x11 [gnuplot] 5.2.6+dfsg1-1
ii  how-can-i-help16
ii  libauthen-sasl-perl   2.1600-1
pn  libdbd-pg-perl
ii  libfile-desktopentry-perl 0.22-1
pn  libnet-smtps-perl 
pn  libterm-size-perl 
ii  libtimedate-perl  2.3000-2
ii  libyaml-syck-perl 1.31-1+b1
ii  mozilla-devscripts0.53
ii  mutt  1.10.1-2
ii  openssh-client [ssh-client]   1:7.9p1-5
ii  piuparts  0.96
ii  postgresql-client 11+198
ii  postgresql-client-11 [postgresql-client]  11.1-2
ii  quilt   

Bug#920469: lintian: "internal error: Cannot add another buildinfo file" after mergechanges

[Simon McVittie]

Package: lintian
Version: 2.5.124
Severity: normal

Steps to reproduce:
* Have a source package producing a mixture of architecture-specific and
  architecture-independent packages (I used xdg-desktop-portal)
* Run sbuild twice to produce _amd64 and _all packages, separately
* mergechanges xdg-desktop-portal_*.changes > merged.changes
* for x in *.changes; do echo $x; lintian $x; done

Expected result:
* Normal lintian output for each changes file

Actual result:
Skipping merged.changes: internal error: Cannot add another buildinfo file at 
/usr/share/perl5/Lintian/ProcessableGroup.pm line 175.

I think mergechanges is correct to keep all the buildinfo from the builds
that I'm combining.

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

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

Versions of packages lintian depends on:
ii  binutils   2.31.1-11
ii  bzip2  1.0.6-9
ii  diffstat   1.62-1
ii  dpkg   1.19.4
ii  dpkg-dev   1.19.4
ii  file   1:5.35-2
ii  gettext0.19.8.1-9
ii  gpg2.2.12-1
ii  intltool-debian0.35.0+20060710.5
ii  libapt-pkg-perl0.1.34+b1
ii  libarchive-zip-perl1.64-1
ii  libcgi-pm-perl 4.40-1
ii  libclass-accessor-perl 0.51-1
ii  libclone-perl  0.41-1+b1
pn  libdigest-sha-perl 
ii  libdpkg-perl   1.19.4
ii  libemail-valid-perl1.202-1
ii  libfile-basedir-perl   0.08-1
ii  libio-async-perl   0.72-1
ii  libipc-run-perl20180523.0-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  libparse-debianchangelog-perl  1.2.0-13
ii  libtext-levenshtein-perl   0.13-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.76-1
ii  libxml-simple-perl 2.25-1
ii  libyaml-libyaml-perl   0.76+repack-1
ii  man-db 2.8.5-1
ii  patchutils 0.3.4-2
ii  perl   5.28.1-3
ii  t1utils1.41-3
ii  xz-utils   5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
ii  binutils-multiarch 2.31.1-11
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.54-1

-- no debconf information

Bug#920460: nautilus: org.freedesktop.FileManager1.service conflict

[Jason Crain]

On Fri, Jan 25, 2019 at 09:01:54PM +0100, Yves-Alexis Perez wrote:
> this is a “preemptive” bug about a future file conflict. Latest Thunar
> upstream version (1.8.3) gained support for the
> org.freedesktop.FileManager1 DBus name
> (https://bugzilla.xfce.org/show_bug.cgi?id=12414). 

Funny, org.freedesktop.FileManager1 was just mentioned earlier today on
GNOME's #gnome-hackers IRC channel.

My understanding of how this service name was originally used is that
the desktop environment automatically started its file manager when the
desktop session began, possibly so it could manage the desktop icons and
background, and the file manager registered the
org.freedesktop.FileManager1 name. Then, if any program sends a message
to FileManager1, they'll get the one started by the desktop environment.
But current GNOME doesn't start nautilus on session start, so if you
have multiple desktop environments installed and send a message to
FileManager1, D-Bus activation starts a file manager and it's
unpredictable which one it will run.

This issue was discussed a while ago in a Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860796#56. smcv's
comment in that bug includes some suggestions. To fix the file conflict,
probably no file manager should install the
org.freedesktop.FileManager1.service file. To fix the service name
conflict, he mentions the posibility of modifying the service file
specification so that a service can declare that it implements the
org.freedesktop.FileManager1 service under a certain DE.

Alternatively, when a DE starts up, it could grab the FileManager1 name
so any requests will be forwarded to the correct file manager for that
desktop, instead of relying on D-Bus activation.

Bug#488707: ps4pdf.sty missing

[Hilmar Preuße]

On 30.06.08 21:21, Thomas Viehmann wrote:

Hi,

Are you the one how submitted https://bugs.debian.org/488707 ?

> For some reason (I've not found it in the list of removed stuff)
> ps4pdf.sty is missingl, it used to be in this package in etch.
> If it is not for license reasons, could you reinclude it?
> While the CTAN page says it's obsolete, it seems to be the only at least
> half-documented option to use ps stuff in pdflatex and is bound to be
> used in legacy documents.
> 
We got the answer that it has been replaced by pst-pdf. The script
ps4pdf now refers to pst-pdf:

hille@sid:~ $ ps4pdf --help
/usr/bin/ps4pdf [-v|-q|--crop|--version|--Xps2pdf OPT] FILE
Process LaTeX document FILE using the pst-pdf package,
including running latex, dvips, and ps2pdf as necessary.
--Xps2pdf OPT passes OPT to ps2pdf.
 (-dAutoRotatePages=/None is always passed.)
--crop runs pdfcrop on ps2pdf output.
--lualatex using the luatex engine for .dvi and .pdf
--xelatex using the xetex engine for .xdv and .pdf

Is this sufficient for you? Is is OK to close that bug?

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



signature.asc
Description: OpenPGP digital signature

Bug#914615: closed by Mechtilde Stehmann (reply to mechti...@debian.org) (914615-d...@bugs.debian.org)

[Jeremy Bicha]

On Fri, Jan 25, 2019 at 1:51 PM Debian Bug Tracking System
 wrote:
> From: Mechtilde Stehmann 
> notfixed - This won't fixed in Debian.

Why?

Thanks,
Jeremy Bicha

Bug#488707: ps4pdf.sty missing

[Hilmar Preuße]

On 30.06.08 21:21, Thomas Viehmann wrote:

Hi,

> For some reason (I've not found it in the list of removed stuff)
> ps4pdf.sty is missingl, it used to be in this package in etch.
> If it is not for license reasons, could you reinclude it?
> While the CTAN page says it's obsolete, it seems to be the only at least
> half-documented option to use ps stuff in pdflatex and is bound to be
> used in legacy documents.
> 
We got the answer that it has been replaced by pst-pdf. The script
ps4pdf now refers to pst-pdf:

hille@sid:~ $ ps4pdf --help
/usr/bin/ps4pdf [-v|-q|--crop|--version|--Xps2pdf OPT] FILE
Process LaTeX document FILE using the pst-pdf package,
including running latex, dvips, and ps2pdf as necessary.
--Xps2pdf OPT passes OPT to ps2pdf.
 (-dAutoRotatePages=/None is always passed.)
--crop runs pdfcrop on ps2pdf output.
--lualatex using the luatex engine for .dvi and .pdf
--xelatex using the xetex engine for .xdv and .pdf

Is this sufficient for you? Is is OK to close that bug?

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



signature.asc
Description: OpenPGP digital signature

Bug#920433: RFS: wiggle/1.1-1 [QA]

[Dmitry Bogatov]

[2019-01-25 22:45] Carlos Maddela 
> Package: sponsorship-requests
> Severity: normal
>
>   Dear mentors,
>
>   I am looking for a sponsor for my package "wiggle"
>
>  * Package name: wiggle
>Version : 1.1-1
>Upstream Author : Neil Brown 
>  * URL : https://neil.brown.name/wiggle
>  * License : GPL-2+
>Section : vcs
>
>   It builds this binary package:
>
> wiggle - apply patches with conflicting changes
>
>   To access further information about this package, please visit the 
> following URL:
>
>   https://mentors.debian.net/package/wiggle
>
>
>   Alternatively, one can download the package with dget using this command:
>
> dget -x 
> https://mentors.debian.net/debian/pool/main/w/wiggle/wiggle_1.1-1.dsc

Uploaded. Thank you for your contribution.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#919773: RFH: libdbd-sqlite3-perl / #919773

[gregor herrmann]

Hi mips porters,

we have a test failure of libdbd-sqlite3-perl on mips only: #919773
and neither the perl team nor upstream [0] were successful so far.
Maybe someone with mips knowdledge could take a look?

Cheers,
gregor

[0] https://github.com/DBD-SQLite/DBD-SQLite/issues/45

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


signature.asc
Description: Digital Signature

Bug#218557: dies with "Cannot find node `Top'"

[Hilmar Preuße]

On 01.11.03 06:36, John R Lenton wrote:

Hi all,

> Package: info
> Version: 4.6-1
> Severity: important
> Tags: sid
> 
> fwiw, strace attached.
> 
We did not really a move forward in this bug in the last 15 years. We
discussed the topic, if info needs to be able to process a corrupt dir
file. Further we noticed that install-info needs to be more robust and
is Debian specific.
As of 5.2.0.dfsg.1-4 install-info is the one from upstream.

Is anybody of you still able to reproduce the problem or should we close
the issue instead?

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



signature.asc
Description: OpenPGP digital signature

Bug#920468: node-libnpx accesses the network at build-time

[Steve Langasek]

Package: node-libnpx
Version: 10.2.0-2
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Pirate,

In Ubuntu, the node-libnpx has failed to build because it tries to access
the network in order to download test dependencies:

[...]
# Subtest: test/index.js
# Subtest: npx --always-spawn
not ok 1 - Command failed: node /<>/test/util/npx-bin.js 
--always-spawn echo-cli hewwo
  ---
  stack: |
ChildProcess.child.on.code (child.js:41:21)
  at:
line: 41
column: 21
file: child.js
function: ChildProcess.child.on.code
  isOperational: true
  stderr: >
npm ERR! code ENOTFOUND
  
npm ERR! errno ENOTFOUND
  
npm ERR! network request to https://registry.npmjs.org/echo-cli 
failed,
reason: getaddrinfo ENOTFOUND registry.npmjs.org 
registry.npmjs.org:443
  
npm ERR! network This is a problem related to network connectivity.
[...]
   # Subtest: npx with custom installer stdio
not ok 1 - Command failed: node 
/<>/test/util/npx-bin-inherit-stdio.js say-shalom@1.2.7
  ---
  stack: |
ChildProcess.child.on.code (child.js:41:21)
  at:
line: 41
column: 21
file: child.js
function: ChildProcess.child.on.code
  isOperational: true
  stderr: >
npm ERR! code ENOTFOUND
  
npm ERR! errno ENOTFOUND
  
npm ERR! network request to https://registry.npmjs.org/say-shalom 
failed,
reason: getaddrinfo ENOTFOUND registry.npmjs.org 
registry.npmjs.org:443
  
npm ERR! network This is a problem related to network connectivity.
[...]

(https://launchpad.net/ubuntu/+source/node-libnpx/10.2.0-2/+build/15638838)

Packages should not be accessing sites on the Internet at build time.  Since
I can't find either echo-cli or say-shalom as a package in Debian, I think
the right solution here is to disable these tests.

Please find attached a patch which does this.  I have uploaded this patch to
Ubuntu.

Regards,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru node-libnpx-10.2.0/debian/patches/disable-network-test.patch 
node-libnpx-10.2.0/debian/patches/disable-network-test.patch
--- node-libnpx-10.2.0/debian/patches/disable-network-test.patch
1969-12-31 16:00:00.0 -0800
+++ node-libnpx-10.2.0/debian/patches/disable-network-test.patch
2019-01-25 14:26:43.0 -0800
@@ -0,0 +1,73 @@
+Description: Disable tests that require network access
+ Tests in this package require access to https://registry.npmjs.org/echo-cli
+ and https://registry.npmjs.org/say-shalom at build time.  Disable these
+ tests, since NPM is inaccessible at build time per policy.
+Author: Steve Langasek 
+Last-Modified: 2018-01-25
+
+Index: node-libnpx-10.2.0/test/index.js
+===
+--- node-libnpx-10.2.0.orig/test/index.js
 node-libnpx-10.2.0/test/index.js
+@@ -16,39 +16,6 @@
+ 
+ const NPX_ESC = isWindows ? child.escapeArg(NPX_PATH) : NPX_PATH
+ 
+-test('npx --always-spawn', t => {
+-  return child.spawn('node', [
+-NPX_ESC, '--always-spawn', 'echo-cli', 'hewwo'
+-  ], {stdio: 'pipe'}).then(res => {
+-t.equal(res.stdout.trim(), 'hewwo')
+-  })
+-})
+-
+-test('npx --always-spawn resolves promise after command is executed', t => {
+-  const _runCommand = child.runCommand
+-  const parsed = main.parseArgs([
+-process.argv[0],
+-'[fake arg]',
+-'--always-spawn',
+-'echo-cli',
+-'hewwo'
+-  ], NPM_PATH)
+-  child.runCommand = (command, opts) => {
+-child.runCommand = _runCommand
+-return Promise.resolve([command, opts])
+-  }
+-  return main(parsed)
+-.then(args => {
+-  const command = args[0]
+-  const opts = args[1]
+-  t.ok(command.includes('node'), 'node executes the command')
+-  t.equal(opts.alwaysSpawn, true, 'set opts.alwaysSpawn')
+-  t.equal(opts.command, 'echo-cli', 'set opts.command')
+-  t.ok(opts.cmdOpts[0].includes('echo-cli'), 'set opts.cmdOpts[0]')
+-  t.equal(opts.cmdOpts[1], 'hewwo', 'set opts.cmdOpts[1]')
+-})
+-})
+-
+ test('npx --shell-auto-fallback', t => {
+   return child.spawn('node', [
+ NPX_ESC, '--shell-auto-fallback', 'zsh'
+@@ -293,21 +260,6 @@
+   })
+ })
+ 
+-test('npx with custom installer stdio', t => {
+-  const NPX_PATH = path.resolve(__dirname, 'util', 'npx-bin-inherit-stdio.js')
+-  const NPX_ESC = isWindows ? child.escapeArg(NPX_PATH) : NPX_PATH
+-
+-  return child.spawn('node', [
+-

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

[Trek]

On Thu, 24 Jan 2019 19:02:54 -0800
Bill Brelsford  wrote:

> Thanks for the build instructions, Trek.  However, dpkg-buildpackage
> fails (at test-condition, line 4259 in attached trace file).

to workaround these @#!%^&* tests, you should go in the systemd-240
directory and type as user:

  sed -i 's/\(main(.*) {\)/\1 return 0;/' src/test/test-*.c

then try again to rebuild:

  dpkg-buildpackage -b -uc -us


I hope it will work fine this time!
ciao

Bug#920467: ngraph-gtk: fails at runtime on 32-bit archs

[Steve Langasek]

Source: ngraph-gtk
Version: 6.08.00-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco

Dear maintainers,

Since the upgrade to 6.08.00, ngraph-gtk has been failing its autopkgtests
in Ubuntu on 32-bit architectures (i386 and armhf):

[...]

autopkgtest [00:39:34]: test run-test: [---

(ngraph:2067): dbind-WARNING **: 00:39:37.513: Error retrieving accessibility 
bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus 
was not provided by any .service files
*** stack smashing detected ***:  terminated
Aborted (core dumped)
autopkgtest [00:39:40]: test run-test: ---]
autopkgtest [00:39:43]: test run-test:  - - - - - - - - - - results - - - - - - 
- - - -
run-test FAIL non-zero exit status 134

[...]

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/armhf/n/ngraph-gtk/20181211_004020_9e1b2@/log.gz

This hasn't been reported on the Debian infrastructure because Debian only
regularly runs autopkgtests for the amd64 architecture; however, I can
confirm that the autopkgtests fail the same way if run against the Debian
binaries.  It appears to me that this means the ngraph-gtk package is broken
at runtime on these architectures, so I'm filing this bug at severity
serious.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#918120: ITP: bpftrace -- high-level tracing language for Linux eBPF

[Michael Prokop]

Hi!

* Vincent Bernat [Thu Jan 03, 2019 at 03:58:07PM +0100]:

> * Package name: bpftrace
>   Version : git
>   Upstream Author : IO Visor Project
> * URL : https://github.com/iovisor/bpftrace
> * License : Apache 2
>   Programming Lang: C++
>   Description : high-level tracing language for Linux eBPF

[...]

> The copyright assignment is currently not precise enough. Original
> author is Previously, Alastair Robertson.

Has this been sorted out in the meanwhile?
Or put differently, any news regarding the bpftrace package,
would be great to have it available in/with buster!

regards,
-mika-


signature.asc
Description: Digital signature

Bug#920466: mldonkey-server: Init script fails to stop daemon properly

[Sunil Mohan Adapa]

Package: mldonkey-server
Version: 3.1.6-1+b1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

As part of adding mldonkey into FreedomBox, we noticed that the mldonkey-server
does not stop properly. This is because start-stop-daemon is asked to stop
based only on the PID file which is owned by non-root user. Making the process
match more specific fixes the problem.

# start-stop-daemon --stop --pidfile /var/run/mldonkey/mlnet.pid
start-stop-daemon: matching only on non-root pidfile
/var/run/mldonkey/mlnet.pid is insecure
# echo $?
2
# start-stop-daemon --stop --pidfile /var/run/mldonkey/mlnet.pid --exec
/usr/bin/mlnet
# echo $?
0

I have created a merge request to fix the issue. Tagging this issue with
'patch'.

https://salsa.debian.org/ocaml-team/mldonkey/merge_requests/1

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

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

Versions of packages mldonkey-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.70
ii  libbz2-1.0 1.0.6-9
ii  libc6  2.28-5
ii  libgcc11:8.2.0-14
ii  libgd3 2.2.5-5
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libpng16-161.6.36-2
ii  libstdc++6 8.2.0-14
ii  lsb-base   10.2018112800
ii  mime-support   3.61
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

mldonkey-server recommends no packages.




-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAlxLhiMRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfK/1w/9H/vFfCW/N7EM1DkzWkHoNzKtaW/Xn0Ih
rJzb7fUyq3LFBexILTMHvgz8d/hPoRFuktgY2Thvq8E546bRB4oYfStXfFO+njXd
LkMKEPhyKqTgOfRjCMKVr7QUtBpYN5XBze99esEhIGzg9Al/vZXyBxtz4voFJ2LL
R0p/0FlWCT6fXsy3z0T5Mfm0jV4IyC42bh/1MemzR7ATmvc6mL9/TMXV3vZEdX2A
OMu+XRkJhown5vQVeC32hfJWreb5J93urVPdHXltXZb5tJjvx9X3tfNAK3i/EEx+
5aXktK4/TP8BAj/A2uJ6yxf4vE5HFPxrca8ZrX4qcjstHuaB/yGCru2oWaUzkBD5
0RFn5HOtwXI8NXVP6zTIimVQqkoXzeY8SQsSQBToWkxjJchXQ0u9EiijdZM5nDNJ
qfJVp/qk6okK9MerP2sNwtHAWyxgOa5iqFrifITmLoJfZrmtkkg4VRs1eYpCGHr9
v9E2wCsKfRp2V/tKzASbxk6Oc7P7iEBWMmQTAmuSmK84k2VvQTwjMy+OCOOeIue5
Gqdwz1+BgpIF4baRgIalYIu9iGHfQBErfY3GLgcdjJx+ketfqZHw3VTlLjCipfUt
D/ppP5q4FlHnlb5OraNakVwei1Bdn2wK7UnevjqGcMMYRm5m1YkK3Ci3gUnwz4zv
Ruln29zlUD8=
=5KnO
-END PGP SIGNATURE-

Bug#914984: texdoc: off-by-one error with -l

[Hilmar Preuße]

On 29.11.18 11:06, Julian Gilbey wrote:

Hi Julian,

> texdoc -l number
> reports:
> 44 results.  Display them all? (y/N)
> but then only lists 43 results. Either the displayed count is wrong or
> the final result is not being displayed.
> 
Are you still able to reproduce the issue? Upstream says, the issue has
been solved, but what I see is e.g.:

hille@sid:~ $ texdoc --list nu
316 results.  Display them all? (y/N)

...and then 202 documents are listed.

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



signature.asc
Description: OpenPGP digital signature

Bug#915856: sphinx: Failed cross building with Build-Depends on python3-sphinx

[Dmitry Shachnev]

On Fri, Jan 25, 2019 at 05:41:56PM +0100, Helmut Grohne wrote:
> Hi Dmitry,
>
> On Fri, Jan 25, 2019 at 11:14:23AM +0300, Dmitry Shachnev wrote:
> > Does this mean that packages that are not using autodoc (like ncmpc) can
> > already build-depend on python3-sphinx:native to become cross-buildable?
>
> Yes, that is my understanding. My plan was postponing such patches to
> simplify stretch-backports. I'm not opposed to them in general, I just
> didn't want to cause unnecessary work.

@Kaliko: please test if it works for you.

> > Does cmake sound like a good start? It already has docs in a separate
> > package, just needs the B-D adjusted.
>
> Yes, cmake is on the list above precisely due to sphinx. It also is a
> key package, so it fits my description very well.
>
> I certainly appreciate you putting effort in resolving these issues. I
> also appreciate X-Debbugs-Cc (to record the bug numbers).
>
> Debian unstable currently has almost 3 source packages. Almost 14000
> of them build architecture-dependent binary packages. (The others are
> irrelevant to cross building). Around 7500 have cross-satisfiable
> dependencies. I didn't work that much on satisfiability problems lately,
> so this is only around 55%. Having you work here would be a boon. Of the
> 3900 packages that I tried building, 2900 do cross build. This is a much
> higher ratio of almost 75%. Getting those 55% up would be awesome. If
> you fix half of the sphinx users, we're 1% closer to perfection. :)

Sorry, I have quite little time for Debian at all, and from it very little
time I can devote to Sphinx (as I also have Qt and many other packages).
And most of that time comes into test-rebuilding reverse dependencies when
upstream releases a new version that breaks everything...

So I cannot promise that I will take care of half of those packages.
I will take care only of some of them, those that I am familiar with or
those that are easy to fix. Fortunately cmake matches these patterns.

P.S. Maybe I should merge this bug with #818115? They both discuss cross-
building issues.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#920465: bpfcc-tools: new upstream version 0.8.0

[Michael Prokop]

Package: bpfcc-tools
Version: 0.7.0-2
Severity: wishlist

Hi!

Since 2019-01-11 version 0.8.0 is available at
https://github.com/iovisor/bcc/releases
Would be great to get that (or a newer version) into buster.

Thanks for maintaining bpfcc-tools!

regards,
-mika-

Bug#920463: marked as done (texlive-base breaks fig2dev autopkgtest)

[Norbert Preining]

> The problem here was, that the fig2dev testsuite used plain tex in
> combination with tikz (which internally uses pgf).  According to

Ahh, that one. Yes, etex please. tex is as I explained DEK version which
is not really adapted for tikz/pgf.

Thanks

Norbert

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

Bug#918746: pam-ssh-agent-auth alternative

[Benda Xu]

Hi Moritz,

That needs to be seriously considered.  I am using this package
extensively.  Do you any alternatives to it?

Yours,
Benda

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Dmitry Bogatov]

[2019-01-23 12:41] Jonathan Nieder 
> [...]
> > It is my fault. I dropped /var/lib/supervise directory in runit=2.1.2-4,
> > which was expected by git-daemon-run.
> >
> > Today runit packaging underwent quite a rework, and packages, providing
> > runscripts are encouraged to use dh_runit(1). It manages creation of
> > apporiate directories and symbolic links. If you have any issues, do not
> > hezitate to ask -- runit is my top priority.
>
> Thanks, these are two good starting points.  I'll take a look at the
> 2.1.2-4 changes and into whether it's simple to use dh_runit.  Hopefully
> the latter will take care of everything. :)

It should. If not, I am here to help/fix/improve.

Still, I am surprised, that adding /var/lib/supervise did not help to
you. I will apply patch to `debian-sid' branch and take a closer look at
this weekend.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#920299: lintian: warning for dh_runit usage

[Dmitry Bogatov]

[2019-01-23 23:56] Chris Lamb 
> part   text/plain 418
> tags 920299 + moreinfo
> thanks
>
> Dmitry,
>
> > please add warning for packages, that use dh_runit(1) debhelper (file
> > debian/.runit exists), but do not have Breaks: ${runit:Breaks}.
>
> Please elaborate why a `Breaks: ${runit:Breaks}` is needed; I will
> need this for the tag long description.

Sure. In general, versions of dh_runit(1) sometimes generate runscripts,
that assume something of bin:runit, that is only provided by recent
revisions of bin:runit. Given that runscrips are to be included in
package in same way, as init.d scripts and systemd.service files, I
can't generate dependency on runit. Instead, I ensure, that if runit
/is/ installed, it is installed with sufficently recent version.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#920366: developers-reference: ftbfs in sid, builds fine in stable

[Holger Levsen]

On Sat, Jan 26, 2019 at 06:17:48AM +0900, Norbert Preining wrote:
> I will upload new packages that include the fontspec fixes, as well as
> tighter package coupling. This will fix 2- and most probably also 1-,

thank you for your quick feedback and fixing this!


-- 
tschüß,
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#920463: texlive-base breaks fig2dev autopkgtest

[Norbert Preining]

Hi,

On Fri, 25 Jan 2019, Paul Gevers wrote:
> testing when that autopkgtest is run with the binary packages of
> texlive-base from unstable. It passes when run with only packages from

I guess you then have a mixed system of texlive packages installed, some
from testing and some from unstable. Is this correct?

This has triggered other bugs, so I will upload new packages with strict
versioning so that all tl have to be of the same version in the next
days.

Thanks

Norbert

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

Bug#920366: developers-reference: ftbfs in sid, builds fine in stable

[Norbert Preining]

Hi everyone,

it seems there are two issues here:
1- ftbfs logidee-tools
2- ftbfs developers-reference

ad 1-
FIrst of all, I cannot reproduce this error on sid, so with all packages
properly upgraded.

That means, I assume you have a mixed upgrade of packages where it
fails, is this correct?

If yes, then I just need to force the same version of packages to fix
it.


ad 2-
There was a regression in fontspec that was fixed 2 days ago. I will
upload new packages ASAP.

*

I will upload new packages that include the fontspec fixes, as well as
tighter package coupling. This will fix 2- and most probably also 1-,
but I still hope that I get feedback from logidee-tools maintainers.

Thanks

Norbert

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

Bug#920464: libnet-works-perl needs hinting into testing

[Adrian Bunk]

Package: release.debian.org
Severity: normal

libnet-works-perl is a binary-all package this is
not installable on i386 (it is only installable
on 64bit architectures).

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

[Norbert Preining]

Hi Yutaka,

good morning!

> The exact cause would be there is an empty cache remained in
> gnome-keyring-daemon.  In my case, it is under:
[...]
> Attached is a Python script (I name it test_clear.py) to clear the cache
> entry (your specific keygrip is hard-coded).  You need python3-gi
> package (and ignoring warning about version specification).

Bingo! That worked like a charm!

Thanks a bit lot, that helped.

I leave it to you to close/rename/reassign this bug, not sure what
should be best done with it.

It is strange that there was a empty pwd stored.

> https://dev.gnupg.org/T4340

I see you have already added support for that, big thanks.

All the best and thanks a lot

Norbert

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

Bug#821408: Pam 1.3.0

[Florian Vessaz]

Hello Steve and Andreas,

On Thu, Jan 24, 2019 at 12:10:18AM +0100, Florian Vessaz wrote:
[...]
> I'll take the time to review those differences tomorrow or Friday night.

I compared the two branches:

 [a] https://gitlab.gnugen.ch:fvessaz/pkg-pam.git ah/master
 [b] https://salsa.debian.org/ah/pam.git master

The differences I observed are:

- Changelog entry for version 1.3.1-1 are different, the one in [b]
  looks better to me.

- [a] contains patches metadata (author, date) retrieved from VCS
  history or BTS while [b] does not.

- In patches/007_modules_pam_unix, [b] is is not adding the "obscure"
  argument which gates the functionality added by that same patch.

- In patches/055_pam_unix_nullok_secure, [a] adds the "int nullok =
  off(UNIX__NONULL, ctrl);" at the tail of the list of already present
  declarations at the start of the if block while [b] adds it at the
  top. As far as I can tell, both versions have the same result and
  there is no apparent advantage of one over the other:

  [a] static char *envp[] = { NULL };
  const char *args[] = { NULL, NULL, NULL, NULL };
  int nullok = off(UNIX__NONULL, ctrl);

  [b] int nullok = off(UNIX__NONULL, ctrl);
  static char *envp[] = { NULL };
  const char *args[] = { NULL, NULL, NULL, NULL };

  Another difference is that [a] does not use an implicit declaration of
  _pammodutil_tty_secure. [b] is thus triggering an additional implicit
  declaration warning during the build.

  Finally, it appears that [b] was not adapted to the change made
  upstream to how unix_args is defined in modules/pam_unix/support.h.

- In patches/PAM-manpage-section, [a] is doing pam.8.xml -> pam.7 ->
  PAM.7 while [b] is doing pam.8.xml -> pam.8 -> PAM.7. Same result in
  both cases.

  I updated [a] to do as [b] since [b] is changing less lines for the
  same result. Thus, at the time you are reading this e-mail, this
  difference will not be present.

- patches/cve-2010-4708.patch is still included in [b] while upstream
  settled the issue in pam 1.1.3. As the patch description does not
  provide any argument for keeping it despite upstream settling the
  issue, [a] dropped it. If it is preferred to keep the patch, in my
  opinion the patch description should mention the reason.

- In patches/make_documentation_reproducible.patch [a] uses
  "LC_ALL=C.UTF-8" while [b] uses "LC_ALL=C". Usage of "LC_ALL=C.UTF-8"
  was introduced by 4b9ee4f1ec73d87668ce40f0a362ecbc58159d9f.

- In patches/update-motd [a] clarifies a sentence.

Please let me know if my branch should be updated, I can take the time
to do so if I receive feedback. And don't hesitate to replace my commit
with the changelog entry.

Thank you,
-- Florian


signature.asc
Description: PGP signature

Bug#920463: texlive-base breaks fig2dev autopkgtest

[Paul Gevers]

Source: texlive-base, fig2dev
Control: found -1 texlive-base/2018.20190122-1
Control: found -1 fig2dev/1:3.2.7a-3
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of texlive-base the autopkgtest of fig2dev fails in
testing when that autopkgtest is run with the binary packages of
texlive-base from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
texlive-base   from testing2018.20190122-1
fig2devfrom testing1:3.2.7a-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of texlive-base to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package? 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=texlive-base

https://ci.debian.net/data/autopkgtest/testing/amd64/f/fig2dev/1779958/log.gz
Test tikz output language.

 33: conditionally allocate \XFigu   FAILED (output.at:175)
 34: pattern with stroke color equal to fill color   ok

Create and embed bitmaps in fig-file.

 35: gif ok
 36: jpegok
 37: pcx ok
 38: png ok
 39: png with smoothing  ok
 40: ppm ok
 41: tiffok
 42: xbm ok
 43: xbm with smoothing  ok
 44: xpm skipped
(bitmaps.at:104)

Creation of temporary files.

 45: eps with acscii preview ok
 46: eps with tiff preview   ok

Embed postscript variants.

 47: epsiok
 48: postscript, created by fig2dev  ok
 49: postscript, created by latexok

## - ##
## Test results. ##
## - ##

ERROR: 46 tests were run,
1 failed unexpectedly.
3 tests were skipped.
## -- ##
## testsuite.log was created. ##
## -- ##

Please send `fig2dev/tests/testsuite.log' and all information you think
might help:

   To: 
   Subject: [fig2dev 3.2.7a] testsuite: 33 failed

You may investigate any problem if you feel able to do so, in which
case the test suite provides a good starting point.  Its output may
be found below `fig2dev/tests/testsuite.dir'.

make[1]: *** [Makefile:583: check-local] Error 1
make[1]: Leaving directory
'/tmp/autopkgtest-lxc.choif6me/downtmp/build.4Dg/src/fig2dev/tests'
make: *** [Makefile:449: check-am] Error 2
autopkgtest [04:50:27]: test fig2dev-testsuite: ---]




signature.asc
Description: OpenPGP digital signature

Bug#916691: cuyo -- Not fit for next release

[Adrian Bunk]

On Mon, Dec 17, 2018 at 02:30:43PM +0100, Bernhard R. Link wrote:
> Source: cuyo
> Severity: critical
> 
> Pseudo-Bug to keep cuyo out fo testing so it does not end up in the next 
> release.

You've seen the question in #916692?

>   Bernhard R. Link

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#920461: 'unexpected operator' error coming from /etc/init.d/openipmi

[Adam Di Carlo]

Package: openipmi
Version: 2.0.25-2
Severity: normal

Even disabled, when starting the package, I'm seeing an error from
systemctl:

root@salsa:/etc/init.d# systemctl status openipmi.service
● openipmi.service - LSB: OpenIPMI Driver init script
   Loaded: loaded (/etc/init.d/openipmi; generated)
   Active: active (exited) since Fri 2019-01-25 15:16:37 EST; 3s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 3081 ExecStart=/etc/init.d/openipmi start (code=exited, 
status=0/SUCCESS)

Jan 25 15:16:37 salsa systemd[1]: Starting LSB: OpenIPMI Driver init script...
Jan 25 15:16:37 salsa openipmi[3081]: /etc/init.d/openipmi: 55: [: 4.17: 
unexpected operator
Jan 25 15:16:37 salsa openipmi[3081]: Starting ipmi drivers ipmi.
Jan 25 15:16:37 salsa systemd[1]: Started LSB: OpenIPMI Driver init script.


It doesn't seem to affect functionality.

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

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

Versions of packages openipmi depends on:
ii  libc6 2.28-5
ii  libncurses6   6.1+20181013-1
ii  libopenipmi0  2.0.25-2
ii  libpopt0  1.16-11
ii  libsnmp30 5.7.3+dfsg-5
ii  libssl1.1 1.1.1a-1
ii  libtinfo6 6.1+20181013-1
ii  lsb-base  10.2018112800

openipmi recommends no packages.

openipmi suggests no packages.

-- Configuration Files:
/etc/default/openipmi changed:
IPMI_SI=no
DEV_IPMI=yes
IPMI_WATCHDOG=no
IPMI_WATCHDOG_OPTIONS="timeout=60"
IPMI_POWEROFF=no
IPMI_POWERCYCLE=no
IPMI_IMB=no


-- no debconf information

Bug#920455: followup on bash process substitution and wait

[Daniel Kahn Gillmor]

looks like what's happening is that the parent bash process doesn't
invoke the process substitution itself.   Rather, the subprocess that
will exec the command itself *first* spawns a grandchild process for the
process execution, before execing the expected command.

that means that wait(-1) of the expected command is going to hang
because it's waiting on a child process that it doesn't know about.

here's the relevant strace info:

$ strace -T -tt -f -e wait4,clone,execve ./wait-hang-behavior.bash 
14:58:44.997547 execve("./wait-hang-behavior.bash", 
["./wait-hang-behavior.bash"], 0x7ffccd028678 /* 53 vars */) = 0 <0.000508>
14:58:45.006079 clone(strace: Process 12365 attached
child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f6b51955a10) = 12365 <0.000207>
[pid 12364] 14:58:45.006703 wait4(-1,  
[pid 12365] 14:58:45.007253 clone(strace: Process 12366 attached
child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f6b51955a10) = 12366 <0.81>
[pid 12365] 14:58:45.007599 execve("./wait-hang-behavior-2.bash", 
["./wait-hang-behavior-2.bash"], 0x563b2c6c4c50 /* 53 vars */) = 0 <0.000260>
[pid 12366] 14:58:45.008281 clone(strace: Process 12367 attached
child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f6b51955a10) = 12367 <0.88>
[pid 12366] 14:58:45.008577 wait4(-1,  
[pid 12367] 14:58:45.008658 execve("/usr/bin/tee", ["tee", "-p", "./stdout"], 
0x563b2c6c4c50 /* 53 vars */) = 0 <0.000166>
hi there
[pid 12365] 14:58:45.011442 wait4(-1,   C-c C-c 
[pid 12364] 14:59:04.039138 <... wait4 resumed> 0x7fff384a5340, 0, NULL) = ? 
ERESTARTSYS (To be restarted if SA_RESTART is set) <19.032359>
strace: Process 12364 detached
strace: Process 12365 detached
strace: Process 12366 detached
strace: Process 12367 detached


signature.asc
Description: PGP signature

Bug#920460: nautilus: org.freedesktop.FileManager1.service conflict

[Yves-Alexis Perez]

Source: nautilus
Version: 3.30.5-1
Severity: normal

Hi,

this is a “preemptive” bug about a future file conflict. Latest Thunar
upstream version (1.8.3) gained support for the
org.freedesktop.FileManager1 DBus name
(https://bugzilla.xfce.org/show_bug.cgi?id=12414). 

This is a generic Freedesktop name which is supposed to be used to open
the file manager of the current desktop.

Until now, Nautilus was the only package providing this, but now we have
a problem. First is obviously a file conflict if I upload Thunar 1.8.3-1
as-is, the second beeing a conflict on the service name itself, even if
I (for example) rename the file.

It's not the first time we have issues like this, generic DBus names
aren't really practical for distributions. I'm open to sugestions on how
to handle this.

Regards,
-- 
Yves-Alexis

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

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

Bug#919831: Javadoc -link makes broken links if module name matches package name

[Ole Streicher]

Hi Matthias,

on a number of packages, javadoc now fails, which is reported by a
number of bugs. Since you mentioned that this is not a bug in the JDK,
could you give a hint what the problem is? The error message is a bit
mystic, at least to me. And the openjdk commit also does not enlighten me.

It a bug in the individual packages or one in javahelper? And what
should be done to fix it?

Best

Ole

On 25.01.19 09:26, Matthias Klose wrote:
> so this is not an openjdk error, and should be fixed in the pacakges itself. 
> See
> 
> 8211916: Javadoc -link makes broken links if module name matches package name
> http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/66a53d6047d1
> 
> see the -source 8 passed in the tests.
> 
> 

Bug#817914: developers-reference: globally change "new maintainer" into "new member"

[Holger Levsen]

Hi Holger,

yes, a patch to fix this would be awesome! Many thanks in advance! :)


-- 
tschüß,
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#920437: ITP: displaylink -- Proprietary driver for DisplayLink devices

[Hanno Stock]

Am Fr, 25. Jan 2019, um 17:03, schrieb Ben Hutchings:
> Please consider choosing a more specific package name.  Since we have
> free drivers for some DisplayLink devices, we should encourage users to
> use those where possible.

Ok, I see. What about displaylink-nonfree ? One could also append to the long 
description a hint which package to
use for devices supported by the free drivers.

Bug#920042: lua-nvim: autopkgtest times out since 2019-01-10

[Paul Gevers]

On Mon, 21 Jan 2019 21:17:00 +0100 Paul Gevers  wrote:
> Since 2019-01-10 the autopkgtest of your package times out (after 2:47h)
> on ci.debian.net. Unfortunately, this most likely isn't caused by any of
> your direct (test) dependencies, otherwise the integration with our
> migration software should have caught it.

> Can you please investigate the situation? Don't hesitate to ask for help
> for the Debian CI team² if you need help solving this issue.

If your test is using bash and is using the builtin wait function, I
suggest you look at bug 920455.

Paul

https://bugs.debian.org/920455



signature.asc
Description: OpenPGP digital signature

Bug#920459: toulbar2 ftbfs in unstable

[Matthias Klose]

Package: src:toulbar2
Version: 1.0.0+dfsg3-1.1
Severity: serious
Tags: sid buster

toulbar2 ftbfs in unstable

[...]
*geometry* driver: auto-detecting
*geometry* detected driver: pdftex
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/gettitlestring.sty))
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}] (./index.tex
(/usr/share/texlive/texmf-dist/tex/latex/wasysym/uwasy.fd)
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsa.fd)
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsb.fd)
! Missing } inserted.

}
l.7 \end{longtabu}

?
! Emergency stop.

}
l.7 \end{longtabu}

!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on refman.log.
make[4]: *** [Makefile:6: refman.pdf] Error 1
make[4]: Leaving directory
'/<>/toulbar2-1.0.0+dfsg3/obj-x86_64-linux-gnu/latex'
make[3]: *** [CMakeFiles/doc.dir/build.make:71: doc] Error 2
make[3]: Leaving directory 
'/<>/toulbar2-1.0.0+dfsg3/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:76: CMakeFiles/doc.dir/all] Error 2
[...]

Bug#918508: Should golang-1.10 be shpped in buster?

[Dr. Tobias Quathamer]

control: retitle -1 RM: golang-1.10 -- ROM; superseeded by golang-1.11
control: reassign -1 ftp.debian.org
control: severity -1 normal

Am 06.01.2019 um 21:11 schrieb Adrian Bunk:
> Source: golang-1.10
> Severity: serious
> 
> With golang-1.11 as default now, should golang-1.10
> be shipped in buster?

Dear FTP team,

could you please remove golang-1.10 from unstable? The version 1.11
should be shipped as default with buster, and golang-1.10 has already
been removed for that reason from testing.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#920442: (no subject)

[spamson]

On 2019-01-25 13:22, Marc Deslauriers wrote:
Looks like this is caused by texlive-base (2018.20190122-1), reverting 
to

texlive-base (2018.20181214-1) fixes the FTBFS.

Bug#787123: rsync: please make the build reproducible

[Samuel Henrique]

Hello Dhole,

I'm sorry it took so long to address this problem, and by the time I had a
look at that, your patch wasn't enough anymore, but I'm very thankful for
your work, we used a part of it to make rsync reproducible, and I mentioned
your contribution on the changelog.

I just uploaded 3.1.3-4, which should be the fully reproducible rsync
[package] release :)

Regards,

-- 
Samuel Henrique 

Bug#856594: makedumpfile: In a chroot, kdump-tools.postinst creates initramfs for the host kernel

[Thadeu Lima de Souza Cascardo]

Hi, Benjamin.

Thanks for all the bug reports and merge request on makedumpfile.

I am working through these, though a little behind and with some lack of
time to do it properly and on time.

But I know at least this bug should be fixed with 1:1.6.4-2.

  * Ignore uninstalled kernels when doing the kernel postinst. (Closes: #904524)

Can you test it, without your patches?

In that case, would you send another merge request without that patch?

Thanks.
Cascardo.

Bug#920281: Re : Bug#920281: ntopng: Unable to finish the post-inst.

[Marc Haber]

On Thu, Jan 24, 2019 at 12:15:54PM -0800, Ludovico Cavedon wrote:
> Something is going wrong with the migration I have not been able to
> reproduce yet.

I see the same issue. The cause is the line
runuser -u ntopng -- tar xf- -C $DATA_DIR
in postinst. The error message is a bit misleading, strace shows that
tar is actually trying to open a file called '-C'.

I am not an expert in tar's short option, but you might have hit an
argument parsing issue in tar.

Changing the line to

runuser -u ntopng -- tar --extract --verbose --file - --directory $DATA_DIR

has some chance to work (worked for me), but I think that's a style
question and there surely is a way to write that in a way that tar will
also accept with short options. I have tar 1.30+dfsg-4.

btw, in my opinion this is a release critical bug.

Hope this helps.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#920442: (no subject)

[Marc Deslauriers]

Looks like this is caused by texlive-base (2018.20190122-1), reverting to
texlive-base (2018.20181214-1) fixes the FTBFS.

Bug#886664: [Pkg-javascript-devel] Bug#886664: fixed in node-d3-timer 1.0.7-4

[Jonas Smedegaard]

Quoting Xavier (2019-01-25 18:14:38)
> Le 25/01/2019 à 17:39, Santiago Vila a écrit :
> > found 886664 1.0.7-4
> > thanks
> > 
> >>[ Xavier Guimard ]
> >>* Remove timeout based tests (Closes: #886664)
> > 
> > Hi. Sorry for the reopening but this does not seem fixed:
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/node-d3-timer.html
> > 
> > Thanks.
> 
> Hello,
> 
> Javascript is an asynchronous language, so many tests are timeout 
> based, but deb machines are so slow that we have to patch many 
> packages to increase delays...

How do you mean they are "timeout-based"?


 - Jonas

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

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


signature.asc
Description: signature

Bug#920458: python3-twisted: Incorrect dependencies on python3-attr

[Kurt Roeckx]

Package: python3-twisted
Version: 17.4.0-2
Severity: serious

Hi,

When using python3-twisted from backports (18.7.0-2~bpo9+1), I get
the following error:
Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/synapse/app/homeserver.py", line 27, in 

from twisted.internet import defer, reactor
  File "/usr/lib/python3/dist-packages/twisted/internet/reactor.py", line 38, 
in 
from twisted.internet import default
  File "/usr/lib/python3/dist-packages/twisted/internet/default.py", line 56, 
in 
install = _getInstallFunction(platform)
  File "/usr/lib/python3/dist-packages/twisted/internet/default.py", line 44, 
in _getInstallFunction
from twisted.internet.epollreactor import install
  File "/usr/lib/python3/dist-packages/twisted/internet/epollreactor.py", line 
24, in 
from twisted.internet import posixbase
  File "/usr/lib/python3/dist-packages/twisted/internet/posixbase.py", line 18, 
in 
from twisted.internet import error, udp, tcp
  File "/usr/lib/python3/dist-packages/twisted/internet/udp.py", line 53, in 

from twisted.internet import base, defer, address
  File "/usr/lib/python3/dist-packages/twisted/internet/base.py", line 27, in 

from twisted.internet._resolver import (
  File "/usr/lib/python3/dist-packages/twisted/internet/_resolver.py", line 25, 
in 
from twisted.internet.address import IPv4Address, IPv6Address
  File "/usr/lib/python3/dist-packages/twisted/internet/address.py", line 23, 
in 
class IPv4Address(object):
  File "/usr/lib/python3/dist-packages/twisted/internet/address.py", line 37, 
in IPv4Address
type = attr.ib(validator=attr.validators.in_(["TCP", "UDP"]))
AttributeError: module 'attr.validators' has no attribute 'in_'

I had python3-attr 16.3.0-1 installed. If I upgrade it to
17.4.0-2~bpo9+1, the problem goes away.

I'm filing this against 17.4.0-2 since I think it applies to all
versions, including the version in testing.


Kurt

Bug#920457: fw4spl ftbfs in unstable

[Matthias Klose]

Package: src:fw4spl
Version: 17.2.0-1
Severity: serious
Tags: sid buster

fw4spl ftbfs in unstable

cd /<>/obj-x86_64-linux-gnu/fwMemory && /usr/bin/c++
-DBOOST_ALL_DYN_LINK -DBOOST_SPIRIT_USE_PHOENIX_V3
-DBOOST_THREAD_DONT_PROVIDE_DEPRECATED_FEATURES_SINCE_V3_0_0
-DBOOST_THREAD_PROVIDES_FUTURE -DBOOST_THREAD_VERSION=2 -DFWMEMORY_EXPORTS
-DFWMEMORY_VER=\"0.1\" -DSPYLOG_LEVEL=2 -DSPYLOG_NO_INCLUDE=1
-I/<>/SrcLib/core/fwMemory/include
-I/<>/obj-x86_64-linux-gnu/fwMemory/include
-I/<>/SrcLib/core/fwCamp/include
-I/<>/obj-x86_64-linux-gnu/fwCamp/include
-I/<>/SrcLib/core/fwCore/include
-I/<>/obj-x86_64-linux-gnu/fwCore/include
-I/<>/SrcLib/core/fwCom/include
-I/<>/obj-x86_64-linux-gnu/fwCom/include
-I/<>/SrcLib/core/fwThread/include
-I/<>/obj-x86_64-linux-gnu/fwThread/include
-I/<>/SrcLib/core/fwTools/include
-I/<>/obj-x86_64-linux-gnu/fwTools/include  -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra
-Wconversion -Wno-unused-parameter -Wno-ignored-qualifiers -fvisibility=hidden
-O3 -DNDEBUG -fPIC   -std=gnu++11 -o
CMakeFiles/fwMemory.dir/src/fwMemory/BufferInfo.cpp.o -c
/<>/SrcLib/core/fwMemory/src/fwMemory/BufferInfo.cpp
/<>/SrcLib/io/fwDcmtkTools/src/fwDcmtkTools/Dictionary.cpp: In
static member function 'static void fwDcmtkTools::Dictionary::loadDictionary()':
/<>/SrcLib/io/fwDcmtkTools/src/fwDcmtkTools/Dictionary.cpp:32:21:
error: 'class GlobalDcmDataDictionary' has no member named 'unlock'; did you
mean 'rdlock'?
 dcmDataDict.unlock();
 ^~
 rdlock
make[3]: *** [fwDcmtkTools/CMakeFiles/fwDcmtkTools.dir/build.make:66:
fwDcmtkTools/CMakeFiles/fwDcmtkTools.dir/src/fwDcmtkTools/Dictionary.cpp.o] 
Error 1
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:7350:
fwDcmtkTools/CMakeFiles/fwDcmtkTools.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs

Bug#919763: adios: armhf FTBFS when built on arm64

[Steve Langasek]

Package: adios
Followup-For: Bug #919763
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Hi Alastair,

I'm reopening this bug report because I see that you have closed it by
disabling the testsuite.

This is a wrong fix for the issue given that the tests are correctly
identifying CPU incompatibility in the code.  This only results in willingly
shipping binaries that will not work on more recent ARM CPUs (and even older
CPUs, when using a kernel in a particular mode).

If you as maintainer don't want to support adios across the range of CPUs
that the Debian armhf port is expected to work on, then it would be better
to remove the adios binaries for this architecture instead.

(And btw, this issue would also affect sparc64 as an architecture, not only
armhf, due to similar alignment constraints.)

However, I've just prepared a patch that fixes the unaligned access problems
in adios's code.  Would you consider applying this as a solution instead?

It could stand to be improved - in particular, for cases where we are
byteswapping, the code currently writes the variable twice where this could
be optimized to be a single write.  But I presume the byteswap case is only
of interest on big-endian architectures, so not of great concern on modern
targets.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru adios-1.13.1/debian/patches/no-unaligned-access.patch 
adios-1.13.1/debian/patches/no-unaligned-access.patch
--- adios-1.13.1/debian/patches/no-unaligned-access.patch   1969-12-31 
16:00:00.0 -0800
+++ adios-1.13.1/debian/patches/no-unaligned-access.patch   2019-01-25 
09:21:48.0 -0800
@@ -0,0 +1,248 @@
+Description: use alignment-safe buffer handling.
+ Currently we are using assignment to copy the contents of a variable of
+ arbitrary type into a buffer, but this is not portable because the buffer
+ address may not be aligned.  Use memcpy() instead, which should be
+ comparable performance but alignment-safe.
+Author: Steve Langasek 
+Last-Modified: 2019-01-25
+Bug-Debian: https://bugs.debian.org/919763
+
+Index: adios-1.13.1/src/core/adios_bp_v1.c
+===
+--- adios-1.13.1.orig/src/core/adios_bp_v1.c
 adios-1.13.1/src/core/adios_bp_v1.c
+@@ -155,21 +155,21 @@
+ 
+ uint64_t attrs_end = b->file_size - 28;
+ 
+-b->pg_index_offset = *(uint64_t *) (b->buff + b->offset);
++memcpy(&b->pg_index_offset, b->buff + b->offset, sizeof(uint64_t));
+ if(b->change_endianness == adios_flag_yes) {
+ swap_64(b->pg_index_offset);
+ }
+ 
+ b->offset += 8;
+ 
+-b->vars_index_offset = *(uint64_t *) (b->buff + b->offset);
++memcpy(&b->vars_index_offset, b->buff + b->offset, sizeof(uint64_t));
+ if(b->change_endianness == adios_flag_yes) {
+ swap_64(b->vars_index_offset);
+ }
+ 
+ b->offset += 8;
+ 
+-b->attrs_index_offset = *(uint64_t *) (b->buff + b->offset);
++memcpy(&b->attrs_index_offset, b->buff + b->offset, sizeof(uint64_t));
+ if(b->change_endianness == adios_flag_yes) {
+ swap_64(b->attrs_index_offset);
+ }
+@@ -203,13 +203,13 @@
+ uint64_t process_groups_count;
+ uint64_t process_groups_length;
+ 
+-process_groups_count = *(uint64_t *) (b->buff + b->offset);
++memcpy(&process_groups_count, b->buff + b->offset, sizeof(uint64_t));
+ if(b->change_endianness == adios_flag_yes) {
+ swap_64(process_groups_count);
+ }
+ b->offset += 8;
+ 
+-process_groups_length = *(uint64_t *) (b->buff + b->offset);
++memcpy(&process_groups_length, b->buff + b->offset, sizeof(uint64_t));
+ if(b->change_endianness == adios_flag_yes) {
+ swap_64(process_groups_length);
+ }
+@@ -275,7 +275,8 @@
+ }
+ b->offset += 4;
+ 
+-(*root)->offset_in_file = *(uint64_t *) (b->buff + b->offset);
++memcpy(&((*root)->offset_in_file), b->buff + b->offset,
++   sizeof(uint64_t));
+ if(b->change_endianness == adios_flag_yes) {
+ swap_64((*root)->offset_in_file);
+ }
+@@ -321,7 +322,7 @@
+ }
+ b->offset += 4;
+ 
+-vars_length = *(uint64_t *) (b->buff + b->offset);
++memcpy(&vars_length, b->buff + b->offset, sizeof(uint64_t));
+ if(b->change_endianness == adios_flag_yes) {
+ swap_64(vars_length);
+ }
+@@ -390,7 +391,8 @@
+ (*root)->type = (enum ADIOS_DATATYPES) flag;
+ b->offset += 1;
+ 
+-characteristics_sets_count = *(uint64_t *) (b->buff + b->offset);
++memcpy(&characteristics_sets_count, b->buff + b->offset,
++   sizeof(uint64_t));
+ if(b->change_endianness == adios_flag_yes