Bug#816880: RFS: ctmg/1.1-1 [ITP]

[Iván Ruvalcaba]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: ctmg
  Version : 1.1-1
  Upstream Author : Jason A. Donenfeld 
* URL : https://git.zx2c4.com/ctmg/
* License : ISC
  Section : utils

It builds those binary packages:

  ctmg  - Simple wrapper around cryptsetup for encrypted containers

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

  http://mentors.debian.net/package/ctmg

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

  dget -x http://mentors.debian.net/debian/pool/main/c/ctmg/ctmg_1.1-1.dsc

More information about hello can be obtained from 
https://git.zx2c4.com/ctmg/about/. ITP bug report: http://bugs.debian.org/816864


Regards,
  Iván Ruvalcaba

Bug#816879: transition: libtommath

[Dominique Dumont]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello

libtommath 1.0 has been released upstream. The new library went
from so version 0 to 1. Some macros like MIN and MAX were removed
from the public header files. This may break compilation.

libtommath 1 was uploaded in experimental and builds fine on all
supported arch:
https://buildd.debian.org/status/package.php?p=libtommath=experimental=yes

Affected reversed dependencies are:

* convlit, libtomcrypt:
  rebuild ok, needs binNMU

* moarvm, rakudo:
  I maintain theses packages and a new version is ready

* firebird3:
  only in experimental. I've warned the maintainer of
  the incoming change

All the best

Ben file:

title = "libtommath";
is_affected = .depends ~ "libtommath0" | .depends ~ "libtommath1";
is_good = .depends ~ "libtommath1";
is_bad = .depends ~ "libtommath0";


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

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 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)

Bug#816878: ITP: reel -- Celluloid::IO-powered HTTP server for Ruby

[Hleb Valoshka]

Package: wnpp
Severity: wishlist
Owner: Hleb Valoshka <375...@gmail.com>

* Package name: reel
  Version : 0.6.0
  Upstream Author : Tony Arcieri 
* URL : https://github.com/celluloid/reel
* License : Expat
  Programming Lang: Ruby
  Description : Celluloid::IO-powered HTTP server for Ruby

Web Server used by Berkshelf API Server.

Bug#816862: lintian: API documentation in manpage format

[Niels Thykier]

Jakub Wilk:
> Package: lintian
> Version: 2.5.41
> Severity: wishlist
> 
> I'd like to have Lintian API documentation in manpage format (in
> addition to, or instead of the HTML documentation).
> 

Seems reasonable.

 * Should just be a question of some "pod2man" + installing them
 * Patches welcome :)

~Niels





signature.asc
Description: OpenPGP digital signature

Bug#813598: FTBFS[kfreebsd]: tests/mini-loss-time race

[Andreas Metzler]

On 2016-03-05 Nikos Mavrogiannopoulos  wrote:
> On Sat, 2016-03-05 at 17:30 +0100, Andreas Metzler wrote:
[...]
>> Well with 3.4.10 the timeout does not seem to make any difference. 
>> Any of

>> gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); [Steven's 
>> patch]
>> gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000); [3.4.10]
>> gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000);
 
>>  [e6dcb14dbbd3e9e40a1f193a7bf6657e82b88cb9]
>> *always* fails on kfreebsd-amd64.

> Then the issue may have been different that what was initially thought.
> It would be nice to have some debugging output of the failed test
> (e.g., run with -v). Is that a 32-bit system? I'm wondering whether it
> relates to the undefined behavior fixes.

Hello,

this was on kfreebsd-amd64 but it also fails on kfreebsd-i386. Steven
has posted the -v output. (Which is lucky since the respective Debian
porter machine has become unreachable overnight.)

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

Bug#815980: tracker.debian.org: All packages have uscan issues

[Osamu Aoki]

Hi,

On Sat, Mar 05, 2016 at 07:15:46AM +0100, Lucas Nussbaum wrote:
...
> Looking at the errors, uscan doesn't seem to use the  tag, but instead
> output its errors in the  tag. (but that was already the case).

Correct.

When uscan faces "die" situation, it calls "uscan_die" and create
 tag data.  When uscan faces "warn" situation, it calls
"uscan_warn" and create  data.  Most watch file parsing errors
are "warn" situation since uscan may be looping ober multiple watch file
which is better to be continued.

After my recent code review, I found a few unwrapped "die" and "warn" in
the code.  They are fixed now so all  and  are
properly generated for all cases with the next upload.

Regards,

Osamu

Bug#816877: xombrero segfaults on a specific page

[Francesco Ariis]

Package: xombrero
Version: 2:1.6.3-1
Severity: normal

Dear Maintainer,

when trying to access http://www.braincells.com/debian/index.cgi/search/item=299
I get:

> f@x60s:~$ xombrero http://www.braincells.com/debian/index.cgi/search/item=299
> xombrero: config_parse: cannot open /usr/share/xombrero/user-agent-headers: 
> No such file or directory
> xombrero: config_parse: cannot open /usr/share/xombrero/http-accept-headers: 
> No such file or directory
> 
> (xombrero:2642): Gtk-WARNING **: Theme parsing error: xombrero.css:47:1: 
> Expected semicolon
> 
> (xombrero:2642): Gtk-WARNING **: Theme parsing error: xombrero.css:110:1: 
> Expected semicolon
> Segmentation fault

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

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

Versions of packages xombrero depends on:
ii  libbsd0 0.7.0-2
ii  libc6   2.19-18+deb8u3
ii  libgdk-pixbuf2.0-0  2.31.1-2+deb8u4
ii  libglib2.0-02.42.1-1
ii  libgnutls-deb0-28   3.3.8-6+deb8u3
ii  libgtk-3-0  3.14.5-1+deb8u1
ii  libjavascriptcoregtk-3.0-0  2.4.9-1~deb8u1
ii  libpango-1.0-0  1.36.8-3
ii  libsoup2.4-12.48.0-1
ii  libwebkitgtk-3.0-0  2.4.9-1~deb8u1

xombrero recommends no packages.

xombrero suggests no packages.

-- no debconf information

Bug#787950: (no subject)

[Giorgos Skafidas]

I found that keeping the shell, but changing the read line to 

cur_status="$(cat $MDBASE/sync_action)"

also lets checks run.

Bug#805318: debian-faq: Update informations about qmail and djbdns

[Joost van Baal-Ilić]

tags 805318 pending
thanks

Hi Stéphane,

Thanks for your patch.  It inspired me to get to work on this.


