Bug#1067687: lcov: Missing runtime dependency on libtimedate-perl

[Dave Jones]

Source: lcov
Version: 1.15-1
Severity: important

Dear Maintainer,

While libtimedate-perl is included as a build dependency, it's missing 
from the runtime dependencies. However, the genhtml binary relies upon 
Date/Parse.pm which is provided by libtimedate-perl, hence it needs to 
be in the runtime dependencies too.

I suspect many users haven't noticed this as libtimedate-perl is pulled 
in by many other things too, but on a minimal cloud image this results 
in the following output when attempting to run genhtml:

   $ genhtml -o /tmp/i3-coverage/ i3.info
   Can't locate Date/Parse.pm in @INC (you may need to install the 
   Date::Parse module) (@INC contains: /etc/perl 
   /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 
   /usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 
   /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base 
   /usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 
   /usr/local/lib/site_perl) at /usr/bin/genhtml line 89.

Bug#1064303: authprogs: Program name is incorrect in description, "authrpogs" instead of "authprogs"

[Russell Jones]

Package: authprogs
Severity: minor
X-Debbugs-Cc: a1hg94...@mozmail.com

Dear Maintainer,

"authrpogs is invoked" in the description should say "authprogs is invoked"

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

Kernel: Linux 6.6.15-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages authprogs depends on:
ii  python3   3.11.6-1
pn  python3-yaml  

authprogs recommends no packages.

authprogs suggests no packages.

Bug#1057117:

[Neil Jones]

Steve,

Any progress on this bug?

It is very easy to replicate and needs to be addressed urgently.

I would suggest removing the swiftlang package from Debian testing and 
returning it to unstable until this bug is fixed.

The package really shouldn't be out of experimental yet, as it does not work 
even in the simplest operation.

As I have reported here - https://github.com/apple/swift/issues/60690 
 - even the basic swiftc complier 
is not working.

Neil


> On Dec 2, 2023, at 5:52, Steve M  wrote:
> 
> Neil,
> 
> Thank you for taking to time to test my packaging efforts and submit a bug
> report. I just did a quick test and was unable to reproduce your bug on Debian
> testing. This weekend when I have a little more time I'll try setting up a 
> clean
> Debian unstable environment and try again.
> 
> $ mkdir hello && cd hello && swift package init --type executable
> Creating executable package: hello
> Creating Package.swift
> Creating README.md
> Creating .gitignore
> Creating Sources/
> Creating Sources/hello/main.swift
> Creating Tests/
> Creating Tests/helloTests/
> Creating Tests/helloTests/helloTests.swift
> $ swift build
> Building for debugging...
> [6/6] Linking hello
> Build complete! (1.16s)
> $ .build/x86_64-pc-linux-gnu/debug/hello
> Hello, world!
> $ 
> 
> 
> -Steve
> 

Bug#1031693: import-dsc: dangling pristine-tar treeish with multiple components

[Huw Jones]

Hi,

Is there anything I can do to help resolve this issue?

Kind regards,
Huw

Bug#516152: Patch to fix the documentation

[Dave Jones]

Attaching an updated patch based on the current state of unstable. Some 
bits of the prior patch already appeared in the documentation, other 
bits needed a little re-working, but the intent is the same: the 
behaviour of bash is unchanged, this just changes the documentation to 
match the behaviour.


Best regards,

Dave Jones.
diff --git a/debian/changelog b/debian/changelog
index cd2b7c6d..b645fec8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+bash (5.2.15-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/man-bashrc.diff: Correct the bash(1) man-page to note that --rcfile
+does not prevent the execution of the system-wide /etc/bash.bashrc file.
+Closes: #516152.
+
+ -- Dave Jones   Tue, 14 Nov 2023 11:31:40 +
+
 bash (5.2.15-2) unstable; urgency=medium
 
   * Remove one more pdf file without source. Closes: #1024598.
diff --git a/debian/patches/man-bashrc.diff b/debian/patches/man-bashrc.diff
index 300d3ebf..1602a98c 100644
--- a/debian/patches/man-bashrc.diff
+++ b/debian/patches/man-bashrc.diff
@@ -2,17 +2,17 @@
 
 --- a/doc/bash.1
 +++ b/doc/bash.1
-@@ -187,7 +187,9 @@ Display a usage message on standard outp
- .PD
- Execute commands from
- .I file
--instead of the standard personal initialization file
-+instead of the system wide initialization file
-+.I /etc/bash.bashrc
-+and the standard personal initialization file
- .I ~/.bashrc
+@@ -192,7 +192,9 @@ instead of the standard personal initial
  if the shell is interactive (see
  .SM
+ .B INVOCATION
+-below).
++below). Note that the system wide initialization file
++.I /etc/bash.bashrc
++is still executed.
+ .TP
+ .B \-\-login
+ Equivalent to \fB\-l\fP.
 @@ -218,7 +220,9 @@ reads these files when it is invoked as
  below).
  .TP
@@ -36,13 +36,12 @@
  option.
  The \fB\-\-rcfile\fP \fIfile\fP option will force
  .B bash
--to read and execute commands from \fIfile\fP instead of \fI~/.bashrc\fP.
-+to read and execute commands from \fIfile\fP instead of
-+\fI/etc/bash.bashrc\fP and \fI~/.bashrc\fP.
+ to read and execute commands from \fIfile\fP instead of \fI~/.bashrc\fP.
++Note that \fI/etc/bash.bashrc\fP will still be read.
  .PP
  When
  .B bash
-@@ -426,8 +432,8 @@ or the secure shell daemon \fIsshd\fP.
+@@ -426,14 +432,15 @@ or the secure shell daemon \fIsshd\fP.
  If
  .B bash
  determines it is being run non-interactively in this fashion,
@@ -53,7 +52,15 @@
  It will not do this if invoked as \fBsh\fP.
  The
  .B \-\-norc
-@@ -11581,6 +11587,9 @@ The \fBbash\fP executable
+ option may be used to inhibit this behavior, and the
+ .B \-\-rcfile
+-option may be used to force another file to be read, but neither
++option may be used to force another file to be read instead of
++\fI~/.bashrc\fP, but neither
+ \fIrshd\fP nor \fIsshd\fP generally invoke the shell with those options
+ or allow them to be specified.
+ .PP
+@@ -11672,6 +11679,9 @@ The \fBbash\fP executable
  .FN /etc/profile
  The systemwide initialization file, executed for login shells
  .TP

Bug#1043156: floatbg: please consider upgrading to 3.0 source format

[Howard Jones]

On 06/08/2023 19:40, Bastian Germann wrote:

Source: floatbg
Version: 1.0-28.1
Severity: wishlist

This package is among the few that still use source format 1.0.
Please upgrade it to source format 3.0:
https://wiki.debian.org/Projects/DebSrc3.0

I think it's been about 20 years since I reported an issue with this 
package - is there a reason why I still get updates on every other issue 
filed for it? :-)

Bug#979688: Simplifying the list of image files for arm64 sunxi boards

[Dave Jones]

Hi Vagrant,

Heinrich Schuchardt and I were just having a look at this area for the 
ubuntu packaging, specifically whether to include 
u-boot-sunxi-with-spl.bin in the u-boot-sunxi build (and whether to poke 
upstream to update the README that gets included by u-boot-sunxi.docs), 
and ran across this bug while seeing if anything had been considered in 
this area up in Debian.


Is this still on the cards post-bookworm?

Thanks!

Dave Jones.

Bug#1040169: smplayer: Smplayer hangs when starting video

[Edward C. Jones]

Package: smplayer
Version: 22.7.0~ds0-1
Severity: important
X-Debbugs-Cc: edcjo...@edcjones.abcd.net

Dear Maintainer,

Smplayer hangs whenever I try to start a video.  When I close the window
smplayer is in, I sometimes get an error message and a log.  Here is a log:

=
/usr/bin/mpv --no-quiet --terminal --no-msg-color
/ --input-ipc-server=/tmp/smplayer-mpv-1ff50
/ --msg-level=ffmpeg/demuxer=error --video-rotate=no --no-config --no-fs
/ --hwdec=no --sub-auto=fuzzy --vo=x11, --no-input-default-bindings
/ --input-vo-keyboard=no --no-input-cursor --cursor-autohide=no
/ --no-keepaspect --wid=8 --monitorpixelaspect=1 --osd-level=1 --osd-scale=1
/ --osd-bar-align-y=0.6 --sub-ass --embeddedfonts --sub-ass-line-spacing=0
/ --sub-scale=1 --sub-font=Arial --sub-color=#
/ --sub-shadow-color=#ff00 --sub-border-

color=#ff00 --sub-border-size=0.75 --sub-shadow-offset=2.5
--sub-font-size=50 --sub-bold=no --sub-italic=no --sub-margin-y=8
--sub-margin-x=20 --sub-codepage=ISO-8859-1 --vid=1 --sub-pos=100
--volume=55 --cache=auto --screenshot-template=cap_%F_%p_%02n
--screenshot-format=jpg
--screenshot-directory=/home/edcjones/Pictures/smplayer_screenshots
--audio-pitch-correction=yes --volume-max=110
--term-playing-msg=MPV_VERSION=${=mpv-version:}

INFO_VIDEO_WIDTH=${=width}
INFO_VIDEO_HEIGHT=${=height}
INFO_VIDEO_ASPECT=${=video-params/aspect}
INFO_VIDEO_FPS=${=container-fps:${=fps}}
INFO_VIDEO_FORMAT=${=video-format}
INFO_VIDEO_CODEC=${=video-codec}
INFO_DEMUX_ROTATION=${=track-list/0/demux-rotation}
INFO_AUDIO_FORMAT=${=audio-codec-name}
INFO_AUDIO_CODEC=${=audio-codec}
INFO_AUDIO_RATE=${=audio-params/samplerate}
INFO_AUDIO_NCH=${=audio-params/channel-count}
INFO_LENGTH=${=duration:${=length}}
INFO_DEMUXER=${=current-demuxer:${=demuxer}}
INFO_SEEKABLE=${=seekable}
INFO_TITLES=${=disc-titles}
INFO_CHAPTERS=${=chapters}
INFO_TRACKS_COUNT=${=track-list/count}
METADATA_TITLE=${metadata/by-key/title:}
METADATA_ARTIST=${metadata/by-key/artist:}
METADATA_ALBUM=${metadata/by-key/album:}
METADATA_GENRE=${metadata/by-key/genre:}
METADATA_DATE=${metadata/by-key/date:}
METADATA_TRACK=${metadata/by-key/track:}
METADATA_COPYRIGHT=${metadata/by-key/copyright:}
INFO_MEDIA_TITLE=${=media-title:}
INFO_STREAM_PATH=${stream-path}
 --audio-client-name=SMPlayer --term-status-msg=STATUS: ${=time-pos} /
 ${=duration:${=length:0}} P: ${=pause} B: ${=paused-for-cache} I:
 ${=core-idle} VB: ${=video-bitrate:0} AB: ${=audio-bitrate:0}
 /data/pics/videos/trever/chris vs mikey.flv

(+) Video --vid=1 (h264 854x480 29.955fps)
 (+) Audio --aid=1 (aac 2ch 44100Hz)
[vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter)
[vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 8, serial: 12
[vo/x11/x11] Error code: 9, request code: e, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 8, serial: 13
[vo/x11/x11] Error code: 3, request code: 28, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 8, serial: 16
[vo/x11/x11] Error code: 3, request code: 2, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 8, serial: 18
[vo/x11/x11] Error code: 3, request code: 1, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 1b
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 1e
[vo/x11/x11] Error code: 3, request code: 91, minor code: 3
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 20
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 21
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11] Warning: this legacy VO has bad performance. Consider fixing your
 graphics drivers, or not forcing the x11 VO.
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 23
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 24
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter)
[vo/x11/x11] Type: 0, display: 0x7f7bd80456b0, resourceid: 1a2, serial: 25
[vo/x11/x11] Error code: 9, request code: 37, minor code: 0
[W][14041.464775] pw.conf  | [  conf.c:  939 try_load_conf()]
   

Bug#1034867: smplayer always crashes in Debian 12

[Edward C. Jones]

Package: smplayer
Version: 22.7.0~ds0-1
Followup-For: Bug #1034867
X-Debbugs-Cc: 

Dear Maintainer,

I recently installed Debian 12 (bookworm) on my PC.  I use KDE.

Whenever I try to run smplayer, it does nothing.  If I try to delete the
smplayer window, smplay tells me it has crashed and points me to a log file
I suspect my bug may be the same as #1034867 because there are many X11
errors in the log.

Here is the log:
===

/usr/bin/mpv --no-quiet --terminal --no-msg-color 
--input-ipc-server=/tmp/smplayer-mpv-17e34 --msg-level=ffmpeg/demuxer=error 
--video-rotate=no --no-config --no-fs --hwdec=no --sub-auto=fuzzy --vo=x11, 
--no-input-default-bindings --input-vo-keyboard=no --no-input-cursor 
--cursor-autohide=no --no-keepaspect --wid=8 --monitorpixelaspect=1 
--osd-level=1 --osd-scale=1 --osd-bar-align-y=0.6 --sub-ass --embeddedfonts 
--sub-ass-line-spacing=0 --sub-scale=1 --sub-font=Arial --sub-color=# 
--sub-shadow-color=#ff00 --sub-border-color=#ff00 
--sub-border-size=0.75 --sub-shadow-offset=2.5 --sub-font-size=50 --sub-bold=no 
--sub-italic=no --sub-margin-y=8 --sub-margin-x=20 --sub-codepage=ISO-8859-1 
--sub-pos=100 --volume=55 --cache=auto --screenshot-template=cap_%F_%p_%02n 
--screenshot-format=jpg 
--screenshot-directory=/home/edcjones/Pictures/smplayer_screenshots 
--audio-pitch-correction=yes --volume-max=110 
--term-playing-msg=MPV_VERSION=${=mpv-version:}
INFO_VIDEO_WIDTH=${=width}
INFO_VIDEO_HEIGHT=${=height}
INFO_VIDEO_ASPECT=${=video-params/aspect}
INFO_VIDEO_FPS=${=container-fps:${=fps}}
INFO_VIDEO_FORMAT=${=video-format}
INFO_VIDEO_CODEC=${=video-codec}
INFO_DEMUX_ROTATION=${=track-list/0/demux-rotation}
INFO_AUDIO_FORMAT=${=audio-codec-name}
INFO_AUDIO_CODEC=${=audio-codec}
INFO_AUDIO_RATE=${=audio-params/samplerate}
INFO_AUDIO_NCH=${=audio-params/channel-count}
INFO_LENGTH=${=duration:${=length}}
INFO_DEMUXER=${=current-demuxer:${=demuxer}}
INFO_SEEKABLE=${=seekable}
INFO_TITLES=${=disc-titles}
INFO_CHAPTERS=${=chapters}
INFO_TRACKS_COUNT=${=track-list/count}
METADATA_TITLE=${metadata/by-key/title:}
METADATA_ARTIST=${metadata/by-key/artist:}
METADATA_ALBUM=${metadata/by-key/album:}
METADATA_GENRE=${metadata/by-key/genre:}
METADATA_DATE=${metadata/by-key/date:}
METADATA_TRACK=${metadata/by-key/track:}
METADATA_COPYRIGHT=${metadata/by-key/copyright:}
INFO_MEDIA_TITLE=${=media-title:}
INFO_STREAM_PATH=${stream-path}
 --audio-client-name=SMPlayer --term-status-msg=STATUS: ${=time-pos} / 
${=duration:${=length:0}} P: ${=pause} B: ${=paused-for-cache} I: ${=core-idle} 
VB: ${=video-bitrate:0} AB: ${=audio-bitrate:0} /data/pics/videos/trever/trever 
and chris grappling part 3.webm

 (+) Video --vid=1 (*) (vp8 640x480 30.000fps)
 (+) Audio --aid=1 (*) (vorbis 1ch 44100Hz)
[vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 8, serial: 12
[vo/x11/x11] Error code: 9, request code: e, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 8, serial: 13
[vo/x11/x11] Error code: 3, request code: 28, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 8, serial: 16
[vo/x11/x11] Error code: 3, request code: 2, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 8, serial: 18
[vo/x11/x11] Error code: 3, request code: 1, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 1b
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 1e
[vo/x11/x11] Error code: 3, request code: 91, minor code: 3
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 20
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 21
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11] Warning: this legacy VO has bad performance. Consider fixing your 
graphics drivers, or not forcing the x11 VO.
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 23
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11/x11] X11 error: BadWindow (invalid Window parameter)
[vo/x11/x11] Type: 0, display: 0x7febb40456b0, resourceid: 322, serial: 24
[vo/x11/x11] Error code: 3, request code: 12, minor code: 0
[vo/x11/x11] X11 error: BadDrawable (invalid Pixmap or Window parameter)
[vo/x11/x11] Type: 0, display: 

Bug#1037541: libguestfs: FTBFS: supermin: error: lstat: Value too large for defined data type: /var/tmp/supermin2b73c8.tmpdir/base.d/init

[Richard W.M. Jones]

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

I think what's happening here is we are using the 31/32 bit lstat
functions in OCaml:

  
https://github.com/ocaml/ocaml/blob/3d50c168062e9fdbacf739a73738b10108ff3628/otherlibs/unix/unix.mli#L500

(I guess st_size which is signed 31 bits on armv7, but 63 bits on 64 bit
platforms).  We ought to be using the 64 bit version instead:

  
https://github.com/ocaml/ocaml/blob/3d50c168062e9fdbacf739a73738b10108ff3628/otherlibs/unix/unix.mli#L544

The specific problem will be that the size of some file has grown
larger than 1GB resulting in this runtime error, although that seems unusual.

Now we *ought* to be using those functions already because we should
always be doing:

  open Unix
  open Unix.LargeFile

to use the "LargeFile" (64 bit) versions of the functions.  I had a
quick look through the code to see where we are using 'open Unix'
without 'open Unix.LargeFile' but I couldn't find the place, leaving
me confused.

(Of course the other problem is that Fedora has abandoned all 32 bit
platforms long ago so we never test this ...)

Practically my recommendation is to exclude the whole virt stack on
armv7 since it has been years since we tested it.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

Bug#1037013: libexiv2-27 0.27.3-3+deb11u2 makes gthumb crash

[Martin Tharby Jones]

Package: libexiv2-27
Version: 0.27.3-3+deb11u2
Severity: important
X-Debbugs-Cc: mar...@brasskipper.org.uk, t...@security.debian.org

Dear Maintainer,

The latest update causes gthumb crash it worked with Version: 0.27.3-3+deb11u1

martin@ant:~$ gthumb

(gthumb:8908): Gtk-WARNING **: 15:10:24.901: Failed to register client:
GDBus.Error:org.gnome.SessionManager.AlreadyRegistered: Unable to register
client
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::at: __n (which is 19) >= this->size() (which is 19)
Aborted
martin@ant:~$

This looks like a known bug see
https://bugs.launchpad.net/ubuntu/+source/exiv2/+bug/1942799

martin@ant:~$ gdb -q gthumb
Reading symbols from gthumb...
(gdb) start
Temporary breakpoint 1 at 0xf85b9: file ../gthumb/main.c, line 47.
Starting program: /usr/local/bin/gthumb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe138) at
../gthumb/main.c:47
47  program_argv0 = argv[0];
(gdb) c
Continuing.
[New Thread 0x755cb700 (LWP 9597)]
[New Thread 0x7fffee4e6700 (LWP 9598)]
[New Thread 0x7fffe1926700 (LWP 9599)]
[New Thread 0x7fffdbfff700 (LWP 9600)]
[New Thread 0x7fffe1125700 (LWP 9601)]
[New Thread 0x7fffe0924700 (LWP 9602)]

(gthumb:9593): Gtk-WARNING **: 15:28:39.706: Failed to register client:
GDBus.Error:org.gnome.SessionManager.AlreadyRegistered: Unable to register
client
[New Thread 0x7fffdb7fe700 (LWP 9604)]
[New Thread 0x7fffd9940700 (LWP 9605)]
[New Thread 0x7fffd913f700 (LWP 9606)]
terminate called after throwing an instance of 'std::out_of_range'
  what():  basic_string::at: __n (which is 19) >= this->size() (which is 19)

