Bug#872401: ITP: lmdbxx -- C++ wrapper for LMDB

[Hubert Chathi]

Package: wnpp
Owner: Hubert Chathi 
Severity: wishlist

* Package name: lmdbxx
  Version : 0.9.14.1+git
  Upstream Author : Arto Bendiken 
* URL or Web page : https://github.com/bendiken/lmdbxx
* License : Unlicense (public domain)
  Description : C++ wrapper for LMDB

 "This is a comprehensive C++ wrapper for the LMDB embedded database library,
 offering both an error-checked procedural interface and an object-oriented
 resource interface with RAII semantics."

Bug#851052: Fix flickering

[James Cameron]

Extra text insertion cursor (caret) blinks were scheduled.

Each blink invalidated the window and redrew it.

I've submitted a patch upstream on 13791.  I'm interested to hear if
it fixes it for others.

http://dev.laptop.org/~quozl/z/1diDDl.txt

-- 
James Cameron
http://quozl.netrek.org/

Bug#870843: [pkg-go] Bug#870843: golang-github-armon-go-metrics-dev: unhandled symlink to directory conversion: /usr/share/gocode/src/github.com/sirupsen/logrus -> ../Sirupsen/logrus

[Martín Ferrari]

reassign 870843 golang-github-sirupsen-logrus-dev
thanks

This bug is filed under the wrong package.

Bug#872400: augeas: CVE-2017-7555: Improper handling of escaped strings leading to memory corruption

[Salvatore Bonaccorso]

Source: augeas
Version: 1.8.0-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/hercules-team/augeas/pull/480

Hi,

the following vulnerability was published for augeas.

CVE-2017-7555[0]:
crash/memory corruption when handling certain escaped strings

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-7555
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7555
[1] https://github.com/hercules-team/augeas/pull/480
[2] 
https://github.com/hercules-team/augeas/pull/480/commits/39592c4eef8d4826947adca94c7fbd6efb8d47ca
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1475621 (not
addessible at time of writing)
[4] http://www.openwall.com/lists/oss-security/2017/08/17/3

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#872339: libgda-5.0-4: Can't rebuild package with --with-ui

[Pavlo Solntsev]

ok, I was able to compile the package with ui support. Could you please
explain why this option was turned off?

Bug#872012: [tex-common] Installing fails due to fmtutil failure

[Norbert Preining]

Hi

> After all, feel free to close this bugreport then...

Found the problem.

You need to set
export LANG=C
in the chroot. luatex dies when LANG is unset.

I will add LANG=C to the fmtutil calls to make sure
that this doesn't happen again.

Thanks for your report and insistance!

Norbert

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

Bug#872277: patched version needed to avoid fatal: Out of memory, getdelim failed crash

[Yaroslav Halchenko]

Hi Jonathan -- thank you very much for looking into it

> > Subject: patched version needed to avoid fatal: Out of memory, getdelim 
> > failed crash
> You could say that about all bugs.  A patched version is needed to fix
> the bug. :)

;) indeed... should have said "attached patch is needed to ..." ;-)


> [...]
> > For a while this issue was haunting us in various deployments, in 
> > particular 
> > - on NFS mounts
> > - within standalone build of git-annex
> > that many git commands could crash randomly at various points with

> > fatal: Out of memory, getdelim failed

> > message.  Recently upstream tracked it down, and offered a perspective patch
> > (see attached, cherry-picked from git upstream repository) -- it is a very
> > simple patch.  I have tested it on our deployments (as applied against
> > 1:2.11.0-3 in stretch, but it is applicable to sid/experimental version as
> > well)

> > original report upstream and the thread with further discussion(s) on
> > possible improvements to the patch:
> > https://public-inbox.org/git/20170809173928.h2ylvg5tp2p5i...@hopa.kiewit.dartmouth.edu/

> > Please please consider adapting this patch for the official packages of git 
> > in
> > Debian sid, and ideally to the version in stretch.  This would be of great 
> > help
> > to avoid those problems on the NFS-mounts and to generate fixed standalone
> > builds of git-annex (CCing git-annex author, Joey) which many users rely 
> > upon
> > on various (even non-Debian) systems.

> Thanks for writing.  Can you say more about the impact?  

devastation... pain ... suffering... really -- somehow it started to
show up more for us recently and since no easy workaround -- I just had
to provide a patched version to get around.  In datalad we use git
extensively so we run into higher chance to hit it because git is likely
to be invoked multiple times  per 1 datalad command.  Just now, my
previous email was to a student reporting the issue while trying to tame
git.
Also running it within singularity container also seems to make this bug
more reproducible -- and we are switching to use Debian singularity
container for many computations on our CentOS HPC...  so although very
basic, its impact is large and it greatly reduces our quality of life ;)

> E.g. is there a
> reproduction recipe I can use to experience this on stable?  How often
> do people experience this, and do they have a workaround?

(un)fortunately so far I just had experienced it within stable debian
singularity environment (such as our neurodebian one, e.g. this one
(http://datasets.datalad.org/singularity/neurodebian-v2.2.img.tgz, it is
huge etc), must be on a bind-mount of NFS-mounted partition (not sure if
specific mount options  are in play here as well). 

but because issue is kinda ill-messaged (has actually nothing to do with
insufficient memory as far as I see it), I think it also misguides some
folks: quick google lead to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842586
which was closed since on the next run build succeeded...

I do not think that there is a workaround besides a patch or rebuild
(with  HAVE_GETDELIM=)

> The patch also appeared to still be under discussion upstream.  Someone
> investigating how the standard and various platforms handle errors from
> getdelim would likely be appreciated there.

yeah

> One possibility in the Debian packaging would be for us to pass
> HAVE_GETDELIM= in our build flags to avoid using getdelim altogether.
> That way, we get correct behavior while waiting for the upstream
> discussion to settle.

whatever you think would be more appropriate is good with me, as long as
we do not keep hitting this issue ;-)  I just know that initial
patch seems have resolved issue for me, and I haven't tried building
without that functionality (i.e. with HAVE_GETDELIM=) so not sure if
that one wouldn't have any side-effects if upstream largely builds/tests
with it

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#849525: Bug also confirmed in version 1.28.2

[Markus Hamilton]

On Mon, 14 Aug 2017 21:41:20 -0500 Jason Crain  
wrote:

> On Mon, Aug 14, 2017 at 05:15:56PM -0400, Markus Hamilton wrote:
> > The bug is still there using version 1.28.2 now ... in fact there 
are forum
> > discussions and bug reports all over the internet about this 
problem for
> > years now. Could we at least get a statement from the maintainers 
whether
> > this will ever get fixed or is there some policy we could implement 
to allow
> > this. SOME information would really help to figure out where this 
is going.

>
> From the gvfs-mount manpage:
>
> -a, --anonymous
> Use an anonymous user when authenticating
>
> This option was added in gvfs version 1.23.90 so gvfs-mount (or gio
> mount) should work on stretch or later. On earlier versions you can try
> entering a fake username and password depending on how you have samba
> set up.
>
> About pcmanfm and caja - I don't see any problem with anonymous smb
> shares using nautilus so this is likely something that pcmanfm and caja
> need to add support for.
>
>

I think we misunderstand each other. I am not talking about anonymous 
access. I am talking about accessing a samba server which does not have 
anonymous (guest) access enabled. So users do have to provide a username 
to be able to login. Some of these usernames (aka smb accounts) just 
have no (or in words an empty) password. Using anonymous access will not 
work (disabled on the server). A fake username will not work either 
(unknown to the server). It has to be a valid username and an empty 
password. Using mount via command line works fine. Here's an example - 
"markus" is a valid smb account at the server. The password is empty.


sudo mount -t cifs //servername/sharename /mnt -o 
username=markus,password=""


But when I try the same operation using gvfs-mount like this:

gvfs-mount smb://servername/sharename

Then the first thing gvfs-mount does is spitting out a message saying 
"Password required for share sharename on servername". It then asks for 
username, then domain and finally password. Just hitting "enter" doesn't 
cut it. gvfs-mount asks again for the password.


So far I have not managed to mount a smb share using gvfs-mount if the 
valid smb account simply is passwordless. If you can tell me how to do 
that then I'm ready to shift the blame to to pcmanfm and caja. "mount -t 
cifs..." is living proof that it's not a samba (or Windows, for that 
matter) problem.


So again: how do I gvfs-mount a smb share with a non-anonymous, valid 
smb username but without entering (because there is none) a password?


Thank you for reading here. There are so many users out there with the 
same problem. It used to work. It stopped working at some point during 
the life of jessie.

Bug#872399: salt: CVE-2017-12791: Directory traversal vulnerability on salt-master via crafted minion IDs

[Salvatore Bonaccorso]

Source: salt
Version: 2016.11.5+ds-1
Severity: grave
Tags: security upstream patch
Forwarded: https://github.com/saltstack/salt/pull/42944

Hi,

the following vulnerability was published for salt.

CVE-2017-12791[0]:
Maliciously crafted minion IDs can cause unwanted directory traversals on the 
Salt-master

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-12791
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12791
[1] https://github.com/saltstack/salt/pull/42944
[2] 
https://github.com/saltstack/salt/commit/6366e05d0d70bd709cc4233c3faf32a759d0173a

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#872398: x11-xkb-utils: setxkbmap, when run at startup, has no effect

[Christopher Cramer]

Package: x11-xkb-utils
Version: 7.7+3+b1
Severity: normal

This is my .xsession (which is executed by xdm):

xsetroot -solid black
xset -b
xset s 0
xset s off
xset dpms 0 0 0
xset -dpms
xset r rate 250 30
setxkbmap -keycodes evdev -types default -compat 
'basic+misc+iso9995+ledcaps(group_lock)' -symbols 
'pc+us+kh:2+level3(ralt_switch)+ctrl(nocaps)'
xkbset -bell -feedback sticky -twokey latchlock
xkbset exp '=sticky'
ssh-agent &
export _JAVA_AWT_WM_NONREPARENTING=1
exec ratpoison

It all used to work perfectly. But at some point, the setxkbmap command
stopped having any effect when run from the .xsession file. I notice
this immediately after Ratpoison has started because I am used to hitting
the Caps Lock key, intending for it to be remapped as Control, to enter
a Ratpoison command. But instead it acts as Caps Lock. It is as if the
setxkbmap command was never run at all.

However, if I enter that same command manually (in bash, running in
urxvt), it works. The .xsession file is definitely being executed,
because the effects of all the other commands are happening.  I tried
also putting the command into the Ratpoison startup file, .ratpoisonrc,
but it didn't work there either.

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

Kernel: Linux 4.11.0-2-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 x11-xkb-utils depends on:
ii  libc62.24-14
ii  libx11-6 2:1.6.4-3
ii  libxaw7  2:1.0.13-1+b2
ii  libxkbfile1  1:1.0.9-2
ii  libxt6   1:1.1.5-1

x11-xkb-utils recommends no packages.

x11-xkb-utils suggests no packages.

-- no debconf information

Bug#872389: Evolution classified under “Office” instead of “Internet” in the desktop menu.

[Mario Castelán Castro]

Package: evolution
Version: 3.22.6-1

Thunderbird, Geary and Sylpheed are found under the menu “Internet” in
the desktop menu, but Evolution is inconsistently classified under ”Office”.

I am using Debian 9.



signature.asc
Description: OpenPGP digital signature

Bug#856311: avahi-daemon: Won't start due to rlimit nproc, confused by lxc containers

[Trent Lloyd]

On 17/08/17 09:58, James Valleroy wrote:

On Mon, 27 Feb 2017 10:35:18 -0500 Matthew Gabeler-Lee
 wrote:

On one of my systems, avahi-daemon can't start due to its default rlimit-nproc 
value of 3.

This also affects Debian-CI for packages that depend on avahi-daemon
(such as https://ci.debian.net/packages/f/freedombox-setup/unstable/amd64/).

It looks like the default limit was removed in upstream release v0.7.



As you state, I removed the default limits in 0.7 for exactly this 
reason, if you don't use UID separation with your containers you run 
into this issue.
The change is literally to comment out the lines in the default 
avahi-daemon.conf


I actually ended up removing all the limits because the memory limit was 
also sometimes being exceeded causing crashes on larger networks.  So I 
commented out the entire section and decided with systemd we can leave 
it up to the system to impose any limits they desire as part of the init 
settings - but really it was just some kind of poor anti-DoS measure.  
It would not be unreasonable to backport this change to stable in my 
view, and intend to SRU the same change to stable in Ubuntu.


- Trent

Bug#872397: dnsmasq: needs to call restorecon from /etc/init.d script for SE Linux systems

[Russell Coker]

Package: dnsmasq
Version: 2.76-5
Severity: normal

A patch like the following is needed for correct operation on SE Linux systems
that aren't using systemd.  This sets the correct context on that directory,
running restorecon multiple times is not a problem and running it when SE
Linux is disabled is also not a problem.

--- /etc/init.d/dnsmasq.orig2017-08-15 13:25:33.454535140 +1000
+++ /etc/init.d/dnsmasq 2017-08-16 14:36:30.297443148 +1000
@@ -127,6 +127,7 @@
mkdir /run/dnsmasq || return 2
chown dnsmasq:nogroup /run/dnsmasq || return 2
 fi
+   [ -x /sbin/restorecon ] && /sbin/restorecon /run/dnsmasq
 
start-stop-daemon --start --quiet --pidfile /run/dnsmasq/$NAME.pid 
--exec $DAEMON --test > /dev/null || return 1
start-stop-daemon --start --quiet --pidfile /run/dnsmasq/$NAME.pid 
--exec $DAEMON -- \


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1), LANGUAGE=en_AU:en 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnsmasq depends on:
ii  dnsmasq-base 2.76-5+b1
ii  init-system-helpers  1.48
ii  netbase  5.4

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
pn  resolvconf  

-- Configuration Files:
/etc/dnsmasq.conf changed [not included]
/etc/init.d/dnsmasq changed [not included]

-- no debconf information

Bug#872396: dnsmasq: should have a tmpfiles.d entry for /run/dnsmasq

[Russell Coker]

Package: dnsmasq
Version: 2.76-5
Severity: normal

d /run/dnsmasq 755 dnsmasq nogroup

Something like the above in /usr/lib/tmpfiles.d/dnsmasq.conf will correctly
create the directory and assign the correct SE Linux context when running
systemd.


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1), LANGUAGE=en_AU:en 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnsmasq depends on:
ii  dnsmasq-base 2.76-5+b1
ii  init-system-helpers  1.48
ii  netbase  5.4

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
pn  resolvconf  

-- Configuration Files:
/etc/dnsmasq.conf changed [not included]
/etc/init.d/dnsmasq changed [not included]

-- no debconf information

Bug#872395: cinnamon: Re-enable moving default panel to top of screen

[Charles Cazabon]

Package: cinnamon
Version: 3.2.7-4
Severity: wishlist
Tags: upstream

Dear Maintainer,

Hi - Cinnamon in previous versions had an exposed preference to allow you to
move the default panel from the bottom of the screen to the top.

It appears in Cinnamon 3 - at least in 3.2.7 as shipped by Debian in sid/buster
- this preference is no longer present in the configuration/settings app.  At
least I can't find it, and I can't find any references to the feature online.
Other people besides me miss this feature.

The actual feature still exists and works - if you manually set the setting
with gsettings as follows:

gsettings set org.cinnamon panels-enabled "['1:0:top']"

... it will correctly move the panel to the top of the screen, and everything
continues to work fine.  So there seems to be little reason to hide this
feature, given that it was previously exposed and many people came to depend on
it.

Please add - or convince upstream to add - this setting back to those exposed
in the settings app.

Thank you,

Charles



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

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

Versions of packages cinnamon depends on:
ii  caribou  0.4.21-1+b1
ii  cinnamon-common  3.2.7-4
ii  cinnamon-control-center  3.2.1-3
ii  cinnamon-desktop-data3.2.4-4
ii  cinnamon-screensaver 3.2.13-4
ii  cinnamon-session 3.2.0-4
ii  cinnamon-settings-daemon 3.2.1-3
ii  cjs  3.2.0-3
ii  cups-pk-helper   0.2.6-1+b1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gir1.2-accountsservice-1.0   0.6.43-1
ii  gir1.2-caribou-1.0   0.4.21-1+b1
ii  gir1.2-clutter-1.0   1.26.2+dfsg-1
ii  gir1.2-cmenu-3.0 3.2.0-3
ii  gir1.2-cogl-1.0  1.22.2-2
ii  gir1.2-cvc-1.0   3.2.4-4
ii  gir1.2-gdkpixbuf-2.0 2.36.5-2
ii  gir1.2-gkbd-3.0  3.22.0.1-1+b1
ii  gir1.2-glib-2.0  1.50.0-1+b1
ii  gir1.2-gnomedesktop-3.0  3.22.2-1
ii  gir1.2-gtk-3.0   3.22.16-1
ii  gir1.2-gtkclutter-1.01.8.2-2
ii  gir1.2-javascriptcoregtk-3.0 2.4.11-3
ii  gir1.2-keybinder-3.0 0.3.1-1
ii  gir1.2-meta-muffin-0.0   3.2.1-2
ii  gir1.2-networkmanager-1.01.8.2-1
ii  gir1.2-notify-0.70.7.7-2
ii  gir1.2-pango-1.0 1.40.6-1
ii  gir1.2-polkit-1.00.105-18
ii  gir1.2-soup-2.4  2.56.0-2+deb9u1
ii  gir1.2-upowerglib-1.00.99.4-4+b1
ii  gir1.2-xapp-1.0  1.0.2-1
ii  gkbd-capplet 3.22.0.1-1+b1
ii  gnome-backgrounds3.22.1-1
ii  gnome-themes-standard3.22.3-1
ii  gsettings-desktop-schemas3.22.0-1
ii  iso-flags-png-320x2401.0.1-1
ii  libatk-bridge2.0-0   2.24.1-1
ii  libatk1.0-0  2.24.0-1
ii  libc62.24-12
ii  libcairo21.14.10-1
ii  libcinnamon-menu-3-0 3.2.0-3
ii  libcjs0  3.2.0-3
ii  libclutter-1.0-0 1.26.2+dfsg-1
ii  libcogl-pango20  1.22.2-2
ii  libcogl-path20   1.22.2-2
ii  libcogl201.22.2-2
ii  libcroco30.6.12-1
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libgirepository-1.0-11.50.0-1+b1
ii  libgl1-mesa-glx [libgl1] 13.0.6-1+b2
ii  libglib2.0-0 2.52.3-1
ii  libglib2.0-bin   2.52.3-1
ii  libgstreamer1.0-01.12.2-1
ii  libgtk-3-0   3.22.16-1
ii  libjs-jquery 3.1.1-2
ii  libmozjs-24-024.2.0-5.1+b2
ii  libmuffin0   3.2.1-2
ii  libpango-1.0-0   1.40.6-1
ii  libpangocairo-1.0-0  1.40.6-1
ii  libstartup-notification0 