On Tue, Nov 17, 2015 at 12:28:57AM +0100, Stéphane Blondon wrote:
> Source: debian-faq
> Severity: wishlist
> 
> The FAQ
> (https://www.debian.org/doc/manuals/debian-faq/ch-software.en.html#s-qmail)
> talks about several software in 5.11 (qmail, djbdns, etc. However, their
> statuses have changed compared to 2008.
> 
>  - Currently, qmail is available in wheezy (oldstable), jessie (stable),
> stretch (testing) and sid (unstable).
> https://packages.debian.org/search?keywords=qmail=names=all=all
> 
> I suggest to update this data.
> 
> 
>  - The paragraph talks about ezmlm-idx. The case is more complicated: it
> exists only in experimental but some replacements exist (mlmmj or
> Enemies of Carlotta). I suggest to not change the current information.
> 
>  - Currently, djbdns is only in sid so I suggest to update the current
> information.
> 
> 
> There is a patch attached to this bug report. It's based on the webpage.

> --- "The Debian GNU_Linux FAQ - Software available in the Debian 
> system.orig.html"2015-11-17 00:01:37.0 +0100
> +++ "The Debian GNU_Linux FAQ - Software available in the Debian system.html" 
> 2015-11-17 00:17:31.0 +0100
> @@ -60,7 +60,7 @@
>   href="https://www.debian.org/doc/manuals/debian-faq/ch-software.en.html#s-isitdebian;
>  rel="section" title="5.8 How can I check that I am using a Debian system, 
> and what version is it?">
>   href="https://www.debian.org/doc/manuals/debian-faq/ch-software.en.html#s-nonenglish;
>  rel="section" title="5.9 How does Debian support non-English languages?">
>   href="https://www.debian.org/doc/manuals/debian-faq/ch-software.en.html#s-pine;
>  rel="section" title="5.10 Where is pine?">
> - href="https://www.debian.org/doc/manuals/debian-faq/ch-software.en.html#s-qmail;
>  rel="section" title="5.11 Where is qmail/ezmlm/djbdns?">
> + href="https://www.debian.org/doc/manuals/debian-faq/ch-software.en.html#s-qmail;
>  rel="section" title="5.11 Where is ezmlm/djbdns?">
>   href="https://www.debian.org/doc/manuals/debian-faq/ch-software.en.html#s-flash;
>  rel="section" title="5.12 Where is a player for Flash (SWF)?">
>   href="https://www.debian.org/doc/manuals/debian-faq/ch-software.en.html#s-googleearth;
>  rel="section" title="5.13 Where is Google Earth?">
>   href="https://www.debian.org/doc/manuals/debian-faq/ch-software.en.html#s-voip;
>  rel="section" title="5.14 Where is VoIP software?">
> @@ -536,7 +536,7 @@
>  
>  
>  
> -5.11 Where is qmail/ezmlm/djbdns?
> +5.11 Where is ezmlm/djbdns?
>  
>  
>  Dan J.  Bernstein used to distribute  href="http://cr.yp.to/software.html;>all software he has written
> @@ -548,15 +548,18 @@
>  
>  
>  
> -As of 2008-09, daemontools, djbdns and
> -ucspi-tcp are shipped with Debian lenny (in main).  As of this
> -writing (2008-09), qmail nor ezmlm is shipped with
> -Debian main; see http://bugs.debian.org/457318;>Bug #457318 
> (ITP
> -qmail) and http://bugs.debian.org/469193;>Bug 
> #469193
> +As of this
> +writing (2015-10), ezmlm is not shipped with
> +Debian main; see 
> +http://bugs.debian.org/469193;>Bug #469193
>  (ITP ezmlm-idx) for the current status.
>  
>  
>  
> +As of 2015-10, djbdns is currently in sid (unstable) only.
> +
> +
> +
>  As of 2008-09, publicfile was still not free software.
>  

I've made it into this text:



Where is ezmlm/djbdns/qmail?

Dan J. Bernstein used to distribute http://cr.yp.to/software.html;
name="all software he has written"> with a restrictive license which does not
allow modified binaries to be distributed.  In november 2007 however, Bernstein
said "[...] i have decided to put all of my future and [...] past software into
the public domain".  See http://cr.yp.to/distributors.html; name="FAQ
from distributors"> for his distribution terms.

As of this writing (2016-03), https://bugs.debian.org/516394;> and https://bugs.debian.org/796118;> for details and see publicfile software is still not free 
software, a Other software of Dan J. Bernstein (

Bug#816876: systemd: bootsched fails after systemd is installed resumes working after systemd is removed

[jda2000]

Source: systemd
Severity: normal

Dear Maintainer,

In the course of an update from Debian 7 to Debian 8 on a color iMac sytemd 
replaced sysv style init.
Subsequently, bootsched from powerpc-utils stopped working.  It would run and 
return 0 status but
the system would not power-on at the appointed time.

Following the instructions found here:
  https://ispire.me/downgrade-from-debian-sid-to-stable-from-jessie-to-wheezy/
sysvinit was re-installed and systemd removed:

apt-get install sysvinit-core sysvinit sysvinit-utils
(reboot)
apt-get remove --purge --auto-remove systemd

During this process a message flashed by saying that a supernode(?) had a 
future date
probably due to an invalid hardware clock setting and the notation "FIXED"

On a hunch, I skipped the rest of the roll-back and retested /sbin/bootshed
That test and a few subsequent all worked. 

and earlier attempt to fix the problem with:

# hwclock --set --date "$(date)"

had not worked.

I'm staying on Debian 8 since /sbin/bootsched is working.

I submit this report to document the work-around in case there are other color 
iMacs out there still.

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

Kernel: Linux 3.16.0-4-powerpc
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)

Bug#770926: debian-faq: Missing word(s) in faq section 1.5

[Joost van Baal-Ilić]

tags 770926 pending
thanks

Hi Simon,

On Tue, Nov 25, 2014 at 10:23:53AM +0100, Simon Kainz wrote:
> Tags: patch
> 
> please see the attached patch.

> Index: basic_defs.sgml
> ===
> --- basic_defs.sgml   (Revision 10498)
> +++ basic_defs.sgml   (Arbeitskopie)
> @@ -141,7 +141,7 @@
> very strict about shipping truly free software.  The guidelines used to
> determine if a work is "free" are provided in  id="http://www.debian.org/social_contract#guidelines; name="The Debian 
> Free
> -   Software">.
> +   Software Guidelines (DFSG)">.
>  
>  The entire system, or any individual component of it, can be

Thanks, commited to SVN in revision 11070.

Bye,

Joost

Bug#785772: #785772 golang-gocheck: New upstream version available

[Dmitry Smirnov]

"golang-gocheck" should be removed from Debian due to conflict with "golang-
check.v1-dev" responsible for the same name space "gopkg.in/check.v1".

Looks like golang-gocheck is a much older version of "golang-check.v1".

-- 
Best wishes,
 Dmitry Smirnov.

---

The persistence of erroneous beliefs exacerbates the widespread
anachronistic failure to recognize the urgent problems that face
humanity on this planet.
-- Murray Gell-Mann, "Quark and the Jaguar"


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

Bug#816875: Remmina does not transfer Shift+Tab over VNC

[Dark Penguin]

Package: remmina
Version: 1.1.1-2

In a VNC connection, Shift+Tab combination just does not get across to 
the remote desktop. It does not have any result at all, with or without 
"Grab Keyboard" enabled.


Shift+Tab is one of the very basic shortcuts for people who mostly use 
keyboard and not mouse: open some application on the remote screen, 
enter the login, Tab, enter the password... oh, I made a typo in the 
login! Shift+Tab... Nothing happens! You have to reach for the mouse to 
click the login field again...


Shift+Tab does work correctly over RDP, though.


--
darkpenguin

Bug#815734: regression: ESS cannot be compiled

[Norbert Preining]

Dear all

> BINGO -- once I add that things pass with the new texinfo.tex

Good. 

I have uploaded texinfo -5 just now, should be in the repos in
no time.

After this, please remove the old texinfo.tex copies - we had to
fight with outdated texinfo.tex for too often around the 4.8
times, I try to make sure that this doesn't happen again.

For -6 I have added a recommends on texlive-fonts-recommended, but
this is for users and not targetting package builds. So please
add the build-dep if necessary.

Thanks everyone

Norbert


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

Bug#816874: Remina tray icon treats everything like a double-click

[Dark Penguin]

Package: remmina
Version: 1.1.1-2

I have Remmina autostart when I log in, so the Remmina icon sits in the 
tray. Whenever I want to connect to some host, I click the tray icon and 
the I choose an item from the list of saved hosts.


Now, I only have very few hosts, so those two clicks happen in less than 
a second. And for some reason, Remmina treats it like a double-click and 
opens the main program window, even though the first click is on the 
icon, and the second click is on a menu item. And I have to close the 
main window every time, or remember to make a long pause after clicking 
the tray icon and before choosing the host to connect to.


Also, instead of two separate clicks, I usually do it the Linux way: 
click on the tray icon, hold the button down, move it to the menu item I 
want, and release the button. I find this really convenient. But even in 
this case Remmina treats it like a double-click, even though it was 
actually only one click and release!!



--
darkpenguin

Bug#812213: RFP: golang-github-satori-go.uuid -- UUID package for Go

[Peter Colberg]

retitle 812213 ITP: golang-github-satori-go.uuid -- UUID package for Go
owner 812213 ! 
thanks

Hi Daniel,

On Thu, Jan 21, 2016 at 05:21:21PM +0100, Daniel Stender wrote:
> * Package name: golang-github-satori-go.uuid
>   Version : 0.0+git20151029.d41af8b
>   Upstream Author : Maxim Bublis 
> * URL : https://github.com/satori/go.uuid
> * License : Expat
>   Programming Lang: Go
>   Description : UUID package for Go

I intend to upload this package, which is a dependency of acmetool [1].

[1] 
https://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20160229/003379.html

Regards,
Peter

Bug#816873: opensmtpd: debconf setting for root_address is ignored

[Jerad Simpson]

Package: opensmtpd
Version: 5.7.3p2-1
Severity: normal

Dear Maintainer,

As you can see, the debconf information at the bottom of the report lists myuser
to receive emails sent to the root user.  This does not appear to be happening,
and there are no extra lines in /etc/aliases as I would expect.  It seems
confusing to have the debconf option, but then have it do nothing.

Or maybe some other configuration I have is just not right.  This mailserver is
really only meant to send mail to my local users, so I have not entered a
typical FQDN as the mailname.  For example, I have only 'censored' instead of
something like 'censored.localdomain'.

Thanks,

Jerad

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

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

Versions of packages opensmtpd depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.58
ii  libasr01.0.2-1
ii  libc6  2.21-9
ii  libdb5.3   5.3.28-11
ii  libevent-2.0-5 2.0.21-stable-2+b1
ii  libpam0g   1.1.8-3.2
ii  libssl1.0.21.0.2g-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages opensmtpd recommends:
ii  opensmtpd-extras  5.7.1-2

opensmtpd suggests no packages.

-- debconf information:
* opensmtpd/mailname: censored
* opensmtpd/root_address: myuser

Bug#804203: ITP: golang-github-fatih-color -- Color package for Go (golang)

[Peter Colberg]

Hi Andrew,

On Thu, Nov 05, 2015 at 10:46:34PM -0500, Andrew Starr-Bochicchio wrote:
> * Package name: golang-github-fatih-color
>   Version : 0.0~git20151026.10.8640971-1
>   Upstream Author : Fatih Arslan
> * URL : https://github.com/fatih/color
> * License : Expat
>   Programming Lang: Go
>   Description : Color package for Go (golang)

Do you still intend to upload this package to Debian?

I intend to package acmetool for Debian [1], which depends on
github.com/cheggaaa/pb, which depends on github.com/fatih/color.

[1] 
https://lists.alioth.debian.org/pipermail/pkg-go-maintainers/Week-of-Mon-20160229/003379.html

I am not a Debian Developer, so I would upload the package via a
sponsorship request, in case you are no longer interested in it.

Regards,
Peter

Bug#816872: wmbattery: memory leak in wmbattery

[Dave Johnson]

Package: wmbattery
Version: 2.45-2
Severity: important

Dear Maintainer,

wmbattery appears to have a memory leak.  When invoked with "wmbattery -w 2" it 
is leaking approx 350KB/minute on my system.  Eventually it runs out of memory 
and is killed by kernel.


$ while sleep 300; do ps u $(pidof wmbattery); done
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
davijoh3 29894  0.2  0.0  18524  6792 ?Sl   21:24   0:00 wmbattery -w 2
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
davijoh3 29894  0.2  0.1  20068  7976 ?Sl   21:24   0:01 wmbattery -w 2
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
davijoh3 29894  0.2  0.1  21604  9404 ?Sl   21:24   0:01 wmbattery -w 2
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
davijoh3 29894  0.2  0.1  23160 10588 ?Sl   21:24   0:02 wmbattery -w 2
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
davijoh3 29894  0.2  0.1  24696 12208 ?Sl   21:24   0:03 wmbattery -w 2
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
davijoh3 29894  0.2  0.1  26164 14032 ?Sl   21:24   0:03 wmbattery -w 2
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
davijoh3 29894  0.2  0.1  27700 15464 ?Sl   21:24   0:04 wmbattery -w 2
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
davijoh3 29894  0.2  0.2  29644 17240 ?Sl   21:24   0:05 wmbattery -w 2
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
davijoh3 29894  0.2  0.2  31180 18964 ?Sl   21:24   0:05 wmbattery -w 2



-- System Information:
Debian Release: 8.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (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 wmbattery depends on:
ii  libapm1  3.2.2-15
ii  libc62.19-18+deb8u3
ii  libglib2.0-0 2.42.1-1
ii  libupower-glib3  0.99.1-3.2
ii  libx11-6 2:1.6.2-3
ii  libxext6 2:1.3.3-1
ii  libxpm4  1:3.5.11-1+b1
ii  upower   0.99.1-3.2

wmbattery recommends no packages.

Versions of packages wmbattery suggests:
ii  wmaker  0.95.5-2+b2

-- no debconf information

Bug#798136: wmbattery does not update display after launching

[David Johnson]

I also saw this issue after upgrading to jessie.

launching wmbattery with no args and it would never update after
launch.

workaround is to launch wmbattery with a -w argument, i.e.
"wmbattery -w 2".  it updates correctly when run with a -w specified.

Bug#816645: devscripts testsuite failure on raspbian and presumablly other deratives that are not special-cased.

[Osamu Aoki]

Hi,

On Fri, Mar 04, 2016 at 12:50:14PM +, Peter Green wrote:
> On 04/03/16 12:12, Osamu Aoki wrote:
> >Hi,
> >
> >I just pushed changes to address your bug report.  Please check it and
> >report if it works on Rasbian.
> Log attatched. It fixed the tests that were failing previously but gave a
> new slew of test failures. e.g.
...
> ./test_uscan_mangle
...
> uscan: Newest version of foo on remote site is 0.0, specified download 
> version is 0.0
> ASSERT:uscan: Version should be 0.0-1 but 0.0-0raspbian1 
> expected:<0.0-0raspbian1> but was:<0.0-1>

I did not update Ubuntu specific rule in test_uscan_mangle.  So this is
can be fixed by new update.

I checked other test rules and I do not see Ubuntu any more in uscan
related @arts.  Please check new version.

Regards,

Osamu 

Bug#787950: How about accepting this patch?

[Dark Penguin]

I think this situation is a disaster. Not having periodical checks on 
your arrays, or rather, having them fail quietly without even notifying 
the admin, can lead to grave consequences. (People tend to underestimate 
how critical it is to have periodical consistency checks, especially in 
RAID5's).


Finding this bug report is not exactly easy. I've spent a whole day 
trying to find out why do I not have consistency checks, and I could not 
advance any further than "why does checkarray not do anything". Not to 
mention it was a very lucky coincidence that I even noticed not having 
consistency checks.


So, how about accepting this patch and having checkarray use bash by 
default? I see no downsides to this; bash is an "essential" package, so 
most people do have bash installed; even if they don't, they will still 
not have critical maintenance fail silently, but get an error message. 
Even if this is fixed in more recent kernels, 4.1-LTS is one of the most 
popular ones, if not THE most popular, and it still has this problem.



But still... "One byte at a time"? Was this the reason why Linus wrote 
one of his most famous quotes about this being incredibly stupid rather 
than simply "inefficient"? %) Is there at least a bug filed against dash 
about, um, "optimizing the inefficient behaviour potentially leading to 
major problems on most widely used LTS kernels"?



--
darkpenguin

Bug#815734: regression: ESS cannot be compiled

[Dirk Eddelbuettel]

On 6 March 2016 at 11:15, Norbert Preining wrote:
| Hi all,
| 
| On Sat, 05 Mar 2016, Dirk Eddelbuettel wrote:
| > kpathsea: Running mktexmf ecrm1440
| 
| apt-get install texlive-fonts-recommended

BINGO -- once I add that things pass with the new texinfo.tex
 
| Since 6.0 or so in some circumstances this is necessary, due to the
| usage of T1 encoded fonts. It depends on the texi input file,
| so it is not a strong dependency.
| 
| I might add a recommends to texinfo for that, though.

FWIW for r-base itself I appear to have added the depends on
texlive-fonts-recommended in April of 2008 or almost eight years ago.  When
texlive was probably a different beast.

In any event, MANY thanks to Norbert and texinfo upstream. I couldn't have
sorted this out myself. Or at least not quickly ...

Dirk

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

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#639006: Bug #639006 - libreoffice-calc: Basic runtime error '423' for Maxchange

[Stéphane Aulery]

Hello naths,

Tue, 23 Aug 2011 21:18:09 +0530, naths wrote:
> Package: libreoffice-calc
> Version: 1:3.3.4-1
> Severity: normal
>
> When try to open a file containing macro libreofficeCalc open a > 
LibreOffice

> Basic window of VBAProject with the macro
> containing line " .MaxChange = 0.001 ".
> This shows an error of " BASIC runtime error ' 423 ' MaxChange " .
> Still the file/sheets are working fine.

The following bug is similar. This is probably a non or poorly 
implemented feature:


Can you reproduce this bug with a newer version of LO please?

Do you have a document to test?

Regards,

--
Stéphane Aulery

Bug#815734: regression: ESS cannot be compiled

[Norbert Preining]

Hi all,

On Sat, 05 Mar 2016, Dirk Eddelbuettel wrote:
> kpathsea: Running mktexmf ecrm1440

apt-get install texlive-fonts-recommended

Since 6.0 or so in some circumstances this is necessary, due to the
usage of T1 encoded fonts. It depends on the texi input file,
so it is not a strong dependency.

I might add a recommends to texinfo for that, though.

Norbert


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

Bug#816871: Segfault in battery.so

[Wakko Warner]

Package: procmeter3
Version: 3.6-1
Severity: important

Procmeter segfaults every time.  Strace shows it trying to open
/sys/class/power_supply which doesn't exist on my system.  Removing
battery.so causes procmeter to work.  Procmeter 3.5d-1 works.

Here's the strace:
open("/usr/lib/ProcMeter3/modules/battery.so", O_RDONLY|O_CLOEXEC) = 5
read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\22\0\0\0\0\0\0"..., 
832) = 832
fstat(5, {st_mode=S_IFREG|0644, st_size=18280, ...}) = 0
mmap(NULL, 2113640, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 
0x7f1390b55000
mprotect(0x7f1390b58000, 2097152, PROT_NONE) = 0
mmap(0x7f1390d58000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x3000) = 0x7f1390d58000
close(5)= 0
mprotect(0x7f1390d58000, 4096, PROT_READ) = 0
openat(AT_FDCWD, "/sys/class/power_supply", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or 
directory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
+++ killed by SIGSEGV +++
zsh: segmentation fault  strace procmeter3

GDB:
(gdb) run
Starting program: /usr/bin/procmeter3 

Program received signal SIGSEGV, Segmentation fault.
0x76874b40 in dirfd () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x76874b40 in dirfd () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x745377b4 in Initialise ()
   from /usr/lib/ProcMeter3/modules/battery.so
#2  0xf67f in LoadModule ()
#3  0xfc00 in LoadAllModules ()
#4  0x8bc8 in main ()
(gdb) 


Please note the following information was when 3.5d-1 was installed.
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.4 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages procmeter3 depends on:
ii  libatk1.0-0 2.18.0-1
ii  libc6   2.21-9
ii  libcairo2   1.14.6-1
ii  libfontconfig1  2.11.0-6.3
ii  libfreetype62.6.1-0.1
ii  libgdk-pixbuf2.0-0  2.32.3-1.2
ii  libglib2.0-02.46.2-3
ii  libgtk2.0-0 2.24.29-1
ii  libice6 2:1.0.9-1+b1
ii  libpango1.0-0   1.38.1-1
ii  libsensors4 1:3.4.0-2
ii  libsm6  2:1.2.2-1+b1
ii  libx11-62:1.6.3-1
ii  libxaw7 2:1.0.13-1
ii  libxext62:1.3.3-1
ii  libxmu6 2:1.1.2-2
ii  libxt6  1:1.1.5-1

procmeter3 recommends no packages.

procmeter3 suggests no packages.

-- no debconf information

Bug#815408: gscan2pdf: fails to record some settings when saving profile

[Gerry Butler]

Good afternoon Jeffrey

Thank you for your reply. And thank you too for your work on gscan2pdf.

I have only recently started using gscan2pdf, and I may have a
misunderstanding
about how profiles should be used. Following is the way I assumed I could
use them:

(1) Suppose I always want to scan business cards with 24bit colour,
200 dpi, flat-bed, 90mm x 60mm.

(2) I have just been scanning A4 pages with gray scale, 150 dpi, adf
central align,
210 x 297 mm

(3) I assume I can re-load a previously saved profile, called "business
card", which will
set everything to my desired values.

(4) But it can't, because when I saved "business card" profile, it did not
record mode or
resolution, as they were already 24bit colour and 200 dpi when I saved it.

(5) I can make it save mode and resolution in the "business card" profile
by making
sure I change every setting before saving the "business card" profile, but
that
seems more awkward than it should be.

I intend to use the scanner frequently, to scan and store routine
documents, so I seek
the quickest way to set the desired options for each document type.

I have submitted a related bug report about failure to set geometry to 90mm
x 60mm,
although these values are recorded in the profile. This may also be a
misunderstanding on my part.

My scanner is brother MFC-8890DW. It shows only a few settings: mode,
resolution,
source (flatbed, adf, etc), geometry.

Perhaps a partial solution might be to save only the common options, or
those
not requiring a restart. I am willing to devote some time to experimenting
with settings and options, if that will assist you.

Thank you

Gerry

Bug#714417: - libreoffice-base: can't open dBASE files in base

[Stéphane Aulery]

Hello Gary,

Le Fri, 28 Jun 2013 21:18:52 -0400, Gary Dale wrote :


Package: libreoffice-base
Version: 1:4.0.3-3
Severity: normal

* What led up to the situation?
I use an ancient Visual dBASE running in a Windows XP VM to manipulate run resul
ts from several
sources in order to create a single table that I use to drive a "form letter" ce
rtificate to
send to each of the participents. Now that I'm using Jessie, I find I can't get
to the
dBASE tables.

* What exactly did you do (or not do) that was effective (or ineffective)?
When I connect to existing databases that link to dBASE tables, I can see the ta
bles. However,
when I create a new table and link to a dBASE table, I can't see the tables. The
  connection
tests OK, but the tables aren't visible.


I have no dBASE database for testing by myself.

Are there has been progress with new versions?

In the bugtracker LO I could find about twenty bug related dBASE but 
nothing identical:


https://bugs.documentfoundation.org/buglist.cgi?quicksearch=dBASE_id=596063

Regards,

--
Stéphane Aulery

Bug#725221: Bug #725221 - libreoffice-calc: Japanese characters not correctly displayed

[Stéphane Aulery]

Hello Charles,

Thu, 03 Oct 2013 10:20:57 +0900, Charles Plessy wrote :


it has been a long time that I have a strange problem with LibreOffice
Calc: while it can display Japanese characters in the Input line, it
replaces them with a rectangular box in the cell itself.

I attached a test file and a screenshot to illustrate.  Using the same
file Gnumeric displays the character correctly.  It seems that, in the
cells only, LibreOffice is not able to use a replacement font to
display Japanese (and probably other CJK) characters.  For instance,
if in the attached file I change the font from Liberation Sans (or any
Latin-oriented font) to a Japanese-oriented font ( *-gothic, *-mincho,
etc), then the problem dissapears.

Would there be a simple solution to this problem ?


Generaly speaking, Asiatics languages support is broken in LO as for 
viewing and typing.


Search LO bugtracker with keywords japanese, CJK, Chinese, Hangul, ibus; 
everything is more or less broken.


I could not reproduce the bug with LO 5.1.0.3, but it seems random 
according to comments.


Regards,

--
Stéphane Aulery

Bug#816159: www.debian.org: new introduction for blends page

[Jonas Smedegaard]

Hi Ana,

Quoting Ana Custura (2016-03-05 20:23:36)
> Hi all,
>
> On 05/03/16 14:01, Jonas Smedegaard wrote:
>
>>> Of course, the information can be rephrased and moved if one wants 
>>> to put less emphasis on it (for more emphasis elsewhere).  For 
>>> instance, we could add something like "Debian Pure Blends are 
>>> developed, distributed and supported fully within Debian" at the end 
>>> of the current "first paragraph".
>>
>> That sounds like a nice improvement to me.
>
> With regards to the second paragraph that was removed, 'forks' is not 
> a concept most end users will be familiar with,

Then how about "not deriving away from Debian" instead - is that a 
common and familiar concept/expression in english?


> but the idea that blends are entirely contained within Debian is 
> important.

I think that changes focus:

Discussing whether the piece you hold in your hand and am interested in 
is contaminated or not is different from discussing how a lot of pieces 
(only a fraction of which you as a user have a direct interest in) are 
all uncontaminated.


> I suggest we add a second paragraph:
>
>
> "Debian Pure Blends are developed, distributed and supported fully
> within Debian. Therefore, if you obtain a complete
> Debian distribution, you have all available Debian Pure Blends
> available for installation."
> 
> How does this sound?

To me that sounds less relevant for me - as a potential user of a blend: 
It talks about how all blends are in Debian, rather than (as the 
original text) each individual blend - e.g. the one specific blend I am 
interested in.


 - Jonas

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

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


signature.asc
Description: signature

Bug#534325: yakuake: "Keep window open when losing focus" option does not stay set between sessions

[Diederik de Haas]

tags 534325 unreproducible
thanks

On Tue, 23 Jun 2009 11:32:58 -0400 "Jonathan E. Magen"  
wrote:
> When modifying the menu option to "Keep window open when it loses focus
> option", it works for one session. However, every time yakuake is restarted 
> (for example, another session), the option's state reverts to checked status
> regardless of state. It can be reset again and it will hold for the 
> duration of the session.

Is this issue still occurring? I was not able to reproduce it.

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

Bug#635437: yakuake: Tab labels don't respect konsole profile settings

[Diederik de Haas]

On Mon, 25 Jul 2011 20:39:32 +0200 starenka  wrote:
> I use custom tab title formats (local = %u@%D, remote = %u@%H). These work
> okay in konsole, but yakuake seems to ignore such settings altough all other
> settings from such profile are aplied flawlessly. Tried to purge yakuake and
> install again, but no avail.

Is this problem still present?
You probably need to apply the tip from Jekyll Wu though.

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

Bug#816870: hplip: contains non-free code

[Julian Andres Klode]

Package: src:hplip
Severity: serious
Tags: upstream
Control: forwarded -1 https://bugs.launchpad.net/hplip/+bug/1553628

In prnt/hpcups, the headers of ErnieFilter.cpp and .h say:

// This software is licensed solely for use with HP products. Redistribution
// and use with HP products in source and binary forms, with or without
// modification, are permitted provided that the following conditions are met:

As such, the code is non-free because I cannot safely redistribute it. Could 
that be changed to a normal 3-clause BSD license like the other files?

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

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

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#731366: Re : Bug #731366 - libreoffice: ibus and complex input methods do not work at all in 4.4.x

[Stéphane Aulery]

This bug is the subject of two similar reports involving ibus and KDE 
(4) for the entry of Asian languages:


https://bugs.documentfoundation.org/show_bug.cgi?id=91375

and

https://bugs.documentfoundation.org/show_bug.cgi?id=34016

--
Stéphane Aulery

Bug#753930: [yakuake] Program Crashes On Setting

[Diederik de Haas]

tags 753930 unreproducible moreinfo
thanks

On Sun, 06 Jul 2014 14:31:06 +0300 David Baron  wrote:
> Package: yakuake
> Version: 2.9.9-1
> Severity: normal
> 
> Any time trying to get to settings, program crashes.
> Width and height from dropdown can be set, not retained, nor is position.

Does this issue still occur? A new version of yakuake has recently been 
released, maybe it fixes your issue.

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

Bug#734652: Re : Bug #734652 libreoffice-calc: saving file as .sxc screws up content

[Stéphane Aulery]

Hello 0 1,

Wed, 08 Jan 2014 22:29:21 +0100, 0 1 wrote :


I am experiencing a very simple problem: it seems Libreoffice Calc can't
save properly as .sxc format.

Numbers are kept properly inside the spreadsheet, but a simple «sum»
operation is screwed up, as seen in this screenshot:
https://pix.isalo.org/?img=1387458494.png

Attached some .odx document (the original, no problem with it) and some
(saved as) .sdx one, which exhibits the problem.


This bug is fixed in version 5.1.0.3 at least.

Can you reproduce it with your current version please?

Regards,

--
Stéphane Aulery

Bug#816869: icedove: Could the caret/focus be located on the folders list at startup time?

[Jean-Philippe MENGUAL]

Package: icedove
Version: 38.6.0-1
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?

Just tried Icedove with an end-user. I use Orca, MATE.

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

Run Icedove: alt-f1, Internet -> Icedove.

   * What was the outcome of this action?

The caret/focus reaches some area I don't know. I need to press tab twice to
reach the folders list.

   * What outcome did you expect instead?

I'd like to have the caret on folders list at runtime.

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

Here's what think orca guys about it, technically:
https://mail.gnome.org/archives/orca-list/2016-February/msg00431.html

Thanks very much!

Best regards,


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

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

Versions of packages icedove depends on:
ii  debianutils   4.7
ii  fontconfig2.11.0-6.3
ii  libasound21.1.0-1
ii  libatk1.0-0   2.18.0-1
ii  libc6 2.21-9
ii  libcairo2 1.14.6-1
ii  libdbus-1-3   1.10.6-1
ii  libdbus-glib-1-2  0.106-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-4
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6.1-0.1
ii  libgcc1   1:5.3.1-8
ii  libgdk-pixbuf2.0-02.32.3-1.2
ii  libglib2.0-0  2.46.2-3
ii  libgtk2.0-0   2.24.29-1
ii  libhunspell-1.3-0 1.3.3-3+b2
ii  libnspr4  2:4.11-1
ii  libnss3   2:3.21-1.1
ii  libpango-1.0-01.38.1-1
ii  libpangocairo-1.0-0   1.38.1-1
ii  libpangoft2-1.0-0 1.38.1-1
ii  libpixman-1-0 0.33.6-1
ii  libsqlite3-0  3.10.2-1
ii  libstartup-notification0  0.12-4
ii  libstdc++65.3.1-8
ii  libvpx3   1.5.0-2
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  psmisc22.21-2.1+b1
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-en-us [hunspell-dictionary] 20070829-6
ii  hunspell-fr-classical [hunspell-dictionary]  1:5.5-1
ii  iceowl-extension 38.6.0-1

Versions of packages icedove suggests:
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.13.2+dfsg-5

-- no debconf information

Bug#812459: python3-stem: fails to upgrade from 'testing' - trying to overwrite /usr/bin/tor-prompt

[Dererk]

tags 812459 +confirmed +pending
thanks

On 03/05/2016 08:41 PM, Donncha O'Cearbhaill wrote:
> This package is marked for autoremoval on the 8th March and the bug has
> not received a response from the package maintainer.
>
> I've attached an NMU patch which I think will resolve this issue.
>
> Regards,
> Donncha
Hi Donncha!

Thanks for the heads-up on this! This may have slipped through across
the week's rush. Again thanks!

Patch does look nice!
On its way!


Cheers,

Dererk

-- 
BOFH excuse #109:
The electricity substation in the car park blew up.




signature.asc
Description: OpenPGP digital signature

Bug#810543: RFS: python-bond/1.4-1 [ITP]

[Mattia Rizzolo]

control: tag -1 moreinfo
control: owner -1 !

On Sat, Jan 09, 2016 at 06:29:41PM +0100, Yuri D'Elia wrote:
> I am looking for a sponsor for my package "python-bond"
> 
>  http://mentors.debian.net/package/python-bond
> 
>  This is my first package and upload to python-modules.

ok, as this is in DPMT, and there is a team policy enforcing the git
repository needs to be inline with what is uploaded, I just ignored
mentors and went ahead cloning the git repo.

before all: the name of the repository needs to be the same as the
source, so it should be renamed to python-bond (note that there is also
hooks/post-receive to update, the kgb call hardcode (for some reasons,
it shouldn't be necessary at all) the name in the --module option)

1) it fails to build.  python(3)-nose and python(3)-setuptools-git
   are not in build-dep
2) vcs-field-uses-insecure-uri
3) duplicate-long-description
4) duplicate-short-description
5) the aboves are lintian tags; except for the first (which has been
introduced after your RFS) you should have noticed the other two, and
I wouldn't have expected to see them at a RFS stage; please remember to
run lintian in a more verbose than normal mode before asking a RFS
6) debian/docs: with this file you install the README only in
python-bond, I think you may want to install it also in python3-bond;
you can accomplish this by either overriding dh_installdocs and
re-calling it, or by renaming d/docs to d/python-bond.docs, and copying
it to d/python3-bond.docs
7) please bump Standards-Version to 3.9.7

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#791463: Quick review

