Bug#846192: devscripts: lintian called from debuild always fail (gave error exit status 1)

[Christian Marillat]

Package: devscripts
Version: 2.16.10
Severity: normal

Dear Maintainer,

>From several sources I see this error :

dpkg-buildpackage: info: full upload (original source is included)
dpkg-buildpackage: info: running hook check
 lintian ../motioneye-dmo_0.35.1-dmo1_i386.changes
E: motioneye-dmo source: source-is-missing 
motioneye/static/js/css-browser-selector.js line length is 2180 characters 
(>512)
E: motioneye-dmo source: source-is-missing motioneye/static/js/jquery.min.js
E: motioneye-dmo source: source-is-missing 
motioneye/static/js/jquery.timepicker.min.js
W: motioneye: binary-without-manpage usr/bin/meyectl
dpkg-buildpackage: error: lintian ../motioneye-dmo_0.35.1-dmo1_i386.changes 
gave error exit status 1
debuild: fatal error at line 1100:
dpkg-buildpackage -rfakeroot -us -uc --hook-check=cd ..;  -j10 
--check-command=lintian failed

I think this bug has been introcuded when bug #845628 has been fixed.

Tell me if you want more info.

Christian

-- Package-specific info:

--- /etc/devscripts.conf ---
DSCVERIFY_KEYRINGS="trustedkeys.gpg"

--- ~/.devscripts ---
DEVSCRIPTS_CHECK_DIRNAME_LEVEL=0
DEBCHANGE_RELEASE_HEURISTIC=log
DEBCHANGE_MULTIMAINT=no
DEBCLEAN_CLEANDEBS=yes
DEBSIGN_KEYID=65558117
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-j10"
DEBUILD_LINTIAN=yes
DEBUILD_LINTIAN_OPTS="--color always"
DSCVERIFY_KEYRINGS="trustedkeys.gpg"
USCAN_DOWNLOAD=no
USCAN_SYMLINK=no
USCAN_VERBOSE=no
DEBCHANGE_AUTO_NMU=no

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev 1.18.15
ii  libc62.24-7
ii  perl 5.24.1~rc4-1
pn  python3:any  

Versions of packages devscripts recommends:
ii  apt 1.4~beta1
ii  at  3.1.20-1
ii  curl7.51.0-1
ii  dctrl-tools 2.24-2
pn  debian-keyring  
ii  dupload 2.7.0
pn  equivs  
ii  fakeroot1.21-2
ii  file1:5.29-1
ii  gnupg   1.4.20-6
ii  gnupg2  2.1.11-7
pn  libdistro-info-perl 
ii  libencode-locale-perl   1.05-1
ii  liblwp-protocol-https-perl  6.06-2
pn  libsoap-lite-perl   
ii  liburi-perl 1.71-1
ii  libwww-perl 6.15-1
pn  licensecheck
ii  lintian 2.5.49
ii  man-db  2.7.5-2
ii  patch   2.7.5-1
ii  patchutils  0.3.4-2
pn  python3-debian  
pn  python3-magic   
ii  sensible-utils  0.0.9
ii  strace  4.13-0.1
ii  unzip   6.0-20
pn  wdiff   
ii  wget1.18-4
ii  xz-utils5.2.2-1.2

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20160123cvs-3
ii  build-essential  12.2
pn  check-all-the-things 
pn  cvs-buildpackage 
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
pn  gnuplot  
ii  gpgv 1.4.20-6
pn  how-can-i-help   
pn  libauthen-sasl-perl  
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
ii  libterm-size-perl0.207-1+b4
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:7.3p1-3+b1
ii  piuparts 0.72
pn  ratt 
pn  reprotest
ii  svn-buildpackage 0.8.6
ii  w3m  0.5.3-33

-- no debconf information

Bug#846038: wesnoth: Setting fullscreen crashes game

[Vincent Cheng]

Control: tag -1 + moreinfo unreproducible

Hi,

On Sun, Nov 27, 2016 at 6:12 PM, Alex Henry  wrote:
> Package: wesnoth
> Version: 1:1.12.6-1
> Severity: important
> Tags: upstream
>
> Hello! As the title says whenever I select "fullscreen" the game
> simply dies on me. The following is output to the console:
>
> setting mode to 1024x768x32
> X Error of failed request:  BadValue (integer parameter out of range for 
> operation)
>   Major opcode of failed request:  152 (XFree86-VidModeExtension)
>   Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
>   Value in failed request:  0x49e
>   Serial number of failed request:  196
>   Current serial number in output stream:  198
>
> I am using KDE5 and I believe that Debian is using Wayland on top of X.org
> or something like that.
>
> I'm setting this as important because I imagine most people like
> to play games fullscreen but it is a matter of opinion really. If
> you think this should prevent the game from reaching stable I
> believe you'd have to change it to a higher severity.

I can't reproduce this bug myself; I have always been able to run
wesnoth in windowed or fullscreen mode without a problem.

My guess is that this is some sort of bug specific to certain
fullscreen resolutions (probably more esoteric ones). There are
mentions of this issue in the wesnoth forums, e.g. [1], so probably
not an isolated issue, but I don't think it's widespread enough to
justify a severity bump. Please try and see if this is reproducible
with wesnoth-1.13, and also consider filing a bug report upstream [2].

Regards,
Vincent

[1] https://forums.wesnoth.org/viewtopic.php?t=43576=592233
[2] https://wiki.wesnoth.org/Reportingbugs

Bug#844986: repo moved

[Paolo Greppi]

I moved the git repo to here:
https://anonscm.debian.org/cgit/python-modules/packages/python-jsonref.git

Paolo



signature.asc
Description: OpenPGP digital signature

Bug#796769: retitle to ITP: hdmi2usb-fx2-firmware -- f/w for micro-controller on HDMI2USB hardware

[Stefano Rivera]

Control: retitle -1 ITP: hdmi2usb-fx2-firmware -- FX2 firmware for hdmi2usb 
board development
Control: owner -1 !

This package contains the FX2 firmware for several modes of the Numato
Opsis board's USB interface.

It is used for flashing updates to the board.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#845482: repo moved

[Paolo Greppi]

I moved the git repo to here:
https://anonscm.debian.org/cgit/python-modules/packages/python-patch.git

Paolo



signature.asc
Description: OpenPGP digital signature

Bug#841090: Why not just set signal handlers?

[Dmitry Bogatov]

[2016-11-28 00:56] Ian Jackson 
>
> part   text/plain1705
> Ian Jackson writes ("Re: Bug#841090: Why not just set signal handlers?"):
> > It's certainly not just my opinion.  This bug was fixed in Python and
> > GHC and xfce4-terminal already.  The bug I filed against lightdm has
> > been fixed.
> >
> >  https://ghc.haskell.org/trac/ghc/ticket/4274
> >  https://twistedmatrix.com/trac/ticket/4199
> >  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733722
>
> Also,
>
> libguestfs
>   https://www.redhat.com/archives/libguestfs/2011-April/msg6.html
>
> launchpad
>   
> https://code.launchpad.net/~jelmer/launchpad/637507-subprocess-sigpipe/+merge/37940
>   Written in Python but the Python fix would have been backwards-
>   incompatible so often applications need patching.  This one is
>   notable because launchpad wants to run dpkg-source -x and motivation
>   in the bug report suggests that dpkg-source -x can break sometimes
>   with SIGPIPE ignored.
>
> pyanaconda
>   
> https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-September/013489.html
>   (another Python one)
>
> chromium
>   
> https://chromium.googlesource.com/native_client/src/native_client/+/master/tools/test_lib.py
>   (another Python one)
>
> ubuntutools
>   https://lists.ubuntu.com/archives/universe-bugs/2011-June/197570.html
>   (another Python one)
>
> dak
>   https://lists.debian.org/debian-dak/2013/10/msg9.html
>   (having this bug in the Python standard library just keeps giving)
>
> I also found this
>
>   http://www.pixelbeat.org/programming/sigpipe_handling.html
>
> I hope that's enough to convince you...

Enough, sure. Will add fix for dvtm.

Thank you.

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgp5dCkjx4muy.pgp
Description: PGP signature

Bug#846173: [Pkg-libvirt-maintainers] Bug#846173: libvirt-daemon: Fails to locate existing usb device

[Guido Günther]

On Mon, Nov 28, 2016 at 10:56:33PM +, David Gilmour wrote:
> 
> Package: libvirt-daemon
> Version: 2.4.0-1+b1
> Severity: important
> 
> Dear Maintainer,
> 
> I have a custom udev rule used to implement usb-hotplug support for the a 
> guest, whose name is dgw.
> 
> This is the contents of /etc/udev/rules.d/91-hotplug.rules:
> ---
> ACTION=="add", \
> SUBSYSTEM=="usb", \
> ENV{ID_VENDOR_ID}=="18ec", \
> ENV{ID_MODEL_ID}=="3399", \
> RUN+="/usr/bin/virsh attach-device dgw 
> /home/david/udev/david-webcam-dgw.xml"
> 
> ACTION=="remove", \
> SUBSYSTEM=="usb", \
> ENV{ID_VENDOR_ID}=="18ec", \
> ENV{ID_MODEL_ID}=="3399", \
> RUN+="/usr/bin/virsh detach-device dgw 
> /home/david/udev/david-webcam-dgw.xml"
> ---
> 
> This is the content of david-webcam-dgw.xml:
> ---
> 
>   
> 
> 
>   
> 
> ---
> 
> The rule is correctly activated when the device is plugged in, but with udev 
> logging set to debug level, the syslog trace is as follows:
> 
> ---
> Nov 26 14:48:27 dgh systemd-udevd[8692]: Process 'mtp-probe
> /sys/devices/pci:00/:00:14.0/usb1/1-3/1-3.1 1 67' succeeded.
> Nov 26 14:48:27 dgh systemd-udevd[8692]: RUN '/usr/bin/virsh attach-device 
> dgw /home/david/udev/david-webcam-dgw.xml' 
> /etc/udev/rules.d/91-dg-webcam-dgw-hotplug.rules:10
> Nov 26 14:48:27 dgh systemd-udevd[8692]: handling device node 
> '/dev/bus/usb/001/067', devnum=c189:66, mode=0664, uid=0, gid=100 Nov 26 
> 14:48:27 dgh systemd-udevd[8692]: set permissions /dev/bus/usb/001/067, 
> 020664, uid=0, gid=100 Nov 26 14:48:27 dgh systemd-udevd[8692]:
> creating symlink '/dev/char/189:66' to '../bus/usb/001/067'
> Nov 26 14:48:27 dgh systemd-udevd[8692]: created db file 
> '/run/udev/data/c189:66' for '/devices/pci:00/:00:14.0/usb1/1-3/1-3.1'
> Nov 26 14:48:27 dgh systemd-udevd[8694]: starting '/usr/bin/virsh 
> attach-device dgw /home/david/udev/david-webcam-dgw.xml'
> Nov 26 14:48:27 dgh libvirtd[3841]: internal error: unable to execute QEMU 
> command 'device_add':
> failed to find host usb device 1:67 Nov 26 14:48:27 dgh systemd-udevd[8692]: 
> '/usr/bin/virsh attach- device dgw 
> /home/david/udev/david-webcam-dgw.xml'(err) 'error: '
> Nov 26 14:48:27 dgh systemd-udevd[8692]: '/usr/bin/virsh attach-device dgw 
> /home/david/udev/david-
> webcam-dgw.xml'(err) 'Failed to attach device from 
> /home/david/udev/david-webcam-dgw.xml'
> Nov 26 14:48:27 dgh systemd-udevd[8692]: '/usr/bin/virsh attach-device dgw 
> /home/david/udev/david-
> webcam-dgw.xml'(err) 'error: internal error: unable to execute QEMU command 
> 'device_add': failed to find host usb device 1:67'
> Nov 26 14:48:27 dgh systemd-udevd[8692]: '/usr/bin/virsh attach-device dgw 
> /home/david/udev/david-
> webcam-dgw.xml'(out) ''
> Nov 26 14:48:27 dgh systemd-udevd[8692]: Process '/usr/bin/virsh 
> attach-device dgw /home/david/udev/david-webcam-dgw.xml' failed with exit 
> code 1.
> ---
> 
> As you can see, the error is that QEMU device_add fails, complaining it 
> cannot find the usb device that was indeed created.
> 
> Additional detail: The above log was generated after the addition of another 
> rules file Thinking it might be a permission problem,I added another rules 
> file 50-myusb.rules as follows:
> ---
> SUBSYSTEMS=="usb", GROUP="users", MODE="0666"
> ---
> but with or without this rules file the error reported is the same.
> 
> Intrestingly, the commands
> 
> virsh attach-devcice dgw /home/david/udev/david-webcam-dgw.xml
> and
> virsh detach-devcice dgw /home/david/udev/david-webcam-dgw.xml
> 
> both work and successfully attach the device to the guest if the device is 
> connected - but the udev script fails.
> 
> USB hotplug on this host was working normally as recently as a couple of 
> months ago; possibly a stretch update caused a regression. As of now, I am 
> unable to make USB hotplug to guests work.
> 
> Thanks so much for looking into this.

I won't have time to look into this, sorry. I suggest to:

* set libvirt debugging to debug
* check which monitor commands get issued to attach the device

Create a new script run from the udev rule that

* checks the necessary device nodes are actually there
* uses the above monitor commands via "virsh qemu-monitor-command"

if it still fails it's within qemu if not there's something broken in
libvirt.

Cheers,
 -- Guido

Bug#845925: autopkgtest customize script for vmdebootstrap is unable to resolve httpredir.debian.org

[Johannes Schauer]

Hi Martin,

Quoting Martin Pitt (2016-11-28 22:31:52)
> Johannes Schauer [2016-11-28 12:15 +]:
> > Can you tell me a way to diagnose the problem as apparently it works fine 
> > for
> > you?

So I put this into the file:

echo $root
cat $root/etc/resolv.conf

And added a -x. With that I got on standard error:

Running customize script /usr/share/autopkgtest/setup-commands/setup-testbed
+ umask 0022
+ [ /tmp/tmpSxHjE2 = --help ]
+ root=/tmp/tmpSxHjE2
+ echo /tmp/tmpSxHjE2
/tmp/tmpSxHjE2
+ cat /tmp/tmpSxHjE2/etc/resolv.conf
cat: /tmp/tmpSxHjE2/etc/resolv.conf: No such file or directory
EEEK! Something bad happened...
Command failed: /usr/share/autopkgtest/setup-commands/setup-testbed 
/tmp/tmpSxHjE2 autopkgtest-sid.raw


Cleaning up
Umounting /tmp/tmpSxHjE2
ERROR: Command failed: /usr/share/autopkgtest/setup-commands/setup-testbed 
/tmp/tmpSxHjE2 autopkgtest-sid.raw


So apparently, there is no /etc/resolv.conf inside the chroot??

cheers, josch


signature.asc
Description: signature

Bug#846141: hint-tester always converts its input to lowercase, meaning you can't use it on package versions with uppercase characters

[Niels Thykier]

Control: tags -1 confirmed

Iain Lane:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: britney
> 
> Ahoy,
> 
> I noticed when using hint-tester on Ubuntu.
> 
>   britney> easy […] dreamchess/0.2.1-RC2-2build1 […]
>   Version mismatch, dreamchess 0.2.1-rc2-2build1 != 0.2.1-RC2-2build1
> 
> The latter is the right version, but my input has been downcased by
> britney.
> 
> Apparently[0] uppercase characters are legal in package versions (and
> even if they weren't this would be a strange place to surface the
> violation). Is there a reason for calling lower() here? Attached a patch
> which just removes that - and makes the hint work for me.
> 
> Cheers,
> 

Hi,

Thanks for catching this. :)

I will include it in one of the coming patch bundles for Britney.

Thanks,
~Niels

Bug#836722: [Pkg-javascript-devel] Bug#836722: Bug#836722: Bug#836722: needs yargs as a dependency

[Pirate Praveen]