Bug#872394: cinnamon: In-panel application launcher hover text wrong; always displays "Files"

[Charles Cazabon]

Package: cinnamon
Version: 3.2.7-4
Severity: minor

Dear Maintainer,

Hi - a minor bug but it affects usability.  If you "add applets" to the default
panel, choose to add an "application launcher", then it adds a default launcher
pointing to the file browser application, with appropriate folder icon and
hover text that says "Files".

You then right-click and select options->edit to point it to the application
you actually want to launch, enter a name, and pick an icon.

However, ever after setting a different title, the launcher retains the hover
text "Files", which makes it difficult to determine which launcher is for which
app if the icons are not sufficiently distinguishing.

The hover text should be the title that was entered for the instance of the
launcher applet.

Thanks,

Charles



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

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

Versions of packages cinnamon depends on:
ii  caribou  0.4.21-1+b1
ii  cinnamon-common  3.2.7-4
ii  cinnamon-control-center  3.2.1-3
ii  cinnamon-desktop-data3.2.4-4
ii  cinnamon-screensaver 3.2.13-4
ii  cinnamon-session 3.2.0-4
ii  cinnamon-settings-daemon 3.2.1-3
ii  cjs  3.2.0-3
ii  cups-pk-helper   0.2.6-1+b1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gir1.2-accountsservice-1.0   0.6.43-1
ii  gir1.2-caribou-1.0   0.4.21-1+b1
ii  gir1.2-clutter-1.0   1.26.2+dfsg-1
ii  gir1.2-cmenu-3.0 3.2.0-3
ii  gir1.2-cogl-1.0  1.22.2-2
ii  gir1.2-cvc-1.0   3.2.4-4
ii  gir1.2-gdkpixbuf-2.0 2.36.5-2
ii  gir1.2-gkbd-3.0  3.22.0.1-1+b1
ii  gir1.2-glib-2.0  1.50.0-1+b1
ii  gir1.2-gnomedesktop-3.0  3.22.2-1
ii  gir1.2-gtk-3.0   3.22.16-1
ii  gir1.2-gtkclutter-1.01.8.2-2
ii  gir1.2-javascriptcoregtk-3.0 2.4.11-3
ii  gir1.2-keybinder-3.0 0.3.1-1
ii  gir1.2-meta-muffin-0.0   3.2.1-2
ii  gir1.2-networkmanager-1.01.8.2-1
ii  gir1.2-notify-0.70.7.7-2
ii  gir1.2-pango-1.0 1.40.6-1
ii  gir1.2-polkit-1.00.105-18
ii  gir1.2-soup-2.4  2.56.0-2+deb9u1
ii  gir1.2-upowerglib-1.00.99.4-4+b1
ii  gir1.2-xapp-1.0  1.0.2-1
ii  gkbd-capplet 3.22.0.1-1+b1
ii  gnome-backgrounds3.22.1-1
ii  gnome-themes-standard3.22.3-1
ii  gsettings-desktop-schemas3.22.0-1
ii  iso-flags-png-320x2401.0.1-1
ii  libatk-bridge2.0-0   2.24.1-1
ii  libatk1.0-0  2.24.0-1
ii  libc62.24-12
ii  libcairo21.14.10-1
ii  libcinnamon-menu-3-0 3.2.0-3
ii  libcjs0  3.2.0-3
ii  libclutter-1.0-0 1.26.2+dfsg-1
ii  libcogl-pango20  1.22.2-2
ii  libcogl-path20   1.22.2-2
ii  libcogl201.22.2-2
ii  libcroco30.6.12-1
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libgirepository-1.0-11.50.0-1+b1
ii  libgl1-mesa-glx [libgl1] 13.0.6-1+b2
ii  libglib2.0-0 2.52.3-1
ii  libglib2.0-bin   2.52.3-1
ii  libgstreamer1.0-01.12.2-1
ii  libgtk-3-0   3.22.16-1
ii  libjs-jquery 3.1.1-2
ii  libmozjs-24-024.2.0-5.1+b2
ii  libmuffin0   3.2.1-2
ii  libpango-1.0-0   1.40.6-1
ii  libpangocairo-1.0-0  1.40.6-1
ii  libstartup-notification0 0.12-4+b2
ii  libx11-6 2:1.6.4-3
ii  libxfixes3   1:5.0.3-1
ii  libxml2  2.9.4+dfsg1-3
ii  mesa-utils

Bug#872393: sphinx: autopkgtest failure on armhf with webkit2gtk 2.17.90

[Jeremy Bicha]

Source: sphinx
Version: 1.5.6-2

Hi, webkit2gtk 2.17.90 (2.18 Beta 1) is no migrating out of
artful-proposed because the sphinx-doc autopkgtest is failing on
armhf.

http://autopkgtest.ubuntu.com/packages/s/sphinx/artful/armhf

Could you look into this?

Thanks,
Jeremy Bicha

Bug#872194: espeakup: Espeakup fails to start due to libespeak-ng.so.1.1.49 segfault

[Steven Shiau]

OK, if I downgrade these two packages from 1.49.1 to 1.49.0, then 
everything is OK:

espeak-ng-data:amd641.49.0+dfsg-11
libespeak-ng1:amd64 1.49.0+dfsg-11

Steven

On 8/15/2017 PM 02:28, Steven Shiau wrote:

Package: espeakup
Version: 1:0.80-5+b3
Severity: normal

Dear Maintainer,

Espeakup fails to start due to libespeak-ng.so.1.1.49 segfault in Debian Sid.

* How to reproduce the issue?
  Just run "sudo service espeakup start"

  The error messages in /var/log/messages are attached.

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

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

Versions of packages espeakup depends on:
ii  espeak   1.48.04+dfsg-5+b1
ii  init-system-helpers  1.49
ii  libc62.24-14
ii  libespeak-ng11.49.1+dfsg-2
ii  lsb-base 9.20161125

espeakup recommends no packages.

espeakup suggests no packages.

-- no debconf information


--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/47CF935C
Fingerprint: 0240 1FEB 695D 7112 62F0  8796 11C1 12DA 47CF 935C

Bug#872392: libgc: Please add support for arm64ilp32

[Wookey]

Source: libgc
Version: 7.4.2-8
Severity: normal
Tags: patch upstream

arm64ilp32 is a new arm64 ABI currently being bootstrapped. libgc
needs symbols updates and a config update.

Attached is a patch to add the config.
And another for the symbols update.

The symbols update can also easily done with the following sed:
sed -i -e '/^ /s/=\(!\?\)arm64 /&\1arm64ilp32 /' debian/libgc1c2.symbols
sed -i -e 's/_Zn\(.\){size_t}@Base 1:7.2d/_Zn\1{size_t}@Base 1:7.4.2-8/' 
debian/libgc1c2.symbols
i.e. add arm64ilp32 entries to match arm64
and then update the version on two symbols.

for reasons I don't understand the version on the last two symbols:
_Zna{size_t}@BASE
_Znw{size_t}@BASE
changes from 1:7.2d to the current 1:7.4.2-8
so the above sed to change the version on those two lines is also needed 
for a happy compilation.

More info on the arm64ilp32 port can be found at:
https://wiki.linaro.org/Platform/arm64-ilp32
https://wiki.debian.org/Arm64ilp32Port
--- gcconfig.h	2014-06-03 07:09:52.0 +0100
+++ gcconfig.h.fixed	2017-08-15 04:46:22.019254312 +0100
@@ -1983,9 +1983,17 @@
 # endif
 
 # ifdef AARCH64
-#   define CPP_WORDSZ 64
 #   define MACH_TYPE "AARCH64"
-#   define ALIGNMENT 8
+#   ifdef __ILP32__
+# define ALIGNMENT 4
+# define CPP_WORDSZ 32
+#   else
+# ifndef __LP64__
+#   error --> unknown ABI
+# endif
+# define ALIGNMENT 8
+# define CPP_WORDSZ 64
+#   endif
 #   ifndef HBLKSIZE
 # define HBLKSIZE 4096
 #   endif
--- debian/libgc1c2.symbols.backup	2017-08-11 22:28:32.738255232 +
+++ debian/libgc1c2.symbols	2017-08-12 01:42:18.279939037 +
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 1:7.4.2 alpha amd64 arm64 armel armhf hppa hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc powerpcspe ppc64 ppc64el s390x x32
+# SymbolsHelper-Confirmed: 1:7.4.2 alpha amd64 arm64 arm64ilp32 armel armhf hppa hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc powerpcspe ppc64 ppc64el s390x x32
 libgc.so.1 libgc1c2 #MINVER#
  (arch=armel)AO_compare_double_and_swap_double_emulation@Base 1:7.4.2
  (arch=armel)AO_fetch_compare_and_swap_emulation@Base 1:7.4.2
@@ -9,8 +9,8 @@
  GC_FirstDLOpenedLinkMap@Base 1:7.2d
  (arch=kfreebsd-amd64 kfreebsd-i386)GC_FreeBSDGetDataStart@Base 1:7.2d
  (arch=sparc sparc64)GC_SysVGetDataStart@Base 1:7.2d
- (arch=!arm64 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el !sh4)GC_acquire_mark_lock@Base 1:7.4.2
- (arch=!arm64 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el !sh4)GC_active_count@Base 1:7.4.2
+ (arch=!arm64 !arm64ilp32 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el !sh4)GC_acquire_mark_lock@Base 1:7.4.2
+ (arch=!arm64 !arm64ilp32 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el !sh4)GC_active_count@Base 1:7.4.2
  GC_add_ext_descriptor@Base 1:7.2d
  GC_add_map_entry@Base 1:7.2d
  GC_add_roots@Base 1:7.2d
@@ -27,8 +27,8 @@
  GC_alloc_large@Base 1:7.2d
  GC_alloc_large_and_clear@Base 1:7.2d
  GC_alloc_reclaim_list@Base 1:7.2d
- (arch=arm64 nios2 hppa ppc64el sh4)GC_allocate_lock@Base 1:7.4.2
- (arch=!arm64 !nios2 !hppa !ppc64el !sh4)GC_allocate_ml@Base 1:7.4.2
+ (arch=arm64 arm64ilp32 nios2 hppa ppc64el sh4)GC_allocate_lock@Base 1:7.4.2
+ (arch=!arm64 !arm64ilp32 !nios2 !hppa !ppc64el !sh4)GC_allocate_ml@Base 1:7.4.2
  GC_allochblk@Base 1:7.2d
  GC_allochblk_nth@Base 1:7.2d
  GC_allocobj@Base 1:7.2d
@@ -59,7 +59,7 @@
  GC_build_fl@Base 1:7.2d
  GC_build_fl_clear2@Base 1:7.2d
  GC_build_fl_clear4@Base 1:7.2d
- (arch=!arm64 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el !sh4)GC_bytes_allocd_tmp@Base 1:7.4.2
+ (arch=!arm64 !arm64ilp32 !nios2 !hppa !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !ppc64el !sh4)GC_bytes_allocd_tmp@Base 1:7.4.2
  GC_bytes_found@Base 1:7.2d
  GC_call_with_alloc_lock@Base 1:7.2d
  GC_call_with_gc_active@Base 1:7.2d
@@ -94,12 +94,12 @@
  GC_continue_reclaim@Base 1:7.2d
  GC_copy_bl@Base 1:7.2d
  GC_copyright@Base 1:7.2d
- (arch=!arm64 !nios2 !hppa !ppc64el !sh4)GC_core_finalized_malloc@Base 1:7.4.2
- (arch=!arm64 !nios2 !hppa !ppc64el !sh4)GC_core_gcj_malloc@Base 1:7.4.2
- (arch=!arm64 !nios2 !hppa !ppc64el !sh4)GC_core_malloc@Base 1:7.4.2
- (arch=!arm64 !nios2 !hppa !ppc64el !sh4)GC_core_malloc_atomic@Base 1:7.4.2
+ (arch=!arm64 !arm64ilp32 !nios2 !hppa !ppc64el !sh4)GC_core_finalized_malloc@Base 1:7.4.2
+ (arch=!arm64 !arm64ilp32 !nios2 !hppa !ppc64el !sh4)GC_core_gcj_malloc@Base 1:7.4.2
+ (arch=!arm64 !arm64ilp32 !nios2 !hppa !ppc64el !sh4)GC_core_malloc@Base 1:7.4.2
+ (arch=!arm64 !arm64ilp32 !nios2 !hppa !ppc64el !sh4)GC_core_malloc_atomic@Base 1:7.4.2
  GC_current_warn_proc@Base 1:7.2d
- (arch=!arm64 !nios2 !kfreebsd-amd64 !kfreebsd-i386 !mips !mips64el !mipsel !s390 !s390x !sparc !sparc64)GC_data_start@Base 1:7.2d
+ (arch=!arm64 !arm64ilp32 !nios2 !kfreebsd-amd64 !kfreebsd-i386 !mips !mips64el !mipsel !s390 !s390x !sparc !sparc64)GC_data_start@Base 1:7.2d
  GC_debug_change_stubborn@Base 1:7.2d
  

Bug#868977: statsmodels is marked for autoremoval from testing

[Yaroslav Halchenko]

On August 16, 2017 8:11:50 PM EDT, Andreas Tille  wrote:
>Hi Yaroslav,
>
>> apparently it is a problem in recent pandas, which isn't yet resolved
>or
>> worked around in statsmodels
>>
>https://github.com/statsmodels/statsmodels/issues/3841#issuecomment-318630239
>> so we might just need to wait a bit more
>
>I've checked the Gitlab issue but I have no idea what to do.  In worst
>case I think we might deactivate the affected test and lower severity
>of
>the bug to important.  My rationale for this means is that there is
>quite
>a set of rdepends which would be removed from testing otherwise.
>
>Kind regards
>
>Andreas.
>
>On Wed, Aug 16, 2017 at 04:39:13AM +, Debian testing autoremoval
>watch wrote:
>> statsmodels 0.8.0~rc1+git59-gef47cd9-5 is marked for autoremoval from
>testing on 2017-09-01
>> 
>> It is affected by these RC bugs:
>> 868977: statsmodels: FTBFS: TypeError: data type not understood
>> 
>> 
>> -- 
>> debian-science-maintainers mailing list
>> debian-science-maintain...@lists.alioth.debian.org
>>
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
>> 

Yeah... That is probably a way to go for now

Bug#867360: tomboy: either drop gmime or switch to mimekit?

[Paul Warren]

Package: tomboy
Version: tomboy
Followup-For: Bug #867360

Just as a note, tomboy is currently uninstallable on testing:

pwarren@hollis:~$ sudo apt-get install tomboy
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 tomboy : Depends: libgmime2.6-cil but it is not installable
E: Unable to correct problems, you have held broken packages.

Cheers
--
Paul Warren



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

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

Versions of packages tomboy depends on:
pn  gconf2  
ii  libatk1.0-0 2.24.0-1
ii  libc6   2.24-12
ii  libcairo2   1.14.10-1
pn  libdbus-glib2.0-cil 
pn  libdbus2.0-cil  
ii  libfontconfig1  2.12.3-0.2
ii  libfreetype62.8-0.2
pn  libgconf2.0-cil 
ii  libgdk-pixbuf2.0-0  2.36.5-2
ii  libglib2.0-02.53.4-3
ii  libglib2.0-cil  2.12.40-2
pn  libgmime2.6-cil 
ii  libgtk2.0-0 2.24.31-2
ii  libgtk2.0-cil   2.12.40-2
ii  libgtkspell02.0.16-1.1
ii  libice6 2:1.0.9-2
pn  libmono-addins-gui0.2-cil   
pn  libmono-addins0.2-cil   
ii  libmono-cairo4.0-cil4.6.2.7+dfsg-1
ii  libmono-corlib4.5-cil   4.6.2.7+dfsg-1
ii  libmono-posix4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-core4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-xml4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system4.0-cil   4.6.2.7+dfsg-1
ii  libpango-1.0-0  1.40.6-1
ii  libpangocairo-1.0-0 1.40.6-1
ii  libpangoft2-1.0-0   1.40.6-1
ii  libproxy1v5 0.4.14-3
ii  libsm6  2:1.2.2-1+b3
ii  libx11-62:1.6.4-3
ii  mono-runtime4.6.2.7+dfsg-1

tomboy recommends no packages.

Versions of packages tomboy suggests:
ii  evolution  3.22.6-1
pn  tasque 

Bug#872391: libapt-pkg-perl: Please provide Uploaders in AptPkg::Source

[Norbert Preining]

Package: libapt-pkg-perl
Version: 0.1.32+b2
Severity: normal

I am writing a tool for generating graph database from the apt cache,
but I am missing access to the uploaders in AptPkg::Source.

Thanks

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

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

Versions of packages libapt-pkg-perl depends on:
ii  libapt-pkg5.0   1.5~beta1
ii  libc6   2.24-14
ii  libgcc1 1:7.1.0-13
ii  libstdc++6  7.1.0-13
ii  perl-base [perlapi-5.26.0]  5.26.0-5

libapt-pkg-perl recommends no packages.

libapt-pkg-perl suggests no packages.

-- no debconf information

Bug#872390: Re enable tests after transition

[Lisandro Damián Nicanor Pérez Meyer]

Source: qtcharts-opensource-src
Version: 5.9.1-3
Severity: important

Re enable test after the transition has passed and try to solve them.

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

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

Bug#856311: avahi-daemon: Won't start due to rlimit nproc, confused by lxc containers