Thread 9 "pool-gthumb" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffd9940700 (LWP 9605)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x76c30537 in __GI_abort () at abort.c:79
#2  0x744fe7ec in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x74509966 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x745099d1 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x74509c65 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x74501113 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x7fffdac3db16 in  () at /lib/x86_64-linux-gnu/libexiv2.so.27
#8  0x7fffdabcbcdd in Exiv2::Xmpdatum::write(std::ostream&, Exiv2::ExifData
const*) const ()
at /lib/x86_64-linux-gnu/libexiv2.so.27
#9  0x7fffdab961c1 in Exiv2::Metadatum::print[abi:cxx11](Exiv2::ExifData
const*) const ()
at /lib/x86_64-linux-gnu/libexiv2.so.27
#10 0x7fffdadf02c2 in exiv2_read_metadata(Exiv2::Image::AutoPtr,
GFileInfo*, gboolean)
(image=..., info=0x56134b30, update_general_attributes=1)
at ../extensions/exiv2_tools/exiv2-utils.cpp:830
#11 0x7fffdadf08ad in exiv2_read_metadata_from_file(GFile*, GFileInfo*,
gboolean, GCancellable*, GError**)
(file=0x55908d40, info=0x56134b30, update_general_attributes=1,
cancellable=0x56111520, error=0x0) at
../extensions/exiv2_tools/exiv2-utils.cpp:888
#12 0x7fffdadf69c2 in gth_metadata_provider_exiv2_read
(base=0x7fffc808f650, file_data=0x561966f0, attributes=0x562053d0
"standard::type,standard::is-hidden,standard::is-
backup,standard::name,standard::display-name,standard::edit-
name,standard::icon,standard::symbolic-
icon,standard::size,thumbnail::pathtime::created,time"...,
cancellable=0x56111520)
at ../extensions/exiv2_tools/gth-metadata-provider-exiv2.c:124
#13 0x55620807 in gth_metadata_provider_read
(self=0x7fffc808f650, file_data=0x561966f0, attributes=0x562053d0
"standard::type,standard::is-hidden,standard::is-
backup,standard::name,standard::display-name,standard::edit-
name,standard::icon,standard::symbolic-
icon,standard::size,thumbnail::pathtime::created,time"...,
cancellable=0x56111520)
at ../gthumb/gth-metadata-provider.c:117
#14 0x55620a16 in _g_query_metadata_async_thread
(task=0x561a6330, source_object=0x0, task_data=0x5610bbf0,
cancellable=0x56111520)
at ../gthumb/gth-metadata-provider.c:215
#15 0x77c0204e in  () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#16 0x77daf9a4 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x77daf0bd in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x76debea7 in start_thread (arg=) at
pthread_create.c:477
#19 0x76d09a2f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) c
Continuing.
[Thread 0x7fffd913f700 (LWP 9606) exited]
[Thread 0x7fffd9940700 (LWP 9605) exited]
[Thread 0x7fffdb7fe700 (LWP 9604) exited]
[Thread 0x7fffe1125700 (LWP 9601) exited]
[Thread 0x7fffdbfff700 (LWP 9600) exited]
[Thread 

Bug#1036795: ITP: sphinx-design -- sphinx extension for creating responsive web components

[Dave Jones]

An initial attempt at packaging is now available in the following repo 
on salsa:


https://salsa.debian.org/python-team/packages/sphinx-design

The one stumbling block was that sphinx-design relies on FontAwesome for 
some of its icon styles. That's fine for docs built for the web, but for 
the offline docs package (python-sphinx-design-doc) that brings up an 
obvious privacy-breach-generic tag on lintian.


After reading through bug #902981 I patched around this by adding a dep 
on fonts-fork-awesome and patching the docs/conf.py to use the 
fork-awesome CSS in the local docs build instead. Please note this won't 
affect output built with the main package (python3-sphinx-design); it 
simply ensures that the offline copy of the docs really is offline.

Bug#1036795: ITP: sphinx-design -- sphinx extension for creating responsive web components

[Dave Jones]

Package: wnpp
Severity: wishlist
Owner: Dave Jones 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: sphinx-design
  Version : 0.4.1
  Upstream Author : Executable Books
* URL : https://sphinx-design.readthedocs.io/en/latest/
* License : MIT
  Programming Lang: Python
  Description : sphinx extension for creating responsive web components

This is the intended successor [1] to the sphinx-panels extension, which 
is currently in Debian. The intent is to maintain it from the python 
team.

[1]: 
https://sphinx-design.readthedocs.io/en/latest/get_started.html#migrating-from-sphinx-panels

Bug#1032932: git-buildpackage: --no-sign-tags doesn't take effect if git config says to sign tags

[Huw Jones]

Package: git-buildpackage
Version: 0.9.22
Severity: important
Tags: patch
X-Debbugs-Cc: h...@pexip.com

Dear Maintainer,

My gitconfig contains
[tag]
gpgsign = true
When calling 
gbp import-dsc --pristine-tar --no-sign-tags
I get prompted by gpg to sign my tags.
With the `--no-sign-tags` option, I would expect it to instruct git to **not** 
sign tags.
The following patch (also available 
https://github.com/pexip/os-git-buildpackage/commit/8ef3ec7880caaf167429426142b0aa965ee41dd5)
resolves the issue for me.

diff --git a/gbp/git/repository.py b/gbp/git/repository.py
index e21b19e..90c8395 100644
--- a/gbp/git/repository.py
+++ b/gbp/git/repository.py
@@ -676,6 +676,8 @@ class GitRepository(object):
 if sign:
 args += ['-s']
 args += ['-u', keyid] if keyid else []
+else:
+args += ['--no-sign']
 args += [name]
 args += [commit] if commit else []
 self._git_command("tag", args)

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

Kernel: Linux 5.10.0-17-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.21.3+deb11u1
ii  git1:2.30.2-1
ii  man-db 2.9.4-2
ii  python33.9.2-3
ii  python3-dateutil   2.8.1-6pexip3
ii  python3-pkg-resources  52.0.0-4
ii  sensible-utils 0.0.14

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.89
ii  pbuilder  0.231
ii  pristine-tar  1.49
ii  python3-requests  2.25.1+dfsg-2

Versions of packages git-buildpackage suggests:
pn  python3-notify2  
ii  sudo 1.9.5p2-3
ii  unzip6.0-26+deb11u1

-- no debconf information

Bug#1019701: RFP: rpi-imager -- Raspberry Pi Imaging Utility

[Dave Jones]

Hi Francois, Lin,

I'm the maintainer for the current Ubuntu packaging of rpi-imager [1]. 
If Debian's interested in adding this, there's a few changes in the 
Ubuntu packaging that *might* interest Debian (in particular the bits 
that include the JSON schema documentation, and patch out the privacy 
violations that lintian then warns about, and possibly the d/watch file 
as well).


I'm currently prepping the packaging for 1.7.4 but it's a little 
complicated by the new "no-big-endian" check [2] which obviously breaks 
the s390x build. I should probably just disable that build but a part of 
me is tempted to "just fix it"!


Oh, and 1.7.4 also includes the man-page that I previously patched into 
1.7.3 [3].


Anyway, do feel free to grab anything from there if it's wanted!

[1]: https://launchpad.net/ubuntu/+source/rpi-imager/1.7.3+noembed-0ubuntu1

[2]: 
https://github.com/raspberrypi/rpi-imager/commit/142ddfc0370e75a2f49e8c119e5b467f38e6f839

[3]: https://github.com/raspberrypi/rpi-imager/pull/491

Best regards,

Dave Jones.

Bug#1031701: python3-pandas: Pandas requires version '2.0.1' or newer of 'xlrd'

[Christopher Jones]

Hi,

Sadly they really are .xls files rather than the more slightly more sane .xlsx.

Thanks!

—
Chris

> On 20 Feb 2023, at 22:39, Rebecca N. Palmer  wrote:
> 
> Is the file you're trying to open .xlsx or .xls?  Do you have 
> python3-openpyxl installed?  If .xlsx and no, try installing it.
> 
> (python3-)xlrd 2.0+ can only open .xls files, not .xlsx.  Hence, pandas 1.5+ 
> read_excel() always uses (python3-)openpyxl for .xlsx files. python3-pandas 
> already Recommends python3-openpyxl.  (This intentionally isn't a hard 
> Depends because pandas can be used on other data formats without it, but the 
> error message probably should point to openpyxl not xlrd.)

Bug#1031701: python3-pandas: Pandas requires version '2.0.1' or newer of 'xlrd'

[Christopher Jones]

Package: python3-pandas
Version: 1.5.3+dfsg-1
Severity: normal

Dear Maintainer,

When attempting to use pandas read_excel function I get the following error 
message:
ImportError: Pandas requires version '2.0.1' or newer of 'xlrd' (version 
'1.2.0' currently installed).

xlrd 1.2 appears to be the latest currently available release packaged for 
Debian.

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

Bug#1031693: import-dsc: dangling pristine-tar treeish with multiple components

[Huw Jones]

Package: git-buildpackage
Version: 0.9.22
Severity: important
X-Debbugs-Cc: h...@pexip.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***
import-dsc leaves a dangling treeish when importing a dsc with multiple 
components.

For example, sqlite3

```
$ dget --download-only --quiet --allow-unauthenticated 
http://ftp.debian.org/debian/pool/main/s/sqlite3/sqlite3_3.34.1-3.dsc
$ gbp import-dsc -v --pristine-tar sqlite3_3.34.1-3.dsc
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: Upstream version: 3.34.1
gbp:debug: Debian version: 3
gbp:debug: Upstream tarball: /tmp/sqlite3/sqlite3_3.34.1.orig.tar.xz
gbp:debug: Additional tarballs: /tmp/sqlite3/sqlite3_3.34.1.orig-www.tar.xz
gbp:debug: Debian patch: /tmp/sqlite3/sqlite3_3.34.1-3.debian.tar.xz
gbp:info: No git repository found, creating one.
gbp:debug: ['git', 'init']
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: tar ['-C', '/tmp/sqlite3/tmp4mt7atb8', '-a', '-xf', 
'/tmp/sqlite3/sqlite3_3.34.1.orig.tar.xz'] []
gbp:info: Found component tarball 'sqlite3_3.34.1.orig-www.tar.xz'
gbp:debug: tar ['-C', '/tmp/sqlite3/tmp4mt7atb8/tmpcrfvrq1w', '-a', '-xf', 
'/tmp/sqlite3/sqlite3_3.34.1.orig-www.tar.xz'] []
gbp:debug: rm ['-rf', '/tmp/sqlite3/tmp4mt7atb8/tmpcrfvrq1w'] []
gbp:debug: ['git', 'tag', '-l', 'debian/3.34.1-3']
gbp:debug: ['git', 'tag', '-l', 'debian/3.34.1-3']
gbp:debug: ['git', 'tag', '-l', 'upstream/3.34.1']
gbp:debug: ['git', 'tag', '-l', 'upstream/3.34.1']
gbp:debug: ['git', 'tag', '-l', 'upstream/3.34.1']
gbp:debug: ['git', 'tag', '-l', 'upstream/3.34.1']
gbp:debug: ['git', 'add', '-f', '.']
gbp:debug: ['git', 'write-tree']
gbp:debug: ['git', 'commit-tree', '1d6f0d8b6276d7ee72fa76fcd2e4cd2d35b86b33']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: Import Upstream version 3.34.1', 
'refs/heads/master', 'cefbc7af913751e761e8b9ff7beb83e0d3f59abe']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/master']
gbp:debug: ['git', 'branch', 'upstream', 'master']
gbp:debug: ['git', 'tag', '-m', 'Upstream version 3.34.1', 'upstream/3.34.1', 
'cefbc7af913751e761e8b9ff7beb83e0d3f59abe']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/master']
gbp:debug: tar ['-C', '.', '-a', '-xf', 
'/tmp/sqlite3/sqlite3_3.34.1-3.debian.tar.xz'] []
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 
'cefbc7af913751e761e8b9ff7beb83e0d3f59abe^{commit}']
gbp:debug: ['git', 'branch', '--contains', 
'cefbc7af913751e761e8b9ff7beb83e0d3f59abe']
gbp:debug: ['git', 'add', '-f', '.']
gbp:debug: ['git', 'write-tree']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'master']
gbp:debug: ['git', 'commit-tree', 'a39172afdec174692199169ccecf1578cfc4b84e', 
'-p', 'cefbc7af913751e761e8b9ff7beb83e0d3f59abe']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: Import Debian changes 3.34.1-3', 
'refs/heads/master', '9ab03e07211eb7c103ebd31fabc5325f47cd2d8d', 
'cefbc7af913751e761e8b9ff7beb83e0d3f59abe']
gbp:debug: ['git', 'tag', '-m', 'Debian release 3.34.1-3', 'debian/3.34.1-3', 
'9ab03e07211eb7c103ebd31fabc5325f47cd2d8d']
gbp:debug: ['git', 'ls-tree', '-z', 'cefbc7af913751e761e8b9ff7beb83e0d3f59abe', 
'--']
gbp:debug: ['git', 'mktree', '-z']
gbp:debug: ['git', 'ls-tree', '-z', 'cefbc7af913751e761e8b9ff7beb83e0d3f59abe', 
'--']
gbp:debug: Creating pristine tar commit 
'/tmp/sqlite3/sqlite3_3.34.1.orig-www.tar.xz' from 
'caa99a00bc6709686138dd8813a810f6fa9eef90'
gbp:debug: pristine-tar [] ['commit', 
'/tmp/sqlite3/sqlite3_3.34.1.orig-www.tar.xz', 
'caa99a00bc6709686138dd8813a810f6fa9eef90']
gbp:debug: pristine-tar [] ['commit', 
'/tmp/sqlite3/sqlite3_3.34.1.orig.tar.xz', 
'b8d2ba8963a49f910bb8dfe27e0a3926c3f9a72c']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/master']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'master']
gbp:debug: ['git', 'reset', '--quiet', '--hard', 
'9ab03e07211eb7c103ebd31fabc5325f47cd2d8d', '--']
gbp:debug: rm ['-rf', '/tmp/sqlite3/tmp4mt7atb8'] []
gbp:info: Version '3.34.1-3' imported under '/tmp/sqlite3/sqlite3'
```

gbp imports ok, but leaves a dangling tree-ish
```
$ git fsck --lost-found
Checking object directories: 100% (256/256), done.
dangling tree b8d2ba8963a49f910bb8dfe27e0a3926c3f9a72c
```

This means that if you push (not mirror), or prune dangling objects, you cannot 
checkout the main tarball.
```
$ git reflog expire --expire=now && git gc --aggressive --prune=now && git fsck 
--lost-found
Enumerating objects: 2909, done.
Counting objects: 100% (2909/2909), done.
Delta compression using up to 16 threads
Compressing objects: 100% (2884/2884), done.

Bug#1026409:

[Christopher Jones]

hg-git release 1.0.1 appears to the first release they claim to support 
Mercurial 6.2, updating this package to that release seems like a likely fix.

https://foss.heptapod.net/mercurial/hg-git/-/tags/1.0.1

Thanks!

Bug#1026409: mercurial-git currently broken in testing

[Christopher Jones]

Subject: mercurial-git currently broken in testing
Package: mercurial-git
Version: 0.10.4-4
Severity: important

Dear Maintainer,

mercurial-git is currently broken in Debian testing.

Attempting to clone a git repo results in the following error:

importing git objects into hg
transaction abort!
rollback completed
** Unknown exception encountered with possibly-broken third-party extension 
"hggit" 0.10.4 (dulwich 0.20.50)
** which supports versions 6.1 of Mercurial.
** Please disable "hggit" and try your action again.
** If that fixes the bug please report it to 
https://foss.heptapod.net/mercurial/hg-git/issues
** Python 3.10.9 (main, Dec  7 2022, 13:47:07) [GCC 12.2.0]
** Mercurial Distributed SCM (version 6.2.3)
** Extensions loaded: hggit 0.10.4 (dulwich 0.20.50)
Traceback (most recent call last):
  File "/usr/bin/hg", line 59, in 
dispatch.run()
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 143, in run
status = dispatch(req)
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 232, in 
dispatch
status = _rundispatch(req)
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 276, in 
_rundispatch
ret = _runcatch(req) or 0
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 451, in 
_runcatch
return _callcatch(ui, _runcatchfunc)
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 461, in 
_callcatch
return scmutil.callcatch(ui, func)
  File "/usr/lib/python3/dist-packages/mercurial/scmutil.py", line 153, in 
callcatch
return func()
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 441, in 
_runcatchfunc
return _dispatch(req)
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1254, in 
_dispatch
return runcommand(
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 899, in 
runcommand
ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1266, in 
_runcommand
return cmdfunc()
  File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1252, in 

d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
  File "/usr/lib/python3/dist-packages/mercurial/util.py", line 1880, in check
return func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/mercurial/commands.py", line 5463, in 
pull
modheads = exchange.pull(
  File "/usr/lib/python3/dist-packages/hggit/util.py", line 63, in inner
return f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/hggit/__init__.py", line 563, in 
exchangepull
pullop.cgresult = repo.githandler.fetch(remote.path, heads)
  File "/usr/lib/python3/dist-packages/hggit/git_handler.py", line 308, in fetch
imported = self.import_git_objects(remote_name, filteredrefs)
  File "/usr/lib/python3/dist-packages/hggit/git_handler.py", line 850, in 
import_git_objects
self.import_git_commit(commit)
  File "/usr/lib/python3/dist-packages/hggit/git_handler.py", line 1078, in 
import_git_commit
node = unfiltered.commitctx(ctx)
  File "/usr/lib/python3/dist-packages/mercurial/localrepo.py", line 236, in 
wrapper
return orig(repo.unfiltered(), *args, **kwargs)
  File "/usr/lib/python3/dist-packages/mercurial/localrepo.py", line 3247, in 
commitctx
return commit.commitctx(self, ctx, error=error, origctx=origctx)
  File "/usr/lib/python3/dist-packages/mercurial/commit.py", line 84, in 
commitctx
n = repo.changelog.add(
  File "/usr/lib/python3/dist-packages/mercurial/changelog.py", line 611, in add
extra = encodeextra(extra)
  File "/usr/lib/python3/dist-packages/mercurial/changelog.py", line 85, in 
encodeextra
items = [_string_escape(b'%s:%s' % (k, d[k])) for k in sorted(d)]
  File "/usr/lib/python3/dist-packages/mercurial/changelog.py", line 85, in 

items = [_string_escape(b'%s:%s' % (k, d[k])) for k in sorted(d)]
TypeError: %b requires a bytes-like object, or an object that implements 
__bytes__, not 'generator'

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

Kernel: Linux 6.0.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mercurial-git depends on:
ii  mercurial [python3-mercurial]  6.2.3-1+b1
ii  python33.10.6-1
ii  python3-dulwich0.20.50-1+b1

mercurial-git recommends no packages.

mercurial-git suggests no packages.

-- no debconf information

--
Chris Jones

Bug#1014177: qemu-user-static: QEMU aarch64 user mode emulation always segfaults

[Tony Garnock-Jones]

On Tue, 13 Sep 2022 23:42:19 +0300 Michael Tokarev  wrote:

I uploaded new upstream release of qemu a few days ago, 7.1, can you verify
if that one makes any difference?


It looks hopeful at least for my use cases!

# dpkg --add-architecture arm64
# apt update
# apt install hello:arm64
# apt install qemu-user-static binfmt-support
# hello
Hello, world!

# apt install docker.io
# docker run -it --rm --platform=linux/arm64 alpine:edge uname -m
aarch64

# dpkg -l qemu-user-static binfmt-support hello
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----==
ii  binfmt-support   2.2.2-1  amd64Support for extra binary 
formats
ii  hello:arm64  2.10-2   arm64example package based on 
GNU hello
ii  qemu-user-static 1:7.1+dfsg-2 amd64QEMU user mode emulation 
binaries (static version)



Thank you!

Regards,
  Tony

Bug#1014177: qemu-user-static: QEMU aarch64 user mode emulation always segfaults

[Tony Garnock-Jones]

Hi,

I think I'm seeing the same thing. Reproduction from a fresh install of 
bookworm on an x86_64 host:


# dpkg --add-architecture arm64
# apt update
# apt install hello:arm64
# apt install qemu-user-static binfmt-support
# hello
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

This is the probable cause of a problem I was trying to resolve with 
docker, namely that running an aarch64 container hangs. To reproduce 
*that*, follow the above steps, then:


# apt install docker.io
# docker run -it --rm --platform=linux/arm64 alpine:edge uname -m
(it hangs and never prints anything)
(which is different from the behaviour for e.g. 32 bit arm)

Could this be related to

 - Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999421
 - Upstream qemu issue https://gitlab.com/qemu-project/qemu/-/issues/555

?

Tony

Bug#1011273: sbuild: autopkgtest unshare is not running dscverify

[Dave Jones]

Package: sbuild
Version: 0.79.0-1ubuntu1
Severity: normal
Tags: patch

Dear Maintainer,

While working on merging the current sbuild from Debian unstable to 
Ubuntu I noticed something a bit odd in the "unshare" test (both in our 
delta with Debian, but also in the Debian original):

At the top of verify() in unshare [1], the routine attempts to assign 
its arguments to some variables:

verify_src="${1+no}"
verify_bin="${1+no}"

Unfortunately, there's a couple of errors here. Firstly only the first
argument is used ($2 never gets a look in). But secondly, the "+" 
expansion ("use alternative value") means that, if $1 is "" the result 
is "" but otherwise the result is "no". So verify_src and verify_bin can 
only *ever* be "no"; they can never be "yes". This means the dscverify 
sections later on never get called.

Our delta in Ubuntu compounds these mistakes by also making the orig and 
deb sections optional and ... also using $1 and the "+" expansion [2].
Oops!

Firstly, instead of relying on a bunch of boolean yes/no parameters I 
think it might be nicer to simply list the things we'd like verify to 
check (e.g. "verify orig deb dsc"), which I've done in a local branch. 
Once that change was in place I also discovered that dscverify still 
never ran because it never gets installed in the system setup by the 
qemu-wrapper script because devscripts is missing from EXTRA_DEPS there.

Finally, once this was all working I discovered that the .dsc file 
should *not* be checked when sbuild is run *without* the "--source" 
option because, although the .dsc file is produced in this case, it 
isn't signed (presumably because it doesn't get listed in the .changes) 
file. To fix this I separated the .dsc and .changes checks into their 
own sub-routines and modified the calls to verify() accordingly.

I'm attaching a patch which fixes the issue, but once I've got a bug 
number I'll propose the changes as an MR on salsa for convenience.

[1]: 
https://salsa.debian.org/debian/sbuild/-/blob/main/debian/tests/unshare#L71

[2]: 
https://git.launchpad.net/ubuntu/+source/sbuild/tree/debian/tests/unshare?h=applied/ubuntu/devel=23ce4fa3e9bbe83ca70a23224c2c3f8829078227#n80


Best regards,

Dave Jones.
diff --git a/debian/tests/unshare b/debian/tests/unshare
index 2c45a1fe..b9013eb1 100755
--- a/debian/tests/unshare
+++ b/debian/tests/unshare
@@ -20,6 +20,7 @@ chmod 700 "${AUTOPKGTEST_TMP}/gpghome"
 export GNUPGHOME="${AUTOPKGTEST_TMP}/gpghome"
 
 verify_orig() {
+   echo "verifying test-pkg_1.0.tar.xz" >&2
 cat << END | base64 -d > "${AUTOPKGTEST_TMP}/expected"
 /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/BBZdADoZSs4dfiUjFYSOxzYxnd+/m6AlVEVOGf2j
 nT6NK0F9XZ7LLydbY3I//WjMOM2RFpGUqZ8R8Q8lLmydB5SLN5ZQSPW3OJjHlzxVQmv2v3KUyPxo
@@ -47,6 +48,7 @@ END
 }
 
 verify_deb() {
+   echo "verifying test-pkg_1.0_all.deb" >&2
 cat << END | base64 -d > "${AUTOPKGTEST_TMP}/expected"
 ITxhcmNoPgpkZWJpYW4tYmluYXJ5ICAgMTQ2NzMxMDUxMiAgMCAgICAgMCAgICAgMTAwNjQ0ICA0
 ICAgICAgICAgYAoyLjAKY29udHJvbC50YXIueHogIDE0NjczMTA1MTIgIDAgICAgIDAgICAgIDEw
@@ -68,26 +70,31 @@ END
rm "${AUTOPKGTEST_TMP}/expected"
 }
 
-verify() {
-   verify_src="${1+no}"
-   verify_bin="${1+no}"
-   echo "verifying test-pkg_1.0.tar.xz" >&2
-   verify_orig
-   echo "verifying test-pkg_1.0_all.deb" >&2
-   verify_deb
+verify_dsc() {
# we shouldn't have to manually pass the keyring because the path is an
# implementation detail of gnupg (it used to be named pubring.gpg in
# the past) but dscverify ignores GNUPGHOME, see Debian bug #981008
-   if [ "$verify_bin" = "yes" ]; then
-   echo "verifying test-pkg_1.0.dsc" >&2
-   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" 
"${AUTOPKGTEST_TMP}/test-pkg_1.0.dsc"
-   echo "verifying test-pkg_1.0_${nativearch}.changes" >&2
-   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" 
"${AUTOPKGTEST_TMP}/test-pkg_1.0_${nativearch}.changes"
-   fi
-   if [ "$verify_src" = "yes" ]; then
-   echo "verifying test-pkg_1.0_source.changes" >&2
-   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" 
"${AUTOPKGTEST_TMP}/test-pkg_1.0_source.changes"
-   fi
+   echo "verifying test-pkg_1.0.dsc" >&2
+   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" \
+   "${AUTOPKGTEST_TMP}/test-pkg_1.0.dsc"
+}
+
+verify_bin_changes() {
+   echo "verifying test-pkg_1.0_${nativearch}.cha

Bug#1007924: RFS: rshell/0.0.31-1 [ITP] -- Remote shell for working with MicroPython boards

[Dave Jones]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: rshell
   Version : 0.0.31-1
   Upstream Author : https://github.com/dhylands/rshell
 * URL : https://github.com/dhylands/rshell
 * License : MIT
 * Vcs : https://salsa.debian.org/python-team/packages/rshell
   Section : python

The source builds the following binary packages:

  python3-rshell - Remote shell for working with MicroPython boards - python3 
library
  rshell - Remote shell for working with MicroPython boards

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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/r/rshell/rshell_0.0.31-1.dsc

Changes for the initial release:

 rshell (0.0.31-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1007924)

Thanks for you consideration!

--
  Dave Jones



signature.asc
Description: PGP signature

Bug#1007924: ITP: rshell -- A remote shell for working with MicroPython boards

[Dave Jones]

Package: wnpp
Severity: wishlist
Owner: Dave Jones 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: rshell
  Version : 0.0.31-1
  Upstream Author : https://github.com/dhylands/rshell
* URL : https://pypi.org/project/rshell/
* License : MIT
  Programming Lang: Python
  Description : A remote shell for working with MicroPython boards

A simple shell which runs on the host and uses MicroPython's raw-REPL to 
send Python snippets to the board in order to get file-system 
information, to copy files to and from MicroPython's file-system. It 
also has the ability to invoke the MicroPython REPL, so rshell can be 
used as a terminal emulator as well.

Currently, the standard method for installing this is to use pip3. 
However, given it has minimal dependencies (pyserial and pyudev) which 
are already packaged nicely in Debian, there's no particular reason this 
shouldn't be deb-packaged too. The only other (direct) means of 
manipulating the file-system on a MicroPython device currently available 
in Debian (that I'm aware of) is the Thonny editor. However, Thonny 
requires a graphical environment, whilst rshell is also suitable for 
console only environments.

I'm happy to maintain this package as part of the Python team.

Bug#1006147: Merge request

[Dave Jones]

I've now submitted the following merge request for this issue:

https://salsa.debian.org/pkg-debconf/debconf/-/merge_requests/10


Best regards,

Dave Jones.

Bug#1006147: debconf: dpkg-reconfigure fails to restart services after #994204

[Dave Jones]

Package: debconf
Version: 1.5.73
Severity: important

Dear Maintainer,

As part of fixing an issue with restarting services in debhelper 
(#994204), I proposed a patch [1] that, in certain circumstances (when 
--no-restart-after-upgrade is specified) moves the duty of stopping 
services from the prerm maintainer script to the preinst maintainer 
script (see #994204 for the reasoning behind this change). That fix has 
been merged in Debian, although not yet released. In Ubuntu, the fix has 
also been merged and is currently in our -proposed pocket.

One issue [2] that arose during the testing of the fix was that, for the 
slapd service (part of the openldap package), dpkg-reconfigure now 
failed to restart the service. The slapd service is indeed declared with 
--no-restart-after-upgrade and, and digging into dpkg-reconfigure's code 
I found that it runs prerm, config, and postinst, but not preinst. 
Hence, with services using --no-restart-after-upgrade, prerm no longer 
stops the service and by the time it gets to postinst, the "start" 
operation there has nothing to do.

My assumption is that prerm was only in that sequence to stop services 
(it's seems a little odd to me for it to be in dpkg-reconfigure 
otherwise? Am I missing something else there?). However, I'm guessing 
that replacing prerm with preinst would lead to breakage in packages 
that assume prerm is still run by dpkg-reconfigure. Instead, I'm 
proposing to add preinst to the list of maintainer scripts run by 
dpkg-reconfigure. I'll propose a merge request to the debconf salsa repo 
that adds preinst to the list, and update this with the link shortly.

Many thanks for any attention you can give this, and for any light you 
can shed on my assumptions above. If you need any more detail on the 
reasoning behind the fix for #994204 (and its related issue #989155), 
please let me know.

[1]: https://salsa.debian.org/debian/debhelper/-/merge_requests/61

[2]: https://bugs.launchpad.net/bugs/1959054 (comment # 15 onwards)


Best regards,

Dave Jones.

Bug#994204: Fix merged; package rebuilds needed after release

[Dave Jones]

Thanks to Niels Thykier, the proposed fix [1] was merged over the 
weekend. When debhelper is next released, this should at least deal with 
the issue for future package builds. However, packages built after the 
release of 13.4 (which first incorporated the fix for #989155 which 
caused this issue) ought to have a rebuild in order to correct their 
generated maintainer scripts.


I've had a search of DCS [2] (thanks to Christian for informing me of 
this excellent resource!) and gone through all packages that match 
--no-(stop-after|restart-(on|after))-upgrade in their source (I've 
stripped out those that obviously don't apply like debhelper itself, or 
the odd one that only mentioned these in their historical changelogs, or 
within their code, like dh-runit).


The resulting list is ~80 packages long but please bear in mind that 
this *may not* be comprehensive. In particular, packages might be using 
the short form of these options (-r or -R), but for obvious reasons 
searching for these forms would be impractical. Still, I have a sneaking 
suspicion that most package maintainers tend to stick to the long-form 
of these options so I'd hope the list captures the majority of packages 
that need rebuilding.


Once the fix makes it into a debhelper release, the following packages 
ought to be rebuilt:


aoetools
apcupsd
apparmor
apt
apt-cacher-ng
aumix
bip
buildbot
ceph
chrony
cloud-init
cpufrequtils
dbus
dbus-broker
docker.io
dpdk
drbd-utils
fsprotect
g810-led
ganeti
gdnsd
gpm
h2o
haproxy
ifupdown
ifupdown-ng
iipimage
inetsim
inspircd
iwd
libvirt
live-config
live-tools
lizardfs
lxc
lxcfs
moosefs
nghttp2
nginx
ngtcp2
nodm
ntp
nullmailer
ocfs2-tools
open-infrastructure-compute-tools
open-iscsi
openstack-cluster-installer
open-vm-tools
openvpn
pacemaker
packagekit
pdudaemon
phosh
plymouth
policycoreutils
python-certbot
qcontrol
qemu
quassel
robustirc-bridge
rpcbind
runit
samba
sanlock
sbd
sbuild
slim
sysstat
systemd
tarantool
targetcli-fb
tgt
tlp
ufw
umtp-responder
unscd
wdm
whereami
xrdp
yubikey-luks
zfs-linux

[1]: https://salsa.debian.org/debian/debhelper/-/merge_requests/61

[2]: 
https://codesearch.debian.net/search?q=--no-%28stop-after%7Crestart-%28on%7Cafter%29%29-upgrade=0



Best regards,

Dave Jones.

Bug#994204: MR for #994204

[Dave Jones]

Hi,

I've opened a tentative fix for this [1]. I've included a (hopefully!) 
comprehensive write-up in the description of the MR, but for the sake of 
completeness here's an e-mail friendly copy:


There are two bugs addressed in this request; mostly it undoes the 
original fix for #989155, and then fixes that in such a way that #994204 
does not occur.


The original issue (#989155) dealt with moving a package from the new 
default restart behaviour ("--restart-after-upgrade", indicating 
services should be restarted in a single step after file unpacking) to 
the older restart behaviour ("--no-restart-after-upgrade", indicating 
services should be stopped prior to unpacking, then started again at the 
end of installation. The crux of this issue is, with the 
"--no-restart-after-upgrade" option, *two* versions of the package are 
involved in stopping and restarting the service. Specifically, the 
"prerm" script of the *old* version of the package stops services, then 
the "postinst" script of the *new* version of the package starts 
services.


The original fix for this issue (in commit 6067bc2f [2] and 5b27a541 
[3]), handled this by leaving the stop behaviour in "prerm" and 
modifying the start behaviour in "postinst" to always *restart* (with 
the unfortunate consequence found in #994204).


I think it may be preferable to instead move the stop behaviour to the 
"preinst" script of the *new* version of the package so that both stop 
and start behaviours are encapsulated in a *single* version of the 
package (and hence can be freely moved between). This also means that 
"postinst" script's prior behaviour can be restored.


To that end, the MR first reverts the two commits associated with 
#989155, then adds a third commit that adds a "preinst" script for 
"dh_installinit" and "dh_installsystemd" (and tidies up a little of the 
substitution handling in the former). The test suite still passes for 
me, and in a few test packages I've attempted building with the patched 
version I *think* the restart behaviour is now fixed in the various 
scenarios outlined above ("--no-stop-on-upgrade" for #994204, and moving 
"--restart-after-upgrade" to "--no-restart-after-upgrade" for #989155).


However, my Perl skills are extremely rusty, and this is not an area I'm 
overly familiar with, so any additional scrutiny is very welcome!


[1]: https://salsa.debian.org/debian/debhelper/-/merge_requests/61

[2]: https://salsa.debian.org/debian/debhelper/-/commit/6067bc2f

[3]: https://salsa.debian.org/debian/debhelper/-/commit/5b27a541


Best regards,

Dave Jones.

Bug#1004920: HTTP apt requests to ftp.uk.debian.org now redirecting to HTTPS when requested via 127.0.0.1 forward

[Matthew Jones]

Package: mirrors
We have an ssh tunnel forwarding traffic via a Debian Stretch server to 
ftp.uk.debian.org<ftp://ftp.uk.debian.org>. This is because the requesting 
client (also Debian Stretch) only has outbound ssh access (no other ports 
open). The tunnel is as follows:
ssh client@server -L 127.0.0.1:2081:ftp.uk.debian.org:80
And we then have the following line amongst others in the apt sources list:
deb http://127.0.0.1:2081/debian/ stretch main contrib non-free
For a few years now, whenever we run apt-get update, it works. But today it 
seems the above address is being redirected to HTTPS, e.g.:
Answer for: 
http://127.0.0.1:2081/debian/dists/stretch-backports/contrib/Contents-armhf.lzma
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.18.0
Date: Thu, 27 Jan 2022 16:25:20 GMT
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: 
https://127.0.0.1/debian/dists/stretch-backports/contrib/Contents-armhf.lzma
Also, the port specified in the initial request doesn’t appear to be honoured, 
according to the last line above.
We then get:
Err:5 https://127.0.0.1/debian stretch/main armhf Packages
server certificate verification failed. CAfile: 
/etc/ssl/certs/ca-certificates.crt CRLfile: none

If we change the ssh port forward to instead use 
ftp.de.debian.org<ftp://ftp.de.debian.org>, it works fine, just as the UK 
version used to, with no 302 redirect (different package extracted from earlier 
logs, but otherwise comparable):
Answer for: 
http://127.0.0.1:2081/debian/dists/stretch-backports/non-free/i18n/by-hash/SHA256/ecdde85fe38ffd2be1ba30e194d7e380cd5d18a0ae21c994bda09a4246ccaacb
HTTP/1.1 200 OK
Date: Thu, 27 Jan 2022 16:35:23 GMT
Server: Apache/2.4.25 (Debian)
Last-Modified: Mon, 13 Jul 2020 13:57:07 GMT
ETag: "9676-5aa5310fc3ad2"
Accept-Ranges: bytes
Content-Length: 38518
More interestingly, if I temporarily make it so that the client has HTTP 
access, and point apt directly at “deb http://ftp.uk.debian.org/debian/ stretch 
main contrib non-free”, then it works fine over HTTP as before, so it’s not an 
indiscriminately applied redirect. It’s as though the Nginx instance at the 
other end is now behaving differently depending on request hostname or perhaps 
port number.
I should add that there’s nothing in the chain that isn’t apparent from the ssh 
options “-L 127.0.0.1:2081:ftp.uk.debian.org:80”, it’s just a simple forward to 
the outside world.
We have a lot of kit in the field with this symptom, and would be nice to know 
if this can/will be fixed so that we can act accordingly.
I am using apt 1.4.6 (armhf) on Debian GNU/Linux 9

Regards,

[cid:image716390.png@3185E099.A4D73DB5]
MATTHEW JONES​
CLOUD SOLUTIONS ARCHITECT
RAMTECHGLOBAL.COM<https://www.ramtechglobal.com/>
SOCIAL MEDIA LINKEDIN 
<https://www.linkedin.com/company/ramtech-electronics-limited/> | YOUTUBE 
<https://www.youtube.com/channel/UCiLOcTLTQ1I5PPpA7ytgVrw> | 
TWITTER<https://twitter.com/RamtechGlobal>
EMAIL matthew.jo...@ramtechglobal.com<mailto:matthew.jo...@ramtechglobal.com>
OFFICE +44 (0)115 957 8282
This email has been sent by and on behalf of one or more of Ramtech Electronics 
Limited, Ramtech Overseas Limited, Ramtech North America Inc or Ashton Lister 
Investments Limited, (together, ‘Ramtech’). This e-mail, including attachments, 
is private and may be confidential and is for the intended recipient only. If 
you are not the intended addressee, please notify us by telephone (+44 (0)115 
957 8282) or by email (priv...@ramtechglobal.com) and confirm that it has been 
deleted from your system and any copies destroyed. If you are not the intended 
recipient you are strictly prohibited from using, printing, copying, 
distributing or disseminating this e-mail or any information contained in it. 
Ramtech use reasonable endeavours to virus scan all e-mails leaving the firms 
but no warranty is given that this e-mail and any attachments are virus free. 
You should undertake your own virus checking. The right to monitor e-mail 
communications through our networks is reserved by us. Each of Ramtech 
Electronics Limited (registered no. 02538255), Ramtech Overseas Limited 
(registered no. 10162495) and Ashton Lister Investments Limited (registered no. 
05617735) are companies registered in England and Wales and whose registered 
office is at: Ramtech House, Castlebridge Office Village, Castle Marina Rd, 
Nottingham NG7 1TN. Ramtech North America Inc principle place of business is 
5126 South Royal Atlanta Dr. Tucker, GA 30084, USA. To understand how we 
respect and protect your personal data, please see our privacy statement at 
https://ramtechglobal.com/privacy-statement

Bug#1004917: evolution: Contacts API is deprecated. Migrate to People API to retain programmatic access to Google Contacts

[Martin Tharby Jones]

Package: evolution
Version: 3.38.3-1
Severity: important
X-Debbugs-Cc: mar...@brasskipper.org.uk

Dear Maintainer,

evolution dislays the following error. I believe this is fixed in testing,
please build evolution in bullseye-backports so that the fix is avalible to
those using stable.

Failed to connect address book “mar...@brasskipper.org.uk : Contacts”

Invalid request URI or header, or unsupported nonstandard parameter: Contacts
API is being deprecated. Migrate to People API to retain programmatic access to
Google Contacts. See https://developers.google.com/people/contacts-api-
migration.


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

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

Versions of packages evolution depends on:
ii  dbus   1.12.20-2
ii  evolution-common   3.38.3-1
ii  evolution-data-server  3.38.3-1
ii  libc6  2.31-13+deb11u2
ii  libcamel-1.2-623.38.3-1
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libecal-2.0-1  3.38.3-1
ii  libedataserver-1.2-25  3.38.3-1
ii  libevolution   3.38.3-1
ii  libglib2.0-0   2.66.8-1
ii  libgtk-3-0 3.24.24-4
ii  libical3   3.0.9-2
ii  libnotify4 0.7.9-3
ii  libsoup2.4-1   2.72.0-2
ii  libwebkit2gtk-4.0-37   2.34.4-1~deb11u1
ii  libxml22.9.10+dfsg-6.7
ii  psmisc 23.4-2

Versions of packages evolution recommends:
ii  evolution-plugin-bogofilter  3.38.3-1
ii  evolution-plugin-pstimport   3.38.3-1
ii  evolution-plugins3.38.3-1
ii  yelp 3.38.3-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.2.27-2
ii  network-manager 1.30.0-2

Bug#1004014: open-iscsi: Duplicate dh_installsystemd section in d/rules

[Dave Jones]

Source: open-iscsi
Version: 2.1.5-1
Severity: important

Dear Maintainer,

In commit 693da74e, it appears lintian-brush changed both the 
override_dh_systemd_enable and override_dh_systemd_start sections in 
d/rules to override_dh_installsystemd with the result that there are now 
two override_dh_installsystemd rules in the makefile. The first is 
presumably ignored with the result that the postinst/prerm sections for 
the iscsid.service unit are omitted.

Best regards,

Dave Jones.

Bug#1002986: libguestfs-tools: Depends on guestfs-tools that is not in the archive

[Richard W.M. Jones]

> It looks like libguestfs-tools version 1:1.46.2-1 in depending on
> guestfs-tools that is not in the archive making the package
> uninstalable

Just wanted to note that upstream we have split up the
old, very large, libguestfs git "monorepo", splitting out:

guestfs-tools (https://github.com/rwmjones/guestfs-tools)

 - All the C and OCaml tools like virt-df, virt-customize, etc. except
   for guestfish, virt-v2v and virt-p2v.

virt-v2v (https://github.com/libguestfs/virt-v2v)

 - Conversion from VMware to KVM.

virt-p2v (https://github.com/libguestfs/virt-p2v)

 - Conversion from physical machines to KVM.

libguestfs (https://github.com/libguestfs/libguestfs)

 - Now it's just the library and language bindings (including
   guestfish because that is -- kind of -- a set of shell script
   bindings)

FWIW here are the new Fedora packages in case you want to see how we
decided to arrange the subpackages and dependencies.

https://src.fedoraproject.org/rpms/libguestfs/tree/rawhide
https://src.fedoraproject.org/rpms/guestfs-tools/tree/rawhide
https://src.fedoraproject.org/rpms/virt-v2v/tree/rawhide
https://src.fedoraproject.org/rpms/virt-p2v/tree/rawhide

Another thing to say is that we're planning eventually to move all the
git repos to gitlab because it's a more free software friendly
solution compared to github.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

Bug#990280: RFS: lg-gpio/0.1.7.0-1 [ITP] -- Control GPIO pins remotely

[Dave Jones]

Hi Bastian,

Thanks for the comments so far! Just one thing to clear up, I think:

On Tue, Nov 16, 2021 at 02:27:11AM +0100, Bastian Germann wrote:
[snip]

d/watch
===
debian-watch-file-is-missing

This is very important when you have several packages to maintain. It keeps 
track of new releases.


Unfortunately in this case, upstream's form of distribution doesn't 
work with Debian's uscan tooling. Specifically, they distribute 
their various libraries and tools (including lg) as a zip file named 
after the project without a version component. The version component 
is stored as an empty file within the root of the zip file.

[snip]


I just checked http://abyz.me.uk/lg/lg.zip against the GitHub 
releases/tags provided archive. They are not bit-by bit identical but 
contain the same source. As .zip cannot be used as an orig tarball 
directly, it is actually preferrable in this case not to get the 
author-uploaded zip but to use the GitHub tar.gz archive.


You can use one of uscan's versionmangle options to add the .0.0 but 
in my opinion you can also just go with the GitHub tag version. So, 
please replace your get-orig-source script by d/watch.


Unfortunately, the Git repo tags only represent a tiny fraction of the 
releases done so far. This should show the set of releases that have 
actually been made:


  $ git clone https://github.com/joan2937/lg
  $ cd lg
  $ for h in $(git rev-list master); do
  > git show $h^{tree} | grep "^v[0-9.]*$"
  > done | uniq
  v0.2.0.0
  v0.1.7.0
  v0.1.6.2
  v0.1.6.1
  v0.1.6.0
  v0.1.5.8
  v0.1.5.7
  v0.1.5.6
  v0.1.5.5
  v0.1.5.4
  v0.1.5.3
  v0.1.5.2
  v0.1.5.1
  v0.1.5.0
  v0.1.4.0
  v0.1.3.0
  v0.1.2.2
  v0.1.2.1
  v0.1.2.0
  v0.1.1.0
  v0.1.0.4
  v0.1.0.3
  v0.1.0.2
  v0.1.0.1
  v0.1.0.0
  v0.0.4.3
  v0.0.4.2
  v0.0.4.1
  v0.0.4.0
  v0.0.3.1
  v0.0.3.0
  v0.0.2.0
  v0.0.1.0

In rather stark contrast to:

  $ git tag
  v0.0
  v0.1
  v0.2

In other words, it would appear the author doesn't create tags for every 
release, just major ones. If that's all Debian would be interested in, I 
can certainly put together a d/watch file but I wonder whether it's 
preferable to have an option that picks up all releases (albeit a 
horribly non-standard one)?


Actually, you are already claiming in d/copyright that Source is 
https://github.com/joan2937/lg.


Ah, I was under the mis-apprehension that was a relatively informal 
field that simply pointed at a "useful" source location rather than a 
specific source (the archive location in this case is rather less useful 
than the git repo, given it's only ever the latest version available). 

Happy to adjust this accordingly, but figured I'd wait on your response 
to the point above about missing versions before going ahead.


Thanks,

Dave.

Bug#990280: RFS: lg-gpio/0.1.7.0-1 [ITP] -- Control GPIO pins remotely

[Dave Jones]

Hi Bastian,

On Sun, Nov 14, 2021 at 01:58:54AM +0100, Bastian Germann wrote:

On Mon, 1 Nov 2021 14:43:14 + Dave Jones wrote:
Filed bug #998243 against wnpp, and took the opportunity to bump the 
packaging to 0.2.0.0 while doing so; packaging is updated on salsa, 
and the source package is also uploaded to mentors.

d/watch
===
debian-watch-file-is-missing

This is very important when you have several packages to maintain. It 
keeps track of new releases.


Unfortunately in this case, upstream's form of distribution doesn't work 
with Debian's uscan tooling. Specifically, they distribute their various 
libraries and tools (including lg) as a zip file named after the project 
without a version component. The version component is stored as an empty 
file within the root of the zip file.


In other words, it's not possible (or more accurately I couldn't work 
out how) to get uscan to determine a new version is available and 
download it.


However, I agree entirely that this is an important piece of tooling for 
any maintainer, hence my inclusion of a simple "get-orig-source" script 
in the debian/ directory (also referenced as the "get-orig-source" 
target of d/rules) which does the equivalent job to uscan in this case 
(downloads the appropriate zip archive from upstream, checks if it 
matches the present one, and calls mk-origtargz on the result as 
necessary).



d/copyright
===
Please consider relicensing debian/* or at least debian/patches/* to 
the Unlicense as well.
The effective license of your patched package is GPL-3+ now, given 
that your patches are actually copyrightable. Also, upstream would not 
take your patches.


Good point -- certainly happy to relicense the debian/* bits as 
Unlicense (I was surprised to learn that on Debian SQLite, a famously 
public domain piece of software, is likewise GPL licensed as a result of 
this).



Please rename what is now called public-domain to Unlicense.


Fixed (though I'm slightly dis-heartened that unlicensed stuff can't be 
trivially labelled public-domain).



d/control
=
duplicate-short-description liblgpio-dev liblgpio1 python3-lgpio


Fixed.


python3-rgpio: package-contains-no-arch-dependent-files


Ah yes, the rgpio Python bit should indeed be "all". Fixing that caused 
a "not-binnmuable-all-depends-any" tag to pop up in lintian, which is 
something new to me (and led to some "what is binnmu?" googling). I 
*appear* to have fixed that by cargo-culting the tag's recommendation to 
change the dependency to >= source:Version but I wonder if there's some 
subtlety I'm missing. Would be grateful if you (or anyone) could verify 
this is indeed correct now.



d/changelog
===
Why are the .0.0 in your upstream version? I see 0.2 on GitHub.


The GitHub repo doesn't have the definitive list of versions (e.g. 
0.1.6.1 and 0.1.7.0, which were released, are missing); the author's 
versioning scheme (within the source archive) always includes four 
components, so I assumed the upstream component of the debian version 
number should do likewise?


Though, in light of the "not-binnmuable-all-depends-any" tag I 
encountered above, I wonder if they should be left off to permit a 
stronger Depends line for python3-rgpio?



symbols
===
symbols-file-missing-build-depends-package-field liblgpio.so.1 librgpio.so.1


Fixed.


Thanks for the review,

Dave Jones.

Bug#990280: RFS: lg-gpio/0.1.7.0-1 [ITP] -- Control GPIO pins remotely

[Dave Jones]

On Mon, Nov 01, 2021 at 10:55:07AM +, Dave Jones wrote:

On Sun, Oct 31, 2021 at 11:30:30PM +0100, Bastian Germann wrote:

On Thu, 30 Sep 2021 18:30:18 +0200 Bastian Germann  wrote:

Control: tags -1 moreinfo

On Thu, 24 Jun 2021 14:31:00 +0100 Dave Jones  wrote:

Changes for the initial release:

  lg-gpio (0.1.7.0-1) UNRELEASED; urgency=medium

 .
   * Initial Debian release.


You have to close an ITP bug with this. I did not find a RFP or 
ITP bug for this package name in the wnpp pseudo package. So 
please create one and change your changelog accordingly. Also, 
your package should target experimental or unstable.


Ah, I'll get on with fixing this, thanks!


Filed bug #998243 against wnpp, and took the opportunity to bump the 
packaging to 0.2.0.0 while doing so; packaging is updated on salsa, and 
the source package is also uploaded to mentors.

Bug#998243: ITP: lg-gpio -- Control GPIO pins via the kernel's gpiochip device interface

[Dave Jones]

Package: wnpp
Severity: wishlist
Owner: Dave Jones 

* Package name: lg-gpio
  Version : 0.2.0.0-1
  Upstream Author : https://github.com/joan2937/lg
* URL : https://abyz.me.uk/lg
* License : public-domain
  Programming Lang: C, Python
* Vcs : https://salsa.debian.org/python-team/packages/lg-gpio
  Section : electronics
  Description : Control GPIO pins via the kernel's gpiochip device interface

This package provides a comprehensive userspace GPIO interface akin to 
libgpiod (which is already in Debian), but crucially with additional 
methods for performing PWM (and other interfaces).

This makes it a viable replacement for RPi.GPIO (also in Debian) both in 
scripts that directly use that library, as well as those using gpiozero 
(again, already in Debian). In the latter case, the current Debian 
version of gpiozero (1.4 in stable) relies upon RPi.GPIO as its pin 
driver. However from 1.6 onwards (in unstable) it also supports lg-gpio 
as a (preferred) pin driver (though I don't think the patch for 
preferring lg is currently in the Debian version of the packaging).

I'm happy to maintain this package as part of the Python team (although 
the Raspi team might seem more appropriate, there's nothing Raspberry Pi 
specific in lg-gpio).

A request for sponsorship is (possibly prematurely!) open in #990280.

Bug#990280: RFS: lg-gpio/0.1.7.0-1 [ITP] -- Control GPIO pins remotely

[Dave Jones]

On Sun, Oct 31, 2021 at 11:30:30PM +0100, Bastian Germann wrote:

On Thu, 30 Sep 2021 18:30:18 +0200 Bastian Germann  wrote:

Control: tags -1 moreinfo

On Thu, 24 Jun 2021 14:31:00 +0100 Dave Jones  wrote:

Changes for the initial release:
>   lg-gpio (0.1.7.0-1) UNRELEASED; urgency=medium
  .
* Initial Debian release.


You have to close an ITP bug with this. I did not find a RFP or ITP 
bug for this package name in the wnpp pseudo package. So please 
create one and change your changelog accordingly. Also, your package 
should target experimental or unstable.


Ah, I'll get on with fixing this, thanks!

Also, please explain how you would justify the introduction of this lib 
to Debian when there is libgpiod already.


Certainly -- the TL;DR version is: because libgpiod doesn't provide all 
the facilities required to replace the "legacy" GPIO interfaces 
currently popular on platforms like the Raspberry Pi, while lg-gpio 
does.


The longer version is:

To be a viable replacement for the legacy GPIO interfaces (on which, 
more below), any new interface needs to support the facilities of the 
legacy interfaces. Unfortunately, libgpiod provides no means to perform 
PWM (in software or otherwise) which makes it an unattractive 
replacement for the legacy interfaces. lg-gpio, which is still based on 
the new gpiochip devices, provides this (and quite a few other bits 
besides).


On the Raspberry Pi (and a few other Pi-like platforms) there are 
currently a few popular libraries for manipulating the GPIO pins from 
userspace:


RPi.GPIO -- probably the most popular library, currently in Raspberry Pi 
OS, Debian, and Ubuntu. This is a "legacy" library in that it (mostly) 
bangs directly on the GPIO registers, (mostly) bypassing the kernel. 
Various clones of this library exist for other Pi-like platforms, but 
I'm not sure any of those clones exist in Debian, and they're probably 
not an attractive idea anyway given that things should be moving towards 
using gpiochip (like libgpiod and lg-gpio).


pigpiod -- probably the second most popular library, currently in 
Raspberry Pi OS only. Also bangs directly on the GPIO registers but 
(unlike RPi.GPIO) doesn't require clients to have root authority or 
access to those registers directly (via something like /dev/gpiomem) as 
clients talk to a (root) daemon over a socket instead (which also 
provides the option for remote control of GPIO pins, if the socket is 
bound to something other than localhost). Provides a form of hardware 
PWM (DMA controller banging on the GPIO registers) which is attractive 
to anyone wanting perfect servo control (for example), without 
additional hardware. However, it is *very* architecture specific: 
strictly Raspberry Pi only, and armhf only.


gpiozero -- a high level library providing "device" interfaces (for 
LEDs, buttons, motors, servos, rotary controllers, etc). Exists in 
Raspberry Pi OS, Debian, and Ubuntu (full disclosure: I'm one of the 
developers on this project). This sits on top of "pin drivers" like 
RPi.GPIO, pigpiod, or lg-gpio. I haven't got around to writing a 
libgpiod interface yet (although it is on my to-do list [1]), but when I 
do it won't be able to support things like the Motor class, or Servo, or 
PWMLED because it simply lacks the ability to perform PWM (whilst these 
all work happily with the lg-gpio driver).


Incidentally, lg-gpio (and eventually libgpiod) potentially open 
gpiozero up to being used on more platforms than just the Raspberry Pi 
(although currently, the lg-gpio interface in it is Pi specific as 
that's the only pin layout it knows).


Finally, there's an "rg" (remote GPIO) library that builds on top of 
lg-gpio (by the same author) that fills the same socket-based role that 
pigpiod provides above (perhaps unsurprisingly, the author of pigpiod is 
also the author of lg and rg). I haven't gotten around to writing an rg 
interface layer for gpiozero yet, but it's also on my to-do list.


A more complete write-up of all this (and other aspects) is at [2], but 
hopefully that's enough?


[1] 
https://github.com/gpiozero/gpiozero/issues/840#issuecomment-787521929


[2] 
https://waldorf.waveform.org.uk/2021/the-pins-they-are-a-changin.html



Thanks for your attention,

Dave Jones.

Bug#953412:

[Mike Jones]

8465757

Bug#513451: qemu-img: add stdin/stdout support

[Richard W.M. Jones]

12 years after this bug was filed, and because this is the top hit for
"qemu-img" and stdin / stdout, I want to point out that this is now
possible in Debian and other Linux distros using nbdcopy (in package
libnbd-bin) + qemu-nbd.

To stream from any qemu format such as qcow2 out to stdout:

  nbdcopy -- [ qemu-nbd -f qcow2 image.qcow2 ] - | file -

To stream from stdin into any qemu format such as qcow2:

  zcat image.gz | nbdcopy -- - [ qemu-nbd -f qcow2 output.qcow2 ]

Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd

[Tony Garnock-Jones]

Just to follow up again, here's an improved version of the patch that 
doesn't hand-roll quite so much socketpair/fork/exec code, reusing 
existing tools/ code instead!


Also, here's the upstream discussion of the patch on the 
linux-perf-users mailing list: 
https://lore.kernel.org/linux-perf-users/20210910102307.2055484-1-to...@leastfixedpoint.com/T/#u


Cheers,
  Tony
>From e3df73f35abf7485c351e541b6ab9280328cbbc9 Mon Sep 17 00:00:00 2001
From: Tony Garnock-Jones 
Date: Fri, 10 Sep 2021 12:19:46 +0200
Subject: [PATCH v2] tools/perf: Use long-running addr2line per dso

Invoking addr2line in a separate subprocess, one for each required
lookup, takes a terribly long time. This patch introduces a
long-running addr2line process for each dso, *DRAMATICALLY* speeding
up runs of perf. What used to take tens of minutes now takes tens of
seconds.

Debian bug report about this issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815

Signed-off-by: Tony Garnock-Jones 

---
Changes since v1:
 - use "subcmd/run-command.h" machinery instead of socketpair/fork/exec directly


 tools/perf/util/srcline.c | 384 --
 1 file changed, 284 insertions(+), 100 deletions(-)

diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index 5b7d6c16d33f..1e0b0be4de04 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -1,8 +1,10 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -15,6 +17,7 @@
 #include "srcline.h"
 #include "string2.h"
 #include "symbol.h"
+#include "subcmd/run-command.h"
 
 bool srcline_full_filename;
 
@@ -119,6 +122,8 @@ static struct symbol *new_inline_sym(struct dso *dso,
 	return inline_sym;
 }
 
+#define MAX_INLINE_NEST 1024
+
 #ifdef HAVE_LIBBFD_SUPPORT
 
 /*
@@ -273,8 +278,6 @@ static void addr2line_cleanup(struct a2l_data *a2l)
 	free(a2l);
 }
 
-#define MAX_INLINE_NEST 1024
-
 static int inline_list__append_dso_a2l(struct dso *dso,
    struct inline_node *node,
    struct symbol *sym)
@@ -361,26 +364,14 @@ void dso__free_a2l(struct dso *dso)
 	dso->a2l = NULL;
 }
 
-static struct inline_node *addr2inlines(const char *dso_name, u64 addr,
-	struct dso *dso, struct symbol *sym)
-{
-	struct inline_node *node;
-
-	node = zalloc(sizeof(*node));
-	if (node == NULL) {
-		perror("not enough memory for the inline node");
-		return NULL;
-	}
-
-	INIT_LIST_HEAD(>val);
-	node->addr = addr;
-
-	addr2line(dso_name, addr, NULL, NULL, dso, true, node, sym);
-	return node;
-}
-
 #else /* HAVE_LIBBFD_SUPPORT */
 
+struct a2l_subprocess {
+	struct child_process addr2line;
+	FILE *to_child;
+	FILE *from_child;
+};
+
 static int filename_split(char *filename, unsigned int *line_nr)
 {
 	char *sep;
@@ -402,114 +393,307 @@ static int filename_split(char *filename, unsigned int *line_nr)
 	return 0;
 }
 
+static void addr2line_subprocess_cleanup(struct a2l_subprocess *a2l)
+{
+	if (a2l->addr2line.pid != -1) {
+		kill(a2l->addr2line.pid, SIGKILL);
+		finish_command(>addr2line); /* ignore result, we don't care */
+		a2l->addr2line.pid = -1;
+	}
+
+	if (a2l->to_child != NULL) {
+		fclose(a2l->to_child);
+		a2l->to_child = NULL;
+	}
+
+	if (a2l->from_child != NULL) {
+		fclose(a2l->from_child);
+		a2l->from_child = NULL;
+	}
+
+	free(a2l);
+}
+
+static struct a2l_subprocess *addr2line_subprocess_init(const char *path)
+{
+	const char *argv[] = { "addr2line", "-e", path, "-i", "-f", NULL };
+	struct a2l_subprocess *a2l = NULL;
+	int start_command_status = 0;
+
+	a2l = zalloc(sizeof(*a2l));
+	if (a2l == NULL)
+		goto out;
+
+	a2l->to_child = NULL;
+	a2l->from_child = NULL;
+
+	a2l->addr2line.pid = -1;
+	a2l->addr2line.in = -1;
+	a2l->addr2line.out = -1;
+	a2l->addr2line.err = 0;
+	a2l->addr2line.dir = NULL;
+	a2l->addr2line.env = NULL;
+	a2l->addr2line.no_stdin = 0;
+	a2l->addr2line.no_stdout = 0;
+	a2l->addr2line.no_stderr = 1;
+	a2l->addr2line.exec_cmd = 0;
+	a2l->addr2line.stdout_to_stderr = 0;
+	a2l->addr2line.preexec_cb = NULL;
+
+	a2l->addr2line.argv = argv;
+	start_command_status = start_command(>addr2line);
+	a2l->addr2line.argv = NULL; /* it's not used after start_command; avoid dangling pointers */
+
+	if (start_command_status != 0) {
+		pr_warning("could not start addr2line for %s: start_command return code %d\n",
+			   path,
+			   start_command_status);
+		goto out;
+	}
+
+	a2l->to_child = fdopen(a2l->addr2line.in, "w");
+	if (a2l->to_child == NULL) {
+		pr_warning("could not open write-stream to addr2line of %s\n", path);
+		goto out;
+	}
+
+	a2l->from_child = fdopen(a2l->addr2line.out, "r");
+	if (a2l->from_child == NULL) {
+		pr_warning("could not open read-stream from addr2line of %s\n&

Bug#911815: /usr/bin/perf_4.18: Please build perf against libbfd

[Tony Garnock-Jones]

Dear Steinar, Ben, Mike, others:

On Tue, 18 Aug 2020 00:35:53 +0200 "Steinar H. Gunderson" 
 wrote:

But we can probably make the addr2line solution much faster?
perf runs:
[...]
but the normal way of running addr2line is to run it and then start feeding
it addresses on stdin (ie. don't start the program anew for each and every
address we want to look up). I haven't tried, but it sounds like that would
reduce overhead significantly?


Thanks, Steinar, for your suggestion! I've written a patch against the 
non-libbfd code in perf to try it out.


It works very well. What used to take endless minutes now takes a few 
seconds.


Please find my small patch (against "apt source linux-perf-5.10") attached.

I have also started the process of submitting it upstream.

Best Regards,
  Tony
From 536e3e3f348c4bbf28810e8fa4b8bbbfc16d4372 Mon Sep 17 00:00:00 2001
From: Tony Garnock-Jones 
Date: Thu, 9 Sep 2021 12:39:59 +0200
Subject: [PATCH] tools/perf: Use long-running addr2line per dso

Invoking addr2line in a separate subprocess, one for each required
lookup, takes a terribly long time. This patch introduces a
long-running addr2line process for each dso, *DRAMATICALLY* speeding
up runs of perf. What used to take tens of minutes now takes tens of
seconds.

Debian bug report about this issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911815

Signed-off-by: Tony Garnock-Jones 

---
 tools/perf/util/srcline.c | 430 +-
 1 file changed, 330 insertions(+), 100 deletions(-)

diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index 5b7d6c16d33f..767dc9af2789 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -1,8 +1,13 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -119,6 +124,8 @@ static struct symbol *new_inline_sym(struct dso *dso,
 	return inline_sym;
 }
 
+#define MAX_INLINE_NEST 1024
+
 #ifdef HAVE_LIBBFD_SUPPORT
 
 /*
@@ -273,8 +280,6 @@ static void addr2line_cleanup(struct a2l_data *a2l)
 	free(a2l);
 }
 
-#define MAX_INLINE_NEST 1024
-
 static int inline_list__append_dso_a2l(struct dso *dso,
    struct inline_node *node,
    struct symbol *sym)
@@ -361,26 +366,14 @@ void dso__free_a2l(struct dso *dso)
 	dso->a2l = NULL;
 }
 
-static struct inline_node *addr2inlines(const char *dso_name, u64 addr,
-	struct dso *dso, struct symbol *sym)
-{
-	struct inline_node *node;
-
-	node = zalloc(sizeof(*node));
-	if (node == NULL) {
-		perror("not enough memory for the inline node");
-		return NULL;
-	}
-
-	INIT_LIST_HEAD(>val);
-	node->addr = addr;
-
-	addr2line(dso_name, addr, NULL, NULL, dso, true, node, sym);
-	return node;
-}
-
 #else /* HAVE_LIBBFD_SUPPORT */
 
+struct a2l_subprocess {
+	pid_t addr2line_pid;
+	FILE *to_child;
+	FILE *from_child;
+};
+
 static int filename_split(char *filename, unsigned int *line_nr)
 {
 	char *sep;
@@ -402,114 +395,351 @@ static int filename_split(char *filename, unsigned int *line_nr)
 	return 0;
 }
 
+static FILE *dup_fdopen(int fd, const char *mode)
+{
+	FILE *f = NULL;
+	int nfd = dup(fd);
+
+	if (nfd == -1)
+		goto out;
+
+	f = fdopen(nfd, mode);
+	if (f == NULL) {
+		close(nfd);
+		goto out;
+	}
+
+out:
+	return f;
+}
+
+static void addr2line_subprocess_cleanup(struct a2l_subprocess *a2l)
+{
+	int _wstatus = 0;
+
+	if (a2l->addr2line_pid != -1) {
+		kill(a2l->addr2line_pid, SIGKILL);
+		waitpid(a2l->addr2line_pid, &_wstatus, 0);
+		a2l->addr2line_pid = -1;
+	}
+
+	if (a2l->to_child != NULL) {
+		fclose(a2l->to_child);
+		a2l->to_child = NULL;
+	}
+
+	if (a2l->from_child != NULL) {
+		fclose(a2l->from_child);
+		a2l->from_child = NULL;
+	}
+
+	free(a2l);
+}
+
+static struct a2l_subprocess *addr2line_subprocess_init(const char *path)
+{
+	struct a2l_subprocess *a2l = NULL;
+	int sockets[2] = {-1, -1};
+
+	a2l = zalloc(sizeof(*a2l));
+	if (a2l == NULL)
+		goto out;
+
+	a2l->addr2line_pid = -1;
+	a2l->to_child = NULL;
+	a2l->from_child = NULL;
+
+	/* Our convention: sockets[0] is for the parent, sockets[1] for the child */
+	if (socketpair(AF_UNIX, SOCK_STREAM, 0, sockets) == -1)
+		goto out;
+
+	a2l->addr2line_pid = fork();
+
+	switch (a2l->addr2line_pid) {
+	case -1:
+		pr_warning("fork failed for addr2line of %s\n", path);
+		goto out;
+	case 0:
+		/* We are in the child process. */
+		if (sockets[1] != STDIN_FILENO) {
+			if (dup2(sockets[1], STDIN_FILENO) == -1) {
+pr_warning("could not set stdin for addr2line of %s\n", path);
+close(sockets[1]);
+goto out;
+			}
+			close(sockets[1]);
+			sockets[1] = STDIN_FILENO;
+		}
+		if (sockets[1] != STDOUT_FILENO) {
+			if (dup2(sockets[1], STDOUT_FILENO) == -1) {
+pr_warning("could not set stdout for addr2line of %s\n", path);
+close(sockets[1]);
+goto out;
+			}
+		}
+		close(

Bug#993445: RFS: python-sense-hat/2.2.0-3 -- Sense HAT python library (Python 3)

[Dave Jones]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-sense-hat":

 * Package name: python-sense-hat
   Version : 2.2.0-3
   Upstream Author : https://github.com/astro-pi/python-sense-hat
 * URL : https://github.com/astro-pi/python-sense-hat
 * License : BSD-3-Clause
 * Vcs : https://salsa.debian.org/raspi-team/python-sense-hat
   Section : python

It builds those binary packages:

  python3-sense-hat - Sense HAT python library (Python 3)

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


  https://mentors.debian.net/package/python-sense-hat/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-sense-hat/python-sense-hat_2.2.0-3.dsc

Changes for the initial release:

 python-sense-hat (2.2.0-3) unstable; urgency=medium
 .
   * Initial Debian release.

Regards,
--
  Dave Jones

Bug#993443: RFS: rtimulib/7.2.1-6 [ITP] -- Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU library (Python 3)

[Dave Jones]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: rtimulib
   Version : 7.2.1-6
   Upstream Author : https://github.com/RPi-Distro/RTIMULib
 * URL : https://github.com/richards-tech/RTIMULib
 * License : MIT, GPL-3.0+, BSD-2-Clause
 * Vcs : https://salsa.debian.org/python-team/packages/rtimulib
   Section : libs

It builds those binary packages:

  python3-rtimulib - Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU 
library (Python 3)
  librtimulib-utils - Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU 
library (utilities)
  librtimulib-dev - Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU 
library (dev files)
  librtimulib7 - Versatile C++ and Python 9-dof, 10-dof and 11-dof IMU library 
(shared library)

These packages are pre-requisites for support of the Raspberry Pi Sense 
HAT in Debian (though RTIMULib is more general as is applicable to many 
different IMUs).


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


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

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


  dget -x 
https://mentors.debian.net/debian/pool/main/r/rtimulib/rtimulib_7.2.1-6.dsc

Changes for the initial release:

 rtimulib (7.2.1-6) unstable; urgency=medium
 .
   * Initial Debian release.

Regards,
-- Dave Jones

Bug#990280: RFS: lg-gpio/0.1.7.0-1 [ITP] -- Control GPIO pins remotely

[Dave Jones]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "lg-gpio":

 * Package name: lg-gpio
   Version : 0.1.7.0-1
   Upstream Author : https://github.com/joan2937/lg
 * URL : https://abyz.me.uk/lg
 * License : public-domain
 * Vcs : https://salsa.debian.org/python-team/packages/lg-gpio
   Section : electronics

As a bit of background, this package provides a platform agnostic 
interface to controlling GPIO pins via the kernel's (relatively) new 
/dev/gpiochipN devices. In Ubuntu Hirsute, we patched gpiozero 
(currently in Debian at version 1.4) to favour this as a backend over 
the current default of RPi.GPIO, which achieves control (partially) by 
banging directly on the Pi's GPIO hardware registers.


As one of the upstream developers of gpiozero, we're intending to move 
to lg-gpio as the default backend in the next major release, but 
obviously that needs lg-gpio to be ready in the relevant distributions. 
It's currently in Ubuntu, but obviously it'd be preferable it were 
upstream in Debian and could sync from there to both Ubuntu and 
Raspbian.


Some additional notes on quirks in this packaging. There's no d/watch 
file as the upstream developer's distribution format is sufficiently odd 
that uscan can't be easily configured to work with it. However, I have 
included a get-orig-source script that should accomplish the same task.


It builds those binary packages:

  rgpio-tools - Control GPIO pins remotely
  rgpiod - Daemon permitting remote control of GPIO pins
  python3-rgpio - Control GPIO pins remotely via rgpiod
  librgpio1 - Control GPIO pins remotely via rgpiod
  librgpio-dev - Control GPIO pins remotely via rgpiod
  python3-lgpio - Control GPIO pins via the kernel's gpiochip device interface
  liblgpio1 - Control GPIO pins via the kernel's gpiochip device interface
  liblgpio-dev - Control GPIO pins via the kernel's gpiochip device interface

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

  https://mentors.debian.net/package/lg-gpio/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/lg-gpio/lg-gpio_0.1.7.0-1.dsc

Changes for the initial release:

 lg-gpio (0.1.7.0-1) UNRELEASED; urgency=medium
 .
   * Initial Debian release.

Regards,
-- Dave Jones

Bug#924643: RFS: colorzero/2.0-1 [ITP] -- Construct, convert, and manipulate colors in a Pythonic manner.

[Dave Jones]

Hi Emmanuel,

On Mon, Jun 21, 2021 at 01:33:11PM -0300, Emmanuel Arias wrote:

On 6/21/21 11:06 AM, Dave Jones wrote:

On Sat, Jun 19, 2021 at 06:40:58PM -0300, Emmanuel Arias wrote:

Also, you can try to follow DEP-14 (although is mark as candidate)
and add debian/master as default branch.


Ah, this was something that confused me a bit when initially working
on this. I'd read through DEP-14, but then figured a simple way to
start would be to grab my existing packaging for Raspbian and use gbp
import-dsc on it. This set up the repo with a "master" branch rather
than "debian/master" and I then wondered if I'd mis-interpreted
DEP-14's prescription to use "debian/master", and whether it meant one
should use "debian" branch or alternatively a "master" branch.

I think that I don't understand you, sorry :(. But DEP-14 recommend the
use of /* for name the branchs, so for debian the branch should
be debian/*, for ubuntu ubuntu/*, etc.


Ah, sorry -- I'll attempt to elaborate my (rather silly) leap of 
"logic". Having read [PY-GIT] and [DEP-14], and knowing that gbp was 
specifically made for Debian packaging, after using "gbp import-dsc" I 
was slightly surprised to wind up on a "master" branch rather than 
"debian/master". I generally assume that tooling made specifically for a 
purpose (like Debian packaging) probably knows what it's doing better 
than I do, and hence I wondered whether I had missed something and 
whether (yes, it seems silly in hindsight, but still) the recommendation 
to use "debian/master" was to be interpreted as "debian or master" 
rather than a literal "debian/master" string.


Anyway, that's why I initially pushed a "master" branch rather than 
"debian/master" (under the assumption that gbp's defaults are probably a 
better bet than me trying to second guess the interpretation of 
standards :).


[PY-GIT] https://wiki.debian.org/Python/GitPackaging#Git_Branch_Names
[DEP-14] https://dep-team.pages.debian.net/deps/dep14/

In any case, I've fixed up the branches in the repo now and I *think* 
I've got the CI configuration in the right place, though it doesn't seem 
to have triggered a run yet. I've probably missed something in the repo 
config -- will dig into that in a mo.


Thanks for all the advice!

Dave.

Bug#924643: RFS: colorzero/2.0-1 [ITP] -- Construct, convert, and manipulate colors in a Pythonic manner.

[Dave Jones]

Hi Emmanuel,

On Sat, Jun 19, 2021 at 06:40:58PM -0300, Emmanuel Arias wrote:


On 6/19/21 9:03 AM, Peter Green wrote:
Just done some reviewing/tweaking. I've pushed the following changes 
to the git repo, please tell me if you have any objections.


I added a gpb.conf to make git-buildpackage actually use pristine tar 
and hence result in an orig tarball that was consistent with what is 
already in Ubuntu.


Also, you can try to follow DEP-14 (although is mark as candidate) and 
add debian/master as default branch.


Ah, this was something that confused me a bit when initially working on 
this. I'd read through DEP-14, but then figured a simple way to start 
would be to grab my existing packaging for Raspbian and use gbp 
import-dsc on it. This set up the repo with a "master" branch rather 
than "debian/master" and I then wondered if I'd mis-interpreted DEP-14's 
prescription to use "debian/master", and whether it meant one should use 
"debian" branch or alternatively a "master" branch.


Anyway, given it should be "debian/master" I'll get that corrected (I 
assume I'm right in thinking that'll need a 
"debian-branch=debian/master" addition to gbp.conf).



What about enable salsa-ci?


Certainly something on the todo list, but not something I'd read up on 
yet. I'll have a look at that this afternoon.


Thanks,

Dave.

Bug#924643: RFS: colorzero/2.0-1 [ITP] -- Construct, convert, and manipulate colors in a Pythonic manner.

[Dave Jones]

Hi Peter,

On Sat, Jun 19, 2021 at 01:03:31PM +0100, Peter Green wrote:
Just done some reviewing/tweaking. I've pushed the following changes to 
the git repo, please tell me if you have any objections.


I added a gpb.conf to make git-buildpackage actually use pristine tar 
and hence result in an orig tarball that was consistent with what is 
already in Ubuntu.


I found the clean target was not cleaning up the "egg-info" so I added 
a command to do that.


I added a closes: entry for the ITP bug.


No objections at all -- all looks good to me! Still getting used to gbp 
(I was testing the builds with sbuild prior to uploading to Salsa, hence 
why I missed the not-cleaning-up-egg-info).


That leaves one issue that I think still needs to be sorted before I 
sponsor the package.


The file "copyrights" has no license header and the git history says it 
was copied but not where from. Poking around I discovered a script of 
the same name in gpiozero, containing what appears to be the same code 
and committed by you with a commit message of "create copyright 
header", so I presume this script is entirely your work, assuming it is 
I would suggest adding a copyright header upstream and then picking the 
commit up as a Debian patch until there is another upstream release.


You're absolutely correct I shamelessly copied my "copyrights" script 
from gpio-zero :). I'll add a copyright header on there in a mo and pick 
the commit as a patch.



Finally would you consider adding me as a co-maintainer.


Certainly -- I'll add you to "Uploaders" as Emmanuel suggests later in 
the thread.


Thanks!

Dave.

Bug#924643: RFS: colorzero/2.0-1 [ITP] -- Construct, convert, and manipulate colors in a Pythonic manner.

[Dave Jones]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: colorzero
   Version : 2.0-1
   Upstream Author : https://github.com/waveform80/colorzero
 * URL : http://pypi.python.org/pypi/colorzero
 * License : BSD-3-Clause
 * Vcs : https://salsa.debian.org/python-team/packages/colorzero
   Section : python

A little extra background on this submission: one of the existing 
packages in Debian is gpiozero (producing python3-gpiozero). This is 
currently at version 1.4.1 in Debian while upstream it's now at 1.6.2. 
This is partly due to gpiozero 1.5 introducing a dependency on this 
package (colorzero); incidentally, in the interests of clarity, I'm one 
of the developers on gpiozero, and the sole developer on colorzero.


I'd originally had a go at getting colorzero into Debian a couple of 
years ago (hence this follow-up), but knew even less about deb-packaging 
back then. Hopefully this submission is slightly better!


Obviously, I don't expect much to happen until after the freeze, but if 
someone could give it a look and make sure I haven't made too many 
horrendous mistakes that'd be great.


I've also got some updated packaging for gpiozero (and another optional 
dependency it grew in 1.6.x)in salsa but that can wait until colorzero 
(which is a hard dependency) is dealt with, and will obviously require 
coordination with the gpiozero maintainer anyway.


It builds those binary packages:

  python-colorzero-doc - Construct, convert, and manipulate colors in a 
Pythonic manner.
  python3-colorzero - Construct, convert, and manipulate colors in a Pythonic 
manner.

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/colorzero/colorzero_2.0-1.dsc

Changes for the initial release:

 colorzero (2.0-1) UNRELEASED; urgency=medium
 .
   * Initial Debian release.

Thanks!

-- Dave Jones

Bug#945511: seabios: Structure Table Address is Correct

[Giancarlo Jones]

Hi Michael

Thanks for reaching out.

There is no issue.

I thought the address of the smbios structure table encoded in the entry-point 
structure was incorrect. I was looking through a hex dump and read bits 16-23 
of the address as 0xf0, when it is clearly 0x0f. 

I must have also made some errors in my program at the time that made this 
mistake seem realistic, but I can't remember them now.  

In other words, submitted my report in error. I'm sorry; I should have made 
that clearer.

Thanks for working on seabios.

--Giancarlo.

On December 30, 2020 4:13:06 AM EST, Michael Tokarev  wrote:
>On Sun, 20 Sep 2020 21:27:44 -0400 (EDT) "Giancarlo Jones" 
> wrote:
>> 
>> Package: seabios
>> Followup-For: Bug #945511
>> 
>> Dear Maintainer,
>> 
>> The encoded address is correct, even in the dump I uploaded. I made a 
>> mistake in reading it which somehow made it into my program as well.
>
>... ( https://bugs.debian.org/945511 )
>
>Hi Giancarlo!
>
>This bugreport has been neglected for over a year.
>
>I don't quite understand the issue you're having here (in your original
>report), and this your reply makes it even more puzzling - is the issue
>actually present or not?
>
>Thanks,
>
>/mjt

Bug#976101: systemd: Offline update installation in systemd (via gnome-update) doesn't cleanly unmount filesystem

[Josh Jones]

Amazing, that has taught me something very useful!

shutdown-log.txt attached and error is visible!

Josh

On Sun, 2020-12-06 at 21:36 +0100, Michael Biebl wrote:
> Am Sonntag, den 06.12.2020, 19:28 +0100 schrieb Michael Biebl:
> > Am 06.12.20 um 17:04 schrieb Josh Jones:
> > > It is the root filesystem which is failing to be remounted read-
> > > only -
> > > this is a simple setup with only one filesystem for the whole
> > > system.
> > > 
> > > It seems to be happening right at the very very end of the
> > > shutdown
> > > sequence - I have attached a picture of the error; quality is
> > > poor
> > > because I had to capture it from video footage. Is there any way
> > > to
> > > even have anything saved to disk so late in the sequence?
> > 
> > With the shutdown hook described in README.Debian and 
> > https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
> > (install the hook as /lib/systemd/system-shutdown/debug.sh without
> > the 
> > /usr prefix) you can gather logs right until the end
> > 
> > 
> 
> Copy the attached script to /lib/systemd/system-shutdown/, make it
> executable with chmod +x, then add 
> systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
> to the kernel command line and after the reboot, attach the file
> /shutdown-log.txt to this bug report.
> 
> Michael
[0.00] Linux version 4.19.0-13-amd64 (debian-ker...@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.160-2 (2020-11-28)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-13-amd64 
root=UUID=7900bc19-0f2b-463a-b20c-fca3956fd844 ro quiet splash nomodeset
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009efff] usable
[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0x1fff] usable
[0.00] BIOS-e820: [mem 0x2000-0x201f] reserved
[0.00] BIOS-e820: [mem 0x2020-0x40003fff] usable
[0.00] BIOS-e820: [mem 0x40004000-0x40004fff] reserved
[0.00] BIOS-e820: [mem 0x40005000-0xc8c37fff] usable
[0.00] BIOS-e820: [mem 0xc8c38000-0xc97d1fff] reserved
[0.00] BIOS-e820: [mem 0xc97d2000-0xc985efff] usable
[0.00] BIOS-e820: [mem 0xc985f000-0xc98f] ACPI NVS
[0.00] BIOS-e820: [mem 0xc990-0xca0a2fff] reserved
[0.00] BIOS-e820: [mem 0xca0a3000-0xca15cfff] type 20
[0.00] BIOS-e820: [mem 0xca15d000-0xca15dfff] usable
[0.00] BIOS-e820: [mem 0xca15e000-0xca1a0fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xca1a1000-0xcabecfff] usable
[0.00] BIOS-e820: [mem 0xcabed000-0xcaff1fff] reserved
[0.00] BIOS-e820: [mem 0xcaff2000-0xcaff] usable
[0.00] BIOS-e820: [mem 0xcb80-0xcf9f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00042f5f] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by American Megatrends
[0.00] efi:  ACPI=0xc98f  ACPI 2.0=0xc98f  SMBIOS=0xf04c0  
MPS=0xfd560 
[0.00] secureboot: Secure boot could not be determined (mode 0)
[0.00] SMBIOS 2.7 present.
[0.00] DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./Z77 Extreme6, 
BIOS P2.80 07/01/2013
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 3400.112 MHz processor
[0.001358] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.001359] e820: remove [mem 0x000a-0x000f] usable
[0.001366] last_pfn = 0x42f600 max_arch_pfn = 0x4
[0.001369] MTRR default type: uncachable
[0.00137

Bug#976101: systemd: Offline update installation in systemd (via gnome-update) doesn't cleanly unmount filesystem

[Josh Jones]

No worries - I will send you the debug journal at the next package update - or 
if I have time tomorrow I will try to install outdated versions of the packages 
last updated to force it to happen. Whatever is happening is pretty consistent 
for me by the looks of it.

I have just enabled persistent logging.

Josh

On 1 December 2020 22:46:47 GMT+00:00, Michael Biebl  wrote:
>Control: tags -1 unreproducible
>
>Am 01.12.20 um 18:02 schrieb Josh Jones:
>> Sorry which log do you mean by debug journal log? Apologies for my
>> ignorance.
>> 
>> (Incidentally this problem has occured on two out of three offline
>> updates in recent days)
>
>So, I tried this in a test VM.
>The offline update went just fine (see attached journal.txt), so I
>can't 
>reproduce the issue locally and we will need at the very least at 
>journal log.
>
>Michael

Bug#976101: systemd: Offline update installation in systemd (via gnome-update) doesn't cleanly unmount filesystem

[Josh Jones]

Sorry which log do you mean by debug journal log? Apologies for my
ignorance.

(Incidentally this problem has occured on two out of three offline
updates in recent days)

On Sun, 2020-11-29 at 19:45 +0100, Michael Biebl wrote:
> Control: tags -1 + moreinfo
> 
> Am 29.11.20 um 19:23 schrieb Josh:
> > Package: systemd
> > Version: 241-7~deb10u4
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > On two recent clean installations of Buster, I am noticing that
> > choosing to
> > install package updates through gnome-software, and therefore the
> > systemd
> > offline update system, results in the root filesystem not being
> > unmounted
> > properly once packages are installed and therefore gives an fsck
> > error on
> > reboot:
> > 
> > Failed to remount '/' read-only; Device or resource busy
> > 
> > Followed by journal recovery on reboot.
> > 
> > I haven't noticed any serious problems subsequently but it seems
> > like asking
> > for trouble for the filesystem to not be cleanly unmounted right
> > after packages
> > are updated. I have seen this on two machines, neither using 3rd
> > party repos
> > etc.
> 
> Can you please provide a (debug) journal log from such an offline
> update.
> 
> Michael

Bug#973766: Consider taking the Fedora patches to enable modern encryption options.

[Christopher Jones]

Package: vsftpd
Version: 3.0.3-12

Fedora have a number of patches available via 
https://src.fedoraproject.org/rpms/vsftpd/tree/master that enable modern 
encryption standards and make the defualt ssl implementation TLS V1.2.

Please consider including these or similar patches in your package.

SSL V2, V3, and TLSV1.0 which are the only current config options provided by 
this package are all deprecated and should be considered insecure at this point.

Many thanks!

—
Chris

Bug#972241: FTBFS on amd64 and i386 (error: guestfs_launch failed)

[Richard W.M. Jones]

guestfsd: error while loading shared libraries: libtirpc.so.3: cannot open 
shared object file: No such file or directory

Did something change with how libtirpc gets packaged on Debian
or upstream?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

Bug#945511: seabios: Structure Table Address is Correct

[Giancarlo Jones]

Package: seabios
Followup-For: Bug #945511

Dear Maintainer,

The encoded address is correct, even in the dump I uploaded. I made a mistake 
in reading it which somehow made it into my program as well.

--Giancarlo

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

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

-- no debconf information

Bug#967099: libguestfs: FTBFS: dwz: debian/guestfsd/usr/sbin/guestfsd: DWARF version 0 unhandled

[Richard W.M. Jones]

This is actually a bug in binutils, not OCaml.  The fix is:

https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=4d8ee860737005517be588f4771c358593fa421c

See also:

https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/3YRZ5TJK7PTYDYHUDOYC5HFWKZPA7KIJ/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

Bug#969009: transition: sleuthkit

[Richard W.M. Jones]

The libguestfs FTBFS thing is caused by a bug in binutils
(not OCaml or libguestfs).  See:

https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/3YRZ5TJK7PTYDYHUDOYC5HFWKZPA7KIJ/
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=4d8ee860737005517be588f4771c358593fa421c

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

Bug#946594: Fwd: libguestfs incorrectly detects host CPU architecture

[Richard W.M. Jones]

On Thu, Dec 12, 2019 at 11:01:02AM +0100, Vincent Danjean wrote:
> [resend to the good (cloned) bug, sorry for the message in the original bug,
> it was a mistake]
> 
>   Hi,
> 
> On Thu, 5 Dec 2019 11:12:56 +0000 "Richard W.M. Jones"  
> wrote:
> > I believe this is a new bug and nothing much to do with:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775761
> 
>   So I just cloned the bug into #946594 in order to manage the bug reported
> by Pierre Neyron.
> 
> > However about this new bug, what is supposed to happen is that
> > common/mlstdutils/guestfs_config.ml is generated by ./configure with
> > the correct @host_cpu@ substituted.  If that's not happening then it's
> > a build issue on Debian of some kind.
> 
>   I closely look at the build system with him. It occurs that :
> - the Debian package use an 'out-of-source' build (ie the build is
>   *not* done into the source directories)
> - Debian applies some patches to archive this
> - but the current rules about guestfs_config.ml especially target
>   the source directory (whereas ./configure generates it in the
>   build directory, as for all other configure generated files)
> 
> Easy test :
> - remove common/mlstdutils/guestfs_config.ml in the source directory
> - build the Debian package (dpkg-buildpackage -us -uc)
>   => the build fails with:
> ocamlfind ocamlopt -g -annot -safe-string -warn-error CDEFLMPSUVYZX+52-3 
> -ccopt '-g -O2 
> -fdebug-prefix-map=/home/polaris/danjean/libguestfs/libguestfs=. 
> -fstack-protector-strong -Wformat -Werror=format-security 
> -fno-strict-overflow -Wno-strict-overflow' -package str,unix -I . -c 
> ../../../../common/mlstdutils/std_utils.ml -o std_utils.cmx
> File "_none_", line 1:
> Warning 58: no cmx file was found in path for module Guestfs_config, and its 
> interface was not compiled with -opaque
> 
> => the guestfs_config.ml generated in the build directory is not
> taken into account.
> => the Debian package is currently using the provided (x86-64)
> guestfs_config.ml in the source directory and ignore the generated
> one (in the build directory) on all architectures
> => the Debian package is correctly built only on x86-64...
> 
>   The root of the problem is in subdir-rules.mk at the root of the
> package. I found a fix the seems to work:
> =
> --- subdir-rules.mk   2019-12-11 15:45:01.274572831 +0100
> +++ subdir-rules.mk.fixed 2019-12-11 15:44:23.738419530 +0100
> @@ -79,12 +79,12 @@
>  guestfs_am_v_jar_ = $(guestfs_am_v_jar_@AM_DEFAULT_V@)
>  guestfs_am_v_jar_0 = @echo "  JAR " $@;
> 
> -%.cmi: $(srcdir)/%.mli
> +%.cmi: %.mli
>   $(guestfs_am_v_ocamlcmi)$(OCAMLFIND) ocamlc $(OCAMLFLAGS) 
> $(OCAMLPACKAGES) -c $< -o $@
> -%.cmo: $(srcdir)/%.ml
> +%.cmo: %.ml
>   $(guestfs_am_v_ocamlc)$(OCAMLFIND) ocamlc $(OCAMLFLAGS) 
> $(OCAMLPACKAGES) -c $< -o $@
>  if HAVE_OCAMLOPT
> -%.cmx: $(srcdir)/%.ml
> +%.cmx: %.ml
>   $(guestfs_am_v_ocamlopt)$(OCAMLFIND) ocamlopt $(OCAMLFLAGS) 
> $(OCAMLPACKAGES) -c $< -o $@
>  endif
> =
> 
>   The idea is to let "make" to check itself in the build directory and then
> in the source directory by not forcing a path and using the VPATH feature
> (as for all internal automake rules)

Pino, Hillu, what do you think?

Rich.

>   Looking at the ChangeLog, I saw that the build rules about cmi/cmo/cmx/...
> seems tricky, so I would prefer that someone that know ocaml builds checks
> my patch.
>   In any case, the Debian build is broken.
>   As upstream does not seem to support out-of-source build, this problem 
> should
> not appear for it. So the fix can go into a debian patch (even if I think that
> my patch is a no-op for a 'in-source' build)
> 
>   Regards,
> Vincent
> 
> 
> > Rich.
> > 
> > -- 
> > Richard Jones, Virtualization Group, Red Hat 
> > http://people.redhat.com/~rjones
> > Read my programming and virtualization blog: http://rwmj.wordpress.com
> > Fedora Windows cross-compiler. Compile Windows programs, test, and
> > build Windows installers. Over 100 libraries supported.
> > http://fedoraproject.org/wiki/MinGW
> > 
> > 
> > 
> 
> -- 
> Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
> GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
> Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
> APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main
> 
> -- 
> Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
> GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF

Bug#775761: libguestfs incorrectly detects host CPU architecture

[Richard W.M. Jones]

I believe this is a new bug and nothing much to do with:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775761

However about this new bug, what is supposed to happen is that
common/mlstdutils/guestfs_config.ml is generated by ./configure with
the correct @host_cpu@ substituted.  If that's not happening then it's
a build issue on Debian of some kind.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

Bug#944206: evolution: missing text in html mail (white text on white background)

[Tess Jones]

Source: evolution
Version: 3.30.5-1.1
Severity: important

Dear Maintainer,

I just upgraded from stretch to buster. Mails in evolution are now
displayed with most of the text missing if viewed in HTML mode. It
turns out that this is because most of the text is white on white.

The theme in use is 'high contrast'. The same effect is apparent if
'adwaita-dark' is chosen. All the other basic xfce themes seems to
work correctly. This theme has ben in use for a couple of years anddid notcause 
thisproblem on stretch.

I don't know if this should be deemed a bug in the themes or evolution?

So far as I can tell the high-contrast theme comes from the package
gnome-accessibility-themes, which is installed and there are files under 
/usr/share/themes/HighContrast (gtk-2.0/gtkrc and gtk-3.0/gtk.rss and 
index.theme

One thing I notice is that there are many more theme files in
/usr/share/themes than appear in the 'Appearance' dialog. Not sure if
that's relevant.

Any ideas how to debug or fix this, and why it broke inthe upgrade?

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

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

Bug#941903: snapshot.debian.org: 404 error for one snapshot.debian.org IP address but not for the other

[Evan Jones]

On Mon, Oct 21, 2019 at 9:11 AM Peter Palfrader  wrote:

> I'm tempted to think that this tool should not use snapshot but the real
> mirrors that can handle the load way better.
>

It also accesses snapshot.debian.org when building new images, so the
traffic should be pretty small: it is just a tiny handful of developers,
plus the CI system. End users download the binary that was build and
published by Google.

That said: is there some other way to get a specific version of
Packages.txt that does not change? If so, I'd be happy to change this. The
goal is that given a build, future builds should download the *exact same
bits*. My understanding is snapshot.debian.org is exactly the way to do
this?

Thanks!

Evan

Bug#941903: snapshot.debian.org: 404 error for one snapshot.debian.org IP address but not for the other

[Evan Jones]

THANK YOU and whoever else is involved in maintaining this. Just letting
you know that I appreciate the work here. I don't work for Google, but I do
use Distroless [1], a lightweight Debian-based container runtime that uses
snapshot to have reproducible builds, so this was definitely annoying to
work around. Thanks!

[1] https://github.com/GoogleContainerTools/distroless


On Mon, Oct 21, 2019 at 3:54 AM Peter Palfrader  wrote:

> Michael Rogers schrieb am Monday, dem 07. October 2019:
>
> > When trying to fetch package lists and packages from the
> > buster/updates repository I get 404 errors at random, depending on
> > which IP address of snapshot.debian.org my machine chooses for each
> > request. Requests that go to 193.62.202.27 succeed, while requests
> > that go to 185.17.185.185 fail with 404 errors.
>
> > The requested URL /file/02424f70567c5695ef02c2410dd9bca446a86437 was not
> found on this server.
>
> Thanks for the report.  It seems that the farm broke.  Should be fixed
> now, sync is still in progress.
>
> Cheers,
> --
> |  .''`.   ** Debian **
>   Peter Palfrader   | : :' :  The  universal
>  https://www.palfrader.org/ | `. `'  Operating System
> |   `-https://www.debian.org/
>
>

Bug#939546: libnbd: please make the build reproducible

[Richard W.M. Jones]

Upstream in:

https://github.com/libguestfs/libnbd/commit/2a955696cde1be60d468fdc662b4f70ec862b866

which will be in libnbd >= 1.0.1 & >= 1.1.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

Bug#931498: Bug present in Debian GNU/Linux 10 (buster)

[Martin Tharby Jones]

Dear Maintainer,

I've just upgrade to buster and the bug is still the same.

Yours

Martin

Bug#931498: gmpc-plugins: Some plugins are disabled

[Martin Tharby Jones]

Package: gmpc-plugins
Version: 11.8.16-3
Severity: important

Dear Maintainer,

I want to use the gmpc-albumview plugin but it is not built as part of the
stable release. I checked at https://gmpclient.org/plugins and it is still
listed.

I downloaded the source from the link
(http://download.sarine.nl/Programs/gmpc/0.20.0/gmpc-albumview-0.20.0.tar.gz)
on https://gmpc.fandom.com/wiki/GMPC_PLUGIN_ALBUMVIEW.

This fails to build due to following error:

[...]
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -pthread -I/usr/include/gmpc
-I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1
-I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-I/usr/include/freetype2 -I/usr/include/libmpd-1.0/
-DPIXMAP_DATA_DIR=\"/usr/share/gmpc-albumview/icons\" -g -O2 -MT
albumviewplugin_la-plugin.lo -MD -MP -MF .deps/albumviewplugin_la-plugin.Tpo -c
plugin.c  -fPIC -DPIC -o .libs/albumviewplugin_la-plugin.o
In file included from /usr/include/string.h:630:0,
 from /usr/include/glib-2.0/glib/gi18n-lib.h:24,
 from plugin.c:3:
/usr/include/libmpd-1.0/libmpd/libmpd-internal.h:210:10: error: expected
identifier or ‘(’ before ‘__extension__’
 char *   strndup (const char *s, size_t n);
  ^
plugin.c: In function ‘load_list_itterate’:
[...]

This unhelpful message is caused by the redeclaration of strndup(), it is also
declared in string.h.

The declaration in libmpd-internal.h is protected by #ifndef but HAVE_STRNDUP
is not defined in config.h

#ifndef HAVE_STRNDUP
char *  strndup (const char *s, size_t
n);
#endif

Adding #define HAVE_STRNDUP to config.h gives me a useable build but I don't
know enough about autotools so I had to make the addition manually. The problem
seems to be associated with older versions of the C library not providing
strndup().

Several other plugins were disabled as a workaround to fix Debian Bug report
#807735 so a proper fix for this should work for them also. A workaround like
this should have reduced the severity of this bug not closed it!

Yours

Martin



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

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

Versions of packages gmpc-plugins depends on:
ii  gmpc 11.8.16-10
ii  libatk1.0-0  2.22.0-1
ii  libavahi-client3 0.6.32-2
ii  libavahi-common3 0.6.32-2
ii  libavahi-glib1   0.6.32-2
ii  libc62.24-11+deb9u4
ii  libcairo21.14.8-1
ii  libdbus-1-3  1.10.28-0+deb9u1
ii  libdbus-glib-1-2 0.108-2
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libmpd1  0.20.0-2~deb9u1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2

gmpc-plugins recommends no packages.

gmpc-plugins suggests no packages.

-- no debconf information

Bug#901124: roundcube: patching roundcube breaks it

[Steven Jones]

Hi Guilem,

I edited the file as below to make it work with a remote mysql server I already 
had running,

root@email-001:/etc/roundcube# more debian-db.php

Sent: Thursday, 6 June 2019 12:29 PM
To: stven jones; 901...@bugs.debian.org
Subject: Re: Bug#901124: roundcube: patching roundcube breaks it

On Sat, 09 Jun 2018 at 15:16:31 +1200, stven jones wrote:
>   * What exactly did you do (or not do) that was effective (or ineffective)?
>
> reset the debian database config to the remote mysql server's IP after the 
> patching wiped this.

What *exactly* did you do: which file, and its diff?

--
Guilhem.

Bug#174424: COFFEE REQUEST FOR A MEETING

[Arthur Jones]

From: Arthur Jones 
Sent: Friday, May 31, 2019 8:43 AM
To: Arthur Jones
Subject: Re: COFFEE REQUEST FOR A MEETING

Hello,


How are you doing today? Could you please send us quote of 400 cups of Black 
Coffee ? We want you to supply our upcoming conference and barista will be 
picking up from you to the event.
Hope to read from you soon.
Thanks
Arthur

Bug#924643: ITP: colorzero -- Construct, convert, and manipulate colors in a Pythonic manner

[Dave Jones]

Package: wnpp
Severity: wishlist
Owner: Dave Jones 

* Package name: colorzero
  Version : 1.1
  Upstream Author : Dave Jones 
* URL : https://colorzero.readthedocs.io/
* License : BSD 3-clause
  Programming Lang: Python
  Description : Construct, convert, and manipulate colors in a Pythonic 
manner

Colorzero is a library for working with colors in Python. It is not
intended to be as comprehensive as colormath, but is intended to be a
little easier to use, particularly for beginners. The major difference
with colorzero is that colors are tuples and thus immutable. Standard
mathematical operators (addition, subtraction, multiplication, etc.) are
used to generate new colors. Conversions are provided for a wide variety
of systems including YUV, RGB565, CMYK, CIE Lab, and so on.


The GPIO Zero package (which I'm one of the upstream developers for, and
which was recently kindly added to Debian by Peter Green) is currently
at version 1.4.1. We released 1.5.0 recently and this has grown a
dependency on my colorzero library (which was split out from my picamera
library last year).

It's already packaged and in Raspbian, but I'd like to get it upstream
to ease the progress of GPIO Zero to 1.5.0 in Debian. I'm happy to
handle maintainership of the package (I already do for Raspbian);
possibly just need a sponsor to sanity check that there's nothing
dreadfully broken in the current package?

I've also got copies of colorzero 1.1 and gpiozero 1.5 stuffed in a PPA
(https://launchpad.net/~waveform/+archive/ubuntu/pkg) for testing on
Ubuntu on Pi, if that makes things any easier.

Bug#920776: sparse: new upstream release

[Ramsay Jones]

On 29/01/2019 20:57, Jonathan Nieder wrote:
> Hi Uwe,
> 
> Uwe Kleine-König wrote:
>> On 1/29/19 2:38 AM, Jonathan Nieder wrote:
> 
>>> Thoughts of all kinds welcome, as always.  If you'd prefer this in the
>>> form of a "git pull"-able repository, a push to salsa, or an NMU, just
>>> ask.
>>
>> I didn't follow sparse development in the nearer past. Is there a
>> problem with sparse 0.5.2 that would be fixed by going to 0.6.0?
>>
>> My thought was not to touch it for buster and go to 0.6.0 only afterwards.
> 
> Cc-ing Ramsay Jones and Luc to find out.  In [1] I find
> 
> | [I was a little surprised that Linux Mint 19.1 (based on Ubuntu
> | 18.04) has v0.5.1 - Debian unstable has v0.5.2, but both of those
> | are just a little too old for use with git on recent Linux.]
> 

see, eg. https://marc.info/?l=linux-sparse=152668057308589=2
 et. seq.

> but I wasn't able to reproduce a problem with v0.5.2 analyzing git.git
> myself.

The problem, which was actually due to the version of glibc, appeared
for me when updating to Ubuntu 18.04 (as a test run for Linux Mint 19
;-) ). It was also present in fedora 27, 28 and 29 (I assume also in
Ubuntu 18.10, but I haven't tried that).

>  That said, v0.6.0 has been working well for me, so I suspect
> upgrading is not too risky.
> 
> One example improvement is
> 
> commit fdf8252f312a40df9aa51c6e30c0d07fa29ebd12
> Author: Ramsay Jones 
> Date:   Sun Nov 18 23:52:23 2018 +
> 
> constant: add -Wconstant-suffix warning
> 
> Currently, when used on the kernel, sparse issues a bunch
> of warnings like:
> warning: constant 0x1 is so big it is long
> 
> These warning are issued when there is a discrepancy
> between the type as indicated by the suffix (or the absence
> of a suffix) and the real type as selected by the type
> suffix *and* the value of the constant.
> 
> Since there is nothing incorrect with this discrepancy,
> (no bits are lost) these warnings are more annoying than useful.
> So, make them depending on a new warning flag -Wconstant-suffix
> and make it off by default.
> 

Although it mentions the kernel, this was indeed the 'fix' for the
problem on 'newer Linux distros'. (I still think glibc should have
been fixed ... ).

This version also adds many fixes for sparse on cygwin and quite a
few for kernel development. See the release notes on the sparse
wiki (https://sparse.wiki.kernel.org/index.php/Sparse_0.6.0_released).

ATB,
Ramsay Jones

Bug#914286: new stable upstream version 1.3 available

[Ethan R. Jones]

I made a fork, synced with upstream, and merged v1.3
dpkg-buildpackage -b executed fine, passing all tests. (debian:9 docker
image)
Named it opus-1.3-1 as Kevin suggested.
I'm also not an developer, but I believe it just needs to be merged
into Ron's repo. I was unable to make a merge request, assuming that's
due to my "-guest" account.
TIA 



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

Bug#908787: gpiozero: please provide python module on all architectures

[Jones, Dave]

Sorry, this fell off my radar - my clone of the gpio-zero repo (
https://github.com/waveform80/gpio-zero) has some extra branches on it but
all the important bits (for this) are PRd under
https://github.com/RPi-Distro/python-gpiozero/pull/665. However, for some
reason that branch is currently failing the Travis tests - I've got a nasty
feeling I managed to push from the wrong box! I'll try and sort that out
tonight.

Dave.

On Thu, 18 Oct 2018 at 19:20, peter green  wrote:

> I have chatted with Dave Jones (waveform80) about getting gpiozero support
> on more architectures. It seems sensible that as part of doing this we also
> package pigpio to support remote gpio operations.
>
> Dominik do you mind if I add myself to the uploaders for this package and
> work on updating it to the lastest upstream version opening up the
> architecture list?
>
> One thing we need to look at is making sure pi-specific code that hits
> hardware directly doesn't run on anything other than Pis. Both in gpiozero
> and in pigpio. Obviously this is a potential issue now but the risk rises
> as we package more stuff. I spoke to Dave about this at Manchester
> raspberry jam and he told me he had improved the detection in gpiozero
> recently, but the version at https://github.com/rpi-distro/python-gpiozero
> still seems to have the same code.
>
> Dave is there an "experimental" gpiozero repository somewhere I have
> failed to find?
>
> I don't believe any changes to the library would be required for this. The
> control file
> already states "Architecture: all" [1]. Is that correct, or is there
> anything else required?
>
> The gpiozero packaging in Debian and the gpiozero packaging in the
> raspberry pi foundation repo seem to be unrelated. This bug report is
> discussing the former.
>
> pigpio is the C library which runs as a daemon on the Pi. It accepts remote
> commands
> and executes them on the Pi. The Python client (the package would be
> python3-pigpio)
> is pure Python and is what communicates with remote Pis.
> However, both pigpio and python3-pigpio are contained within the same
> source repo
> on GitHub. In Raspbian we have both of these packaged.
>
>
> No, you have them packaged in the rasperry pi foundation repo.
>
> And looking at that packaging it's going to need some work before
> it's something acceptable to upload to Debian.
>
> Right now the python stuff is directed to it's own binary packages but
> all the c stuff is stuffed into one binary package. I see several issues
> with this package.
>
> 1. It contains not one but three shared libaries, none of which seem to
> have proper so-versioning
> 2. It seems to have a directory for some sort of scripts in
> /opt/pigpio/cgi, I don't think this compiles with the filesystem heirachy
> standard.
>
> I will follow up these issues in more detail in another mail with a
> different recipient list (which will include
> https://bugs.debian.org/908787 but not https://bugs.debian.org/856413 )
>
>
>

Bug#908171: sssd: please package for stretch-backports

[Steven Jones]

Hi,


I have been trying to Make Debian Stretch work with Redhat [free]IPA server for 
a cross domain trust. I have RHEL7.5 clients, Ubuntu18LTS clients and 
Centos7.5 all fo which are using sssd 1.16.  Debian stretch has 1.15 and fails 
on a cross forest environment while the other 3 all work over 100,000's of ssh 
login tests.Adding 1.16.3 from unstable fixes this issue so eith add a 
backport or upgrade Stretch to sssd 1.16


regards

Steven Jones

B.Eng (Hons)

Technical Specialist - Linux RHCE

Victoria University ITS,

Level 8 Rankin Brown Building,

Wellington, NZ

6012

0064 4 463 6272

Bug#909228: RFP: loop -- "UNIX's missing loop command!"

[Rich Jones]

Package: wnpp
Severity: RFP

loop lets you write powerful, intuitive looping one-liners in your favorite
shell! For example:

loop './do_thing.sh' --every 15s --until-success --num 5

..And lots more!

MIT licensed, written in Rust.
Source here: https://github.com/Miserlou/Loop/
Related issue: https://github.com/Miserlou/Loop/issues/36

I'm the author of this tool which I find extremely handy, and I'd love it
if I could (eventually) use it on my servers without having to import any
external keys!

Would anybody be interested in stepping up to help polish the application
enough to make an official Debian package? :)

Thanks!
Rich

Bug#904421: installation-report

[Jordan Jones]

Package: installation-reports

Boot method: DVD-1
Image version: 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-9.5.0-amd64-netinst.iso
Date: 23 July 2018, 03:30 UTC

Machine: Fujitsu Lifebook T4410
Processor: Intel(R) Core(TM)2 Duo CPU P8700  @ 2.53GHz
Memory: 4GB
Partitions:FilesystemType 1K-blocks  Used
Available Use% Mounted on
udev  devtmpfs   197 0   197   0% /dev
tmpfs tmpfs   398148 11380386768   3% /run
/dev/mapper/jdeb--vg-root ext4 148479768  44795480  96072284  32% /
tmpfs tmpfs  1990736277064   1713672  14% /dev/shm
tmpfs tmpfs 5120 4  5116   1% /run/lock
tmpfs tmpfs  1990736 0   1990736   0%
/sys/fs/cgroup
/dev/sda1 ext2240972 37468191063  17% /boot
tmpfs tmpfs   39814416398128   1%
/run/user/118
tmpfs tmpfs   39814448398096   1%
/run/user/1000


Output of lspci -knn (or lspci -nn):00:00.0 Host bridge [0600]: Intel
Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40]
(rev 07)
Subsystem: Fujitsu Limited. Mobile 4 Series Chipset Memory Controller
Hub [10cf:144e]
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4
Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
Subsystem: Fujitsu Limited. Mobile 4 Series Chipset Integrated
Graphics Controller [10cf:1458]
Kernel driver in use: i915
Kernel modules: i915
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller [8086:2a43] (rev 07)
Subsystem: Fujitsu Limited. Mobile 4 Series Chipset Integrated
Graphics Controller [10cf:1458]
00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #4 [8086:2937] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller
[10cf:1472]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #5 [8086:2938] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller
[10cf:1472]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1a.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #6 [8086:2939] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller
[10cf:1472]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB2 EHCI Controller #2 [8086:293c] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB2 EHCI Controller
[10cf:1473]
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD
Audio Controller [8086:293e] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) HD Audio Controller
[10cf:1475]
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
Express Port 1 [8086:2940] (rev 03)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
Express Port 2 [8086:2942] (rev 03)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
Express Port 3 [8086:2944] (rev 03)
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1d.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #1 [8086:2934] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller
[10cf:1472]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #2 [8086:2935] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller
[10cf:1472]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB UHCI Controller #3 [8086:2936] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB UHCI Controller
[10cf:1472]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1d.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family)
USB2 EHCI Controller #1 [8086:293a] (rev 03)
Subsystem: Fujitsu Limited. 82801I (ICH9 Family) USB2 EHCI Controller
[10cf:1473]
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge
[8086:2448] (rev 93)
00:1f.0 ISA bridge 

Bug#901124: roundcube: patching roundcube breaks it

[stven jones]

Package: roundcube
Version: 1.2.3+dfsg.1-4+deb9u2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Patching operating system

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

reset the debian database config to the remote mysql server's IP after the 
patching wiped this.

   * What was the outcome of this action?

roundcube now works.

   * What outcome did you expect instead?

That the locally set config is not altered on patching but local config is 
honoured.

*** End of the template - remove these template lines ***


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

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

Versions of packages roundcube depends on:
ii  dpkg1.18.24
ii  roundcube-core  1.2.3+dfsg.1-4+deb9u2

roundcube recommends no packages.

roundcube suggests no packages.

Versions of packages roundcube-core depends on:
ii  dbconfig-common 2.0.8
ii  debconf [debconf-2.0]   1.5.61
ii  dpkg1.18.24
ii  libapache2-mod-php7.0 [libapache2-mod-php]  7.0.27-0+deb9u1
ii  libmagic1   1:5.30-1+deb9u1
ii  php-auth-sasl   1.0.6-3
ii  php-common  1:49
ii  php-mail-mime   1.10.0-2
ii  php-mcrypt  1:7.0+49
ii  php-net-smtp1.7.1-2
ii  php-net-socket  1.0.14-2
ii  php-pear1:1.10.1+submodules+notgz-9
ii  php7.0-cli [php-cli]7.0.27-0+deb9u1
ii  php7.0-intl [php-intl]  7.0.27-0+deb9u1
ii  php7.0-json [php-json]  7.0.27-0+deb9u1
ii  php7.0-mcrypt [php-mcrypt]  7.0.27-0+deb9u1
ii  roundcube-mysql 1.2.3+dfsg.1-4+deb9u2
ii  ucf 3.0036

Versions of packages roundcube-core recommends:
ii  apache2 [httpd-cgi] 2.4.25-3+deb9u4
ii  php-pspell  1:7.0+49
ii  php7.0-gd [php-gd]  7.0.27-0+deb9u1
ii  php7.0-pspell [php-pspell]  7.0.27-0+deb9u1

Versions of packages roundcube-core suggests:
pn  php-crypt-gpg  
pn  php-net-ldap2  
pn  php-net-ldap3  
ii  roundcube-plugins  1.2.3+dfsg.1-4+deb9u2

-- debconf information:
  roundcube/app-password-confirm: (password omitted)
  roundcube/password-confirm: (password omitted)
  roundcube/mysql/app-pass: (password omitted)
  roundcube/mysql/admin-pass: (password omitted)
* roundcube/mysql/admin-user: root
* roundcube/dbconfig-reinstall: false
  roundcube/passwords-do-not-match:
* roundcube/restart-webserver: true
  roundcube/dbconfig-upgrade: true
* roundcube/dbconfig-install: true
* roundcube/language: en_US
  roundcube/missing-db-package-error: abort
* roundcube/reconfigure-webserver: apache2, lighttpd
  roundcube/db/dbname: roundcubemail
  roundcube/upgrade-backup: true
  roundcube/remote/newhost:
  roundcube/remote/port:
  roundcube/internal/skip-preseed: false
* roundcube/install-error: ignore
  roundcube/mysql/method: Unix socket
* roundcube/hosts:
  roundcube/upgrade-error: abort
  roundcube/db/app-user: roundcube@localhost
  roundcube/remote/host: localhost
  roundcube/purge: false
* roundcube/database-type: mysql
  roundcube/internal/reconfiguring: false
  roundcube/remove-error: abort
  roundcube/dbconfig-remove: true

Bug#899317: mercurial-git: Breaks with python-dulwich 19.1

[Chris Jones]

Package: mercurial-git
Version: 0.8.11-1
Severity: important

Dear Maintainer,

mercurial-git is broken by api changes in python-dulwich 19.1 currently
in testing.

Upstream bug here -
https://bitbucket.org/durin42/hg-git/issues/236/issues-when-used-with-dulwich-019

In the mean time downgrading to the version of python-dulwich in stable
works.

Thanks!


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

Versions of packages mercurial-git depends on:
ii  mercurial   4.6-2
ii  python  2.7.15~rc1-1
pn  python-dulwich  

mercurial-git recommends no packages.

mercurial-git suggests no packages.

-- no debconf information

-- 
Chris

Bug#897636: RFS: raphael/2.2.7-1 [QA]

[David William Richmond Davies-Jones]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: raphael
  Version : 2.2.7-1
  Upstream Author : Dmitry Baranovskiy <dmi...@baranovskiy.com>
* URL : https://dmitrybaranovskiy.github.io/raphael/
* License : Expat
  Section : web

It builds those binary packages:

 libjs-raphael - JavaScript library to work with vector graphics

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

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

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

 dget -x
https://mentors.debian.net/debian/pool/main/r/raphael/raphael_2.2.7-1.dsc

More information about hello can be obtained from
https://dmitrybaranovskiy.github.io/raphael/

  Changes since the last upload:

 * QA upload.
 * New upstream release (Closes: #761180)
 * Updated d/watch (Closes: #788574)
 * Set maintainer to Debian QA Group
 * Bump debhelper to level 11
 * Build from upstream tarball
   - Contains both full and minified source (Closes: #874270)
   - Dropped build-dep on node-uglify
 * Updated homepage
 * Converted d/copyright to machine-readable format
 * Standards version 4.1.4


Regards,
   David William Richmond Davies-Jones

Bug#892106: mate-applets: system monitor applet does not remember system monitor width properties just stays at the default 40

[S Jones]

Yes it worked in the past, just fine on version 1.18, this only started
with the upgrade to 1.20

On Mon, Mar 5, 2018 at 11:44 AM, Alex ARNAUD  wrote:

> Contro: tags -1 upsteam
>
> Le 05/03/2018 à 17:16, shaun a écrit :
>
>> Dear Maintainer,
>>
>
> Hello shaun,
>
> Thank you for filing bug on Debian, you help us to make it better.
>
> *** Reporter, please consider answering these questions, where appropriate
>> ***
>>
>> * What led up to the situation?
>>   I always have the system monitor applet in the top panel and the
>> width i
>> set is 100, but everytime logging in it defaults back to a   width of 40
>>
>
> I can confirm the issue. Does it work for you in the past?
>
> Best regards,
> Alex.
>

Bug#891880: roundcubemail: no option in dbconfig for a remote mysql database setup

[stven jones]

Package: roundcubemail
Version: roundcube
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

no option to config roundcube for a remote database, this is then compounded by,
no locatable documentation to config manually, std doc methods do not succeed. 
It appears something somewhere is over-riding attempts to manually edit.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Attempted manual editing of config files in /etc/roundcube in desperation
   * What was the outcome of this action?
no change web ui still reports no db connection
   * What outcome did you expect instead?
hould work.

*** End of the template - remove these template lines ***


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

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

Bug#888182: qemu-system-arm: qemu-system-arm crashes when run as part of the nbdkit testsuite

[Richard W.M. Jones]

I was able to reproduce a crashing bug in qemu-system-arm on armv7
host.  I'm _not_ going to claim this is the same bug that Debian is
seeing, but it might be.

It's deep inside TCG and unfortunately there is not a lot of useful
information in the stack trace.  However it's clearly a bug in qemu.

Core was generated by `/usr/bin/qemu-system-arm -global 
virtio-blk-device.scsi=off -enable-fips -nodef'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xab6a7aa8 in ?? ()
[Current thread is 1 (Thread 0xaa9f7f90 (LWP 25252))]
(gdb) bt
#0  0xab6a7aa8 in ?? ()
#1  0xaba87ad0 in code_gen_buffer ()
#2  0x006291e0 in cpu_tb_exec (itb=, itb=, 
cpu=)
at /usr/src/debug/qemu-2.11.0-4.fc28.arm/accel/tcg/cpu-exec.c:167
#3  cpu_loop_exec_tb (tb_exit=, 
last_tb=, tb=, cpu=)
at /usr/src/debug/qemu-2.11.0-4.fc28.arm/accel/tcg/cpu-exec.c:627
#4  cpu_exec (cpu=)
at /usr/src/debug/qemu-2.11.0-4.fc28.arm/accel/tcg/cpu-exec.c:736
#5  0x005efae4 in qemu_tcg_cpu_thread_fn (arg=0x13ce3e0)
at /usr/src/debug/qemu-2.11.0-4.fc28.arm/cpus.c:1270
#6  0xb53f3f1c in start_thread () from /lib/libpthread.so.0
#7  0xb53790d8 in ?? () from /lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I'm using:

