Bug#815216: Backport gitlab to jessie

[Pirate Praveen]

Package: gitlab
Severity: wishlist

This would enable people to setup gitlab on debian stable.

I have created a script here https://gitlab.com/debian-ruby/backportr

Once I complete the build, I will make a personal repo first and will consider 
uploading to jessie-backports (after fixing test failures of some dependencies).

lib/gitlab_notes.txt at the backportr repo has the manual steps documented.

Bug#815214: boinc-client: boinc client not updating log files

[Preston Maness]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Ugh. Fuckin' mail clients. It mangled my ExecStart line (and is still
trying to mangle it). My service file looks like this presently:

http://pastebin.com/103cK3Ym

Cheers,
Preston Maness

On 02/20/2016 01:20 AM, Preston Maness wrote:
> Howdy everyone,
> 
> Since boinc-client is now handled by the systemd service file,
> systemd is determining where stdout and stderr go. You can run
> "journalctl -u boinc-client.service" to get the logs, and if
> systemd has been set up to also dump to syslog, the logs should be
> in /var/log/syslog as well (I don't know if Debian defaults to
> this, or if I had set systemd to dump logs there forever ago and
> have just forgotten about it).
> 
> Looking at the source code, it looks like there isn't an option
> for cc_config.xml to specify where to put the logs. Originally, the
> init script was utilized to appropriately redirect stdout and
> stderr as needed with the LOGFILE and ERRORLOG environment
> variables respectively, which ultimately were fed into the final
> command that started the boinc-client. As well, there is also a
> "--redirectio" flag that the boinc-client binary itself recognizes,
> which will redirect stdout and stderr to files in the BOINCDIR
> environment variable instead.
> 
> Taking a look at the environment variables for my running
> boinc-client at the moment, these are obviously not present:
> 
> # cat /proc/$(pidof boinc)/environ 
> LANG=en_US.UTF-8PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binHOME=/var/lib/boinc-clientLOGNAME=boincUSER=boincSHELL=/bin/false
>
>  (I'm not sure what LOGNAME is doing there, but I'm ignoring it)
> 
> Presumably, we should still be able to redirect the output as we 
> desire by modifying the boinc-client.service file's "ExecStart" 
> command. Looks like we're certainly not the only ones to run into
> this:
> 
> https://stackoverflow.com/questions/32968506/how-to-pipe-output-to-a-file-when-running-as-a-systemd-service
>
>  So something like:
> 
> ExecStart=/bin/sh -c '/usr/bin/boinc --dir /var/lib/boinc-client
>> /var/log/boinc.log 2>/var/log/boincerr.log'
> 
> or whatever else is desired should work.
> 
> And...
> 
> I changed my unit file's ExecStart to look like that, reloaded the 
> unit files via "systemctl daemon-reload", restarted boinc via 
> "systemctl restart boinc", and then the log files were written to
> again.
> 
> Cheers, Preston Maness
> 
> P.S. - With respect to the other bug 813728 where the log has a
> bunch of "No protocol specified" messages, I'm still thinking about
> how to handle that one. The xorg-server is ultimately responsible
> for the messages getting written. I'll fiddle with the freopen idea
> and see if anything obvious breaks. Though honestly, I'm more
> inclined to just leave things as-is. It's easy enough to rotate
> logs and grep out any lines you don't want. Incidentally, with the
> change to the ExecStart line, the "No Protocol Specified" lines get
> tossed into /var/log/boincerr.log so they're not polluting the
> main /var/log/boinc.log file. So that's nice. Honestly, that's
> probably going to be my answer to that bug.
> 
> On 02/20/2016 12:50 AM, mark wrote:
>> Package: boinc-client Version: 7.6.25+dfsg-1 Severity: important
> 
>> Dear Maintainer,
> 
>> As per email discussions with Gianfranco the boinc-client no
>> longer seems to be updating its log files. This first occured on
>> a number of Raspberry Pi's running the Stretch release around
>> October 2015. This seems to have made its way into the amd64
>> build around January 2016.
> 
>> To try and narrow down the issue I have done the following:
> 
>> I have wiped the machine, downloaded Jessie 8.3 netinst(amd64)
>> and installed it. Removed x11-*. Sure its the old one and
>> boinc-client 7.4.23 works as expected. Log files are in
>> /var/lib/boinc-client. Nothing in /var/log.
> 
>> Changed sources-list to point to Stretch and did a dist-upgrade 
>> which along with everything else updated boinc to 7.6.25. After 
>> install log files in /var/lib/boinc-client are no longer updated.
>>  There are two log files in /var/log now, both zero bytes.
> 
>> Things the Rpi and amd64 have in common is x11-* was removed 
>> (however x11-common gets installed by the dist-upgrade). Stretch
>>  has GCC 5 whereas Jessie is still on GCC 4.9. I also have two 
>> Parallella that use Gianfranco's Ubuntu ppa and they work as 
>> expected (Ubuntu Trusty). The Parallella's also have x11-* 
>> removed.
> 
>> * What led up to the situation? dist-upgrade to Stretch
> 
>> * What exactly did you do (or not do) that was effective (or 
>> ineffective)? clean install Jessie followed by dist-upgrade to 
>> Stretch
> 
>> * What was the outcome of this action? Log files no longer
>> getting updated
> 
>> * What outcome did you expect instead? Log files to work as
>> before
> 
> 
>> -- Package-specific info: -- Contents of 
>> /etc/default/boinc-client: # This file is 
>> 

Bug#815176: staden: Gap4 contig editor does not show sequences

[Andreas Tille]

Hi Kerstin,

thanks agein for your bug report.  I agree that this problem might be a
bit more tricky than the other bug.  I have a slight suspicion that this
user oriented issue might be connected to a later Tcl/Tk version than
you might have used before.

Since I feel unable to track this down I have included upstream in CC
to ask for help.

Kind regards

 Andreas.

On Fri, Feb 19, 2016 at 06:56:36PM +0100, Kerstin Hoef-Emden wrote:
> Package: staden
> Version: 2.0.0+b10-1.1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> 
> I loaded pregap-converted *.exp sequences into gap4 to do an assembly. The
> assembly worked out, but I cannot open the contig editor for proofreading.
> More correctly described: It actually opens, but only the upper window bar
> is visible, neither sequences nor trace files are displayed. Since no
> information on this problem shows up in the log files of gap4, I have got no
> idea concerning the nature of the problem. Perhaps something connected to
> the graphical surface?
> 
> Before upgrading to jessie, I had staden from the sourceforge site installed
> and it worked, but under jessie I have got the problem with both, the debian
> and with the sourceforge package.
> 
> Kerstin
> 
> 
> 
> -- System Information:
> Debian Release: 8.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages staden depends on:
> ii  libc62.19-18+deb8u3
> ii  libcurl3 7.38.0-4+deb8u3
> ii  libfontconfig1   2.11.0-6.3
> ii  libfreetype6 2.5.2-3+deb8u1
> ii  libgcc1  1:4.9.2-10
> ii  liblzma5 5.1.1alpha+20120614-2+b3
> ii  libpng12-0   1.2.50-2+deb8u2
> ii  libstaden-read1  1.13.7-1
> ii  libstdc++6   4.9.2-10
> ii  libtcl8.68.6.2+dfsg-2
> ii  libtk8.6 8.6.2-1
> ii  libx11-6 2:1.6.2-3
> ii  libxext6 2:1.3.3-1
> ii  libxft2  2.3.2-1
> ii  libxss1  1:1.2.2-1
> ii  staden-common2.0.0+b10-1.1
> ii  staden-io-lib-utils  1.13.7-1
> ii  tklib0.6-1
> ii  zlib1g   1:1.2.8.dfsg-2+b1
> 
> staden recommends no packages.
> 
> Versions of packages staden suggests:
> pn  staden-doc  
> 
> -- no debconf information
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#815174: staden: Missing links in /usr/bin

[Andreas Tille]

Hi Kerstin,

thanks a lot for this bug report which is really appreciated as well as
the analysis of the error and the hint for a fix.  I've not decided
whether we really should provide eba itself in /usr/bin or whether it
might be better to use wrapper scripts setting the PATH to
/usr/lib/staden/bin.  The question is whether eba is a user oriented
application itself or just an internal helper.

Trusting your insight as a user I wonder what you might think about
the role of eba.

Kind regards

 Andreas.

On Fri, Feb 19, 2016 at 06:48:41PM +0100, Kerstin Hoef-Emden wrote:
> Package: staden
> Version: 2.0.0+b10-1.1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> I tried to convert *.ab1 files to *.exp files with pregap4, which failed
> with an error message that eba could not be found. I copied an eba from the 
> sourceforge download bay into /usr/bin and retried
> conversion of the ABI chromatograms. The error message concerning eba was
> gone, instead conversion failed because of a missing init_exp command.
> Thereafter I had a closer look into /usr/bin and realized that the staden
> parts were links to /usr/lib/staden/bin, but of the multiple files in
> the sourceforge package, only pregap, gap4, gap5, trev and spin had such a 
> link.
> 
> I thus, created the missing links by hand and conversion worked out. The
> files could be opened and assembled with gap4. Working furtheron with the
> files, however, is still hampered by another problem, which I suspect to be
> of a different kind, thus will be subject to a separate bug report.
> 
> Kerstin
> 
> 
> -- System Information:
> Debian Release: 8.3
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages staden depends on:
> ii  libc62.19-18+deb8u3
> ii  libcurl3 7.38.0-4+deb8u3
> ii  libfontconfig1   2.11.0-6.3
> ii  libfreetype6 2.5.2-3+deb8u1
> ii  libgcc1  1:4.9.2-10
> ii  liblzma5 5.1.1alpha+20120614-2+b3
> ii  libpng12-0   1.2.50-2+deb8u2
> ii  libstaden-read1  1.13.7-1
> ii  libstdc++6   4.9.2-10
> ii  libtcl8.68.6.2+dfsg-2
> ii  libtk8.6 8.6.2-1
> ii  libx11-6 2:1.6.2-3
> ii  libxext6 2:1.3.3-1
> ii  libxft2  2.3.2-1
> ii  libxss1  1:1.2.2-1
> ii  staden-common2.0.0+b10-1.1
> ii  staden-io-lib-utils  1.13.7-1
> ii  tklib0.6-1
> ii  zlib1g   1:1.2.8.dfsg-2+b1
> 
> staden recommends no packages.
> 
> Versions of packages staden suggests:
> pn  staden-doc  
> 
> -- no debconf information
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#815214: boinc-client: boinc client not updating log files

[Preston Maness]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Howdy everyone,

Since boinc-client is now handled by the systemd service file, systemd
is determining where stdout and stderr go. You can run "journalctl -u
boinc-client.service" to get the logs, and if systemd has been set up
to also dump to syslog, the logs should be in /var/log/syslog as well
(I don't know if Debian defaults to this, or if I had set systemd to
dump logs there forever ago and have just forgotten about it).

Looking at the source code, it looks like there isn't an option for
cc_config.xml to specify where to put the logs. Originally, the init
script was utilized to appropriately redirect stdout and stderr as
needed with the LOGFILE and ERRORLOG environment variables
respectively, which ultimately were fed into the final command that
started the boinc-client. As well, there is also a "--redirectio" flag
that the boinc-client binary itself recognizes, which will redirect
stdout and stderr to files in the BOINCDIR environment variable instead.

Taking a look at the environment variables for my running boinc-client
at the moment, these are obviously not present:

# cat /proc/$(pidof boinc)/environ
LANG=en_US.UTF-8PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binHOME=/var/lib/boinc-clientLOGNAME=boincUSER=boincSHELL=/bin/false

(I'm not sure what LOGNAME is doing there, but I'm ignoring it)

Presumably, we should still be able to redirect the output as we
desire by modifying the boinc-client.service file's "ExecStart"
command. Looks like we're certainly not the only ones to run into this:

https://stackoverflow.com/questions/32968506/how-to-pipe-output-to-a-file-when-running-as-a-systemd-service

So something like:

ExecStart=/bin/sh -c '/usr/bin/boinc --dir /var/lib/boinc-client
> /var/log/boinc.log 2>/var/log/boincerr.log'

or whatever else is desired should work.

And...

I changed my unit file's ExecStart to look like that, reloaded the
unit files via "systemctl daemon-reload", restarted boinc via
"systemctl restart boinc", and then the log files were written to again.

Cheers,
Preston Maness

P.S. - With respect to the other bug 813728 where the log has a bunch
of "No protocol specified" messages, I'm still thinking about how to
handle that one. The xorg-server is ultimately responsible for the
messages getting written. I'll fiddle with the freopen idea and see if
anything obvious breaks. Though honestly, I'm more inclined to just
leave things as-is. It's easy enough to rotate logs and grep out any
lines you don't want. Incidentally, with the change to the ExecStart
line, the "No Protocol Specified" lines get tossed into
/var/log/boincerr.log so they're not polluting the main
/var/log/boinc.log file. So that's nice. Honestly, that's probably
going to be my answer to that bug.

On 02/20/2016 12:50 AM, mark wrote:
> Package: boinc-client Version: 7.6.25+dfsg-1 Severity: important
> 
> Dear Maintainer,
> 
> As per email discussions with Gianfranco the boinc-client no longer
> seems to be updating its log files. This first occured on a number
> of Raspberry Pi's running the Stretch release around October 2015.
> This seems to have made its way into the amd64 build around January
> 2016.
> 
> To try and narrow down the issue I have done the following:
> 
> I have wiped the machine, downloaded Jessie 8.3 netinst(amd64) and
>  installed it. Removed x11-*. Sure its the old one and boinc-client
>  7.4.23 works as expected. Log files are in /var/lib/boinc-client.
>  Nothing in /var/log.
> 
> Changed sources-list to point to Stretch and did a dist-upgrade 
> which along with everything else updated boinc to 7.6.25. After 
> install log files in /var/lib/boinc-client are no longer updated. 
> There are two log files in /var/log now, both zero bytes.
> 
> Things the Rpi and amd64 have in common is x11-* was removed 
> (however x11-common gets installed by the dist-upgrade). Stretch 
> has GCC 5 whereas Jessie is still on GCC 4.9. I also have two 
> Parallella that use Gianfranco's Ubuntu ppa and they work as 
> expected (Ubuntu Trusty). The Parallella's also have x11-* 
> removed.
> 
> * What led up to the situation? dist-upgrade to Stretch
> 
> * What exactly did you do (or not do) that was effective (or 
> ineffective)? clean install Jessie followed by dist-upgrade to 
> Stretch
> 
> * What was the outcome of this action? Log files no longer getting
>  updated
> 
> * What outcome did you expect instead? Log files to work as before
> 
> 
> -- Package-specific info: -- Contents of
> /etc/default/boinc-client: # This file is
> /etc/default/boinc-client, it is a configuration file for the #
> /etc/init.d/boinc-client init script.
> 
> # Set this to 1 to enable and to 0 to disable the init script. 
> ENABLED="1"
> 
> # Set this to 1 to enable advanced scheduling of the BOINC core 
> client and # all its sub-processes (reduces the impact of BOINC on
>  the system's # performance). SCHEDULE="1"
> 
> # The BOINC core client will be 

Bug#815215: gemrb: package builds in experimental SDL2-GL plugin, excludes stable SDL1.2 plugin

[Dylan Morrison]

Package: gemrb
Version: 0.8.3-1
Severity: important

Dear Maintainer,

While playing around with gemrb, I found that I could not get the TTF font 
rendering plugin to work without
encountering an immediate Segmentation fault during the font loading process. 
When attempting to report this
bug upstream, I was told that this bug is likely due to the fact that Debian is 
packaging in the SDL2-GL video
plugin for GemRB, which is considered a WIP and not ready for primetime, 
instead of packaging in the mature
and stable SDL1.2 video plugin. I could not find the SDL1.2 plugin or a way to 
load it instead in the debian
gemrb package. It's my belief that as of 0.8.3 the SDL2 code is not stable 
enough to be built in by default
in the debian package, and that we should hold off on building it with SDL2 
support, or at least restrict
this to unstable/experimental.

The thread where I talked to the upstream developers about this is linked below:

http://gibberlings3.net/forums/index.php?showtopic=27867

Thanks for your attenion to this issue,
Dylan J Morrison

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

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

Versions of packages gemrb depends on:
ii  gemrb-data  0.8.3-1
ii  libc6   2.21-7
ii  libgcc1 1:5.3.1-8
ii  libgemrb0.8.3-1
ii  libstdc++6  5.3.1-8
ii  python  2.7.11-1

Versions of packages gemrb recommends:
ii  game-data-packager  44
ii  innoextract 1.5-1
pn  lgogdownloader  

gemrb suggests no packages.

-- no debconf information

Bug#815213: ITP: puppet-module-sbitio-monit -- Puppet module for Monit

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-sbitio-monit
  Version : 1.0.0
  Upstream Author : Jonathan Araña Cruz 
* URL : https://github.com/sbitio/puppet-monit
* License : Mit
  Programming Lang: Ruby, Puppet
  Description : Puppet module for Monit

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 Performs installation and configuration of Monit service, along with fine
 grained definition of checks.
 .
 All check types provided by Monit are supported. Namely: directory, fifo,
 file, filesystem, host, process, program, and system.
 .
 In adition to primitive types, a compound check type is provided: service. It
 is a set of primitives to check a service's init script, binary and process.
 .
 service check type can work with sysv, systemd or upstart. In 0.3.x series it
 defaults to sysv for compatibility reasons. From 1.0.x onwards it defaults to
 the init system that each supported OS configures by default. The init type to
 use can be also set per service. See below for details.

Bug#815212: lilypond: Changing the output paper size is "hard"

[Karl O. Pinc]

Package: lilypond
Version: 2.18.2-4
Severity: wishlist

Hi,

It'd be nice if lilypond had a better way of specifying paper
size.  It defaults to a4 and figuring out how to set it to
letter is non-trivial for the inexperienced.

For the record, one approach is:

  lilypond -dpaper-size='"letter"' foo.ly

It'd be especially nice if lilypond used /etc/papersize.

It'd be nice if lilypond had a PAPERSIZE env var, and/or
a shortcut --paper-size command line option.

It'd be nice if any of the above was mentioned in the man page.

A ~/.lilypond/config file (or some such) containing default command
line option values wouldn't hurt either.

Thanks for listening.

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

Kernel: Linux 3.16.0-4-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 lilypond depends on:
ii  ghostscript9.06~dfsg-2+deb8u1
ii  guile-1.8  1.8.8+1-10
ii  guile-1.8-libs 1.8.8+1-10
ii  libc6  2.19-18+deb8u3
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.5.2-3+deb8u1
ii  libgcc11:4.9.2-10
ii  libglib2.0-0   2.42.1-1
ii  libgmp10   2:6.0.0+dfsg-6
ii  libltdl7   2.4.2-1.11
ii  libpango-1.0-0 1.36.8-3
ii  libpangoft2-1.0-0  1.36.8-3
ii  libstdc++6 4.9.2-10
ii  lilypond-data  2.18.2-4
ii  python 2.7.9-1

Versions of packages lilypond recommends:
ii  lilypond-doc2.18.2-4
ii  texlive-latex-base  2014.20141024-2

lilypond suggests no packages.

-- no debconf information

Bug#815211: kontact: kMail import of old kmail dir fails

[Jan Eringa]

Package: kontact
Version: 4:4.14.10-2
Severity: important

Dear Maintainer,

   * What led up to the situation?
 After starting kontact/kMail none of my existing e-mails were visable
 My mail dir is directly under my home dir as I've had problems in the pas 
with kde/kmail 
 destroying mu archived mails so everything is now under /home//Mail

   * What exactly did you do (or not do) that was effective (or ineffective)?
 I moved the Mail directory sideways (Mail-old) and removed all the 
kmail/contact config from 
 ~/.kde ~/.local etc and restarted kontact clean and created a basic config
 Then created a new sub-folder to import the old kMail content & started 
the import

   * What was the outcome of this action?
 My old archived email to be imported

   * What outcome did you expect instead?
 I keep seeing the following dialog

 Error: Could not add message to folder new. Reason: Unknown collection for 
'279'.

 There are THOUSANDS of these messages & no way to say YES to all or figure 