[Pali Rohár]

On Friday 04 March 2016 22:59:10 Andrew Shadura wrote:
> On 4 March 2016 at 22:57, Pali Rohár  wrote:
> >> >> > Well, I did test it and it worked, otherwise I wouldn't have
> >> >> > proposed it.
> >> > 
> >> > See attachment in which is build log...
> >> 
> >> What version of bmake are you using?
> > 
> > 20150606-1
> > 
> > Anyway, now I found where is probably problem. sub
> > check_auto_buildable test whether exists Makefile or makefile
> > file. But such file will not exists until autoconf is run.
> 
> My bad, there's indeed an error, probably I pushed something
> different from what I tested, it should've probably called
> configure, not check_auto_buildable. I'll have a look tomorrow and
> upload a fix.

First dpkg-buildpackage call works, but calling it secondary fails with:

dpkg-source: info: local changes detected, the modified files are:
 udfclient-0.8.1/Makefile

It is because "debian/rules clean" calls only "bmake clean" which does 
not delete autogenerated file Makefile. That is deleted by another 
target "bmake cleandir".

So version 20150606-2 still does not work for udfclient.

Now I think that I should stay with my implementation which is working 
instead experimenting with --buildsystem=bmake...

-- 
Pali Rohár
pali.ro...@gmail.com


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

Bug#781087: Bug #781087 - libreoffice-impress: impress animation "strechy" dosn't work with drawings

[Stéphane Aulery]

Hi Wolfgang,

Le 05/03/2016 23:51, Wolfgang Hainz a écrit :


yes, I'm still seeing this bug with 5.0.5.2.


Everything matches. I forward the information. Thank you. :))

Regards,

--
Stéphane Aulery

Bug#774716: [Bug 537522] app-arch/pax: directory traversal (CVE-2015-{1193,1194})

[Thorsten Glaser]

tags 774716 + pending upstream
thanks


bugzilla-dae...@gentoo.org dixit:

>https://bugs.gentoo.org/show_bug.cgi?id=537522

>could you resync the pax code w/the latest openbsd ?

For the record over here: resync in progress, but we’ll see
a security fix backport-only release first (which the regular
and LTS security teams are invited to apply to jessie and
wheezy as well, or rather use as source to backport patches
from) and a fully rebased release later (tricky due to merge
conflicts due to heavy both local and upstream changes).