* qemu-system-arm-2.11.0-4.fc28.armv7hl
* kernel-lpae-4.15.0-0.rc9.git2.1.fc28.armv7hl

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

Bug#888182: qemu-system-arm: qemu-system-arm crashes when run as part of the nbdkit testsuite

[Richard W.M. Jones]

The test failure looks like a problem in libguestfs (or maybe qemu)
rather than nbdkit.

TBH in Fedora we disable nbdkit tests on 32-bit armv7, 32-bit i686
and all POWER:

  
https://src.fedoraproject.org/rpms/nbdkit/blob/44518f07e0b28a799fa683f1f5ec2ca9c000ac01/f/nbdkit.spec#_419

Now that's not because they shouldn't work eventually, it's because we
don't routinely test nbdkit upstream on these architectures.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

Bug#887969: nbdkit FTBFS: test failures

[Richard W.M. Jones]

On the face of it, it looks like the following patch should fix it:

  
https://github.com/libguestfs/nbdkit/commit/a6b907e5359a139404cee5fd5c7f94eab36a5fde

What I don't understand is why that isn't included in your nbdkit
(1.1.25) already?

In any case the latest nbdkit -- 1.1.27 released a couple of days ago --
does pass all the tests with the latest qemu.

The valgrind tests are broken with 1.1.27, and that is fixed by the
following 3 commits added after 1.1.27:

  
https://github.com/libguestfs/nbdkit/commit/1e51756907646bc8d2dbcddb2cdb9cea59e5c7bf
  