[James Valleroy]

On Mon, 27 Feb 2017 10:35:18 -0500 Matthew Gabeler-Lee
 wrote:
> 
> On one of my systems, avahi-daemon can't start due to its default 
> rlimit-nproc value of 3.

This also affects Debian-CI for packages that depend on avahi-daemon
(such as https://ci.debian.net/packages/f/freedombox-setup/unstable/amd64/).

It looks like the default limit was removed in upstream release v0.7.



signature.asc
Description: OpenPGP digital signature

Bug#872351: git-buildpackage: [pq] Please make the --abbrev= configurable

[Chris Lamb]

Hi Guido,

> Thanks for the update. I've fixed a syntax error in config.py (attached)

Ah, some careless copy-pasting there. (I had added that line elsewhere
but changed it at the last second prior to sending you the patch.)

> but afterwards there are still test suite errors. I'll have look once
> back from vacation.

Yay, thanks!


Regards,

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

Bug#872351: git-buildpackage: [pq] Please make the --abbrev= configurable

[Guido Günther]

Hi,
On Wed, Aug 16, 2017 at 06:28:16PM -0700, Chris Lamb wrote:
> Hi Guido,
> 
> > Thanks! Can you update docs/manpages/gbp-pq{,-rpm}.sgml as well?
> 
> With pleasure. Updated patch attached.

Thanks for the update. I've fixed a syntax error in config.py (attached)
but afterwards there are still test suite errors. I'll have look once
back from vacation.
Cheers,
 -- Guido
>From 75e18fc5bb4831df924bc708130b0a6ab311a230 Mon Sep 17 00:00:00 2001
Message-Id: <75e18fc5bb4831df924bc708130b0a6ab311a230.1502933971.git@sigxcpu.org>
From: Chris Lamb 
Date: Wed, 16 Aug 2017 18:28:16 -0700
Subject: [PATCH] pq: make --abbrev= configurable
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Closes: #872351
Signed-off-by: Guido Günther 
---
 docs/manpages/gbp-pq-rpm.sgml | 13 +
 docs/manpages/gbp-pq.sgml | 13 +
 gbp/config.py |  5 -
 gbp/scripts/common/pq.py  |  8 
 gbp/scripts/pq.py |  4 +++-
 gbp/scripts/pq_rpm.py |  7 ---
 6 files changed, 41 insertions(+), 9 deletions(-)

diff --git a/docs/manpages/gbp-pq-rpm.sgml b/docs/manpages/gbp-pq-rpm.sgml
index 63a8501a..b8535e6f 100644
--- a/docs/manpages/gbp-pq-rpm.sgml
+++ b/docs/manpages/gbp-pq-rpm.sgml
@@ -23,6 +23,7 @@
   --packaging-dir=DIRECTORY
   --spec-file=FILEPATH
   --upstream-tag=TAG-FORMAT
+  --abbrev=num
   --force
   --[no-]patch-numbers
   
@@ -157,6 +158,18 @@
   
 
   
+  
+--abbrev=NUM
+
+
+  
+	  When exporting a patch queue abbreviate commit, instead of showing the
+	  full 40-byte hexadecimal object name in header lines, show only a
+	  partial prefix of length NUM. This is
+	  useful when existing patches were not generated by .
+  
+
+  
   
 --force
 
diff --git a/docs/manpages/gbp-pq.sgml b/docs/manpages/gbp-pq.sgml
index 9b06ca3e..3af503c0 100644
--- a/docs/manpages/gbp-pq.sgml
+++ b/docs/manpages/gbp-pq.sgml
@@ -26,6 +26,7 @@
   --topic=topic
   --time-machine=num
   --[no-]drop
+  --abbrev=num
   --force
   --meta-closes=bug-close-tags
   --meta-closes-bugnum=bug-number-format
@@ -200,6 +201,18 @@
   a successful export
 
   
+  
+--abbrev=NUM
+
+
+  
+	  When exporting a patch queue abbreviate commit, instead of showing the
+	  full 40-byte hexadecimal object name in header lines, show only a
+	  partial prefix of length NUM. This is
+	  useful when existing patches were not generated by .
+  
+
+  
   
 --force
 
diff --git a/gbp/config.py b/gbp/config.py
index 80506090..ee44e3ff 100644
--- a/gbp/config.py
+++ b/gbp/config.py
@@ -101,7 +101,8 @@ class GbpOptionParser(OptionParser):
 @cvar def_config_files: config files we parse
 @type def_config_files: dict (type, path)
 """
-defaults = {'allow-unauthenticated': 'False',
+defaults = {'abbrev': 7,
+'allow-unauthenticated': 'False',
 'arch': '',
 'author-date-is-committer-date': 'False',
 'author-is-committer': 'False',
@@ -343,6 +344,8 @@ class GbpOptionParser(OptionParser):
 'drop':
 "In case of 'export' drop the patch-queue branch "
 "after export. Default is '%(drop)s'",
+'abbrev':
+"abbreviate commits to this length. default is '%(abbrev)s'",
 'commit':
 "commit changes after export, Default is '%(commit)s'",
 'rollback':
diff --git a/gbp/scripts/common/pq.py b/gbp/scripts/common/pq.py
index e9502ea3..cf98a6cb 100644
--- a/gbp/scripts/common/pq.py
+++ b/gbp/scripts/common/pq.py
@@ -185,7 +185,7 @@ def write_patch_file(filename, commit_info, diff):
 DEFAULT_PATCH_NUM_PREFIX_FORMAT = "%04d-"
 
 
-def format_patch(outdir, repo, commit_info, series, numbered=True,
+def format_patch(outdir, repo, commit_info, series, abbrev, numbered=True,
  path_exclude_regex=None, topic='', name=None, renumber=False,
  patch_num_prefix_format=DEFAULT_PATCH_NUM_PREFIX_FORMAT):
 """Create patch of a single commit"""
@@ -235,14 +235,14 @@ def format_patch(outdir, repo, commit_info, series, numbered=True,
 patch = None
 if paths:
 diff = repo.diff('%s^!' % commit_info['id'], paths=paths, stat=80,
- summary=True, text=True, abbrev=7, renames=False)
+ summary=True, text=True, abbrev=abbrev, renames=False)
 patch = write_patch_file(filepath, commit_info, diff)
 if patch:
 series.append(patch)
 return patch
 
 
-def format_diff(outdir, filename, repo, start, end, path_exclude_regex=None):
+def format_diff(outdir, filename, repo, start, end, abbrev, path_exclude_regex=None):
 """Create a patch of diff between two 

Bug#872351: git-buildpackage: [pq] Please make the --abbrev= configurable

[Chris Lamb]

Hi Guido,

> Thanks! Can you update docs/manpages/gbp-pq{,-rpm}.sgml as well?

With pleasure. Updated patch attached.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/docs/manpages/gbp-pq-rpm.sgml b/docs/manpages/gbp-pq-rpm.sgml
index 63a8501..c564a3c 100644
--- a/docs/manpages/gbp-pq-rpm.sgml
+++ b/docs/manpages/gbp-pq-rpm.sgml
@@ -23,6 +23,7 @@
   
--packaging-dir=DIRECTORY
   
--spec-file=FILEPATH
   
--upstream-tag=TAG-FORMAT
+  --abbrev=num
   --force
   --[no-]patch-numbers
   
@@ -157,6 +158,18 @@
   
 
   
+  
+--abbrev=NUM
+
+
+  
+ When exporting a patch queue abbreviate commit, nstead of showing the
+ full 40-byte hexadecimal object name in header lines, show only a
+ partial prefix of length NUM. This is
+ useful when existing patches were not generated by .
+  
+
+  
   
 --force
 
diff --git a/docs/manpages/gbp-pq.sgml b/docs/manpages/gbp-pq.sgml
index 9b06ca3..529887a 100644
--- a/docs/manpages/gbp-pq.sgml
+++ b/docs/manpages/gbp-pq.sgml
@@ -26,6 +26,7 @@
   --topic=topic
   --time-machine=num
   --[no-]drop
+  --abbrev=num
   --force
   --meta-closes=bug-close-tags
   --meta-closes-bugnum=bug-number-format
@@ -200,6 +201,18 @@
   a successful export
 
   
+  
+--abbrev=NUM
+
+
+  
+ When exporting a patch queue abbreviate commit, nstead of showing the
+ full 40-byte hexadecimal object name in header lines, show only a
+ partial prefix of length NUM. This is
+ useful when existing patches were not generated by .
+  
+
+  
   
 --force
 
diff --git a/gbp/config.py b/gbp/config.py
index 3c484cd..aba0dcb 100644
--- a/gbp/config.py
+++ b/gbp/config.py
@@ -101,7 +101,8 @@ class GbpOptionParser(OptionParser):
 @cvar def_config_files: config files we parse
 @type def_config_files: dict (type, path)
 """
-defaults = {'allow-unauthenticated': 'False',
+defaults = {'abbrev': 7
+'allow-unauthenticated': 'False',
 'arch': '',
 'author-date-is-committer-date': 'False',
 'author-is-committer': 'False',
@@ -343,6 +344,8 @@ class GbpOptionParser(OptionParser):
 'drop':
 "In case of 'export' drop the patch-queue branch "
 "after export. Default is '%(drop)s'",
+'abbrev':
+"abbreviate commits to this length. default is '%(abbrev)s'",
 'commit':
 "commit changes after export, Default is '%(commit)s'",
 'rollback':
diff --git a/gbp/scripts/common/pq.py b/gbp/scripts/common/pq.py
index e9502ea..cf98a6c 100644
--- a/gbp/scripts/common/pq.py
+++ b/gbp/scripts/common/pq.py
@@ -185,7 +185,7 @@ def write_patch_file(filename, commit_info, diff):
 DEFAULT_PATCH_NUM_PREFIX_FORMAT = "%04d-"
 
 
-def format_patch(outdir, repo, commit_info, series, numbered=True,
+def format_patch(outdir, repo, commit_info, series, abbrev, numbered=True,
  path_exclude_regex=None, topic='', name=None, renumber=False,
  patch_num_prefix_format=DEFAULT_PATCH_NUM_PREFIX_FORMAT):
 """Create patch of a single commit"""
@@ -235,14 +235,14 @@ def format_patch(outdir, repo, commit_info, series, 
numbered=True,
 patch = None
 if paths:
 diff = repo.diff('%s^!' % commit_info['id'], paths=paths, stat=80,
- summary=True, text=True, abbrev=7, renames=False)
+ summary=True, text=True, abbrev=abbrev, renames=False)
 patch = write_patch_file(filepath, commit_info, diff)
 if patch:
 series.append(patch)
 return patch
 
 
-def format_diff(outdir, filename, repo, start, end, path_exclude_regex=None):
+def format_diff(outdir, filename, repo, start, end, abbrev, 
path_exclude_regex=None):
 """Create a patch of diff between two repository objects"""
 
 info = {'author': repo.get_author_info()}
@@ -260,7 +260,7 @@ def format_diff(outdir, filename, repo, start, end, 
path_exclude_regex=None):
 paths = patch_path_filter(file_status, path_exclude_regex)
 if paths:
 diff = repo.diff(start, end, paths=paths, stat=80, summary=True,
- text=True, abbrev=7, renames=False)
+ text=True, abbrev=abbrev, renames=False)
 return write_patch_file(filename, info, diff)
 return None
 
diff --git a/gbp/scripts/pq.py b/gbp/scripts/pq.py
index 66a8d0d..8f7adb0 100755
--- a/gbp/scripts/pq.py
+++ b/gbp/scripts/pq.py
@@ -98,7 +98,8 @@ def generate_patches(repo, start, end, outdir, options):
 if 'topic' in cmds:
 topic = cmds['topic']
 name = cmds.get('name', None)
-

Bug#871806: uscan: (dpkg, git-buildpackage) accept/mangle/store signed git tags in cases where upstream does not publish detached sigs on tarballs

[Daniel Kahn Gillmor]

Hi Guillem--

On Thu 2017-08-17 01:05:46 +0200, Guillem Jover wrote:
> It seems to me like you are perhaps trying to reimplement dpkg source
> format «3.0 (git)» (described in man dpkg-source)? :)

Thanks for that pointer, it does seem similar.

I was hoping that we could produce an actual orig.tar.gz (so that the
rest of the tools could use it as they have traditionally) and then some
extra thing outside of the orig.tar.gz that, combined with the tarball,
could be used to recreate the .git/ repository well enough to be able to
(a) recreate the tarball, and (b) cryptographically verify the tag.

this would solve my use case (being able to record and ship upstream's
cryptographic signatures, when upstream "releases" with signed tags)
without requiring the rest of the debian infrastructure to cope with git
bundles as "orig.tar.gz-equivalent" blobs.

But if there's a plan for "3.0 (git)" to become acceptable in debian,
then it does seem like that might be the simplest way to move forward.

i'll play around with git-bundle to try to understand it better.  from a
scan of dpkg-source(1) and the various git manpages that i'm used to
reading, i don't understand what .gitshallow or .git/shallow are
supposed to do.  Does it get shipped alongside the .git?  does
.git/shallow have meaning for other tools that i should be aware of?

 --dkg

Bug#868977: statsmodels is marked for autoremoval from testing

[Andreas Tille]

Hi Yaroslav,

> apparently it is a problem in recent pandas, which isn't yet resolved or
> worked around in statsmodels
> https://github.com/statsmodels/statsmodels/issues/3841#issuecomment-318630239
> so we might just need to wait a bit more

I've checked the Gitlab issue but I have no idea what to do.  In worst
case I think we might deactivate the affected test and lower severity of
the bug to important.  My rationale for this means is that there is quite
a set of rdepends which would be removed from testing otherwise.

Kind regards

Andreas.

On Wed, Aug 16, 2017 at 04:39:13AM +, Debian testing autoremoval watch 
wrote:
> statsmodels 0.8.0~rc1+git59-gef47cd9-5 is marked for autoremoval from testing 
> on 2017-09-01
> 
> It is affected by these RC bugs:
> 868977: statsmodels: FTBFS: TypeError: data type not understood
> 
> 
> -- 
> debian-science-maintainers mailing list
> debian-science-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
> 

-- 
http://fam-tille.de

Bug#872181: debootstrap: error processing argument #4

[Douglas Guptill]

Hello Kibi:

On Thu, Aug 17, 2017 at 01:37:44AM +0200, Cyril Brulebois wrote:

> Control: tag -1 moreinfo
..
> I'm not sure what you're suggesting. 1.0.91 has SCRIPT="$4" AFAICT.
> Ditto for 1.0.67+deb8u1.

Agreed.

Perhaps the 'diff' arguments were in an unusual order?

My suggestion is to change the one line:

  SCRIPT="$4"

to this:

  SCRIPT="$DEBOOTSTRAP_DIR/scripts/$4"

> Also, you want to sending unified diffs.
> Please clarify what you meant.

Sorry about the absence of -u.  I had been checking the more recent
source code, and opted to send a minimal amount of 'diff' output.

Here is a diff from my system - devuan-jessie.

The diff is between the distributed 'debootstrap' and my editted
'debootstrap'.  (The paste below is much butchered by my attempts to
undo the effect of the electric indents of emacs, which I tried, and
failed, to turn off.)

Please let me know if there is anything lacking, and thank you for
looking at the bug report.

Regards,
Douglas.

= (start) diff output =

dguptill@blackscram:/usr/sbin$ diff -u debootstrap.dist debootstrap
--- debootstrap.dist   2017-01-13 02:03:13.0 -0400
+++ debootstrap2017-08-14 16:41:53.159463091 -0300
@@ -1,7 +1,9 @@
 #!/bin/sh
 set -e
 
-VERSION='1.0.86+devuan1.0'
+# VERSION='1.0.86+devuan1.0'
+# changing SCRIPT; Douglas Guptill
+VERSION='1.0.86+devuan1.1'
 
 unset TMP TEMP TMPDIR || true
 
@@ -408,13 +410,16 @@
fi
fi
 
-   SCRIPT="$DEBOOTSTRAP_DIR/scripts/$1"
+   # SCRIPT="$DEBOOTSTRAP_DIR/scripts/$1"
+   # equivalent, but possibly better esthetically, is:
+   SCRIPT="$DEBOOTSTRAP_DIR/scripts/${SUITE}"
if [ -n "$VARIANT" ] && [ -e "${SCRIPT}.${VARIANT}" ]; then
   SCRIPT="${SCRIPT}.${VARIANT}"
   SUPPORTED_VARIANTS="$VARIANT"
fi
if [ "$4" != "" ]; then
-   SCRIPT="$4"
+   # SCRIPT="$4"
+   SCRIPT="$DEBOOTSTRAP_DIR/scripts/$4"
fi
 fi
 
= (end) diff output =

Bug#872388: rss2email: cannot change send-to e-mail address for all existing feeds?

[clayton]

Package: rss2email
Version: 1:3.9-2.1
Severity: wishlist

The only way I can see currently to change the e-mail address that existing
r2e feeds are sent to, is to delete each feed and recreate it individually.
Obviously, this scales horribly.

There should be an option to reset all existing feeds to a new e-mail address.

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

Kernel: Linux 4.11.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_HK:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rss2email depends on:
ii  python-xdg  0.25-4
ii  python2.7   2.7.13-2
ii  python3 3.5.3-3
ii  python3-feedparser  5.1.3-3
ii  python3-html2text   2016.9.19-1

Versions of packages rss2email recommends:
ii  python3-bs4  4.6.0-1

Versions of packages rss2email suggests:
pn  esmtp  

-- no debconf information

Bug#872387: RM: pmx -- ROM; transitional package already in stable

[Norbert Preining]

Package: ftp.debian.org
Severity: normal

pmx has been taken over into texlive packages and is a transitional package 
already in stable,
please remove now.

Thanks

Norbert

Bug#844431: Revised patch: seeking seconds

[Chris Lamb]

Hi Bill,

> Now compare with reproducible build. You get some error report you
> cannot reproduce, do some change following the help provided and
> hope for the best. Then some day later you get the same error
> report.

I'd dearly love to know when/where this occurred if you can provide a
reference.

This is not our, and certainly not my own, intention when filing
reproducibility-related bugs, which always include a well-intentioned
patch.


Best wishes,

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

Bug#872386: RM: tex4ht -- ROM; transitional package already in stable

[Norbert Preining]

Package: ftp.debian.org
Severity: normal


tex4ht is a transitional package to the texlive packages providing tex4ht.
Since it is already in stable, please remove it now.

Thanks

Norbert

Bug#872384: RM: jadetex -- ROM; transitional package that is in stable and not needed anymore

[Norbert Preining]

Package: ftp.debian.org
Severity: normal

jadetex has been taken over into the texlive packages, and is a purely 
transitional
package in stable.

Please remove now.

Thanks.

Norbert

Bug#872385: RM: m-tx -- ROM; transitional package already in stable

[Norbert Preining]

Package: ftp.debian.org
Severity: normal

m-tx has been taken over into the texlive packages, and is a purely transitional
package in stable.

Please remove now.

Thanks.

Norbert

Bug#872382: RM: xmltex -- ROM; transitional package in stable

[Norbert Preining]

Package: ftp.debian.org
Severity: normal


xmltex has been incorporated into texlive packages and is a transitional
package in stable. Please remove it now.

Thanks

Norbert

Bug#872383: RM: musixtex -- ROM; transitional package already in stable, included in texlive

[Norbert Preining]

Package: ftp.debian.org
Severity: normal

musixtex has been taken over into the texlive packages, and is a purely 
transitional
package in stable.

Please remove now.

Thanks.

Bug#872181: debootstrap: error processing argument #4

[Cyril Brulebois]

Control: tag -1 moreinfo

Hi Douglas,

Douglas Guptill  (2017-08-14):
> Package: debootstrap
> Version: 1.0.67+deb8u1
> Severity: normal
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>  running rootstrap to create a devuan filesystem.
> 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>  ran rootstrap.  It failed; with an error message from these lines
> 
> if [ ! -e "$SCRIPT" ]; then
> error 1 NOSCRIPT "No such script: %s" "$SCRIPT"
> fi
> 
> 
>* What was the outcome of this action?
> 
>rootstrap failed.
> 
>* What outcome did you expect instead?
> 
>rootstrap to succeed.
> 
> suggested patch from:
>   diff downloads/debootstrap-1.0.91/debootstrap /usr/sbin/debootstrap :
> 416c395
> < SCRIPT="$DEBOOTSTRAP_DIR/scripts/$4"
> ---
> > SCRIPT="$4"

I'm not sure what you're suggesting. 1.0.91 has SCRIPT="$4" AFAICT.
Ditto for 1.0.67+deb8u1. Also, you want to sending unified diffs.

Please clarify what you meant.


KiBi.


signature.asc
Description: Digital signature

Bug#872380: ITP: pocket-home -- a simple menu for mobile devices

[Stephen Paul Weber]

Package: wnpp
Severity: wishlist

After discussions at Debconf17, it was suggested that I should package for 
Debian the pocket-home program that forms the lightweight home menu of the 
pocketCHIP device.  It is GPL3+ and the most maintained upstream is 
.


This package is already useful on the pocketCHIP (which runs Debian) but 
would be useful on other low-power, low-resolution, touch-friendly devices 
as well.


It is my intention not only to maintain this package, but also to work with 
upstream on improvements as they are discovered to make this program more 
useful on other target devices.


signature.asc
Description: PGP signature

Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Nicolas Boulenguez]

Package: dpkg-dev
Version: 1.18.24
Severity: wishlist
Tags: patch

Hello.

A new implementation of
  /usr/share/dpkg/architecture.mk
  /usr/share/dpkg/buildflags.mk
  /usr/share/dpkg/pkg-info.mk
is attached.  You may use run_tests.sh to check that the behaviour
remains the same in most circumstances, but roughly twice faster.

The current implementation executes a dpkg-* subprocess when a new
Make variable is read, then sets this variable. The new one executes a
subprocess when the first variable is read, but then affects all
variables so that no later execution is ever performed.

This optimization cannot be applied to vendors.mk, but would not help
much for 2 variables anyway.

If you accept the files, please remove
  $(if $(dbg),$(warning subshell))
at the end of the dpkg-*-run line of each file.

Thanks.


dpkg-patches.tar.gz
Description: application/gzip

Bug#872379: chkrootkit hangs when egrepping files in /dev in lxc containers

[Scott Barker]

Package: chkrootkit
Version: 0.50-4+b2
Severity: normal

lxc bind-mounts pts devices over files in /dev when starting a container,
but "find" ignores bind mounts when evaluating file types.

Therefore, a bind-mounted device like this:

  $ ls -l /dev/console
  c--x--x--x 1 root tty 136, 1 Aug 16 15:53 /dev/console

Still shows up when running "find" to look for regular files:

  $ find /dev -type f 
  /dev/console

Because of this behaviour, the chkrootkit command:

  files=`${find} ${ROOTDIR}dev -type f -exec ${egrep} -l "^[0-5] " {} \;`

ends up hanging while trying to egrep /dev/console

This can be avoided by adding an -fstype argument to the find command:

  files=`${find} ${ROOTDIR}dev -type f ! -fstype devpts -exec ${egrep} -l 
"^[0-5] " {} \;`

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

Kernel: Linux 4.9.0-3-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: sysvinit (via /sbin/init)

Versions of packages chkrootkit depends on:
ii  binutils   2.28-5
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u1
ii  net-tools  1.60+git20161116.90da8a0-1
ii  openssh-client 1:7.4p1-10+deb9u1
ii  procps 2:3.3.12-3

chkrootkit recommends no packages.

chkrootkit suggests no packages.

Bug#868905: condor: FTBFS: ld: final link failed: Bad value

[peter green]

On 15/08/17 11:03, peter green wrote:

FYI I tried to build the ubuntu version of the package under raspbian buster 
and got.

[ 98%] Building CXX object 
src/cream_gahp/CMakeFiles/cream_gahp.dir/cream_gahp_server.cpp.o
cd "/condor-8.4.11~dfsg.1/obj-arm-linux-gnueabihf/src/cream_gahp" && /usr/bin/c++  -DARMV7L=ARMV7L -DBUILD_DATE="\"Aug 12 2017\"" -DCONDOR_VERSION=\"8.4.11\" -DGLIBC224=GLIBC224 -DGLIBC=GLIBC -DHAVE_CONFIG_H -DLINUX=\"LINUX_3.8.13.30\" -DPLATFORM=\"ARMV7L-Raspbian_\" -DPRE_RELEASE_STR="\" Debian-8.4.11~dfsg.1-1ubuntu1\"" -DWITH_OPENSSL -D_REENTRANT -I"/condor-8.4.11~dfsg.1/obj-arm-linux-gnueabihf/bld_external/classads-8.4.11/install/include" -I/usr/include/globus -I/usr/lib64/globus/include -I/usr/lib/globus/include -I/usr/include/arm-linux-gnueabihf/globus -I/usr/local/globus/include/globus -I"/condor-8.4.11~dfsg.1/src/condor_includes" -I"/condor-8.4.11~dfsg.1/obj-arm-linux-gnueabihf/src/condor_includes" -I"/condor-8.4.11~dfsg.1/src/condor_utils" -I"/condor-8.4.11~dfsg.1/obj-arm-linux-gnueabihf/src/condor_utils" -I"/condor-8.4.11~dfsg.1/src/condor_daemon_core.V6" -I"/condor-8.4.11~dfsg.1/src/condor_daemon_client" -I"/condor-8.4.11~dfsg.1/src/ccb" 
-I"/condor-8.4.11~dfsg.1/src/condor_io" -I"/condor-8.4.11~dfsg.1/src/h" -I"/condor-8.4.11~dfsg.1/obj-arm-linux-gnueabihf/src/h" -I"/condor-8.4.11~dfsg.1/obj-arm-linux-gnueabihf/src/classad" -I"/condor-8.4.11~dfsg.1/src/classad" -I"/condor-8.4.11~dfsg.1/src/safefile" -I"/condor-8.4.11~dfsg.1/obj-arm-linux-gnueabihf/src/safefile"  -g -O2 -fdebug-prefix-map=/condor-8.4.11~dfsg.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -DWITH_IPV6 -g -O2 -fdebug-prefix-map=/condor-8.4.11~dfsg.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Wall -W -Wextra -Wfloat-equal -Wendif-labels -Wpointer-arith -Wcast-qual -Wcast-align -Wvolatile-register-var -Wno-error=unused-local-typedefs -Wdeprecated-declarations -Wno-error=deprecated-declarations -Wno-nonnull-compare -Wno-error=nonnull-compare -fstack-protector -rdynamic -g -Wno-shadow -o CMakeFiles/cream_gahp.dir/cream_gahp_server.cpp.o 
-c "/condor-8.4.11~dfsg.1/src/cream_gahp/cream_gahp_server.cpp"

/condor-8.4.11~dfsg.1/src/cream_gahp/cream_gahp_server.cpp:36:59: fatal error: 
glite/ce/cream-client-api-c/CreamProxyFactory.h: No such file or directory
 #include "glite/ce/cream-client-api-c/CreamProxyFactory.h"

I have not yet fully investigated this failure.


Ok, it seems that if liblog4cpp5-dev is installed in the build chroot the package tries 
and fails to build the "cream" stuff. if liblog4cpp5-dev is not installed then 
it doesn't try to build it and the package build succeeds..

For raspbian I added a build-conflicts accordingly. A debdiff should pop up 
soon under http://debdiffs.raspbian.org/main/c/condor/

Bug#872351: git-buildpackage: [pq] Please make the --abbrev= configurable

[Guido Günther]

Hi,
On Wed, Aug 16, 2017 at 09:31:35AM -0700, Chris Lamb wrote:
> tags 872351 + patch
> thanks
> 
> Patch attached.

Thanks! Can you update docs/manpages/gbp-pq{,-rpm}.sgml as well?
Cheers,
 -- Guido

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

> diff --git a/gbp/config.py b/gbp/config.py
> index 3c484cd..aba0dcb 100644
> --- a/gbp/config.py
> +++ b/gbp/config.py
> @@ -101,7 +101,8 @@ class GbpOptionParser(OptionParser):
>  @cvar def_config_files: config files we parse
>  @type def_config_files: dict (type, path)
>  """
> -defaults = {'allow-unauthenticated': 'False',
> +defaults = {'abbrev': 7
> +'allow-unauthenticated': 'False',
>  'arch': '',
>  'author-date-is-committer-date': 'False',
>  'author-is-committer': 'False',
> @@ -343,6 +344,8 @@ class GbpOptionParser(OptionParser):
>  'drop':
>  "In case of 'export' drop the patch-queue branch "
>  "after export. Default is '%(drop)s'",
> +'abbrev':
> +"abbreviate commits to this length. default is '%(abbrev)s'",
>  'commit':
>  "commit changes after export, Default is '%(commit)s'",
>  'rollback':
> diff --git a/gbp/scripts/common/pq.py b/gbp/scripts/common/pq.py
> index e9502ea..cf98a6c 100644
> --- a/gbp/scripts/common/pq.py
> +++ b/gbp/scripts/common/pq.py
> @@ -185,7 +185,7 @@ def write_patch_file(filename, commit_info, diff):
>  DEFAULT_PATCH_NUM_PREFIX_FORMAT = "%04d-"
>  
>  
> -def format_patch(outdir, repo, commit_info, series, numbered=True,
> +def format_patch(outdir, repo, commit_info, series, abbrev, numbered=True,
>   path_exclude_regex=None, topic='', name=None, 
> renumber=False,
>   patch_num_prefix_format=DEFAULT_PATCH_NUM_PREFIX_FORMAT):
>  """Create patch of a single commit"""
> @@ -235,14 +235,14 @@ def format_patch(outdir, repo, commit_info, series, 
> numbered=True,
>  patch = None
>  if paths:
>  diff = repo.diff('%s^!' % commit_info['id'], paths=paths, stat=80,
> - summary=True, text=True, abbrev=7, renames=False)
> + summary=True, text=True, abbrev=abbrev, 
> renames=False)
>  patch = write_patch_file(filepath, commit_info, diff)
>  if patch:
>  series.append(patch)
>  return patch
>  
>  
> -def format_diff(outdir, filename, repo, start, end, path_exclude_regex=None):
> +def format_diff(outdir, filename, repo, start, end, abbrev, 
> path_exclude_regex=None):
>  """Create a patch of diff between two repository objects"""
>  
>  info = {'author': repo.get_author_info()}
> @@ -260,7 +260,7 @@ def format_diff(outdir, filename, repo, start, end, 
> path_exclude_regex=None):
>  paths = patch_path_filter(file_status, path_exclude_regex)
>  if paths:
>  diff = repo.diff(start, end, paths=paths, stat=80, summary=True,
> - text=True, abbrev=7, renames=False)
> + text=True, abbrev=abbrev, renames=False)
>  return write_patch_file(filename, info, diff)
>  return None
>  
> diff --git a/gbp/scripts/pq.py b/gbp/scripts/pq.py
> index 66a8d0d..8f7adb0 100755
> --- a/gbp/scripts/pq.py
> +++ b/gbp/scripts/pq.py
> @@ -98,7 +98,8 @@ def generate_patches(repo, start, end, outdir, options):
>  if 'topic' in cmds:
>  topic = cmds['topic']
>  name = cmds.get('name', None)
> -format_patch(outdir, repo, info, patches, options.patch_numbers,
> +format_patch(outdir, repo, info, patches, options.abbrev,
> + numbered=options.patch_numbers,
>   topic=topic, name=name,
>   renumber=options.renumber,
>   patch_num_prefix_format=options.patch_num_format)
> @@ -396,6 +397,7 @@ def build_parser(name):
>  parser.add_config_file_option(option_name="time-machine", 
> dest="time_machine", type="int")
>  parser.add_boolean_config_file_option("drop", dest='drop')
>  parser.add_boolean_config_file_option(option_name="commit", 
> dest="commit")
> +parser.add_config_file_option(option_name="abbrev", dest="abbrev", 
> type="int")
>  parser.add_option("--force", dest="force", action="store_true", 
> default=False,
>help="in case of import even import if the branch 
> already exists")
>  parser.add_config_file_option(option_name="color", dest="color", 
> type='tristate')
> diff --git a/gbp/scripts/pq_rpm.py b/gbp/scripts/pq_rpm.py
> index ebce7ff..9b7fb6a 100755
> --- a/gbp/scripts/pq_rpm.py
> +++ b/gbp/scripts/pq_rpm.py
> @@ -86,9 +86,9 @@ def generate_patches(repo, start, end, outdir, options):
>  merges = repo.get_commits(start, end_commit, options=['--merges'])
>  if merges:
>  # 

Bug#871806: uscan: (dpkg, git-buildpackage) accept/mangle/store signed git tags in cases where upstream does not publish detached sigs on tarballs

[Guillem Jover]

Hi!

On Fri, 2017-08-11 at 14:15:28 -0400, Daniel Kahn Gillmor wrote:
> Package: devscripts
> Priority: wishlist
> Control: affects -1 + dpkg git-buildpackage pristine-tar
> X-Debbugs-Cc: d...@packages.debian.org, git-buildpack...@packages.debian.org, 
> pristine-...@packages.debian.org

> I'm not sure exactly how to do this, but what i'd like to see is a way
> for us to record and make use of signed git tags in the same way.
> 
> I'm opening this bug report in the hopes of starting discussion about
> how to best do it.

> Here's an extremely rough and inefficient approach (which i haven't
> implemented, as this is in brainstorming phase).  I've probably even got
> some of the terminology wrong, or the dataflows backward:
> 
>  * we document how we generate a debian "upstream tarball" from a git
>tag.  for example, we put this in debian/upstream/vcs-gen-tarball:
> 
> git archive --format=tar --prefix=${projname}-${version} ${tagname} | 
> gzip -9n
> 
>  * make a shallow clone of the git archive at the tag, including the
>tag. (i've confirmed that a signed git tag in a shallow repo does
>validate correctly).
> 
>  git clone --bare --depth 1 -b ${tagname} \
> file://path/to/upstream/${projname}.git ${projname}-${version}.git
> 
> 
>  * create an archive of the shallow clone, combined with the command to
>generate the tarball (we can call this a "gtsig")
> 
>  rm -rf ${projname}-${version}.git/hooks
>  cp debian/upstream/vcs-gen-tarball ./${projname}-${version}.git
>  tar cz ./${projname}-${version}.git > ./${projname}-${version}.gtsig
> 
>  * write a simple tool to verify an orig.tar.gz against a signing key
>and a gtsig, by extracting the "shallow clone" of the git repository,
>verifying git tag -v, using git-archive, and then comparing the
>results.

It seems to me like you are perhaps trying to reimplement dpkg source
format «3.0 (git)» (described in man dpkg-source)? :)

Thanks,
Guillem

Bug#868929: kfreebsd-10: FTBFS: ../../../compat/ia32/ia32_genassym.c:1:0: error: code model kernel does not support PIC mode

[Steven Chamberlain]

severity 868929 important
thanks

(linux-)amd64 is not in this package's Architectures: field, therefore
FTBFS on that arch cannot be a RC bug?  (Though I'd be interested in
fixing it someday).

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#872378: fenrir.deb: No speech after enabling fenrir to start in concial.

[Matthew Dyer]

Package: fenrir.deb
Version: 1.6-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
I disabled espeakup.service then enabled fenrir.service
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
Fenrir did not speak after rebooting the system.
   * What outcome did you expect instead?
Fenrir should have spoken after logining to my consel2

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


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

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

Bug#872377: cinnamon: Fn+FX settings keys not responding

[machavez]

Package: cinnamon
Version: 3.2.7-4
Severity: normal

Dear Maintainer,

After recent upgrade,  dist-upgrade, I'm unable to change system settings like 
brightness or Volume level by using Fn+FX keys.
I already discard a lower level issue by trying on Gnome and it is working OK, 
so apparently it is related to Cinnamon.


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

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

Versions of packages cinnamon depends on:
ii  caribou  0.4.21-1+b1
ii  cinnamon-common  3.2.7-4
ii  cinnamon-control-center  3.2.1-3
ii  cinnamon-desktop-data3.2.4-4
ii  cinnamon-screensaver 3.2.13-4
ii  cinnamon-session 3.2.0-4
ii  cinnamon-settings-daemon 3.2.1-3
ii  cjs  3.2.0-3
ii  cups-pk-helper   0.2.6-1+b1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gir1.2-accountsservice-1.0   0.6.43-1
ii  gir1.2-caribou-1.0   0.4.21-1+b1
ii  gir1.2-clutter-1.0   1.26.2+dfsg-1
ii  gir1.2-cmenu-3.0 3.2.0-3
ii  gir1.2-cogl-1.0  1.22.2-2
ii  gir1.2-cvc-1.0   3.2.4-4
ii  gir1.2-gdkpixbuf-2.0 2.36.5-2
ii  gir1.2-gkbd-3.0  3.22.0.1-1+b1
ii  gir1.2-glib-2.0  1.50.0-2
ii  gir1.2-gnomedesktop-3.0  3.22.2-1
ii  gir1.2-gtk-3.0   3.22.18-1
ii  gir1.2-gtkclutter-1.01.8.2-2
ii  gir1.2-javascriptcoregtk-3.0 2.4.11-3
ii  gir1.2-keybinder-3.0 0.3.1-1
ii  gir1.2-meta-muffin-0.0   3.2.1-2
ii  gir1.2-networkmanager-1.01.8.2-1
ii  gir1.2-notify-0.70.7.7-2
ii  gir1.2-pango-1.0 1.40.6-1
ii  gir1.2-polkit-1.00.105-18
ii  gir1.2-soup-2.4  2.56.0-2
ii  gir1.2-upowerglib-1.00.99.5-3
ii  gir1.2-xapp-1.0  1.0.2-1
ii  gkbd-capplet 3.22.0.1-1+b1
ii  gnome-backgrounds3.22.1-1
ii  gnome-themes-standard3.22.3-1
ii  gsettings-desktop-schemas3.24.0-2
ii  iso-flags-png-320x2401.0.1-1
ii  libatk-bridge2.0-0   2.24.1-1
ii  libatk1.0-0  2.24.0-1
ii  libc62.24-12
ii  libcairo21.14.10-1
ii  libcinnamon-menu-3-0 3.2.0-3
ii  libcjs0  3.2.0-3
ii  libclutter-1.0-0 1.26.2+dfsg-1
ii  libcogl-pango20  1.22.2-2
ii  libcogl-path20   1.22.2-2
ii  libcogl201.22.2-2
ii  libcroco30.6.12-1
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libgirepository-1.0-11.50.0-2
ii  libgl1-mesa-glx [libgl1] 13.0.6-1+b2
ii  libglib2.0-0 2.53.4-3
ii  libglib2.0-bin   2.53.4-3
ii  libgstreamer1.0-01.12.2-1
ii  libgtk-3-0   3.22.18-1
ii  libjs-jquery 3.1.1-2
ii  libmozjs-24-024.2.0-5.1+b2
ii  libmuffin0   3.2.1-2
ii  libpango-1.0-0   1.40.6-1
ii  libpangocairo-1.0-0  1.40.6-1
ii  libstartup-notification0 0.12-4+b2
ii  libx11-6 2:1.6.4-3
ii  libxfixes3   1:5.0.3-1
ii  libxml2  2.9.4+dfsg1-3
ii  mesa-utils   8.3.0-5
ii  muffin   3.2.1-2
ii  nemo 3.2.2-3
ii  policykit-1-gnome0.105-6
ii  python   2.7.13-2
ii  python-dbus  1.2.4-1+b2
ii  python-gi-cairo  3.22.0-2+b1
ii  python-imaging   4.2.1-1
ii  python-lxml  

Bug#871547: cinnamon: Black background after upgrade. Unable to change it

[machavez]

Package: cinnamon
Version: 3.2.7-4
Followup-For: Bug #871547

Dear Maintainer,

After recent upgrade, dist-upgrade, Desktop backgroud appears on Black. I have 
tried to change it through cinnamon-settings, also by opening an Image with 
Firefox and assigning it as dektop background from there. No luck.


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

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

Versions of packages cinnamon depends on:
ii  caribou  0.4.21-1+b1
ii  cinnamon-common  3.2.7-4
ii  cinnamon-control-center  3.2.1-3
ii  cinnamon-desktop-data3.2.4-4
ii  cinnamon-screensaver 3.2.13-4
ii  cinnamon-session 3.2.0-4
ii  cinnamon-settings-daemon 3.2.1-3
ii  cjs  3.2.0-3
ii  cups-pk-helper   0.2.6-1+b1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gir1.2-accountsservice-1.0   0.6.43-1
ii  gir1.2-caribou-1.0   0.4.21-1+b1
ii  gir1.2-clutter-1.0   1.26.2+dfsg-1
ii  gir1.2-cmenu-3.0 3.2.0-3
ii  gir1.2-cogl-1.0  1.22.2-2
ii  gir1.2-cvc-1.0   3.2.4-4
ii  gir1.2-gdkpixbuf-2.0 2.36.5-2
ii  gir1.2-gkbd-3.0  3.22.0.1-1+b1
ii  gir1.2-glib-2.0  1.50.0-2
ii  gir1.2-gnomedesktop-3.0  3.22.2-1
ii  gir1.2-gtk-3.0   3.22.18-1
ii  gir1.2-gtkclutter-1.01.8.2-2
ii  gir1.2-javascriptcoregtk-3.0 2.4.11-3
ii  gir1.2-keybinder-3.0 0.3.1-1
ii  gir1.2-meta-muffin-0.0   3.2.1-2
ii  gir1.2-networkmanager-1.01.8.2-1
ii  gir1.2-notify-0.70.7.7-2
ii  gir1.2-pango-1.0 1.40.6-1
ii  gir1.2-polkit-1.00.105-18
ii  gir1.2-soup-2.4  2.56.0-2
ii  gir1.2-upowerglib-1.00.99.5-3
ii  gir1.2-xapp-1.0  1.0.2-1
ii  gkbd-capplet 3.22.0.1-1+b1
ii  gnome-backgrounds3.22.1-1
ii  gnome-themes-standard3.22.3-1
ii  gsettings-desktop-schemas3.24.0-2
ii  iso-flags-png-320x2401.0.1-1
ii  libatk-bridge2.0-0   2.24.1-1
ii  libatk1.0-0  2.24.0-1
ii  libc62.24-12
ii  libcairo21.14.10-1
ii  libcinnamon-menu-3-0 3.2.0-3
ii  libcjs0  3.2.0-3
ii  libclutter-1.0-0 1.26.2+dfsg-1
ii  libcogl-pango20  1.22.2-2
ii  libcogl-path20   1.22.2-2
ii  libcogl201.22.2-2
ii  libcroco30.6.12-1
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libgirepository-1.0-11.50.0-2
ii  libgl1-mesa-glx [libgl1] 13.0.6-1+b2
ii  libglib2.0-0 2.53.4-3
ii  libglib2.0-bin   2.53.4-3
ii  libgstreamer1.0-01.12.2-1
ii  libgtk-3-0   3.22.18-1
ii  libjs-jquery 3.1.1-2
ii  libmozjs-24-024.2.0-5.1+b2
ii  libmuffin0   3.2.1-2
ii  libpango-1.0-0   1.40.6-1
ii  libpangocairo-1.0-0  1.40.6-1
ii  libstartup-notification0 0.12-4+b2
ii  libx11-6 2:1.6.4-3
ii  libxfixes3   1:5.0.3-1
ii  libxml2  2.9.4+dfsg1-3
ii  mesa-utils   8.3.0-5
ii  muffin   3.2.1-2
ii  nemo 3.2.2-3
ii  policykit-1-gnome0.105-6
ii  python   2.7.13-2
ii  python-dbus  1.2.4-1+b2
ii  python-gi-cairo  3.22.0-2+b1
ii  python-imaging   4.2.1-1
ii  python-lxml  

Bug#844431: Revised patch: Oppose

[Russ Allbery]

Bill Allombert  writes:
> On Wed, Aug 16, 2017 at 12:14:53PM -0700, Russ Allbery wrote:

>> If you have specific wording suggestions that you believe would bring
>> this Policy requirement closer in line with what we're already doing in
>> the project (and which has gotten us to 94% reproducible already),
>> please make them.

> This percentage was reached mostly by fixing software tools (compiler,
> doc generators, packaging tools) to be deterministic, rather than by
> fixing individual packages. This is a topic that is wholy absent from
> policy.

Indeed.  There are many things that go into making Debian work that are
wholly absent from Policy.  Hopefully, over time, we can slowly reduce
that, but there will always be new initiatives that aren't documented.

> For example policy could mandate that programs that set timestamps
> honour SOURCE_DATE_EPOCH.

Please propose language.  (Ideally in a separate bug, since this one is
already quite large and it's easier to address specific issues in specific
bugs.)

I'm not opposed to adding more advice and requirements that make sense,
but there are lots of things in Policy that aren't as fully described as
they possibly could be if people did more work.  I'm not willing to block
this on having the perfect language, but if you want to contribute, you're
absolutely welcome to do so.

Most packages do not have to care about SOURCE_DATE_EPOCH because it's set
by dpkg-buildpackage and consumed by the tools that are most frequently
relevant, but I'd be very happy to see that documented in Policy for the
packages that do care.

-- 
Russ Allbery (r...@debian.org)   

Bug#872376: Wayland session does not configure Xwayland authorization; cannot run apps as root

[Josh Triplett]

Package: gnome-session
Version: 3.24.1-2
Severity: normal

[Reporting this on gnome-session, but it may belong on another
component; please feel free to reassign.]

The new Wayland-based session runs Xwayland for compatibility with X
applications, but does not configure any authorization that would allow
running those applications as another user, such as root.  No
~/.Xauthority file exists, and $XAUTHORITY is not set.

As a trivial test, try running `sudo xlsclients` under a Wayland-based
GNOME session.

As one of many practical issues this causes, running KVM as root to
allow its `-net user` mode to send raw packets makes it unable to
connect to Xwayland.

Please consider doing one of the following two things:

- Generating an Xauthority file as part of the Wayland GNOME session,
  and setting $XAUTHORITY. This would allow users who can access that
  file (which would include root) to connect to Xwayland.
- Telling Xwayland to allow connections from `si:localuser:root` by
  default. That seems simpler, and doesn't rely on file permissions,
  though it might potentially surprise people who want to run a
  graphical application as another non-root user.

Personally, I'd suggest the second approach, but either would work.

- Josh Triplett

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

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

Versions of packages gnome-session depends on:
ii  gnome-session-bin  3.24.1-2
ii  gnome-session-common   3.24.1-2
ii  gnome-settings-daemon  3.24.3-1
ii  gnome-shell3.22.3-3

gnome-session recommends no packages.

Versions of packages gnome-session suggests:
ii  desktop-base  9.0.5
ii  gnome-keyring 3.20.1-1
ii  gnome-user-guide  3.22.0-1

-- no debconf information

Bug#844431: Revised patch: Oppose

[Bill Allombert]

On Wed, Aug 16, 2017 at 12:19:47PM -0700, Don Armstrong wrote:
> On Wed, 16 Aug 2017, Bill Allombert wrote:
> > But as a technical document, it is lacking practical recommendation
> > for maintainers how to make sure their package build reproducibly
> 
> The practical recommendations for maintainers are encoded separately, as
> they're evolving. See https://wiki.debian.org/ReproducibleBuilds/Howto
> for example.

> > and create confusion on the goal by using the term 'reproducible
> > build' when 'robust build' is meant (which is a worthwile goal by
> > itself, but a different project nevertheless).
> 
> I'm not convinced that this change will reduce confusion, as the
> reproducible build project has been using this language in Debian for
> many years now.

It is apparent that the reproducible build project has broadened their
focus following the progress they made, which is logical.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#872275: slic3r-prusa: Loadable library and perl binary mismatch

[gregor herrmann]

Control: tag -1 + patch

On Wed, 16 Aug 2017 22:29:11 +0300, Niko Tyni wrote:

> As with #869360, the package is missing a dependency on perlapi-*,
> violating the Debian Perl Policy and losing the guards that make sure
> compiled Perl modules are binary compatible with the current Perl version.
> 
> The other bug has some discussion and a suggested fix.

And the same fix works here as well. Patch attached.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Alanis Morissette: Princes Familiar
diff -Nru slic3r-prusa-1.37.0+dfsg/debian/changelog slic3r-prusa-1.37.0+dfsg/debian/changelog
--- slic3r-prusa-1.37.0+dfsg/debian/changelog	2017-08-05 19:04:13.0 +0200
+++ slic3r-prusa-1.37.0+dfsg/debian/changelog	2017-08-16 23:17:06.0 +0200
@@ -1,3 +1,13 @@
+slic3r-prusa (1.37.0+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "Loadable library and perl binary mismatch":
+add override_dh_perl in debian/rules to make dh_perl search for perl
+modules in the private directory as well.
+(Closes: #872275)
+
+ -- gregor herrmann   Wed, 16 Aug 2017 23:17:06 +0200
+
 slic3r-prusa (1.37.0+dfsg-1) unstable; urgency=medium
 
   * [3561f7e] New upstream version 1.37.0+dfsg
diff -Nru slic3r-prusa-1.37.0+dfsg/debian/rules slic3r-prusa-1.37.0+dfsg/debian/rules
--- slic3r-prusa-1.37.0+dfsg/debian/rules	2017-08-05 19:04:13.0 +0200
+++ slic3r-prusa-1.37.0+dfsg/debian/rules	2017-08-16 23:17:06.0 +0200
@@ -45,3 +45,6 @@
 	# Install zsh completion
 	mkdir -p $(CURDIR)/debian/slic3r-prusa/usr/share/zsh/vendor-completions
 	cp utils/zsh/functions/_slic3r $(CURDIR)/debian/slic3r-prusa/usr/share/zsh/vendor-completions/_slic3r-prusa
+
+override_dh_perl:
+	dh_perl /usr/lib/slic3r-prusa


signature.asc
Description: Digital Signature

Bug#844431: Revised patch: Oppose

[Bill Allombert]

On Wed, Aug 16, 2017 at 12:14:53PM -0700, Russ Allbery wrote:
> If you have specific wording suggestions that you believe would bring this
> Policy requirement closer in line with what we're already doing in the
> project (and which has gotten us to 94% reproducible already), please make
> them.

This percentage was reached mostly by fixing software tools (compiler, 
doc generators, packaging tools) to be deterministic, rather than by
fixing individual packages. This is a topic that is wholy absent from
policy.

For example policy could mandate that programs that set timestamps honour
SOURCE_DATE_EPOCH.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#852596: iio-sensor-proxy: spams syslog with an error message every second

[Francois Gouget]

Package: iio-sensor-proxy
Version: 2.2-1
Followup-For: Bug #852596

Dear Maintainer,

I don't know if a fix got backported to the 4.9 Linux kernel, but this
bug is still present on my Acer V5-171 with iio-sensor-proxy 2.2-1 and
Linux kernel 4.11:

# cat /proc/version
Linux version 4.11.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.11.6-1 (2017-06-19)
# tail -n 3 /var/log/syslog
Aug 15 19:16:31 hawai iio-sensor-prox[525]: Could not open input accel 
'/dev/input/event8': Operation not permitted
Aug 15 19:16:32 hawai iio-sensor-prox[525]: Could not open input accel 
'/dev/input/event8': Operation not permitted
Aug 15 19:16:32 hawai iio-sensor-prox[525]: Could not open input accel 
'/dev/input/event8': Operation not permitted


Also the URL for the 'commit in the relevant upstream kernel
maintainer's tree' from message 75 is invalid:

$ wget 
http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/commit/25a7c6f172af2a3187147c0ad4880c0968de3f02
--2017-08-15 19:12:56-- 
http://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git/commit/25a7c6f172af2a3187147c0ad4880c0968de3f02
Resolving git.infradead.org (git.infradead.org)... 65.50.211.133, 
2001:1868:a000:17::133
Connecting to git.infradead.org (git.infradead.org)|65.50.211.133|:80... 
connected.
HTTP request sent, awaiting response... 404 Not Found
2017-08-15 19:13:00 ERROR 404: Not Found.


It looks like th eonly fix is still to uninstall iio-sensor-prox and
hope it does not get pulled back in with an update.

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

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

Versions of packages iio-sensor-proxy depends on:
ii  libc6   2.24-12
ii  libglib2.0-02.52.3-1
ii  libgudev-1.0-0  230-3
ii  systemd 234-2

iio-sensor-proxy recommends no packages.

iio-sensor-proxy suggests no packages.

-- no debconf information

Bug#872375: lirc: irrecord segfaults when recording a button

[Francois Gouget]

Package: lirc
Version: 0.9.4c-9
Severity: important

Dear Maintainer,

When trying to create a configuration file for my remote, irrecord
crashes when it gets to the 'Now hold down button Xxx' step:

# /etc/init.d/lircd stop
[] Stopping lircd (via systemctl): lircd.serviceWarning: Stopping
lircd.service, but it can still be activated by:
lircd.socket
. ok 

# cat /sys/class/rc/rc0/protocols
[rc-5] nec rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd xmp [lirc]

# cat /sys/class/rc/rc0/input14/name 
Media Center Ed. eHome Infrared Remote Transceiver (147a:e03e)

# ll -d /sys/class/rc/rc0/input14/event13
drwxr-xr-x 3 root root 0 août  15 20:07 /sys/class/rc/rc0/input14/event13

# irrecord -H devinput -f -d /dev/input/event13 /tmp/tmp.conf
[...]
Checking for ambient light  creating too much disturbances.
Please don't press any buttons, just wait a few seconds...

No significant noise (received 0 bytes)

Enter name of remote (only ascii, no spaces) :Test
Using Test.lircd.conf as output filename

Hold down an arbitrary key

Found gap (227049 us)

Please enter the name for the next button (press  to finish
recording)
KEY_1

Now hold down button "KEY_1".
Segmentation fault


This was working fine in the Debian Jessie package, lirc 0.9.0~pre1-1.2.


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

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

Versions of packages lirc depends on:
ii  init-system-helpers  1.49
ii  libasound2   1.1.3-5
ii  libc62.24-12
ii  libftdi1-2   1.3-2+b3
ii  libgcc1  1:7.1.0-10
ii  liblirc-client0  0.9.4c-9
ii  liblirc0 0.9.4c-9
ii  libportaudio219.6.0-1
ii  libstdc++6   7.1.0-10
ii  libsystemd0  234-2
ii  libudev1 234-2
ii  libusb-0.1-4 2:0.1.12-31
ii  libusb-1.0-0 2:1.0.21-2
ii  lsb-base 9.20161125
ii  python3  3.5.3-3

Versions of packages lirc recommends:
pn  gir1.2-vte
ii  python3-gi3.22.0-2+b1
ii  python3-yaml  3.12-1+b1

Versions of packages lirc suggests:
pn  ir-keytable  
pn  lirc-compat-remotes  
pn  lirc-doc 
pn  lirc-drv-irman   
pn  lirc-x   
pn  setserial

-- Configuration Files:
/etc/lirc/lircd.conf.d/devinput.lircd.conf [Errno 2] Aucun fichier ou dossier 
de ce type: '/etc/lirc/lircd.conf.d/devinput.lircd.conf'

-- no debconf information

Bug#810546: openssh-client: hostkey verification fails checking/matching HostKeyAlgorithm; misreports offending HostKey

[Felix Dreissig]

I can confirm this for openssh-client 1:7.4p1-10+deb9u1 on Stretch.
It also affects OpenSSH 7.4p1 on macOS, so I guess it really is an upstream
issue.

Furthermore, the ssh_config manpage says about `HostKeyAlgorithms`:

>[...],
>ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,
>ssh-ed25519,ssh-rsa
> 
> If hostkeys are known for the destination host then this default is
> modified to prefer their algorithms.

Reading this strictly, I assume "this default" only refers to the default value
stated before and the sentence does not apply with custom `HostKeyAlgorithms`.
There appears to be no option to also get the described behavior in that case.

Best regards,
Felix

Bug#871460: Gnome Settings 3.24 breaks Cinnamon power, fn keys, themes, fonts, backgrounds...

[Antonio Niño Díaz]

Package: cinnamon
Version: 3.2.7-4
Followup-For: Bug #871460

Same problem in my computer.



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

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

Versions of packages cinnamon depends on:
ii  caribou  0.4.21-1+b1
ii  cinnamon-common  3.2.7-4
ii  cinnamon-control-center  3.2.1-3
ii  cinnamon-desktop-data3.2.4-4
ii  cinnamon-screensaver 3.2.13-4
ii  cinnamon-session 3.2.0-4
ii  cinnamon-settings-daemon 3.2.1-3
ii  cjs  3.2.0-3
ii  cups-pk-helper   0.2.6-1+b1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  gir1.2-accountsservice-1.0   0.6.43-1
ii  gir1.2-caribou-1.0   0.4.21-1+b1
ii  gir1.2-clutter-1.0   1.26.2+dfsg-1
ii  gir1.2-cmenu-3.0 3.2.0-3
ii  gir1.2-cogl-1.0  1.22.2-2
ii  gir1.2-cvc-1.0   3.2.4-4
ii  gir1.2-gdkpixbuf-2.0 2.36.5-2
ii  gir1.2-gkbd-3.0  3.22.0.1-1+b1
ii  gir1.2-glib-2.0  1.50.0-2
ii  gir1.2-gnomedesktop-3.0  3.22.2-1
ii  gir1.2-gtk-3.0   3.22.18-1
ii  gir1.2-gtkclutter-1.01.8.2-2
ii  gir1.2-javascriptcoregtk-3.0 2.4.11-3
ii  gir1.2-keybinder-3.0 0.3.1-1
ii  gir1.2-meta-muffin-0.0   3.2.1-2
ii  gir1.2-networkmanager-1.01.8.2-1
ii  gir1.2-notify-0.70.7.7-2
ii  gir1.2-pango-1.0 1.40.6-1
ii  gir1.2-polkit-1.00.105-18
ii  gir1.2-soup-2.4  2.56.0-2
ii  gir1.2-upowerglib-1.00.99.5-3
ii  gir1.2-xapp-1.0  1.0.2-1
ii  gkbd-capplet 3.22.0.1-1+b1
ii  gnome-backgrounds3.22.1-1
ii  gnome-themes-standard3.22.3-1
ii  gsettings-desktop-schemas3.24.0-2
ii  iso-flags-png-320x2401.0.1-1
ii  libatk-bridge2.0-0   2.24.1-1
ii  libatk1.0-0  2.24.0-1
ii  libc62.24-12
ii  libcairo21.14.10-1
ii  libcinnamon-menu-3-0 3.2.0-3
ii  libcjs0  3.2.0-3
ii  libclutter-1.0-0 1.26.2+dfsg-1
ii  libcogl-pango20  1.22.2-2
ii  libcogl-path20   1.22.2-2
ii  libcogl201.22.2-2
ii  libcroco30.6.12-1
ii  libgdk-pixbuf2.0-0   2.36.5-2
ii  libgirepository-1.0-11.50.0-2
ii  libgl1-mesa-glx [libgl1] 13.0.6-1+b2
ii  libglib2.0-0 2.53.4-3
ii  libglib2.0-bin   2.53.4-3
ii  libgstreamer1.0-01.12.2-1
ii  libgtk-3-0   3.22.18-1
ii  libjs-jquery 3.1.1-2
ii  libmozjs-24-024.2.0-5.1+b2
ii  libmuffin0   3.2.1-2
ii  libpango-1.0-0   1.40.6-1
ii  libpangocairo-1.0-0  1.40.6-1
ii  libstartup-notification0 0.12-4+b2
ii  libx11-6 2:1.6.4-3
ii  libxfixes3   1:5.0.3-1
ii  libxml2  2.9.4+dfsg1-3
ii  mesa-utils   8.3.0-5
ii  muffin   3.2.1-2
ii  nemo 3.2.2-3
ii  policykit-1-gnome0.105-6
ii  python   2.7.13-2
ii  python-dbus  1.2.4-1+b2
ii  python-gi-cairo  3.22.0-2+b1
ii  python-imaging   4.2.1-1
ii  python-lxml  3.8.0-1+b1
ii  python-pam   0.4.2-13.2
ii  python-pexpect   4.2.1-1
ii  python-pyinotify 0.9.6-1
ii  python3   

Bug#871041: edb: New upstream version = 1.33 [please consider elpafying]

[Nicholas D Steeves]

Control: retitle -1 edb: New upstream version = 1.33 [please consider elpafying]
Control: noowner -1

On Sun, Aug 06, 2017 at 03:49:34PM -0400, Nicholas D Steeves wrote:
> Package: edb
> Severity: normal
> 
> Control: owner -1 !
> 
> Hello, as part of pkg-emacsen I have started work on packaging upstream's 
> 1.33, elpafying this package, and also #840748.

Ok, I give up...I'm not experienced enough to handle those
GNUMakefiles or bizarre byte-compilation procedure.  I've you'd like
to look at some of the approaches I took, clone this repo:

https://github.com/sten0/edb.git

and pull all branches.

Best regards,
Nicholas


signature.asc
Description: PGP signature

Bug#872374: CVE-2017-12876

[Moritz Muehlenhoff]

Package: imagemagick
Severity: grave
Tags: security

This was assigned CVE-2017-12876:
https://github.com/ImageMagick/ImageMagick/issues/663
https://github.com/ImageMagick/ImageMagick/commit/1cc6f0ccc92c20c7cab6c4a7335daf29c91f0d8e

Cheers,
Moritz

Bug#872373: CVE-2017-12877

[Moritz Muehlenhoff]

Package: imagemagick
Version: 8:6.9.7.4+dfsg-16
Severity: grave
Tags: security

This was assigned CVE-2017-12877:
https://github.com/ImageMagick/ImageMagick/issues/662
https://github.com/ImageMagick/ImageMagick/commit/98dda239ec398dd56453460849b4c9057fc424e5

Cheers,
Moritz

Bug#872263: [rb-general] Bug#872263: linux-image-4.11.0-1-amd64-dbg: file overwrite error upgrading from stretch-backports

[Ben Hutchings]

On Wed, 2017-08-16 at 17:51 +, Daniel Shahaf wrote:
> Chris Lamb wrote on Wed, 16 Aug 2017 07:54 -0700:
> > > Still, it seems like there is a wider problem here: if the exact same
> > > code is ever built in two unrelated packages then their debug info
> > > packages will conflict even if the regular binary packages don't.
> > 
> > I've seen this outside of reproducibility where I was shipping the exact
> > same binary in the redis-server and redis-sentinel packages (it changes
> > behaviour based on argv[0]).
> > 
> > The -dbgsym packages then conflicted for the same reason.
> 
> Stupid question, but why _do_ the packages conflict?  Couldn't the
> package manager notice that the file versions that would be installed by
> each package are equivalent [= same name, chmod, and bit-by-bit
> contents], and keep the file existing so long as _either_ package is
> installed?

In the case of the kernel packages, the identical binaries (vDSOs) are
emebedded in kernel images with different filenames.  The identical
debug info is installed with different filenames.  But the symlinks to
them underneath /usr/lib/debug/.build-id therefore have the same (hash-
based) name and *different* content.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou



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

Bug#871460: another example

[Krzysztof Słychań]

I track testing/sid amd64 and update my system daily. Had to reboot 
today, and was surprised that the stock Debian wallpaper appeared 
instead of my favourite one.

Tried to change it in cinnamon-settings, to no effect.

I also noticed that a dark GTK3 theme stopped working as well (Firefox 
and Thunderbird used a standard bright gray theme).
Keys assigned to launch a web browser or email client didn't work too. I 
reassigned them to custom launchers.
I don't like any audio notifications for Cinnamon or FF/TB and was 
surprised to hear a sound when new mail arrived too...



I read suggestions in this bug report and can confirm that removing the 
gnome-settings-daemon (probably a leftover from the past) actually helps.

No more problems, the old wallpaper and themes are back.


The culprit:

Aptitude 0.8.8: log report

Wed, Aug 16 2017 08:27:45 +0200
(...)
[UPGRADE] gnome-settings-daemon:amd64 3.22.2-5 -> 3.24.3-1

Bug#607758: github issue

[c.buhtz]

Because upstream moved from launchpad to GitHub the upstream-bug is no
here https://github.com/bit-team/backintime/issues/199

Bug#872372: libisofs6: null pointer dereference

[Jakub Wilk]

Package: libisofs6
Version: 1.4.6-1

xorriso crashes on the attached ISO image:

  $ xorriso -signal_handling off -indev nullptr.iso -ls
  xorriso 1.4.6 : RockRidge filesystem manipulator, libburnia project.

  libisoburn: WARNING : ISO image size 808464432s larger than readable size 20s
  xorriso : NOTE : Loading ISO image tree from LBA 0
  Segmentation fault

GDB says it's a null pointer dereference in libisofs:

  Program received signal SIGSEGV, Segmentation fault.
  iso_file_source_get_aa_string (src=0x0, aa_string=0xd298, flag=2) at 
libisofs/fsource.c:129
  129 if (src->class->version < 1) {
  (gdb) print src
  $1 = (IsoFileSource *) 0x0
  (gdb) bt
  #0  iso_file_source_get_aa_string (src=0x0, aa_string=0xd298, flag=2) at 
libisofs/fsource.c:129
  #1  0xf7d3798c in iso_image_import (image=0x5656e8e0, src=0x56559cc0, 
opts=0x56559c88, features=0xd3d4) at libisofs/fs_image.c:5743
  #2  0xf7dba4e7 in isoburn_read_image (d=0xf7ca31a0 , 
read_opts=0x56559b98, image=0xd47c) at libisoburn/isofs_wrap.c:316
  #3  0xf7e1b707 in Xorriso_aquire_drive (xorriso=0xf7656008, adr=, 
show_adr=, flag=1) at xorriso/drive_mgt.c:565
  #4  0xf7dfd9a9 in Xorriso_option_dev (xorriso=0xf7656008, in_adr=, flag=1) at xorriso/opts_d_h.c:122
  #5  0xf7def925 in Xorriso_interpreter (xorriso=, argc=, 
argv=, idx=, flag=) at 
xorriso/parse_exec.c:1389
  #6  0x56555ba7 in main ()


Found using American Fuzzy Lop:
http://lcamtuf.coredump.cx/afl/


-- System Information:
Architecture: i386

Versions of packages libisofs6:i386 depends on:
ii  libacl1  2.2.52-3+b1
ii  libc62.24-14
ii  libjte1  1.20-2+b1
ii  zlib1g   1:1.2.8.dfsg-5

--
Jakub Wilk


nullptr.iso.gz
Description: application/gzip

Bug#744801: close

[c.buhtz]

Can you still reproduce this behaviour with the current 1.12 version in
Debian or with the 1.20 version from git?

I vote for closing this bug.

Bug#872371: command ss in iproute2: please add brackets to ipv6, because ipv6 lines are confusing

[nsa spy]

Package: iproute2
Version: 4.9.0-1
Severity: wishlist

command ss in iproute2: please add brackets to ipv6, because ipv6 lines are 
confusing

please add brackets to ipv6 numbers to add clarity from port symbols.
alternate solution could be to use dots or semicolons indicating port.

what there are now (example)
~
# ss -ntlp
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128  *:443  *:* users:(("httpd",pid=999,fd=3))
LISTEN 0 128 :::443 :::* users:(("httpd",pid=999,fd=4))
~

primary proposal
~
# ss -ntlp
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128   *:443*:* users:(("httpd",pid=999,fd=3))
LISTEN 0 128[::]:443 [::]:* users:(("httpd",pid=999,fd=4))
~

alternate solution 1
~
# ss -ntlp
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *.443 *.*users:(("httpd",pid=999,fd=3))
LISTEN 0 128::.443::.*users:(("httpd",pid=999,fd=4))
~

alternate solution 2
~
# ss -ntlp
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 *;443  *;* users:(("httpd",pid=999,fd=3))
LISTEN 0 128::;443 ::;* users:(("httpd",pid=999,fd=4))
~

Bug#872317: libgtk2-perl FTBFS: GtkTextIter test failures

[Niko Tyni]

Control: reassign -1 pango1.0 1.40.9-1
Control: affects -1 src:libgtk2-perl
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=785978

On Wed, Aug 16, 2017 at 12:17:06PM +0300, Adrian Bunk wrote:
> Source: libgtk2-perl
> Version: 2:1.24992-1
> Severity: serious
> 
> Some recent change in unstable makes libgtk2-perl FTBFS:
> 
> https://tests.reproducible-builds.org/debian/history/libgtk2-perl.html
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libgtk2-perl.html

> Test Summary Report
> ---
> t/GtkTextIter.t  (Wstat: 512 Tests: 93 Failed: 2)
>   Failed tests:  67, 69
>   Non-zero exit status: 2

As discussed on IRC with Emilio, this seems to be
https://bugzilla.gnome.org/show_bug.cgi?id=785978 in pango.
Reassigning.
-- 
Niko Tyni   nt...@debian.org

Bug#872275: slic3r-prusa: Loadable library and perl binary mismatch

[Niko Tyni]

Control: severity -1 serious

On Tue, Aug 15, 2017 at 08:28:56AM -0700, wiiliamchung360 wrote:
> Package: slic3r-prusa
> Version: 1.31.4-1
> Severity: important
> 
> Dear Maintainer,
> 
> After an upgrade, it no longer works and throws this error:
> 
> "buildtmp/XS.c: loadable library and perl binaries are mismatched (got
> handshake key 0xdb80080, needed 0xde00080)"
> 
> Could this be a dependency problem?