My current WiP trees for those merges, undocumented and
subject to force pushs though, is at github:MirBSD/opax
for these interested (master is OpenBSD, the branches
mpax and mpax-erstmalnurderbackport are merge aids that
are the base of what will end up in MirBSD CVS, and the
-upstream pendants are branched off the OpenBSD base of
MirBSD’s pax with the same upstream patchlevel; remember
this is for the “merge” part only, the “test, fix, make
portable” part will be done in CVS again, but this helps
(also myself) understanding what individual commit did
what change (to untangle conflicts).

I apologise for the delay. I will also retake active
maintainership of pax. Also sorry Alexander for not
reacting more proactively.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Bug#816868: sysv-rc: error during upgrade due to systemd timeout

[Farmbuyer]

Package: sysv-rc
Version: 2.88dsf-59.3
Severity: normal


Got this today while upgrading:

Preparing to unpack .../sysv-rc_2.88dsf-59.3_all.deb ...
Unpacking sysv-rc (2.88dsf-59.3) over (2.88dsf-59.2) ...
Setting up sysvinit-utils (2.88dsf-59.3) ...
Setting up sysv-rc (2.88dsf-59.3) ...
Processing triggers for systemd (228-2) ...
Failed to execute operation: Connection timed out
dpkg: error processing package systemd (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 systemd
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
Setting up libquadmath0:i386 (5.3.1-10) ...
[lots more "Setting up" messages, none related to sysv]

I've no idea what, exactly, it's complaining about.

The sysv-rc package itself claims to be installed okay and of the correct
version when queried with "dpkg -s", although I haven't yet actually
tried rebooting.


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

Kernel: Linux 4.3.0-1-686-pae (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: sysvinit (via /sbin/init)

Versions of packages sysv-rc depends on:
ii  debconf [debconf-2.0]  1.5.58
ii  init-system-helpers1.29
ii  insserv1.14.0-5.3
ii  startpar   0.59-3
ii  sysvinit-utils 2.88dsf-59.3

Versions of packages sysv-rc recommends:
ii  lsb-base  9.20150917

Versions of packages sysv-rc suggests:
pn  bum  

-- debconf information:
  sysv-rc/unable-to-convert:
  sysv-rc/convert-legacy: true

Bug#812459: python3-stem: fails to upgrade from 'testing' - trying to overwrite /usr/bin/tor-prompt

[Donncha O'Cearbhaill]

This package is marked for autoremoval on the 8th March and the bug has
not received a response from the package maintainer.

I've attached an NMU patch which I think will resolve this issue.

Regards,
Donncha
diff -Nru python-stem-1.4.1b/debian/changelog 
python-stem-1.4.1b/debian/changelog
--- python-stem-1.4.1b/debian/changelog 2016-01-18 14:58:04.0 +0100
+++ python-stem-1.4.1b/debian/changelog 2016-03-06 00:16:13.0 +0100
@@ -1,3 +1,12 @@
+python-stem (1.4.1b-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules: Use update-alternatives to select between
+/usr/bin/tor-prompt for the Python 2 and Python 3 packages
+(Closes: #812459).
+
+ -- Donncha O'Cearbhaill   Sat, 05 Mar 2016 23:24:41 +0100
+
 python-stem (1.4.1b-2) unstable; urgency=medium
 
   * Rollback #767555 since it kinda loses functionality as it is.
diff -Nru python-stem-1.4.1b/debian/python3-stem.postinst 
python-stem-1.4.1b/debian/python3-stem.postinst
--- python-stem-1.4.1b/debian/python3-stem.postinst 1970-01-01 
01:00:00.0 +0100
+++ python-stem-1.4.1b/debian/python3-stem.postinst 2016-03-06 
00:05:52.0 +0100
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+set -e
+
+if [ "$1" = "configure" ] ; then
+update-alternatives --install /usr/bin/tor-prompt tor-prompt 
/usr/bin/python3-tor-prompt 200
+fi
+
+#DEBHELPER#
+
+exit 0
diff -Nru python-stem-1.4.1b/debian/python3-stem.prerm 
python-stem-1.4.1b/debian/python3-stem.prerm
--- python-stem-1.4.1b/debian/python3-stem.prerm1970-01-01 
01:00:00.0 +0100
+++ python-stem-1.4.1b/debian/python3-stem.prerm2016-03-06 
00:05:52.0 +0100
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+set -e
+
+if [ "$1" = "remove" ] ; then
+update-alternatives --remove tor-prompt /usr/bin/python3-tor-prompt
+fi
+
+#DEBHELPER#
+
+exit 0
diff -Nru python-stem-1.4.1b/debian/python-stem.postinst 
python-stem-1.4.1b/debian/python-stem.postinst
--- python-stem-1.4.1b/debian/python-stem.postinst  1970-01-01 
01:00:00.0 +0100
+++ python-stem-1.4.1b/debian/python-stem.postinst  2016-03-06 
00:05:52.0 +0100
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+set -e
+
+if [ "$1" = "configure" ] ; then
+update-alternatives --install /usr/bin/tor-prompt tor-prompt 
/usr/bin/python2-tor-prompt 300
+fi
+
+#DEBHELPER#
+
+exit 0
diff -Nru python-stem-1.4.1b/debian/python-stem.prerm 
python-stem-1.4.1b/debian/python-stem.prerm
--- python-stem-1.4.1b/debian/python-stem.prerm 1970-01-01 01:00:00.0 
+0100
+++ python-stem-1.4.1b/debian/python-stem.prerm 2016-03-06 00:05:52.0 
+0100
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+set -e
+
+if [ "$1" = "remove" ] ; then
+update-alternatives --remove tor-prompt /usr/bin/python2-tor-prompt
+fi
+
+#DEBHELPER#
+
+exit 0
diff -Nru python-stem-1.4.1b/debian/rules python-stem-1.4.1b/debian/rules
--- python-stem-1.4.1b/debian/rules 2016-01-18 15:40:17.0 +0100
+++ python-stem-1.4.1b/debian/rules 2016-03-06 00:17:12.0 +0100
@@ -24,11 +24,12 @@
$$py setup.py install --root debian/python3-stem \
--install-layout=deb; \
done; \
-   rm -rf debian/python-stem/usr/bin
-   
+   mv debian/python-stem/usr/bin/tor-prompt 
debian/python-stem/usr/bin/python2-tor-prompt
+   mv debian/python3-stem/usr/bin/tor-prompt 
debian/python3-stem/usr/bin/python3-tor-prompt
+
 override_dh_auto_clean:
dh_auto_clean -- --all
rm -rf build
 
 override_dh_installman:
-   dh_installman -ppython3-stem debian/tor-prompt.8
+   dh_installman -A debian/tor-prompt.8


signature.asc
Description: OpenPGP digital signature

Bug#816867: gdm3: When started at boot, mouse/keyboard input does not work

[Sam Morris]

Package: gdm3
Version: 3.18.2-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mouse clicks and keyboard keys don't work at gdm when I first boot up. I
have to ssh into my machine and restart gdm to get it to work.

I'm attaching the X server log, though nothing looks amiss to me.
Nothing strange is sent to syslog either:

$ journalctl -u gdm -b
-- Logs begin at Sun 2016-01-24 01:47:44 GMT, end at Sat 2016-03-05 
23:29:27 GMT. --
Mar 05 23:18:41 wintermute systemd[1]: Starting GNOME Display Manager...
Mar 05 23:18:42 wintermute systemd[1]: Started GNOME Display Manager.
Mar 05 23:18:42 wintermute gdm-launch-environment][1007]: 
pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm by 
(uid=0)
Mar 05 23:18:43 wintermute gdm3[836]: GdmDisplay: display lasted 
1.519444 seconds
Mar 05 23:18:43 wintermute gdm3[836]: Child process -1364 was already 
dead.
Mar 05 23:18:43 wintermute gdm3[836]: Child process 1007 was already 
dead.
Mar 05 23:18:43 wintermute gdm3[836]: Unable to kill session worker 
process
Mar 05 23:18:43 wintermute gdm-launch-environment][1451]: 
pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm by 
(uid=0)
Mar 05 23:21:04 wintermute systemd[1]: Stopping GNOME Display Manager...
Mar 05 23:21:05 wintermute systemd[1]: Stopped GNOME Display Manager.
Mar 05 23:21:05 wintermute systemd[1]: Starting GNOME Display Manager...
Mar 05 23:21:05 wintermute systemd[1]: Started GNOME Display Manager.
Mar 05 23:21:05 wintermute gdm-launch-environment][2079]: 
pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm by 
(uid=0)
Mar 05 23:21:05 wintermute gdm3[2061]: GdmDisplay: display lasted 
0.319011 seconds
Mar 05 23:21:05 wintermute gdm3[2061]: Child process -2084 was already 
dead.
Mar 05 23:21:05 wintermute gdm3[2061]: Child process 2079 was already 
dead.
Mar 05 23:21:05 wintermute gdm3[2061]: Unable to kill session worker 
process
Mar 05 23:21:05 wintermute gdm-launch-environment][2112]: 
pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm by 
(uid=0)
Mar 05 23:21:13 wintermute gdm-password][2186]: 
pam_unix(gdm-password:session): session opened for user sam by (uid=0)

You can see there that the log messages from gdm are identical the first
and second times that it starts.

I am unable to even use Ctrl+Alt+F1 to switch to another virtual console
to log in. The only key sequence that responds is Ctrl+Alt+Delete, which
systemd picks up on as if I were at a virtual console that is not
runnign X, and duly reboots the system.

The system itself is a VirtualBox virtual machine. I've had this problem
for months, so it's not caused by a recently updated package.

- -- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (550, 'stable-updates'), (550, 'stable'), (530, 'testing'), (520, 
'unstable'), (510, 'experimental'), (500, 'unstable-debug'), (500, 
'testing-updates')
Architecture: amd64 (x86_64)

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

Versions of packages gdm3 depends on:
ii  accountsservice  0.6.40-3
ii  adduser  3.113+nmu3
ii  dconf-cli0.22.0-1
ii  dconf-gsettings-backend  0.22.0-1
ii  debconf [debconf-2.0]1.5.58
ii  gir1.2-gdm-1.0   3.18.2-1
ii  gnome-session [x-session-manager]3.18.1.2-1
ii  gnome-session-bin3.18.1.2-1
ii  gnome-session-flashback [x-session-manager]  3.18.2-1
ii  gnome-settings-daemon3.18.2-1
ii  gnome-shell  3.18.3-3
ii  gnome-terminal [x-terminal-emulator] 3.18.2-1
ii  gsettings-desktop-schemas3.18.1-1
ii  i3-wm [x-window-manager] 4.11-1
ii  libaccountsservice0  0.6.40-3
ii  libaudit11:2.4-1+b1
ii  libc62.21-9
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libgdm1  3.18.2-1
ii  libglib2.0-0 2.46.2-3
ii  libglib2.0-bin   2.46.2-3
ii  libgtk-3-0   3.18.8-1
ii  libpam-modules   1.1.8-3.1+deb8u1
ii  libpam-runtime   1.1.8-3.1+deb8u1
ii  libpam-systemd   229-2
ii  libpam0g

Bug#814628: [radiotray] is failing to start

[Elías Alejandro]

Dear Marek,
Firstly thanks for your report.
I want to fix up this bug, and I wonder if you can help us what display the
follow step:
1.Enter to the python command line and write.

from radiotray import radiotray_runner

Please send all the display messages.
If you need help please don't hesitate and let me know.

Regards,

Elías Alejandro

On Sat, Feb 13, 2016 at 9:31 AM, Marek Straka  wrote:

> Package: radiotray
> Version: 0.7.3-5
> Severity: important
>
> --- Please enter the report below this line. ---
>
> #:~$ radiotray
>
> ** (radiotray:7789): WARNING **: Error retrieving accessibility bus
> address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus
> was not provided by any .service files
> /usr/lib/python2.7/dist-packages/radiotray/XmlDataProvider.py:23:
> PyGIWarning: Gtk was imported without specifying a version first. Use
> gi.require_version('Gtk', '3.0') before import to ensure that the right
> version gets loaded.
>   from gi.repository import Gtk
> Traceback (most recent call last):
>   File "/usr/bin/radiotray", line 12, in 
> os.chdir(workdir)
> OSError: [Errno 2] Directory or file does not exist: '/usr/bin/src'
>
> --- System information. ---
> Architecture: amd64
> Kernel: Linux 4.3.0-1-amd64
> Debian Release: stretch/sid
>
> Versions of packages radiotray depends on:
> ii  gir1.2-gtk-3.0 3.18.7-1
> ii  gir1.2-keybinder-3.0   0.3.1-1
> ii  gir1.2-notify-0.7  0.7.6-2
> ii  gstreamer1.0-plugins-bad   1.6.2-1
> ii  gstreamer1.0-plugins-base  1.6.3-1
> ii  gstreamer1.0-plugins-good  1.6.3-1
> ii  gstreamer1.0-plugins-ugly  1.6.3-1
> ii  python 2.7.11-1
> ii  python-dbus1.2.0-3
> ii  python-gi  3.18.2-2
> ii  python-glade2  2.24.0-4
> ii  python-gst-1.0 1.6.2-1
> ii  python-lxml3.5.0-1
> pn  python:any 
>

Bug#816855: gramps: unable to display places in geography view

[Sam Manzi]

Related upstream issue: 0009207: geography view Location could not convert
string to float
https://gramps-project.org/bugs/view.php?id=9207


On 6 March 2016 at 07:00, IOhannes m zmoelnig  wrote:

> Package: gramps
> Version: 4.2.2~dfsg-1
> Severity: normal
>
> Dear Maintainer,
>
> today i discovered that the "geography view" stopped working (i'm pretty
> sure it
> did work, but don't know the last version of gramps where this is true).
>
> The problem is, that I store the coordinates of my places in
> degree/minutes/seconds (e.g.  "51° 28′ 48″ N") and gramps fails to convert
> these
> coordinates into floating point (51.48).
> Btw, gramps does a syntax-check when I enter the coordinates, and verifies
> that
> the above coordinates are fine; but when I want to display the places, I
> get a
> traceback:
>
> > Traceback (most recent call last):
> >   File "/usr/lib/python3/dist-packages/gramps/gui/viewmanager.py", line
> 966, in __create_page
> > page_display = page.get_display()
> >   File "/usr/lib/python3/dist-packages/gramps/gui/views/pageview.py",
> line 389, in get_display
> > self.top = self.build_interface()
> >   File "/usr/lib/python3/dist-packages/gramps/gui/views/pageview.py",
> line 162, in build_interface
> > widget = self.build_widget()
> >   File
> "/usr/lib/python3/dist-packages/gramps/plugins/lib/maps/osmgps.py", line
> 115, in build_widget
> > self.change_map(None, config.get("geography.map_service"))
> >   File
> "/usr/lib/python3/dist-packages/gramps/plugins/lib/maps/osmgps.py", line
> 172, in change_map
> > self.goto_handle(handle=None)
> >   File
> "/usr/lib/python3/dist-packages/gramps/plugins/view/geoplaces.py", line
> 176, in goto_handle
> > self.build_tree()
> >   File
> "/usr/lib/python3/dist-packages/gramps/plugins/view/geoplaces.py", line
> 194, in build_tree
> > self._createmap(active)
> >   File
> "/usr/lib/python3/dist-packages/gramps/plugins/view/geoplaces.py", line
> 279, in _createmap
> > self.osm.set_center_and_zoom(float(place.get_latitude()),
> > ValueError: could not convert string to float: '51° 28′ 48″ N'
>
> Attached is a minimal database (consisting of a single place), that
> exhibits the problem.
> Basically, you only have to go to the "Geography" view and select "All
> known places".
> (sometimes i have to switch to another menu and then back after that).
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages gramps depends on:
> ii  gir1.2-gtk-3.03.18.8-1
> ii  librsvg2-22.40.13-3
> ii  python3-bsddb36.1.0-1+b2
> ii  python3-gi3.18.2-2
> ii  python3-gi-cairo  3.18.2-2
> pn  python3:any   
> ii  xdg-utils 1.1.1-1
>
> Versions of packages gramps recommends:
> ii  gir1.2-gexiv2-0.100.10.3-2
> ii  gir1.2-osmgpsmap-1.0  1.1.0-1
> ii  graphviz  2.38.0-12+b1
> ii  python3-icu   1.9.2-2+b2
>
> Versions of packages gramps suggests:
> ii  fonts-freefont-ttf20120503-4
> pn  gir1.2-goocanvas-2.0  
> ii  gir1.2-gtkspell3-3.0  3.0.7-2
> ii  python3-pil   3.1.1-1
> ii  rcs   5.9.4-3
>
> -- no debconf information
>

Bug#816853: [Freedombox-pkg-team] Bug#816853: pagekite: Fix autopkgtests and enable test-tunnel

[Petter Reinholdtsen]

Control: tags -1 + pending

[James Valleroy]
> The attached patch will fix some issues in both tests. I've confirmed
> that the tests work as expected with adt-run.

Thank you very much.  I've applied it to git, and plan an upload once
the current package in unstable enter testing.

--
Happy hacking
Petter Reinholdtsen

Bug#789569: src:argyll -- a lot of memory leaks && some out of bounds errors

[Jörg Frings-Fürst]

Hi,

upstream says no problem.

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#796611: ferm causes a unit ordering cycle that breaks booting

[Sam Morris]

severity 796611 grave
thanks

This is currently causing my system to boot without networking. I am
increasing the severity since other (rather important!) packages are
affected (I assume that I was just lucky until now).

I'm currently using the attached unit file to work around the breakage.
It's the same as the one I sent in before, but with
WantedBy=sysinit.target as advised by Felipe Sateler in the thread
above.

-- 
Sam Morris
https://robots.org.uk/
 
PGP: rsa4096/5CDA27B9
CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
[Unit]
Description=ferm firewall configuration
DefaultDependencies=no
Wants=network-pre.target
Before=network-pre.target shutdown.target
Conflicts=suhtdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/ferm /etc/ferm/ferm.conf
ExecReload=/usr/sbin/ferm /etc/ferm/ferm.conf
ExecStop=/usr/sbin/ferm -F /etc/ferm/ferm.conf

[Install]
WantedBy=sysinit.target

Bug#781087: Bug #781087 - libreoffice-impress: impress animation "strechy" dosn't work with drawings

[Wolfgang Hainz]

Hi Stéphane,

yes, I'm still seeing this bug with 5.0.5.2.

Regards,

Wolfgang

Bug#816866: mirror submission for mirror.fnkr.net

[Florian Kaiser]

Package: mirrors
Severity: wishlist

Submission-Type: new
Site: mirror.fnkr.net
Type: leaf
Archive-architecture: amd64 
Archive-http: /debian/
IPv6: no
Archive-upstream: ftp.de.debian.org
Updates: four
Maintainer: Florian Kaiser 
Country: DE Germany

Bug#816865: bluez: btattach from BlueZ 5.37 needed to enable Bluetooth on recent products, such as ThinkPad Tablet 8

[Jérôme de Bretagne]

Package: bluez
Version: 5.37
Severity: important

Dear Maintainer,

BlueZ has introduced the btattach command in release 5.37, as the successor to
hciattach. It seems to be the new recommended tool to enable recently-supported
chipsets, including in particular some Broadcom combo chipsets using SDIO for
Wi-Fi and UART for Bluetooth.

This is for instance the case on the Lenovo ThinkPad Tablet 8, which is using a
Broadcom 43241 rev B5 chip. The command to enable that Bluetooth device is:

$ btattach --bredr /dev/ttyS1 -P bcm# Sadly, this also requires a binary
firmware but that's another issue.

Could you please include this new btattach tool when you package the next BlueZ
version 5.37, and configure it in a way that it will enable such Bluetooth
chipsets directly at boot time?

I would be glad to evaluate experimental packages to confirm if this is working
properly on the ThinkPad Tablet 8 or not. Right now, I have Bluetooth working
but only in a manual way: recent Linux kernel and BlueZ 5.37 compiled locally
and btattach launched manually.

Thanks a lot,

Jérôme



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

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

Versions of packages bluez depends on:
ii  dbus 1.10.6-1
ii  init-system-helpers  1.28
ii  kmod 22-1
ii  libc62.21-9
ii  libdbus-1-3  1.10.6-1
ii  libglib2.0-0 2.46.2-3
ii  libreadline6 6.3-8+b4
ii  libudev1 229-2
ii  lsb-base 9.20160110
ii  udev 229-2

bluez recommends no packages.

bluez suggests no packages.

-- no debconf information

Bug#816864: ITP: ctmg -- Simple wrapper around cryptsetup for encrypted containers

[Iván Ruvalcaba]

Package: wnpp
Severity: wishlist

* Package name: ctmg
  Version:: 1.1
  Upstream Author : Jason A. Donenfeld 
* URL : https://git.zx2c4.com/ctmg/
* License : ISC
  Programming Lang: Bash
  Description : Simple wrapper around cryptsetup for encrypted containers

ctmg is an encrypted container manager for GNU/Linux using cryptsetup
and various standard file system utilities. Containers have the extension
'.ct' and are mounted at a directory of the same name, but without the
extension. Superuser permissions are required to run this script.

In short, a "poor" and native solution to TrueCrypt-like applications
whitout external dependencies.

Bug#816863: RFP: ruby-ffi-bit-masks -- FFI plugin which adds support for bitmasked types

[Cédric Boutillier]

Package: wnpp
Severity: wishlist

* Package name: ruby-ffi-bit-masks
  Version : 0.1.0
  Upstream Author : Hal Brodigan 
* URL : https://github.com/postmodern/ffi-bit_masks
* License : Expat
  Programming Lang: Ruby
  Description : FFI plugin which adds support for bitmasked types

Missing dependency for ruby-gir-ffi (#815802)

Bug#816272: [Pkg-clamav-devel] Bug#816272: clamav-freshclam: logrotate errors out with "gzip: stdin: file size changed while zipping"

[Sebastian Andrzej Siewior]

On 2016-03-05 20:44:33 [+0100], Christian Pernegger wrote:
> Thank you for getting back to me on this.
> 
> Yes, cron.weekly seems to run at 6:47 and the freshclam update every
> other hour at :46 ...

every other? I assumed twice a day. Probably got the numbers wrong.
Btw: is this the cron/ anacron package or systemd's cron stuff?

> I'll try the delaycompress option. Do you know if there's anything I
> can do to fix the root cause, i.e. the two cron jobs running so close
> together? It's a server that runs 24/7, there's plenty of time for
> them to get out of each other's hair.

I don't know if this is the cron daemon optimizing things or if it is really
by chance that cron.weekly runs at :47 while debconf decided :46 is a good
one.

When you select `cron' in debconf then it will roll the big dice and come up
with a number between 0 and 59 for the minute value. hour is just 24/x
depending on the interval you select. It seems you had bad luck and those
two came close together.
So either you edit it manually (/etc/cron.d/freshclam or so) or try again your
luck with debconf. Assuming the minute value gets set to :15 and then out of 
the sudden cron.weekly runs at 6:15 then it might be optimizing on cron's
side (but then this is the first report).
So there is this. I don't know how easy it would be to get both sides using
`flock' so they don't try writting to the same file at the same time. And we
have multiple scenarios like daemon mode, cron mode and so on.
So *I* really think just adding the extra option to lograte is the simplest
thing to do.

> 
> Christian

Sebastian

Bug#808601: #808601: ruby-rails: circular dependency hell

[Bill Allombert]

On Sat, Mar 05, 2016 at 12:23:35AM -0300, Christian Hofstaedtler wrote:
> The dependencies as stated are correct.
> 
> If you have a better solution, please describe it.
> 
> For now I'm closing this bug report as there's no actionable info.

I am confused: acoording to my record the dependency hell 
disappeared around "Sat Mar  5 12:01:41 CET 2016".
And indeed you probably fixed it yourself:

ruby-rails-html-sanitizer (1.0.3-2) unstable; urgency=medium

  [ Christian Hofstaedtler ]
  * Drop ruby-rails from Depends, as no lib code actually loads rails;
makes the dependency cycle a little less bad.

 -- Christian Hofstaedtler   Sat, 05 Mar 2016 04:24:42 +0100

So I suppose #808601 need to be reassigned to ruby-rails-html-sanitizer
and marked as fixed in 1.0.3-2

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#804616: sslscan: diff for NMU version 1.8.2-2.1

[Sebastian Andrzej Siewior]

Control: tags -1 +pending +patch

Dear maintainer,

I've prepared an NMU for sslscan (versioned as 1.8.2-2.1) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

Sebastian
diff --git a/debian/changelog b/debian/changelog
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+sslscan (1.8.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Make it build without SSLv3 (Closes: #804616)
+
+ -- Sebastian Andrzej Siewior   Sat, 05 Mar 2016 21:17:46 +0100
+
 sslscan (1.8.2-2) unstable; urgency=low
 
   * debian/control:
diff --git a/debian/patches/04-sslv3.diff b/debian/patches/04-sslv3.diff
new file mode 100644
--- /dev/null
+++ b/debian/patches/04-sslv3.diff
@@ -0,0 +1,88 @@
+Subject: compile against libssl1.0.2 without SSLv3
+
+SSLv3 methods are no longer available sine the transition to libssl1.0.2.
+BTS: #797926
+FTBFS of this package: #804616
+
+Signed-off-by: Sebastian Andrzej Siewior 
+Index: sslscan-1.8.2/sslscan.c
+===
+--- sslscan-1.8.2.orig/sslscan.c
 sslscan-1.8.2/sslscan.c
+@@ -575,6 +575,7 @@ int testCipher(struct sslCheckOptions *o
+ 	}
+ 	else
+ #endif
++#ifndef OPENSSL_NO_SSL3_METHOD
+ 	if (sslCipherPointer->sslMethod == SSLv3_client_method())
+ 	{
+ 		if (options->xmlOutput != 0)
+@@ -585,6 +586,7 @@ int testCipher(struct sslCheckOptions *o
+ 			printf("SSLv3  ");
+ 	}
+ 	else
++#endif
+ 	{
+ 		if (options->xmlOutput != 0)
+ 			fprintf(options->xmlOutput, "TLSv1\" bits=\"");
+@@ -703,6 +705,7 @@ int defaultCipher(struct sslCheckOptions
+ 			}
+ 			else
+ #endif
++#ifndef OPENSSL_NO_SSL3_METHOD
+ 			if (sslMethod == SSLv3_client_method())
+ 			{
+ if (options->xmlOutput != 0)
+@@ -713,6 +716,7 @@ int defaultCipher(struct sslCheckOptions
+ 	printf("SSLv3  ");
+ 			}
+ 			else
++#endif
+ 			{
+ if (options->xmlOutput != 0)
+ 	fprintf(options->xmlOutput, "  

Bug#812697: hwinfo: FTBFS

[Sebastien Badia]

tags 812697 pending
tags 812698 pending
thanks

Hi Adrian,

Sorry for the late reply, and thanks for this bug-report!

Just fixed in the git repository, it should be ok in a next upload.

Thanks

Seb


signature.asc
Description: PGP signature

Bug#816862: lintian: API documentation in manpage format

[Jakub Wilk]

Package: lintian
Version: 2.5.41
Severity: wishlist

I'd like to have Lintian API documentation in manpage format (in 
addition to, or instead of the HTML documentation).


--
Jakub Wilk

Bug#816861: fuser does not show the PID that keeps busy a schroot mount-point

[Franco Martelli]

Package: psmisc
Version: 22.21-2

The "fuser" command does not print nothing about PID of processes that
keep busy a schroot's generated mount-point. Error messages when I
logout a schroot session:

~$ logout
E: 10mount: rmdir: failed to remove
'/var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316':
Device or resource busy
E: kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316: Chroot setup failed:
stage=setup-stop

Now I need to discover which PID keeps busy the directory:

~# fuser -m
/var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316
/var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316:
 1rce 2rce 3rce 5rce 7rce 8rce 9rce10rce
11rce12rce13rce15rce16rce17rce18rce20rce
21rce22rce23rce25rce26rce27rce28rce30rce
31rce32rce33rce35rce36rce37rce38rce40rce
41rce42rce43rce44rce45rce46rce47rce48rce
49rce50rce51rce52rce53rce54rce55rce56rce
58rce59rce60rce61rce67rce68rce69rce70rce
73rce   115rce   116rce   117rce   123rce   124rce   125rce   126rce
127rce   128rce   129rce   130rce   131rce   132rce   133rce   134rce
136rce   139rce   140rce   141rce   142rce   143rce   146rce   147rce
155rce   156rce   157rce   158rce   159rce   160rce   161rce   162rce
163rce   165rce   169rce   175rce   176rce   177rce   190rce   191rce
197rce   198rce   220rce   221rce   252rce   254rce   260rce   262rce
267rce   269rce   310rce   342rce   426rce   428rce   435rce   482rce
488rce   494rce   499rce   500rce   502rce   503rce   505rce   506rce
508rce   509rce   511rce   513rce   536rce   537rce   691rce   694rce
701rce   724rce   725rce   726rce   776rce   788rce   801rce   862rce
871rce   899rce   903rce   904rce   909rce   911rce   912rce   914rce
946rce   949rce   950rce   989rce   990rce   993rce   995rce   998rce
1011rce  1046rce  1048rce  1049rce  1053rce  1060rce  1064rce  1079rce
1083rce  1288rce  1301rce  1302rce  1309rce  1333rce  1337rce  1338rce
1339rce  1342rce  1346rce  1368rce  1370rce  1375rce  1384rce  1396rce
1409rce  1418rce  1421rce  1422rce  1442rce  1443rce  1952rce  1953rce
2030rce  2034rce  2061rce  2138rce  2139rce
~# fuser /var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316
~#

but nothing useful it's shown. The only way to find that PID is to
"grep" the mountinfo files into the /proc filesystem:

~$ grep -r a3ca1d7f /proc/*/mountinfo
/proc/2061/mountinfo:196 41 253:3 /
/var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316
rw,relatime shared:135 - ext4 /dev/mapper/ld0-lv2 rw,stripe=256,data=ordered
/proc/2061/mountinfo:200 196 0:14 /
/var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316/sys
rw,nosuid,nodev,noexec,relatime shared:137 master:7 - sysfs sysfs rw
/proc/2061/mountinfo:216 196 0:3 /
/var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316/proc
rw,nosuid,nodev,noexec,relatime shared:151 master:12 - proc proc rw
/proc/2061/mountinfo:218 196 0:5 /
/var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316/dev
rw,relatime shared:153 master:2 - devtmpfs udev
rw,size=10240k,nr_inodes=988768,mode=755
/proc/2061/mountinfo:223 196 0:15 /
/var/lib/schroot/mount/kubuntu-a3ca1d7f-7fce-4673-b84a-6c4835bd7316/run
rw,nosuid,relatime shared:158 master:5 - tmpfs tmpfs
rw,size=1585940k,mode=755
~$

So "2061" was the PID that I looked for. Why doesn't "fuser" find it?

**
* Details of the installation:
**

~$ uname -a
Linux itek 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3
(2016-01-17) x86_64 GNU/Linux
~$ lsmod
Module  Size  Used by
binfmt_misc16949  1
pci_stub   12429  1
vboxpci22921  0
vboxnetadp 25540  0
vboxnetflt 27648  0
vboxdrv   375525  3 vboxnetadp,vboxnetflt,vboxpci
kvm_amd59128  0
kvm   388784  1 kvm_amd
snd_usb_audio 135354  1
uvcvideo   79005  0
videobuf2_vmalloc  12816  1 uvcvideo
videobuf2_memops   12519  1 videobuf2_vmalloc
videobuf2_core 47787  1 uvcvideo
crc32_pclmul   12915  0
v4l2_common12995  1 videobuf2_core
videodev  126451  3 uvcvideo,v4l2_common,videobuf2_core
snd_usbmidi_lib23388  1 snd_usb_audio
media  18305  2 uvcvideo,videodev
snd_rawmidi26806  1 snd_usbmidi_lib
snd_seq_device 13132  1 snd_rawmidi
aesni_intel   151423  0
nvidia   8555095  53
snd_hda_codec_hdmi 45118  1
aes_x86_64 16719  1 aesni_intel
eeepc_wmi  12600  0
asus_wmi   22781  1 eeepc_wmi
sparse_keymap  12818  1 asus_wmi
lrw12757  1 aesni_intel
gf128mul   12970  1 lrw
snd_hda_codec_realtek67127  1
snd_hda_codec_generic63181  1 

Bug#811708: init-system-helpers openrc branch pull request

[Andreas Henriksson]

Hello again Benda Xu.

I've noticed that you in 
http://anonscm.debian.org/cgit/openrc/openrc.git/commit/?id=e29522cd4ee0cb20de161eb7ef33312cf3ac2ae8
have dropped the diverts you shipped in previous openrc package revision
(in  favour of now using invoke-rc.d/update-rc.d from init-system-helpers).

Is this really enough though? Don't you need to actively undivert
on package upgrades to undo the diverts (for those that had the
0.20.4-1 revision installed. Please note that you'll need to handle
the case where the files are not diverted as well (eg. when upgrading
from Debian stable version to current unstable version).

You should be able to check $1 for upgrade and $2 for which version
you're upgrading from. See for example:
https://wiki.debian.org/DpkgConffileHandling

Regards,
Andreas Henriksson

Bug#816603: Ardour (4) - Adding FR translation to the desktop file

[trebmuh]

Le 2016-03-05 22:18, ow...@bugs.debian.org a écrit :

Processing commands for cont...@bugs.debian.org:


tags 816603 +pending
Bug #816603 [ardour] Ardour (4) - Adding FR translation to the desktop 
file

Added tag(s) pending.

thanks

Stopping processing here.

Please contact me if you need assistance.



Thank you :)
Olivier

Bug#804988: keyboard-configuration: Please drop dependency on initscripts package

[Felipe Sateler]

On 5 Mar 2016 17:02, "Anton Zinoviev"  wrote:
>
> On Fri, Mar 04, 2016 at 11:23:52AM -0300, Felipe Sateler wrote:
> >
> > AFAICT, initscripts itself is only needed to ensure the Required-Start
> > dependency of keyboard-setup.sh. This problem is solved by replacing
> > the dependency with init-system-helpers (>= 1.29~), which will do the
> > right thing when initscripts is not installed (ie, not abort the
> > installation).
>
> Another problem is the $remote_fs dependency of console-setup.sh. See
> #621077.

The problem is fixed when init-system-helpers (>= 1.29~) is installed.
Update-rc.d has been modified so that when it detects that initscripts is
not installed, insserv is invoked in a way that doesn't fail if
dependencies are missing. Therefore, the dependency can be changed from
initscripts to init-system-helpers (>= 1.29~).

Saludos

Bug#816444: decruft for wxwidgets3.0

[Scott Kitterman]

On March 5, 2016 4:00:10 PM EST, "Moritz Mühlenhoff"  wrote:
>On Wed, Mar 02, 2016 at 12:21:27AM -0500, Scott Kitterman wrote:
>> On Tuesday, March 01, 2016 10:17:02 PM Moritz Muehlenhoff wrote:
>> > Package: ftp.debian.org
>> > Severity: normal
>> > 
>> > Hi,
>> > since the libstdc++ transition, the binaries are named like
>> > libwxgtk-media3.0-0v5
>> > 
>> > However, the old binaries are still around (and blocking the
>> > gstreamer 0.10 removal), e.g.:
>> > 
>> > wxwidgets3.0: libwxgtk-media3.0-0 [amd64 arm64 armel armhf
>hurd-i386
>> > i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc ppc64el
>s390x]
>> > 
>> > Please decruft them.
>> 
>> At least according to the cruft report [1], that's going to break a
>stack of 
>> things:
>
>Ah. Sorry, I missed these.
>
>> barry: barrydesktop [kfreebsd-amd64 kfreebsd-i386]
>
>The maintainer filed an RM bug at #816774
>
>> freqtweak: freqtweak [amd64 armel armhf hurd-i386 i386
>kfreebsd-amd64 
>> kfreebsd-i386 mips mipsel powerpc s390x]
>
>This has been binNMUed
>
>> 3depict: 3depict [amd64 arm64 armel armhf i386 mips mipsel
>powerpc ppc64el s390x]
>> ginkgocadx: ginkgocadx [armel armhf mips mipsel powerpc ppc64el
>s390x]
>> rapidsvn: rapidsvn
>
>I'll look into three three, so that they're either fixed or removed.
>
>> kicad: kicad [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
>> libwx-perl: libwx-perl [hurd-i386]
>> survex: survex-aven [hurd-i386]
>> therion: therion-viewer [hurd-i386]
>
>These are all outdated/buggy builds on non-release archs not keeping
>up.
>Could you remove the hurd/freebsd builds on for these?

Yes. Once the rest are dealt with, remove the moreinfo tag and I'll take care 
of them at the same time.

Scott K

Bug#816697: jessie-pu: package fonts-sil-andika/1.004-2+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Fri, 2016-03-04 at 18:45 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2016-03-04 at 07:36 +0100, Petter Reinholdtsen wrote:
> > When the font-sil-andika package is installed in Jessie, the fontconfig
> > library print out these warnings for all X programs using fontconfig:
> > 
> > Fontconfig warning: "/etc/fonts/conf.d/65-andika.conf", line 16: Having 
> > multiple values in  isn't supported and may not work as expected
> > Fontconfig warning: "/etc/fonts/conf.d/65-andika.conf", line 35: Having 
> > multiple  in  isn't supported and may not work as expected
> > Fontconfig warning: "/etc/fonts/conf.d/65-andika.conf", line 35: Having 
> > multiple  in  isn't supported and may not work as expected
> > Fontconfig warning: "/etc/fonts/conf.d/65-andika.conf", line 35: Having 
> > multiple  in  isn't supported and may not work as expected
> > Fontconfig warning: "/etc/fonts/conf.d/65-andika.conf", line 35: Having 
> > multiple  in  isn't supported and may not work as expected
> > Fontconfig warning: "/etc/fonts/conf.d/65-andika.conf", line 35: Having 
> > multiple  in  isn't supported and may not work as expected
> > Fontconfig warning: "/etc/fonts/conf.d/65-andika.conf", line 35: Having 
> > multiple  in  isn't supported and may not work as expected
> > Fontconfig warning: "/etc/fonts/conf.d/65-andika.conf", line 35: Having 
> > multiple  in  isn't supported and may not work as expected
> > Fontconfig warning: "/etc/fonts/conf.d/65-andika.conf", line 35: Having 
> > multiple  in  isn't supported and may not work as expected
> > 
> > The package is a reverse dependency of tuxtype and
> > task-hungarian-desktop, and installed by default on Debian Edu.
> > 
> > The cause is an incorrect removal of a obsolete conffile in version
> > 1.004-2.  The fix was uploaded to unstable in version 5.000-1, and I
> > propose to include it in stable too.  The attached patch show the
> > changes. Is this OK to upload to stable?
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam

Bug#816322: aptitude: SIGABRT due to assertion failure when quitting from conflict resolver

[Katsuhiko Nishimra]

Hi, 
On Thu, Mar 03, 2016 at 01:40:57AM +, Manuel A. Fernandez Montecelo wrote:
> Control: tags -1 - moreinfo unreproducible + pending
> 
> 
> Hi Katsuhiko,
> 
> 2016-03-01 19:05 Katsuhiko Nishimra:
> >Hi, thank you for the reply.
> >
> >On Tue, Mar 01, 2016 at 12:30:51PM +, Manuel A. Fernandez Montecelo 
> >wrote:
> >>I could not reproduce it in my systems with the same versions, with
> >>either mini-buffer option enabled (as you seem to have) or disabled.
> >>
> >>Does this happen to you with .7 as well, uploaded earlier today?
> >Yes, it happens with 100% reproducibility also with 0.7.7-1 on my sid
> >system.
> >FWIW, I attach the result from `apt-config dump' and a core-dump from a
> >aptitude 0.7.7-1 killed by SIGABRT.
> >Please feel free to ask me any other information you want.
> 
> I think that I fixed now, but just in case, with the next release
> (should happen in a few days), please confirm if it's fixed for you.
> 
> Initially I thought that it was happening in both curses and command
> line because you mentioned "SIGABRT when quitting a conflict resolver in
> aptitude-curses", so I attempted to reproduce it in curses mode instead
> of following your instructions more closely -- sorry.
> 
> Interestingly, if one accepts a solution then everything is fine (maybe
> because the widget is destroyed).  The problem happens when quitting
> without accepting a solution.

Thank you.
I've confirmed with aptitude=0.7.8-1 that SIGABRT has gone even when
quitting without accepting a solution.

However, I've encountered another corner case.
When aptitude cause too many conflicts and cannot resolve them in
command line mode,
(I ran into this situation because I installed aptitude=0.7.8-1 by dpkg
and forgot upgrading aptitude-dbgsym accordingly, then tested 
$ aptitude -s install -t experimental ~i)
entering curses mode by hitting `e' and quitting without resolving
conflicts kills aptitude by SIGABRT.

This is a very irregular situation, so I won't reopen this bug report.

Again, many thanks for your effort.

Regards,
Katsuhiko

Bug#787168: "filter failed" error when trying to print on HP M1132

[Vincent Ricard]

Package: hplip
Version: 3.16.2+repack0-4
Followup-For: Bug #787168

Hi,

I've the same problem with an HP LaserJet m1132 MFP.

Here are the installed versions:
hplip   3.16.2+repack0-4   i386
cups2.1.3-3i386

In the logs, i found (i tried to print the test page):
D [Job 1116] prnt/hpcups/HPCupsFilter.cpp 486: m_Job initialization failed with 
error = 48
D [Job 1116] Read 107 bytes of print data...
D [Job 1116] Wrote 107 bytes of print data...
D [Job 1116] Sent 107 bytes...
D [Job 1116] PID 4706 (/usr/lib/cups/filter/hpcups) stopped with status 1.

Let me know you wish i run some command to help you debugging this.

Regards

Bug#816859: Dependency on avahi-daemon

[Chris Boot]

Control: tags -1 confirmed

On 05/03/2016 20:52, Hans van Kranenburg wrote:
[snip]
> While trying to install, the following happened:
[snip]
> So maybe you missed a dependency while packaging, as I didn't have
> avahi-daemon installed yet.

Hi Hans,

You are quite right, I definitely have something wrong here. Whether I
need to add a hard dependency on avahi-daemon or fix the systemd unit to
not depend on it so hard I'm not sure yet, but I'll investigate and fix.

Thanks for the bug report!

Chris

-- 
Chris Boot
deb...@bootc.net
GPG: 8467 53CB 1921 3142 C56D  C918 F5C8 3C05 D9CE 



signature.asc
Description: OpenPGP digital signature

Bug#816860: stable backport, please

[Joey Hess]

Package: haskell-stack
Version: 0.1.10.0-1
Severity: normal

There's currently no way to get stack installed on stable w/o
downloading a binary from a third party, without any means of
verification. 

The source depends on a newer base than stable's ghc currently has.
So, it might be somewhat tricky to backport it.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#548505: aptitude reports incorrectly essential packages

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi all,

2009-10-07 15:51 Daniel Burrows:

On Tue, Oct 06, 2009 at 06:32:22PM +0200, Vincenzo Tibullo  
was heard to say:

2009/10/5 Daniel Burrows :
> Internally, aptitude maps "~E" to testing the flags "essential" or
>"important".  

I think this is not what user expect.


 True.  "important" is not a concept that's documented anywhere.  The
only hesitation I have is that it's a change from aptitude's historical
behavior, and I don't want to modify that precipitously.  However, I'll
probably do it eventually, since this is a very small corner case.


I changed this now, so ~E doesn't match those which come from apt with
flag "Important" (because of what D.Burrows says above, and also see
also at bottom of this message).



>This is also what it does when testing whether to warn
>the user about packages they're removing.

>apt always turns on the
>"important" flag for the package named "apt", regardless of whether
>Essential is set to true for it.

This is not clear to me: what do you mean by "apt always turns on the
'important' flag for the package named 'apt'"?


 When apt is setting up its internal structures, it turns the Essential
flag on for packages with "Essential: yes", and it turns the Important
flag on for packages with "Important: yes" (of which there are none).
It also turns it on for packages named "apt", of which there is exactly
one (obviously :) ).


... and now, Important continues to be zero and apt declares itself
Essential and Important internally, depending on some conditions, so the
output is exactly the same as before.

So in a way, this aspect of the bug report is not addressed with the
current fix.

However, if we disregard these flags and go and parse the raw package
records...  seems a bit heavy-handed, going out of our way and probably
inefficient, so I don't know if it's better to do that.

The options are:

a) Do the heavy-handed method anyway, even if expensive

b) Warn in the docs about this specific apt "implementation detail"

c) Mark this bug as +wontfix

d) Ask apt developers to not do that internally

e) Keep this fix checking only for Essential, and do nothing else
  regarding this problem

f) Something else


2011-10-16 03:16 Josh Triplett:

Package: aptitude
Version: 0.6.4-1
Followup-For: Bug #548505

I just hit this today myself, and it resulted in the filing of bug
645451.  Any status on this bug?


So, about one of your messages in that bug report -- it is apt marking
itself as essential, not aptitude treating apt in any special way.

The reason why "cupt/aptitude/... show apt | grep Essential" does not
show it as essential it is because it shows a more-or-less raw record,
where "Essential: yes" is not present.

If the Important flag is not used by any package perhaps it should be
removed from apt, and the reason why apt has "flag Essential" in both
apt (internally) and aptitude is up to apt.  I don't know if apt or
other front-ends (cupt, synaptic, python-apt...) use these flags for
something else.

aptitude does now what Julian recommends in the last message of the
report:

 "aptitude should be changed to ignore the Important flag when
 searching for essential packages."


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#816444: decruft for wxwidgets3.0

[Moritz Mühlenhoff]

On Wed, Mar 02, 2016 at 12:21:27AM -0500, Scott Kitterman wrote:
> On Tuesday, March 01, 2016 10:17:02 PM Moritz Muehlenhoff wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > Hi,
> > since the libstdc++ transition, the binaries are named like
> > libwxgtk-media3.0-0v5
> > 
> > However, the old binaries are still around (and blocking the
> > gstreamer 0.10 removal), e.g.:
> > 
> > wxwidgets3.0: libwxgtk-media3.0-0 [amd64 arm64 armel armhf hurd-i386
> > i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc ppc64el s390x]
> > 
> > Please decruft them.
> 
> At least according to the cruft report [1], that's going to break a stack of 
> things:

Ah. Sorry, I missed these.

> barry: barrydesktop [kfreebsd-amd64 kfreebsd-i386]

The maintainer filed an RM bug at #816774

> freqtweak: freqtweak [amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 
> kfreebsd-i386 mips mipsel powerpc s390x]

This has been binNMUed

> 3depict: 3depict [amd64 arm64 armel armhf i386 mips mipsel powerpc 
> ppc64el s390x]
> ginkgocadx: ginkgocadx [armel armhf mips mipsel powerpc ppc64el s390x]
> rapidsvn: rapidsvn

I'll look into three three, so that they're either fixed or removed.

> kicad: kicad [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
> libwx-perl: libwx-perl [hurd-i386]
> survex: survex-aven [hurd-i386]
> therion: therion-viewer [hurd-i386]

These are all outdated/buggy builds on non-release archs not keeping up.
Could you remove the hurd/freebsd builds on for these?

Cheers,
Moritz

Bug#816859: Dependency on avahi-daemon

[Hans van Kranenburg]

Package: shairport-sync
Version: 2.8.0-1

Hi,

thank you for packaging shairport-sync! I was just browsing around a bit 
wondering if there would be a way to directly stream music from my 
iphone to my debian pc, and discovered this package, just added to 
debian a few days ago.


After fixing a missing dependency, it just works (tm), shows up as 
remote device, I choose it and my music continues to play on this 
computer. Very neat.


While trying to install, the following happened:

# apt-get install shairport-sync
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libconfig9 libdaemon0
The following NEW packages will be installed:
  libconfig9 libdaemon0 shairport-sync
0 upgraded, 3 newly installed, 0 to remove and 87 not upgraded.
Need to get 0 B/145 kB of archives.
After this operation, 383 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Selecting previously unselected package libdaemon0:amd64.
(Reading database ... 99316 files and directories currently installed.)
Preparing to unpack .../libdaemon0_0.14-6_amd64.deb ...
Unpacking libdaemon0:amd64 (0.14-6) ...
Selecting previously unselected package libconfig9:amd64.
Preparing to unpack .../libconfig9_1.5-0.2_amd64.deb ...
Unpacking libconfig9:amd64 (1.5-0.2) ...
Selecting previously unselected package shairport-sync.
Preparing to unpack .../shairport-sync_2.8.0-1_amd64.deb ...
Unpacking shairport-sync (2.8.0-1) ...
Processing triggers for systemd (228-6) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up libdaemon0:amd64 (0.14-6) ...
Setting up libconfig9:amd64 (1.5-0.2) ...
Setting up shairport-sync (2.8.0-1) ...
Failed to start shairport-sync.service: Unit avahi-daemon.service failed 
to load: No such file or directory.

invoke-rc.d: initscript shairport-sync, action "start" failed.
dpkg: error processing package shairport-sync (--configure):
 subprocess installed post-installation script returned error exit status 6
Processing triggers for libc-bin (2.21-9) ...
Processing triggers for systemd (228-6) ...
Errors were encountered while processing:
 shairport-sync
[master 64715cc] committing changes in /etc after apt run
 12 files changed, 144 insertions(+)
 create mode 100644 default/shairport-sync
 create mode 100755 init.d/shairport-sync
 create mode 12 rc0.d/K01shairport-sync
 create mode 12 rc1.d/K01shairport-sync
 create mode 12 rc2.d/S02shairport-sync
 create mode 12 rc3.d/S02shairport-sync
 create mode 12 rc4.d/S02shairport-sync
 create mode 12 rc5.d/S02shairport-sync
 create mode 12 rc6.d/K01shairport-sync
 create mode 100644 shairport-sync.conf
 create mode 12 
systemd/system/multi-user.target.wants/shairport-sync.service

E: Sub-process /usr/bin/dpkg returned an error code (1)


When installing avahi-daemon:

# apt-get install avahi-daemon
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libavahi-core7
Suggested packages:
  avahi-autoipd
Recommended packages:
  libnss-mdns
The following NEW packages will be installed:
  avahi-daemon libavahi-core7
0 upgraded, 2 newly installed, 0 to remove and 87 not upgraded.
1 not fully installed or removed.
Need to get 201 kB of archives.
After this operation, 557 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.nl.debian.org/debian stretch/main amd64 libavahi-core7 
amd64 0.6.32~rc+dfsg-1 [113 kB]
Get:2 http://ftp.nl.debian.org/debian stretch/main amd64 avahi-daemon 
amd64 0.6.32~rc+dfsg-1 [88.4 kB]

Fetched 201 kB in 0s (1,060 kB/s)
Selecting previously unselected package libavahi-core7:amd64.
(Reading database ... 99345 files and directories currently installed.)
Preparing to unpack .../libavahi-core7_0.6.32~rc+dfsg-1_amd64.deb ...
Unpacking libavahi-core7:amd64 (0.6.32~rc+dfsg-1) ...
Selecting previously unselected package avahi-daemon.
Preparing to unpack .../avahi-daemon_0.6.32~rc+dfsg-1_amd64.deb ...
Unpacking avahi-daemon (0.6.32~rc+dfsg-1) ...
Processing triggers for libc-bin (2.21-9) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for dbus (1.10.6-1) ...
Processing triggers for systemd (228-6) ...
Setting up shairport-sync (2.8.0-1) ...
A dependency job for shairport-sync.service failed. See 'journalctl -xe' 
for details.

invoke-rc.d: initscript shairport-sync, action "start" failed.
dpkg: error processing package shairport-sync (--configure):
 subprocess installed post-installation script returned error exit status 1
Setting up libavahi-core7:amd64 (0.6.32~rc+dfsg-1) ...
Setting up avahi-daemon (0.6.32~rc+dfsg-1) ...
Processing triggers for libc-bin (2.21-9) ...
Processing triggers for dbus (1.10.6-1) ...
Processing triggers for systemd (228-6) ...
Errors were encountered while processing:
 shairport-sync
[master 6e29b66] committing changes in /etc after apt run
 51 files changed, 

Bug#816768: v4l2loopback-dkms: simply fails with "Internal data flow error" on basi usage

[Debian/GNU]

On 03/04/2016 10:52 PM, Anonymous wrote:
> If the same hardware boots Linux Mint instead of Debian stable, there
> is no problem.  This package installs completely, so that modprobe is
> automatically run on boot, and the gstreamer test works, as well as
> any other content given over gstreamer.  So this is likely a problem
> with the debian packaging.

which version of Linux Mint is this?
more importantly: which version of v4l2loopback are you running on Mint?

for whatever reasons Mint doesn't list which v4l2loopback version it
ships [1].

which version of GStreamer are you running on Mint?
which version of GStreamer are you running on Debian?


afaik, Mint only takes the Debian packages, so i doubt that there is an
issue with packaging.


[1]
http://packages.linuxmint.com/search.php?keyword=v4l2loopback=any=any



signature.asc
Description: OpenPGP digital signature

Bug#816858: Logical volumes on external USB disk cause boot to enter emergency shell

[Christoph Pleger]

Package: lvm2
Version: 2.02.111-2.2


Dear maintainers,

I have Debian jessie running on a Wandboard armhf device. Some of the 
filesystems are located in LVM logical volumes on an external USB disk. This 
causes boot to enter emergeny shell, because the logical volumes cannot be 
found. The only way I found so far to prevent that is to use sysvinit instead 
of systemd and insert a sleep in /etc/init.d/lvm2 before vgchange.

Regards
  Christoph Pleger 

Bug#816857: gimagereader: fails to launch with "symbol lookup error"

[Manolo Díaz]

Package: gimagereader
Version: 3.1.2+git368fa8f-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

This is the complete error messager:

gimagereader-gtk: symbol lookup error: gimagereader-gtk:
undefined symbol: _ZN9tesseract11TessBaseAPI13AnalyseLayoutEv

The application never gets launched.

Kind regards,
Manolo Díaz


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

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

Versions of packages gimagereader depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  libatkmm-1.6-1v5 2.24.2-1
ii  libc62.21-9
ii  libcairomm-1.0-1v5   1.12.0-1
ii  libgcc1  1:5.3.1-10
ii  libglib2.0-0 2.46.2-3
ii  libglibmm-2.4-1v52.46.3-1
ii  libgomp1 5.3.1-10
ii  libgtk-3-0   3.18.8-1
ii  libgtkmm-3.0-1v5 3.18.0-1
ii  libgtksourceviewmm-3.0-0v5   3.18.0-1
ii  libgtkspellmm-3.0-0v53.0.3+dfsg-2
ii  libpangomm-1.4-1v5   2.38.1-1
ii  libpoppler-glib8 0.38.0-2
ii  libsane  1.0.25-2
ii  libsigc++-2.0-0v52.6.2-1
ii  libstdc++6   5.3.1-10
ii  libtesseract33.04.00-5+b2

gimagereader recommends no packages.

gimagereader suggests no packages.

-- no debconf information

Bug#816856: license-reconcile: The output changes without any changes to the source code

[Petter Reinholdtsen]

Package: license-reconcile
Version: 0.10

While trying to use license-reconcile to check if the debian/copyright
file for zfsonlinux was complete and correct, I discovered something
strange.  The output from license-reconcile changed every time I ran
int.

Here is an example, showing that the list of files reported with
copyright mismatch change for two consecutive runs without any changes
to the code or the debian/copyright file:

% license-reconcile 2>&1 |grep -v -P 'CDDL.* which does not match CDDL.*'|grep 
-v debian/ |grep -v Makefile.in |cut -d: -f1-2
Copyright mismatch: File cmd/zed/zed_conf.h
Copyright mismatch: File cmd/zed/zed_file.h
Copyright mismatch: File config/rpm.am
License mismatch: File config/config.sub has license GPL-2+ which does not 
match GPL-2+ with autoconf exception. at 
/usr/share/perl5/Debian/LicenseReconcile/App.pm line 222,  line 3.
Copyright mismatch: File config/config.sub
Copyright mismatch: File man/man8/zdb.8
Copyright mismatch: File cmd/zed/zed.c
Copyright mismatch: File man/man8/zpool.8
Binary file (standard input) matches
% license-reconcile 2>&1 |grep -v -P 'CDDL.* which does not match CDDL.*'|grep 
-v debian/ |grep -v Makefile.in |cut -d: -f1-2
License mismatch: File contrib/bash_completion.d/zfs has license MIT/X11 (BSD 
like) which does not match Expat. at 
/usr/share/perl5/Debian/LicenseReconcile/App.pm line 222,  line 3.
License mismatch: File scripts/kmodtool has license MIT/X11 (BSD like) which 
does not match Expat. at /usr/share/perl5/Debian/LicenseReconcile/App.pm line 
222,  line 3.
Copyright mismatch: File rpm/generic/zfs.spec.in
Copyright mismatch: File cmd/zed/zed.h
Copyright mismatch: File cmd/zed/zed_log.h
License mismatch: File config/missing has license GPL-2+ which does not match 
GPL-2+ with autoconf exception. at 
/usr/share/perl5/Debian/LicenseReconcile/App.pm line 222,  line 3.
Copyright mismatch: File cmd/zed/zed_event.h
Copyright mismatch: File cmd/zed/zed_log.c
Copyright mismatch: File OPENSOLARIS.LICENSE
Copyright mismatch: File cmd/zed/zed.c
Copyright mismatch: File cmd/zed/zed_strings.c
Copyright mismatch: File config/rpm.am
Copyright mismatch: File cmd/zed/zed_exec.c
Copyright mismatch: File configure.ac
Copyright mismatch: File man/man5/zfs-module-parameters.5
Copyright mismatch: File man/man8/zdb.8
License mismatch: File include/sys/u8_textprep_data.h has license CDDL which 
does not match Expat~Unicode. at 
/usr/share/perl5/Debian/LicenseReconcile/App.pm line 222,  line 3.
Copyright mismatch: File include/sys/u8_textprep_data.h
Copyright mismatch: File man/man8/zpool.8
Binary file (standard input) matches
%

The problematic source can be found using
http://anonscm.debian.org/gitweb/?p=pkg-zfsonlinux/spl.git >.
-- 
Happy hacking
Petter Reinholdtsen

Bug#804988: keyboard-configuration: Please drop dependency on initscripts package

[Anton Zinoviev]

On Fri, Mar 04, 2016 at 11:23:52AM -0300, Felipe Sateler wrote:
> 
> AFAICT, initscripts itself is only needed to ensure the Required-Start
> dependency of keyboard-setup.sh. This problem is solved by replacing
> the dependency with init-system-helpers (>= 1.29~), which will do the
> right thing when initscripts is not installed (ie, not abort the
> installation).

Another problem is the $remote_fs dependency of console-setup.sh. See 
#621077.

Anton Zinoviev

Bug#807992: [OATH-Toolkit-help] Bug#807992: per user oath files

[Antoine Beaupré]

On 2015-12-21 16:44:23, Ilkka Virta wrote:
> On 16.12. 15:44, Antoine Beaupré wrote:
>> On 2015-12-16 06:21:01, Ilkka Virta wrote:
>> Right, you are right of course. I do think it's critical to keep that
>> file from being readable from random apps. The format *is* also a little
>> brittle so it seems important to have standardized access as well...
>>
>> Maybe having a system similar to shadow passwords would be necessary
>> here: there could be a secret file that can only be read by root (or
>> with the right caps) and would need a special tool (oath.passwd?) to
>> reset.
>
> Well being root-only and having some sort of a helper app is already 
> needed. (Though the helper might well be the admins text editor.
>
> As for brittleness, it shares the same thing with all other text files: 
> they kind of have to be rewritten completely every time (can't just 
> replace a single line). Unless you meant some other brittleness? Of 
> course there's locking, per-user files would make that a bit simpler.

No that is pretty much it - i was thinking of lock contention issues and
so on.

> This was the per-user shadow file thingy I was thinking of:
> http://www.openwall.com/tcb/ (see the slides)

right. pretty much what i had in mind.

a.

-- 
When I came back to the United States, I decided that if you could use
propaganda for war, you could certainly use it for peace. And
"propaganda" got to be a bad word because of the Germans using it, so
what I did was to try and find some other words so we found the words
"public relations".
 - Edward Bernays

Bug#816855: gramps: unable to display places in geography view

[IOhannes m zmoelnig]

Package: gramps
Version: 4.2.2~dfsg-1
Severity: normal

Dear Maintainer,

today i discovered that the "geography view" stopped working (i'm pretty sure it
did work, but don't know the last version of gramps where this is true).

The problem is, that I store the coordinates of my places in
degree/minutes/seconds (e.g.  "51° 28′ 48″ N") and gramps fails to convert these
coordinates into floating point (51.48).
Btw, gramps does a syntax-check when I enter the coordinates, and verifies that
the above coordinates are fine; but when I want to display the places, I get a
traceback:

> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/gramps/gui/viewmanager.py", line 966, 
> in __create_page
> page_display = page.get_display()
>   File "/usr/lib/python3/dist-packages/gramps/gui/views/pageview.py", line 
> 389, in get_display
> self.top = self.build_interface()
>   File "/usr/lib/python3/dist-packages/gramps/gui/views/pageview.py", line 
> 162, in build_interface
> widget = self.build_widget()
>   File "/usr/lib/python3/dist-packages/gramps/plugins/lib/maps/osmgps.py", 
> line 115, in build_widget
> self.change_map(None, config.get("geography.map_service"))
>   File "/usr/lib/python3/dist-packages/gramps/plugins/lib/maps/osmgps.py", 
> line 172, in change_map
> self.goto_handle(handle=None)
>   File "/usr/lib/python3/dist-packages/gramps/plugins/view/geoplaces.py", 
> line 176, in goto_handle
> self.build_tree()
>   File "/usr/lib/python3/dist-packages/gramps/plugins/view/geoplaces.py", 
> line 194, in build_tree
> self._createmap(active)
>   File "/usr/lib/python3/dist-packages/gramps/plugins/view/geoplaces.py", 
> line 279, in _createmap
> self.osm.set_center_and_zoom(float(place.get_latitude()),
> ValueError: could not convert string to float: '51° 28′ 48″ N'

Attached is a minimal database (consisting of a single place), that exhibits 
the problem.
Basically, you only have to go to the "Geography" view and select "All known 
places".
(sometimes i have to switch to another menu and then back after that).

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

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

Versions of packages gramps depends on:
ii  gir1.2-gtk-3.03.18.8-1
ii  librsvg2-22.40.13-3
ii  python3-bsddb36.1.0-1+b2
ii  python3-gi3.18.2-2
ii  python3-gi-cairo  3.18.2-2
pn  python3:any   
ii  xdg-utils 1.1.1-1

Versions of packages gramps recommends:
ii  gir1.2-gexiv2-0.100.10.3-2
ii  gir1.2-osmgpsmap-1.0  1.1.0-1
ii  graphviz  2.38.0-12+b1
ii  python3-icu   1.9.2-2+b2

Versions of packages gramps suggests:
ii  fonts-freefont-ttf20120503-4
pn  gir1.2-goocanvas-2.0  
ii  gir1.2-gtkspell3-3.0  3.0.7-2
ii  python3-pil   3.1.1-1
ii  rcs   5.9.4-3

-- no debconf information


places-bug.gramps
Description: application/gzip

Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)

[Anton Zinoviev]

On Fri, Mar 04, 2016 at 03:08:39PM -0300, Felipe Sateler wrote:
>
> > Unfortunately, I will not be able to maintain this file or to update it
> > in accordance with future changes in systemd.  So I suppose that unless
> > you or somebody else volunteers to maintain it, it will be better to
> > continue without it.
> 
> As long as the initscript does simple things, it should require very
> little maintainance. While I can't commit to maintain it (I am no
> expert in console matters), feel free to CC pkg-systemd-maintainers or
> myself if you ever receive a bug about this.

The reason I hesitate is that I am not a "normal" maintainer of 
console-setup.  While I have enough time for development related to 
console-setup, my limitations force me to allocate this time in batches 
with relatively large periods between them.  In fact, it won't be 
incorrect to say that most of the time other people take care of this 
package (one can easily observe this in the changelog).

> >> Before=local-fs-pre.target
> >> Wants=local-fs-pre.target
> >
> > What is the meaning of these two?
> 
> This ensures it is run before systemd attempts to fsck and mount any
> local filesystems. It is therefore a relatively appropriate
> replacement for the checkroot dependency.

What does 'Wants' do?  Is this some kind of optimization?

> There does not appear to be a keymap init script:
> 
> These are created by the kernel when devtmpfs is mounted, and systemd
> mounts /dev before starting any units, so they should be available,
> yes.

This is good.  It seems we don't need 'After'.

> > One novelty in version 1.138 is that it is unnecessary to run setupcon
> > in order to configure the console.  It is OK to configure the keyboard
> > in this way, but this usually will be slower than what the script
> > keyboard-setup.sh does -- instead of setupcon it runs
> > /etc/console-setup/cached_setup_keyboard.sh and reverts to using
> > setupcon only when this script doesn't exist of fails.
> 
> IMO, the init script should be as dumb as possible, as it is a
> conffile. Therefore all program logic should move outside the script
> and into a helper script that lives in /lib. This way, improvements
> are guaranteed to be shipped to users.

The script /etc/console-setup/cached_setup_keyboard.sh is not a 
configuration file and the user is not supposed to edit it.  Since it is 
autogenerated, there is no problem to ship improvements to the users. 
(Under FHS this script would have to go in /var rather than in /etc, 
however, we need it while /var is not yet mounted.  Years ago, nobody at 
debian-devel could find a solution to this problem, so now console-setup 
violates this aspect of FHS.)

> The resulting unit would be:
> 
> ConditionPathExists=/bin/setupcon

Is there a possibility to use something like 'ConditionPathDoesntExist?  
If yes, then we can use two units like these:

Unit 1:

ConditionPathExists=/etc/console-setup/cached_setup_keyboard.sh
ExecStart=/etc/console-setup/cached_setup_keyboard.sh

Unit 2:

ConditionPathDoesntExist=/etc/console-setup/cached_setup_keyboard.sh
ConditionPathExists=/bin/setupcon
ExecStart=/bin/setupcon --keyboard-only

Anton Zinoviev

Bug#800419: tahoe-lafs stops systemd

[James Valleroy]

Resending the patch, since the lines got messed up by my mail client.
From 033ec10c581bda7bfabb668dccc8d6ea3a8d4108 Mon Sep 17 00:00:00 2001
From: James Valleroy 
Date: Sat, 5 Mar 2016 14:25:43 -0500
Subject: [PATCH] Correct arg order in init script.

---
 debian/tahoe-lafs.init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/tahoe-lafs.init b/debian/tahoe-lafs.init
index 352ee75..27a614b 100755
--- a/debian/tahoe-lafs.init
+++ b/debian/tahoe-lafs.init
@@ -55,7 +55,7 @@ _tahoe () {
 case "$action" in
 start|restart)
 su -s "/bin/sh" \
-   -c "'$DAEMON' '$action' $DAEMONARGS '$CONFIG_DIR/${node_name}'" \
+   -c "'$DAEMON' '$action' '$CONFIG_DIR/${node_name}' $DAEMONARGS" \
"$node_uid"
 ;;
 stop)
-- 
2.7.0



signature.asc
Description: OpenPGP digital signature

Bug#816272: [Pkg-clamav-devel] Bug#816272: clamav-freshclam: logrotate errors out with "gzip: stdin: file size changed while zipping"

[Christian Pernegger]

2016-03-04 22:10 GMT+01:00 Sebastian Andrzej Siewior :
> I copied your debconf and it seems to work here. Can you check your logs
> if the freshclam log runs at the same time as your logrorate script?
> I have no idea why but it seems to be the case. Adding `delaycompress'
> to the cron script should fix it.

Thank you for getting back to me on this.

Yes, cron.weekly seems to run at 6:47 and the freshclam update every
other hour at :46 ...

I'll try the delaycompress option. Do you know if there's anything I
can do to fix the root cause, i.e. the two cron jobs running so close
together? It's a server that runs 24/7, there's plenty of time for
them to get out of each other's hair.

Christian

Bug#816854: forcing reinstallation of alternative ... because link group ... is broken

[積丹尼 Dan Jacobson]

Package: imagemagick-6.q16
Version: 8:6.9.2.10+dfsg-2

(Reported by me elsewhere too.)
Preparing to unpack .../imagemagick_8%3a6.9.2.10+dfsg-2_all.deb ...
Unpacking imagemagick (8:6.9.2.10+dfsg-2) ...
Processing triggers for mime-support (3.59) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for desktop-file-utils (0.22-1) ...
Processing triggers for hicolor-icon-theme (0.13-1) ...
Setting up imagemagick-6.q16 (8:6.9.2.10+dfsg-2) ...
update-alternatives: using /usr/bin/compare-im6.q16 to provide /usr/bin/compare 
(compare) in auto mode
update-alternatives: using /usr/bin/animate-im6.q16 to provide /usr/bin/animate 
(animate) in auto mode
update-alternatives: using /usr/bin/convert-im6.q16 to provide /usr/bin/convert 
(convert) in auto mode
update-alternatives: using /usr/bin/composite-im6.q16 to provide 
/usr/bin/composite (composite) in auto mode
update-alternatives: using /usr/bin/conjure-im6.q16 to provide /usr/bin/conjure 
(conjure) in auto mode
update-alternatives: using /usr/bin/import-im6.q16 to provide /usr/bin/import 
(import) in auto mode
update-alternatives: using /usr/bin/identify-im6.q16 to provide 
/usr/bin/identify (identify) in auto mode
update-alternatives: using /usr/bin/stream-im6.q16 to provide /usr/bin/stream 
(stream) in auto mode
update-alternatives: using /usr/bin/display-im6.q16 to provide /usr/bin/display 
(display) in auto mode
update-alternatives: using /usr/bin/montage-im6.q16 to provide /usr/bin/montage 
(montage) in auto mode
update-alternatives: using /usr/bin/mogrify-im6.q16 to provide /usr/bin/mogrify 
(mogrify) in auto mode
update-alternatives: warning: forcing reinstallation of alternative 
/usr/bin/compare-im6.q16 because link group compare-im6 is broken
update-alternatives: warning: forcing reinstallation of alternative 
/usr/bin/animate-im6.q16 because link group animate-im6 is broken
update-alternatives: warning: forcing reinstallation of alternative 
/usr/bin/convert-im6.q16 because link group convert-im6 is broken
update-alternatives: warning: forcing reinstallation of alternative 
/usr/bin/composite-im6.q16 because link group composite-im6 is broken
update-alternatives: warning: forcing reinstallation of alternative 
/usr/bin/conjure-im6.q16 because link group conjure-im6 is broken
update-alternatives: warning: forcing reinstallation of alternative 
/usr/bin/import-im6.q16 because link group import-im6 is broken
update-alternatives: warning: forcing reinstallation of alternative 
/usr/bin/identify-im6.q16 because link group identify-im6 is broken
update-alternatives: warning: forcing reinstallation of alternative 
/usr/bin/stream-im6.q16 because link group stream-im6 is broken
update-alternatives: warning: forcing reinstallation of alternative 
/usr/bin/display-im6.q16 because link group display-im6 is broken
update-alternatives: warning: forcing reinstallation of alternative 
/usr/bin/montage-im6.q16 because link group montage-im6 is broken
update-alternatives: warning: forcing reinstallation of alternative 
/usr/bin/mogrify-im6.q16 because link group mogrify-im6 is broken
Setting up imagemagick (8:6.9.2.10+dfsg-2) ...

Bug#816159: www.debian.org: new introduction for blends page

[Ana Custura]

Hi all,

On 05/03/16 14:01, Jonas Smedegaard wrote:

>> Of course, the information can be rephrased and moved if one wants to put 
>> less
>> emphasis on it (for more emphasis elsewhere).  For instance, we could add
>> something like "Debian Pure Blends are developed, distributed and supported
>> fully within Debian" at the end of the current "first paragraph".
> 
> That sounds like a nice improvement to me.

With regards to the second paragraph that was removed, 'forks' is not a
concept most end users will be familiar with, but the idea that blends
are entirely contained within Debian is important. I suggest we add a
second paragraph:


"Debian Pure Blends are developed, distributed and supported fully
within Debian. Therefore, if you obtain a complete
Debian distribution, you have all available Debian Pure Blends
available for installation."

How does this sound?

Ana

Bug#813598: [gnutls-devel] FTBFS[kfreebsd]: tests/mini-loss-time race

[Steven Chamberlain]

Hi Andreas,

In a future upload please could you try the attached diff, which is a
much simpler way I found to get the testsuite output into the build log.
Since more than one set of tests runs in parallel, we only currently see
the test-suite.log for one set of tests, and not all of them.

> On Sat, 2016-03-05 at 17:30 +0100, Andreas Metzler wrote:
> > Well with 3.4.10 the timeout does not seem to make any difference. 
> > Any of
> > 
> > gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); [Steven's 
> > patch]

Your commit to the gnutls28 package in experimental
https://anonscm.debian.org/cgit/pkg-gnutls/gnutls.git/commit/?h=experimental=896b247a321271ab61ed1fce5065cadbd472c207
seems to do the opposite of my patch, it increases the server timeout?
My patch decreased it:  https://bugs.debian.org/813598#5

> > gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000); [3.4.10]
> > gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); 
> > [e6dcb14dbbd3e9e40a1f193a7bf6657e82b88cb9]
> > *always* fails on kfreebsd-amd64.

If it fails _reliably_ now, I consider that an improvement!
I'll try to test all of the above and see how often each one fails.

Nikos Mavrogiannopoulos wrote:
> It would be nice to have some debugging output of the failed test
> (e.g., run with -v). Is that a 32-bit system? I'm wondering whether it
> relates to the undefined behavior fixes.

I've also attached a log of `tests/mini-loss-time -v`, from a
kfreebsd-amd64 system after I built Andreas' gnutls28/3.4.10-1 package
from experimental.

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
--- debian/rules.orig	2016-03-05 07:16:57.0 +
+++ debian/rules	2016-03-05 12:53:20.231986977 +
@@ -106,12 +106,7 @@
 	dh_strip --ddeb-migration='libgnutls30-dbg (<< 3.4.7-2~)'
 
 override_dh_auto_test:
-	dh_auto_test -O--parallel || touch dh_auto_test.fail
-	@if test -e dh_auto_test.fail ; then \
-		find -name test-suite.log | \
-		while read i ; do \
-		echo "dh_auto_test.fail" ; echo $$i ; echo  ; \
-		cat $$i ; echo ; done ; rm -f dh_auto_test.fail; false; fi
+	dh_auto_test -O--parallel -- VERBOSE=1
 
 override_dh_clean:
 	dh_clean -X.bak
0.20 
0.141000 Will discard server packet 2
0.141029 client|<5>| REC[0x621b20]: Allocating epoch #0
0.141044 client|<3>| ASSERT: gnutls_constate.c:596
0.141057 client|<5>| REC[0x621b20]: Allocating epoch #1
0.141070 server|<5>| REC[0x621b20]: Allocating epoch #0
0.141084 client|<4>| HSK[0x621b20]: Keeping ciphersuite: 
GNUTLS_ECDH_ANON_AES_128_CBC_SHA1 (C0.18)
0.141098 client|<4>| HSK[0x621b20]: Keeping ciphersuite: 
GNUTLS_ECDH_ANON_AES_256_CBC_SHA1 (C0.19)
0.14 client|<4>| HSK[0x621b20]: Keeping ciphersuite: 
GNUTLS_ECDH_ANON_3DES_EDE_CBC_SHA1 (C0.17)
0.141124 client|<4>| EXT[0x621b20]: Sending extension EXT MASTER SECRET (0 
bytes)
0.141137 client|<4>| EXT[0x621b20]: Sending extension STATUS REQUEST (5 bytes)
0.141150 client|<4>| EXT[0x621b20]: Sending extension SAFE RENEGOTIATION (1 
bytes)
0.141163 client|<4>| EXT[0x621b20]: Sending extension SESSION TICKET (0 bytes)
0.141177 client|<4>| EXT[0x621b20]: Sending extension SUPPORTED ECC (12 bytes)
0.141191 client|<4>| EXT[0x621b20]: Sending extension SUPPORTED ECC POINT 
FORMATS (2 bytes)
0.141204 client|<4>| HSK[0x621b20]: CLIENT HELLO was queued [104 bytes]
0.141217 client|<11>| HWRITE: enqueued [CLIENT HELLO] 104. Total 104 bytes.
0.141236 client|<11>| HWRITE FLUSH: 104 bytes in buffer.
0.141250 client|<6>| DTLS[0x621b20]: Start of flight transmission.
0.141263 client|<6>| DTLS[0x621b20]: Sending Packet[0] fragment CLIENT HELLO(1) 
with length: 92, offset: 0, fragment length: 92
0.141277 client|<5>| REC[0x621b20]: Preparing Packet Handshake(22) with length: 
104 and min pad: 0
0.141291 client|<9>| ENC[0x621b20]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
0.141304 server|<3>| ASSERT: gnutls_constate.c:596
0.141316 client|<11>| WRITE: enqueued 117 bytes for 0x5. Total 117 bytes.
0.141329 server|<5>| REC[0x621b20]: Allocating epoch #1
0.141342 client|<5>| REC[0x621b20]: Sent Packet[1] Handshake(22) in epoch 0 and 
length: 117
0.141355 client|<11>| WRITE FLUSH: 117 bytes in buffer.
0.141369 client|<11>| WRITE: wrote 117 bytes, 0 bytes left.
0.141389 server|<3>| ASSERT: gnutls_buffers.c:1158
0.141405 server|<10>| READ: Got 117 bytes from 0x4
0.141423 server|<10>| READ: read 117 bytes from 0x4
0.141436 server|<10>| RB: Have 0 bytes into buffer. Adding 117 bytes.
0.141449 server|<10>| RB: Requested 13 bytes
0.141469 server|<5>| REC[0x621b20]: SSL 254.255 Handshake packet received. 
Epoch 0, length: 104
0.141482 server|<5>| REC[0x621b20]: Expected Packet Handshake(22)
0.141496 server|<5>| REC[0x621b20]: Received Packet Handshake(22) with length: 
104
0.141509 server|<5>| REC[0x621b20]: Decrypted Packet[0.0] Handshake(22) with 
length: 104
0.141522 server|<13>| BUF[REC]: Inserted 104 bytes of Data(22)
0.141534 server|<4>| HSK[0x621b20]: CLIENT HELLO (1) was received. Length 
92[92], frag offset 0, frag length: 92, sequence: 0

Bug#816853: pagekite: Fix autopkgtests and enable test-tunnel

[James Valleroy]

Package: pagekite
Version: 0.5.8a-2
Severity: minor
Tags: patch

The attached patch will fix some issues in both tests. I've confirmed that the
tests work as expected with adt-run.



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

Kernel: Linux 4.4.0-1-amd64 (SMP w/12 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 pagekite depends on:
ii  daemon0.6.4-1
ii  python-openssl0.15.1-2
ii  python-socksipychain  2.0.15-1
pn  python:any

pagekite recommends no packages.

pagekite suggests no packages.

-- Configuration Files:
/etc/pagekite.d/10_account.rc [Errno 13] Permission denied: 
u'/etc/pagekite.d/10_account.rc'

-- no debconf information
>From 59990f061415b7ff3355bff020b8a75ce7295c51 Mon Sep 17 00:00:00 2001
From: James Valleroy 
Date: Sat, 5 Mar 2016 13:52:38 -0500
Subject: [PATCH] Fix autopkgtests and enable test-tunnel.

---
 debian/tests/control |  4 ++--
 debian/tests/test-client-running |  3 +++
 debian/tests/test-tunnel | 15 ++-
 3 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/debian/tests/control b/debian/tests/control
index 2f5c4b8..48daa67 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,4 +1,4 @@
-Depend: @
-Tests: test-client-running
+Depends: @
+Tests: test-client-running, test-tunnel
 Restrictions: needs-root
 
diff --git a/debian/tests/test-client-running b/debian/tests/test-client-running
index 495908e..ffc3836 100755
--- a/debian/tests/test-client-running
+++ b/debian/tests/test-client-running
@@ -1,5 +1,7 @@
 #!/bin/sh
 
+set -e
+
 PATH=/usr/sbin:$PATH
 export PATH
 
@@ -12,6 +14,7 @@ if service pagekite status; then
 echo "success: service running"
 else
 echo "error: service is not running"
+exit 1
 fi
 
 service pagekite stop 2>&1
diff --git a/debian/tests/test-tunnel b/debian/tests/test-tunnel
index 5dcc2c6..14eced0 100755
--- a/debian/tests/test-tunnel
+++ b/debian/tests/test-tunnel
@@ -1,14 +1,14 @@
 #!/bin/sh
 #
-# Set up pagekite on localhost to tunnel from port 80 (http) to port
-# 113 (ident) to allow the ident server to be queried using port 80.
+# Set up pagekite on localhost to tunnel from port 8080 to port 113
+# (ident) to allow the ident server to be queried using port 8080.
 
 set -e
-set -x
 
 SECRET=foo # FIXME replace by something random
 DNSNAME=$(hostname)
 identport=113
+test_error=no
 
 echo "starting frontend"
 pagekite \
@@ -27,13 +27,18 @@ backpid=$!
 sleep 10
 
 echo "trying to connect to ident server via pagekite"
-if echo | nc localhost http; then
+if echo | nc localhost 8080; then
 echo success
 else
 echo error
+test_error=yes
 fi
 
 echo "stopping pagekite processes"
 kill $frontpid $backpid
 sleep 5
-kill -9 $frontpid $backpid
+kill -9 $frontpid $backpid 2>/dev/null || true
+
+if [ "$test_error" = "yes" ]; then
+exit 1
+fi
-- 
2.7.0

Bug#782616: nm.debian.org: Please add a mechanism to test mail dispatch

[efkin]

On 03/05/2016 06:47 PM, Santiago Ruano Rincón wrote:
> Hi,
> 
> 
> I didn't still get that mail about my last NM, even if the timeline fits
> your analysis:
> 
> 2016-02-14  jmw Activity poll sent  Resent activity poll
> 2016-02-19  jmw Advocacies have been approved   
> 2016-02-19  jmw Waiting for AM to confirm   Assigned to santiago
> 2016-02-22  santiagoInteracting with an AM  

That was some missing information, thanks a lot!

> And I can see in the mail archive that the corresponding message:
> 
> From: Jonathan Wiltshire via nm 
> To: Santiago Ruano Rincxf3n 
> 
> I wonder if nm.d.o is not correctly handling the diacritic in my last
> name, look at the "Rincxf3n". I wouldn't be surprised that encoding is
> challenging this also (see https://bugs.debian.org/744077). I'd say we
> still live in a not fully unicode-compliant world.
> 

I will try to test against this scenario and report back here, hopefully
with a solution.

> Even if you English was bad, you shouldn't be sorry.

Thx.

> Thanks for looking into this,

You're welcome.

> Santiago

efkin.

Bug#816852: flashplugin-nonfree: missing gnupg2 dependency

[Nemo Inis]

Package: flashplugin-nonfree
Version: 1:3.6.1+b1
Severity: normal

Dear Maintainer,

flashplugin-nonfree has a "Depends: gnupg" clause, which makes it depend on
GnuPG v1 only.
The clause should be "Depends: gnupg | gnupg2" to allow for systems with GnuPG
v2 only.




-- Package-specific info:
Debian version: stretch/sid
Architecture: i386
Package version: 1:3.6.1+b1
Adobe Flash Player version: LNX 11,2,202,569
MD5 checksums:
88aa056c9d4f919bfc9c301f099fe0d1  
/var/cache/flashplugin-nonfree/adobewebpage.html
160a01dd00527304e5291e65eb0c65e2  
/var/cache/flashplugin-nonfree/get-upstream-version.pl
4a43aafd3e23167487168df8fbcf2b96  
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.i386.tar.gz
d933470c6e6c40ae214758082d658e39  
/usr/lib/flashplugin-nonfree/libflashplayer.so
Alternatives:
flash-mozilla.so - auto mode
  link best version is /usr/lib/flashplugin-nonfree/libflashplayer.so
  link currently points to 
/usr/lib/flashplugin-nonfree/libflashplayer.so
  link flash-mozilla.so is /usr/lib/mozilla/plugins/flash-mozilla.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
lrwxrwxrwx 1 root root 34 Aug 29  2015 
/usr/lib/mozilla/plugins/flash-mozilla.so -> /etc/alternatives/flash-mozilla.so
/usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to 
/etc/alternatives/flash-mozilla.so

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

Kernel: Linux 4.3.0-1-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, 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 flashplugin-nonfree depends on:
ii  binutils   2.26-4
ii  ca-certificates20160104
ii  debconf [debconf-2.0]  1.5.58
ii  gnupg  1.4.20-4
ii  libatk1.0-02.18.0-1
ii  libcairo2  1.14.6-1
ii  libcurl3-gnutls7.47.0-1
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.6.1-0.1
ii  libgcc11:5.3.1-8
ii  libglib2.0-0   2.46.2-3
ii  libgtk2.0-02.24.29-1
ii  libnspr4   2:4.11-1
ii  libnss32:3.21-1.1
ii  libpango1.0-0  1.38.1-1
ii  libstdc++6 5.3.1-8
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.5-1
ii  wget   1.17.1-1+b1

flashplugin-nonfree recommends no packages.

Versions of packages flashplugin-nonfree suggests:
pn  flashplugin-nonfree-extrasound  
ii  fonts-dejavu2.35-1
pn  hal 
ii  iceweasel   44.0.2-1
pn  konqueror-nsplugins 
ii  ttf-mscorefonts-installer   3.6
pn  ttf-xfree86-nonfree 

-- no debconf information

Bug#815734: regression: ESS cannot be compiled

[Dirk Eddelbuettel]

On 5 March 2016 at 19:11, Martin Maechler wrote:
| Well, I'm not so much of a "real texinfo user", but
| @Dirk:  You must have messed up badly:  In your run Metafont is called
| because tex can't find fonts, and then "tears indeed".

The observation is correct, the inference is not.

This is the exact same way we build packages, so this is almost certainly
indicative of a larger, or different issue.  To put it more plainly: the
exact same setup (from my side) built all other ESS uploads over the years.

[ But underlying Debian packages change too so I might need a new font
package, on the other hand I just built 15.09.2-2 this same very a few days
ago.  And, just to make this point very explicit, I rebuilt it now. ]
 
| If I just do what Norbert suggested, placing his new  texinfo.tex  in
| my local directory  then the minimal example runs fine and (after

That is not a pristine, empty, virgin, ... build environment, which is our
requirement and meaurement standard.  [ You can (easily) simulate something
like with by installing the docker binary package and starting from an
(almost empty) Debian or Ubuntu container. It is a powerful too. ]

| 'make clean'), 'make' does also run fine with the ESS manual and all
| other such files there. and I did make sure that indeed Norbert's
| new file is used everywhere in the process:
| (./texinfo.tex Loading texinfo [version 2016-02-05.07.deb2])
| 
| So I'd say Norbert (and his team)'s changes were successful and have
| solved the regression.
| Thank you guys so much!

I disagree (strongly) as I have identical build setups differing only between

   edd@max:/tmp/ess$ grep texinfoversion{2 ess-15.09.2-?/doc/texinfo.tex
   ess-15.09.2-2/doc/texinfo.tex:\def\texinfoversion{2015-06-24.23}
   ess-15.09.2-3/doc/texinfo.tex:\def\texinfoversion{2016-02-05.07.deb2}
   edd@max:/tmp/ess$ 

and the former builds whereas the latter fails.

So, still 'nope' from here.

Dirk
 
| Martin
| 
| On Sat, Mar 5, 2016 at 4:25 PM, Dirk Eddelbuettel  wrote:
| >
| > On 5 March 2016 at 23:37, Norbert Preining wrote:
| > | Hi all (Debian only)
| > |
| > | On Sat, 05 Mar 2016, Gavin Smith wrote:
| > | > Done in SVN revision 7041. Please email if there are further problems.
| > |
| > | I have prepare a new version of texinfo package, can you please check
| > | whether the attached texinfo.tex fixes the problem for you?
| > |
| > | That is, make a built with the attached file included in the source
| > | dir instead of the old version.
| > |
| > | Please check that the log file mentions the following texinfo.tex
| > | version:
| > |   2016-02-05.07.deb2
| > |
| > | Thanks for letting me know
| >
| > Negative.
| >
| > Using the same pbuilder chroot, starting from the same ess 15.09.2-2 
package I
| > successfully prepared with the texinfo 6.0 file texinfo.tex, I now get a
| > fail once I now include the new texinfo.tex you just emailed.
| >
| > I tickle a grep for its version in debian/rules as you requested:
| >
| > dh_testdir
| > echo "*** For Norbert  ***"
| > *** For Norbert  ***
| > grep texinfoversion doc/texinfo.tex
| > \def\texinfoversion{2016-02-05.07.deb2}
| > \message{Loading texinfo [version \texinfoversion]:}
| > \everyjob{\message{[Texinfo version \texinfoversion]}%
| > @c time-stamp-start: "deftexinfoversion{"
| > echo "*** For Norbert  ***"
| > *** For Norbert  ***
| >
| > and it ends in tears a little later -- though now with a different issue.
| > Real texinfo users like Kurt or Martin may have an idea:
| >
| >
| > Chapter 11 [55] [56] [57] [58] [59] [60] Chapter 12 [61]
| > (/build/ess-15.09.2/doc/help-s.texi [62] [63] [64] [65] [66]) Chapter 13
| > [67] (/build/ess-15.09.2/doc/help-sas.texi [68] [69] [70] [71] [72] [73]
| > [74] [75]) Chapter 14 [76] (/build/ess-15.09.2/doc/help-bugs.texi) Chapter 
15
| > [77] (/build/ess-15.09.2/doc/help-jags.texi [78]) Chapter 16 [79]
| > (/build/ess-15.09.2/doc/bugs.texi) (/build/ess-15.09.2/doc/bugrept.texi)
| > (/build/ess-15.09.2/doc/mailing.texi [80]) Appendix A [81] (Indices) [82]
| > kpathsea: Running mktextfm ecrm1440
| > mkdir: cannot create directory '././nonexistent': Permission denied
| > mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; 
input ecrm1440
| > This is METAFONT, Version 2.7182818 (TeX Live 2015/Debian) (preloaded 
base=mf)
| >
| > kpathsea: Running mktexmf ecrm1440
| >
| > ! I can't find file `ecrm1440'.
| > <*> ...ljfour; mag:=1; nonstopmode; input ecrm1440
| >
| > Please type another input file name
| > ! Emergency stop.
| > <*> ...ljfour; mag:=1; nonstopmode; input ecrm1440
| >
| > Transcript written on mfput.log.
| > grep: ecrm1440.log: No such file or directory
| > mktextfm: `mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; input 
ecrm1440' failed to make ecrm1440.tfm.
| > kpathsea: Appending font creation commands to missfont.log.
| >
| > ./ess.texi:3643: Font \thisecfont=ecrm1440 at 14.0pt not loadable: Metric 
(TFM)
| >  file not found.
| > 
| >   

Bug#813632: [Pkg-kde-extras] Bug#813632: digikam crashes when tagging a photo

[Diederik de Haas]

severity 813632 normal
reassign 813632 libexiv2-14 0.25-2.1
merge 813632 814051
thanks

> You can tag this as a duplicate of
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814051

As you wish ;-)

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

Bug#813933: RFS: sawfish/1:1.11-1 [ITA] -- window manager for X11

[Jose M Calhariz]

Ok, this time I overdo it.

On 05/03/16 15:13, Mattia Rizzolo wrote:
> On Fri, Mar 04, 2016 at 09:17:45PM +, Jose M Calhariz wrote:
>> One more iteraction.  This time I centred on cleaning or overriding
>> lintian messages.
> umh 3cb664996f1694f8b72eb42c45ef4ef970f4998c
>
> 1) "Don't know where is the public key." — you of course you can find it
> in any keyserver…, so it should be
> https://sks-keyservers.net/pks/lookup?op=get=0xB60C068FC61670EE
> Then there is always the trouble of trusting that's really theirs, but
> this is another story

The key I am looking is 0x2BF6893F36C73306.

> 2) 'opts="pgpsigurlmangle=s%$%.sha256.sig%"' is not going to work
> anyway, since uscan expects the signature to sign the tarball, while
> that's the signature of the sha256 hash of the tarball

Once I have the key, I will ask upstream to sign the tarball and the
checksum.

> 3) this is not a thing to override since
>a) somebody says overriding lower than warning tags is excessive (I
>   personally don't agree here, just bringing a datapoint)
>b) you override wrong tags (false positive) or tags that for some
>   reason could never be fixed, not just to hide them
>the correct action here is really to leave it as it is, maybe asking
>upstream to start signing the tarballs instead of checksum.
>
Is now OK?

Kind regards
Jose M Calhariz




signature.asc
Description: OpenPGP digital signature

Bug#816850: postfix-policyd-spf-python: policyd can crash on UTF-8 senders

[Jon]

Package: postfix-policyd-spf-python
Version: 1.3.2-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

While testing the new SMTP UTF8 support of postfix3 on my mail server I
noticed that policyd-spf can crash if the message contains a UTF-8 sender
and the SPF result is reject

Mar  5 13:04:49 pinero policyd-spf[32559]: Traceback (most recent call last):
Mar  5 13:04:49 pinero policyd-spf[32559]:   File "/usr/bin/policyd-spf", line 
708, in 
Mar  5 13:04:49 pinero policyd-spf[32559]: sys.stdout.write('action=550 
%s\n\n' % checkerReason)
Mar  5 13:04:49 pinero policyd-spf[32559]: UnicodeEncodeError: 'ascii' codec 
can't encode characters in position 112-114: ordinal not in range(128)
Mar  5 13:04:50 pinero postfix/spawn[32558]: warning: command 
/usr/bin/policyd-spf exit status 1
Mar  5 13:04:50 pinero postfix/smtpd[32543]: warning: premature end-of-input on 
private/policy-spf while reading input attribute name
.


All the code paths right below this catch the UnicodeEncodeError and do
the right thing so the patch is trivial.

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

Kernel: Linux 4.4.0-1-amd64 (SMP w/2 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 postfix-policyd-spf-python depends on:
ii  adduser  3.113+nmu3
ii  postfix  3.0.4-5
ii  python3  3.5.1-2
ii  python3-authres  0.800-2
ii  python3-spf  2.0.12t-1
pn  python3:any  

postfix-policyd-spf-python recommends no packages.

postfix-policyd-spf-python suggests no packages.

-- no debconf information
--- policyd-spf.orig	2016-03-05 13:22:48.314039539 -0500
+++ policyd-spf	2016-03-05 13:23:14.930919022 -0500
@@ -705,7 +705,10 @@
 #  handle results  {{{3
 if debugLevel >= 3: syslog.syslog('Action: {0}: Text: {1}'.format(checkerValue, checkerReason))
 if checkerValue == 'reject':
-sys.stdout.write('action=550 %s\n\n' % checkerReason)
+try:
+sys.stdout.write('action=550 %s\n\n' % checkerReason)
+except UnicodeEncodeError:
+sys.stdout.write('action=550 %s\n\n' % str(checkerReason.encode("UTF-8"))[1:].strip("'"))
 
 elif checkerValue == 'prepend':
 if configData.get('Prospective'):

Bug#816849: ITP: ruby-berkshelf-api-client -- ruby library for communicating with a Berkshelf API server

[Hleb Valoshka]

Package: wnpp
Severity: wishlist
Owner: Hleb Valoshka <375...@gmail.com>

* Package name: ruby-berkshelf-api-client
  Version : 2.0.1
  Upstream Author : Jamie Winsor 
* URL : http://berkshelf.com/
* License : Apache-2.0
  Programming Lang: Ruby
  Description : ruby library for communicating with a Berkshelf API server


Required for Berkshelf - dependency management tool for Chef.

Bug#781087: Bug #781087 - libreoffice-impress: impress animation "strechy" dosn't work with drawings

[Stéphane Aulery]

Hi Wolfgang,

Le 05/03/2016 15:33, Wolfgang Hainz a écrit :


thanks for looking into this issue. Please find below the output of lsusb and 
lspci. Actually I'm using LO Version 5.0.5.2 from Debian Stable backports.


Thanks for tho output.

Did you have the same bug with 5.0.5.2 ?

Regards,

--
Stéphane Aulery

Bug#815734: regression: ESS cannot be compiled

[Martin Maechler]

Well, I'm not so much of a "real texinfo user", but
@Dirk:  You must have messed up badly:  In your run Metafont is called
because tex can't find fonts, and then "tears indeed".

If I just do what Norbert suggested, placing his new  texinfo.tex  in
my local directory  then the minimal example runs fine and (after
'make clean'), 'make' does also run fine with the ESS manual and all
other such files there. and I did make sure that indeed Norbert's
new file is used everywhere in the process:
(./texinfo.tex Loading texinfo [version 2016-02-05.07.deb2])

So I'd say Norbert (and his team)'s changes were successful and have
solved the regression.
Thank you guys so much!

Martin

On Sat, Mar 5, 2016 at 4:25 PM, Dirk Eddelbuettel  wrote:
>
> On 5 March 2016 at 23:37, Norbert Preining wrote:
> | Hi all (Debian only)
> |
> | On Sat, 05 Mar 2016, Gavin Smith wrote:
> | > Done in SVN revision 7041. Please email if there are further problems.
> |
> | I have prepare a new version of texinfo package, can you please check
> | whether the attached texinfo.tex fixes the problem for you?
> |
> | That is, make a built with the attached file included in the source
> | dir instead of the old version.
> |
> | Please check that the log file mentions the following texinfo.tex
> | version:
> |   2016-02-05.07.deb2
> |
> | Thanks for letting me know
>
> Negative.
>
> Using the same pbuilder chroot, starting from the same ess 15.09.2-2 package I
> successfully prepared with the texinfo 6.0 file texinfo.tex, I now get a
> fail once I now include the new texinfo.tex you just emailed.
>
> I tickle a grep for its version in debian/rules as you requested:
>
> dh_testdir
> echo "*** For Norbert  ***"
> *** For Norbert  ***
> grep texinfoversion doc/texinfo.tex
> \def\texinfoversion{2016-02-05.07.deb2}
> \message{Loading texinfo [version \texinfoversion]:}
> \everyjob{\message{[Texinfo version \texinfoversion]}%
> @c time-stamp-start: "deftexinfoversion{"
> echo "*** For Norbert  ***"
> *** For Norbert  ***
>
> and it ends in tears a little later -- though now with a different issue.
> Real texinfo users like Kurt or Martin may have an idea:
>
>
> Chapter 11 [55] [56] [57] [58] [59] [60] Chapter 12 [61]
> (/build/ess-15.09.2/doc/help-s.texi [62] [63] [64] [65] [66]) Chapter 13
> [67] (/build/ess-15.09.2/doc/help-sas.texi [68] [69] [70] [71] [72] [73]
> [74] [75]) Chapter 14 [76] (/build/ess-15.09.2/doc/help-bugs.texi) Chapter 15
> [77] (/build/ess-15.09.2/doc/help-jags.texi [78]) Chapter 16 [79]
> (/build/ess-15.09.2/doc/bugs.texi) (/build/ess-15.09.2/doc/bugrept.texi)
> (/build/ess-15.09.2/doc/mailing.texi [80]) Appendix A [81] (Indices) [82]
> kpathsea: Running mktextfm ecrm1440
> mkdir: cannot create directory '././nonexistent': Permission denied
> mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; 
> input ecrm1440
> This is METAFONT, Version 2.7182818 (TeX Live 2015/Debian) (preloaded base=mf)
>
> kpathsea: Running mktexmf ecrm1440
>
> ! I can't find file `ecrm1440'.
> <*> ...ljfour; mag:=1; nonstopmode; input ecrm1440
>
> Please type another input file name
> ! Emergency stop.
> <*> ...ljfour; mag:=1; nonstopmode; input ecrm1440
>
> Transcript written on mfput.log.
> grep: ecrm1440.log: No such file or directory
> mktextfm: `mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; input 
> ecrm1440' failed to make ecrm1440.tfm.
> kpathsea: Appending font creation commands to missfont.log.
>
> ./ess.texi:3643: Font \thisecfont=ecrm1440 at 14.0pt not loadable: Metric 
> (TFM)
>  file not found.
> 
>\thisecfont
> \indexlbrace ->{\ifmonospace \else \ecfont
>\fi \char 123}
>  ... \kern -0.05em \secbf {\indexlbrace
>   }
> \leftline #1->\line {#1
>\hss }
> \initialx ...e {\secfonts \kern -0.05em \secbf #1}
>   \nobreak \vskip 
> .33\baseli...
>
> \thisline ->\initial {{\indexlbrace }}
>
> ...
> l.3643 @printindex ky
>
> ?
> ./ess.texi:3643: Emergency stop.
> 
>\thisecfont
> \indexlbrace ->{\ifmonospace \else \ecfont
>\fi \char 123}
>  ... \kern -0.05em \secbf {\indexlbrace
>   }
> \leftline #1->\line {#1
>\hss }
> \initialx ...e {\secfonts \kern -0.05em \secbf #1}
>   \nobreak \vskip 
> .33\baseli...
>
> \thisline ->\initial {{\indexlbrace }}
>
> ...
> l.3643 @printindex ky
>
> ./ess.texi:3643:  ==> Fatal error occurred, no output PDF file produced!
> Transcript written on ess.log.
> /usr/bin/texi2dvi: pdfetex exited with bad status, quitting.
> Makefile:43: recipe for target 'ess.pdf' failed
> make[1]: *** [ess.pdf] Error 1
> make[1]: Leaving directory '/build/ess-15.09.2/doc'
> debian/rules:35: recipe for target 

Bug#816848: pepperflashplugin-nonfree: Doesn't update pepperflash

[Frank McCormick]

Package: pepperflashplugin-nonfree
Version: 1.8.2
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,


The pepperflashplugin-nonfree doesn't update or install pepperflash. I suspect 
the reason
is Google has dropped support for 32 bit Google-Chrome, so the flash package is 
simply not available anymore.

This is the result of running it 



root@frank-debian:/home/frank# update-pepperflashplugin-nonfree --install 
--verbose
options :  --install --verbose --
temporary directory: /tmp/pepperflashplugin-nonfree.lOWqvvqSXk
doing apt-get update on google repository
E: No packages found
E: No packages found
E: No packages found
E: No packages found
E: No packages found
downloading 
http://people.debian.org/~bartm/pepperflashplugin-nonfree/latest-stable-verified.txt
selected action = --install
dpkg-deb: error: --extract needs a target directory.
Perhaps you should be using dpkg --install ?

Type dpkg-deb --help for help about manipulating *.deb files;
Type dpkg --help for help about installing and deinstalling packages.
root@frank-debian:/home/frank# 




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

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages pepperflashplugin-nonfree depends on:
ii  binutils   2.26-5
ii  ca-certificates20160104
ii  debconf [debconf-2.0]  1.5.58
ii  gnupg  1.4.20-4
ii  libatk1.0-02.18.0-1
ii  libcairo2  1.14.6-1
ii  libcurl3-gnutls7.47.0-1
ii  libfontconfig1 2.11.0-6.3
ii  libfreetype6   2.6.3-3
ii  libgcc11:5.3.1-10
ii  libglib2.0-0   2.46.2-3
ii  libgtk2.0-02.24.29-1
ii  libnspr4   2:4.11-1
ii  libnss32:3.21-1.1
ii  libpango-1.0-0 1.38.1-1
ii  libpango1.0-0  1.38.1-1
ii  libstdc++6 5.3.1-10
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.5-1
ii  wget   1.17.1-1+b1

pepperflashplugin-nonfree recommends no packages.

Versions of packages pepperflashplugin-nonfree suggests:
ii  chromium   49.0.2623.75-2
pn  hal
ii  ttf-dejavu 2.35-1
pn  ttf-mscorefonts-installer  
pn  ttf-xfree86-nonfree

-- no debconf information

Bug#816847: ITP: dislocker -- read/write encrypted BitLocker volume

[Marco d'Itri]

On Mar 05, Giovani Augusto Ferreira  wrote:

>  The driver used to only read volumes encrypted under a Windows 7 system but 
> is
>  now Windows Vista and 8 capable and has the write functionality.
The package description is not the right place to explain the 
development history of the package: just list its capabilities, if this 
is an information useful to prospective users.

>  The core driver is composed of a library, with multiple binaries using this
>  library. Two binaries are of interest when wanting to ecrypt a BitLocker
>  encrypted partition:
The package description is not a replacemente for the package 
documentation either.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#798680: ruby2.2: Contains file released under a nonfree license

[Francesco Poli]

On Sat, 19 Dec 2015 16:23:02 +0100 Francesco Poli wrote:

> On Sat, 19 Dec 2015 14:06:46 +0100 Christian Hofstaedtler wrote:
> 
> > * Francesco Poli  [151219 13:01]:
[...]
> > While the files in the ruby source package bear the
> > old Unicode license header, Unicode, Inc. has published newer
> > versions of those files under the current unicode.org public
> > license[1] which is as free as we want it to be.
> 
> I am happy to learn this.
> The current Unicode Data Files and Software license [1] indeed looks OK
> for Debian main.
> 
> > 
> > Replacing the license comments in those files is work that's better
> > done upstream but there's no pressing issue for us.
> 
> Apart that the current situation is misleading and should be cured.
> 
> > At some point
> > we should probably update d/copyright saying that those files match
> > the unicode.org/Public files and therefore are under the unicode.org
> > public license. Or upstream gets to updating the file headers
> > first.
> 
> Please urge Ruby upstream developers to update those files, thus
> replacing the old permission notice with the new one.
> In the meanwhile, I think a comment should be placed in the
> debian/copyright file explaining the state of affairs: otherwise,
> expect a number of bug reports similar to this one in the future.

Hello Christian,
I would like to reiterate the importance of curing this misleading
situation.
The debian/copyright file of ruby2.2 (and of ruby2.3, as well) still
claims that a number of files shipped in the package are under the
obsolete troublesome Unicode license. But, as you explained, they are
effectively under the new DFSG-free Unicode license [1].

The fact is that the debian/copyright file is misleading.
I have recently taken a look at it and found this issue. I had even
forgotten about our previous discussion, hence I was about to file a
new bug report about it!:-|
Luckily, while checking whether anyone else had already reported the
issue, I found this bug report and re-read the bug log. At that point,
I saw my own previous messages and thought "wow! I had already had this
discussion and completely forgot about it!"...

So once again: please fix this issue, at least by placing a comment in
the debian/copyright file explaining the state of affairs!

Thanks for your time.
Bye!

[...]
> > [1] http://www.unicode.org/copyright.html#Exhibit1


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp4KJDI92ooc.pgp
Description: PGP signature

Bug#813598: [gnutls-devel] FTBFS[kfreebsd]: tests/mini-loss-time race

[Nikos Mavrogiannopoulos]

On Sat, 2016-03-05 at 17:30 +0100, Andreas Metzler wrote:
> Control: reopen 813598
> 
> On 2016-02-15 Nikos Mavrogiannopoulos  wrote:
> > On Sun, Feb 14, 2016 at 3:14 PM, Andreas Metzler  
> > wrote:
> > > this is http://bugs.debian.org/813598 reported by Steven 
> > > Chamberlain:
> 
> > > gnutls28 tests/mini-loss-time fails about 20% of the time when I 
> > > try it
> > > on kfreebsd-amd64.  I think probably introduced by this commit:
> > > https://gitlab.com/gnutls/gnutls/commit/e2a3ad31c487cbce997a08ddd
> > > c55db639b60c024
> 
> > I've applied a similar fix in master.
> 
> Well with 3.4.10 the timeout does not seem to make any difference. 
> Any of
> 
> gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000); [Steven's 
> patch]
> gnutls_dtls_set_timeouts(session, 1 * 1000, 30 * 1000); [3.4.10]
> gnutls_dtls_set_timeouts(session, 1 * 1000, 29 * 1000);
>  
>  [e6dcb14dbbd3e9e40a1f193a7bf6657e82b88cb9]
> *always* fails on kfreebsd-amd64.

Then the issue may have been different that what was initially thought.
It would be nice to have some debugging output of the failed test
(e.g., run with -v). Is that a 32-bit system? I'm wondering whether it
relates to the undefined behavior fixes.

regards,
Nikos