https://github.com/libguestfs/nbdkit/commit/a3d4a17971bbd84639437a52f5ab1b3fd307c29d
  
https://github.com/libguestfs/nbdkit/commit/b67a2099105a949b9e943b8c8fc8da1c0163c641

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

Bug#876993: regression: menubar and toolbar doesn't autohide in fullscreen non-GNOME mode

[Tony Garnock-Jones]

Package: evince
Version: 3.25.92-1
Severity: normal

Dear Maintainer,

In stock (built-from-git) evince, viewing a PDF in full-screen mode, there is
no menubar, and the toolbar autohides after a brief delay.

In the debian-patched version, with XDG_CURRENT_DESKTOP=GNOME, no menubar
appears, and toolbar hiding works as usual in full-screen mode.

However, when running outside GNOME, there is a menubar, and neither the
menubar nor the toolbar autohide in full-screen mode.

I expected both the menubar and toolbar to autohide in full-screen mode, even
outside GNOME, in the debian-patched version.

I narrowed down the source of the problem to the recent inclusion of patches
traditional_menu_bar.patch and/or unity_normal_titlebar.patch. I'm afraid I
haven't narrowed it down any further than that.

One odd thing: careful observation shows that the toolbar is *trying* to hide
itself, but that there is another (?!?!) toolbar underneath (??!!??) which is
revealed as the "hide" animation takes place. Hovering the mouse over the small
zone below the menubar and near the top of the still-visible toolbar causes the
upper (?!) overlaying (!?) toolbar to slide into visibility again, covering up
the underlying (?!) toolbar again. (The movement is visible because the zoom
widget's x-coordinate is slightly different - maybe by 20 pixels or so - in the
two (?!) toolbars.)