On ചൊവ്വ 29 നവംബര്‍ 2016 11:38 രാവിലെ, Jonas Smedegaard wrote:
> How? Please elaborate!
> 
> Checking now with freshly updated unstable+incoming archives and it 
> still fails to satisfy dependencies.

I should have mentioned node-cross-spawn-async 2.2.5-2 (I had drafted
such a mail, but gnome-shell broke on my laptop, so missed that detail
when typed from mobile)

It just took some time for processing after I uploaded
https://tracker.debian.org/news/819919



signature.asc
Description: OpenPGP digital signature

Bug#843941: New upstream release 3.22.0.1 available

[Jörg Frings-Fürst]

Hello Laurent,

first thanks for your offer to sponsor simple-scan.

A new release is uploaded to mentors and my sponsor Adrian is working
on it.



CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#846191: ITP: node-json-stable-stringify -- deterministic JSON.stringify()

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-json-stable-stringify
  Version : 1.0.1
  Upstream Author : James Halliday  (http://substack.net)
* URL : https://github.com/substack/json-stable-stringify
* License : Expat
  Programming Lang: JavaScript
  Description : deterministic JSON.stringify() with custom sorting
to get deterministic hashes from stringified results



signature.asc
Description: OpenPGP digital signature

Bug#846190: RFS: openldap/2.4.44+dfsg-2 [RC]

[Ryan Tandy]

On Mon, Nov 28, 2016 at 10:38:34PM -0800, Ryan Tandy wrote:
It would be nice if whoever sponsors this upload would consider doing 
a source-only upload so that the fix for #846081 can be validated, as 
suggested in that bug.


Meant to say "validated on the buildds"... For avoidance of doubt, I 
have of course tested it locally (dpkg-buildpackage -A/-B). :)

Bug#846190: RFS: openldap/2.4.44+dfsg-2 [RC]

[Ryan Tandy]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor to upload an updated openldap package.

The package can be found on mentors.debian.net:

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

https://mentors.debian.net/debian/pool/main/o/openldap/openldap_2.4.44+dfsg-2.dsc