Indeed, thanks for reporting it.

As with #869360, the package is missing a dependency on perlapi-*,
violating the Debian Perl Policy and losing the guards that make sure
compiled Perl modules are binary compatible with the current Perl version.

The other bug has some discussion and a suggested fix.

Once this is fixed, the slic3r-prusa maintainer should file a bug against
perl so we can add a Breaks entry for older versions. This makes sure
partial upgrades from stretch work.
-- 
Niko Tyni   nt...@debian.org

Bug#872370: directfb FTCBFS: fails to execute fluxcomp

[Helmut Grohne]

Source: directfb
Version: 1.7.7-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

directfb fails to cross build from source, because it fails executing a
host architecture binary called fluxcomp. Upstream advises that this is
only needed for building and that it should be compiled for the build
architecture. debian/rules configures the flux folder with
dh_auto_configure which defaults to the host architecture though. After
forcing that subdirectory to be configured for the build architecture,
directfb cross builds successfully. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru directfb-1.7.7/debian/changelog 
directfb-1.7.7/debian/changelog
--- directfb-1.7.7/debian/changelog 2017-08-15 19:57:10.0 +0200
+++ directfb-1.7.7/debian/changelog 2017-08-16 20:23:54.0 +0200
@@ -1,3 +1,10 @@
+directfb (1.7.7-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Configure flux for the build architecture (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 16 Aug 2017 20:23:54 +0200
+
 directfb (1.7.7-4) unstable; urgency=medium
 
   * Upload to unstable.
diff --minimal -Nru directfb-1.7.7/debian/rules directfb-1.7.7/debian/rules
--- directfb-1.7.7/debian/rules 2017-08-15 12:01:15.0 +0200
+++ directfb-1.7.7/debian/rules 2017-08-16 20:23:52.0 +0200
@@ -30,7 +30,7 @@
dh_auto_clean
 
 override_dh_auto_configure:
-   dh_auto_configure -Dflux
+   dh_auto_configure -Dflux -- --host=$(DEB_BUILD_GNU_TYPE)
dh_auto_build -Dflux
cp -r flux-files/* .
PATH=$(CURDIR)/flux/src:$$PATH \

Bug#872369: zsh: no completion for "dpkg --verify"

[Sven Joachim]

Package: zsh
Version: 5.4.1-1
Severity: normal

In version 1.17.2, dpkg learned a new --verify (or -V) command as well
as a --verify-format option, neither of which is currently supported by
zsh's completion system.


-- Package-specific info:

Packages which provide vendor completions:

Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
 Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ NameVersion  Architektur  Beschreibung
+++-===---
ii  curl7.55.0-1 i386 command line tool 
for transferring data with URL syn
ii  mpv 0.26.0-3 i386 video player 
based on MPlayer/mplayer2
ii  ninja-build 1.7.2-3  i386 small build 
system closest in spirit to Make
ii  reprepro5.1.1-1  i386 Debian package 
repository producer
ii  systemd 234-2i386 system and 
service manager
ii  udev234-2i386 /dev/ and hotplug 
management daemon
ii  youtube-dl  2017.05.18.1-1   all  downloader of 
videos from YouTube and other sites

dpkg-query: Kein Pfad gefunden, der auf Muster /usr/share/zsh/vendor-functions/ 
passt


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

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

Versions of packages zsh depends on:
ii  dpkg1.19.0
ii  libc6   2.24-14
ii  libcap2 1:2.25-1
ii  libtinfo5   6.0+20170715-2
ii  zsh-common  5.4.1-1

Versions of packages zsh recommends:
ii  libc6 2.24-14
ii  libncursesw5  6.0+20170715-2
ii  libpcre3  2:8.39-4

Versions of packages zsh suggests:
ii  zsh-doc  5.4.1-1

-- no debconf information

Bug#870103: freeplane: a Java (knopflerfish) exception will prevent freeplane from starting

[Felix Natter]

hello Sophoklis,

a workaround should be to copy:
  /usr/share/freeplane/props.xargs ->
  /usr/share/freeplane/fwdir/fwprops.xargs
and
  /usr/share/freeplane/init.xargs ->
  /usr/share/freeplane/fwdir/fwinit.xargs

Is there anything special in your freeplane config?
Which working directory?

I am wondering whether we shall ask knopflerfish upstream.

Cheers and Best Regards,
-- 
Felix Natter

Bug#844431: Revised patch: Oppose

[Don Armstrong]

On Wed, 16 Aug 2017, Bill Allombert wrote:
> But as a technical document, it is lacking practical recommendation
> for maintainers how to make sure their package build reproducibly

The practical recommendations for maintainers are encoded separately, as
they're evolving. See https://wiki.debian.org/ReproducibleBuilds/Howto
for example.

> and create confusion on the goal by using the term 'reproducible
> build' when 'robust build' is meant (which is a worthwile goal by
> itself, but a different project nevertheless).

I'm not convinced that this change will reduce confusion, as the
reproducible build project has been using this language in Debian for
many years now.

But I could be wrong. Please propose an alternative patch to policy
which addresses your concerns if you feel strongly about it.

-- 
Don Armstrong  https://www.donarmstrong.com

Maybe I did steal your heart
and I am such a perfect criminal
that you never noticed
 -- a softer world #481
http://www.asofterworld.com/index.php?id=481

Bug#871987: openssl breaks dovecot

[Sebastian Andrzej Siewior]

On 2017-08-16 07:46:14 [-0700], James Bottomley wrote:
> When you run a system for others, you don't get to dictate tools.
I do :)

>  However, from the complaints it seems to be android 2.3.7 and any
> embedded system still using openssl 0.9.8, which must be using TLS 1.0

so basically everything old without any (security)support but still
functional. Let me see how we deal with this…

> James

Sebastian

Bug#844431: Revised patch: Oppose

[Russ Allbery]

Bill Allombert  writes:

> This is one of the reasons I do not attend DebConf anymore. We are an
> online organization. Consultation should happen online. Metting are nice
> but they should not be used to vet consensus and ignore absentees.

> So I object to Adrian being overriden on that ground.

That's only a part of what went into this, but I will strongly defend
using the opportunity of in-person meetings to judge consensus.  It's very
difficult to judge consensus over email because only the strong opinions
are visible.  There are frequently situations where there's a large
sentiment in one direction or another that isn't expressed in long threads
full of lots of back and forth between a small handful of people who may
or may not have representative opinions.

We can't always do it, and we obviously have to be sensitive to the fact
that not everyone is in the room, but we're also going for consensus, not
unanimity.  When we have the opportunity to get direction from a large
gathering of developers, we should make use of it.

But I'm taking this position for a large number of reasons, of which
consensus at DebConf is only one.

> But as a technical document, it is lacking practical recommendation for
> maintainers how to make sure their package build reproducibly and create
> confusion on the goal by using the term 'reproducible build' when
> 'robust build' is meant (which is a worthwile goal by itself, but a
> different project nevertheless).

If you have specific wording suggestions that you believe would bring this
Policy requirement closer in line with what we're already doing in the
project (and which has gotten us to 94% reproducible already), please make
them.  I am not at all trying to rule out constructive suggestions to make
the language better, either now or in subsequent revisions of Policy.  I
think what we've got is pretty good, and I am comfortable with putting it
into Policy now, but concrete wording proposals with justification would
be welcome.  Like everything else in Policy, we can always improve how we
describe our project-wide baseline.

It's not normally Policy's role to offer detailed advice on how to meet a
particular requirement.  For example, Policy mentions debhelper in a few
footnotes but doesn't document how to use it to create compliant packages
in general.  That's not its purpose; usually that sort of documentation
can be better-maintained by other teams, such as the reproducible builds
team.

The definition in the current proposal is intentionally weaker (in the
sense that fewer packages would fail it) than what current reproducible
build testing is doing in a few places (such as with environment
variables) because it takes a conservative stance to set a baseline and it
errs on the side of a clear and simple problem statement.  It's possible
that we'll want to make it more complex in the future, but I think with
environment variables we should first have a discussion (Ximin and I
started that; I probably should move it off this thread) because I'm not
sure that's the best approach.  In the meantime, this achieves the goal of
declaring a baseline that Debian packages should be reproducible under
controlled and simple-to-state circumstances, which is something for which
I'm quite sure we have general project consensus.

If you believe it is premature to specify this in Policy entirely, I
strongly disagree, and am not persuadable on that point.

-- 
Russ Allbery (r...@debian.org)   

Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]

[Andrey Rahmatullin]

On Wed, Aug 16, 2017 at 01:00:21PM -0600, Stephen Dennis wrote:
> > > > By the way, binutils (>= 2.28.0) is wrong, as 2.28-1 is not >= 2.28.0.
> > > >
> > >
> > > Fixing.
> > You've changed it to >= 2.25-5. Why? Also, why this restriction is needed?
> >
> 
> I don't know what the guidance is for versions, so I picked the versions
> for Jessie (oldstable). There's nothing in the code that would prevent it
> from being built with older versions of these dependencies. 
Then why do you have a version restriction at all?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#872367: MATE dictionary program does not respond to user input and cannot be closed

[Hegebeek]

Package: mate-utils
Version: 1.8.1+dfsg1-2+deb8u1

Dear maintainer,

When the MATE dictionary program is started from the main menu, then the 
application appears, but a search term cannot be entered. The program 
also does not respond when the menu items below the title bar are 
clicked on. The window can be moved, resized, minimized and restored to 
its original size, but the window cannot be closed.


The MATE dictionary program has worked fine until recently. The cause of 
the problem is not known. My operating system (Debian Jessie) is up to 
date, has no broken packages and its integrity has been checked with 
debsums -l and debsums -ca.


Remarkably, when the application is added to the MATE panel it works 
there.


When the application is started from a MATE terminal:

maarten@desktop-computer:~$ mate-dictionary

the MATE dictionary window appears, but the MATE terminal gives the 
following error message 2 times immediately, and another 6 times after a 
few seconds.


(mate-dictionary:3039): Gtk-CRITICAL **: IA__gtk_widget_event: assertion 
'WIDGET_REALIZED_FOR_EVENT (widget, event)' failed


MATE System Monitor shows that the MATE dictionary programs are sleeping 
and that no process is raging. A mate-dictionary process can be ended by 
the System Monitor.


Selection of package updates that I carried out this month and last 
month:


gir1.2-gtk-2.0 (2.24.25-3+deb8u1) to 2.24.25-3+deb8u2
gtk2-engines-pixbuf (2.24.25-3+deb8u1) to 2.24.25-3+deb8u2
libgtk2.0-0 (2.24.25-3+deb8u1) to 2.24.25-3+deb8u2
libgtk2.0-bin (2.24.25-3+deb8u1) to 2.24.25-3+deb8u2
libgtk2.0-common (2.24.25-3+deb8u1) to 2.24.25-3+deb8u2

Other information:

maarten@desktop-computer:~$ uname -a
Linux desktop-computer 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u2 
(2017-06-26) x86_64 GNU/Linux


maarten@desktop-computer:~$ dpkg -s libc6 | grep ^Version
Version: 2.19-18+deb8u10

According to Synaptic, mate-utils has installed:
/usr/share/applications/mate-dictionary.desktop
/usr/share/applications/mate-disk-usage-analyzer.desktop
/usr/share/applications/mate-screenshot.desktop
/usr/share/applications/mate-search-tool.desktop
/usr/share/applications/mate-system-log.desktop
but according to Caja, these files are not in /usr/share/applications to 
be found.


Kind regards

Maarten

Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]

[Stephen Dennis]

Thank you for the feedback and for the effort it takes to review these
packages.

On Wed, Aug 16, 2017 at 12:40 PM, Andrey Rahmatullin 
wrote:

> On Tue, Aug 15, 2017 at 12:05:26PM -0600, Stephen Dennis wrote:
> > > By the way, binutils (>= 2.28.0) is wrong, as 2.28-1 is not >= 2.28.0.
> > >
> >
> > Fixing.
> You've changed it to >= 2.25-5. Why? Also, why this restriction is needed?
>

I don't know what the guidance is for versions, so I picked the versions
for Jessie (oldstable). There's nothing in the code that would prevent it
from being built with older versions of these dependencies. However, if you
have better guidance, lead on. Should I pick all the versions from testing?

I've run license-reconcile on the package, it shows a lot of copyright
> mismatches and asks you to name the pcre.* license "BSD-3-clause". I've
> alos noticed src/wild.cpp says "This code is hereby placed under GNU
> copyleft" which is not clarified, not mentioned in debian/copyright and
> may be problematic in conjuction with Artistic 1.0.
>

Glad to make the BSD-3-clause change.

The wild.cpp code is very old (on the order of 20-25 years), and it has
changed little in that time. Code that old has been licensed and
re-licensed by the original authors, starting with GNU but eventually
landing under Artistic 1.0. There is a long and complex history, and it is
possible that someone contributed code that I don't know about, but I know
for certain that all of the primary maintainers have agreed to put their
work under Artistic 1.0 (not only for TinyMUX but for the entire family of
MUSH-style servers). If you want to read about this complex history, check
out http://wiki.tinymux.org/index.php/History.


Stephen

Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[RjY]

Package: src:gpgme1.0
Version: 1.8.0-3

It seems in recent unstable the gnupg package has turned into a
metapackage pulling in the whole gpg suite. Thus the dependency chain

  mutt -> libgpgme11 -> gnupg -> [lots of stuff]

is pulling in a lot of stuff I don't need. I use mutt and don't want to
uninstall it, so could the dependency be reduced? It seems splitting up
the gnupg package into smaller pieces is pointless if commonly used
applications force the whole lot to be pulled in.

Many thanks in advance for your consideration.

-- 
https://rjy.org.uk/

Bug#871295: htmlcxx: diff for NMU version 0.86-1.2

[Stephen Kitt]

Control: tags 871295 + patch
Control: tags 871295 + pending

Dear maintainer,

I've prepared an NMU for htmlcxx (versioned as 0.86-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,

Stephen
diff -Nru htmlcxx-0.86/debian/changelog htmlcxx-0.86/debian/changelog
--- htmlcxx-0.86/debian/changelog	2016-08-16 13:53:33.0 +0200
+++ htmlcxx-0.86/debian/changelog	2017-08-16 17:13:31.0 +0200
@@ -1,3 +1,10 @@
+htmlcxx (0.86-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add GCC 7 symbols (Closes: #871295).
+
+ -- Stephen Kitt   Wed, 16 Aug 2017 17:13:31 +0200
+
 htmlcxx (0.86-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru htmlcxx-0.86/debian/libcss-parser-pp0v5.symbols htmlcxx-0.86/debian/libcss-parser-pp0v5.symbols
--- htmlcxx-0.86/debian/libcss-parser-pp0v5.symbols	2016-08-16 13:53:33.0 +0200
+++ htmlcxx-0.86/debian/libcss-parser-pp0v5.symbols	2017-08-16 17:11:04.0 +0200
@@ -39,3 +39,4 @@
  (c++|optional)"std::vector::~vector()@Base" 0.83
  (c++|optional)"void std::vector::_M_emplace_back_aux(htmlcxx::CSS::Parser::Selector const&)@Base" 0.86
  free_rulesets@Base 0.83
+ (c++|optional)"void std::vector::_M_realloc_insert(__gnu_cxx::__normal_iterator >, htmlcxx::CSS::Parser::Selector const&)@Base" 0.86-1.2~
diff -Nru htmlcxx-0.86/debian/libhtmlcxx3v5.symbols htmlcxx-0.86/debian/libhtmlcxx3v5.symbols
--- htmlcxx-0.86/debian/libhtmlcxx3v5.symbols	2016-08-16 13:53:33.0 +0200
+++ htmlcxx-0.86/debian/libhtmlcxx3v5.symbols	2017-08-16 17:08:59.0 +0200
@@ -66,6 +66,7 @@
  (c++)"htmlcxx::Uri::user(std::__cxx11::basic_string)@Base" 0.85
  (c++|optional)"char const* htmlcxx::HTML::ParserSax::skipHtmlTag(char const*, char const*)@Base" 0.83
  (c++|optional)"htmlcxx::CharsetConverter::Exception::~Exception()@Base" 0.83
+ (c++|optional)"htmlcxx::HTML::Node::operator std::__cxx11::basic_string() const@Base" 0.86-1.1~
  (c++|optional)"htmlcxx::HTML::Node::~Node()@Base" 0.83
  (c++|optional)"htmlcxx::HTML::ParserDom::~ParserDom()@Base" 0.83
  (c++|optional)"htmlcxx::HTML::ParserSax::~ParserSax()@Base" 0.83
@@ -82,12 +83,14 @@
  (c++|optional)"std::vector >::pre_order_iterator, std::allocator >::pre_order_iterator> >::_M_insert_aux(__gnu_cxx::__normal_iterator >::pre_order_iterator*, std::vector >::pre_order_iterator, std::allocator >::pre_order_iterator> > >, tree >::pre_order_iterator const&)@Base" 0.83
  (c++|optional)"tree >::pre_order_iterator::operator++()@Base" 0.83
  (c++|optional)"tree >::pre_order_iterator tree >::append_child >::pre_order_iterator>(tree >::pre_order_iterator, htmlcxx::HTML::Node const&)@Base" 0.83
+ (c++|optional)"tree >::pre_order_iterator::pre_order_iterator(tree >::sibling_iterator const&)@Base" 0.86-1.2~
  (c++|optional)"tree >::~tree()@Base" 0.83
  (c++|optional)"void htmlcxx::HTML::ParserSax::parse(char const*&, char const*&, std::forward_iterator_tag)@Base" 0.83
  (c++|optional)"void htmlcxx::HTML::ParserSax::parseComment(char const*, char const*)@Base" 0.83
  (c++|optional)"void htmlcxx::HTML::ParserSax::parseContent(char const*, char const*)@Base" 0.83
  (c++|optional)"void htmlcxx::HTML::ParserSax::parseHtmlTag(char const*, char const*)@Base" 0.83
  (c++|optional)"void std::vector >::pre_order_iterator, std::allocator >::pre_order_iterator> >::_M_emplace_back_aux >::pre_order_iterator const&>(tree >::pre_order_iterator const&)@Base" 0.86
+ (c++|optional)"void std::vector >::pre_order_iterator, std::allocator >::pre_order_iterator> >::_M_realloc_insert 

Bug#871693: RFS: tinymux/2.10.1.14-1 [RC]

[Andrey Rahmatullin]

On Tue, Aug 15, 2017 at 12:05:26PM -0600, Stephen Dennis wrote:
> > By the way, binutils (>= 2.28.0) is wrong, as 2.28-1 is not >= 2.28.0.
> >
> 
> Fixing.
You've changed it to >= 2.25-5. Why? Also, why this restriction is needed?

I've run license-reconcile on the package, it shows a lot of copyright
mismatches and asks you to name the pcre.* license "BSD-3-clause". I've
alos noticed src/wild.cpp says "This code is hereby placed under GNU
copyleft" which is not clarified, not mentioned in debian/copyright and
may be problematic in conjuction with Artistic 1.0.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#844431: Revised patch: Oppose

[Bill Allombert]

On Wed, Aug 16, 2017 at 09:30:23AM -0700, Russ Allbery wrote:
> As Policy Editor (a delegated position), based on my read of project
> consensus including in-person verification of that consensus at DebConf
> 17, I am formally declaring that I believe this change has consensus
> despite your opposition.  We will therefore include this change in the
> next release of Policy.

This is one of the reasons I do not attend DebConf anymore. We are an
online organization. Consultation should happen online. Metting are nice
but they should not be used to vet consensus and ignore absentees.

So I object to Adrian being overriden on that ground.

Now it seems to me this policy proposal is a way to acknowledge the
great work of the reproducible build project. As such it is probably
fine and they amply deserve praise and acknowledgement.

But as a technical document, it is lacking practical recommendation for
maintainers how to make sure their package build reproducibly and create
confusion on the goal by using the term 'reproducible build' when 
'robust build' is meant (which is a worthwile goal by itself, but a
different project nevertheless). 

So I am concerned we are putting the cart before the horse.

Cheers,
Another Policy Editor (a delegated position).
-- 
Bill. 

Imagine a large red swirl here. 

Bug#844431: Revised patch: Oppose

[Russ Allbery]

Just to be completely, 100% clear: I will not be responding further to
this line of argument in this bug.  If you disagree with my decision as a
project delegate, I've spelled out your possible next steps under Debian's
governance process.

-- 
Russ Allbery (r...@debian.org)   

Bug#844431: Revised patch: Oppose

[Adrian Bunk]

On Wed, Aug 16, 2017 at 09:30:23AM -0700, Russ Allbery wrote:
>...
> This text is a formalization and simplification of existing practice that
> we worked out in conjuction with the reproducible builds team and that
> strikes a balance between attempting to enumerate all the causes of
> nonreproducibility (which would be quite difficult to do) and providing
> some clear guidance to maintainers about what types of output variance
> they *don't* have to worry about (since obviously packages can't be
> reproducible under all circumstances and in all environments).  The
> intention is to set a minimum bar that packages should be trying to meet,
>...

The definition of reproducibility in policy does not match any past, 
present or future practice in Debian.

And no current or currently planned reproducible testing does test
or is intended to test whether packages meet this minimum bar.

> This is directly in the center of Policy's normal role of standardizing
> and documenting best practice that has been developed elsewhere in the
> project.
>...

If it would actually standardize what is considered reproducible
in Debian everything would be fine.

> The definition is not decoupled from current practice.  It is roughly
> equivalent to the information currently captured in *.buildinfo files
> while being easily comprehensible to people who haven't studied
> *.buildinfo files.
>...

2 of the 5 items in policy require changes to .buildinfo, and for a 
third I cannot easily comprehend whether it would require changes to 
.buildinfo since it is unclear what it is supposed to mean:

- a set of environment variable values;

.buildinfo currently records only some environment variables.
If all or different ones are allowed to vary that is a change.
I am actually surprised that the latest set of suggested permitted
variations does not seem to be based on the existing list currently
used for .buildinfo

- a version of a source package unpacked at a given path;

The path is currently not in .buildinfo

- a build architecture;

What is the intended purpose of this, especially what is this supposed 
to output for i386 builds on amd64 kernel?
.buildinfo currently follows dpkg-architecture, and outputs i386.
i386/amd64 kernels is a build variation in the reproducible builds
infrastructure that does result in packages being built differently,
which makes it unclear whether this difference was supposed to be
addressed here.

> Finally, Policy in no way constrains people from filing bugs or reporting
> issues (via whatever means, such as tracker.debian.org) in packages about
> things that are not spelled out in Policy.
>...

https://tracker.debian.org/pkg/hsqldb1.8.0
"Does not build reproducibly during testing"

This statement in tracker is automatically generated based on results 
from the reproducible builds infrastructure.

Is it acceptable to claim in tracker that a package is not reproducible, 
when that package might actually be reproducible based on the definition 
of reproducibility spelled out in Policy? [1]

cu
Adrian

[1] as explained earlier, it is not obvious whether or not this
specific package is reproducible according to Policy

-- 

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

Bug#872355: ITP: node-is-module -- Node.js code to check if a string is an ES6 module

[Julien Puydt]

Hi,

Le 16/08/2017 à 19:26, Philip Hands a écrit :
> Julien Puydt  writes:
>> * URL : https://github.com/component/is-module
> 
> That URL is not correct.
> 
> Did you perhaps mean:  https://github.com/timaschew/is-module
> 

It's annoying:
   https://www.npmjs.com/package/is-module
points to:
   https://github.com/component/is-module
so what I packaged is what people using npm to get their javascript
chunk actually use. But indeed, that link is a 404.

The link you point to gives the same license with the same copyright,
but it doesn't look like it's the same author, so I don't know what
I'm supposed to do.

Snark on #debian-js

Bug#872355: ITP: node-is-module -- Node.js code to check if a string is an ES6 module

[Philip Hands]

Julien Puydt  writes:

> Hi,
>
> Le 16/08/2017 à 19:26, Philip Hands a écrit :
>> Julien Puydt  writes:
>>> * URL : https://github.com/component/is-module
>> 
>> That URL is not correct.
>> 
>> Did you perhaps mean:  https://github.com/timaschew/is-module
>> 
>
> It's annoying:
>https://www.npmjs.com/package/is-module
> points to:
>https://github.com/component/is-module
> so what I packaged is what people using npm to get their javascript
> chunk actually use. But indeed, that link is a 404.
>
> The link you point to gives the same license with the same copyright,
> but it doesn't look like it's the same author, so I don't know what
> I'm supposed to do.

Sorry, I've no idea -- the link I came up with is just the result of
putting 'is-module' into github's search -- I have no information about
how that might relate to whatever was at the other link, or why it's not
there now.

I do note that timaschew's version includes a comment:

  // no idea what these regular expressions do,
  ...

  ( https://github.com/timaschew/is-module/blob/master/index.js#L2 )

which strikes me as a little worrying, given that the regular
expressions constitute pretty-much everything that this package does, so
if you can find a version of this by someone that knows what they are
doing, that might be a bonus ;-)

I guess that the way to make that better would be to get the person
responsible for the original version of the regexps to factor that bit
out into a separate library, and then rely on that in their code, at
which point you'd have a maintained version of the regexps to use, but I
can understand that that might not be the path of least resistance.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#844431: Revised patch: seeking seconds

[Ximin Luo]

Russ Allbery:
> Ximin Luo  writes:
> 
>> Fair enough. I actually spotted that but thought it was better to get
>> "something" into Policy rather than nitpick. I guess other people were
>> thinking similar things. Well, lesson learnt, I will be more forceful
>> next time.
> 
>> The sentence I amended said "most environment variables" so our intent
>> is clear. If we want to fix this now, I would suggest amending:
> 
>> - a set of environment variable values; and
>> + a set of reserved environment variable values; and
> 
>> then later:
> 
>> + A "reserved" environment variable is defined as DEB_*, DPKG_, 
>> SOURCE_DATE_EPOCH, BUILD_PATH_PREFIX_MAP, variables listed by 
>> dpkg-buildflags and other variables explicitly used by buildsystems to 
>> affect build output, excluding any variables used by non-build programs to 
>> affect their behaviour. Explicitly, this excludes TERM, HOME, LOGNAME, USER, 
>> PATH and likely any variables ending with *PATH.
> 
> We intentionally didn't spell this out in this much detail because it felt
> better to defer this (stricter) bar until we have documentation of the
> *.buildinfo file, and also because we were worried about the list changing
> (once it goes into Policy, it's more irritating to change).  The current
> standard in Policy is intentionally weaker than this in order to be
> simpler.
> 
> I still lean towards taking this approach, because I'm pretty worried
> about the scope of:
> 
> other variables explicitly used by buildsystems to affect build output
> 
> That's not really an enumerable list.  My recommendation, if you want to
> allow some environment variables to vary without affecting
> reproducibility, is to explicitly list the set of environment variables
> that can vary, rather than trying to list the ones that have to remain
> fixed.
> 

Intuitively it feels weird to say "if you vary USER, the output must remain 
fixed", but also "if you vary RANDOMUNIQUESPECIALSNOWFLAKEVARIABLE then the 
output is allowed to change".

Certain environment variables have become convention to affect a build, like 
CFLAGS, and even debuild(1) doesn't clear them - but clears the other envvars. 
That is what I was going on.

> But, more fundamentally, I'm dubious that weakening the environment
> variable set is a good use of anyone's time.  Why not define reproducible
> builds as setting a specific set of environment variables and no others?
> We're long past the point where building packages in an isolated
> environment with a fixed set of environment variables is a great hardship
> or even particularly unusual.  I think the effort would be better spent on
> fixing (with enumerated exceptions) the set of environment variables set
> by buildds, sbuild, pbuilder, and other infrastructure that builds
> packages than in making packages tolerate random environment variables
> being set during the build.  It's really hard to track down all the
> environment variable settings that might affect Autoconf, the build tools,
> document formatters, and so forth.
> 

My proposal was the opposite, to *strengthen* the definition that was already 
accepted - I *don't* think we should track down all those variables and make 
packages immune to them, that is why I added "other variables explicitly used 
by buildsystems to affect build output" etc. OTOH, some other variables are 
used by non-build tools, such as LC_*, USER, etc. Since they affect non-build 
programs, they possibly may be set in a developer's normal environment, so just 
running "debian/rules build" will pick these up. Then, the build should stay 
the same despite these other variables.

If a build tool needs to be run in a specific locale, it should either use a 
locale-independent sorting program, or set LC_ALL explicitly itself regardless 
of what the parent environment says.

This doesn't contradict us from using a fixed or mostly-clean environment in 
sbuild, pbuilder, debuild, etc.

Now that I think about it however, it's probably not reasonable to expect that 
the output remains the same when PATH is changed. On tests.r-b.org we vary it 
by appending a dummy value [1] but if the user adds their own stuff to the 
beginning then the output may well change. There is probably no point in trying 
to prevent that in all packages. In a sense, it does very much affect what 
build tools are run, even though non-build programs also use it. However, my 
gut feeling still says that it's not right for the locale (LC_*) to affect a 
build process. I will try to think of a more precise way to express this 
difference.

X

[1] https://tests.reproducible-builds.org/debian/index_variations.html

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#812826: xim problem

[Sean Whitton]

Hello Osamu,

On Wed, Aug 16 2017, Osamu Aoki wrote:

> Did you install library supporting ..
>
> If you read dialog carefully, im-config tells me as:
>
>  * Application platform support:
>* GNOME/GTK+: ibus-gtk and ibus-gtk3 (both)
>* KDE/Qt: ibus-qt4
>* Clutter: ibus-clutter
>* EMACS: ibus-el
>
>
> You need to install these.
>
> ibus-el doesn't exist any more but ibus-gtk, ibus-gtk3, ibus-qt4,
> ibus-clutter.

All of them were already installed.

I think that Emacs and urxvt just don't support ibus.  I guess I should
use a different terminal emulator, and use Emacs' own support for typing
Korean.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#803924: for stretch?

[Matthew Gabeler-Lee]

Is this fix queued to end up in stretch?  A prior mail suggests maybe it
is, but not clear?  Will that not be released until the stretch 9.1
update goes out?

Bug#872366: libsane: Missing man page

[Brian Potkin]

Package: libsane
Version: 1.0.25-4.1
Severity: normal


sane-dll(5) is referenced from many SANE manual pages. It does not
exist on my system.

Regards,

Brian.

Bug#872365: python-cysignals-pari: Makes sagemath uninstallable, but sagemath depends on python-cysignals-pari

[Robbie Harwood]

Package: python-cysignals-pari
Version: 1.6.5+ds-1
Severity: important

Dear Maintainer,

sagemath depends on python-cysignals-pari.  However, python-cysignals-pari
has:

Breaks: sagemath (< 8.0~), sagemath:i386 (< 8.0~)

Since the only version of sagemath avaioable is 7.6, this makes sagemath
uninstallable.

I'm reporting this bug to your package because it has the problem; if you feel
that sagemath is at fault, please reassign.

Thanks,
--Robbie

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

Kernel: Linux 4.11.0-1-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages python-cysignals-pari depends on:
ii  libc6 2.24-12
pn  libpari-gmp-tls5  
ii  python2.7.13-2

Versions of packages python-cysignals-pari recommends:
pn  cysignals-tools  

Versions of packages python-cysignals-pari suggests:
pn  python-cysignals-doc  

Bug#872364: libsane: Is consolekit relevant?

[Brian Potkin]

Package: libsane
Version: 1.0.25-4.1
Severity: normal


Consolekit is mentioned twice in README.Debian. Should this be replaced
by libpam-systemd?

Regards,

Brian.

Bug#853452: injeqt: ftbfs with GCC-7

[Mateusz Łukasik]

Control: + patch
Control: + upstream

Here has been fixed upstream: 
https://github.com/vogel/injeqt/commit/de025e0c472bdb2fcabbc9dc2fd443b91ab28e28


I will prepare NMU at the of week.

--
 .''`.  Mateusz Łukasik
: :' :  https://l0calh0st.pl
`. `'   Debian Member - mat...@linuxmint.pl
  `-GPG: D93B 0C12 C8D0 4D7A AFBC  FA27 CCD9 1D61 11A0 6851

Bug#872263: [rb-general] Bug#872263: linux-image-4.11.0-1-amd64-dbg: file overwrite error upgrading from stretch-backports

[Daniel Shahaf]

Chris Lamb wrote on Wed, 16 Aug 2017 07:54 -0700:
> > Still, it seems like there is a wider problem here: if the exact same
> > code is ever built in two unrelated packages then their debug info
> > packages will conflict even if the regular binary packages don't.
> 
> I've seen this outside of reproducibility where I was shipping the exact
> same binary in the redis-server and redis-sentinel packages (it changes
> behaviour based on argv[0]).
> 
> The -dbgsym packages then conflicted for the same reason.

Stupid question, but why _do_ the packages conflict?  Couldn't the
package manager notice that the file versions that would be installed by
each package are equivalent [= same name, chmod, and bit-by-bit
contents], and keep the file existing so long as _either_ package is
installed?

Bug#844431: Revised patch: seeking seconds

[Russ Allbery]

Bill Allombert  writes:
> On Wed, Aug 16, 2017 at 09:36:04AM -0700, Russ Allbery wrote:

>> Note that, for most developers, this is pretty much equivalent to the
>> current situation with FTBFS on, say, s390 architectures.  Or even
>> issues with running under whichever init system is not the one the
>> maintainer personally uses.

> Debian provides porter box for that purpose. This means if your package
> FTBFS on s390 you can login to a s390 porter box, use sbuild to set up a
> build environment, fix the problem and then check the package now build
> correctly.

> Now compare with reproducible build. You get some error report you
> cannot reproduce, do some change following the help provided and hope
> for the best. Then some day later you get the same error report.

This hasn't been my experience with reproducible build bug reports.  Once
there's a bug report of unreproducibility under some specific situation,
I've always been able to reproduce it by doing multiple builds with that
specific variation and seeing how the output changes.

I agree that this may not always be the case, but it's also not always the
case that one can reproduce an s390 buildd failure on a porter box.

-- 
Russ Allbery (r...@debian.org)   

Bug#872291: openorienteering-mapper: unable to open files with spaces in their names

[Graham Inggs]

Control: tags -1 + pending

The problem was in the wrapper script in the Debian packaging, fix committed:
https://anonscm.debian.org/cgit/collab-maint/openorienteering-mapper.git/commit/?id=b5b08688497ca64328df90c9d41fa845bb4a6079

Bug#872358: RFS/ITP: node-is-module/1.0.0-1

[Andrey Rahmatullin]

On Wed, Aug 16, 2017 at 07:03:47PM +0200, Julien Puydt wrote:
>  * URL : https://github.com/component/is-module
404

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#872363: caja still reports glib object warnings

[shirish शिरीष]

Package: caja
Version: 1.18.3-1
Severity: normal

Dear Maintainer,

I'm still glib warnings and critical messages on caja.

(caja:19739): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(caja:19739): GLib-GObject-CRITICAL **: g_signal_connect_data:
assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(caja:19739): GLib-GObject-WARNING **: invalid (NULL) pointer instance

(caja:19739): GLib-GObject-CRITICAL **: g_signal_connect_data:
assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(caja:19739): EggSMClient-CRITICAL **: egg_sm_client_is_resumed:
assertion 'client == global_client' failed

These errors shouldn't be with mate 1.18 series, that was supposed to
be the big thing.

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

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

Versions of packages caja depends on:
ii  caja-common   1.18.3-1
ii  desktop-file-utils0.23-2
ii  gvfs  1.30.4-1+b1
ii  libatk1.0-0   2.24.0-1
ii  libc6 2.24-12
ii  libcairo-gobject2 1.14.10-1
ii  libcairo2 1.14.10-1
ii  libcaja-extension11.18.3-1
ii  libexempi32.4.3-1
ii  libexif12 0.6.21-2+b2
ii  libgail-3-0   3.22.18-1
ii  libgdk-pixbuf2.0-02.36.5-2
ii  libglib2.0-0  2.53.4-3
ii  libglib2.0-data   2.53.4-3
ii  libgtk-3-03.22.18-1
ii  libice6   2:1.0.9-2
ii  libmate-desktop-2-17  1.18.0-1
ii  libnotify40.7.7-2
ii  libpango-1.0-01.40.6-1
ii  libpangocairo-1.0-0   1.40.6-1
ii  libselinux1   2.6-3+b2
ii  libsm62:1.2.2-1+b3
ii  libstartup-notification0  0.12-4+b2
ii  libx11-6  2:1.6.4-3
ii  libxml2   2.9.4+dfsg1-3
ii  mate-desktop  1.18.0-1
ii  shared-mime-info  1.8-1

Versions of packages caja recommends:
ii  gvfs-backends  1.30.4-1+b1

Versions of packages caja suggests:
ii  engrampa1.18.2-1
ii  gstreamer1.0-tools  1.12.2-1
ii  meld3.16.4-1

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#844431: Revised patch: seeking seconds

[Bill Allombert]

On Wed, Aug 16, 2017 at 09:36:04AM -0700, Russ Allbery wrote:
> Note that, for most developers, this is pretty much equivalent to the
> current situation with FTBFS on, say, s390 architectures.  Or even issues
> with running under whichever init system is not the one the maintainer
> personally uses.

Debian provides porter box for that purpose. This means if your package
FTBFS on s390 you can login to a s390 porter box, use sbuild to set up a
build environment, fix the problem and then check the package now build
correctly.

Now compare with reproducible build. You get some error report you
cannot reproduce, do some change following the help provided and
hope for the best. Then some day later you get the same error
report.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#872361: mpg123 misparses IPv6 address + port in http_proxy

[Ivan Shmakov]

Package:  mpg123
Version:  1.23.8-1+b1

It appears that mpg123(1) fails to notice the :PORT suffix when
parsing an http_proxy value that contains an IPv6 address.

Consider, e. g.:

$ http_proxy=http://\[::1\]:8080/ \
  strace -o "$(mktemp -- /tmp/strace.)" -- \
  mpg123 --test -- http://stream.chipbit.net:8000/autodj.m3u 
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
version 1.23.8; written and copyright by Michael Hipp and others
free software (LGPL) without any warranty but with best wishes
HTTP request failed: 404 Not Found
main: [src/mpg123.c:709] error: Access to http resource 
http://stream.chipbit.net:8000/autodj.m3u failed.
$ 

The strace(1) output reveals that mpg123(1) tries to connect to
the default HTTP port (80), not the one specified (8080):

connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::1", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 0

Also to note is that using an (IPv6-only) name (as shown below)
in place of the IPv6 address does not cause the issue.

$ http_proxy=http://ip6-localhost:8080/ \
  mpg123 --test -- http://stream.chipbit.net:8000/autodj.m3u 

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A