Thank you!

Regards,
  Tony



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

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

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  evince-common3.25.92-1
ii  gsettings-desktop-schemas3.24.1-1
ii  libatk1.0-0  2.26.0-2
ii  libc62.24-17
ii  libcairo-gobject21.14.10-1
ii  libcairo21.14.10-1
ii  libevdocument3-4 3.25.92-1
ii  libevview3-3 3.25.92-1
ii  libgdk-pixbuf2.0-0   2.36.10-2
ii  libglib2.0-0 2.54.0-1
ii  libgnome-desktop-3-123.26.0-2
ii  libgtk-3-0   3.22.21-1
ii  libnautilus-extension1a  3.26.0-1
ii  libpango-1.0-0   1.40.12-1
ii  libpangocairo-1.0-0  1.40.12-1
ii  libsecret-1-00.18.5-3.1
ii  shared-mime-info 1.8-1

Versions of packages evince recommends:
ii  dbus-x11 [dbus-session-bus]  1.11.16+really1.10.22-1

Versions of packages evince suggests:
ii  gvfs 1.30.4-1+b1
ii  nautilus-sendto  3.8.6-1
ii  poppler-data 0.4.8-1
pn  unrar

-- no debconf information

Bug#873822: RFS: achilles/2-9 [QA]

[David William Richmond Davies-Jones]