This upload fixes one RC bug reported against the previous upload: FBTFS 
with dpkg-buildpackage -A (#846081/#845506). I also applied a patch 
related to cross-building (#839251) and resolved or silenced several 
(sadly not yet all) lintian issues.


It would be nice if whoever sponsors this upload would consider doing a 
source-only upload so that the fix for #846081 can be validated, as 
suggested in that bug.


Changes since 2.4.44+dfsg-1:

 [ Ryan Tandy ]
 * Update Standards-Version to 3.9.8; no changes required.
 * Enable dh_makeshlibs for libldap-2.4-2. Remove libldap-2.4-2.postinst, now
   replaced by the automatic ldconfig trigger.
 * Don't execute slapd's override_dh_install when building only
   arch-independent packages. (Closes: #845506)
 * Override lintian false positives on slapd.README.Debian,
   slapd-smbk5pwd.postinst, and slapd-smbk5pwd triggering ldconfig.
 * Perform permissions changes in override_dh_fixperms instead of in
   override_dh_install.
 * Remove manual chmod of schema files since dh_fixperms sets correct
   permissions automatically.

 [ Helmut Grohne ]
 * Fix FTCBFS: Pass CC to make explicitly. (Closes: #839251)

The full history can be found in the git repository:

https://anonscm.debian.org/git/pkg-openldap/openldap.git

thanks,
Ryan

Bug#845614: RFS: acorn/4.0.3-1

[Julien Puydt]

Hi,

On 25/11/2016 20:02, Gianfranco Costamagna wrote:

http://debomatic-amd64.debian.net/distribution#unstable/acorn/4.0.3-1/buildlog

FTBFS


Can you get the sources from mentors anew? I checked again and it 
compiled perfectly from git (and Pirate Praveen tried it too 
successfully), so I removed from mentors and re-uploaded.


It's strange : amd64 is precisely what I have here, so if my pbuilder 
was happy... why isn't debomatic?


Thanks,

Snark on #debian-js

Bug#846188: python-distro: Missing depends on lsb-release

[Scott Kitterman]

Package: python-distro
Version: 1.0.1-1
Severity: grave
Justification: renders package unusable

The package popens lsb_release, so it's essentially unusable without
lsb-release.

Scott K

Bug#846189: RM: pgrouting [mips mips64el mipsel] -- ROM; Blocking removal of postgis

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
Control: block 846187 by -1

Please remove pgrouting from mips* to unblock the removal of postgis.

Kind Regards,

Bas

Bug#846187: RM: postgis [mips mips64el mipsel] -- ROM; Cannot be built due to #844357, blocking testing migration

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove postgis from mips*, it cannot be built there due to
#844357 and the missing binaries will block testing migration.

Kind Regards,

Bas

Bug#836722: [Pkg-javascript-devel] Bug#836722: Bug#836722: needs yargs as a dependency

[Jonas Smedegaard]

[re-adding bugreport]]

Quoting Pirate Praveen (2016-11-29 06:56:23)
> On 2016, നവംബർ 29 10:05:58 AM IST, Jonas Smedegaard  wrote:
>>Cannot build the new uglifyjs until bug#846076 is resolved.
> 
> This is now fixed.

How? Please elaborate!

Checking now with freshly updated unstable+incoming archives and it 
still fails to satisfy dependencies.


 - Jonas

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

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

Bug#845082: (no subject)

[Graham Inggs]

On 29 November 2016 at 00:29, Breno Leitao  wrote:
> We just created a pull request to have this fixed upstream.

Thanks!

> Should we create a Debian patch also?

This bug is tagged 'pending' and there's already a patch in the
packaging git [1].
I did notice the patch uses round() while your PR uses llround().
Antonio, should that be changed?


[1] 
https://anonscm.debian.org/cgit/debian-science/packages/numexpr.git/commit/?id=5c1edd14c6cf8f1258514faca2010380be75bb37

Bug#846178: Bug#811310: Removal of jade

[Dr. Tobias Quathamer]

Am 29. November 2016 02:25:39 MEZ, schrieb Neil Roeth :
>On 11/26/2016 02:21 PM, Dr. Tobias Quathamer wrote:
>> Dear Neil,
>>
>> I've cleaned up the list of bugs which prevented the removal of jade,
>> because I'd like to get Debian into shape before the near freeze.
>>
>> To my understanding, the only package left for jade is kannel, which
>> has an RC bug (#828362) and will be auto-removed from testing on
>> 2016-12-25. Therefore, jade could be removed without affecting
>kannel.
>>
>> Are you going to file the removal bug then, or should I take care of
>> that?
>>
>> Regards,
>> Tobias
>>
>Thanks, Tobias.  I created removal bug 846178 for jade.  The jade
>source
>package builds both the jade and sp binary packages and I mentioned
>that
>in the bug report.  Do I need to create a separate removal bug for each
>binary package or is that one bug sufficient to enable the ftp masters
>to remove everything that is built by that source package?

Hi Neil,

one bug should be enough. It might be good  to mention both removal tracking 
bugs:

#811310
#811312

For more  context for FTP-Masters. Done that now.

Regards,
Tobias

Bug#846168: [pkg-gnupg-maint] Bug#846168: gnupg2: --export-ssh-key is not working

[NIIBE Yutaka]

On 11/29/2016 06:46 AM, Hans Freitag wrote:
> Exporting ssh2 keys is not working with gnupg 2.1.16
> 
> $ gpg2 --export-ssh-key SOMEKEYID
> gpg: O j: Assertion "ret_found_key == NULL || ret_keyblock != NULL" 
> in lookup failed (../../g10/getkey.c:3677)
> Abgebrochen

Thank you for bug report.  It is just fixed in upstream yesterday.

commit 4db9a425644dccaf81b51ebc97b32a9cc21941a4
Author: Justus Winter 
Date:   Mon Nov 28 13:36:56 2016 +0100

g10: Fix iteration over getkey results.

* g10/getkey.c (getkey_next): Only ask 'lookup' for the exact match if
our caller requested the key.  Fixes a crash in 'lookup'.

GnuPG-bug-id: 2848
Fixes-commit: 1d03cc77e1706f7da653153ad4b58c61e4fd2573
Signed-off-by: Justus Winter 

-- 

Bug#836722: [Pkg-javascript-devel] Bug#836722: Bug#836722: needs yargs as a dependency

[Pirate Praveen]

On 2016, നവംബർ 29 10:05:58 AM IST, Jonas Smedegaard  wrote:

>Cannot build the new uglifyjs until bug#846076 is resolved.

This is now fixed.

Bug#831032: pptp-linux: Please update patches and packaging

[James Cameron]

Everything beautiful was merged and released in pptp-1.9.0

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

Bug#846186: RM: ruby-rails-autolink: ROM; rc-buggy, no rdepends

[Pirate Praveen]

package: ftp.debian.org

This was packaged for diaspora, which does not depend on it anymore.
Please remove.



signature.asc
Description: OpenPGP digital signature

Bug#846185: ITP: ixo-usb-jtag -- Firmware for USB JTAG programmers

[Stefano Rivera]

Package: wnpp
Severity: wishlist
Owner: Stefano Rivera 

* Package name: ixo-usb-jtag
  Version : 0.0.0+git20160908
  Upstream Author : Tim 'mithro' Ansell 
* URL : https://github.com/mithro/ixo-usb-jtag
* License : GPL-2+
  Programming Lang: C
  Description : Firmware for USB JTAG programmers

This firmware allows a USB-capable microcontroller to act like an Altera
USB-Blaster JTAG pod. Which in turn may allow you to use tools you'd
normally use with the Altera USB-Blaster, including UrJTAG and openocd.

Supported hardware: The Cypress FX2 EZ-USB family, or an FTDI FT245 in
combination with a CPLD. Builds are included for the hdmi2usb project's
boards (Digilet Atlys and Numato Opsis).

Bug#836722: [Pkg-javascript-devel] Bug#836722: Bug#836722: needs yargs as a dependency

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2016-11-29 05:26:39)
> Seems to me that a simple chmod command is the right thing to use.  I 
> do that now, and try release the package - but you are quite welcome 
> to suggest other approaches, or adapt the package yourself.

Cannot build the new uglifyjs until bug#846076 is resolved.

 - Jonas

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

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

Bug#836722: [Pkg-javascript-devel] Bug#836722: Bug#836722: needs yargs as a dependency

[Jonas Smedegaard]

Quoting Pirate Praveen (2016-11-28 11:32:00)
> Control: block -1 by 846076
> 
> On Sun, 27 Nov 2016 14:08:15 +0530 Pirate Praveen 
> wrote:
> > yargs is in NEW and we can upload a new version once it is accepted.
> > 
> Hi Jonas,
> 
> I have prepared the package in git and it is almost ready for upload.
> Can you review and fix these two warnings and upload it?
> 
> W: node-uglify: manpage-has-useless-whatis-entry
> usr/share/man/man1/uglifyjs.1.gz
> W: node-uglify: script-not-executable
> usr/lib/nodejs/uglify-js/bin/extract-props.js
> 
> I'm not too familiar with cdbs, on plain debhelper I could use dh_fixperms

CDBS runs dh_fixperms.  This line in dbian/rules instructs dh_fixparms 
to skip nodejs library path, if that is what you wanted to do:

DEB_FIXPERMS_EXCLUDE_node-uglify = usr/lib/nodejs

I don't follow how dh_fixperms is relevant here, however: I believe 
dh_fixperms can only be told to _skip_ fixing some permissions, not be 
educated to e.g. treat /usr/lib/* same as /usr/bin.

Seems to me that a simple chmod command is the right thing to use.  I do 
that now, and try release the package - but you are quite welcome to 
suggest other approaches, or adapt the package yourself.

Thanks for all your great work!


 - Jonas

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

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

Bug#843210: closed by Matthias Klose <d...@debian.org> (not reproducible anymore)

[Guillem Jover]

Control: reopen -1
Control: notfixed -1 2.27.51.20161124-1
Control: found -1 2.27.51.20161127-1

On Sun, 2016-11-27 at 12:57:12 +, Debian Bug Tracking System wrote:
> Date: Sun, 27 Nov 2016 13:54:52 +0100
> From: Matthias Klose 
> To: 843210-d...@bugs.debian.org
> Subject: not reproducible anymore
> Message-ID: <89733d51-9469-8e34-cc6a-0a5afbf30...@debian.org>
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
>  Thunderbird/45.4.0
> X-Spam-Status: No, score=-6.8 required=4.0 tests=BAYES_00,FROMDEVELOPER,
>  RCVD_IN_DNSWL_LOW,TVD_SPACE_RATIO,VERSION autolearn=ham autolearn_force=no
>  version=3.4.0-bugs.debian.org_2005_01_02
> 
> Version: 2.27.51.20161124-1
> 
> not reproducible anymore.

I can still reproduce it with the provided recipe. I've encoded it now
into a shell script to make it easier to test in the future. Here's
the current output of the command:

  ,---
  $ ./test.sh
  diversion by binutils-multiarch from: /usr/bin/x86_64-linux-gnu-ar
  diversion by binutils-multiarch to: /usr/bin/x86_64-linux-gnu-ar.single
  binutils-multiarch, binutils: /usr/bin/x86_64-linux-gnu-ar
  diversion by binutils-multiarch from: /usr/bin/x86_64-linux-gnu-ranlib
  diversion by binutils-multiarch to: /usr/bin/x86_64-linux-gnu-ranlib.single
  binutils-multiarch, binutils: /usr/bin/x86_64-linux-gnu-ranlib
  binutils2.27.51.20161127-1
  binutils-multiarch  2.27.51.20161127-1
  ar: creating libtest-1.a
  8492849dadb7ee31912b2a7bd79d4206  libtest-1.a
  ar: creating libtest-2.a
  8492849dadb7ee31912b2a7bd79d4206  libtest-2.a
  0e0204da97014373201f8f56b67a064d  libtest-3.a
  9b5b260bd9e951c19e0c5decdc118571  libtest-4.a
  c83d71bfc4638b108569a1c0ec3b7d80  libtest-5.a
  Artifacts in /tmp/ar-test.3MJz28TuWA
  `---

Thanks,
Guillem


test.sh
Description: Bourne shell script

Bug#846184: binutils-mingw-w64: Inconsistent with other cross packages

[Ben Longbons]

Package: binutils-mingw-w64
Version: 2.27.51.20161105-2+7.2
Severity: wishlist

Dear Maintainer,

To be consistent with other binutils-$cross packages:

* the packages should be named according to the triple
(binutils-i686-w64-mingw32 and binutils-x86-64-w64-mingw32 - note that
underscore is not valid in package names so it is replace with dash)

* Symlinks should be placed in /usr/$triple/bin
(This is important to support tools that only know how to look
for `ld` and `as` in another PATH, common among non-C cross-compilers)


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

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

Versions of packages binutils-mingw-w64 depends on:
ii  binutils-mingw-w64-i6862.27.51.20161105-2+7.2
ii  binutils-mingw-w64-x86-64  2.27.51.20161105-2+7.2

binutils-mingw-w64 recommends no packages.

binutils-mingw-w64 suggests no packages.

-- no debconf information

Bug#846183: vim package fails to build with dh_strip error "unknown option: dbgsym-migration"

[David Barnett]

Package: vim
Version: 8.0.0095-1

When I try to build the v8.0.0095-1 tag from
https://anonscm.debian.org/cgit/pkg-vim/vim.git using pbuilder, I get an
error from the dh_strip command: "unknown option: dbgsym-migration".

The issue seems to be that
https://anonscm.debian.org/cgit/pkg-vim/vim.git/commit/?id=cf485aa6 never
updated the debian/control file with debhelper (>= 9.20160114) as the
instructions at https://wiki.debian.org/AutomaticDebugPackages recommend,
and debhelper >= 9.20160114 isn't satisfiable in my environment.

David

Bug#846182: reportbug: Wrong package version detected when it contains a +

[Ben Longbons]

Package: reportbug
Version: 6.6.6
Severity: normal

Dear Maintainer,

While reporting a bug against binutils-mingw-w64, `reportbug` claimed it
was out-of-date:


Getting status for binutils-mingw-w64...
Checking for newer versions at madison...

Your version (2.27.51.20161105-2+7.2) of binutils-mingw-w64 appears to be out 
of date.
The following newer release(s) are available in the Debian archive:
  stable: 5.2+deb8u1
  testing: 7.2
  unstable: 7.2


But from ,
the available versions should be:

oldstable: 2.22-8+deb7u2+2+deb7u1
stable: 2.25-5+5.2+deb8u1
testing: 2.27.51.20161105-2+7.2
unstable: 2.27.51.20161105-2+7.2


-- Package-specific info:
** Environment settings:
PAGER="less"
INTERFACE="text"

** /home/ben/.reportbugrc:
reportbug_version "5.1.1"
mode standard
ui text
email "brlongb...@gmail.com"
smtphost smtp.gmail.com:587
smtpuser "brlongb...@gmail.com"
smtptls

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

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

Versions of packages reportbug depends on:
ii  apt   1.3.1
ii  python-reportbug  6.6.6
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4  4.88~RC4-2
ii  exim4-daemon-light [mail-transport-agent]  4.88~RC4-2
ii  file   1:5.29-1
ii  gnupg  2.1.16-2
ii  python-gtk22.24.0-5.1
pn  python-gtkspellcheck   
ii  python-urwid   1.3.1-2+b1
ii  python-vte 1:0.28.2-5+b1
ii  xdg-utils  1.1.1-1

Versions of packages python-reportbug depends on:
ii  apt   1.3.1
ii  file  1:5.29-1
ii  python-debian 0.1.29
ii  python-debianbts  2.6.1
pn  python:any

python-reportbug suggests no packages.

-- no debconf information

Bug#846181: The version of virtualbox-ext-pack doesn't sync to virtualbox

[Chang, MingDien]

Package: virtualbox-ext-pack
Version: 5.1.8-1
Severity: grave

After apt update in stretch(testing), the virtualbox related packages are
upgraded to 5.1.10, except the virtualbox-ext-pack which is still 5.1.8, and
failed to open sessions of vms with the messages:
The device helper structure version has changed.
If you have upgraded VirtualBox recently, please make sure you have terminated
all VMs and upgraded any extension packs. If this error persists, try re-
installing VirtualBox. (VERR_PDM_DEVHLPR3_VERSION_MISMATCH).



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

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

Versions of packages virtualbox-ext-pack depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  virtualbox 5.1.10-dfsg-1
ii  wget   1.18-4

virtualbox-ext-pack recommends no packages.

virtualbox-ext-pack suggests no packages.

-- debconf information:
* virtualbox-ext-pack/license: true

Bug#845456: Please add a udeb to ca-certificates

[Michael Shuler]

Thanks for the patches to enable the use of HTTPS in the installer. This
does sound useful. (And apologies for the holiday delay in replying.)

I'd like to complete a pending stable upload, first, then I'll work on
this request.

-- 
Kind regards,
Michael

Bug#846157: compile fails

[Ben Hutchings]

Control: reassign -1 src:linux 4.8.7-1
Control: forcemerge 841368 -1

On Mon, 2016-11-28 at 13:43 -0600, Brent S. Elmer wrote:
> Package: linux-source-4.8
> Version: 4.8.7-1
> Severity: normal
> 
> I am trying to compile a 4.8 kernel and it is failing.
[...]

This is a bug in Debian's package of gcc-6, but we will work around it
in the kernel source.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
- John Levine, moderator of
comp.compilers


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

Bug#846180: gitlab not restarted after redis-server upgrade

[Jason Rhinelander]

Package: gitlab
Version: 8.13.6+dfsg1-2
Severity: normal

Dear Maintainer,

I just installed an upgraded version of redis-server (but not of gitlab 
itself), and after the upgrade gitlab was no longer running.  The 
following reproduces this easily for me:



$ for i in "" -mailroom -sidekiq -unicorn -workhorse; do
  s=gitlab$i; echo $s; sudo service $s status | grep Active; done

gitlab
   Active: active (exited) since Mon 2016-11-28 21:06:38 EST; 3s ago
gitlab-mailroom
   Active: active (running) since Mon 2016-11-28 21:06:26 EST; 15s ago
gitlab-sidekiq
   Active: active (running) since Mon 2016-11-28 21:06:38 EST; 3s ago
gitlab-unicorn
   Active: active (running) since Mon 2016-11-28 21:06:26 EST; 15s ago
gitlab-workhorse
   Active: active (running) since Mon 2016-11-28 21:06:26 EST; 15s ago



$ sudo apt-get install redis-server --reinstall

Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not 
upgraded.

Need to get 0 B/407 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 253802 files and directories currently installed.)
Preparing to unpack .../redis-server_3%3a3.2.5-2_amd64.deb ...
Unpacking redis-server (3:3.2.5-2) over (3:3.2.5-2) ...
Processing triggers for systemd (232-6) ...
Processing triggers for man-db (2.7.5-2) ...
Setting up redis-server (3:3.2.5-2) ...



$ for i in "" -mailroom -sidekiq -unicorn -workhorse; do
  s=gitlab$i; echo $s; sudo service $s status | grep Active; done

gitlab
   Active: inactive (dead) since Mon 2016-11-28 21:06:49 EST; 13s ago
gitlab-mailroom
   Active: inactive (dead) since Mon 2016-11-28 21:06:50 EST; 13s ago
gitlab-sidekiq
   Active: inactive (dead) since Mon 2016-11-28 21:06:52 EST; 10s ago
gitlab-unicorn
   Active: inactive (dead) since Mon 2016-11-28 21:06:50 EST; 12s ago
gitlab-workhorse
   Active: inactive (dead) since Mon 2016-11-28 21:06:49 EST; 13s ago



I have no idea whether this is something wrong in the gitlab service 
files, something wrong in redis-server, or something elsewhere (e.g. in 
debhelper's scripts for restarting on upgrade).



Jason Rhinelander

Bug#845803: [pkg-gnupg-maint] Bug#845803: src:gpgme1.0: please consider reducing priority of -dev packages

[Daniel Kahn Gillmor]

Control: tags 845803 + confirmed

On Sat 2016-11-26 15:16:06 -0500, Ryan Tandy wrote:
> Package: src:gpgme1.0
> Version: 1.8.0-2
> Severity: normal
>
> Today I noticed that "aptitude install ~pstandard" pulls in many more 
> packages than it used to. A significant part of this seems to be 
> transitive Depends of libgpgmepp-dev, via qtbase5-dev.
>
> It looks like Priority: standard is set for the entire gpgme1.0 source 
> package (all binaries). Please consider reducing the priority of the 
> binary packages that are not dependencies of other Priority: standard 
> packages (at least the -dev and -doc packages).

You're absolutely right, sorry about this.  I'm not convinced that any
of the gpgme packages need to be priority: standard, in fact.

Looking at the revision control history, this was bumped from "optional"
to "standard" back in 2013 in response to a request from the mutt
maintainer: https://bugs.debian.org/623353

however, mutt is today priority: optional itself, so i'm going to bump
all of gpgme back down to "optional" (and its -dev packages down to
"extra") in the next release.

Thank you for catching this and reporting it, Ryan.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#846179: gitlab: Use notify on ready under systemd instead of hack with sleep + check commandline

[Jason Rhinelander]

Package: gitlab
Version: 8.13.6+dfsg1-2
Severity: normal

Dear Maintainer,

The current systemd service file for gitlab-sidekiq contains a hack to 
delay the systemd service startup until sidekiq is actually ready by 
sleeping for up to 32 seconds (in increments of 4 seconds) until 
sidekiq's cmdline changes.


Besides being an unpleasant hack, and potentially ending too early (e.g. 
if sidekiq takes more than 32 seconds to start up on a slow/loaded 
machine), this also has the unfortunate consequence of showing this 
command forever in the service status output, and of making the service 
take up to 4 seconds longer than necessary to actually be registered as 
started.


We can do much better by performing a proper systemd notify, as follows 
(I've tested this locally, and it works properly):



1. Patch the installed /etc/gitlab/initializers/sidekiq.rb to add, near 
the top of the configure_server function:



  if ((socket_path = ENV["NOTIFY_SOCKET"]))
config.on(:startup) do
  notify_socket = Socket.new(Socket::AF_UNIX, Socket::SOCK_DGRAM, 0)
  notify_socket.connect(Socket.sockaddr_un(socket_path))
  notify_socket.sendmsg "READY=1", Socket::MSG_NOSIGNAL
end
  end


2. change the gitlab-sidekiq.service file to contain:

Type=notify

and delete the ExecStartPost= line.



Then we get proper notification support: notification happens 
immediately upon sidekiq being ready, the hack is gone, and the job 
starts faster.



Jason Rhinelander



smime.p7s
Description: S/MIME Cryptographic Signature

Bug#845498: [Pkg-pascal-devel] Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Ben Longbons]

On Mon, Nov 28, 2016 at 12:19 AM, Abou Al Montacir
 wrote:
> For now you can use multi-arch to install fp-compiler

No, you can't (that was the first thing I thought of):
fp-compiler:i386 depends on binutils:i386 rather than
binutils-i586-linux-gnu, and binutils:i386 isn't multiarch
installable. You'd have to do a full cross chroot, currently.

But once the dependency part is fixed, /etc/fpc.cfg can `#INCLUDE
/etc/fpc/$FPCTARGET.cfg` and put `-e/usr/i586-linux-gnu/bin
-Fl/usr/lib/i386-linux-gnu -Fl/lib/i386-linux-gnu -Fl /usr/lib32
-Fl/lib32` in there (each of those .cfg files will have to be manually
written/installed based on the Debian arch (of the fp-compiler
package), the Debian triple (subdir of /usr/lib), the legacy libdir
(/lib32 - actually not sure if this is necessary or not anymore), the
GNU triple (of binutils), and the FPC target (for choice of the
filename)). Incidentally, managing /etc/fpc.cfg through
update-alternatives is a waste since it could be implemented as just
`#INCLUDE /etc/fpc-$fpcversion.cfg` (though since jessie has 2.6.4, an
appropriate upgrade path would need to be written).

The above is fairly trivial and will get you a multiarch "cross"
compiler, with /etc/ ready for real (non-multiarch fp-compiler (I
*think* the libc6-*-cross packages are only needed because of ld.so
conflicting. but fp-units-* are actually multiarch safe already,
they're just not marked as such - they put all their files in
/usr/lib/fpc/$fpcversion/{units,fpmkinst}/$FPCTARGET/ already)) ones.
Then it's just a SMOC to actually build real cross-compilers binary
packages from the Debian source package.

I should probably write a tool to hack-up what I've described above by
using `apt-get download` and extracting/modifying the .deb files.
Maybe test it on Jessie since it has backports to test multiple
*versions* too.

> then just use a shell script to call call the right FPC using qemu

The shell script is unnecessary if you install qemu-user-binfmt (or
qemu-user-static, which `Provides:` it).

-Ben

Bug#846165: .../.ssh/config line 127: Bad protocol spec '1'.

[Russ Allbery]

Robert de Bath  writes:

> Package: ssh
> Version: 1:7.3p1-3

> This error occurs whatever I attempt to connect to, even though the
> particular stanza of the config as nothing to do with the host I'm
> connecting to. It is obviously inefficient and much too aggressive.

> I obviously still have a use for v1 as there isn't an ssh v2 sufficiently
> portable to install on the machine in question.

Per /usr/share/doc/openssh-client/NEWS.Debian.gz (which apt-listchanges
would show to you automatically):

openssh (1:7.1p1-2) unstable; urgency=medium

  OpenSSH 7.0 disables several pieces of weak, legacy, and/or unsafe
  cryptography.

   * Support for the legacy SSH version 1 protocol is disabled by default at
 compile time.  Note that this also means that the Cipher keyword in
 ssh_config(5) is effectively no longer usable; use Ciphers instead for
 protocol 2.  The openssh-client-ssh1 package includes "ssh1", "scp1",
 and "ssh-keygen1" binaries which you can use if you have no alternative
 way to connect to an outdated SSH1-only server; please contact the
 server administrator or system vendor in such cases and ask them to
 upgrade.
[...]

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

Bug#843832: needrestart: detect need for a systemctl daemon-reload

[Paul Wise]

On Mon, 2016-11-28 at 21:17 +0100, Thomas Liske wrote:

> Configuration files etc. are beyond the scope of needrestart

Ok, fair enough.

> there should be a mechanism around apt to handle reloading systemd

There already is for system services but not user services.

systemctl will report when daemon-reload is needed when restarting things.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#846178: ftp.debian.org: RM: jade -- ROM; obsolete, replaced by openjade and opensp

[Neil Roeth]

Package: ftp.debian.org
Severity: normal

Please remove the jade source package from which the jade and sp binary
packages are built.  They are obsolete and there are replacements
already in Debian, openjade and opensp.

-- 
Neil Roeth

Bug#846177: A rustc-src package would be useful for racer completion

[Dato Simó]

Source: rustc
Severity: wishlist

It would be nice to have a rustc-src package containing the source
for Rust itself.

The (widely-used) racer completion engine needs access to the
source in order to work.

There is precedent for this, for example Go provides a golang-src
package.

I don't think that the racer dependency on the source code is
going away any time soon — though if it were, that would be a
reason not to introduce a source package.

Thanks for considering,

-d

Bug#825487: [Piuparts-devel] Bug#825487: Another situation where this change would help

[Holger Levsen]

Hi Sean,

thanks for pinging this bug, I'll try to reply soon…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#845648: [debian-mysql] Bug#845648: mention how to deal with Pre-4.1 password hash found. It is deprecated and will be removed in a future release. Please upgrade it to a new format warning

[積丹尼 Dan Jacobson]

Now I got as far as

echo "ALTER USER 'wikiuser'@'localhost.localdomain' IDENTIFIED BY 
'-[censored]-';"|mysql --user=root --password=-[censored]-; sleep 1
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1396 (HY000) at line 1: Operation ALTER USER failed for 
'wikiuser'@'localhost.localdomain'
echo "ALTER USER 'jidanni'@'%' IDENTIFIED BY '-[censored]-';"|mysql --user=root 
--password=-[censored]-; sleep 1
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1396 (HY000) at line 1: Operation ALTER USER failed for 'jidanni'@'%'

By the way nothing is written to /var/log/mysql*(/*) these days.

But I noticed these:

# journalctl -f&
# service mysql start
11月 29 08:34:42 jidanni2 systemd[1]: Accepted new private connection.
11月 29 08:34:42 jidanni2 systemd[1]: Got message type=method_call sender=n/a 
destination=org.freedesktop.systemd1 object=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=GetUnit cookie=1 
reply_cookie=0 error=n/a
11月 29 08:34:42 jidanni2 systemd[1]: Sent message type=method_return sender=n/a 
destination=n/a object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 
error=n/a
11月 29 08:34:42 jidanni2 systemd[1]: Got message type=method_call sender=n/a 
destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1/unit/multi_2duser_2etarget 
interface=org.freedesktop.DBus.Properties member=Get cookie=2 reply_cookie=0 
error=n/a
11月 29 08:34:42 jidanni2 systemd[1]: Sent message type=method_return sender=n/a 
destination=n/a object=n/a interface=n/a member=n/a cookie=2 reply_cookie=2 
error=n/a
11月 29 08:34:42 jidanni2 systemd[1]: Got disconnect on private connection.
11月 29 08:34:42 jidanni2 systemd[1]: Accepted new private connection.
11月 29 08:34:42 jidanni2 systemd[1]: Got message type=method_call sender=n/a 
destination=org.freedesktop.systemd1 object=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=ListUnitFilesByPatterns 
cookie=1 reply_cookie=0 error=n/a
11月 29 08:34:43 jidanni2 systemd[1]: Sent message type=method_return sender=n/a 
destination=n/a object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 
error=n/a
11月 29 08:34:43 jidanni2 systemd[1]: Got disconnect on private connection.
11月 29 08:34:44 jidanni2 systemd-logind[414]: Got message type=signal 
sender=:1.0 destination=n/a object=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=UnitRemoved cookie=7043 
reply_cookie=0 error=n/a
11月 29 08:34:44 jidanni2 systemd-logind[414]: Got message type=signal 
sender=:1.0 destination=n/a object=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=UnitRemoved cookie=7045 
reply_cookie=0 error=n/a
11月 29 08:34:44 jidanni2 systemd-logind[414]: Got message type=signal 
sender=:1.0 destination=n/a object=/org/freedesktop/systemd1 
interface=org.freedesktop.systemd1.Manager member=UnitRemoved cookie=7047 
reply_cookie=0 error=n/a
11月 29 08:34:44 jidanni2 systemd-logind[414]: Got message type=signal 
sender=:1.0 destination=n/a 
object=/org/freedesktop/systemd1/unit/mysql_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=7049 
reply_cookie=0 error=n/a
11月 29 08:34:44 jidanni2 systemd-logind[414]: Got message type=signal 
sender=:1.0 destination=n/a 
object=/org/freedesktop/systemd1/unit/mysql_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=7050 
reply_cookie=0 error=n/a
11月 29 08:34:44 jidanni2 systemd-logind[414]: Got message type=signal 
sender=:1.0 destination=n/a object=/org/freedesktop/systemd1/job/919 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=7051 
reply_cookie=0 error=n/a
11月 29 08:34:44 jidanni2 systemd[26148]: mysql.service: Executing: 
/usr/share/mysql/mysql-systemd-start pre
11月 29 08:34:44 jidanni2 systemd-logind[414]: Got message type=signal 
sender=:1.0 destination=n/a 
object=/org/freedesktop/systemd1/unit/mysql_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=7052 
reply_cookie=0 error=n/a
11月 29 08:34:44 jidanni2 systemd-logind[414]: Got message type=signal 
sender=:1.0 destination=n/a 
object=/org/freedesktop/systemd1/unit/mysql_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=7053 
reply_cookie=0 error=n/a
11月 29 08:34:44 jidanni2 systemd-logind[414]: Got message type=signal 
sender=:1.0 destination=n/a 
object=/org/freedesktop/systemd1/unit/mysql_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=7054 
reply_cookie=0 error=n/a
11月 29 08:34:44 jidanni2 systemd-logind[414]: Got message type=signal 
sender=:1.0 destination=n/a 
object=/org/freedesktop/systemd1/unit/mysql_2eservice 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=7055 
reply_cookie=0 error=n/a
11月 29 08:34:44 jidanni2 mysqld[26154]: mysql.service: Executing: 
/usr/sbin/mysqld
11月 29 

Bug#844473: Update nginx module nchan to 1.0.6

[nobody]

The latest version of Nchan is now 1.0.8. I've updated the debian build,
you can pull it from https://github.com/slact/nginx-deb

Changes since 1.0.6:

1.0.8 (Nov. 28 2016)
 fix: possible crash under severely heavy load, introduced in 1.0.7 with
stack-overflow fix
1.0.7 (Nov. 27 2016)
 fix: memory leak after websocket publisher uncleanly aborts connection
 fix: misbehaving websocket publisher with nchan_publisher_upstream_request
 fix: potential stack overflow with very large message buffers
 fix: invalid memory access with empty nchan_publisher_upstream_request
for websocket publisher
 fix: incorrect handling of chunked response from
nchan_publisher_upstream_request
 fix: publishing through websocket too fast may result in buffered
messages that never arrive
 fix: DELETE to multiplexed channel should delete all listed channels
 fix: abort if publishing to multiple channels while using redis


j...@slact.net:
> Package: nginx
> Version: 1.10.2-2
> 
> I'm the author of Nchan and I've released a new version with some
> important bugfixes, security fixes, and new features. It would be nice
> if the Nginx package could be updated to the latest version, 1.0.6
> 
> https://nchan.slact.net/changelog
> 
> Changes since 1.0.2 (current version in the Debian package):
> 
> 1.0.6 (Nov. 15 2016)
>  fix: large messages were sometimes incorrectly cleaned up, leaving
> behind temp files
>  fix: file descriptor leak when listening on a unix socket and suddenly
> aborting client connections
>  fix: invalid memory access after reloading twice with redis enabled
>  fix: crash after shutting down nginx when 'master_process' set to 'off'
>  change: nchan_max_channel_subscribers now always refers to subscribers
> on this instance of Nchan, even when using Redis.
>  feature: subscribe/unsubscribe callbacks with nchan_subscribe_request
> and nchan_unsubscribe_request
> 1.0.4 (Oct. 28 2016)
>  security: fix crash when receiving large messages over websocket with
> ws+nchan subprotocol
> 1.0.3 (Sept. 3 2016)
>  feature: nchan_message_timeout and nchan_message_buffer_length can now
> use nginx variables for dynamic values
>  fix: unsolicited websocket PONGs disconnected the subscriber in
> violation of RFC6455
>  fix: possible script error when getting channel from Redis
>  fix: possible incorrect message IDs when using Redis (thanks @supertong)
>  security: possible invalid memory access on publisher GET, POST, or
> DELETE when using Redis and the publisher connection is terminated
> before receiving a response
>  fix: correct publisher response code when nchan_authorize_request is
> unavailable (502 instead of 500)
>  security: crash if publisher POSTs request with no Content-Length
> header when using nchan_authorize_request
> 
> https://nchan.slact.net/
> 
> Thanks,
>Leo P.
> 

Bug#804225: postfix: Upgraded my system today and postfix fails to install via apt-get. Tried running postinst manually and no errors are showing. Nothing usefull in the logs that I can see when deb

[Scott Kitterman]

On Fri, 06 Nov 2015 11:59:50 + zarren  wrote:
> Package: postfix
> Version: 2.11.3-1+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> Tried t a dist upgrade on my system today and postfix fails to install with 
the following output.

...

What release are you on?  That version is the stable version, but the bug says 
your apt prefers unstable:

Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')

Upgrading to the latest 3.1.0-4 should work.  If you are still having problems 
after trying that, please provide more logs.

Scott K

Bug#844804: Cannot reproduce

[Jordi Mallach]

severity 844804 important
tags 844804 + unreproducible
thanks

Hi Lucas,

I'm taking the liberty to lower the severity of this bug, as I can't reproduce
on a current sid pbuilder chroot.

I am thinking this might have been caused by the openssl mess, etc.

libsnmp-dev is definitely installable here, and my build succeeds:
dpkg-deb: building package 'zabbix-server-pgsql' in 
'../zabbix-server-pgsql_3.0.5+dfsg-1_amd64.deb'.

If you could revisit this bug and close if you think it was a transient
uninstallability problem, please go ahead.

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer http://www.debian.org/
jo...@sindominio.net jo...@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/


signature.asc
Description: PGP signature

Bug#845996: needrestart: Restarts lxdm by default

[Rodrigo Campos]

On Sun, Nov 27, 2016 at 05:45:24PM +0100, Thomas Liske wrote:
> 
> Hi Rodrigo,
> 
> Rodrigo Campos  writes:
> > I'm using lxdm display manager and needrestart tries to restart it by 
> > default,
> > instead of being disabled by default as it is with others DM.
> 
> I've added an override to the default configuration at upstream[1]. Thanks
> for reporting.
> 
> [1] 
> https://github.com/liske/needrestart/commit/2bf61d8f65a03fb6ecec2ddbb16e27100ba04c40

Thank you! :)

Bug#841133: ruby-gruff: FTBFS: Tests hang after segmentation fault

[Gunnar Wolf]

Package: ruby-gruff
Version: 0.6.0-1
Followup-For: Bug #841133

This bug does not only happen at build time, it makes Gruff completely
unusable :-(

$ irb
>> require 'gruff'
=> true
>> g=Gruff::Bar.new '100x100'
/usr/lib/ruby/vendor_ruby/gruff/base.rb:968: [BUG] Segmentation fault at 
0x18
ruby 2.3.1p112 (2016-04-26) [x86_64-linux-gnu]

-- Control frame information ---
c:0024 p: s:0095 e:94 CFUNC  :initialize
c:0023 p: s:0093 e:92 CFUNC  :new
c:0022 p:0034 s:0090 e:89 METHOD /usr/lib/ruby/vendor_ruby/gruff/base.rb:968
c:0021 p:0103 s:0087 e:86 METHOD /usr/lib/ruby/vendor_ruby/gruff/base.rb:230
c:0020 p:0012 s:0081 e:80 METHOD /usr/lib/ruby/vendor_ruby/gruff/bar.rb:10 
[FINISH]
c:0019 p: s:0077 e:76 CFUNC  :new
c:0018 p:0016 s:0073 E:0023a8 EVAL   (irb):2 [FINISH]
c:0017 p: s:0070 e:69 CFUNC  :eval
c:0016 p:0025 s:0063 e:62 METHOD /usr/lib/ruby/2.3.0/irb/workspace.rb:87
c:0015 p:0027 s:0056 e:54 METHOD /usr/lib/ruby/2.3.0/irb/context.rb:380
c:0014 p:0024 s:0050 e:49 BLOCK  /usr/lib/ruby/2.3.0/irb.rb:489
c:0013 p:0041 s:0042 e:41 METHOD /usr/lib/ruby/2.3.0/irb.rb:623
c:0012 p:0011 s:0037 e:36 BLOCK  /usr/lib/ruby/2.3.0/irb.rb:486
c:0011 p:0128 s:0033 e:32 BLOCK  /usr/lib/ruby/2.3.0/irb/ruby-lex.rb:246 
[FINISH]
c:0010 p: s:0030 e:29 CFUNC  :loop
c:0009 p:0009 s:0027 e:26 BLOCK  /usr/lib/ruby/2.3.0/irb/ruby-lex.rb:232 
[FINISH]
c:0008 p: s:0025 e:24 CFUNC  :catch
c:0007 p:0018 s:0021 e:20 METHOD /usr/lib/ruby/2.3.0/irb/ruby-lex.rb:231
c:0006 p:0037 s:0018 E:001700 METHOD /usr/lib/ruby/2.3.0/irb.rb:485
c:0005 p:0009 s:0015 e:14 BLOCK  /usr/lib/ruby/2.3.0/irb.rb:395 [FINISH]
c:0004 p: s:0013 e:12 CFUNC  :catch
c:0003 p:0174 s:0009 E:001820 METHOD /usr/lib/ruby/2.3.0/irb.rb:394
c:0002 p:0023 s:0004 E:0020a0 EVAL   /usr/bin/irb:11 [FINISH]
c:0001 p: s:0002 E:000a30 (none) [FINISH]

-- Ruby level backtrace information 
/usr/bin/irb:11:in `'
/usr/lib/ruby/2.3.0/irb.rb:394:in `start'
/usr/lib/ruby/2.3.0/irb.rb:394:in `catch'
/usr/lib/ruby/2.3.0/irb.rb:395:in `block in start'
/usr/lib/ruby/2.3.0/irb.rb:485:in `eval_input'
/usr/lib/ruby/2.3.0/irb/ruby-lex.rb:231:in `each_top_level_statement'
/usr/lib/ruby/2.3.0/irb/ruby-lex.rb:231:in `catch'
/usr/lib/ruby/2.3.0/irb/ruby-lex.rb:232:in `block in each_top_level_statement'
/usr/lib/ruby/2.3.0/irb/ruby-lex.rb:232:in `loop'
/usr/lib/ruby/2.3.0/irb/ruby-lex.rb:246:in `block (2 levels) in 
each_top_level_statement'
/usr/lib/ruby/2.3.0/irb.rb:486:in `block in eval_input'
/usr/lib/ruby/2.3.0/irb.rb:623:in `signal_status'
/usr/lib/ruby/2.3.0/irb.rb:489:in `block (2 levels) in eval_input'
/usr/lib/ruby/2.3.0/irb/context.rb:380:in `evaluate'
/usr/lib/ruby/2.3.0/irb/workspace.rb:87:in `evaluate'
/usr/lib/ruby/2.3.0/irb/workspace.rb:87:in `eval'
(irb):2:in `irb_binding'
(irb):2:in `new'
/usr/lib/ruby/vendor_ruby/gruff/bar.rb:10:in `initialize'
/usr/lib/ruby/vendor_ruby/gruff/base.rb:230:in `initialize'
/usr/lib/ruby/vendor_ruby/gruff/base.rb:968:in `reset_themes'
/usr/lib/ruby/vendor_ruby/gruff/base.rb:968:in `new'
/usr/lib/ruby/vendor_ruby/gruff/base.rb:968:in `initialize'

-- Machine register context 
 RIP: 0x7ff7c96f2249 RBP: 0x RSP: 0x7ffe1f029a10
 RAX: 0x RBX: 0x0181d210 RCX: 0x0181d240
 RDX: 0x RDI: 0x7ff7c9a13b00 RSI: 0x
  R8: 0x0181caa0  R9: 0x41a0 R10: 0x
 R11: 0x R12: 0x7ff7c9a13b58 R13: 0x7ff7c9a13b08
 R14: 0x0181d210 R15: 0x7ff7c9a13b00 EFL: 0x00010246

-- C level backtrace information ---



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

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

Versions of packages ruby-gruff depends on:
ii  ghostscript 9.19~dfsg-3
ii  gsfonts 1:8.11+urwcyr1.0.7~pre44-4.3
ii  ruby1:2.3.0+4
ii  ruby-rmagick2.15.4+dfsg-2
ii  ruby2.1 [ruby-interpreter]  2.1.5-4
ii  ruby2.2 [ruby-interpreter]  2.2.4-1

ruby-gruff recommends no packages.

ruby-gruff suggests no packages.

-- no debconf information

Bug#843941: New upstream release 3.22.0.1 available

[Laurent Bigonville]

On Fri, 11 Nov 2016 03:18:21 +0100 Michael Biebl  wrote:
>
> Hi,

Hi Jörg,

> there is a new upstream release available. Would be great if you can
> update the package accordingly so we don't ship stretch with a
> development version.

Do you know when the new version will be uploaded in unstable? Do you 
need a sponsor?


Regards,

Laurent Bigonville

Bug#846176: ITP: restic -- restic backup program

[Félix Sipma]

Package: wnpp
Severity: wishlist
Owner: "Félix Sipma" 

* Package name: restic
  Version : 0.3.0
  Upstream Author : Alexander Neumann 
* URL : https://restic.github.io/
* License : BSD
  Programming Lang: Go
  Description : restic is a backup program which allows saving multiple 
revisions of files and directories in an encrypted repository stored on 
different backends.

I think this backup program will be a nice addition to Debian. I will need a 
sponsor.


signature.asc
Description: PGP signature

Bug#846175: gnupg-agent: Cannot use/delete ssh keys w/ empty passphrase

[Matthias Urlichs]

Package: gnupg-agent
Version: 2.1.16-2
Severity: important

I have a few ssh keys with empty passphrase stored in gpg-agent.

I can't delete them; "ssh-add -d path/to/file-pub" silently fails.
So does "ssh-add -D".

I can't use them:
gpg-agent[6308]: failed to unprotect the secret key: No passphrase given

Umm, yes a passphrase *was* asked for, and given; it just happens to be
empty. So? This worked before updating my system to Testing yesterday.

I consider this to be a fairly major regression.

Bug#828327: gnubiff: FTBFS due to missing #include

[Kurt Roeckx]

On Tue, Nov 29, 2016 at 12:47:13AM +0200, Adrian Bunk wrote:
> On Mon, Nov 28, 2016 at 11:05:07PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2016-11-28 23:31:38 [+0200], Adrian Bunk wrote:
> > > Control: retitle -1 gnubiff: FTBFS due to missing #include 
> > > Control: tags -1 patch fixed-upstream
> > > Control: unblock 827061 by -1
> > > 
> > > I've confirmed that gnubiff builds fine with OpenSSL 1.1
> > > 
> > > The attached patch cherry-picks the missing cstring includes
> > > from 2.2.17
> > 
> > I have problems following you here. This package depends on openssl and
> > links against it.
> 
> Yes.
> 
> > This package does not build as-is against 1.1.0 and a
> > binNMU will fail.
> 
> This is not really an OpenSSL issue.

We've been tracking all packages that fail to build that
build-depend on libssl-dev, even if they breakage isn't caused by
openssl.

You can argue about it either way, it's not important for me.


Kurt

Bug#845795: scala-parser-combinators: no symlink for scala-parser-combinators.jar?

[Emmanuel Bourg]

Hi Patrice,

Scala libraries are built for a specific version of the runtime
(different versions of the runtime aren't fully compatible) Here
scala-parser-combinators was built with Scala 2.11 and the jar installed
in /usr/share/java contains the scala version to make this clear. So you
simply have to modify the find_jar directive of your wrapper script and
look for scala-parser-combinator_2.11 instead of scala-parser-combinator.

Emmanuel Bourg

Bug#588510: retitle 588510 rename thin-client-server profile to ltsp-server-profile

[Holger Levsen]

control: retitle -1 rename thin-client-server profile to ltsp-server-profile

Hi,

so I thought about this some more and came to this conclusion because…

ltsp-server-profile is correct and and for those who don't know it,
it's as cryptic as terminal-server-profile. if one doesnt know "ltsp"
nor "terminal", both are meaningless and need to be explained. (easy
with ltsp: we use the ltsp-server project…) - OTOH if one knows the term
"terminal" it's not obvious that "LTSP"-terminals are ment. and if one
knows "LTSP", the name is also obvious.

It's also true that the ltsp-server-profile provides more services than
just "LTSP", but today, the LTSP functionality of these servers is the
main one, so I think the name "ltsp-server-profile" is indeed good.

And should we, after basically using LTSP forever, switch away from LTSP
as the main technology for this, I think it will also be sensible to
rename the profile again, to make this change very clear. But I don't
suppose this will happen any time soon :)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#600293: gnupg-agent: gpg-agent's ssh-agent support claims to delete loaded secret keys, but does not.

[Matthias Urlichs]

Package: gnupg-agent
Version: 2.1.16-2
Followup-For: Bug #600293

what do you mean, "ssh-add -D" returns an error? does not. Not here anyway.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'unstable'), (600, 'stable'), (550, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Versions of packages gnupg-agent depends on:
ii  libassuan0  2.4.3-2
ii  libc6   2.24-5
ii  libgcrypt20 1.7.3-2
ii  libgpg-error0   1.25-1
ii  libnpth01.2-3
ii  libreadline77.0-1
ii  pinentry-gnome3 [pinentry]  0.9.7-9
ii  pinentry-gtk2 [pinentry]0.9.7-9
ii  pinentry-qt [pinentry]  0.9.7-9

Versions of packages gnupg-agent recommends:
ii  gnupg  2.1.16-2
ii  gpgsm  2.1.16-2

gnupg-agent suggests no packages.

-- no debconf information

Bug#668238: terminator: Doesn't close unlinked files

[Egmont Koblinger]

I've reported this issue upstream:
https://bugs.launchpad.net/terminator/+bug/1645500

e.

Bug#843263: grafana: Blank page on new install

[Felix Knecht]

I can confirm that Mieks workaround works. I hit me when upgrading
grafana to the latest version in stretch. So this is not only on new
installs, but the latest update broke grafana in stretch!

Bug#846174: dh_install: could refuse .install file lines without trailing slash in compat 11

[Thorsten Glaser]

Package: debhelper
Version: 10.2.2
Severity: wishlist

After debugging just another bug because dh_install works differently
from cp(1), I came to the conclusion that, maybe, the next compat should
introduce a change that .install file lines that lack a trailing slash,
as well as dh_install invocations that actually pass the arguments on
the command line and lack the trailing slash, will error out.

That means:


cat >debian/foo.install <<\EOF
foo/bar/somefile usr/share/foo/somefile
EOF

dh_install foo/baz/somefile /usr/share/foo/somefile


Both these will error out, and the probably-wanted…


cat >debian/foo.install <<\EOF
foo/bar/somefile usr/share/foo/
EOF

dh_install foo/baz/somefile /usr/share/foo/


… will work. Collateral damage:


cat >debian/foo.install <<\EOF
foo/bar/somefile usr/share/foo
EOF

dh_install foo/baz/somefile /usr/share/foo


… will no longer work, but as the slash form has worked
like forever this is no big loss. I hope that this makes
it more clear to people that dh_install isn‘t cp(1).

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20161112.1
ii  binutils 2.27.51.20161127-1
ii  dh-autoreconf12
ii  dh-strip-nondeterminism  0.028-1
ii  dpkg 1.18.15
ii  dpkg-dev 1.18.15
ii  file 1:5.29-1
ii  libdpkg-perl 1.18.15
ii  man-db   2.7.5-2
ii  perl 5.24.1~rc4-1
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#846173: libvirt-daemon: Fails to locate existing usb device

[David Gilmour]

Package: libvirt-daemon
Version: 2.4.0-1+b1
Severity: important

Dear Maintainer,

I have a custom udev rule used to implement usb-hotplug support for the a 
guest, whose name is dgw.

This is the contents of /etc/udev/rules.d/91-hotplug.rules:
---
ACTION=="add", \
SUBSYSTEM=="usb", \
ENV{ID_VENDOR_ID}=="18ec", \
ENV{ID_MODEL_ID}=="3399", \
RUN+="/usr/bin/virsh attach-device dgw 
/home/david/udev/david-webcam-dgw.xml"

ACTION=="remove", \
SUBSYSTEM=="usb", \
ENV{ID_VENDOR_ID}=="18ec", \
ENV{ID_MODEL_ID}=="3399", \
RUN+="/usr/bin/virsh detach-device dgw 
/home/david/udev/david-webcam-dgw.xml"
---

This is the content of david-webcam-dgw.xml:
---

  


  

---

The rule is correctly activated when the device is plugged in, but with udev 
logging set to debug level, the syslog trace is as follows:

---
Nov 26 14:48:27 dgh systemd-udevd[8692]: Process 'mtp-probe
/sys/devices/pci:00/:00:14.0/usb1/1-3/1-3.1 1 67' succeeded.
Nov 26 14:48:27 dgh systemd-udevd[8692]: RUN '/usr/bin/virsh attach-device dgw 
/home/david/udev/david-webcam-dgw.xml' 
/etc/udev/rules.d/91-dg-webcam-dgw-hotplug.rules:10
Nov 26 14:48:27 dgh systemd-udevd[8692]: handling device node 
'/dev/bus/usb/001/067', devnum=c189:66, mode=0664, uid=0, gid=100 Nov 26 
14:48:27 dgh systemd-udevd[8692]: set permissions /dev/bus/usb/001/067, 020664, 
uid=0, gid=100 Nov 26 14:48:27 dgh systemd-udevd[8692]:
creating symlink '/dev/char/189:66' to '../bus/usb/001/067'
Nov 26 14:48:27 dgh systemd-udevd[8692]: created db file 
'/run/udev/data/c189:66' for '/devices/pci:00/:00:14.0/usb1/1-3/1-3.1'
Nov 26 14:48:27 dgh systemd-udevd[8694]: starting '/usr/bin/virsh attach-device 
dgw /home/david/udev/david-webcam-dgw.xml'
Nov 26 14:48:27 dgh libvirtd[3841]: internal error: unable to execute QEMU 
command 'device_add':
failed to find host usb device 1:67 Nov 26 14:48:27 dgh systemd-udevd[8692]: 
'/usr/bin/virsh attach- device dgw /home/david/udev/david-webcam-dgw.xml'(err) 
'error: '
Nov 26 14:48:27 dgh systemd-udevd[8692]: '/usr/bin/virsh attach-device dgw 
/home/david/udev/david-
webcam-dgw.xml'(err) 'Failed to attach device from 
/home/david/udev/david-webcam-dgw.xml'
Nov 26 14:48:27 dgh systemd-udevd[8692]: '/usr/bin/virsh attach-device dgw 
/home/david/udev/david-
webcam-dgw.xml'(err) 'error: internal error: unable to execute QEMU command 
'device_add': failed to find host usb device 1:67'
Nov 26 14:48:27 dgh systemd-udevd[8692]: '/usr/bin/virsh attach-device dgw 
/home/david/udev/david-
webcam-dgw.xml'(out) ''
Nov 26 14:48:27 dgh systemd-udevd[8692]: Process '/usr/bin/virsh attach-device 
dgw /home/david/udev/david-webcam-dgw.xml' failed with exit code 1.
---

As you can see, the error is that QEMU device_add fails, complaining it cannot 
find the usb device that was indeed created.

Additional detail: The above log was generated after the addition of another 
rules file Thinking it might be a permission problem,I added another rules file 
50-myusb.rules as follows:
---
SUBSYSTEMS=="usb", GROUP="users", MODE="0666"
---
but with or without this rules file the error reported is the same.

Intrestingly, the commands

virsh attach-devcice dgw /home/david/udev/david-webcam-dgw.xml
and
virsh detach-devcice dgw /home/david/udev/david-webcam-dgw.xml

both work and successfully attach the device to the guest if the device is 
connected - but the udev script fails.

USB hotplug on this host was working normally as recently as a couple of months 
ago; possibly a stretch update caused a regression. As of now, I am unable to 
make USB hotplug to guests work.

Thanks so much for looking into this.

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

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

Versions of packages libvirt-daemon depends on:
ii  libapparmor12.10.95-6
ii  libaudit1   1:2.6.7-1
ii  libavahi-client30.6.32-1
ii  libavahi-common30.6.32-1
ii  libblkid1   2.29-1
ii  libc6   2.24-5
ii  libcap-ng0  0.7.7-3
ii  libdbus-1-3 1.10.12-1
ii  libdevmapper1.02.1  2:1.02.136-1
ii  libfuse22.9.7-1
ii  libgnutls30 3.5.6-4
ii  libnetcf1   1:0.2.8-1+b1
ii  libnl-3-200 3.2.27-1
ii  libnl-route-3-200   3.2.27-1
ii  libnuma12.0.11-2
ii  libparted2  3.2-16+b1
ii  libpcap0.8  1.8.1-3
ii  libpciaccess0   0.13.4-1
ii  librados2   0.80.11-1.1
ii  librbd1 0.80.11-1.1
ii  libsasl2-2  2.1.27~72-g88d82a3+dfsg-1
ii  libselinux1 2.6-3
ii  libssh2-1   1.7.0-1
ii  libudev1232-3
ii  libvirt02.4.0-1+b1
ii  libxen-4.8  4.8.0~rc5-1
ii  libxenstore3.0  4.8.0~rc5-1
ii  libxml2 

Bug#845644: xorg-server: breaks virtualbox build

[Gianfranco Costamagna]

control: reassign -1 src:virtualbox
control: forwarded -1 https://www.virtualbox.org/ticket/16052

>Not sure if this would be the xserver's fault for not defining _XOPEN_SOURCE or
>__need_sigset_t, or virtualbox. I'm thinking the latter as in a simple test
>case, including signal.h without doing anything else gives me sigset_t.
thanks, lets ask vbox developers about their opinion, in any case we have to fix

the build in a later step.

(since security team asked to remove it from Stretch... this might be a good 
reason)

G.

Bug#828327: gnubiff: FTBFS due to missing #include

[Adrian Bunk]

On Mon, Nov 28, 2016 at 11:05:07PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-28 23:31:38 [+0200], Adrian Bunk wrote:
> > Control: retitle -1 gnubiff: FTBFS due to missing #include 
> > Control: tags -1 patch fixed-upstream
> > Control: unblock 827061 by -1
> > 
> > I've confirmed that gnubiff builds fine with OpenSSL 1.1
> > 
> > The attached patch cherry-picks the missing cstring includes
> > from 2.2.17
> 
> I have problems following you here. This package depends on openssl and
> links against it.

Yes.

> This package does not build as-is against 1.1.0 and a
> binNMU will fail.

This is not really an OpenSSL issue.

> *Why* do you clear the blocker against the transition
> bug?

Please verify that my patch is not about OpenSSL code, and gives
a successful build with a package dependency on libssl1.1

> Sebastian

cu
Adrian

-- 

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

Bug#843543: [Pkg-tigervnc-devel] Bug#843543: Bug#843543: tigervnc: FTBFS with xserver 1.19

[Ola Lundqvist]

Hi fellow tigervnc developers

I have fixed the bug in git however as I do not have a sid chroot
available at the moment I can not build it. A later xorg-source needs
more recent tools than I have in my stable box.

This is the error I got:
configure: error: Package requirements (fixesproto >= 5.0 damageproto
>= 1.1 xcmiscproto >= 1.2.0 xtrans >= 1.3.5 bigreqsproto >= 1.1.0
xproto >= 7.0.31 randrproto >= 1.5.0 renderproto >= 0.11 xextproto >=
7.2.99.901 inputproto >= 2.3 kbproto >= 1.0.3 fontsproto >= 2.1.3
pixman-1 >= 0.27.2 videoproto compositeproto >= 0.4 recordproto >=
1.13.99.1 scrnsaverproto >= 1.1 resourceproto >= 1.2.0 presentproto >=
1.0 xineramaproto xkbfile  pixman-1 >= 0.27.2 xfont2 >= 2.0.0 xau
libsystemd >= 209 xshmfence >= 1.1 xdmcp) were not met:

Requested 'xtrans >= 1.3.5' but version of XTrans is 1.3.4
Requested 'xproto >= 7.0.31' but version of Xproto is 7.0.26
Requested 'randrproto >= 1.5.0' but version of RandrProto is 1.4.0
No package 'xfont2' found

It would be very good if one of you could add these build dependencies
to the debian/control file, build on unstable and upload.

Thanks in advance

Best regards

// Ola

On 23 November 2016 at 12:54, Ola Lundqvist  wrote:
> Hi
>
> Thank you for the information. Now we just have to fix it. :-)
>
> // Ola
>
> On 22 November 2016 at 23:57, Emilio Pozuelo Monfort 
> wrote:
>>
>> Control: severity -1 serious
>>
>> On 08/11/16 22:04, Emilio Pozuelo Monfort wrote:
>> > On 07/11/16 17:40, Ben Hildred wrote:
>> >>
>> >>
>> >> On Mon, Nov 7, 2016 at 9:13 AM, Emilio Pozuelo Monfort
>> >> > >> > wrote:
>> >>
>> >> Source: tigervnc
>> >> Version: 1.6.0+dfsg-4
>> >> Severity: important
>> >>
>> >> Hi,
>> >>
>> >> I rebuilt your package against xserver 1.19 (2:1.18.99.901-1 to be
>> >> precise,
>> >> note we have 2:1.18.99.902-1 in experimental now) and it failed to
>> >> build,
>> >> particularly it failed to apply the patches to the new xserver:
>> >>
>> >> Hunk #1 succeeded at 161 with fuzz 2 (offset 36 lines).
>> >> Hunk #2 FAILED at 153.
>> >> Hunk #3 FAILED at 215.
>> >> Hunk #4 FAILED at 226.
>> >> 3 out of 4 hunks FAILED -- saving rejects to file os/WaitFor.c.rej
>> >> debian/rules:126: recipe for target
>> >> 'unix/xserver/.apply-patches-vnc-patch-xorg.stamp' failed
>> >>
>> >> (full log attached)
>> >>
>> >> I see there is a new upstream release, so it may be good to look at
>> >> that
>> >> for xserver 1.19 compatibility.
>> >>
>> >> I have seen a fix for this in the upstream change history. I cannot
>> >> remember if
>> >>   it made it into 1.7 or not from the top of my head.
>> >
>> > I saw some patches in upstream github too[1]. IIRC they were not in the
>> > last
>> > release, but they can probably be backported?
>> >
>> > [1]
>> >
>> > https://github.com/TigerVNC/tigervnc/commit/3fed95eda27dfbeee6535f987f5d14a66f64749b
>>
>> I just uploaded xserver 1.19 to sid, so this is RC.
>>
>> Cheers,
>> Emilio
>>
>> ___
>> Pkg-tigervnc-devel mailing list
>> pkg-tigervnc-de...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-tigervnc-devel
>
>
>
>
> --
>  - Ola Lundqvist ---
> /  o...@debian.org Folkebogatan 26  \
> |  o...@inguza.com  654 68 KARLSTAD  |
> |  http://inguza.com/  +46 (0)70-332 1551   |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
>  ---
>



-- 
 - Ola Lundqvist ---
/  o...@debian.org Folkebogatan 26  \
|  o...@inguza.com  654 68 KARLSTAD  |
|  http://inguza.com/  +46 (0)70-332 1551   |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36  4FE4 18A1 B1CF 0FE5 3DD9 /
 ---

Bug#845082: (no subject)

[Breno Leitao]

We just created a pull request to have this fixed upstream.

https://github.com/pydata/numexpr/pull/235

Should we create a Debian patch also?

Bug#846172: ITP: golang-github-rcrowley-go-metrics -- Go port of Coda Hale's Metrics library

[liang]

Package: wnpp
Severity: wishlist
Owner: Liang Yan 

* Package name: golang-github-rcrowley-go-metrics
  Version : 0.0~git20160921.0.ab2277b-1
  Upstream Author : Richard Crowley
* URL : https://github.com/rcrowley/go-metrics
* License :  BSD 2-Clause
  Programming Lang: Go
  Description : Go port of Coda Hale's Metrics library

 It implements a go Metrics library which could capture JVM- and 
application-level metrics.

Bug#846171: ITP: golang-github-daaku-go.zipexe -- Package zipexe attempts to open an executable binary file as a zip file.

[liang]

Package: wnpp
Severity: wishlist
Owner: Liang Yan 

* Package name: golang-github-daaku-go.zipexe
  Version : 0.0~git20150329.0.a5fe243-1
  Upstream Author : Naitik Shah
* URL : https://github.com/daaku/go.zipexe
* License : MIT
  Programming Lang: Go
  Description : Package zipexe attempts to open an executable 
binary file as a zip file.


  This module was taken as-is from 
https://github.com/cookieo9/resources-go.
  More detail could be found from 
https://godoc.org/github.com/daaku/go.zipexe

Bug#846154: Please set XORG_BOUND somewhat higher than 2:1.18.99

[Luca Boccassi]

Control: reassign -1 xserver-xorg-video-nvidia
Control: forcemerge 846030 -1

On Mon, 2016-11-28 at 20:28 +0100, Alf Gaida wrote:
> Package: nvidia-driver
> Version: 375.20-1.1
> Severity: normal
> 
> Dear Manitainer,
> 
> with the current bound the driver isn't installable with the current
> xserver-xorg-core 2:1.19.0-2 - but should be.
> 
> Thanks Alf

Hi,

This has been fixed in a new upload this morning already, should be in
the archive any moment now. Sorry for the mismatch.

Kind regards,
Luca Boccassi


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

Bug#836759: proftpd-dfsg: please drop the build dependency on hardening-wrapper

[Hilmar Preuße]

Am 06.10.2016 um 22:20 schrieb Mattia Rizzolo:

Hi,


13) the -l option of dh_shlibdeps is really unneeded nowadays



   dh_shlibdeps - calculate shared library dependencies

   -ldirectory[:directory ...]
  With recent versions of dpkg-shlibdeps, this option is generally 
not needed.


  It tells dpkg-shlibdeps (via its -l parameter), to look for 
private package libraries in the specified directory (or
  directories -- separate with colons). With recent versions of 
dpkg-shlibdeps, this is mostly only useful (...) or other situations 
where the library is installed into a

  directory not on the regular library search path.


We install a lot of so-files into /usr/lib/proftpd (as plugins). Is 
/usr/lib/... considered to be a "regular library search path"?


After removing that option these messages are still there:

dpkg-shlibdeps: warning: 
debian/proftpd-mod-ldap/usr/lib/proftpd/mod_ldap.so contains an 
unresolvable reference to symbol pr_signals_handle: it's probably a plugin
dpkg-shlibdeps: warning: 33 other similar warnings have been skipped 
(use -v to see them all)


...so this makes me thinks that the option is indeed useless. Please 
confirm. Many thanks!


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

Bug#828327: gnubiff: FTBFS due to missing #include

[Sebastian Andrzej Siewior]

On 2016-11-28 23:31:38 [+0200], Adrian Bunk wrote:
> Control: retitle -1 gnubiff: FTBFS due to missing #include 
> Control: tags -1 patch fixed-upstream
> Control: unblock 827061 by -1
> 
> I've confirmed that gnubiff builds fine with OpenSSL 1.1
> 
> The attached patch cherry-picks the missing cstring includes
> from 2.2.17

I have problems following you here. This package depends on openssl and
links against it. This package does not build as-is against 1.1.0 and a
binNMU will fail. *Why* do you clear the blocker against the transition
bug?

> cu
> Adrian
> 

Sebastian

Bug#846170: claws-mail handles IMAP UIDs incorrectly

[Darac Marjal]

Package: claws-mail
Version: 3.14.1-1.1
Severity: normal

Dear Maintainer,

The IMAP UIDs on one of my folders has increased to more than 2^31
which is causing claws-mail to repeatedly complain:

> folder.c:2265:Removed message 2147483647 from cache.

Upon examining folder.c I notice that, while cache_max_num,
folder_max_num, cache_cur_num and folder_cur_num ARE stored as unsigned
int (guint), in certain situations G_MAXINT is used as an "invalid
value". The attached patch changes this to G_MAXUINT. The patch also
changes usage of GPOINTER_TO_INT and GINT_TO_POINTER to their unsigned
variants.

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

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

Versions of packages claws-mail depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-5
ii  libcairo21.14.6-1.1
ii  libcompfaceg11:1.5.2-5
ii  libdb5.3 5.3.28-12
ii  libdbus-1-3  1.10.12-1
ii  libdbus-glib-1-2 0.108-1
ii  libenchant1c2a   1.6.0-11+b1
ii  libetpan17   1.6-2
ii  libfontconfig1   2.11.0-6.7
ii  libfreetype6 2.6.3-3+b1
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.2-1
ii  libgnutls30  3.5.6-4
ii  libgtk2.0-0  2.24.31-1
ii  libice6  2:1.0.9-1+b1
ii  libldap-2.4-22.4.44+dfsg-1
ii  liblockfile1 1.09-6
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libpangoft2-1.0-01.40.3-3
ii  libpisock9   0.12.5-dfsg-2+b2
ii  libsasl2-2   2.1.27~72-g88d82a3+dfsg-1
ii  libsm6   2:1.2.2-1+b1
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b3

Versions of packages claws-mail recommends:
pn  aspell-en | aspell-dictionary  
ii  claws-mail-i18n3.14.1-1.1
ii  xfonts-100dpi  1:1.0.4+nmu1

Versions of packages claws-mail suggests:
ii  chromium [www-browser] 53.0.2785.143-1
pn  claws-mail-doc 
pn  claws-mail-tools   
ii  firefox-esr [www-browser]  45.5.0esr-1
pn  gedit | kwrite | mousepad | nedit  
ii  lynx [www-browser] 2.8.9dev11-1

-- no debconf information
diff -ur claws-mail-3.14.1.orig/src/folder.c claws-mail-3.14.1/src/folder.c
--- claws-mail-3.14.1.orig/src/folder.c	2016-11-28 19:28:22.869928915 +
+++ claws-mail-3.14.1/src/folder.c	2016-11-28 21:05:12.490606898 +
@@ -2196,22 +2196,22 @@
 		cache_list_last = g_slist_last(cache_list);
 		cache_max_num = ((MsgInfo *)cache_list_last->data)->msgnum;
 	} else {
-		cache_cur_num = G_MAXINT;
+		cache_cur_num = G_MAXUINT;
 		cache_max_num = 0;
 	}
 
 	if (folder_list_cur != NULL) {
 		GSList *folder_list_last;
 	
-		folder_cur_num = GPOINTER_TO_INT(folder_list_cur->data);
+		folder_cur_num = GPOINTER_TO_UINT(folder_list_cur->data);
 		folder_list_last = g_slist_last(folder_list);
-		folder_max_num = GPOINTER_TO_INT(folder_list_last->data);
+		folder_max_num = GPOINTER_TO_UINT(folder_list_last->data);
 	} else {
-		folder_cur_num = G_MAXINT;
+		folder_cur_num = G_MAXUINT;
 		folder_max_num = 0;
 	}
 
-	while ((cache_cur_num != G_MAXINT) || (folder_cur_num != G_MAXINT)) {
+	while ((cache_cur_num != G_MAXUINT) || (folder_cur_num != G_MAXUINT)) {
 		/*
 		 *  Message only exists in the folder
 		 *  Remember message for fetching
@@ -2240,8 +2240,8 @@
 			}
 			
 			if (add) {
-new_list = g_slist_prepend(new_list, GINT_TO_POINTER(folder_cur_num));
-debug_print("Remembered message %d for fetching\n", folder_cur_num);
+new_list = g_slist_prepend(new_list, GUINT_TO_POINTER(folder_cur_num));
+debug_print("Remembered message %u for fetching\n", folder_cur_num);
 			}
 
 			/* Move to next folder number */
@@ -2249,9 +2249,9 @@
 folder_list_cur = folder_list_cur->next;
 
 			if (folder_list_cur != NULL)
-folder_cur_num = GPOINTER_TO_INT(folder_list_cur->data);
+folder_cur_num = GPOINTER_TO_UINT(folder_list_cur->data);
 			else
-folder_cur_num = G_MAXINT;
+folder_cur_num = G_MAXUINT;
 
 			continue;
 		}
@@ -2262,7 +2262,7 @@
 		 */
 		if (cache_cur_num < folder_cur_num) {
 			msgcache_remove_msg(item->cache, cache_cur_num);
-			debug_print("Removed message %d from cache.\n", cache_cur_num);
+			debug_print("Removed message %u from cache.\n", cache_cur_num);
 
 			/* Move to next cache number */
 			if (cache_list_cur)
@@ -2271,7 +2271,7 @@
 			if (cache_list_cur != NULL)
 cache_cur_num = ((MsgInfo *)cache_list_cur->data)->msgnum;
 			else
-cache_cur_num = G_MAXINT;
+cache_cur_num = G_MAXUINT;
 
 			update_flags |= F_ITEM_UPDATE_MSGCNT | F_ITEM_UPDATE_CONTENT;
 
@@ -2291,7 +2291,7 @@
 new_list = 

Bug#838631: Maybe related to #833930

[Benjamin Aigner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I personally don't use gitk (as referred from #833930),
but I installed it and I have the same error.
Maybe these bugs are related.

Maybe another additional relation might be the fact, that I'm using a
Thinkpad X201 too, also with the internal Intel graphics (also stated
in #833930)

On 28/11/16 20:58, Elena ``of Valhalla'' wrote:
> I'm also having this issue.
> 
> I'm not sure it is related, but on both computers where I've had
> this issue I'm also suffering from 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833930
> 
> I've tried to reproduce both issues in a clean VM, first by
> installing jessie, apt installing xorg+fluxbox+kicad+gitk,
> dist-upgrading to stretch and rebooting and then by installing
> jessie, dist-upgrading to stretch, rebooting and then apt
> installing xorg+fluxbox+kicad+gitk. In both cases, I couldn't
> reproduce neither issue.
> 
> I did then try to uninstall libx11-6 and all its dependencies and
> then reinstall everything on one computer, as that may have worked
> for #833930, but it wasn't enough and on that computer I still have
> both problems.
> 

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEkZ15Sx/u8b4k40JmSXFOvY0eyL8FAlg8pwgACgkQSXFOvY0e
yL8soAf/Zr3xfYM18dvw+9FKxAsb5VHg0JRQd/ymXJ9goAUak/yPJCluOad880AL
0HF0hfjfKMnzJAyvY1e47Btr6f8UUJXw7+3IOt0N4UP7Q3/KVn76VF2p5hVMT2zv
8TtFCRJeJScluea3rCKQ8XSaqHOOCqwf9wnCHSpwd3LgR1MbaeeclQ4ybds9mblr
ZlVjnyWTXtYW8G0OWt7fqhIQY1f9BTh0lOAb3SQ/uVqW0CEyJq5CGBJDeRyKPW78
zv2DAqzyRWUXGCwrz8g9W1oc8In+zcIa+OlP4OIxDkD6DJshsxmy8sZ3q+w98i0S
tz3pgMrUES4DSs65CcwIaqYZRnxxEA==
=fx2d
-END PGP SIGNATURE-

Bug#846169: ITP: golang-github-akavel-rsrc -- Tool for embedding binary resources in Go programs

[liang]

Package: wnpp
Severity: wishlist
Owner: Liang Yan 

* Package name: golang-github-akavel-rsrc
  Version : 2+git20151103.6.ba14da1-1
  Upstream Author : Mateusz Czapliński
* URL : https://github.com/akavel/rsrc
* License : MIT
  Programming Lang: Go
  Description : Tool for embedding binary resources in Go programs.

 It is based on ideas presented by Minux, currently work on arch "386" and
  experimental for "amd64".

Bug#845188: closed by Don Armstrong <d...@debian.org> (reply to ow...@bugs.debian.org) (Re: Bug#845188: bugs.debian.org: Please provide "Content-Disposition: attachment; filename=[..]" headers)

[Don Armstrong]

On Mon, 28 Nov 2016, Raphael Hertzog wrote:
> On Mon, 21 Nov 2016, Debian Bug Tracking System wrote:
> > We (hopefully) do this in all cases for which there is a filename:
> > 
> > $ HEAD 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi\?att\=1\;bug\=804063\;filename\=reproducible.patch\;msg\=10
> > 200 OK
> > [...]
> > Content-Disposition: inline; filename="reproducible.patch"
> 
> It does not seem to be working for me either.
> 
> $ curl -sI 
> 'https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=775322;filename=775322_v5.tar.gz;msg=112'

[...]

> So it looks like that I have the desired filename, only after the
> attachement has been cached somewhere. Maybe this is specific to some
> special setup made by DSA... putting them in copy.

Huh. That is really, really odd.

I wonder if it's because we output Content-Disposition: after sending
Content-Type:? I don't see how that should matter in the spec, but maybe
clients fail if that hasn't been done properly?


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

If you wish to strive for peace of soul, then believe; if you wish to
be a devotee of truth, then inquire.
 -- Friedrich Nietzsche

Bug#573173: support multiple kernel versions with same flavour

[Raphael Hertzog]

Control: tag -1 - patch

Hello Michal,

On Thu, 25 Aug 2016, Michal Suchanek wrote:
> sending fixed/updated version of the patch.
> This works for me quite well with live-build in Debian and Syslinux.
> Grub is unsupported.

As long as grub is unsupported, I can't really apply this patch.
In particular since grub is required for EFI support nowadays.

Also I'm not sure that I like the fact that we advertise the kernel
version by default. As you might have noticed, the default grub config
in Debian hides the current kernel version. You only see it in a sub-menu.

We should probably aim for something similar in live-build when
we have multiple kernels.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#831032: pptp-linux: Please update patches and packaging

[Ola Lundqvist]

Hi Christoph

Thanks a lot for the work you have done. Do you even want to take over
the maintenance of this package? I do not use it anymore and it would
be very welcome with a more interested maintainer than myself.

Cheers

// Ola

On 26 November 2016 at 14:51, Christoph Biedl
 wrote:
> Ola Lundqvist wrote...
>
>> Thank you for the suggestion. I't is now on my todo list. Patches are as
>> always welcome.
>
> Um, too much for a patch. I decided to provide an updated
> debian.tar.xz. Unpack it on top of the orig.tar and see for yourself.
>
> There were also two little time bombs, now defused. I might however have
> placed an easter egg somewhere.
>
>
> Left to do:
>
> * Make the test work (upstream)
>
> * Check compliance with latest Debian policy/Standards-Version: 3.9.8
>
> * Add Homepage:, convert debian/copyright to DEP-5/format 1.0
>
> * Upstream all the patches
>
> * Examine the warnings emitted by gcc-6
>
> * Convince upstream to remove pptpsetup.8 in the clean target
>
> Should be as simple as:
>
> --- a/Makefile
> +++ b/Makefile
> @@ -60,7 +60,7 @@
> $(CC) -o vector_test vector_test.o vector.o
>
>  clean:
> -   $(RM) *.o config.h
> +   $(RM) *.o config.h pptpsetup.8
>
>  clobber: clean
> $(RM) $(PPTP_BIN) vector_test
>
> There's a workaround in debian/rules now to make
> "fakeroot debian/rules clean" work as expected.
>
> Cheers,
>
> Christoph



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#846168: gnupg2: --export-ssh-key is not working

[Hans Freitag]

Package: gnupg2
Version: 2.1.16-2
Severity: normal

Dear Maintainer,

Exporting ssh2 keys is not working with gnupg 2.1.16

$ gpg2 --export-ssh-key SOMEKEYID
gpg: O j: Assertion "ret_found_key == NULL || ret_keyblock != NULL" in 
lookup failed (../../g10/getkey.c:3677)
Abgebrochen

A 2.1.15 binary is working fine with the same key/keyring. 


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

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

Versions of packages gnupg2 depends on:
ii  gnupg  2.1.16-2

gnupg2 recommends no packages.

gnupg2 suggests no packages.

-- no debconf information

Bug#846062: s-nail: not a proper mailx alternative

[Steffen Nurpmeso]

Hallo.

Hilko Bengen  wrote:
 |* Bas Zoetekouw:
 |> s-nail/heirloom-mailx is not a proper alternative for mailx/bsd-mailx,
 |> as it uses different command line options (for example on a regulair
 |> mailx, -a means "add header, whereas for s-nail it means "add
 |> attachment").
 |
 |We had some discussion about whether to provide a mailx alternative back
 |in the day when heirloom-mailx was still called nail, see #272256.
 |
 |And at one time there was even a report about a missing -a option
 |although it seems that then the submitter decided otherwise, see #381575
 |
 |> This breaks other packages (for example cron-apt) that rely on a
 |> mailx-dependency to send mails.  Therefore, I'm making this Serious
 |> severity.
 |
 |The -a option was added to bsd-mailx by Debian more than 16 years ago.
 |However, there does not seem to be any clear definition that tells us
 |what to expect from a /usr/bin/mailx program.
 |
 |Is this really s-nail's fault?
 |
 |Steffen, would you consider changing the parameter for adding an
 |attachment to something else?

Rather not, Gunnar Ritter introduced -a already in the first
release of (then) nail, v9.0.0, 21st of March 2000.  Even if not,
-a and attachments smells more sane than -a and header additions..
And also the -a of that patched bsd-mailx seems to be used for
faking MIME headers -- one of my occasional Google searches
regarding S-nail presented a bug report in Debian or Ubuntu that
matches this report here --, and that is pretty useless for
nail/mailx since that handles MIME itself.

Cron-apt, hm.  Ok, that not.  Terrible thing :).  Tja.  It is
possible to differentiate with a check:

  ?64[steffen@wales nail.git]$ mail -V  
 
  v14.8.14
  ?0[steffen@wales nail.git]$ echo|MAILRC=/dev/null mail -n#
 
  At EOF
  ?0[steffen@wales nail.git]$ echo|MAILRC=/dev/null heirloom-mailx -n#  
 
  heirloom-mailx: illegal option -- #
  Usage: heirloom-mailx -eiIUdEFntBDNHRV~ -T FILE -u USER -h hops -r address -s 
SUBJECT -a FILE -q FILE -f FILE -A ACCOUNT -b USERS -c USERS -S OPTION users

e.g.

  ( echo|MAILRC=/dev/null heirloom-mailx -n# ) >/dev/null 2>&1
  ( echo|MAILRC=/dev/null mail -n# ) >/dev/null 2>&1

Likely that this doesn't really hurt this script that much.
(Does it set MAILRC=/dev/null or use -n?  Don't think so.)
For none-MIME header additions (this "a" i realize) we will have
the `customhdr' command and the *customhdr* variable, as used for
sending this message (BlahBlahBlah and OpenPGP headers), which
could be used from the command line with -X (command) or -S
(variable), e.g.,

  echo bla|./s-nail -d -X'customhdr jazz funk' -Scustomhdr=ju:hu du@auch
  ...
  s-nail: >>> MTA: /usr/sbin/sendmail, arguments: sendmail -i -- du@auch
  s-nail: >>> Date: Mon, 28 Nov 2016 22:22:56 +0100
  s-nail: >>> To: du@auch
  s-nail: >>> User-Agent: s-nail v14.9.0-pre2-92-gcdbe3e5
  s-nail: >>> jazz: funk
  s-nail: >>> ju: hu
  s-nail: >>> 
  s-nail: >>> bla

Unfortunately only with v14.9.0 it will be possible to define
rather any header when feeding in via -t, too:

  ./s-nail -:/ -#d -t hey@you >> MTA: /usr/sbin/sendmail, arguments: sendmail -i -- hey@you
  s-nail: >>> Date: Mon, 28 Nov 2016 22:43:04 +0100
  s-nail: >>> From: hey
  s-nail: >>> To: hey@you
  s-nail: >>> User-Agent: s-nail v14.9.0-pre2-92-gcdbe3e5
  s-nail: >>> X-Curs: diet
  s-nail: >>> X-Tea: Chinese
  s-nail: >>> 
  s-nail: >>> Body.
  s-nail: >>> More Body.

Sorry.
I'm afraid we don't have that many command line options available
for use, but -a i think it cannot be.
Ciao.

--steffen

Bug#846060: patch

[Ola Lundqvist]

Hi Bob and Bas

Thank you very much for this. I have changed the code according to
that and uploaded a new release.

// Ola

On 28 November 2016 at 20:21, Bob Proulx  wrote:
> Bas Zoetekouw wrote:
>> -eval mail $XHEADERS -s \"$SUBJECT\" \"$MAILTO\" < "$MAIL"
>> +( printf "$hdr\n"; echo; cat $MAIL ) | sendmail -t
>
> If using sendmail and reading from stdin then the -oi option should
> also be used.  The sendmail man page says:
>
>   -oi  When reading a message from standard input, don't treat a line
>   with only a . character as the end of input.
>
> Therefore:
>
>   ... | sendmail -t -oi
>
> Bob



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#440057: memory leaks in apt-transport-https - unanswered since 9 years

[Holger Levsen]

control: tags -1 security moreinfo

Hi,

this bug has probably has security implications (though probably only
for low memory systems…) and has been unanswered since 9 years…

with https://bugs.debian.org/apt-transport-https and with deb.debian.org
since recently supporting https, this bug has become quite visible too…

and it was reported against 0.7.6, is it even still present in todays
unstable (or stable)?


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#845169: ruby-carrierwave: FTBFS in testing (unknown option '--initialize-insecure')

[Emilio Pozuelo Monfort]

Hi,

On Tue, 29 Nov 2016 00:42:00 +0530 Pirate Praveen  wrote:
> On Mon, 21 Nov 2016 00:42:58 + Santiago Vila  wrote:
> > Maybe some build-depends needs to be versioned?
> 
> It was building fine with mysql-5.7 in unstable, this version is not yet
> migrated to testing. I think I will disable the tests until mysql-5.7
> can enter testing.

We're moving to MariaDB because of security concerns on MySQL. There have been
bug reports filed recently, though ruby-carrierwave (and others) were missed
because it doesn't depend build-depend on libmysqlclient-dev. I will let the
mysql team know about it so they can file the remaining bugs.

Basically, what you need to do is switch your build-dependency from mysql-server
to default-mysql-server. That will pull mariadb-server, which is similar to
mysql-server-5.6. Thus you may need to switch back to the previous options.

Sorry for the inconvenience. This should have happened much earlier but there
have been several delays.

Thanks,
Emilio

Bug#828327: gnubiff: FTBFS due to missing #include

[Adrian Bunk]

Control: retitle -1 gnubiff: FTBFS due to missing #include 
Control: tags -1 patch fixed-upstream
Control: unblock 827061 by -1

I've confirmed that gnubiff builds fine with OpenSSL 1.1

The attached patch cherry-picks the missing cstring includes
from 2.2.17

cu
Adrian

-- 

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

Description: Cherry-pick missing #include  from 2.2.17
Origin: upstream
Bug-Debian: https://bugs.debian.org/828327

--- gnubiff-2.2.16.orig/src/biff.cc
+++ gnubiff-2.2.16/src/biff.cc
@@ -30,6 +30,7 @@
 #include "support.h"
 
 #include 
+#include 
 #include 
 #include 
 #include 
--- gnubiff-2.2.16.orig/src/socket.cc
+++ gnubiff-2.2.16/src/socket.cc
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
--- gnubiff-2.2.16.orig/src/ui-applet-gnome.cc
+++ gnubiff-2.2.16/src/ui-applet-gnome.cc
@@ -31,6 +31,7 @@
 
 #include 
 #include 
+#include 
 
 #include "ui-applet-gnome.h"
 #include "ui-popup.h"

Bug#845188: closed by Don Armstrong <d...@debian.org> (reply to ow...@bugs.debian.org) (Re: Bug#845188: bugs.debian.org: Please provide "Content-Disposition: attachment; filename=[..]" headers)

[Raphael Hertzog]

Control: reopen -1

On Mon, 21 Nov 2016, Debian Bug Tracking System wrote:
> We (hopefully) do this in all cases for which there is a filename:
> 
> $ HEAD 
> https://bugs.debian.org/cgi-bin/bugreport.cgi\?att\=1\;bug\=804063\;filename\=reproducible.patch\;msg\=10
> 200 OK
> [...]
> Content-Disposition: inline; filename="reproducible.patch"

It does not seem to be working for me either.

$ curl -sI 
'https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=775322;filename=775322_v5.tar.gz;msg=112'
HTTP/1.1 200 OK
Date: Mon, 28 Nov 2016 21:18:55 GMT
Server: Apache
Etag: 3dbb9e20356568e1338ec7e80806784f
X-Clacks-Overhead: GNU Terry Pratchett
Content-Type: application/x-gzip

And in Firefox, the first time I click on the link I always get a
"bugreport.cgi" filename. If I click again, then I have the desired
filename. Doing multiple HEAD requests is not enough to get the
desired header. But when I do two GET request in Firefox and then
try again a new HEAD request, then I have the desired header:

$ curl -sI 
'https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=775322;filename=775322_v5.tar.gz;msg=112'
HTTP/1.1 200 OK
Date: Mon, 28 Nov 2016 21:20:44 GMT
Server: Apache
Etag: 40521391a16b049a2889601c91e4e6eb
X-Clacks-Overhead: GNU Terry Pratchett
Cache-Control: public, max-age=604800
Content-Disposition: inline; filename="775322_v5.tar.gz"
Strict-Transport-Security: max-age=15552000
Age: 41
Content-Length: 265161
Content-Type: application/x-gzip

So it looks like that I have the desired filename, only after the
attachement has been cached somewhere. Maybe this is specific to
some special setup made by DSA... putting them in copy.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#846167: qtwebchannel5-examples/armel unsatisfiable Depends: nodejs

[Adrian Bunk]

Source: qtwebchannel-opensource-src
Version: 5.7.1~20161021-2
Severity: serious

Migration to testing (and therefore inclusion in stretch)
is currently blocked by:
  qtwebchannel5-examples/armel unsatisfiable Depends: nodejs

nodejs is gone on armel, and won't come back.

There are two ways how this could be resolved:

1. if qtwebchannel-opensource-src makes sense without nodejs,
   the qtwebchannel5-examples dependencies on nodejs and npm
   should become [!armel]

OR

2. - add a build-dependency on nodejs so that qtwebchannel-opensource-src
 gets built only on architectures where nodejs is available, AND
   - send an "RM: qtwebchannel-opensource-src [armel]" bug
 against ftp.debian.org to get rid of the old package on armel

Bug#846166: .../.ssh/config line 127: Bad protocol spec '1'.

[Robert de Bath]

Package: ssh
Version: 1:7.3p1-3

This error occurs whatever I attempt to connect to, even though the particular 
stanza of the config as nothing to do with the host I'm

connecting to. It is obviously inefficient and much too aggressive.

I obviously still have a use for v1 as there isn't an ssh v2 sufficiently 
portable to install on the machine in question.


This is the stanza at line 127.

# simh vax running Ultrix 4.5
Host ultrix
User robert
Port 2120
HostName 127.0.0.1
AddressFamily inet
HostKeyAlias=ultrix
Protocol 1
Cipher blowfish


--
Rob.  (Robert de Bath )
 

Bug#846165: .../.ssh/config line 127: Bad protocol spec '1'.

[Robert de Bath]

Package: ssh
Version: 1:7.3p1-3

This error occurs whatever I attempt to connect to, even though the 
particular stanza of the config as nothing to do with the host I'm

connecting to. It is obviously inefficient and much too aggressive.

I obviously still have a use for v1 as there isn't an ssh v2 
sufficiently portable to install on the machine in question.


This is the stanza at line 127.

# simh vax running Ultrix 4.5
Host ultrix
User robert
Port 2120
HostName 127.0.0.1
AddressFamily inet
HostKeyAlias=ultrix
Protocol 1
Cipher blowfish


--
Rob.  (Robert de Bath )
 

Bug#718225: Review of live-build patchset to authenticate downloaded files

[Raphael Hertzog]

Control: tag -1 - patch
Control: severity -1 + wishlist

I quickly reviewed the patch set and it's way too intrusive for me to
commit it. I think the goal is laudable but the approach taken is
overkill.

We don't need new options, we just want something safe by default. If
anything we should be using apt even more... 

I don't plan to spend time on this large problem given that live-build.
live-build is in a low maintenance mode and that kind of large change
is not the kind of thing that we are interested in.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#846164: dpkg-dev: Have dpkg-genchanges support a source+buildinfo-only upload

[Ximin Luo]

Package: dpkg-dev
Version: 1.18.15
Severity: wishlist

Dear Maintainer,

Currently one can do

$ dpkg-buildpackage --changes-option=-S

to do a binary build locally, but only upload the source package so that 
buildds build on all arches. Note that this command *does* generate a buildinfo 
file, but does not include it in the changes file.

It would be good to be able to do something like

$ dpkg-buildpackage --changes-option=-SB

to do a binary build locally, but only upload the source package *and* the 
buildinfo file.

This was one idea we had near the beginning of the R-B project. The idea being 
developers could do this, then the buildds could try to match what they built, 
as an extra check. Another advantage is that the upload itself would be reduced 
in size.

(Something other than -SB would also be fine.)

X

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

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

Versions of packages dpkg-dev depends on:
ii  binutils  2.27.51.20161108-1
ii  bzip2 1.0.6-8
ii  libdpkg-perl  1.18.15
ii  make  4.1-9
ii  patch 2.7.5-1
pn  perl:any  
ii  tar   1.29b-1.1
ii  xz-utils  5.2.2-1.2

Versions of packages dpkg-dev recommends:
ii  build-essential  12.2
ii  clang-3.5 [c-compiler]   1:3.5.2-5
ii  fakeroot 1.21-2
ii  gcc [c-compiler] 4:6.1.1-1
ii  gcc-6 [c-compiler]   6.2.0-13
ii  gnupg2.1.16-2
ii  gnupg2   2.1.16-2
ii  gpgv 2.1.16-2
ii  libalgorithm-merge-perl  0.08-3

Versions of packages dpkg-dev suggests:
ii  debian-keyring  2016.09.04

-- no debconf information

Bug#810371: Upstream does support libftdi1

[Geert Stappers]

Control: tag -1 pending

Gathered information:

In upstream's git log is:

| commit 25341355813d1e9dd0a32871bbc63c0a6e48d01c
| Author: Mike Frysinger 
| Date:   Sun Mar 24 04:57:38 2013 +
| 
| add support for libftdi-1.x
| 
| git-svn-id: https://urjtag.svn.sourceforge.net/svnroot/urjtag/trunk@2037 
b68d4a1b-bc3d-0410-92ed-d4ac073336b7


Changing Build-Depends  'libftdi-dev' in 'libtdi1-dev'
changes "configure output"

| checking for LIBFTDI... no
| checking for LIBFTDI... yes
| checking for ftdi_usb_open... yes
| checking for ftdi_read_data_submit... no

into

| checking for LIBFTDI... yes
| checking for ftdi_usb_open... yes
| checking for ftdi_read_data_submit... yes



Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: Digital signature

Bug#846148: 6.2.1 breaks upstream's kernel

[Matthias Klose]

On 28.11.2016 18:34, Harald Dunkel wrote:
> Package: gcc-6
> Version: 6.2.1-5
> 
> Upstream's kernel (4.8.11) built with gcc 6.2.1 freezes with the
> message "loading initial ramdisk ..." at boot time.
> 
> Moving back to 6.2.0-6 fixes the problem. Same config file, of
> course.
> 
> How comes that Debian suddenly uses the bleeding edge gcc as the
> default compiler? Maybe I am too blind to see, but 6.2.1 cannot
> even be found on ftp.gnu.org.

you are too blind.  this is the current gcc-6-branch.

> A few years ago the default compiler was chosen *very* carefully.
> I miss that.

gcc was always built from the branch for decades.

I'm closing this issue, this is no GCC issue. This looks like a duplicate of
#845690, but the bug report lacks proper information.

Bug#732242: general: CPU fan always on (high speed)

[Mathieu Malaterre]

> I find these informations here:
> http://www.linux-hell.com/2015/04/11/temperature-control-on-dell-latitude-e7440-under-ubuntu-14-04-2-lts/

Also referenced here: http://askubuntu.com/a/398635/248166

Seems to works very nicely on my system:

$ sudo dmidecode | grep -A3 '^System Information'
System Information
Manufacturer: Dell Inc.
Product Name: Dell System Vostro 3750
Version: Not Specified

Bug#843381: ffproxy: server does not start

[Emmanuel Bouthenot]

Toni,

[...]

> I installed ffproxy and then tried to start it.  Out of the box, ffproxy
> does not start, complaining that it is unable to open a file
> 'db/access.ip'. However, for all locations I tried, this file is there.
> I tried to modify the chroot settings and the database path settings,
> but to no avail. So far, I have been unable to start ffproxy. Here is an
> attempt where I try to start it by hand:

As you may have noticed, /var/lib/ffproxy is the directory where ffproxy
is chrooted when started with the init script.

If you want to start it outside the chroot, you just need to run:

# ffproxy -D /etc/ffproxy

Regards,

M.

-- 
Emmanuel Bouthenot
  mail: kolter@{openics,debian}.orggpg: 4096R/0x929D42C3
  xmpp: kol...@im.openics.org  irc: kolter@{freenode,oftc}

Bug#846163: magicor: Add an option to disable the info scroller

[Andrej Mernik]

Package: magicor
Version: 1.1-4
Severity: wishlist
Tags: patch

Dear Maintainer,

the info scroller that displays on the bottom of the game screen is distracting
and not very useful (at least for me).

I'm attaching a patch that adds an option to disable it. The option defaults to
true (the scroller is displayed by default). Please test the attached patch and
include it into the package if possible.

Best Regards,
Andrej Mernik



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

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

Versions of packages magicor depends on:
ii  libglade2-0  1:2.6.4-2
ii  libsdl-image1.2  1.2.12-5+b5
ii  libsdl-mixer1.2  1.2.12-11+b1
ii  magicor-data 1.1-4
ii  python   2.7.9-1
ii  python-gtk2  2.24.0-4
ii  python-pygame1.9.1release+dfsg-10+b1
ii  python2.72.7.9-2+deb8u1

magicor recommends no packages.

magicor suggests no packages.
diff -ur magicor-1.1/magicor/__init__.py magicor-1.1-patched/magicor/__init__.py
--- magicor-1.1/magicor/__init__.py	2009-04-24 12:59:37.0 +0200
+++ magicor-1.1-patched/magicor/__init__.py	2016-11-28 21:22:39.0 +0100
@@ -235,7 +235,7 @@
 pygame.display.init()
 pygame.display.set_caption("Magicor")
 pygame.mouse.set_visible(False)
-for k in ("sound", "joystick", "music", "eyecandy"):
+for k in ("sound", "joystick", "music", "eyecandy", "scroller"):
 if not config.has_key(k):
 config[k] = 1
 if (not config.has_key(k)
diff -ur magicor-1.1/magicor/states/options.py magicor-1.1-patched/magicor/states/options.py
--- magicor-1.1/magicor/states/options.py	2009-04-24 12:59:37.0 +0200
+++ magicor-1.1-patched/magicor/states/options.py	2016-11-28 20:24:19.588667863 +0100
@@ -174,6 +174,10 @@
   config.getBool("eyecandy"),
   "eyecandy"),
self.toggleEyecandy)
+self.addOption(BoolOption("scroller",
+  config.getBool("scroller"),
+  "scroller"),
+   self.toggleScroller)
 self.addOption(IntOption("sound vol",
  config.getInt("sound_vol"),
  "sound_vol", 0, 100),
@@ -217,6 +221,11 @@
 if hasattr(self.previous, "eyecandy"):
 self.previous.eyecandy = self.config.getBool("eyecandy")
 return True
+  
+def toggleScroller(self):
+if hasattr(self.previous, "scroller"):
+self.previous.scroller = self.config.getBool("scroller")
+return True
 
 def toggleFullscreen(self):
 if self.config.get("fullscreen"):
diff -ur magicor-1.1/magicor/states/play.py magicor-1.1-patched/magicor/states/play.py
--- magicor-1.1/magicor/states/play.py	2009-04-24 12:59:37.0 +0200
+++ magicor-1.1-patched/magicor/states/play.py	2016-11-28 20:26:07.334846971 +0100
@@ -427,7 +427,8 @@
 self.hudSprites.update()
 self.hudSprites.draw(self.renderSurface)
 self.screen.blit(self.renderSurface, (80, 16))
-self.drawScroller()
+if self.config.get("scroller"):
+self.drawScroller()
 for y in xrange(0, self.screen.get_height(), 32):
 self.screen.fill(0,
  (0,
@@ -465,5 +466,6 @@
 self.hudSprites.update()
 self.hudSprites.draw(self.renderSurface)
 self.screen.blit(self.renderSurface, (80, 16))
-self.drawScroller()
+if self.config.get("scroller"):
+self.drawScroller()
 self.control()

Bug#846146: hexchat: Please enable LUA

[Mattia Rizzolo]

Control: reassign -1 src:hexchat 2.12.3-0.1
Control: forcemerge -1 834491

On Mon, Nov 28, 2016 at 06:14:06PM +0100, Paride Legovini wrote:
> Please enable the LUA bindings, possibly using a separate package like
> hexchat-perl and hexchat-python3.

yes, yes, it's coming.
It's already done in git, but it has to go through NEW, I wanted the new
release out quickly to fix that other release critical bug :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#838631: Bug#833930: gitk: display shot, application usability gone

[Elena ``of Valhalla'']

I've also been having the same issue for quite some time.

Today I've noticed that I'm also having it on another computer *and*
I've noticed that it seems to be correlated with having rendering issues
with kicad ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838631 ).

Like Antoni Marcinek uninstalling and reinstalling did not help.

I did try to reproduce it on a clean virtual machine, but in that case I
wasn't able to see it.

Both computers that have this issue are liberated thinkpad x200 with an
intel graphic card.

I could probably try a fresh install, but I would need to find a spare
hard disk (and free time to actually do it), so it will take a few days
before I'm able to do so.

-- 
Elena ``of Valhalla''

Bug#773775: About bootstrap_archive-keys

[Raphael Hertzog]

Hello,

I reviewed the patches submitted in that bug and I have not found
one worth committing. live-build is in low maintenance mode so
I'm trying to not break compatibility with unnecessary new requirements.

In fact, I believe that the bootstrap_archive-keys step is entirely
useless. We already have the --keyring-packages option. It forces usage
of a package, but that's acceptable IMO.

I'm going to drop the script entirely.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#801605: xserver-xorg: X fails to start as normal user

[Ricardo Fabian Peliquero]

On Mon, Nov 28, 2016 at 05:26:42PM +0100, Julien Cristau wrote:
> On 11/28/2016 03:54 PM, Ricardo Fabian Peliquero wrote:
> > On Tue, Oct 13, 2015 at 09:56:31PM +0200, Julien Cristau wrote:
> >> On Tue, Oct 13, 2015 at 16:22:45 -0300, Ricardo Peliquero wrote:
> >>
> >>> I had to install libpam-systemd and systemd-shim to solve the problem. 
> >>> Should this package be recommended by xorg or xinit?
> >>>
> >> Ah, thanks.  I think adding that as a Recommends in xinit sounds sensible, 
> >> yes.
> >>
> >> Cheers,
> >> Julien
> > 
> > Dear maintainer,
> > 
> > Last year I suggested adding libpam-systemd as a Recommends in 
> > xserver-xorg-core or xinit. That suggestion was applied at that time. 
> > 
> > The problem is also solved by installing xserver-xorg-legacy and e.g. 
> > configuring /etc/X11/Xwrapper.config like it is shown below for a radeon 
> > card. Please, consider adding this package to the Recommends as an 
> > alternative to libpam-systemd.
> > 
> >  ; cat /etc/X11/Xwrapper.config
> >  needs_root_rights = yes
> > 
> > My suggestion would be xserver-xorg-core Recommends: libpam-systemd | 
> > xserver-xorg-legacy.
> > 
> Nope, we shouldn't be recommending people use the setuid root wrapper, IMO.
> 
> Cheers,
> Julien
> 

I understand (and agree). What about changing libpam-systemd to Suggests rather 
than Recommends?

Thank you,

Ricardo

Bug#825887: mnemosyne: does not start due to removal of WebKit from python-qt4

[Felix Gruber]

Upstream has worked on porting mnemosyne to Python3 and PyQt5.
They have published a link to a beta for the upcoming release 2.4 of
mnemosyne on their mailinglist:

https://groups.google.com/forum/#!topic/mnemosyne-proj-users/Et6uWBbFRjU

This version of mnemosyne should be compatible with the PyQt5 in Debian
testing. It would be nice if we could package this before the release of
stretch.

Cheers,
Felix

Bug#845751: yadifa FTBFS on ppc64el: internal compiler error: in push_reload, at reload.c:1349

[Breno Leitao]

Hello,

On 11/26/2016 10:57 AM, Adrian Bunk wrote:
> Source: yadifa
> Version: 2.2.2-1
> Severity: serious
> 
> https://buildd.debian.org/status/fetch.php?pkg=yadifa=ppc64el=2.2.2-1=1480164499
> 
> ...
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./include/dnscore -Wdate-time 
> -D_FORTIFY_SOURCE=2 -DNDEBUG -g -DDNSCORE_BUILD -D_THREAD_SAFE -D_REENTRANT 
> -D_FILE_OFFSET_BITS=64 -I/«PKGBUILDDIR»/lib/dnscore 
> -I/«PKGBUILDDIR»/lib/dnscore/include -fno-ident -ansi -pedantic -Wall 
> -Wno-unknown-pragmas -Werror=missing-field-initializers -std=gnu99 
> -mtune=native -DUSES_GCC -DPREFIX=\"/usr\" -DSYSCONFDIR=\"/etc\" 
> -DLOCALSTATEDIR=\"/var\" -DDATAROOTDIR=\"/usr/share\" 
> -DDATADIR=\"/usr/share\" -DLOCALEDIR=\"/usr/share/locale\" 
> -DLOGDIR=\"/var/log/yadifa\" -DTCLDIR=\"\" -DNDEBUG -O3 -g -DCMR -c 
> src/message_print_format_dig.c -o src/message_print_format_dig.o
> src/message_print_format_dig.c: In function 'message_print_format_dig_buffer':
> src/message_print_format_dig.c:304:1: internal compiler error: in 
> push_reload, at reload.c:1349
>  }
>  ^
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> Preprocessed source stored into /tmp/ccy8l7aF.out file, please attach this to 
> your bugreport.

This is a known issue on GCC as you can see at:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543

I just created a patch to fix this FTBFS on Debian. It is attached to this 
email.

diff -Nru yadifa-2.2.2/debian/changelog yadifa-2.2.2/debian/changelog
--- yadifa-2.2.2/debian/changelog	2016-11-08 06:21:48.0 -0500
+++ yadifa-2.2.2/debian/changelog	2016-11-28 15:12:29.0 -0500
@@ -1,3 +1,9 @@
+yadifa (2.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Avoid compiling with O3 on ppc64el due to a known bug
+
+ -- Breno Leitao   Mon, 28 Nov 2016 15:12:29 -0500
+
 yadifa (2.2.2-1) unstable; urgency=medium
 
   * New upstream version 2.2.2 (Closes: #828612)
diff -Nru yadifa-2.2.2/debian/patches/fix-ppc64el_ftbfs.patch yadifa-2.2.2/debian/patches/fix-ppc64el_ftbfs.patch
--- yadifa-2.2.2/debian/patches/fix-ppc64el_ftbfs.patch	1969-12-31 19:00:00.0 -0500
+++ yadifa-2.2.2/debian/patches/fix-ppc64el_ftbfs.patch	2016-11-28 15:12:29.0 -0500
@@ -0,0 +1,27 @@
+--- a/m4/eurid.m4	2016-11-08 05:56:43.140600104 -0500
 b/m4/eurid.m4	2016-11-28 15:01:27.0 -0500
+@@ -298,6 +298,9 @@ case "$(uname -m)" in
+ 		CPU_UNKNOWN=0
+ 		cpu_intel_compatible=1
+ 		;;
++	ppc64le)
++		cpu_power_compatible=1
++		;;
+ 	*)
+ 		;;
+ esac
+@@ -625,7 +628,13 @@ then
+ 			CCOPTIMISATIONFLAGS=-O3
+ 		fi
+ 	fi
+-
++ 
++	dnl Move to O2 due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543
++	if [[ $cpu_power_compatible -eq 1 ]]
++	then
++	CCOPTIMISATIONFLAGS=-O2
++	fi
++	
+ AM_CONDITIONAL([USES_ICC], [false])
+ AM_CONDITIONAL([USES_GCC], [true])
+ AM_CONDITIONAL([USES_CLANG], [false])
diff -Nru yadifa-2.2.2/debian/patches/series yadifa-2.2.2/debian/patches/series
--- yadifa-2.2.2/debian/patches/series	2016-11-08 06:21:48.0 -0500
+++ yadifa-2.2.2/debian/patches/series	2016-11-28 15:12:20.0 -0500
@@ -5,3 +5,4 @@
 fix-yadifad-spelling.patch
 fix-yadifarc-manpage.patch
 do-not-use-or-define-the-compile-date.patch
+fix-ppc64el_ftbfs.patch

Bug#843832: needrestart: detect need for a systemctl daemon-reload

[Thomas Liske]

tags 843832 wontfix
thanks

Hi Paul,


needrestart tries to detect which daemons (read: processes in the
broadest sense) should be restarted due to upgraded libraries (read:
code to be somehow *executed*). Configuration files etc. are beyond the
scope of needrestart (maybe there should be a mechanism around apt to
handle reloading systemd).


HTH,
Thomas


Paul Wise  writes:

> Package: needrestart
> Severity: wishlist
>
> When systemd service configuration files are modified, there is often a
> need to ask the systemd daemons to reload their configuration files:
>
> systemctl daemon-reload
> sudo -u uid systemctl --user daemon-reload
>
> The need to reload systemd service configuration files can be detected
> using these commands, passing the names of all loaded units.
>
> systemctl --property NeedDaemonReload show name.service other.service
> sudo -u uid systemctl --user --property NeedDaemonReload show name.service 
> other.service
>
> The list of loaded units can be found using these commands:
>
> systemctl --all list-units
> sudo -u uid systemctl --user systemctl --all list-units
>
> Unfortunately it doesn't appear to be machine-parsable.
>
> -- 
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

-- 

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  Jabber:   xmpp:tho...@jabber.fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::