out what is wrong/broken
 I'm concerned that e-mails from my old Mail folder will not be imported

 Is there a way for me to export my saved data to another format 
(Evolution, IceDove, Other???) 
 ias I'm really starting to worry that kMail/kontact is no longer a safe 
place for me to store my e-mails

 Destroying/loosing user data is IMHO a really bad thing :(



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

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

Versions of packages kontact depends on:
ii  kde-runtime   4:15.08.3-1+b1
ii  libc6 2.21-7
ii  libkcmutils4  4:4.14.14-1+b1
ii  libkdecore5   4:4.14.14-1+b1
ii  libkdepim44:4.14.10-2
ii  libkdepimdbusinterfaces4  4:4.14.10-2
ii  libkdeui5 4:4.14.14-1+b1
ii  libkdewebkit5 4:4.14.14-1+b1
ii  libkio5   4:4.14.14-1+b1
ii  libkontactinterface4a 4:4.14.10-1
ii  libkparts44:4.14.14-1+b1
ii  libkpimidentities44:4.14.10-1
ii  libkpimutils4 4:4.14.10-1
ii  libqt4-dbus   4:4.8.7+dfsg-5
ii  libqtcore44:4.8.7+dfsg-5
ii  libqtgui4 4:4.8.7+dfsg-5
ii  libqtwebkit4  2.3.4.dfsg-6
ii  libstdc++65.3.1-8

Versions of packages kontact recommends:
ii  akregator 4:4.14.10-2
ii  kaddressbook  4:4.14.10-2
ii  kmail 4:4.14.10-2
ii  knotes4:4.14.10-2
ii  korganizer4:4.14.10-2

Versions of packages kontact suggests:
pn  gnokii
ii  kjots 4:4.14.10-2
ii  knode 4:4.14.10-2
ii  ktimetracker  4:4.14.10-2

-- no debconf information

Bug#815210: ccache: Support cross compilers in /usr/lib/gcc-cross

[Vagrant Cascadian]

Package: ccache
Version: 3.2.4-1
Severity: normal

Thanks for maintaining ccache, it's hugely useful!

When installing gcc-5-arm-linux-gnueabihf, compilers such as
/usr/bin/arm-linux-gnueabihf-gcc-5 are not installed with ccache.  The
compilers are installed into /usr/lib/gcc-cross/arm-linux-gnueabihf.
I'm not sure what all would be necessary to support them in this path.

With gcc-4.9-arm-linux-gnueabihf, it worked because it installed
compilers in /usr/lib/gcc/TRIPLET, and ccache appeared to find and
configure these compilers just fine.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#815209: poedit: missing Crowdin integration

[Janusz S. Bień]

Package: poedit
Version: 1.8.7-1
Severity: normal

It is present upstream since 1.8.

I understand it was removed intentionally due to some technical
problems, but perhaps they have been solved in the meantime.

Best regards

Janusz

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

Kernel: Linux 4.1.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 poedit depends on:
ii  gettext0.19.7-2
ii  libboost-system1.58.0  1.58.0+dfsg-4.1
ii  libc6  2.21-8
ii  libcld2-0  0.0.0-git20150806-2
ii  libdb5.3++ 5.3.28-11
ii  libexpat1  2.1.0-7
ii  libgcc11:5.3.1-8
ii  libglib2.0-0   2.46.2-3
ii  libgtk2.0-02.24.29-1
ii  libgtkspell0   2.0.16-1.1
ii  libicu55   55.1-7
ii  liblucene++0v5 3.0.7-8
ii  libstdc++6 5.3.1-8
ii  libwxbase3.0-0v5   3.0.2+dfsg-1.2
ii  libwxgtk3.0-0v53.0.2+dfsg-1.2
ii  poedit-common  1.8.7-1

poedit recommends no packages.

poedit suggests no packages.

-- no debconf information

-- 
   ,   
Prof. dr hab. Janusz S. Bien -  Uniwersytet Warszawski (Katedra Lingwistyki 
Formalnej)
Prof. Janusz S. Bien - University of Warsaw (Formal Linguistics Department)
jsb...@uw.edu.pl, jsb...@mimuw.edu.pl, http://fleksem.klf.uw.edu.pl/~jsbien/

Bug#511814: ipmievd: can't change syslog facility

[Jörg Frings-Fürst]

Hi,

I close this bug again. It was reopened without any comments and the
future isn't into upstream since more then 6 years.


If you need this future please file a new upstream bug. 

Thank you for spending your time helping to make Debian better with
this bug report. 


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-54538 Bausendorf

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#765639: affecting more and more people

[Simon Ruggier]

On Mon, 15 Feb 2016 18:59:46 + "Adam D. Barratt" <
a...@adam-barratt.org.uk> wrote:
> On Mon, 2016-02-15 at 19:46 +0100, Christian Beer wrote:
> > Hi,
> >
> > there are more people reporting that they are directly affected by a bug
> > in the Debian Jessie openssl package where it doesn't check an
> > alternative certificate chain (which is fixed in the latest upstream
1.0.1).
> [...]
> > Right now the combination of openssl and ca-certificates in Debian
> > Jessie is not working for a lot of websites (that they themselves can't
> > fix). I understand the hesitation to upgrade openssl but I would like to
> > return to a working Jessie rather than use an obviously broken one.
>
> If it's that broken, then it should be fixed anyway, regardless of any
> decision of whether or not to accept full upstream releases in to
> Jessie.
>
> Regards,
>
> Adam

As a long-time Debian user who is indirectly affected by this issue, I'd
like to see Debian simply adopt the upstream 1.0.2 releases instead of
trying to maintain a messy fork that contains a mix of 1.0.1 and backported
1.0.2 changes. Staying as close as possible to upstream benefits Debian by
using releases that have been reviewed and tested by both upstream and also
other OpenSSL users. Every change backported onto Debian's stable version
of OpenSSL also carries the risk of creating a new security vulnerability
unique to Debian, and staying close to upstream minimizes this. Although
upstream could introduce bugs in their new releases, the same is equally
true when Debian makes its own releases from backported changes.

Some upstreams do not make releases that are suitable for reuse as SRUs, so
I think this kind of policy may need to be decided on a case by case basis.
In the case of OpenSSL, it' a mature, widely used package whose releases
consist mostly of security updates anyway, and they've also promised not to
break binary compatibility between last-digit releases like 1.0.1 and
1.0.2.[1] There seems to be little justification for the risk and
significant effort required to maintain a fork that sits in between 1.0.1
and 1.0.2, and I think that if new upstream releases do introduce problems,
Debian is better off working directly with upstream than trying to do its
own completely separate OpenSSL development.

Also, my own testing seems to show that the certificate chain issue is
still present in the latest 1.0.1 release (as I commented on 813468), so
adopting the latest 1.0.2 release seems like the only reasonable
alternative.

[1] https://www.openssl.org/policies/releasestrat.html

Bug#660304: uploaded

[Rogério Brito]

Hi, Daniel.

On Fri, Feb 19, 2016 at 7:18 AM, Daniel Pocock  wrote:
> I've made an upload of this package today.
>
> It is in the debian-science repository.

Thanks a lot for the upload and the update, Daniel! Not only for
r-can-tm but also for all the other r-cran-* packages that I just saw
on the NEW queue of ftpmaster!


Thanks once again,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#815208: sasl2-bin: auth_rimap infinite loop (hang) when IMAP server closes connection

[Jered Floyd]

Package: sasl2-bin
Version: 2.1.26.dfsg1-13+deb8u1jf1
Severity: important
Tags: upstream patch

Dear Maintainer,

I run Zimbra Collaboration Server (ZCS 8.5.x) which send a BYE and closes the 
connection on failed authentication.  This causes auth_rimap to go into an 
infinite loop as its criteria for if data is available on the socket is 
incorrect.

This bug was introduced by the patch for upstream bug #3211, included in 
cyrus-sasl2 2.1.26.  The while() loop at auth_rimap.c:607 (line #496 upstream) 
has incorrect exit criteria -- if the socket is closed and the fd is at EOF the 
loop will not exit.

A patch is attached, which I have tested and confirmed resolves the issue.  
This patch stacks onto cyrus-sasl2_2.1.26.dfsg1-13+deb8u1.

I have submitted this bug and patch upstream, and it is tracked as bug #3920: 
https://bugzilla.cyrusimap.org/show_bug.cgi?id=3920

Sample IMAP exchange:
  S:   * OK IMAP4 ready
  C:   saslauthd LOGIN "test" "test"
  S:   saslauthd NO LOGIN failed
  S:   * BYE Zimbra IMAP server terminating connection
  Server closes connection

Sample strace:
  alarm(30)   = 0
  read(12, "* OK IMAP4 ready\r\n", 1000)  = 18
  alarm(0)= 30
  select(13, [12], NULL, NULL, {1, 0})= 0 (Timeout)
  sendto(4, "<39>Feb 19 21:20:24 saslauthd[55"..., 100, MSG_NOSIGNAL, NULL, 0) 
= 100
  alarm(30)   = 0
  writev(12, [{"saslauthd LOGIN ", 16}, {"\"test\"", 6}, {" ", 1}, {"\"test\"", 
6}, {"\r\n", 2}], 5) = 31
  alarm(0)= 30
  alarm(30)   = 0
  read(12, "saslauthd NO LOGIN failed\r\n", 1000) = 27
  alarm(0)= 20
  select(13, [12], NULL, NULL, {1, 0})= 1 (in [12], left {0, 999831})
  read(12, "* BYE Zimbra IMAP server termina"..., 973) = 49
  select(13, [12], NULL, NULL, {0, 999831}) = 1 (in [12], left {0, 999719})
  read(12, "", 924)   = 0
  select(13, [12], NULL, NULL, {0, 999719}) = 1 (in [12], left {0, 999717})
  read(12, "", 924)   = 0
  select(13, [12], NULL, NULL, {0, 999717}) = 1 (in [12], left {0, 999715})
etc.

Regards,
--Jered



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
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 sasl2-bin depends on:
ii  db-util5.3.0
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18+deb8u3
ii  libcomerr2 1.42.12-1.1
ii  libdb5.3   5.3.28-9
ii  libgssapi-krb5-2   1.12.1+dfsg-19+deb8u2
ii  libk5crypto3   1.12.1+dfsg-19+deb8u2
ii  libkrb5-3  1.12.1+dfsg-19+deb8u2
ii  libldap-2.4-2  2.4.40+dfsg-1+deb8u2
ii  libpam0g   1.1.8-3.1+deb8u1
ii  libsasl2-2 2.1.26.dfsg1-13+deb8u1jf1
ii  libssl1.0.01.0.1k-3+deb8u2

sasl2-bin recommends no packages.

sasl2-bin suggests no packages.

-- Configuration Files:
/etc/default/saslauthd changed [not included]

-- debconf information excluded
--- a/saslauthd/auth_rimap.c
+++ b/saslauthd/auth_rimap.c
@@ -494,7 +494,7 @@
 while( select (fds, , NULL, NULL,  ) >0 ) {
if ( FD_ISSET(s, ) ) {
   ret = read(s, rbuf+rc, sizeof(rbuf)-rc);
-  if ( ret<0 ) {
+  if ( ret<=0 ) {
  rc = ret;
  break;
   } else {
@@ -607,7 +607,7 @@
 while( select (fds, , NULL, NULL,  ) >0 ) {
if ( FD_ISSET(s, ) ) {
   ret = read(s, rbuf+rc, sizeof(rbuf)-rc);
-  if ( ret<0 ) {
+  if ( ret<=0 ) {
  rc = ret;
  break;
   } else {

Bug#815089: libimage-exiftool-perl: extract timestamp hash/algo of signed+timestamped PDF

[Fulano Diego Perez]

i grepped through some other signed PDFs created from within Adobe
Acrobat, signed with differing CA certs and timestamp servers and
DigestAlgos - they all report the same md5 DigestValue...(?)

disappointingly, tests with LibreOffice Writer signed/timestamped PDFs
did not display a DigestValue. LO 5 can sign/timestamp exported PDFs but
only timestamp from a non-AUTH http[s] timestamp server

see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810723

shall await mr exiftool's prognosis of DigestValue...

Bug#813562: Test suite failure

[James R Barlow]

Thanks for your help. Output order is due to multiprocessing.

That nailed it. tesseract 3.04.01 changed its output when asked to
determine page orientation. It's an improved, but it breaks parsing.

I will throw together a patch to make the appropriate distinctions.


$ tess-3.04.01 -psm 0 tests/resources/linn-west.jpg stdout
Page number: 0
Orientation in degrees: 270
Rotate: 90
Orientation confidence: 29.34
Script: Latin
Script confidence: 45.33

$ tess-3.04.00 -psm 0 tests/resources/linn-west.jpg stdout
Orientation: 3
Orientation in degrees: 90
Orientation confidence: 29.34
Script: 1
Script confidence: 45.33



On Fri, Feb 19, 2016 at 16:28 Sean Whitton  wrote:

> Hello,
>
> On Fri, Feb 19, 2016 at 10:45:51PM +, James R Barlow wrote:
> > In any case, could you try running this:
> > ocrmypdf --rotate-pages tests/resources/cardinal.pdf out.pdf
> >
> > In cardinal.pdf the same page is rotated in each cardinal direction.
> out.pdf
> > should have all pages facing up. Is this the case? The output will also
> give
> > information on rotation status:
> > INFO - 1: page is facing ⇧, confidence 18.69
> > INFO - 3: page is facing ⇩, confidence 21.86 - correcting rotation
> > INFO - 4: page is facing ⇦, confidence 20.71 - correcting rotation
> > INFO - 2: page is facing ⇨, confidence 21.63 - correcting rotation
> > INFO - 3: rotating image layer 180 degrees
> > INFO - 2: rotating image layer 90 degrees
> > INFO - 4: rotating image layer 270 degrees
>
> No, it gets it wrong.  Result attached, and the output:
>
> ,
> | root@artemis:/build/ocrmypdf-4.0.1# ocrmypdf --rotate-pages
> tests/resources/cardinal.pdf out.pdf
> | INFO -1: page is facing ⇧, confidence 18.69
> | INFO -2: page is facing ⇦, confidence 21.63 - correcting rotation
> | INFO -3: page is facing ⇩, confidence 21.86 - correcting rotation
> | INFO -4: page is facing ⇨, confidence 20.71 - correcting rotation
> | INFO -2: rotating image layer 270 degrees
> | INFO -3: rotating image layer 180 degrees
> | INFO -4: rotating image layer 90 degrees
> `
>
> (note that the order it processes the pages in is different to your
> example)
>
> > It would also help to try in python3:
> >
> > >>> import ocrmypdf.leptonica as lp
> > >>> lp.getLeptonicaVersion()
> >
> > ...to see if there's anything unusual about how debian sid is reporting
> the
> > leptonica version.
>
> ,
> | root@artemis:/build/ocrmypdf-4.0.1# cd /usr/lib/python3/dist-packages
> | root@artemis:/usr/lib/python3/dist-packages# python3
> | Python 3.5.1+ (default, Jan 13 2016, 15:09:18)
> | [GCC 5.3.1 20160101] on linux
> | Type "help", "copyright", "credits" or "license" for more information.
> | >>> import ocrmypdf.leptonica as lp
> | >>> lp.getLeptonicaVersion()
> | 'leptonica-1.73'
> `
>
> --
> Sean Whitton
>

Bug#815207: yaws: man 5 yaws.conf inaccurate

[Jiff]

Package: yaws
Version: 2.0.2-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
man 5 yaws.conf

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
The deflate section mention a primitive named: "compress_level",
this is wrong.

   * What was the outcome of this action?
The actual name of this primitive is: "compression_level".



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

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

Versions of packages yaws depends on:
ii  adduser  3.113+nmu3
ii  erlang-yaws  2.0.2-1
ii  lsb-base 9.20160110
ii  ssl-cert 1.0.37

yaws recommends no packages.

Versions of packages yaws suggests:
ii  erlang-yapp  2.0.2-1
ii  logrotate3.8.7-2
ii  yaws-chat2.0.2-1
ii  yaws-doc 2.0.2-1
pn  yaws-mail
ii  yaws-wiki2.0.2-1
ii  yaws-yapp2.0.2-1

-- Configuration Files:
/etc/yaws/conf.avail/localhost-ssl.conf [Errno 13] Permission denied: 
u'/etc/yaws/conf.avail/localhost-ssl.conf'
/etc/yaws/conf.avail/localhost.conf [Errno 13] Permission denied: 
u'/etc/yaws/conf.avail/localhost.conf'
/etc/yaws/yaws.conf [Errno 13] Permission denied: u'/etc/yaws/yaws.conf'

-- no debconf information

Bug#813468: [Pkg-openssl-devel] Bug#813468: cross-references and workaround

[Simon Ruggier]

On Tue, 2 Feb 2016 19:14:24 +0100 Kurt Roeckx  wrote:
>[ ...]
> On Tue, Feb 02, 2016 at 03:04:41PM +0100, Christian Beer wrote:
> > Since it works in openssl 1.0.2 you can either upgrade the package in
> > Jessie to 1.0.2 (which is unlikely I think) or backport the fix for
> > 1.0.2 to 1.0.1 upstream (which is even more unlikely).
>
> This has already been fixed in the upstream 1.0.1 release of a
> year ago.

Can you elaborate on which release of 1.0.1 you think fixes this
issue? I've looked in the 1.0.1 changelog[1] and I don't see any items
that look like they would address this. To confirm my suspicion, I
downloaded and built the 1.0.1r tarball and tested it, it still fails
to accept a valid certificate whose trust chain should end in a
non-self-signed/intermediate certificate. In my case, I'm looking at a
site whose trust chain ends with the Baltimore CyberTrust Root, which
is "issued by" the weak GTE CyberTrust Global Root that is now gone
from ca-certificates. The openssl 1.0.2f command from stretch accepts
it, while 1.0.1 tries and fails to get the issuer cert:
> $ /tmp/openssl/1.0.1r/installprefix/bin/openssl s_client -connect 
> us12.api.mailchimp.com:443
> CONNECTED(0003)
> depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
> verify error:num=20:unable to get local issuer certificate
> verify return:0
> ---
> Certificate chain
>  0 s:/C=US/ST=GA/L=Atlanta/O=ROCKET SCIENCE GROUP/OU=Rocket Science 
> Group/CN=*.api.mailchimp.com
>i:/C=NL/L=Amsterdam/O=Verizon Enterprise 
> Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
>  1 s:/C=NL/L=Amsterdam/O=Verizon Enterprise 
> Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
>i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
>  2 s:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
>i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE 
> CyberTrust Global Root
> ---

I suspect that this is the change in 1.0.2 that fixes this problem:[2]
>  *) Initial experimental support for explicitly trusted non-root CAs.
> OpenSSL still tries to build a complete chain to a root but if an
> intermediate CA has a trust setting included that is used. The first
> setting is used: whether to trust (e.g., -addtrust option to the x509
> utility) or reject.
> [Steve Henson]

This is a pretty big issue for a tool whose main job description
includes verifying SSL certificates. I think it would be reasonable to
fix this in Jessie, even if that means putting 1.0.2 in its entirety
into a SRU. I'm going to chime in on 765639 as well.

[1] https://www.openssl.org/news/openssl-1.0.1-notes.html
[2] https://www.openssl.org/news/changelog.html#x7

Bug#815206: xml2rfc: FTBFS, needs build dependency on python-requests

[Logan Rosen]

Package: xml2rfc
Version: 2.5.1-1
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Hi,

The latest upload of xml2rfc (2.5.1-1) fails to build from source because
test.py imports requests, but there is no build dependency on python-requests.

In Ubuntu, the attached patch was applied to achieve the following:

  * Build-depend on python-requests to fix FTBFS.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-2-generic (SMP w/1 CPU core)
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)
diff -Nru xml2rfc-2.5.1/debian/control xml2rfc-2.5.1/debian/control
--- xml2rfc-2.5.1/debian/control	2016-02-16 09:26:20.0 -0500
+++ xml2rfc-2.5.1/debian/control	2016-02-19 21:46:22.0 -0500
@@ -8,7 +8,8 @@
  python,
  python-setuptools,
  dh-python,
- help2man
+ help2man,
+ python-requests
 Maintainer: Daniel Kahn Gillmor 
 Standards-Version: 3.9.6
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/xml2rfc.git

Bug#801253: how to handle not much used feature which depends on a deprecated technology

[Axel Beckert]

Hi,

thanks toogley for trying to tackle this issue.

Paul Wise wrote:
> On Sat, Feb 20, 2016 at 3:28 AM, toogley wrote:
> > what do you think about that? Am i missing sth?
> 
> I would go with 1) or 3) add support for systemd-logind and whatever
> other options there are for people who don't like systemd (ConsoleKit2
> etc) and send that to upstream.

Indeed, thanks Paul for that comment.

wicd seems the most popular alternative to NetworkManager for those
who dislike NetworkManager's hard dependency on libpam-systemd and
hence systemd.

So to add an exclusive hard dependency on anything systemd-ish would
probably annoy a not so small part of wicd's user base in Debian and
should be avoided.

Making use of systemd features if systemd is installed, is though
welcome. This means that according configuration files should be
shipped, but wicd should not solely rely on them -- as it seems to
have happened with consolekit in the past.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#815031: wine: packaging depends fault

[Jens Reyer]

control: tags -1 + moreinfo

Hi Richard

On 02/18/2016 03:59 AM, Austin English wrote:
> On Wed, Feb 17, 2016 at 8:46 PM, Richard Jasmin  
> wrote:
>> we have a SERIOUS depends issue going on with Jessie and multiarch(and any
>> spins based of Jessie).
>>
>> I thought it was just skype being a dick. Its not.
>> Try and install wine and you have the same scenario.
>>
>> What it boils down to is this:
>>
>> The installable package demands libav.
>> Libav demands every other libav package.
>> ASoundlibs are demanded.
>>
>> This demands (generic) openCL be installed, breaking any proprietary video
>> setup you may have(or at least in part).These packages have no need for 
>> either
>> libav, nor openCL.
> 
> Wine doesn't use or depend on libav, I'm not sure how you came to the
> conclusion that this is a Wine bug.

You can at least uninstall the following packages (+ a bunch of other
packages depended on by them).
libasound2-plugins
libavcodec-ffmpeg56
libavresample-ffmpeg2
libavutil-ffmpeg54
libswscale-ffmpeg3
libvdpau-va-gl1
vdpau-driver-all

However, libasound2 has to be installed. And I fail to see a reason to
change that.


>> This demands (generic) openCL be installed [...]
>> Only in rare cases is OpenCL needed. The wine apps that may need it, cannot 
>> run
>> it due to other requirements.Skype doesnt need it.
>>
>> This was reported prior to DECEMBER 2014.
>> (http://ubuntuforums.org/showthread.php?t=2257502)
> Ubuntu isn't Debian, and reports made on ubuntu forums aren't tracked
> in Debian's bug system.

Indeed, and in this case except for wine-development they don't even
have the same packages.

But you know that you can alternatively install
[amd|nvidia|ocl-icd]-libopencl1?

Does this solve the problems for you?

Greets
jre

Bug#815205: sbcl: FTBFS due to TeX error

[Logan Rosen]

Source: sbcl
Version: 2:1.3.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

I just merged sbcl 2:1.3.1-1 into Ubuntu (we have a simple chmod change in
debian/rules), and it failed to build on all architectures [1]. I verified
that this issue affects Debian unstable as well by building it in a chroot.

It appears to be due to a TeX issue during the build.

Thanks,
Logan Rosen

[1] https://launchpad.net/ubuntu/+source/sbcl/2:1.3.1-1ubuntu1

Bug#815204: rss2email: option to deliver to an mbox or Maildir

[Paul Wise]

Package: rss2email
Severity: wishlist

I would like to switch from liferea to rss2email but I'd like to
preserve my folder structure from liferea. To switch over I would need
rss2email to support storing items in mboxes or Maildirs on a per-feed
basis so that I can create the tree structure and assign feeds to dirs.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#815202: packages: machines and sponsors information is outdated

[Paul Wise]

Package: www.debian.org
Severity: minor
User: www.debian@packages.debian.org
Usertags: packages

The packages site says the two packages mirrors are piatti and rore but
these were decommissioned a long time ago. It would be best to generate
the machines and sponsors info from Debian LDAP on a regular basis so
that this information never gets out of date. Some combination of
the description, purpose, sponsor and allowedGroups LDAP fields should
be enough to find the right hosts and display the right info. picconi
and pkgmirror-1and1 are the current hosts for this service.

https://packages.debian.org/about/sponsors.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#815203: grub2:[INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Source: grub2
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Here's Japanese po-debconf templates translation (ja.po) file that
reviewed by several Japanese Debian developers and users.

Could you apply it, please?

--
Takuma Yamada

-- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
'trusty'), (100, 'trusty-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-49-generic (SMP w/2 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


ja.po.gz
Description: application/gzip

Bug#815201: packages: change maintenance info to Debian Website Team

[Paul Wise]

Package: www.debian.org
Severity: minor
User: www.debian@packages.debian.org
Usertags: packages

The packages site says it is "maintained by Frank Lichtenheld" but he
hasn't been involved for a while so it would be best to say "maintained
by the Debian Website Team" on that page. I would change this myself
but I don't understand the forest of branches in the git repository.

https://packages.debian.org/about/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#815187: Bug debian-Installer jessie: Installation grub fails without error message

[Cyril Brulebois]

Hi François,

François POLASTRON  (2016-02-19):
> package: Debian-Installer
> Version: 20150422+deb8u3 
> 
> Dear Maintener,
> 
> I found a big bug in debian-Installer on a "BIOS Legacy" computer
> When trying to force grub installation in other device than primary disk, in 
> graphical mode the menu lets the user choose the device:
> /dev/sda
> /dev/sdb
> ...
> But when we choose one of a device debian-Installer don't install GRUB 
> WITHOUT 
> ERROR MESSAGE. 

This seems very strange to me. Any chance you have access to this computer
anyway, and can share the installer logs containing the failed attempt?
(/var/log/installer/syslog notably.)

> In fact we must enter the device with the keyboard taping "/dev/sda"... to 
> contourn the bug. 

(contourner = to work around)

> Excuse-me for my english language. I'm a french guy

Don't worry, we've seen worse messages. ;)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#815200: tzdata: US/Pacific-New timezone is arcane, confusing

[Robert Edmonds]

Package: tzdata
Version: 2016a-1
Severity: wishlist

Hi,

When running "dpkg-reconfigure tzdata" to reconfigure my machine's time
zone, one of the choices presented on the "US" menu is
"Pacific-New". Apparently this is a reference to a proposed time zone
that never became law in the U.S.:

http://catless.ncl.ac.uk/Risks/13.87.html#subj1

US presidential election year politics help cause time zone bugs

Paul Eggert 
Mon, 26 Oct 92 14:47:57 PST

Several people on the west coast of the US reported that their Unix
systems failed to switch from daylight savings time to standard time
yesterday, 25 October 1992.  The reason?  When they originally
configured their systems, they were asked to choose one of the
following time zone rules:

US/Alaska   US/Central  US/Hawaii   US/Pacific
US/Aleutian US/East-Indiana US/Michigan US/Pacific-New
US/Arizona  US/Eastern  US/Mountain US/Samoa
...

Some people chose `US/Pacific-New' instead of `US/Pacific'.  After
all, who wants the old version when you can have the new version?

Unfortunately, `US/Pacific-New' stands for ``Pacific Presidential
Election Time'', which was passed by the House in April 1989 but
never signed into law.  In presidential election years, this rule
would have delayed the PDT-to-PST switchover until after the
election, to lessen the effect of broadcast news election
projections on last-minute west-coast voters.  Thus, US/Pacific-New
and US/Pacific have always been identical -- until yesterday.

This problem comes from combining Arthur David Olson's deservedly
popular time zone software (which you can FTP from elsie.nci.nih.gov
in pub/tz92b.tar.Z) with some overly terse vendor-supplied
installation procedures.  No doubt Olson did not use a more
informative name like `US/Pacific-Presidential-Election' because of
the 14-character file name length limit in many Unix file systems.
In view of yesterday's experience, though, it seems unwise to make
the hypothetical choice available under any name, since it gives
free rein to Murphy's Law.

Interestingly, US/Pacific and US/Pacific-New appear to now be aliases
for the same underlying time zone:

edmonds@chase{0}:~$ dpkg -S US/Pacific
tzdata: /usr/share/zoneinfo/US/Pacific-New
tzdata: /usr/share/zoneinfo/right/US/Pacific-New
tzdata: /usr/share/zoneinfo/posix/US/Pacific-New
tzdata: /usr/share/zoneinfo/posix/US/Pacific
tzdata: /usr/share/zoneinfo/right/US/Pacific
tzdata: /usr/share/zoneinfo/US/Pacific

edmonds@chase{0}:~$ ls -l /usr/share/zoneinfo/{right/,posix/,}US/Pacific*
lrwxrwxrwx 1 root root 18 Jan 29 15:28 /usr/share/zoneinfo/US/Pacific -> 
../SystemV/PST8PDT
lrwxrwxrwx 1 root root 18 Jan 29 15:28 /usr/share/zoneinfo/US/Pacific-New 
-> ../SystemV/PST8PDT
lrwxrwxrwx 1 root root 21 Jan 29 15:28 /usr/share/zoneinfo/posix/US/Pacific 
-> ../../SystemV/PST8PDT
lrwxrwxrwx 1 root root 21 Jan 29 15:28 
/usr/share/zoneinfo/posix/US/Pacific-New -> ../../SystemV/PST8PDT
lrwxrwxrwx 1 root root 18 Jan 29 15:28 /usr/share/zoneinfo/right/US/Pacific 
-> ../SystemV/PST8PDT
lrwxrwxrwx 1 root root 18 Jan 29 15:28 
/usr/share/zoneinfo/right/US/Pacific-New -> ../SystemV/PST8PDT

So the behavior described in 1992 for the "US/Pacific-New" time zone
isn't even replicable any more:

edmonds@chase{0}:~$ zdump -v /usr/share/zoneinfo/posix/US/Pacific-New | 
grep 1992
/usr/share/zoneinfo/posix/US/Pacific-New  Sun Apr  5 09:59:59 1992 UT = Sun 
Apr  5 01:59:59 1992 PST isdst=0 gmtoff=-28800
/usr/share/zoneinfo/posix/US/Pacific-New  Sun Apr  5 10:00:00 1992 UT = Sun 
Apr  5 03:00:00 1992 PDT isdst=1 gmtoff=-25200
/usr/share/zoneinfo/posix/US/Pacific-New  Sun Oct 25 08:59:59 1992 UT = Sun 
Oct 25 01:59:59 1992 PDT isdst=1 gmtoff=-25200
/usr/share/zoneinfo/posix/US/Pacific-New  Sun Oct 25 09:00:00 1992 UT = Sun 
Oct 25 01:00:00 1992 PST isdst=0 gmtoff=-28800

Probably that's a hack to fix the time on systems where the sysadmin
inadvertently chose the wrong timezone. Maybe US/Pacific-New should be
removed, or at least not displayed in the "dpkg-reconfigure tzdata"
menu?

-- 
Robert Edmonds
edmo...@debian.org

Bug#815172: crossbuild-essential-armhf: cross-building issues due to missing libc6-dev:armhf

[Johannes Schauer]

Hi,

On Fri, 19 Feb 2016 09:24:23 -0800 Vagrant Cascadian  wrote:
> Using sbuild's "--add-depends libc6-dev:armhf" does work around the issue for
> me, but it seems a bit cumbersome to manually specify cross-build
> dependencies...
> 
> 
> According to the changelog, libc6-dev apparently was dropped
> intentionally:
> 
>   build-essential (12.2) unstable; urgency=medium
> 
> * Bump dependencies on gcc and g++ to 5.3.
> * For cross packages, drop libc-dev dependency on libc-dev.
> 
>  -- Matthias Klose   Wed, 03 Feb 2016 00:26:37 +0100
> 
> I know there's a fair amount of history and background on
> cross-toolchains in Debian, and I'm not in a position to intelligently
> debate all the ramifications of the various methods.
> 
> 
> If you have a recommendation of how I can cross-build u-boot without
> manually installing build-dependencies, that would be really helpful!
> Up until recently, installing crossbuild-essential-armhf, which sbuild did
> automatically, worked quite nicely.

Speaking with my sbuild maintainer hat on, I was made aware of this bug through
a request to add libc-dev:$hostarch and libstdc++6-dev:$hostarch as additional
implicit crossbuild dependencies to sbuild in addition to the existing
crossbuild-essential-$hostarch crossbuild dependency. This would remove the
need to manually add "--add-depends libc6-dev:$hostarch" to the sbuild
invocation when cross building for $hostarch with the new crossbuild-essential
packages as described by vagrant.

I would assume that packages should be able to rely on libc-dev:$hostarch being
installed as part of build-essential no matter whether the host architecture
equals the build architecture or not. Since I wonder where the right place is
to fix this problem is and whether I should really modify sbuild, I'd like to
join vagrant in their plea to get to know why this change was made in the 12.2
upload of src:build-essential.

Intuitively it feels wrong to carry more implicit dependencies like
build-essential and crossbuild-essential-$arch than necessary in packages
resolving or checking crossbuild dependencies like sbuild, pbuilder,
mk-build-deps, dose3, dpkg-checkbuilddeps or `apt-get build-dep`. Naively, I
thought that the point of the crossbuild-essential-$arch packages was to encode
the essential multiarch crossbuild dependencies in a single binary package
rather than hardcoding them in multiple pieces of dependency resolving software
which makes these architecture specific lists hard to maintain or keeping them
in sync.

So how and where should this best be handled?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#815197: iputils package update

[Noah Meyerhans]

On Fri, Feb 19, 2016 at 06:29:36PM -0500, Jester 2.0 wrote:
>The iputils package included in Sid is from 2012.  There have been several
>releases since then and should be updated.  Specifically, the iputils-ping
>package needs to be updated to support the unified ping binary.

That github repo is a fork of iputils, and is not the repository we're
tracking. The official iputils upstream is
http://www.skbuff.net/iputils/

Debian currently contains something close but not quite up to date. An
update to the latest upstream snapshot is pending.

noah



signature.asc
Description: Digital signature

Bug#219140: combined ping binary

[Noah Meyerhans]

On Fri, Feb 19, 2016 at 06:28:11PM -0500, Jester 2.0 wrote:
>This functionality was committed to the source in June 2015.  
>Specific
>commit: 
> [1]https://github.com/iputils/iputils/commit/ebad35fee3de851b809c7b72ccc654a72b6af61d
>Also, the iputils package in general hasn't been updated since 2012. 
>Should be updated in general.

As mentioned elsewhere, that is not the iputils repo we're tracking. See
http://www.skbuff.net/iputils/ for the upstream project we follow.

noah



signature.asc
Description: Digital signature

Bug#815199: ITP: acme-tiny -- letsencrypt tiny python client

[Jeremías Casteglione]

Package: wnpp
Severity: wishlist
Owner: "Jeremías Casteglione" 

* Package name: acme-tiny
  Version : 20151229
  Upstream Author : Daniel Roesler 
* URL : https://github.com/diafygi/acme-tiny
* License : MIT
  Programming Lang: Python
  Description : letsencrypt tiny python client

acme-tiny is a tiny script to issue and renew TLS certs from Let's Encrypt

This is a tiny, auditable script that you can throw on your server to issue and
renew Let's Encrypt certificates. Since it has to be run on your server and
have access to your private Let's Encrypt account key, I tried to make it as
tiny as possible (currently less than 200 lines). The only prerequisites are
python and openssl.

You have to deal yourself wiht the openssl stuff, and with webserver
configuration and such. But it doesn't require more dependencies than openssl
and it just works, no need for sudo nor being root to run it either. I'm using
it for my personal TLS stuff.

I'm not a DD nor a DM either, so an sponsor will be needed.

Bug#815198: NEW script: /usr/lib/debbug/mbox

[Mike Gabriel]

Package: debbugs
Version: 2.6.0~exp1+git20160213.3eea543
Severity: wishlist

Hi,

I have hacked together a little new script named "mbox". I have it in  
/usr/lib/debbugs.


The script prints a bug number's mailbox to stdout. Maybe it is helpful.

Script is attached. It has been derived from bugreport.cgi.

Greets,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de
#!/usr/bin/perl

use warnings;
use strict;

use POSIX qw(strftime);

use Debbugs::Config qw(:globals :text);

# for read_log_records
use Debbugs::Log qw(read_log_records);
use Debbugs::Common qw(buglog bug_status);
use Debbugs::Status qw( split_status_fields get_bug_status);
use Debbugs::MIME qw(create_mime_message);

use List::Util qw(max);

my $ref = shift or die;


my %bugusertags;

my $buglog = buglog($ref);
my $bug_status = bug_status($ref);

my $buglogfh;
if ($buglog =~ m/\.gz$/) {
my $oldpath = $ENV{'PATH'};
$ENV{'PATH'} = '/bin:/usr/bin';
$buglogfh = IO::File->new("zcat $buglog |") or quitcgi("open log for $ref: 
$!");
$ENV{'PATH'} = $oldpath;
} else {
$buglogfh = IO::File->new($buglog,'r') or quitcgi("open log for $ref: $!");
}

my %status =
%{split_status_fields(get_bug_status(bug=>$ref,
 bugusertags => \%bugusertags,
))};

my @records;
eval{
 @records = read_log_records($buglogfh);
};

my $mbox = 1;

my @log;
if ( $mbox ) {
 binmode(STDOUT,":raw");
 my $date = strftime "%a %b %d %T %Y", localtime;

 my $message_number=0;
 my %seen_message_ids;
 for my $record (@records) {
  next if $record->{type} !~ /^(?:recips|incoming-recv)$/;
  my $wanted_type = 'incoming-recv';
  # we want to include control messages anyway
  my $record_wanted_anyway = 0;
  my ($msg_id) = $record->{text} =~ /^Message-Id:\s+<(.+)>/im;
  next if defined $msg_id and exists $seen_message_ids{$msg_id};
  next if defined $msg_id and $msg_id 
=~/handler\..+\.ack(?:info|done)?\@/;
  $record_wanted_anyway = 1 if $record->{text} =~ /^Received: \(at 
control\)/;
  next if not $record->{type} eq $wanted_type and not 
$record_wanted_anyway and @records > 1;
  $seen_message_ids{$msg_id} = 1 if defined $msg_id;
  my @lines = split( "\n", $record->{text}, -1 );
  if ( $lines[ 1 ] =~ m/^From / ) {
   my $tmp = $lines[ 0 ];
   $lines[ 0 ] = $lines[ 1 ];
   $lines[ 1 ] = $tmp;
  }
  if ( !( $lines[ 0 ] =~ m/^From / ) ) {
   unshift @lines, "From unknown $date";
  }
  map { s/^(>*From )/>$1/ } @lines[ 1 .. $#lines ];
  print join( "\n", @lines ) . "\n";
 }
 exit 0;
}


pgpjnplHaj_r4.pgp
Description: Digitale PGP-Signatur

Bug#792653: Probably related to CapabilityBoundingSet

[Jim Barber]

Alberto Gonzalez wrote:

> Hi,

Hi Alberto.
I only just noticed now that you updated this case.
 
> Did you run "systemctl daemon-reload" after changing the .service file? 

Yes, as per my original bug report I tried the following:


Each time I edited the file, I tried the following commands before
starting the service:

systemctl reenable openvpn@.service
systemctl daemon-reload
systemctl daemon-reexec


> I'll upload 2.3.10 soon, can you check if it works with it?

I now have the new version of openvpn.
If I re-add the following directives to my configuation with this version, 
openvpn now starts without error:

user openvpn
group nogroup
iproute /usr/local/sbin/openvpn-ip

And a ps listing shows the openvpn processes running as the openvpn user.

With my phone I am able to connect to openvpn okay, but I was unable to browse 
anything with my web browser.
If I remove the directives and restart openvpn and reconnect my phone again 
then browsing works.

So I am now futher than I was before but something else is wrong.

I compared the syslog entries for my connection when running openvpn at the 
root and openvpn users.
I then compared routes.
When running with the root user, an extra route is added when my phone connects.
When running with the openvpn user, there is no extra route added when my phone 
connects.

I edited the /usr/local/sbin/openvpn-ip script so that it looks like this:

#!/bin/sh
echo "openvpn-ip script invoked" >> /tmp/openvpn-ip.tmp
/usr/bin/sudo /sbin/ip $*

Then I connected with the phone while openvpn was running as the openvpn user.
The /tmp/openvpn-ip.tmp file was not created.
So it looks like the following directive in the configuration file is not 
having an effect, or for some reason openvpn is unable to run it:

iproute /usr/local/sbin/openvpn-ip

The permissions on the file are okay and the openvpn user is able to reach it:

# sudo -u openvpn ls -l /usr/local/sbin/openvpn-ip 
-rwxr-xr-x 1 root staff 92 Feb 20 07:32 /usr/local/sbin/openvpn-ip

So perhaps another capability is stopping this file from being run?
I saw no other log messages relating to failure to access or run the 
/usr/local/sbin/openvpn-ip script anywhere.

Regards,
Jim.

Bug#815193: razorqt: please make the build reproducible

[Manuel A. Fernandez Montecelo]

Hi Reiner,

2016-02-19 21:34 GMT+00:00 Reiner Herrmann :
>
> Hi!
>
> While working on the "reproducible builds" effort [1], we have noticed
> that razorqt could not be built reproducibly.

Thanks for your report, but this package is kind of obsolete: it's
dead upstream (merged with lxde-qt), it will not be present in the
next stable release, it depends on Qt4 which the maintainers plan to
retire before the next release as well, etc, see:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784181

I was planning to ask this package to be removed at some point, but
since lxde-qt is still very fresh, I thought about giving it more
time, and at least while Qt4 is around it can be used and some people
maybe prefer it over other alternatives.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#623433: #623433: python-zsi: Faulty detection of nillable elements

[Christian Hofstaedtler]

Hi,

while I don't expect this bug to go anywhere, here's some additional
info. We've found us in a similar situation, where the service we
were talking to returned nil elements in an apache map.

Unfortunately the proposed patch didn't solve the issue for us,
probably because of a namespace prefixing issue.

A colleague came up with this patch and we've been using that in
production for quite a while:


diff --git a/ZSI/TCapache.py b/ZSI/TCapache.py
index fe39a00..3d61faf 100644
--- a/ZSI/TCapache.py
+++ b/ZSI/TCapache.py
@@ -17,7 +17,7 @@ class _Map(TypeCode):
 def __init__(self, pname=None, aslist=0, **kw):
 TypeCode.__init__(self, pname, **kw)
 self.aslist = aslist
-self.tc = _Struct(None, [ _Any('key'), _Any('value') ], inline=1)
+self.tc = _Struct(None, [ _Any('key'), _Any('value', nillable=True) ], 
inline=1)
 
 def parse(self, elt, ps):
 self.checkname(elt, ps)


-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#801253: how to handle not much used feature which depends on a deprecated technology

[Paul Wise]

On Sat, Feb 20, 2016 at 3:28 AM, toogley wrote:

> what do you think about that? Am i missing sth?

I would go with 1) or 3) add support for systemd-logind and whatever
other options there are for people who don't like systemd (ConsoleKit2
etc) and send that to upstream.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#815126: linux-image-4.4.0-1-amd64 hangs after 'Loading initial ramdisk ...'

[Serhii Yehorov]

Have same problem with desktop based on Gigabyte GA-970A-UD3.
ThinkPad Edge E330 3354-AY5 have everything OK.

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

Bug#754377: unable to reproduce the insserv problem, piuparts likes wheezy but does not like jessie

[Petter Reinholdtsen]

[Johan Laenen]
> I'm unable to reproduce the problem with insserv rejecting the script
> header on a fresh debian install in a virtual box environment. The install
> on wheezy works without a problem, on jessie piuparts:

Looking at the message, I suspect it only happen on machines / chroots
without udev installed.  There are two fixes: (1) Depend on udev or (2)
make the udev init.d script dependency optional.  I recommend (2).

Notice the Required-Start header in the current init.d script:

### BEGIN INIT INFO
# Provides:  eeepc-acpi-scripts
# Required-Start:udev mountkernfs $remote_fs
# Required-Stop: 
# Default-Start: S
# Default-Stop:
# Short-Description: Load modules which are useful on EeePCs and similar 
hardware
### END INIT INFO

If udev is moved to Should-Start instead, the init.d script will be installable
also when udev isn't installed.

Btw, are you sure it need to depend on udev mountkernfs and should be
enabled in rcS.d?  I suspect using 'Default-Start: 2 3 4 5' might be a
better option if nothing during early boot or single user mode need
the modules loaded.

-- 
Happy hacking
Petter Reinholdtsen

Bug#219140: combined ping binary

[Jester 2.0]

This functionality was committed to the source in June 2015.

Specific commit:
https://github.com/iputils/iputils/commit/ebad35fee3de851b809c7b72ccc654a72b6af61d

Also, the iputils package in general hasn't been updated since 2012.
Should be updated in general.

Bug#815197: iputils package update

[Jester 2.0]

Package: iputils
Version: 3:20121221-5

The iputils package included in Sid is from 2012.  There have been several
releases since then and should be updated.  Specifically, the iputils-ping
package needs to be updated to support the unified ping binary.

Specific commit:
https://github.com/iputils/iputils/commit/ebad35fee3de851b809c7b72ccc654a72b6af61d

Last release:  https://github.com/iputils/iputils/releases/tag/s20150815

Bug#815006: Renaming Iceweasel to Firefox

[Moritz Muehlenhoff]

On Fri, Feb 19, 2016 at 09:46:59PM +0900, Mike Hommey wrote:
> For clarity, do you mean you're fine with a iceweasel->firefox-esr
> transition in stable(jessie) when we upgrade to 45? (which will be by 45.2,
> at the beginning of June)

It's likely a lot easier on your side if we do that, right?

It might actually even also be simpler for us, since we wouldn't need to track 
two
different source package names for several years.

If the respective transition packages are in place, that seems acceptable
to me (after all we had a in comparison more drastic UI change between ESR24
and ESR31).

Cheers,
Moritz

Bug#814544: wheezy-pu: package clamav/0.99+dfsg-0+deb7u1

[Sebastian Andrzej Siewior]

On 2016-02-19 05:56:27 [+], Adam D. Barratt wrote:
> The sparc build has now failed three times, across two different builds.

And why did mips pass? Isn't mips the difficult one?

The patch attached is a simplified version of what I had on smetana
during testing. I would give it another try to make sure it works before
the final upload.
Speaking of which: does this count as a wheezy-pu bug for
clamav/0.99+dfsg-0+deb7u2?
Do you want to see this change in unstable before it hits wheezy?

I have a tiny testcase which fails on my armel box but succeeds on the
armel porterbox. I guess the HW on the porterbox is new enough to work
with this (mine is ARMv5 and the porterbox is ARMv7 which is enough for
armhf). My testcase does not fail on the mips/mipsel porter boxes.

> Regards,
> 
> Adam

Sebastian
diff --git a/libclamav/yara_exec.c b/libclamav/yara_exec.c
index dbd7ae8..eb06fbb 100644
--- a/libclamav/yara_exec.c
+++ b/libclamav/yara_exec.c
@@ -54,6 +54,16 @@ typedef struct _YR_MATCH
 #include "yara_exec.h"
 #endif
 
+#define __packed__attribute__((packed))
+
+struct __una_u64 { uint64_t x; } __packed;
+
+static inline uint64_t get_unaligned_64(const void *p)
+{
+	const struct __una_u64 *ptr = (const struct __una_u64 *)p;
+	return ptr->x;
+}
+
 #define STACK_SIZE 16384
 #define MEM_SIZE   MAX_LOOP_NESTING * LOOP_LOCAL_VARS
 
@@ -184,7 +194,7 @@ int yr_execute_code(
 #endif
 
   case OP_PUSH:
-r1 = *(uint64_t*)(ip + 1);
+r1 = get_unaligned_64(ip + 1);
 ip += sizeof(uint64_t);
 push(r1);
 break;
@@ -194,38 +204,38 @@ int yr_execute_code(
 break;
 
   case OP_CLEAR_M:
-r1 = *(uint64_t*)(ip + 1);
+r1 = get_unaligned_64(ip + 1);
 ip += sizeof(uint64_t);
 mem[r1] = 0;
 break;
 
   case OP_ADD_M:
-r1 = *(uint64_t*)(ip + 1);
+r1 = get_unaligned_64(ip + 1);
 ip += sizeof(uint64_t);
 pop(r2);
 mem[r1] += r2;
 break;
 
   case OP_INCR_M:
-r1 = *(uint64_t*)(ip + 1);
+r1 = get_unaligned_64(ip + 1);
 ip += sizeof(uint64_t);
 mem[r1]++;
 break;
 
   case OP_PUSH_M:
-r1 = *(uint64_t*)(ip + 1);
+r1 = get_unaligned_64(ip + 1);
 ip += sizeof(uint64_t);
 push(mem[r1]);
 break;
 
   case OP_POP_M:
-r1 = *(uint64_t*)(ip + 1);
+r1 = get_unaligned_64(ip + 1);
 ip += sizeof(uint64_t);
 pop(mem[r1]);
 break;
 
   case OP_SWAPUNDEF:
-r1 = *(uint64_t*)(ip + 1);
+r1 = get_unaligned_64(ip + 1);
 ip += sizeof(uint64_t);
 pop(r2);
 if (r2 != UNDEFINED)
@@ -540,7 +550,7 @@ int yr_execute_code(
 
 // r1 = number of arguments
 
-r1 = *(uint64_t*)(ip + 1);
+r1 = get_unaligned_64(ip + 1);
 ip += sizeof(uint64_t);
 
 // pop arguments from stack and copy them to args array
@@ -854,7 +864,7 @@ int yr_execute_code(
 
 #if REAL_YARA //not supported ClamAV
   case OP_IMPORT:
-r1 = *(uint64_t*)(ip + 1);
+r1 = get_unaligned_64(ip + 1);
 ip += sizeof(uint64_t);
 
 FAIL_ON_ERROR(yr_modules_load(

Bug#815175: [buildd-tools-devel] Bug#815175: sbuild-update fails to unmount schroots on failure

[Johannes Schauer]

Control: reassign -1 schroot
Control: retitle -1 schroot fails to unmount chroot on failure in setup.d 
scripts

Hi Ryan,

Quoting Ryan Kavanagh (2016-02-19 23:30:13)
> On Fri, Feb 19, 2016 at 09:07:46PM +0100, Johannes Schauer wrote:
> > Quoting Ryan Kavanagh (2016-02-19 18:56:32)
> > > rak@zeta:~$ sbuild-update -udr source:jessie-amd64
> > > E: 15binfmt: update-binfmts: unable to open 
> > > /var/run/schroot/mount/jessie-snap-a6a720c2-d20d-4251-b3a5-1e043da0e1e2/bin/sh:
> > >  No such file or directory
> > > E: 20copyfiles: cp: cannot create regular file 
> > > '/var/run/schroot/mount/jessie-snap-a6a720c2-d20d-4251-b3a5-1e043da0e1e2/etc/resolv.conf':
> > >  No such file or directory
> > > E: jessie-snap-a6a720c2-d20d-4251-b3a5-1e043da0e1e2: Chroot setup failed: 
> > > stage=setup-start
> > > Chroot setup failed
> > > Error setting up source:jessie-amd64 chroot
> > > Chroot setup failed at /usr/bin/sbuild-update line 170.
> > 
> > this error looks strange.
> > 
> > Can you tell me a way how I can reproduce the problem you have with
> > sbuild-update?
> 
> The above error is a classic case of PEBKAC. I accomplished it roughly
> as follows:
> 
> mkfs.ext4 /dev/wd/jessie-chroot
> mkdir /tmp/jessie
> mount /dev/wd/jessie-chroot /tmp/jessie
> sbuild-createchroot jessie /tmp/wd-jessie-chroot 
> http://httpredir.debian.org/debian
> umount /tmp/jessie
> ... delete /etc/schroot/schroot.d/* and add the appropriate LVM snapshot
> ... config entry to /etc/schroot/schroot.conf
> suild-update -udr source:jessie-amd64
> 
> which then caused a snapshot of /dev/wd/jessie-chroot to get mounted,
> which was empty (I fed the wrong path to sbuild-createchroot), and so
> sbuild-update obviously couldn't find bin/sh under it :)
> 
> So, I suppose this should be considered a 'wishlist' bug, where
> sbuild-update should fail gracefully and umount stuff even on failure.

thanks, this allowed me to reproduce this. Though don't think that sbuild can
do anything about this problem, as I think it is schroot which fails to clean
up after failing to begin the session.

Steps to reproduce:

$ cat /etc/schroot/chroot.d/unstable-amd64-sbuild-Y0L33s
[unstable-amd64-sbuild]
type=file
description=Debian unstable/amd64 autobuilder
file=/srv/chroot/unstable-amd64.tar.gz
groups=root,sbuild
root-groups=root,sbuild
profile=sbuild
$ mkdir empty
$ tar -C empty -czf empty.tar.gz .
$ sudo mv empty.tar.gz /srv/chroot/unstable-amd64.tar.gz
$ sudo chown root:root /srv/chroot/unstable-amd64.tar.gz
$ schroot -c chroot:unstable-amd64-sbuild --begin-session
E: 15binfmt: update-binfmts: unable to open 
/var/run/schroot/mount/unstable-amd64-sbuild-ca29d966-e3e4-4196-b824-7e153b317c1d/bin/sh:
 No such file or directory
E: 20copyfiles: cp: cannot create regular file 
'/var/run/schroot/mount/unstable-amd64-sbuild-ca29d966-e3e4-4196-b824-7e153b317c1d/etc/resolv.conf':
 No such file or directory
E: unstable-amd64-sbuild-ca29d966-e3e4-4196-b824-7e153b317c1d: Chroot setup 
failed: stage=setup-start
$ mount | grep /run/schroot/mount/
tmpfs on 
/run/schroot/mount/unstable-amd64-sbuild-3aab5ea7-86ae-4c30-b096-d58406f025bb 
type tmpfs (rw,nosuid,nodev,relatime,size=8388608k)
proc on 
/run/schroot/mount/unstable-amd64-sbuild-3aab5ea7-86ae-4c30-b096-d58406f025bb/var/run/schroot/mount/unstable-amd64-sbuild-3aab5ea7-86ae-4c30-b096-d58406f025bb/proc
 type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on 
/run/schroot/mount/unstable-amd64-sbuild-3aab5ea7-86ae-4c30-b096-d58406f025bb/var/run/schroot/mount/unstable-amd64-sbuild-3aab5ea7-86ae-4c30-b096-d58406f025bb/sys
 type sysfs (rw,nosuid,nodev,noexec,relatime)
udev on 
/run/schroot/mount/unstable-amd64-sbuild-3aab5ea7-86ae-4c30-b096-d58406f025bb/var/run/schroot/mount/unstable-amd64-sbuild-3aab5ea7-86ae-4c30-b096-d58406f025bb/dev
 type devtmpfs (rw,relatime,size=10240k,nr_inodes=1497603,mode=755)
devpts on 
/run/schroot/mount/unstable-amd64-sbuild-3aab5ea7-86ae-4c30-b096-d58406f025bb/var/run/schroot/mount/unstable-amd64-sbuild-3aab5ea7-86ae-4c30-b096-d58406f025bb/dev/pts
 type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on 
/run/schroot/mount/unstable-amd64-sbuild-3aab5ea7-86ae-4c30-b096-d58406f025bb/var/run/schroot/mount/unstable-amd64-sbuild-3aab5ea7-86ae-4c30-b096-d58406f025bb/dev/shm
 type tmpfs (rw,relatime)



Thanks!

cheers, josch


signature.asc
Description: signature

Bug#803777: libqb: FTBFS on hurd-i386

[Svante Signell]

On Fri, 2016-02-19 at 21:22 +0100, Christoph Berg wrote:
> Re: Svante Signell 2016-02-18 <1455809556.5852.62.ca...@gmail.com>
> > Attached is an updated patch together with an updated symbols file,
> > generated
> > with gcc-5.3.1-5.
> 
> Hi Svante,
> 
> thanks for the updated patch, and I'm glad that libqb has now been
> built for the Hurd as well so the rest of the Clusterlabs stack has a
> chance to get running.
> 
> I'm not entirely sure what happened with sem_timedwait change. The
> configure.ac patch looks good to me, but unfortunately it makes the
> package fail on some architectures, e.g. on arm64:
> https://buildd.debian.org/status/fetch.php?pkg=libqb=arm64=0
> .17.2.real-5=1455889304
> https://buildd.debian.org/status/package.php?p=libqb
> 
> Does that make any sense to you?

Hi, found the problem. The updated patch unfortunately removed the
check for sem_timedwait, the updated patch is as attached (without)
-   sem_timedwait semtimedop \
+   semtimedop \

This is plain wrong, dunno how this happened, sorry for the confusion.
The rpl_* stuff, I'll look into tomorrow.
BTW: Iv'e subscribed to upstream, and submitted the GNU/Hurd and
GNU/Linux patches. They want either a git pull request or git-sendmail
patches. I think I'll go on with the latter, as the former need you get
an account on github.

Thanks!
Index: libqb-0.17.2.real/configure.ac
===
--- libqb-0.17.2.real.orig/configure.ac
+++ libqb-0.17.2.real/configure.ac
@@ -206,6 +206,22 @@ AC_CHECK_FUNCS([alarm clock_gettime ftru
 		sched_get_priority_max sched_setscheduler \
 		getpeerucred getpeereid])
 
+		AC_MSG_CHECKING(for a working sem_timedwait)
+		LDFLAGS=-lpthread
+		AC_RUN_IFELSE([AC_LANG_PROGRAM(
+[[#include ]],
+[[sem_t sem;
+struct timespec ts;
+if (sem_init(, 0, 0) == -1) return -1;
+if(sem_timedwait(, )==-1) return -1;]])],
+			  [
+			AC_MSG_RESULT([yes])
+			AC_DEFINE_UNQUOTED([HAVE_SEM_TIMEDWAIT], [1], [Define to 1 if sem_timedwait works])
+			  ],
+			  [
+			AC_MSG_RESULT([no])
+			  ])
+
 AM_CONDITIONAL(HAVE_SEM_TIMEDWAIT,
 	   [test "x$ac_cv_func_sem_timedwait" = xyes])
 AM_CONDITIONAL(HAVE_EPOLL,
@@ -341,6 +357,11 @@ case "$host_os" in
 		CP=rsync
 		AC_MSG_RESULT([Solaris])
 	;;
+	*gnu*)
+		AC_DEFINE_UNQUOTED([QB_GNU], [1],
+   [Compiling for GNU/Hurd platform])
+		AC_MSG_RESULT([GNU])
+	;;
 	*)
 		AC_MSG_ERROR([Unsupported OS? h])
 	;;
Index: libqb-0.17.2.real/lib/log_thread.c
===
--- libqb-0.17.2.real.orig/lib/log_thread.c
+++ libqb-0.17.2.real/lib/log_thread.c
@@ -164,7 +164,11 @@ qb_log_thread_start(void)
 
 	if (logt_sched_param_queued) {
 		res = qb_log_thread_priority_set(logt_sched_policy,
+#if defined(HAVE_PTHREAD_SETSCHEDPARAM) && defined(HAVE_SCHED_GET_PRIORITY_MAX)
 		 logt_sched_param.sched_priority);
+#else
+		 0);
+#endif
 		if (res != 0) {
 			goto cleanup_pthread;
 		}
Index: libqb-0.17.2.real/lib/ipc_socket.c
===
--- libqb-0.17.2.real.orig/lib/ipc_socket.c
+++ libqb-0.17.2.real/lib/ipc_socket.c
@@ -79,7 +79,7 @@ qb_ipc_dgram_sock_setup(const char *base
 	}
 	snprintf(sock_path, PATH_MAX, "%s-%s", base_name, service_name);
 	set_sock_addr(_address, sock_path);
-#if !(defined(QB_LINUX) || defined(QB_CYGWIN))
+#if !(defined(QB_LINUX) || defined(QB_CYGWIN) || defined(QB_GNU))
 	res = unlink(local_address.sun_path);
 #endif
 	res = bind(request_fd, (struct sockaddr *)_address,
@@ -287,7 +287,7 @@ _finish_connecting(struct qb_ipc_one_way
 static void
 qb_ipcc_us_disconnect(struct qb_ipcc_connection *c)
 {
-#if !(defined(QB_LINUX) || defined(QB_CYGWIN))
+#if !(defined(QB_LINUX) || defined(QB_CYGWIN) || defined(QB_GNU))
   struct sockaddr_un un_addr;
   socklen_t un_addr_len = sizeof(struct sockaddr_un);
   char *base_name;
@@ -298,7 +298,7 @@ qb_ipcc_us_disconnect(struct qb_ipcc_con
 	munmap(c->request.u.us.shared_data, SHM_CONTROL_SIZE);
 	unlink(c->request.u.us.shared_file_name);
 
-#if !(defined(QB_LINUX) || defined(QB_CYGWIN))
+#if !(defined(QB_LINUX) || defined(QB_CYGWIN) || defined(QB_GNU))
 if (getsockname(c->response.u.us.sock, (struct sockaddr *)_addr, _addr_len) == 0) {
   length = strlen(un_addr.sun_path);
   base_name = strndup(un_addr.sun_path,length-9);
@@ -422,7 +422,7 @@ retry_peek:
 
 		if (errno != EAGAIN) {
 			final_rc = -errno;
-#if !(defined(QB_LINUX) || defined(QB_CYGWIN))
+#if !(defined(QB_LINUX) || defined(QB_CYGWIN) || defined(QB_GNU))
 			if (errno == ECONNRESET || errno == EPIPE) {
 final_rc = -ENOTCONN;
 			}
@@ -657,7 +657,7 @@ _sock_rm_from_mainloop(struct qb_ipcs_co
 static void
 qb_ipcs_us_disconnect(struct qb_ipcs_connection *c)
 {
-#if !(defined(QB_LINUX) || defined(QB_CYGWIN))
+#if !(defined(QB_LINUX) || defined(QB_CYGWIN) || defined(QB_GNU))
 	struct sockaddr_un 

Bug#813562: Test suite failure

[James R Barlow]

I ran into a similar failure because leptonica 1.71 has an integer overflow
bug in the function pixCorrelationBinary which I use only in the test suite
to check if some output PDFs visually resemble an expected reference PDF. I
rewrote that function in Python for the older versions. The relevant code
is ocrmypdf.leptonica.Pix.correlation_binary. I added a test that only
exercises pixCorrelationBinary (test_monochrome_correlation), and this one
passed.

I checked that the tests can pass in the Docker version (they are slightly
broken for an unrelated reason), which is debian stretch which has
leptonica 1.73 (good version) and the same set of libraries as yours. The
one difference is tesseract 3.04.01 vs .00, but I compiled the tesseract
3.04.01 and found that made no difference.

In any case, could you try running this:
ocrmypdf --rotate-pages tests/resources/cardinal.pdf out.pdf

In cardinal.pdf the same page is rotated in each cardinal direction.
out.pdf should have all pages facing up. Is this the case? The output will
also give information on rotation status:
INFO - 1: page is facing ⇧, confidence 18.69
INFO - 3: page is facing ⇩, confidence 21.86 - correcting rotation
INFO - 4: page is facing ⇦, confidence 20.71 - correcting rotation
INFO - 2: page is facing ⇨, confidence 21.63 - correcting rotation
INFO - 3: rotating image layer 180 degrees
INFO - 2: rotating image layer 90 degrees
INFO - 4: rotating image layer 270 degrees

That would help establish whether something is actually wrong or the test
case is somehow at fault.

It would also help to try in python3:

>>> import ocrmypdf.leptonica as lp
>>> lp.getLeptonicaVersion()

...to see if there's anything unusual about how debian sid is reporting the
leptonica version.


On Fri, 19 Feb 2016 at 12:04 Sean Whitton  wrote:

> Hello,
>
> On Fri, Feb 19, 2016 at 07:11:32AM +, James R Barlow wrote:
> > What version of leptonica is installed?
> > tesseract --version will report this.
>
> From within my Sid chroot:
>
> root@artemis:/build/ocrmypdf-4.0.1# tesseract --version
> tesseract 3.04.01
>  leptonica-1.73
>   libgif 5.1.2 : libjpeg 6b (libjpeg-turbo 1.4.2) : libpng 1.2.54 :
> libtiff 4.0.6 : zlib 1.2.8 : libwebp 0.4.4 : libopenjp2 2.1.0
>
> > Also what's the file name for liblept?
>
> The Debian liblept package provides:
>
> /usr/lib/liblept.so.5
> /usr/lib/liblept.so.5.0.0
>
> --
> Sean Whitton
>

Bug#679334: debian-installer: now in alpha3 system total freeze

[Martin Michlmayr]

* BasaBuru  [2016-02-18 21:46]:
> > basaburu, can you confirm things are working for you?
> 
> Yes, At last upgrade it's resolve

Ok, that's good.  Unfortunately, I cannot tell how BasaBuru's issue
relates to the one reported by KiBi originally, so I suggest KiBi
closes this bug if it's indeed fixed.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#679334: debian-installer: now in alpha3 system total freeze

[BasaBuru]

El Martes, 16 de febrero de 2016 20:40:51 usted escribió:
> * Steve McIntyre  [2015-10-28 21:44]:
> > >The bug is now more big, is not a minor bug
> > >
> > >The system is freeze when start.
> > >
> > >In my opinion the debian installer team need kill the bug NOW
> > >
> > >The newie users are very lost
> > 
> > We believe it's fixed in alpha 4 that was just released at the weekend
> > - please try that and see if if helps?
> 
> basaburu, can you confirm things are working for you?

Yes, At last upgrade it's resolve

-- 
Agur bero bat / a greeting

BasaBuru

  BASATU 

~  
basatia bihur zaitez
~

gako ID gnupg: F9044F8FC64B2544
hatz-aztarna: 13FF 7B28 D999 B957 F837 D566 F904 4F8F C64B 2544

Bug#803777: libqb: FTBFS on hurd-i386

[Svante Signell]

On Fri, 2016-02-19 at 21:22 +0100, Christoph Berg wrote:
> Re: Svante Signell 2016-02-18 <1455809556.5852.62.ca...@gmail.com>
> > Attached is an updated patch together with an updated symbols file,
> > generated
> > with gcc-5.3.1-5.
> 
> Hi Svante,
> 
> thanks for the updated patch, and I'm glad that libqb has now been
> built for the Hurd as well so the rest of the Clusterlabs stack has a
> chance to get running.
> 
> I'm not entirely sure what happened with sem_timedwait change. The
> configure.ac patch looks good to me, but unfortunately it makes the
> package fail on some architectures, e.g. on arm64:
> https://buildd.debian.org/status/fetch.php?pkg=libqb=arm64=0
> .17.2.real-5=1455889304
> https://buildd.debian.org/status/package.php?p=libqb
> 
> Does that make any sense to you?
> 

Hi Chistoph,

The check for a working sem_timedwait patch is from me, yes. Please
give me some time to find out what happened, no signals is expected to
be sent to that process. Dunno know (yet) what's the problem, the code
is fairly simple.

Thanks! 

Bug#815175: [buildd-tools-devel] Bug#815175: sbuild-update fails to unmount schroots on failure

[Ryan Kavanagh]

Hi Josch,

On Fri, Feb 19, 2016 at 09:07:46PM +0100, Johannes Schauer wrote:
> Quoting Ryan Kavanagh (2016-02-19 18:56:32)
> > rak@zeta:~$ sbuild-update -udr source:jessie-amd64
> > E: 15binfmt: update-binfmts: unable to open 
> > /var/run/schroot/mount/jessie-snap-a6a720c2-d20d-4251-b3a5-1e043da0e1e2/bin/sh:
> >  No such file or directory
> > E: 20copyfiles: cp: cannot create regular file 
> > '/var/run/schroot/mount/jessie-snap-a6a720c2-d20d-4251-b3a5-1e043da0e1e2/etc/resolv.conf':
> >  No such file or directory
> > E: jessie-snap-a6a720c2-d20d-4251-b3a5-1e043da0e1e2: Chroot setup failed: 
> > stage=setup-start
> > Chroot setup failed
> > Error setting up source:jessie-amd64 chroot
> > Chroot setup failed at /usr/bin/sbuild-update line 170.
> 
> this error looks strange.
> 
> Can you tell me a way how I can reproduce the problem you have with
> sbuild-update?

The above error is a classic case of PEBKAC. I accomplished it roughly
as follows:

mkfs.ext4 /dev/wd/jessie-chroot
mkdir /tmp/jessie
mount /dev/wd/jessie-chroot /tmp/jessie
sbuild-createchroot jessie /tmp/wd-jessie-chroot 
http://httpredir.debian.org/debian
umount /tmp/jessie
... delete /etc/schroot/schroot.d/* and add the appropriate LVM snapshot
... config entry to /etc/schroot/schroot.conf
suild-update -udr source:jessie-amd64

which then caused a snapshot of /dev/wd/jessie-chroot to get mounted,
which was empty (I fed the wrong path to sbuild-createchroot), and so
sbuild-update obviously couldn't find bin/sh under it :)

So, I suppose this should be considered a 'wishlist' bug, where
sbuild-update should fail gracefully and umount stuff even on failure.

Best wishes,
Ryan

-- 
|_)|_/  Ryan Kavanagh   | Debian Developer
| \| \  http://ryanak.ca/   | GPG Key 4A11C97A


signature.asc
Description: PGP signature

Bug#815125: linux-image-4.4.0-1-amd64 fails to load initrd - no booting

[Yves-Alexis Perez]

On Fri, 19 Feb 2016 16:24:06 +0900 Norbert Preining  wrote:
> Package: src:linux
> Version: 4.4.2-1
> Severity: critical
> Justification: breaks the whole system
> 
> Dear all,
> 
> till now I was running
>   linux-image-4.4.0-trunk-amd64 (from experimental)
> without any problem. Today I installed
>   linux-image-4.4.0-1-amd64 (version 4.4.2-1)
> and tried to boot into it. Booting stopped at 
>   Loading initrd
> and remains there.
> 
I'm experiencing this issue too, on a 2015 Lenovo ThinkPad X250, using UEFI
boot.

I've tried to boot a vanilla 4.4.2 kernel with custom configuration, which
boots fine. I'm rebuilding a vanilla 4.4.2 kernel with the Debian
configuration to check wether it boots fine or not.

It might be related to the UEFI patches added on top of the 4.4.2 kernel, not
sure when they appeared.

Regards,
-- 
Yves-Alexis



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

Bug#332498: RFH: openssl -- Secure Socket Layer (SSL) binary and related cryptographic tools

[Kurt Roeckx]

On Thu, Feb 18, 2016 at 04:19:27PM +0100, William Bonnet wrote:
> Hi Kurt
> 
> I am really interested in helping on this package.
> 
> Do you still need some help ? If yes please let me know. It is about
> one year without comments on this bug. Maybe you have found some
> people ? But it is still open :)
> 
> You can get in touch with me either through the BT, or directly by
> email or irc _william_. So we can define how to help

I'm always looking for help, in any way you want to help.

You can also talk to me on IRC with the nick Q_.


Kurt

Bug#814891: [PKG-Openstack-devel] Bug#814891: management interface does not show node statistics

[Gaudenz Steinlin]

Hi Thomas

Thomas Goirand  writes:

> Hi Benedikt,
>
> So, according to what you wrote, there's a missing feature in Jessie.
> But the general policy is to *not* add new features to the Stable branch
> of Debian, and likely, the release team would refuse such an update.

It's not a missing feature but a broken feature. The same feature was
working in wheezy and is working in stretch. Also the log attached to
the original report clearly shows that the feature was not just removed
but is broken but intended to be present.

> So I don't understand how any action can be made on this bug.
>
> Could you explicit what you expect the rabbitmq package maintainers to
> do in this case?

Bug severities are ultimately your call to decide upon but I would treat
this as an RC bug in a package in stable, try to find the upstream
commit that fixes it, apply this as a patch to the version in stable and
upload to stable-proposed-updates.

AFAIK the stable release team is commited to fixing RC bugs in stable
updates even if they are only found after the release.

I would consider this RC because it's a regression and because it makes
it impossible to monitor the node. You need the node statistics for
effective monitoring. Running something like RabbitMQ in production
without monitoring is not an option IMO.

Gaudenz

P.S.: I tried to set the correct version information on this bug so that
it's clear that it only affects stable. I hope I got it right, feel free
to adjust if my commands did not do the right thing (TM).


signature.asc
Description: PGP signature

Bug#815196: ITP: awlsim -- S7 compatible soft-PLC

[Michael Büsch]

Package: wnpp
Severity: wishlist
Owner: "Michael Büsch" 

* Package name: awlsim
  Version : 0.44?
  Upstream Author : Michael Buesch 
* URL : http://bues.ch/h/awlsim
* License : GPLv2+
  Programming Lang: Python
  Description : S7 compatible soft-PLC

Awlsim is a soft-PLC (see
https://en.wikipedia.org/wiki/Programmable_logic_controller) that can execute
STEP7 (see German https://de.wikipedia.org/wiki/STEP_7) compatible AWL/STL
code.

I plan to maintain the Debian package by myself.
The upstream repository, also maintained by me, already contains some basic
Debian packaging scripts. (see http://bues.ch/gitweb?p=awlsim.git;a=tree)

Bug#815195: Please add Ilias Tsitsimpis <i.tsitsim...@gmail.com> as a DM

[Ilias Tsitsimpis]

Package: debian-maintainers
Severity: normal

Hi,

please add my key, AD70 2001 13F0 D159 8485  04AB 0098 F613 1EB8 6413,
to the Debian Maintainers keyring.

The jetring changeset is attached.

Thanks,
Ilias
Comment: Add Ilias Tsitsimpis  as a Debian Maintainer
Date: Fri, 19 Feb 2016 23:30:03 +0200
Action: import
Recommended-By: 
  Apollon Oikonomopoulos 
Agreement: 
  https://lists.debian.org/debian-newmaint/2016/02/msg00016.html
Advocates: 
  https://lists.debian.org/debian-newmaint/2016/02/msg00017.html
Data: 
  -BEGIN PGP PUBLIC KEY BLOCK-
  Version: GnuPG v1
  
  mQINBFVVt30BEACcBjRz8BQV4Ab0FeWdjWZyOoz5SlsSY/kLGa/7y7Kx/F6Js++I
  2iluAXYFw3pl7qACWBxzUWb+rJsi7rO9GInaiugWVLybn6HWfkpGXZSSeS5MRN19
  yuGw84eGfxTxYBqjBPmKUk7Z+DTVGqee4SrYfylUklfzzcxRGBoAQO1IFa2pVIfa
  n10tQfE/qstBV/bB5//TKWixWo4Y56/BR5YJK/KKIM8GZ3Ta790iJMEd+Z0c2ZQ3
  V/IN6zhNdnD2KgSjbRPkOBO+ZSd9nuBeiizt+iyKaNnG+VCFTuu09J+aUJ+GlTRI
  gHUygCOxLDcftptycxDaZbF1T1rlKmzegEcE2fFIFptPqzEXw7QqZeAlDTxkG42I
  lbUEC17RxLrsdEQc4bMfnB/XGRpUM+/HAw/9afH4MoSkud6ZCZvgrw+MkLdVu3A9
  VFiH6xOzblmTvf31oQ+pb8jrmiklNWcGjEn+XXwvtgZVX2ABa9DFAZgjnaM6bPf8
  dgAdmxS6WV7g4vM5UZhWvLHttChZWjKOFNWH2gAyvY2lrlL2t35NdZEsnyE4hUqs
  CzK4Zv915n9XBlvvtWPu0tbw7Th9UxhqJiGNIT+XOjWqzlKhrE7f22YpvoawW1i/
  H7e1kfBRtdPX+QGppuSh4anDDYUOE+PgcQZFw+GwVWBsBv9aLYvY9oCZVwARAQAB
  tClJbGlhcyBUc2l0c2ltcGlzIDxpLnRzaXRzaW1waXNAZ21haWwuY29tPokCNwQT
  AQoAIQUCVVW3fQIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRAAmPYTHrhk
  E6yZD/93+EbhuKszjCPwXNnPlOqDw4kshmeGYDcMIxFGkF75OAY2srNVcEscRmBB
  gzlF3opKFtwpn9KJpET/Y76vPX4dvOXtFxuscUOTZybRPAUpPPREEW7DEzODI3uA
  OEQulpLucPaoAX0SU3kNbszPAE6qRAx7Z/Cuc/A1Pf+Pwh41B6uXjARIZfH2v/4m
  F4hSokqC86Ey856tuJgd/QaLCoEMhLfAxUIAfe5ai6i5ZlL0jVz9IWrK1hSnAZGi
  FD2Dp/kZEegeqeKMOBcQ91wlJ2TPaWGOqyVNODgkwlyJO4f9lho5uj2GETNZCsjM
  XCTTq1stGDXRHIfG8uHnHCLUv97o5MyACq6iWBSNj6DfIa0vcbkzwM2gCwVYapaD
  TMe16GdGwfIq/4e22JV4Z5o2NESI9+UjWTjGlynSEjFTo3LaEnQ5VxcNdFI+19R1
  SpD1a5lOwyuS72l8jwc8pPcie1JLV1DocKzrkRM8Fw30BnVPWicdVGlKQlPcnvW+
  99Y7NbiNEM+yxeggfAF6hl/OU6cR9FaMoqdHZwdV3O9QFaJTE8d8ODaWtbpVsLbk
  4dtuJN00RdQDfZ/kNHFX8gmR+mDYwUEQh6M24xyA04ORL17CdfSemCkfvXeNsoTW
  4Fqe3Cpcc8jvSynY5+h3QNhplcor0BZvIbFZhWlw/uwGTE0qeIkCHAQQAQoABgUC
  VVmdUgAKCRBvuJC6JfPj7goBD/9yHRBybjjo9MAVOozOniszASV1GrBUJOQ/MvAt
  peFQCn09GrdjutvM16uNyBw4OI+9KWjOJDdlHA81b+++I2yfDVO+8uz9Mv/DLOiu
  7968RyaJFXinOkaFZzMncybbCsKTOiLLsEsar/nWnN/GzSIzblDzuL0HbfFKQzxd
  jEif1jBINIzVPUHSjSpYmp5eied/6y6BnxPQt67Ne7q9CJIlDuRIfnICcYlSvKn5
  bhqrcbiqnbl8M5xxu9ZUtg6g4OgjWC1PK3EIX5Y4y7uErm7++47XzCcYZz1iPFDK
  akqMGcqUR7uinu51BXsS/80thJ5qbMkzvoilmp7tHkBaluUD3tWYFZvkLSkRTiAi
  8Vf+ux2J3ROpaqPysezpBl9o3k7cVVpkJi80c8he2wdUFPFU//jA0ftYaL20uQnG
  FpzKjXd+p+Ccpt9YUx5+gU4MHqmwzfIqQZr13WqKfzJ/b+57MYbn4mYi27UXbu3G
  aoHNpDp1OOUlt3OTpWuXhdvx1D1ZBUIHNjKrlBjYb+OfWUuLScjVxyrRjZvkI5zS
  EaSqYsd9/VhgB1B4wxBj6MzvlmmpgUizJI4tor6zbIHBG9WqWbsFsB0fvy4ail1h
  ADmQr49u+XfL7HWD9LTkoF19cCO1cavI8ERyZL1URlWiBU9DmAGwNfvYeghMf8ac
  FFEDJokCHAQQAQgABgUCViqUbwAKCRD1GxjHICSCJLnPD/4qPyF7iOBKurYb4jRC
  F6xwgiicA6O8qVTjP4JrmuPD2KjwgFiN6jZS7Q+HwLpLzUN3MOXZ/UDT3TJbjNNT
  lRq3pGp0GlpG0a6ahmcduuIEJix1EkhL+ZAMCmaDQYe3FZPlerS7yHTItHN3DIsN
  chQEOsTSXoFq9+Re6gueUrw7l1LPn234ZT1Vn8yDpl5CrWLnvJ1dnDDSvzCd12dX
  12SJj4OzEekl6wO7SpV98Q4qHLxybuqyN2w8vImZBoninVyiJ+hv0YUG8ijkW1cD
  xQJ54FuMfXLU5gDv+FwpeqlNhYoABcKUPunINxbFxTB+eIv3vGUde0TihsauLXwM
  vNrdsYFprNrswOjWucXbRCdWVDG+U0b4MxEBrJYNyqXtIH7FT6a08Rj5/WRPvIZa
  v6fAxcs/5kp/Zl3HCpF4UtMsLhsR7F0iS9WMFyhD7GCKkryNOBofej8mXmgx55cy
  MYDBtxLRRpPWFPDLnVHCXMMGUkfxamLpdZCTPo9tvNG+4A9lK70HPhFxqbiIUEzK
  pRd6j3TcXUnB/yLPCol0jwC8vHQepiMQ+OSlnKVotEOfjVjo4EdhiliVug8QYqZI
  WJC65D7ZBnoiHLpegzwh9v+VnRqtVtVFUq6B7rFm4inW3b7UewX1rrdBO83gWP57
  U9BT5QkY+b7rnePKdN/zVZ2oyYkCHAQQAQoABgUCVsTlbwAKCRDDvXgyaAwJbHl9
  EACSJy639VIykpvXb2useggn33ZQpwWX9SubkA1zLz3sK9jgXteF2coRat+WUgDY
  YK2TT1tNH8TtzdU3uH+r5elLap0Nj84X8YTzejxzF11hoL9YtcflAeCjFdhgIRdt
  WsziB6zfojlQb0+pf3uyc/yIfQj7fYoUXiY7tz1p7y5IJA6psd9B+FWLeO2yhIOT
  BIlzMmEUsV+LNJNDxdDhhp2/TLDt/YAYpMnpYUQQaUE9cPxN5zLFfIrTaHTGqS/e
  oArNG93h8Ufd9wwhw/0td4dRRJCbW7C1zaWduvu+E43XuEKz6OONYsBMs5AZ0YpR
  lxxslWgb9m8p5/dg/u4Jf/giX76wBP/z/MmPQtZTT9tK7rUdOBG+aE9HGMipI4ki
  ac+g1aISqwOB9zOZ+D+9VyoqVsgH3Iu1qySAJdvKOCeay7hg0FEXH+WedGo48CKH
  7SAggm+L6Nv10La1MXZ5PoPNCVnQBmXNqoN2ZUxwqIl+CnIMSHWwXzCYB6ObrWcA
  limglLSv9/ENoLIeQeuS6zNCEZx3B5NG2eu7RtYS+frC+hv0TQV9KPDrp/PAwq6d
  9NBYLp17cZOt1S9y03K8p/sG2j+ON+mf/87coKRpuAH/A/qPGSnOiY7h975/2HLd
  DL1SG3IOXMoEP4hN154XPCn2Dn1ADmAErF8kv61fHWkQMIkCHAQQAQoABgUCVsTl
  gQAKCRCdC15bHuyPDis5EADWBkbrkM5kB377lqOQ9V5zj+4hHuuU88jP6q9xpkAn
  GssfF8Fz1PWtaTfVizQ/CS7uT584KPSQjCYD42YBIV/q+cNWFDUbQQQK9LXIvRUJ
  ukanaB8+fpa0Hm3/+qoMCK88IY02ahqg4ScD9b0S1uVhCbbXTge27JpBa8V56dvt
  YLiqtp1zDjOoRF3up8Mazpb/nT0WoNODfSOLr6ffk43uq1nQWKYqGhSDaRBKUhiS
  dJl/0993mSZl7/b8rgYS2b9aBX3R2eKvLZkewgle+/Zw2BxGMeZrfxrXqoRfPGj4
  5MB4PIA3gw2Z75ChXLN57wddRCY08ej7WTVwPZIQOCKJlmdPGMd1oTiHTQxdNJQ3
  gm79OdOEjMa85j2SEdHKGUVDLM8nJo2v7xLNrUomI/Q+U2oJGZbieEZ49i/FRkDW
  

Bug#815194: fakechroot: env lists no environment variable

[jhcha54008]

Package: fakechroot
Version: 2.18-1
Severity: normal
Tags: patch

Dear Maintainer,

env in a fakechroot environment produces no output (instead of
listing all environment variables).

$ fakechroot fakeroot -s .fakeroot.state debootstrap --variant=fakechroot sid 
mychroot
[ ... ]
$ echo $?
0
$ fakechroot fakeroot -i .fakeroot.state -s .fakeroot.state chroot mychroot
# export EXAMPLE1="example1"
# env
# echo $?
0
# printenv
FAKECHROOT=true
SHELL=/bin/bash
TERM=linux
LD_PRELOAD=libfakeroot-sysv.so:libfakechroot.so
FAKECHROOT_EXCLUDE_PATH=/dev:/proc:/sys
[ ... ]
EXAMPLE1=example1
[...]

One recover the normal behavior of env with the following patch (all
environment variables are listed)

Thank you for your ongoing work on fakechroot !

Regards,
JH Chatenet

diff -Naur a/usr/bin/env.fakechroot b/usr/bin/env.fakechroot
--- a/usr/bin/env.fakechroot
+++ b/usr/bin/env.fakechroot
@@ -77,7 +77,7 @@
 
 if [ $# -eq 0 ]; then
 export | while read line; do
-if [ "$line" = "${line#declare -x }" ]; then
+if [ "$line" = "${line#declare -x }" ] && [ "$line" = "${line#export 
}" ]; then
 continue
 fi
 fakechroot_env_key="${line#declare -x }"
@@ -99,7 +99,7 @@
 
 if [ $fakechroot_env_ignore_env = yes ]; then
 fakechroot_env_keys=`export | while read line; do
-if [ "$line" = "${line#declare -x }" ]; then
+if [ "$line" = "${line#declare -x }" ] && [ "$line" = 
"${line#export }" ]; then
 continue
 fi
 fakechroot_env_key="${line#declare -x }"


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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: unable to detect

Versions of packages fakechroot depends on:
ii  libfakechroot  2.18-1

fakechroot recommends no packages.

fakechroot suggests no packages.

-- no debconf information

Bug#812325: amavisd-new fails recognizing viruses on non-English systems if the AV scanner writes localized messages to stdout

[Mike Gabriel]

HI Brian,

On  Do 11 Feb 2016 03:41:25 CET, Brian May wrote:


Brian May  writes:


Can you please test the following change to the init.d script and let me
know if it works for you?


Any success?

We need this tested before I can update stable.

Thanks.


it took me some time to set up a test system for this. I can now  
confirm that the issue re-occurred and that the proposed patch from  
this bug fixes the issue.


Thanks for the heads up!
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de


pgpAF4cNokKs8.pgp
Description: Digitale PGP-Signatur

Bug#815193: razorqt: please make the build reproducible

[Reiner Herrmann]

Source: razorqt
Version: 0.5.2-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that razorqt could not be built reproducibly.
While generating .desktop files, grep misdetects the input as binary
data when a non-UTF8 locale is used.
This leads to the embedding of lines like this into the files:
"Binary file 
/build/razorqt-0.5.2/razorqt-resources/sys/translations/razor_zh_TW.desktop 
matches"

The attached patch fixes this by telling grep to treat the input as
text.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/series b/debian/patches/series
index a7bfb4b..becb3b3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 lightdm3.patch
 libstatgrab-0.90.patch
+unicode-grep.patch
diff --git a/debian/patches/unicode-grep.patch b/debian/patches/unicode-grep.patch
new file mode 100644
index 000..7356279
--- /dev/null
+++ b/debian/patches/unicode-grep.patch
@@ -0,0 +1,22 @@
+Author: Reiner Herrmann 
+Description: Fix misdetection as binary input when LC_ALL=C
+
+--- a/cmake/RazorTranslate.cmake
 b/cmake/RazorTranslate.cmake
+@@ -238,13 +238,13 @@
+ set(_pattern "'\\[.*]\\s*='")
+ if (_translations)
+ add_custom_command(OUTPUT ${_outFile}
+-COMMAND grep -v "'#TRANSLATIONS_DIR='" ${_inFile} > ${_outFile}
+-COMMAND grep --no-filename ${_pattern} ${_translations} >> ${_outFile}
++COMMAND grep -a -v "'#TRANSLATIONS_DIR='" ${_inFile} > ${_outFile}
++COMMAND grep -a --no-filename ${_pattern} ${_translations} >> ${_outFile}
+ COMMENT "Generating ${_fileName}${_fileExt}"
+ )
+ else()
+ add_custom_command(OUTPUT ${_outFile}
+-COMMAND grep -v "'#TRANSLATIONS_DIR='" ${_inFile} > ${_outFile}
++COMMAND grep -a -v "'#TRANSLATIONS_DIR='" ${_inFile} > ${_outFile}
+ COMMENT "Generating ${_fileName}${_fileExt}"
+ )
+ endif()


signature.asc
Description: PGP signature

Bug#815191: stdeb: Uses cmd line options removed in apt-file 3

[Niels Thykier]

Source: stdeb
Severity: normal
Tags: sid stretch
Usertags: apt-file-3

Hi,

The stdeb file "stdeb/util.py" contains a function calling apt-file
twice.  First time with "--dummy --non-interactive" (and a second time
without).  The two options listed are not available in apt-file 3 and
the first call should probably be removed.

Thanks,
~Niels

Bug#815192: manpages-de: please make the build reproducible

[Reiner Herrmann]

Source: manpages-de
Version: 1.11-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that manpages-de could not be built reproducibly.
When processing po files with generate-addendum.sh and using a non-UTF8
locale, grep misdetects them as binary files and embeds the line:
"Binary file (standard input) matches"

The attached patch fixes this by telling grep to treat the input as
text.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..7ab0073
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+unicode-grep.patch
diff --git a/debian/patches/unicode-grep.patch b/debian/patches/unicode-grep.patch
new file mode 100644
index 000..61212eb
--- /dev/null
+++ b/debian/patches/unicode-grep.patch
@@ -0,0 +1,20 @@
+Author: Reiner Herrmann 
+Description: Fix misdetection as binary input when LC_ALL=C
+
+--- a/po/generate-addendum.sh
 b/po/generate-addendum.sh
+@@ -22,10 +22,10 @@
+ # and remove the comment character
+ translators=`sed '/msgid/q;s/^#\s\+//' "$pofile" |
+ # Throw away the common (non translator) lines
+-grep -v "German translation of manpages" |
+-grep -v "This file is distributed under the same license as the manpages-de package." |
+-grep -v "Copyright © of this file:" |
+-grep -v "msgid" |
++grep -a -v "German translation of manpages" |
++grep -a -v "This file is distributed under the same license as the manpages-de package." |
++grep -a -v "Copyright © of this file:" |
++grep -a -v "msgid" |
+ # Split lines to extract the name (and e-mail address)
+ cut -f1 -d","`
+ # Determine number of translators


signature.asc
Description: PGP signature

Bug#815190: dh-make-perl: Accesses apt-file 3 cache directly

[Niels Thykier]

Package: dh-make-perl
Severity: normal
Tags: sid stretch
Usertags: apt-file-3

Hi,

The dh-make-perl package has code to access the apt-file cache
directly.  In apt-file 3, this cache is removed (merged into APT's
cache).

Please update dh-make-perl accordingly.

 * Please use "apt-get indextargets [--format ...]" to find the cache
   files.  The apt-file ones you are interested in should generally be
   "Created-by: Contents-deb".

 * Please use "/usr/lib/apt/apt-helper cat-file files ..." for reading
   the files (to ensure you support all the compression algorithms
   supported by APT).

Thanks,
~Niels

Bug#815189: sftp uploader uses wrong user name ordering

[Michael Kuhn]

Package: dput-ng
Version: 1.10

When using the sftp uploader, the user name from the SSH configuration
is always preferred, that is, the order is currently: login name, dput
profile, SSH configuration. This is backwards because one might want to
override the user name in the dput profile.

The attached patch fixes the problem by changing the order as follows:
login name, SSH configuration, dput profile


Best regards,
MichaelFrom 7607fabdbe5cf7fd7b7f5d9890e568a48d9791ed Mon Sep 17 00:00:00 2001
From: Michael Kuhn 
Date: Fri, 19 Feb 2016 21:46:17 +0100
Subject: [PATCH] Fix user name ordering.

---
 dput/uploaders/sftp.py | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/dput/uploaders/sftp.py b/dput/uploaders/sftp.py
index e00b892..f902e58 100644
--- a/dput/uploaders/sftp.py
+++ b/dput/uploaders/sftp.py
@@ -56,16 +56,20 @@ def check_paramiko_version(req):
 return version_info >= req
 
 
-def find_username(conf):
+def find_username(conf, ssh_conf):
 """
-Given a profile (``conf``), return the preferred username to login
-with. It falls back to getting the logged in user's name.
+Given a profile (``conf``) and an SSH configuration (``ssh_conf``),
+return the preferred username to login with.
+The profile takes precedence over the SSH configuration.
+It falls back to getting the logged in user's name.
 """
 user = None
 user = pwd.getpwuid(os.getuid()).pw_name
+if 'user' in ssh_conf:
+user = ssh_conf['user']
 if 'login' in conf:
 new_user = conf['login']
-if new_user != "*":
+if new_user != '*':
 user = new_user
 if not user:
 raise SftpUploadException(
@@ -151,9 +155,7 @@ class SFTPUploader(AbstractUploader):
 config.parse(open(os.path.expanduser('~/.ssh/config')))
 o = config.lookup(fqdn)
 
-user = find_username(self._config)
-if "user" in o:
-user = o['user']
+user = find_username(self._config, o)
 
 ssh_kwargs['username'] = user
 
-- 
2.5.0

Bug#815188: aide: 31_aide_apt-file will need updating with apt-file 3

[Niels Thykier]

Source: aide
Severity: normal
Tags: sid stretch
Usertags: apt-file-3

Hi,

The file debian/aide.conf.d/31_aide_apt-file (in the source package)
contains code that lists files in the apt-file cache.

In apt-file 3, this cache has been removed (merged with APT regular
cache) and accordingly this file may need to be updated.

Thanks,
~Niels

Bug#803844: mplayer: FTBFS with FFmpeg 2.9

[Roberto Togni]

On Fri, 8 Jan 2016 20:31:01 +0100 Andreas Cadhalpun
 wrote:
> Hi Miguel,
> 
> On 08.01.2016 03:02, Miguel A. Colón Vélez wrote:
> > I was waiting for a clear idea of when FFmpeg was going to release to
> > decide if I should patch 1.2 or just take an upstream snapshot. Most
> > of the new bugs reports are fixed upstream so I will probably use an
> > upstream snapshot.
> 
> Wouldn't it be better if all relevant fixes were included in the 1.2.1
> release? Packaging snapshots is always a bit problematic as one never
> knows when a good time for packaging the next snapshot is and upstream
> doesn't really know which version of their code is used.
> 
> > Thanks for the reminder.
> 
> You're welcome and thanks for the quick reply. :)
> 
Hi,
 we just released MPlayer 1.3, which is compatible with FFmpeg 3.0.x

If possible, please upgrade to the new version instead of patching 1.2.1

Ciao,
 Roberto

Bug#815153: transition: libvigraimpex

[Emilio Pozuelo Monfort]

On 19/02/16 21:12, Daniel Stender wrote:
> On 19.02.2016 21:05, Emilio Pozuelo Monfort wrote:
>> Control: tags -1 moreinfo
>>
>> On 19/02/16 13:39, Daniel Stender wrote:
>>> However, libvigraimpex currently doesn't build on all official supported 
>>> archs,
>>> I'm on this to get solved and upload one more package in experimental soon.
>>
>> Let us know when that is solved. Bonus points if you also fix that in the
>> unstable package so the ilmbase & openexr transitions can finish.
>>
>> Cheers,
>> Emilio
> 
> All right.
> 
> "fix unstable package" meaning 1.10.0+git20160120.803d5d4-2 with 
> "libvigraimpex6", right?

Yes.

Cheers,
Emilio

Bug#815187: Bug debian-Installer jessie: Installation grub fails without error message

[François POLASTRON]

package: Debian-Installer
Version: 20150422+deb8u3 

Dear Maintener,

I found a big bug in debian-Installer on a "BIOS Legacy" computer
When trying to force grub installation in other device than primary disk, in 
graphical mode the menu lets the user choose the device:
/dev/sda
/dev/sdb
...
But when we choose one of a device debian-Installer don't install GRUB WITHOUT 
ERROR MESSAGE. 

In fact we must enter the device with the keyboard taping "/dev/sda"... to 
contourn the bug. 

Excuse-me for my english language. I'm a french guy

Bug#805645: dh-make: manpage.xml.ex uses , which fails to format correctly

[Craig Small]

On Sat, Nov 21, 2015 at 2:54 AM Julian Gilbey  wrote:

> I don't know whether this should be regarded as a dh-make issue or
> someone else's, but the example manpage.xml.ex included uses a
> , which is processed into
>
I'm not sure what it should be then as I don't use xml myself.

I agree, I'm not sure if this is valid xml and the parser is wrong or the
xml itself should be changed.

 - Craig

Bug#803777: libqb: FTBFS on hurd-i386

[Christoph Berg]

Re: Svante Signell 2016-02-18 <1455809556.5852.62.ca...@gmail.com>
> Attached is an updated patch together with an updated symbols file, generated
> with gcc-5.3.1-5.

Hi Svante,

thanks for the updated patch, and I'm glad that libqb has now been
built for the Hurd as well so the rest of the Clusterlabs stack has a
chance to get running.

I'm not entirely sure what happened with sem_timedwait change. The
configure.ac patch looks good to me, but unfortunately it makes the
package fail on some architectures, e.g. on arm64:
https://buildd.debian.org/status/fetch.php?pkg=libqb=arm64=0.17.2.real-5=1455889304
https://buildd.debian.org/status/package.php?p=libqb

Does that make any sense to you?

Relatedly, I'm puzzled why the rpl_sem_* symbols have suddenly
appeared. As your patch was the only change in the package, it must be
related. Was that expected? (I don't mind the symbols, I'm just
curious where they are coming from, given your patch looks like it
should be a no-op on the other architectures.)

>  rpl_sem_destroy@Base 0.17.2.real-4.1
>  rpl_sem_getvalue@Base 0.17.2.real-4.1
>  rpl_sem_init@Base 0.17.2.real-4.1
>  rpl_sem_post@Base 0.17.2.real-4.1
>  rpl_sem_timedwait@Base 0.17.2.real-4.1
>  rpl_sem_trywait@Base 0.17.2.real-4.1
>  rpl_sem_wait@Base 0.17.2.real-4.1

These are new, on all architectures and even on jessie.

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/

Bug#815186: libfile-mimeinfo-perl: mimeopen should ship a *.desktop file

[Kernc]

Package: libfile-mimeinfo-perl
Version: 0.27-1
Severity: normal

Dear Maintainers!

/usr/bin/mimeopen, working fabulously for downloaded files of
application/octet-stream mime type, should include a
/usr/share/applications/mimeopen.desktop file like the following:

[Desktop Entry]
Type=Application
Version=1.0
Name=mimeopen
GenericName=Open with default application
Comment=Mime-type and file extension-aware file opener
Exec=mimeopen -n %F
Icon=system-run
Terminal=false
MimeType=application/octet-stream

This will allow e.g. Iceweasel to exploit mimeopen's stated ability to open
application/octet-stream files (which browsers often receive when
appropriate response headers are not sent) and the latter will open
the file with preferred application without problem.

Since one can't really sensibly associate application/octet-stream with
any single application, the attached file most elegantly solves the issue
of Iceweasel proposing to open, for one ffs example, downloaded PDF
files in VLC or tar.gz archives in audacious!

Thanks!


mimeopen.desktop
Description: application/desktop

Bug#815124: webkit2gtk FTBFS on alpha; configure code not detecting arch properly

[Michael Cree]

On Fri, Feb 19, 2016 at 10:06:35AM +0200, Alberto Garcia wrote:
> On Fri, Feb 19, 2016 at 07:36:38PM +1300, Michael Cree wrote:
> 
> > webkit2gtk FTBFS on alpha due to the configure code not fully
> > configuring the build for the arch.  I attach a patch which fixes
> > the issue.
> 
> Applied, thanks! It will go in the next upload.

Thanks.  Just confirming that the test build of 2.10.6-1 with that
patch I set going has now built to completion.

Michael.

Bug#815153: transition: libvigraimpex

[Daniel Stender]

On 19.02.2016 21:05, Emilio Pozuelo Monfort wrote:
> Control: tags -1 moreinfo
> 
> On 19/02/16 13:39, Daniel Stender wrote:
>> However, libvigraimpex currently doesn't build on all official supported 
>> archs,
>> I'm on this to get solved and upload one more package in experimental soon.
> 
> Let us know when that is solved. Bonus points if you also fix that in the
> unstable package so the ilmbase & openexr transitions can finish.
> 
> Cheers,
> Emilio

All right.

"fix unstable package" meaning 1.10.0+git20160120.803d5d4-2 with 
"libvigraimpex6", right?

DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
http://www.danielstender.com/blog/

Bug#815185: aptitude: [INTL:nl] Dutch po file for the aptitude package

[Frans Spiesschaert]

 

Package: aptitude 
Severity: wishlist 
Tags: l10n patch 
 

Dear Maintainer, 
 
== 
Please find attached the updated Dutch po file for the aptitude package. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
=== 
 

-- 
Cheers,
Frans

===
http://home.base.be/vt6362833/



nl.po.gz
Description: application/gzip


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

Bug#790925: pandas: FTBFS on armhf and sparc: Bus error in test_append_frame_column_oriented

[Yaroslav Halchenko]

On Fri, 19 Feb 2016, Lennart Sorensen wrote:

> On Fri, Feb 19, 2016 at 12:11:35PM -0500, Yaroslav Halchenko wrote:
> > Thanks for looking into it. Fwiw, for such cases better to use python-dbg 
> > so you could then py-bt and do more introspection within attached gdb. You 
> > would need -dbg packages for numpy etc

> I hadn't ever needed to debug python before, and since the error seemed
> to be in C code, not python code, I wasn't sure looking for a python
> way of debugging would help.

it would show python stack which might give better idea of the scope
etc.  Not that it is a panacea but I found it handy from time to time

> I can't seem to guess how to use python-dbg though.  Certainly just
> replacing python with python-dbg doesn't work in this case.

you just need to rebuild entire pandas using python-dbg, smth like

python-dbg setup.py build_ext --inplace

and then use it straight from there

P.S. for some packages I did provide -lib-dbg package with extensions
built using python-dbg, sorry that I took a shortcut with pandas

Thanks again for looking into it

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

Bug#813562: Test suite failure

[Sean Whitton]

Hello,

On Fri, Feb 19, 2016 at 07:11:32AM +, James R Barlow wrote:
> What version of leptonica is installed?
> tesseract --version will report this.

From within my Sid chroot:

root@artemis:/build/ocrmypdf-4.0.1# tesseract --version
tesseract 3.04.01
 leptonica-1.73
  libgif 5.1.2 : libjpeg 6b (libjpeg-turbo 1.4.2) : libpng 1.2.54 : libtiff 
4.0.6 : zlib 1.2.8 : libwebp 0.4.4 : libopenjp2 2.1.0

> Also what's the file name for liblept?

The Debian liblept package provides:

/usr/lib/liblept.so.5
/usr/lib/liblept.so.5.0.0

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#813661: xserver-xorg-video-intel: severe display corruption on Sandy Bridge

[Romain Francoise]

On Thu, Feb 04, 2016 at 07:00:58AM +0100, Peter Colberg wrote:
> Since upgrading to the above version, I am experiencing severe display
> corruption on a Sandy Bridge GPU when using the chromium browser.
> Other graphical applications (xterm, evince, gimp) are not affected.
>
> The corruption occurs when the window spans the full width of the
> screen, and disappears when reducing the window to half the width.
> (I am using the awesome tiling window manager.) Please see the
> attached screenshots of the full width versus half width case.

I'm seeing something similar with Chrome in full screen mode, awesome
and the xserver-xorg-video-intel version currently in testing.
Reverting to 2.99.917-2 fixes it as well.

Did you file an upstream bug?

Thanks,
-- 
Romain Francoise 
http://people.debian.org/~rfrancoise/

Bug#815184: Interop with *.desktop entries

[Adam Majer]

Package: menu
Version: 2.1.47
Severity: normal

Since the decision about #741573, it seems that menu package can no
longer depend on packages providing proper menu entries if a .desktop
file is installed. Menu window managers still depend on `menu` package
as its sole source of menu information, for example fluxbox.

Is there any work being done to consolidate /usr/share/applications/*
with /usr/share/menu/* entries?  More specifically, is there any work
being done for menu to parse .desktop files in addition to the
standard menu entries?

Thanks,
Adam

Bug#815175: [buildd-tools-devel] Bug#815175: sbuild-update fails to unmount schroots on failure

[Johannes Schauer]

Hi,

Quoting Ryan Kavanagh (2016-02-19 18:56:32)
> rak@zeta:~$ sbuild-update -udr source:jessie-amd64
> E: 15binfmt: update-binfmts: unable to open 
> /var/run/schroot/mount/jessie-snap-a6a720c2-d20d-4251-b3a5-1e043da0e1e2/bin/sh:
>  No such file or directory
> E: 20copyfiles: cp: cannot create regular file 
> '/var/run/schroot/mount/jessie-snap-a6a720c2-d20d-4251-b3a5-1e043da0e1e2/etc/resolv.conf':
>  No such file or directory
> E: jessie-snap-a6a720c2-d20d-4251-b3a5-1e043da0e1e2: Chroot setup failed: 
> stage=setup-start
> Chroot setup failed
> Error setting up source:jessie-amd64 chroot
> Chroot setup failed at /usr/bin/sbuild-update line 170.

this error looks strange.

Can you tell me a way how I can reproduce the problem you have with
sbuild-update?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#815153: transition: libvigraimpex

[Emilio Pozuelo Monfort]

Control: tags -1 moreinfo

On 19/02/16 13:39, Daniel Stender wrote:
> However, libvigraimpex currently doesn't build on all official supported 
> archs,
> I'm on this to get solved and upload one more package in experimental soon.

Let us know when that is solved. Bonus points if you also fix that in the
unstable package so the ilmbase & openexr transitions can finish.

Cheers,
Emilio

Bug#814544: wheezy-pu: package clamav/0.99+dfsg-0+deb7u1

[Adam D. Barratt]

On Fri, 2016-02-19 at 08:31 -0800, Scott Kitterman wrote:
> 
> On February 19, 2016 6:22:19 AM PST, "Adam D. Barratt" 
>  wrote:
> >On Fri, 2016-02-19 at 05:56 +, Adam D. Barratt wrote:
> >> On Thu, 2016-02-18 at 22:54 +, Adam D. Barratt wrote:
> >> > Control: tags -1 + pending
> >> > 
> >> > On Wed, 2016-02-17 at 22:18 -0500, Scott Kitterman wrote:
> >> [...]
> >> > > Thanks.  Both clamav and libclamunrar source uploads are done. 
> >I'll see what 
> >> > > I can get done about getting them pushed through New.
> >> > 
> >> > clamav got through NEW earlier today and has already built
> >everywhere
> >> > except sparc. I've scheduled the binNMUs with appropriate
> >dep-waits.
> >> 
> >> The sparc build has now failed three times, across two different
> >builds.
> >
> >c-icap-modules also appears to have FTBFS on all architectures.
> 
> OK. Will have a look at that too.

Thanks.

Regards,

Adam

Bug#815126: linux-image-4.4.0-1-amd64 hangs after 'Loading initial ramdisk ...'

[Martin Dickopp]

On Fri, Feb 19, 2016 at 10:50:34AM +0100, Vincent Bernat wrote:
>  ❦ 19 février 2016 07:34 GMT, Jim Barber 
>  :
> 
> > I upgraded from linux-image-4.3.0-1-amd64 (version 4.3.5-1) to 
> > linux-image-4.4.0-1-amd64.
> > On rebooting the system I am presented with grub, and then start booting 
> > into Linux.
> > I only get to see 2 lines with the cursor below them on the lefthand side.
> >
> > Loading Linux 4.4.0-1 ...
> > Loading initial ramdisk ...
> > _
> >
> > The system freezes at this point and is unresponsive.
> > I have to hold my power button down for approx 10s to power off the laptop.
> > Booting back into linux-4.3.0-1-amd64 works fine.
> 
> I am in the same situation. I am also on the same system (Thinkpad X1
> Carbon, but 2nd).

I observe exactly the same behavior on my Toshiba Kira 10D.

Best regards,
Martin

Bug#813370: vlc: no video in h264 files

[Andreas Weber]

On 2016-02-19 01:54, Rémi Denis-Courmont wrote:
> As far as I know, this is a bug in libvdpau-va-gl.
> 
> Uninstall the libvdpau-va-gl1 package and restart VLC.

Did that, works, thank you!

Bug#815162: xserver-xorg-legacy: completely broken (locks up input / xf86OpenConsole: Cannot open virtual console)

[Jan Braun]

Sven Joachim schrob:
> You need to install libpam-systemd, or put "needs_root_rights = yes" in
> /etc/X11/Xwrapper.config.

Thanks, needs_root_rights=yes solves the issue.
[systemd rant available on request]

> See #814313 and #814394.

If you want to downgrade (and merge with #814313), I won't object, but
I'll not do that myself because dataloss failure mode and apt-listbugs
visibility.
Sorry for not finding the dups on my own, though.

Thank you,
Jan


signature.asc
Description: PGP signature

Bug#790925: pandas: FTBFS on armhf and sparc: Bus error in test_append_frame_column_oriented

[Lennart Sorensen]

On Fri, Feb 19, 2016 at 12:11:35PM -0500, Yaroslav Halchenko wrote:
> Thanks for looking into it. Fwiw, for such cases better to use python-dbg so 
> you could then py-bt and do more introspection within attached gdb. You would 
> need -dbg packages for numpy etc

I hadn't ever needed to debug python before, and since the error seemed
to be in C code, not python code, I wasn't sure looking for a python
way of debugging would help.

I can't seem to guess how to use python-dbg though.  Certainly just
replacing python with python-dbg doesn't work in this case.

I just get this:

+ export VER=3.5
+ echo 3.5
+ grep -q ^3
+ PY=3
+ pwd
+ /bin/ls -d /tmp/pandas-0.17.1/debian/tmp/usr/lib/python3/dist-packages/
+ export PYTHONPATH=/tmp/pandas-0.17.1/debian/tmp/usr/lib/python3/dist-packages/
+ pwd
+ pwd
+ export MPLCONFIGDIR=/tmp/pandas-0.17.1/build HOME=/tmp/pandas-0.17.1/build
+ python3.5 ci/print_versions.py

INSTALLED VERSIONS
--
commit: None
python: 3.5.1.final.0
python-bits: 32
OS: Linux
OS-release: 3.19.0-armmp
machine: armv7l
processor: 
byteorder: little
LC_ALL: None
LANG: en_CA.UTF-8

pandas: 0.17.1
nose: 1.3.7
pip: None
setuptools: 20.1.1
Cython: 0.23.2
numpy: 1.11.0b3
scipy: 0.17.0
statsmodels: None
IPython: None
sphinx: 1.3.5
patsy: None
dateutil: 2.4.2
pytz: 2012c
blosc: None
bottleneck: None
tables: 3.2.2
numexpr: 2.5
matplotlib: 1.5.1
openpyxl: None
xlrd: None
xlwt: None
xlsxwriter: None
lxml: None
bs4: 4.4.1
html5lib: 0.999
httplib2: None
apiclient: None
sqlalchemy: None
pymysql: None
psycopg2: None
Jinja2: None
+ cd build/
+ LC_ALL=C.UTF-8 xvfb-run -a -s -screen 0 1280x1024x24 -noreset python3.5-dbg 
/usr/bin/nosetests -s -v -A not network and not disabled 
pandas.io.tests.test_pytables:pandas.io.tests.test_pytables.TestHDFStore.test_append_frame_column_oriented
Failure: ImportError (C extension: 'hashtable' not built. If you want to import 
pandas from the source directory, you may need to run 'python setup.py 
build_ext --inplace' to build the C extensions first.) ... ERROR

==
ERROR: Failure: ImportError (C extension: 'hashtable' not built. If you want to 
import pandas from the source directory, you may need to run 'python setup.py 
build_ext --inplace' to build the C extensions first.)
--
Traceback (most recent call last):
  File 
"/tmp/pandas-0.17.1/debian/tmp/usr/lib/python3/dist-packages/pandas/__init__.py",
 line 7, in 
from pandas import hashtable, tslib, lib
ImportError: cannot import name 'hashtable'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest
raise self.exc_val.with_traceback(self.tb)
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 407, in 
loadTestsFromName
module = resolve_name(addr.module)
  File "/usr/lib/python3/dist-packages/nose/util.py", line 312, in resolve_name
module = __import__('.'.join(parts_copy))
  File 
"/tmp/pandas-0.17.1/debian/tmp/usr/lib/python3/dist-packages/pandas/__init__.py",
 line 13, in 
"extensions first.".format(module))
ImportError: C extension: 'hashtable' not built. If you want to import pandas 
from the source directory, you may need to run 'python setup.py build_ext 
--inplace' to build the C extensions first.

--
Ran 1 test in 0.010s

FAILED (errors=1)


-- 
Len Sorensen

Bug#815154: gnome-control-center removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard

[Andreas Henriksson]

Hello Anton Zinoviev.

Thanks for quick followup I sympathize with being left to debug
a "corrupt" file which you don't know if your tool wrote or not, while
not having any (for the moment known) way to reproduce the problem.

On Fri, Feb 19, 2016 at 08:52:25PM +0300, Anton Zinoviev wrote:
[...]
> In my opinion "correctly" (in this case) means this:
> If some configuration program wants to modify the value of some variable in 
> /etc/default/keyboard, it can do so.

I agree about this interpretation.

> The modifying program, however, has to leave everything else intact:
> assignments of unknown variables, commented lines and blank lines.

I don't think this is good advice however.

Consider the highly theoretical case of a very simple configuration
program only dealing with XKBLAYOUT and leaving other fields intact,
eg. XKBVARIANT.

Consider the difference between:

XKBLAYOUT="us"

... and ...

XKBLAYOUT="us"
XKBVARIANT="dvorak"

I bet a person who ends up with the latter when expecting the
former would be really surprised.


Also consider what this theoretical program which toggles between
us and swedish layout would do to this file:

XKBLAYOUT="se"
XKBVARIANT="dvorak"

What does  mean? Possibly "svorak" (which is an actual layout) but
I'm not sure the above is the correct syntax for that.

IMHO leaving unknown fields untouched is to be considered harmful.

(fwiw, I'm a user of us-dvorak + swedish (qwerty) myself, as well as
someone who highly dislikes svorak.)

[...]
> XKBMODEL has no default value (at least in console-setup).  It should
> always be present and never as empty value.

(If there's no default, how can it be expected to never be empty?!
Also empty seems to be perfectly acceptable by/for X atleast.)

> 
> XKBOPTIONS is not necessary in which case empty value is assumed.
> Notice however that XKBOPTIONS should never be empty (or missing) when
> the keyboard is for a non-Latin language.

Thanks for this advice. I think it would be great if we could formalize
the expectations programs parsers (and writers) of /etc/default/keyboard
can make on a wiki.debian.org page or similar

I'm thinking a table with all known variables listed plus if they're
optional, default value,  what else?

(Once it's more clear to me I'll volunteer trying to improve the debian
systemd/localed patch to follow your advice when I find time, unless someone
else beats me to it. Main question would be the one in paranthesis above.)

> Since gnome-control-center doesn't provide means to configure
> XKBOPTIONS, I suppose it will be best if it leaves the current value
> unchanged (this is debatable).

As discussed above I don't really agree and appreciate this being
debatable. ;)

For model and options (which is part of the SetX11Keyboard dbus API)
gnome-control-center would have to read out the current setting and pass
it back when setting it again if we want to follow your suggestion as
there's (as far as I can see) is no way to signal over the dbus api to
"leave value unchanged".

For other (unknown) values the systemd patch would need to be changed as
it currently only reads out a fixed set of variables (those matching the
known set included in the dbus apis) and unlinks the existing file on
writing out new settings.

Before implementing any of the above I really think we should think
twice about it though. As mentioned I think leaving unknown fields
untouched can lead to unexpected results and it's much better to
always consider any reconfiguration as the full details of the wanted
new configuration setting.

> 
> > I also noticed that patched localed writes out the file without the
> > values quoted is that considered required?
> > eg. FOO="bar" becomes FOO=bar when localed writes the file.
> 
> Thank you for noticing this. It doesn't matter whether it will be FOO="bar" 
> or 
> FOO=bar, as long as bar doesn't contain spaces.  I don't know if there is any 
> configuration program which puts spaces there, but both console-setup and X 
> permit spaces, so the sysadmin may put spaces there.  I've just tested that 
> gnome-control-center doesnt work properly when the values contain spaces (for 
> example when XKBLAYOUT="us, fr").  Fortunately, it doesn't put spaces in bar. 
> However it erases some parts of the string.  This is another bug.

Thanks for looking into this and I also think we should continue that
discussion in a separate bug report to keep focus on the more important
and practical problem in this bug report.

Regards,
Andreas Henriksson

Bug#815182: debmake: Should MIT copyright be renamed to Expat?

[Petter Reinholdtsen]

Package: debmake
Version: 4.2.2-1
Severity: important

I believe
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-specification
 >
specify the license text present in /usr/share/debmake/extra4/MIT should
be named Expat, not MIT.  Do you agree?

I noticed when using 'debmake -k' and debmake asked me to rename Expat
to MIT in the zfs package.

If I am right, I believe this is an important bug to fix as it is very
misleading to recommend the wrong license name and complain about
correct license names.  Setting severity accordingly.

-- 
Happy hacking
Petter Reinholdtsen

Bug#801253: how to handle not much used feature which depends on a deprecated technology

[toogley]

Hey.

i want to fix this 
https://lintian.debian.org/tags/dbus-policy-at-console.html report in 
the wicd package.


the concerning lines in the wicd source dir are
(https://anonscm.debian.org/cgit/collab-maint/wicd.git/tree/other/wicd.conf)
--













--


the situation is this: the above feature is depending on consolekit, 
which is not actively maintained. Consolekit was, according to the git 
history of d/control never a dependency of wicd (at least in debian).


I don't have much evidence on this, but i doubt this feature was much 
consciously used. I mean, neither the manpages of wicd, nor anything 
else than the actual code are mentioning this feature. At least i didn't 
found anything else. And generally, that block is not very "beautiful" 
in my eyes, beacause it changes the behavior of wicd in relation of 
consolekit - without notifying the user about that.


So basically, i think i have 2 options:

1) remove that block in debian completely and ask upstream to do the same.

2) because of the lintian warning and the obsolescence of consolekit, 
converting that part to systemd-logind and send that to upstream.



what do you think about that? Am i missing sth?

Bug#815000:

[Eric H. Jung]

> until when [791645] gets
> solved, there's no way to use recent icedove releases with FoxyProxy.

That is correct.

Eric Jung
FoxyProxy

Bug#815140: [Pkg-utopia-maintainers] Bug#815140: network-manager: lib update breaks openconnect in NM

[Mike Miller]

On Fri, Feb 19, 2016 at 15:30:39 +0100, Michael Biebl wrote:
> 
> Not sure whether this is a KDE issue or openconnect issue.
> I use neither of them.
> 
> Mike, can you have a look?

I also don't use KDE.

I've just updated to 1.1.90, and I don't see any openconnect connection
problems here with gnome-shell.

-- 
mike

Bug#815181: RM: ismrmrd -- ROM; FTBFS [armhf hppa]

[Ghislain Vaillant]

Package: ftp.debian.org
Severity: normal

Dear ftp team,

Since enabling the testsuite for the ismrmrd source package, a few
architectures started to FTBFS, mostly due to usage of non-portable
code in the implementation of the library and its corresponding
testsuite.

I managed to fix most of them in subsequent uploads and iterations with
upstream, but hit a deadend for the armhf and hppa architectures.
Upstream has no interest in dedicating time supporting any of both, so
I will have to rely on support from porters, which will take time.

Meanwhile, may I ask you guys to allow the package to transition to
testing by removing the existing ismrmrd binary packages for both
armhf and hppa architectures.

Many thanks,
Ghislain

Bug#815179: xdelta3: diff for NMU version 3.0.8-dfsg-1.2

[Salvatore Bonaccorso]

Package: xdelta3
Version: 3.0.8-dfsg-1.1
Severity: normal
Tags: patch pending

Dear Andrea,

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

This actually should have been even better included in my previous NMU
(adding the tests and fixing the lzma tests).

Regards,
Salvatore
diff -Nru xdelta3-3.0.8-dfsg/debian/changelog xdelta3-3.0.8-dfsg/debian/changelog
--- xdelta3-3.0.8-dfsg/debian/changelog	2016-02-10 21:33:48.0 +0100
+++ xdelta3-3.0.8-dfsg/debian/changelog	2016-02-19 19:11:56.0 +0100
@@ -1,3 +1,12 @@
+xdelta3 (3.0.8-dfsg-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update CVE-2014-9765.patch.
+Add as well tests that the default appheader works.
+  * Fix LZMA tests (Closes: #740284)
+
+ -- Salvatore Bonaccorso   Fri, 19 Feb 2016 13:23:39 +0100
+
 xdelta3 (3.0.8-dfsg-1.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru xdelta3-3.0.8-dfsg/debian/patches/CVE-2014-9765.patch xdelta3-3.0.8-dfsg/debian/patches/CVE-2014-9765.patch
--- xdelta3-3.0.8-dfsg/debian/patches/CVE-2014-9765.patch	2016-02-10 21:33:48.0 +0100
+++ xdelta3-3.0.8-dfsg/debian/patches/CVE-2014-9765.patch	2016-02-19 19:11:56.0 +0100
@@ -2,14 +2,21 @@
 Origin: upstream, https://github.com/jmacd/xdelta/commit/969e65d3a5d70442f5bafd726bcef47a0b48edd8
 Bug-Debian: https://bugs.debian.org/814067
 Forwarded: not-needed
-Author: "josh.macdonald" 
+Author: Josh MacDonald 
 Reviewed-by: Salvatore Bonaccorso 
 Last-Update: 2016-02-10
 Applied-Upstream: 3.0.9
 
+---
+ xdelta3-main.h |  5 ++--
+ xdelta3-test.h | 83 +++---
+ 2 files changed, 83 insertions(+), 5 deletions(-)
+
+diff --git a/xdelta3-main.h b/xdelta3-main.h
+index 090b7d9..5146b38 100644
 --- a/xdelta3-main.h
 +++ b/xdelta3-main.h
-@@ -2810,14 +2810,15 @@ main_get_appheader (xd3_stream *stream,
+@@ -2810,14 +2810,15 @@ main_get_appheader (xd3_stream *stream, main_file *ifile,
  
if (appheadsz > 0)
  {
@@ -27,3 +34,132 @@
  	{
  	  *slash = 0;
  	  parsed[place++] = start;
+diff --git a/xdelta3-test.h b/xdelta3-test.h
+index e9848b6..dd45528 100644
+--- a/xdelta3-test.h
 b/xdelta3-test.h
+@@ -166,7 +166,7 @@ static int do_cmd (xd3_stream *stream, const char *buf)
+ 	{
+ 	  stream->msg = "abnormal command termination";
+ 	}
+-  return XD3_INTERNAL;
++  return ret;
+ }
+   return 0;
+ }
+@@ -429,12 +429,12 @@ test_compare_files (const char* tgt, const char *rec)
+ }
+ 
+ static int
+-test_save_copy (const char *origname)
++test_copy_to (const char *from, const char *to)
+ {
+   char buf[TESTBUFSIZE];
+   int ret;
+ 
+-  snprintf_func (buf, TESTBUFSIZE, "cp -f %s %s", origname, TEST_COPY_FILE);
++  snprintf_func (buf, TESTBUFSIZE, "cp -f %s %s", from, to);
+ 
+   if ((ret = system (buf)) != 0)
+ {
+@@ -445,6 +445,12 @@ test_save_copy (const char *origname)
+ }
+ 
+ static int
++test_save_copy (const char *origname)
++{
++  return test_copy_to(origname, TEST_COPY_FILE);
++}
++
++static int
+ test_file_size (const char* file, xoff_t *size)
+ {
+   struct stat sbuf;
+@@ -2361,6 +2367,76 @@ test_no_output (xd3_stream *stream, int ignore)
+   return 0;
+ }
+ 
++/* This tests that the default appheader works */
++static int
++test_appheader (xd3_stream *stream, int ignore)
++{
++  int i;
++  int ret;
++  char buf[TESTBUFSIZE];
++  char bogus[TESTBUFSIZE];
++  xoff_t ssize, tsize;
++  test_setup ();
++
++  if ((ret = test_make_inputs (stream, , ))) { return ret; }
++
++  snprintf_func (buf, TESTBUFSIZE, "%s -q -f -e -s %s %s %s", program_name,
++		 TEST_SOURCE_FILE, TEST_TARGET_FILE, TEST_DELTA_FILE);
++  if ((ret = do_cmd (stream, buf))) { return ret; }
++
++  if ((ret = test_copy_to (program_name, TEST_RECON2_FILE))) { return ret; }
++
++  snprintf_func (buf, TESTBUFSIZE, "chmod 0700 %s", TEST_RECON2_FILE);
++  if ((ret = do_cmd (stream, buf))) { return ret; }
++
++  if ((ret = test_save_copy (TEST_TARGET_FILE))) { return ret; }
++  if ((ret = test_copy_to (TEST_SOURCE_FILE, TEST_TARGET_FILE))) { return ret; }
++
++  if ((ret = test_compare_files (TEST_TARGET_FILE, TEST_COPY_FILE)) == 0)
++{
++  return XD3_INVALID;  // I.e., files are different!
++}
++
++  // Test that the target file is restored.
++  snprintf_func (buf, TESTBUFSIZE, "(cd /tmp && %s -q -f -d %s)",
++		 TEST_RECON2_FILE,
++		 TEST_DELTA_FILE);
++  if ((ret = do_cmd (stream, buf))) { return ret; }
++
++  if ((ret = test_compare_files (TEST_TARGET_FILE, TEST_COPY_FILE)) != 0)
++{
++  return ret;
++}
++
++  // Test a malicious string w/ entries > 4 in the appheader by having
++  // the encoder write it:
++  for (i = 0; i < TESTBUFSIZE / 4; ++i)
++{
++  bogus[2*i] = 'G';
++  bogus[2*i+1] = '/';
++}
++  bogus[TESTBUFSIZE/2-1] = 0;
++
++  snprintf_func 

Bug#815180: isc-dhcp-server: New initscript breaks `service isc-dhcp-server status`

[Pierre Ynard]

Package: isc-dhcp-server
Version: 4.3.3-8
Severity: important

After migrating from 4.3.3-5, I have two obvious issues with the
status command of the new initscript:

 - It fails to see that any servers are running, and returns:

# service isc-dhcp-server status
Status of ISC DHCPv4 server:  is not running.
Status of ISC DHCPv6 server:  is not running.

   regardless of what server is actually running. This is because it
   checks the wrong variables DHCPv4/6_PID, which are never set, instead
   of DHCPDv4/6_PID

 - When upgrading from a simple DHCPv4-only setup, the status command
   will return an error code if the DHCPv4 server is running but the
   DHCPv6 server is not running, even if the latter is disabled in the
   configuration. This seems wrong and breaks stuff. I suggest that the
   status command uses `test -n "$INTERFACESv4/6"` conditional guards
   similar to the start command too, with the $INTERFACES magic factored
   out.

Please fix the status command in all cases.

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

Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages isc-dhcp-server depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  debianutils4.7
ii  libc6  2.21-9
ii  libdns-export100   1:9.9.5.dfsg-12.1
ii  libirs-export911:9.9.5.dfsg-12.1
ii  libisc-export951:9.9.5.dfsg-12.1
ii  lsb-base   9.20160110

Versions of packages isc-dhcp-server recommends:
pn  isc-dhcp-common  
pn  policycoreutils  

Versions of packages isc-dhcp-server suggests:
pn  isc-dhcp-server-ldap  

-- Configuration Files:
/etc/dhcp/dhcpd.conf changed [not included]

-- debconf information excluded

Bug#815135: No cursor displayed

[Vincent Bernat]

 ❦ 19 février 2016 15:40 +0200, Timo Aaltonen  :

>> Since last upgrade, no cursor is displayed in my case. Dunno exactly
>> how to investigate such an issue. Tried to reboot several time, to
>> switch screens with xrandr. No luck.
>
> works fine on my haswell, have you tried another device?

Don't have a problem on my home station (Haswell as well).
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#815162: xserver-xorg-legacy: completely broken (locks up input / xf86OpenConsole: Cannot open virtual console)

[Sven Joachim]

On 2016-02-19 16:24 +0100, Jan Braun wrote:

> Package: xserver-xorg-legacy
> Version: 2:1.18.1-1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> Starting X via "startx" somehow locks up the input system: my xsession
> starts up, but keyboard and trackpoint stop working (including
> ctrl-alt-f#, ctrl-alt-backspace).
> My music player keeps playing, so the computer is alive, I just can't
> interact with it. I don't have ssh access or even an external keyboard
> right now, so my only option is to force a shutdown.

You need to install libpam-systemd, or put "needs_root_rights = yes" in
/etc/X11/Xwrapper.config.  See #814313 and #814394.

Cheers,
   Sven

Bug#815154: gnome-control-center removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard

[Anton Zinoviev]

On Fri, Feb 19, 2016 at 05:10:03PM +0100, Andreas Henriksson wrote:
> 
> > By the way, I was very surprised to find that gnome-control-center modifies 
> > a 
> > configuration file belonging to other package.  This is not something 
> > Debian 
> > policy permits.
> 
> If you want to get into policy discussion land you should know that
> /etc/default/keyboard is *not* a conffile (as far as I can see).

Now I can see how what I wrote can be confusing in Debian context.  When I 
wrote 
'conffile' I simply used it as an abbreviation for 'configuration file'.

The following is the relevant part in the Policy:

] If it is desirable for two or more related packages to share a configuration 
file 
] and for all of the related packages to be able to modify that configuration 
file, 
] then the following should be done:
]
] One of the related packages (the "owning" package) will manage the 
configuration 
] file with maintainer scripts as described in the previous section.
]
] The owning package should also provide a program that the other packages may 
use 
] to modify the configuration file.

In our case the "owning" package is keyboard configuration because this is the 
package which creates /etc/default/keyboard and maintains this file in the 
package scripts.  Since in the last sentence the Policy says 'should' and not 
'must' there is no need for keyboard-configuration to provice a modifying 
program.  (However, if the maintainters of systemd want to have such a program, 
I 
don't mind to provide one.)

My point, however, is this: any package modifying a foreign configuration file 
has to _at_least_ inform the maintainer of the owning package.  People are 
going 
to report bugs about broken configuration files against the respective owning 
package and if its maintainer is unaware that other packages are modifying it, 
then he will be unable to deal with such bugs properly.

> > Nevertheless, we do want the keyboard configuration to be user 
> > friendly, so I approve what gnome-control-center does, as long as it does 
> > it 
> > correctly. :)
> Suggestions on what correctly means here could be helpful.

In my opinion "correctly" (in this case) means this:
If some configuration program wants to modify the value of some variable in 
/etc/default/keyboard, it can do so.  The modifying program, however, has to 
leave everything else intact: assignments of unknown variables, commented lines 
and blank lines.

> Is XKBMODEL= always expected to be written out to the file even
> if the value is empty? (or is it a bug in the parsers not handling
> when its missing? I'd say normally you want parsers to be liberal
> in what they accept.)

XKBMODEL has no default value (at least in console-setup).  It should always be 
present and never as empty value.

XKBOPTIONS is not necessary in which case empty value is assumed.  Notice 
however 
that XKBOPTIONS should never be empty (or missing) when the keyboard is for a 
non-Latin language.  Since gnome-control-center doesn't provide means to 
configure XKBOPTIONS, I suppose it will be best if it leaves the current value 
unchanged (this is debatable).

> I also noticed that patched localed writes out the file without the
> values quoted is that considered required?
> eg. FOO="bar" becomes FOO=bar when localed writes the file.

Thank you for noticing this. It doesn't matter whether it will be FOO="bar" or 
FOO=bar, as long as bar doesn't contain spaces.  I don't know if there is any 
configuration program which puts spaces there, but both console-setup and X 
permit spaces, so the sysadmin may put spaces there.  I've just tested that 
gnome-control-center doesnt work properly when the values contain spaces (for 
example when XKBLAYOUT="us, fr").  Fortunately, it doesn't put spaces in bar. 
However it erases some parts of the string.  This is another bug.

Anton Zinoviev

Bug#814954: libgcrypt20: add libgcrypt-mingw-w64-dev for cross-building to Windows targets

[Andreas Metzler]

On 2016-02-17 Daniel Kahn Gillmor  wrote:
[...]
> The attached set of patches against branch1.6 (also in the
> debian-windows branch of
> https://anonscm.debian.org/git/users/dkg/libgcrypt.git) provides this
> for libgcrypt.
[...]

Hello,

this does not build for me on current sid:
/bin/bash ../libtool --mode=compile --tag=RC i686-w64-mingw32-windres 
-DHAVE_CONFIG_H -I. -I../../src -I.. -i "versioninfo.rc" -o "versioninfo.lo"
libtool: compile:  i686-w64-mingw32-windres -DHAVE_CONFIG_H -I. -I../../src 
-I.. -i versioninfo.rc  -o .libs/versioninfo.o
i686-w64-mingw32-windres: versioninfo.rc.in:21: syntax error
Makefile:1240: recipe for target 'versioninfo.lo' failed
make[2]: *** [versioninfo.lo] Error 1

cu Andreas

Bug#815176: staden: Gap4 contig editor does not show sequences

[Kerstin Hoef-Emden]

Package: staden
Version: 2.0.0+b10-1.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,


I loaded pregap-converted *.exp sequences into gap4 to do an assembly. The
assembly worked out, but I cannot open the contig editor for proofreading.
More correctly described: It actually opens, but only the upper window bar
is visible, neither sequences nor trace files are displayed. Since no
information on this problem shows up in the log files of gap4, I have got no
idea concerning the nature of the problem. Perhaps something connected to
the graphical surface?

Before upgrading to jessie, I had staden from the sourceforge site installed
and it worked, but under jessie I have got the problem with both, the debian
and with the sourceforge package.

Kerstin



-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages staden depends on:
ii  libc62.19-18+deb8u3
ii  libcurl3 7.38.0-4+deb8u3
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-3+deb8u1
ii  libgcc1  1:4.9.2-10
ii  liblzma5 5.1.1alpha+20120614-2+b3
ii  libpng12-0   1.2.50-2+deb8u2
ii  libstaden-read1  1.13.7-1
ii  libstdc++6   4.9.2-10
ii  libtcl8.68.6.2+dfsg-2
ii  libtk8.6 8.6.2-1
ii  libx11-6 2:1.6.2-3
ii  libxext6 2:1.3.3-1
ii  libxft2  2.3.2-1
ii  libxss1  1:1.2.2-1
ii  staden-common2.0.0+b10-1.1
ii  staden-io-lib-utils  1.13.7-1
ii  tklib0.6-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

staden recommends no packages.

Versions of packages staden suggests:
pn  staden-doc  

-- no debconf information

Bug#815178: kamailio: CVE-2016-2385: SEAS Module Heap overflow

[Salvatore Bonaccorso]

Source: kamailio
Version: 4.3.4-1.1
Severity: grave
Tags: security patch upstream

Hi,

the following vulnerability was published for kamailio.

CVE-2016-2385[0]:
SEAS Module Heap overflow

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-2385
[1] http://www.openwall.com/lists/oss-security/2016/02/15/4

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#815154: gnome-control-center removes XKBMODEL and XKBOPTIONS from /etc/default/keyboard

[Anton Zinoviev]

On Fri, Feb 19, 2016 at 08:52:25PM +0300, Anton Zinoviev wrote:
> 
> The following is the relevant part in the Policy:
> 
> ] If it is desirable for two or more related packages to share a 
> configuration file 
> ] and for all of the related packages to be able to modify that configuration 
> file, 
> ] then the following should be done:
> ]
> ] One of the related packages (the "owning" package) will manage the 
> configuration 
> ] file with maintainer scripts as described in the previous section.
> ]
> ] The owning package should also provide a program that the other packages 
> may use 
> ] to modify the configuration file.
> 
> In our case the "owning" package is keyboard configuration because this is 
> the 
> package which creates /etc/default/keyboard and maintains this file in the 
> package scripts.