It was with compat level 10.

On 01/09/17 23:28, Tobias Frost wrote:
> Am Freitag, den 01.09.2017, 23:01 +0100 schrieb David William Richmond
> Davies-Jones:
>> I did do an upload here I dropped the build-dep, but it threw up a
>> warning about outdated config.{sub|guess}. Should I ignore this?
> 
> This was probably before setting compat level 10?
> (As said, d/compat == 10 does the magic, see https://lists.debian.org/d
> ebian-devel/2016/04/msg00018.html)
> 
> 
> 
>> On 01/09/17 22:59, Tobias Frost wrote:
>>> Am Freitag, den 01.09.2017, 21:14 +0100 schrieb David William
>>> Richmond
>>> Davies-Jones:
>>>> Hello
>>>>
>>>> I have fixed the problems with the copyright file, deleted the
>>>> stray
>>>> file, and fixed the lintian warnings about encoding in desktop
>>>> file
>>>> and
>>>> description started with synopsis.
>>>
>>> OK
>>>
>>>> I also *think* that I've got everything sorted with autoreconf
>>>> etc,
>>>> but
>>>> to be honest I always seem to have trouble and get confused with
>>>> them.
>>>
>>> With compat level 10 dh-autoreconf is default -> you do not need B-
>>> D on
>>> it or autotools-dev anymore. That should fix the warning :)
>>>
>>> Fix this and reupload... Then we're ready, I guess!
>>>
>>> Thanks for the package!
>>>
>>> --
>>> tobi
>>>
>>>
>>>> David
>>>>
>>>> On 31/08/17 22:17, Tobias Frost wrote:
>>>>> Control: owner -1 !
>>>>> Control: tags -1 moreinfo
>>>>>
>>>>> Hallo David,
>>>>>
>>>>> The package is already in a nice state; many thanks for
>>>>> updating
>>>>> it!
>>>>>
>>>>> However some fixes are required:
>>>>>
>>>>> - d/copyright needs fixing:
>>>>>   - as it says "Copyright: ?"... I think it must be 
>>>>> Copyright: 2000 Matthew Danish <mdan...@andrew.cmu.edu>
>>>>>   - Also the License is GPL-2+
>>>>>   - The license grant is not copied verbatimly 
>>>>>
>>>>> - d/manpage is a stray file.
>>>>>
>>>>> - Please (try to) fix those linitan warnings or evaluate if
>>>>> they
>>>>> are
>>>>> valid:
>>>>>
>>>>> W: achilles source: useless-autoreconf-build-depends autotools-
>>>>> dev
>>>>> I: achilles source: debian-watch-file-is-missing
>>>>> I: achilles: hardening-no-bindnow usr/bin/achilles
>>>>> W: achilles: description-synopsis-starts-with-article
>>>>> I: achilles: desktop-entry-contains-encoding-key
>>>>> usr/share/applications/achilles.desktop:3 Encoding
>>>>> I: achilles: desktop-entry-lacks-keywords-entry
>>>>> usr/share/applications/achilles.desktop
>>>>>
>>>>>
>>>>> --
>>>>> tobi
>>>>>
>>
>>

Bug#873822: RFS: achilles/2-9 [QA]

[David William Richmond Davies-Jones]

I did do an upload where I dropped the build-dep, but it threw up a
warning about outdated config.{sub|guess}. Should I ignore this?

On 01/09/17 22:59, Tobias Frost wrote:
> Am Freitag, den 01.09.2017, 21:14 +0100 schrieb David William Richmond
> Davies-Jones:
>> Hello
>>
>> I have fixed the problems with the copyright file, deleted the stray
>> file, and fixed the lintian warnings about encoding in desktop file
>> and
>> description started with synopsis.
> 
> OK
> 
>> I also *think* that I've got everything sorted with autoreconf etc,
>> but
>> to be honest I always seem to have trouble and get confused with
>> them.
> 
> With compat level 10 dh-autoreconf is default -> you do not need B-D on
> it or autotools-dev anymore. That should fix the warning :)
> 
> Fix this and reupload... Then we're ready, I guess!
> 
> Thanks for the package!
> 
> --
> tobi
> 
> 
>> David
>>
>> On 31/08/17 22:17, Tobias Frost wrote:
>>> Control: owner -1 !
>>> Control: tags -1 moreinfo
>>>
>>> Hallo David,
>>>
>>> The package is already in a nice state; many thanks for updating
>>> it!
>>>
>>> However some fixes are required:
>>>
>>> - d/copyright needs fixing:
>>>   - as it says "Copyright: ?"... I think it must be 
>>> Copyright: 2000 Matthew Danish <mdan...@andrew.cmu.edu>
>>>   - Also the License is GPL-2+
>>>   - The license grant is not copied verbatimly 
>>>
>>> - d/manpage is a stray file.
>>>
>>> - Please (try to) fix those linitan warnings or evaluate if they
>>> are
>>> valid:
>>>
>>> W: achilles source: useless-autoreconf-build-depends autotools-dev
>>> I: achilles source: debian-watch-file-is-missing
>>> I: achilles: hardening-no-bindnow usr/bin/achilles
>>> W: achilles: description-synopsis-starts-with-article
>>> I: achilles: desktop-entry-contains-encoding-key
>>> usr/share/applications/achilles.desktop:3 Encoding
>>> I: achilles: desktop-entry-lacks-keywords-entry
>>> usr/share/applications/achilles.desktop
>>>
>>>
>>> --
>>> tobi
>>>

Bug#873822: RFS: achilles/2-9 [QA]

[David William Richmond Davies-Jones]

Hello

I have fixed the problems with the copyright file, deleted the stray
file, and fixed the lintian warnings about encoding in desktop file and
description started with synopsis.

I also *think* that I've got everything sorted with autoreconf etc, but
to be honest I always seem to have trouble and get confused with them.

David

On 31/08/17 22:17, Tobias Frost wrote:
> Control: owner -1 !
> Control: tags -1 moreinfo
> 
> Hallo David,
> 
> The package is already in a nice state; many thanks for updating it!
> 
> However some fixes are required:
> 
> - d/copyright needs fixing:
>   - as it says "Copyright: ?"... I think it must be 
> Copyright: 2000 Matthew Danish 
>   - Also the License is GPL-2+
>   - The license grant is not copied verbatimly 
> 
> - d/manpage is a stray file.
> 
> - Please (try to) fix those linitan warnings or evaluate if they are
> valid:
> 
> W: achilles source: useless-autoreconf-build-depends autotools-dev
> I: achilles source: debian-watch-file-is-missing
> I: achilles: hardening-no-bindnow usr/bin/achilles
> W: achilles: description-synopsis-starts-with-article
> I: achilles: desktop-entry-contains-encoding-key
> usr/share/applications/achilles.desktop:3 Encoding
> I: achilles: desktop-entry-lacks-keywords-entry
> usr/share/applications/achilles.desktop
> 
> 
> --
> tobi
> 

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Ramsay Jones]

On 31/08/17 21:55, Uwe Kleine-König wrote:
> On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote:
>> That is very much like on x86_64 missing define "#weak_define __x86_64__ 1"
>>
>> Does cgcc work for you? In the future we do want to move the archetecture
>> related define from cgcc into sparse by itself. For now you can set
>> "sparse" as "cgcc -no-compile"
> 
> Yes that works. So to address the Debian bug I can do:
> 
>  - move sparse to /usr/lib
>  - teach cgcc about the move of sparse
>  - make /usr/bin/sparse call cgcc -no-compile "$@"

Hmm, I don't think that would be a good idea ...

> or is it easier to teach sparse about the architecture stuff?

I now understand (I think!) that you are building a sparse
package (presumably a .deb) and you are concerned that sparse
does not pass it's own testsuite on those platforms.