Please, ignore this.  Obviously, it talks about the package configuration 
scripts 
and gnome-control-center is not such a script.

Anton Zinoviev

Bug#815175: sbuild-update fails to unmount schroots on failure

[Ryan Kavanagh]

Package: sbuild
Version: 0.68.0-1
Severity: normal

The sbuild-update(1) commant fails to unmount schroots after
encountering errors. I expected it to gracefully clean up after itself,
unless otherwise specified, upon encountering an error. I've attached a
copy of my schroot.conf.

Here's a transcript showing the issue:

rak@zeta:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=8151612k,nr_inodes=2037903,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1632360k,mode=755)
/dev/sda1 on / type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
(rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup 
(rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/freezer type cgroup 
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/cpuset type cgroup 
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/devices type cgroup 
(rw,nosuid,nodev,noexec,relatime,devices)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
(rw,relatime,fd=28,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,noatime)
/dev/mapper/sdc5_crypt on /home type btrfs 
(rw,noatime,ssd,space_cache,subvolid=5,subvol=/)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=1632360k,mode=700,uid=1000,gid=1000)
/dev/mapper/wd on /media/wd type ext4 
(rw,nosuid,nodev,noatime,data=ordered,user=rak)
/dev/mapper/wd on /home/ryan/Pictures type ext4 
(rw,nosuid,nodev,noatime,data=ordered)
rak@zeta:~$ schroot -l
chroot:default
chroot:default-source
chroot:jessie
chroot:jessie-amd64
chroot:jessie-amd64-source
chroot:jessie-snap
chroot:jessie-source
chroot:sid-snap
chroot:stable
chroot:stable-amd64
chroot:stable-amd64-source
chroot:stable-source
chroot:unstable
chroot:unstable-amd64
chroot:unstable-amd64-source
chroot:unstable-source
source:default
source:jessie
source:jessie-amd64
source:jessie-snap
source:sid-snap
source:stable
source:stable-amd64
source:unstable
source:unstable-amd64
rak@zeta:~$ sbuild-update -udr source:jessie-amd64
E: 15binfmt: update-binfmts: unable to open 
/var/run/schroot/mount/jessie-snap-a6a720c2-d20d-4251-b3a5-1e043da0e1e2/bin/sh: 
No such file or directory
E: 20copyfiles: cp: cannot create regular file 
'/var/run/schroot/mount/jessie-snap-a6a720c2-d20d-4251-b3a5-1e043da0e1e2/etc/resolv.conf':
 No such file or directory
E: jessie-snap-a6a720c2-d20d-4251-b3a5-1e043da0e1e2: Chroot setup failed: 
stage=setup-start
Chroot setup failed
Error setting up source:jessie-amd64 chroot
Chroot setup failed at /usr/bin/sbuild-update line 170.
rak@zeta:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=8151612k,nr_inodes=2037903,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1632360k,mode=755)
/dev/sda1 on / type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/perf_event type cgroup 
(rw,nosuid,nodev,noexec,relatime,perf_event)