As I said before, the additional failures you are seeing are
in the 'llvm backend' code (which, as far as I know, only passes
on x86_64 Linux), and in my opinion the llvm-backend programs should
not be installed. (The Makefile will build them automatically if
you have llvm installed, likewise for c2xml/libxml and test-inspect/gtk).

[I would like to see build variable(s) to allow the user to suppress
the build (or installation) of the other 'non-primary' sparse programs.]

Anyway, if you were to un-install llvm, sparse-llvm etc., would not
be built, and the tests would not be run ... ;-)

Christopher, as the project maintainer, has the joy of making these
kinds of decisions! :-D

ATB,
Ramsay Jones

Bug#873822: RFS: achilles/2-9 [QA]

[David William Richmond Davies-Jones]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: achilles
   Version : 2-9
   Upstream Author : Matthew Danish <mdan...@andrew.cmu.edu>
 * URL : http://achilles.sourceforge.net/
 * License : GPL-2
   Section : science

It builds those binary packages:

 achilles   - An artificial life and evolution simulator

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/a/achilles/achilles_2-9.dsc


More information about achilles can be obtained from
http://achilles.sourceforge.net/

Changes since the last upload:

 * QA upload.
 * Source format 3.0 (quilt)
 * Bumped compat level to 10
 * Converted d/rules to dh_* format
 * Removed menu file
 * Set maintainer to Debian QA Group
 * Converted d/changelog to machine-readable format
 * Standards version 4.0.1

Regards,
David William Richmond Davies-Jones

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Ramsay Jones]

On 30/08/17 17:14, Uwe Kleine-König wrote:
> Hello,
> 
> Antoine Beaupre (on Cc:) noticed that sparse doesn't work on some not so
> common architectures like ppc32le, s390x, ppc64 and sparc64[1]. This is
> nicely catched by the testsuite, e.g.:

The only architecture, from the above list, that is not supported
by cgcc seems to be ppc32le.

>   ukleinek@plummer:~/sparse$ git rev-parse HEAD
>   958c11c35d98417eb6b948bffe2dffed14eb3320
>   ukleinek@plummer:~/sparse$ uname -a
>   Linux plummer 4.9.0-3-powerpc64le #1 SMP Debian 4.9.30-2+deb9u3 
> (2017-08-06) ppc64le GNU/Linux
>   ukleinek@plummer:~/sparse$ make check V=1

It would be easier to see the results if you _didn't_ add V=1. ;-)

[snip]
>   Out of 287 tests, 272 passed, 15 failed (10 of them are known to fail)
>   Makefile:232: recipe for target 'check' failed
>   make: *** [check] Error 1
>   ukleinek@plummer:~/sparse$ 

The additional five failures are all in the llvm backend (sparsec),
which you do not need to use sparse as a 'checker'.

> The problem is that some cpp symbols are not defined in sparse that are
> expected to exist. So I can "fix" backend/sum.c with the following
> patch:
> 
> diff --git a/validation/backend/sum.c b/validation/backend/sum.c
> index 0604299..d0be8dd 100644
> --- a/validation/backend/sum.c
> +++ b/validation/backend/sum.c
> @@ -1,3 +1,5 @@
> +#define __powerpc64__
> +#define _CALL_ELF 2
>  #include 
>  #include 
>  
> 

Yep, sparse/sparsec do not define various macros that gcc/clang define
by default on a given architecture. This is a known problem (that I have
been meaning to fix ...). The 'workaround' for the time being is to use
the cgcc front-end to sparse. (for example 'make CC=cgcc', or perhaps
'cgcc -no-compile').

[You didn't mention your usage - is this for a kernel build?]

ATB,
Ramsay Jones

Bug#871229: /usr/sbin/update-grub: running update-grub segment faults

[Steven Jones]

Sorry unable to capture an output


I have tried to use pastebin but the case isnt being updated with the links.


regards

Steven



From: Colin Watson 
Sent: Monday, 7 August 2017 8:28 p.m.
To: steven.jo...@vuw.ac.nz; 871...@bugs.debian.org
Subject: Re: Bug#871229: /usr/sbin/update-grub: running update-grub segment 
faults

On Mon, Aug 07, 2017 at 02:15:46PM +1200, steven.jo...@vuw.ac.nz wrote:
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***

Neither your bug report nor any of your follow-ups includes the actual
output from update-grub.  Please run the following as root and post the
*exact* output (there will be quite a lot of it):

  sh -x /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg

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

Bug#870824: RFS: fspy/0.1.1-2 [QA]

[David William Richmond Davies-Jones]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/08/17 18:37, Adam Borowski wrote:
> On Sat, Aug 05, 2017 at 04:16:26PM +0100, David William Richmond
> Davies-Jones wrote:
>> * Package name: fspy Version : 0.1.1-2
> 
>> https://mentors.debian.net/debian/pool/main/f/fspy/fspy_0.1.1-2.dsc
>
>>  Changes since the last upload:
>> 
>> * QA upload. * Applied reproducible build patch from Chris Lamb
>> (Closes: #831354) * Bumped compat level to 10 * Set maintainer to
>> Debian QA Group * Dropped build-dep on quilt * Removed obsolete
>> fields from d/control * Converted to source format 3.0 (quilt) *
>> Converted d/rules to dh_ format * Removed useless watch file *
>> Converted d/copyright to machine-readable format * Standards
>> version 4.0.0
> 
> Likewise, please remove the commented out old version from
> debian/rules.
> 
> There's also no explanation why the man page is moved from page 8
> to 1; the move itself is correct but it should be mentioned.
> 
> 
> Meow!
> 

I have made the changes and re-uploaded
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJZh45MAAoJECIyhjOTII6f2rkQAKA+FmXGkLI+Ah4wN1T1yzWu
Cdher9xq9zu2Vt7OcagJ0lxYjudbVfNirY5r5cOAdPuMjkgRZ8VFpYuXBWMkQTb+
dSTHE5Tk4jCII+2VdToLI3ss6TGiASIpQY+PdOqQHr+0sqpOX9xe4n+ZlEgFceQ5
oYeCrbQSTQJ55FucCx5DioBGTxEi9rPG+8qmaIQbl9x6YTYqFc8335knH6fDYZZm
84Tyl0PqAwwRbe2Su5E/Mc7OL7nFRp1y2MfEk7CNdi2tPcXtvUz6pOzW4Q9cYp1O
GIr/DglqCLKmjJdLn82xawc/ZD34gAG5RWxmb86agkk7HH6LLVPPc0IwpvcjsvKJ
u4DNl6IadjNhKrAKN8PzR8pGV6WkTO9r8HRaOnhHl36b8HyERrAE7MUzDmmIWj3B
cMGWW6W69Jzb3Pu8s9qbj0KTDV+QwGP9bbqdBjWzcF3magSgkkvEYxCSCtukMMUU
2qQ24S7KmAzwIMWf9klX2bGHCKbeR/Csxht4rraRK4Lwq9k7f6B1KvNPMD0IgySA
mgfMo3VNQHappfWifBu50zwIqOgj3AHmosx3U7S1xT1zVK3gU+OQyg2bVzx7e3Fg
EEMvseYPf7fK3G49uRBO+ylLS0ftc9LMNwSRtMKSwcbYH5Y5DYzkwce1CxYFjk+N
+vOa/dFlMlCNnjvSrYbp
=ELBL
-END PGP SIGNATURE-

Bug#870824: RFS: fspy/0.1.1-2 [QA]

[David William Richmond Davies-Jones]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: fspy
   Version : 0.1.1-2
   Upstream Author : Richard Sammet <richard.sam...@gmail.com>
 * URL : http://mytty.org/fspy
 * License : GPL-2+
   Section : misc

It builds those binary packages:

 fspy  - filesystem activity monitoring tool

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

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


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

 dget -x
https://mentors.debian.net/debian/pool/main/f/fspy/fspy_0.1.1-2.dsc

More information about fspy can be obtained from http://mytty.org/fspy.

Changes since the last upload:

 * QA upload.
 * Applied reproducible build patch from Chris Lamb (Closes: #831354)
 * Bumped compat level to 10
 * Set maintainer to Debian QA Group
 * Dropped build-dep on quilt
 * Removed obsolete fields from d/control
 * Converted to source format 3.0 (quilt)
 * Converted d/rules to dh_ format
 * Removed useless watch file
 * Converted d/copyright to machine-readable format
 * Standards version 4.0.0


Regards,
David William Richmond Davies-Jones
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJZheFKAAoJECIyhjOTII6fxewQALEyOkoOtQr9JEX8KFkiFLFs
ud2kt7OznK3yWecpFAyhoqw8is2DxeSgBLISOaRN1vYsNDn9CSE/2tqHZzBhlU7B
x2CFBHCtUtrFI1+UALcH4ogrRrpXxYbtlqu6/qkUm1Q+WBWGGH99HFoTqU5aMJh9
9ztQ+tuE9YfyFcLeRgXOryQZBD4KXBVudJsICjnYuWivEkQriK7MUsp4MHJ/OYNE
1KyJhkK6gPJrCFI5UnGDHkCQrlizAqb8WY0/At1ZRIth64oyxHu+hSVo+NelrR7Q
bhSndoB7uMJOFtfxmeSNeFlH0k+yZiLHZn+ZioGA2UpZImwtTQoxjQ+Zq9OQHUfB
IVDOorYBC1G5Fv0ZsQhtxlHnHldHzJHc5X8yGcZNMDfKxrQeh743FWewEJgUXKb6
0o4k00wq5qDp8ZvxdSrdhijtRk9ps2zyznOTSGgolnalJIckD+j/mrqSyVZTF0Q2
272/SKeIgU5j0NvTtqrjrBUPCDqEFYAjbFfgzakrwhZ/sudEHKg22GBjtEfAWcoH
lYtjxuoXePWht4cK1nljCYJZFdYRvlc8YRd52C2j5U20o6lLK3FkDbehDDb27ayI
BOwSzpsG1dInXRgaxk5twV5tTrwF13xyahy6W965Qh2sP0K+M5CppD4X0QldfljG
0jqLGlWApthdTkNLIAI9
=YJt3
-END PGP SIGNATURE-

Bug#870823: Subject: RFS: xtail/2.1-6 [QA]

[David William Richmond Davies-Jones]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: xtail
   Version : 2.1-6
   Upstream Author : Chip Rosenthal <c...@unicom.com>
 * URL : https://www.unicom.com/sw/xtail
 * License : Unlicense
   Section : utils

It builds those binary packages:

 xtail - like "tail -f", but works on truncated files, directories, more

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

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


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

 dget -x
https://mentors.debian.net/debian/pool/main/x/xtail/xtail_2.1-6.dsc

More information about xtail can be obtained from
https://www.unicom.com/sw/xtail.

Changes since the last upload:

 * QA upload.
 * Bumped compat level to 10
 * Converted d/rules to dh format
 * Add ISO Date patch from Jari Aalto <jari.aa...@cante.net> (Closes:
#562903)
 * Set maintainer to QA Group
 * Added homepage to d/control
 * Converted d/copyright to machine-readable format
 * Made URLs use HTTPS where possible
 * Standards version 4.0.0


Regards,
David William Richmond Davies-Jones
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJZheBxAAoJECIyhjOTII6fCGkP/2lwQCvFrxfaBjht/ItwhTgE
wS69Mul7ZYbE19v0hk0oXYzPiul+v8F3oEJAFwXsW7vDoHlKIaZcToMkebRP6Fgk
bGkHARkEODb81l6H84gS9stUkSt7OsDe2pCLViSOGqtZ2EpYgOKC9hiZ9f/vYkGK
6akv8tHhQPaUanMBBAYC2yAehMCwqERk5sJCY+Oiw/2s3M9f68Jo9Vkumte+hhQb
q9swBOPxKx38hwClHYYqVs7JPqGpjDg6B4DSw4UFVmXTkp5xu6hzVV19zJxpFFw9
Utj+QNaxYFhCXAYwHhrILMx1TfgcsRMnezUd1xdWf/sSbFUpfRGrpWy1zJpv+hVS
uMLqHdWE9kcY3XLNuD4VfSiejBTz7nExx+FMytOH/8TYH1KBpvTYlIXv8QffZ3zS
yAJQp3D66d/N6XB3H3wIIa1p3DppG/QYGFTyhH+Rs1DaqhL9mpzqB8w/OYxNC74j
r5dw6Ea7Dis94/XLgs14idncxeyj1OZ3UhDgEOrVd+V8f2GsMOnzjAcm/mHInGCU
3uaIlEWQOlzyZF/tcSUV7saxzaaCN7OVL/OxYBoUQFv9b+jZneT95Xqv4NbA8z/P
HhU4nDt3mSuZgF0QBklflO4BSBfKLsnAv7nIDJWujMW8KXEflI4826LEGQl85umR
s/eHfHRW3mWfDR+Z/8fn
=DKHE
-END PGP SIGNATURE-

Bug#866976: RM: tetzle [armel armhf] -- RoQA; Qt uses OpenGL ES on armel/armhf

[David William Richmond Davies-Jones]

On Mon, 2017-07-03 at 10:26 +0300, Adrian Bunk wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Qt uses OpenGL ES instead of full OpenGL on armel and armhf,
> making packages that use OpenGL both through Qt and directly
> often FTBFS (as in this case).

Sorry for having to ask (I'm still an amateur), but how do I fix this?

Bug#866958: Subject: RFS: tetzle/2.1.0-1 [QA]

[David William Richmond Davies-Jones]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: tetzle
   Version : 2.1.0-1
   Upstream Author : Graeme Gott <gra...@gottcode.org>
 * URL : https://gottcode.org/tetzle/
 * License : GPL-3
   Section : games

It builds those binary packages:

 tetzle - Jigsaw puzzle game

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

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


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

 dget -x https://mentors.debian.net/debian/pool/main/t/tetzle/tetzle_2.
1.0-1.dsc

More information about tetzle can be obtained from https://gottcode.org
/tetzle/

  Changes since the last upload:

  * QA upload.
  * New upstream release
- Updated build-deps to QT5
  * Removed broken watch file
  * Replaced menu file with desktop file
  * Added some missing information in d/copyright
  * Bumped compat to 10
  * Standards version 4.0.0


  Regards,
   David William Richmond Davies-Jones

Bug#864291: samba: Trivial DOS against servers running 4.2.14+dfsg-0+deb8u5 with Unix Extensions enabled

[Alun Jones]

Package: samba
Version: 2:4.2.14+dfsg-0+deb8u6
Severity: important
Tags: upstream

Dear Maintainer,

On the current stable version of Samba, it is trivially easy to cause instances
of the Samba daemon, smbd, to eat CPU and leak memory. By launching
multiple connections, this can be used to cause a DOS of the machine running
the Samba service.

The fault relates to the handling of dangling symbolic links and can
be triggered as follows:

1. Create a broken symbolic link with Unix extensions enabled:

  smbclient //server/share -c "posix; symlink nothing broken"

2. Try to write to the broken symbolic link with Unix extensions disabled:

  smbclient //server/share -c "put /etc/issue broken"

Step 2 results in an instance of smbd running a busy loop and leaking 
memory *even after the client has disconnected*. By running step 2 
multiple times, CPU and memory resources on the machine can be exhausted.

The issue was fixed in the upstream version of Samba in February this year
(the fix is in 4.5.6):

https://github.com/samba-team/samba/commit/10c3e3923022485c720f322ca4f0aca5d7501310

Given the severity of the issue and the trivial ease with which it can be
triggered, is there any chance of this fix being backported to the version of
Samba currently supported by Jessie?

Thanks,
Alun.

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

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

Versions of packages samba depends on:
ii  adduser  3.113+nmu3
ii  dpkg 1.17.27
ii  libbsd0  0.7.0-2
ii  libc62.19-18+deb8u9
ii  libhdb9-heimdal [heimdal-hdb-api-8]  1.6~rc2+dfsg-9
ii  libldb1  2:1.1.20-0+deb8u1
ii  libpam-modules   1.1.8-3.1+deb8u2
ii  libpam-runtime   1.1.8-3.1+deb8u2
ii  libpopt0 1.16-10
ii  libpython2.7 2.7.9-2+deb8u1
ii  libtalloc2   2.1.2-0+deb8u1
ii  libtdb1  1.3.6-0+deb8u1
ii  libtevent0   0.9.28-0+deb8u1
ii  lsb-base 4.1+Debian13+nmu1
ii  multiarch-support2.19-18+deb8u9
ii  procps   2:3.3.9-9
ii  python   2.7.9-1
ii  python-dnspython 1.12.0-1
ii  python-ntdb  1.0-5
ii  python-samba 2:4.2.14+dfsg-0+deb8u6
pn  python2.7:any
ii  samba-common 2:4.2.14+dfsg-0+deb8u6
ii  samba-common-bin 2:4.2.14+dfsg-0+deb8u6
ii  samba-dsdb-modules   2:4.2.14+dfsg-0+deb8u6
ii  samba-libs   2:4.2.14+dfsg-0+deb8u6
ii  tdb-tools1.3.6-0+deb8u1
ii  update-inetd 4.43

Versions of packages samba recommends:
ii  attr   1:2.4.47-2
ii  logrotate  3.8.7-1+b1
ii  samba-vfs-modules  2:4.2.14+dfsg-0+deb8u6

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
ii  ntp1:4.2.6.p5+dfsg-7+deb8u2
pn  smbldap-tools  
pn  winbind

-- debconf information:
  samba/run_mode: daemons
  samba-common/title:

Bug#857465: Postfix-3.1.4 reintroduces bug 214741

[LaMont Jones]

tags 857465 + wontfix
--

I believe that the postinst does the best it can at getting the FQDN into
main.cf -- this doesn't do much for the upgrade path though.

I agree with upstream that postfix should not be calling gethostbyname
at runtime -- if this is happening in a fresh install, then I'm interested
in the configuration of the host that led to this, so that we can make that
path work better.

lamont

On Sat, May 20, 2017 at 12:29:15PM +0100, James Cowgill wrote:
> On 11/03/17 16:32, Herwig Burgert wrote:
> > Package: postfix
> > 
> > Version: 3.1.4-4
> > 
> > Description:
> > 
> > postfix-3.1.4 currently part of the upcoming release of strech
> > reintroduces bug 214741 which was fixed for postfix-2.11.3 (jessie). -
> > Fetch the correct FQDN for myhostname.
> > For details on this bug see:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214741.
> 
> FWIW, this was also broken for me when I setup my new postfix server
> (postfix was convinced my domain was "localdomain"). I gave up and
> hardcoded the correct mydomain in main.cf.
> 
> James
> 
> 

Bug#855173: RFP: keepassxc -- Community fork of KeePassX, a free and open-source cross-platform password manager.

[Matt Jones]

I am not a maintainer or developer but an active user if debain and
keepass. I would be willing to take this in depending on timeframe. I have
time starting next week to devote to this. I have built packages in the
past so this is not a huge issue for me

On Feb 14, 2017 5:45 PM, "KeePassXC Team"  wrote:

> Package: wnpp
> Severity: wishlist
>
> * Package name: keepassxc
>   Version : 2.1.1
>   Upstream Author : KeePassXC 
> * URL : https://keepassxc.org
> * License : GPLv2, GPLv3
>   Programming Lang: C++
>   Description : Community fork of KeePassX, a free and open-source
> cross-platform password manager.
>
> KeePassXC aims to incorporate many pull requests as well as additional
> newly developed features that have never been merged into KeePassX.
> Besides many bug fixes and other minor changes, the current version
> (2.1.1) already contains the following additional features:
>
> - Autotype on all three major platforms (Linux, Windows, OS X)
> - Stand-alone password generator
> - Password strength meter
> - Use website's favicons as entry icons
> - Merging of databases
> - Automatic reload when the database changed on disk
> - KeePassHTTP support for use with PassIFox in Firefox and chromeIPass
> in Google Chrome and Chromium
>
> More features will come in 2.2.0. (e.g. Yubikey support, Twofish cipher
> support, a welcome screen redesign, general user interface improvements
> etc.)
>
> At the time of the fork, KeePassXC built upon the latest but never
> released KeePassX source tree, which included the switch to Qt5.
>
> I'm writing you as one of the main developers of KeePassXC. We would
> like to get KeePassXC into the official Debian repositories and from
> there into other derivatives such as Ubuntu. We would be willing to
> package KeePassXC ourselves, but since none of us developers is an
> active Debian user, we would like to ask first if someone else would be
> willing to package it for us. In the interest of package quality, this
> would likely be best. Packaging KeePassXC is (and for the foreseeable
> future will be) quite similar to packaging KeePassX, so maybe the
> original KeePassX maintainer could handle this if he's willing to? He's
> on X-Debbugs-Cc.
>
> Thanks and regards
> Janek
>
>

Bug#852697: [pkg-gnupg-maint] Bug#852697: gnupg-agent: automatically starts gpg-agent in root user slice

[Michael Jones]

On Sun, 5 Feb 2017 11:21:58 +0100 Laurent Bonnaud
 wrote:
> On 05/02/2017 10:08, Daniel Kahn Gillmor wrote:
> 
> > Were you able to isolate what's launching the process?
> 
> Yes I finally took the time to test all apt hooks and found the cause: it is 
> /etc/apt/apt.conf.d/11daptup from package daptup.
> 
> Should I reassign the bug?
> 
> > btw, that gpg-agent process is a systemd user service.  when root fully
> > logs out of the machine, that user service should also terminate.
> > perhaps its running might cause you less worry if you know it will get
> > cleaned up at logout?
> 
> It is more complicated than that: since I have cron-apt on my system, a new 
> gpg-agent process is spawned automatically each night and does not go away.
> 
> -- 
> Laurent.
> 
> 

I also can't ssh, it seems the gpg-agent no longer looks at
"/home/mike/.gnupg/gpg-agent.conf", does not find "enable-ssh-support",
and starts the gpg agent without ssh support as;

mike  1717 1  0 10:09 ?00:00:00 /lib/systemd/systemd --user
...
mike  3275  1717  0 10:23 ?00:00:00  \_ /usr/bin/gpg-agent
--supervised

Kind Regards,
Mike