Bug#819774: Typo in description: witch

[Egmont Koblinger]

Package: cowsay-off
Version: 3.03+dfsg1-15

Package description says:
This package contains cows witch some may consider to be offensive.

Should be s/witch/which/

Bug#819775: cmake: Should build-depend on cvs for cvs tests

[Samuel Thibault]

Package: cmake
Version: 3.5.0-1
Severity: normal

Hello,

The cmake testsuite includes some cvs tests, so cmake should
build-depend on cvs so as to run those tests too.

Samuel

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

Kernel: Linux 4.5.0 (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 cmake depends on:
ii  cmake-data3.5.0-1
ii  dpkg  1.18.4
ii  libarchive13  3.1.2-11+b1
ii  libc6 2.22-4
ii  libcurl3  7.47.0-1
ii  libexpat1 2.1.1-1
ii  libgcc1   1:6-20160109-1
ii  libjsoncpp1   1.6.5-4
ii  libstdc++66-20160109-1
ii  procps2:3.3.11-3
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages cmake recommends:
ii  gcc   4:5.3.1-1
ii  make  4.1-9

Versions of packages cmake suggests:
pn  codeblocks   
ii  eclipse  3.8.1-8
pn  ninja-build  

-- no debconf information

-- 
Samuel
 cool, j'ai un rapport a rendre pour le 31 decembre a minuit...
 -+- #ens-mim - bonne année ! -+-

Bug#814600: [Android-tools-devel] Bug#814600: android-tools: B-D on obsolete android-system-dev

[Mattia Rizzolo]

On Mon, Feb 22, 2016 at 04:25:39PM +0100, Hans-Christoph Steiner wrote:
> we're going to be removing this package anyway, so I don't think we need
> to fix it.  And if someone wants to backport it, then android-system-dev
> can be backported too.

if you want to remove this package, why not doing it?

In the meantime, this actually became the last blocker (I hoped the
others partial removals were enough, but they allegedly were not) for
migration of all the android stack to testing, I asked FTP masters if
they are willing to break android-tools by forcing the removal of
android-system-dev.

-- 
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#819397: src:ncurses: Add udeb support to libtinfo5

[Roger Shimizu]

On Sat, Apr 2, 2016 at 3:06 AM, Sven Joachim  wrote:
> On 2016-03-31 19:57 +0900, Roger Shimizu wrote:
>
>> Control: retitle -1 Add udeb support to libtinfo5 and libncurses5
>>
>>
>> Dear Sven,
>>
>> Really appreciate your review and comments!
>> I addressed your concern, and here's patch v2.
>>
>> Changes v2:
>> - add udeb supoort to libncurses5
>
> Care to elaborate why that is needed?  The screen package does not
> depend on libncurses5.

Yes, screen in ftp archive doesn't depend on libncurses5.
But if you build now, it depends more libraries than before.
Here's my result:

 Depends: libc6 (>= 2.15), libncurses5 (>= 6), libpam0g (>= 0.99.7.1),
libtinfo5 (>= 6), libutempter0 (>= 1.1.5)

>> +Package: libtinfo5-udeb
>> +Package-Type: udeb
>> +Section: debian-installer
>> +Architecture: any
>> +Depends: ${shlibs:Depends}, ${misc:Depends}
>> +Description: shared low-level terminfo library for terminal handling - udeb
>> + The ncurses library routines are a terminal-independent method of
>> + updating character screens with reasonable optimization.
>> + .
>> + This package contains the stripped-down udeb version of shared low-level
>> + terminfo library.
>
> Minor nitpick: you may want to add a "Priority: extra" line, otherwise
> the udebs inherit the priority from the source package (i.e. required).

Fixed in v3.

>> index e1f67dc..063495c 100755
>> --- a/debian/rules
>> +++ b/debian/rules
>> @@ -471,8 +471,8 @@ endif
>>   dh_compress -s -N$(package-examples)
>>   dh_fixperms -s
>>   dh_link -s
>> - dh_makeshlibs -p$(package-ti) -V "$(package-ti) $(sodepver)" -- -c4
>> - dh_makeshlibs -p$(package-lib) -V "$(package-lib) $(sodepver)" -- -c4
>> + dh_makeshlibs -p$(package-ti) -V "$(package-ti) $(sodepver)" 
>> --add-udeb=$(package-ti)-udeb -- -c4
>> + dh_makeshlibs -p$(package-lib) -V "$(package-lib) $(sodepver)" 
>> --add-udeb=$(package-ti)-udeb -- -c4
>
> Surely the last line should read "…--add-udeb=$(package-lib)-udeb…"
> instead?

Thanks for pointing out!
And here goes the patch v3.

Changes v2:
 - add udeb supoort to libncurses5
Changes v3:
 - add "Priority: extra" to udeb in debian/control
 - fix typo when calling dh_makeshlibs

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1
From c3a9246635351ebf2aead211ce35a0c9b841c372 Mon Sep 17 00:00:00 2001
From: Roger Shimizu 
Date: Sun, 27 Mar 2016 23:15:51 +0900
Subject: [PATCH] Add udeb support to libtinfo5 and libncurses5

---
 debian/changelog|  7 +++
 debian/control  | 26 ++
 debian/libncurses5-udeb.install |  4 
 debian/libtinfo5-udeb.install   |  2 ++
 debian/rules|  4 ++--
 5 files changed, 41 insertions(+), 2 deletions(-)
 create mode 100644 debian/libncurses5-udeb.install
 create mode 100644 debian/libtinfo5-udeb.install

diff --git a/debian/changelog b/debian/changelog
index a02785a..55ea615 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ncurses (6.0+20160319-2) UNRELEASED; urgency=medium
+
+  [ Roger Shimizu ]
+  * Add udeb support to libtinfo5 and libncurses5
+
+ -- Roger Shimizu   Sat, 26 Mar 2016 18:22:36 +0900
+
 ncurses (6.0+20160319-1) unstable; urgency=medium
 
   * New upstream patchlevel.
diff --git a/debian/control b/debian/control
index a740fa2..8b8509b 100644
--- a/debian/control
+++ b/debian/control
@@ -27,6 +27,19 @@ Description: shared low-level terminfo library for terminal handling
  .
  This package contains the shared low-level terminfo library.
 
+Package: libtinfo5-udeb
+Package-Type: udeb
+Section: debian-installer
+Architecture: any
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}
+Description: shared low-level terminfo library for terminal handling - udeb
+ The ncurses library routines are a terminal-independent method of
+ updating character screens with reasonable optimization.
+ .
+ This package contains the stripped-down udeb version of shared low-level
+ terminfo library.
+
 Package: libncurses5
 Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
@@ -40,6 +53,19 @@ Description: shared libraries for terminal handling
  This package contains the shared libraries necessary to run programs
  compiled with ncurses.
 
+Package: libncurses5-udeb
+Package-Type: udeb
+Section: debian-installer
+Architecture: any
+Priority: extra
+Depends: libtinfo5-udeb (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
+Description: shared libraries for terminal handling -udeb
+ The ncurses library routines are a terminal-independent method of
+ updating character screens with reasonable optimization.
+ .
+ This package contains the stripped-down udeb version of shared libraries
+ necessary to run programs compiled with ncurses.
+
 Package: libtinfo-dev
 Architecture: any
 Section: libdevel
diff --git a/debian/libncurses5-udeb.install b/debian/libncurses5-udeb.install
new file mode 100644
index 000..162fb52
--- /dev/null
+++ b/debian/libncurses5-udeb.install
@@ -0,0 +1,4 @@
+usr/

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Peter Nowee]

On Fri, Apr 01, 2016 at 10:37:35PM -0700, Jamie Zawinski wrote:
> Peter Nowee wrote:
>
> > Was I wrong when I said that you value user freedom above your wish
> > that we either keep the warning or remove your software from Debian?
>
> Awesome, you seem to be one of those people who think "if it's legal,
> it must be right." That's a common toxin in the software industry
> these days.
>
> I guess you want Debian to be the kind of operation that uses the
> work of others while blatantly and explicitly ignoring the wishes of
> the person who *did the actual creative work*.

No and no.

You called this upon yourself when you put in that time bomb.

With regard to stable/jessie, I propose we use our rights, but try to 
make up for ignoring your wishes by trying to reduce the flow of bug 
reports to you in another way, for example by the additional URL in the
About box I suggested by my earlier email. Please reconsider.

With regard to future versions of Debian, again I think you should be 
more clear in your license terms. Don't pretend to publish it as free 
software, but then use pretty "please", time bombs and cursing to get
users to not use their freedoms.


signature.asc
Description: Digital signature

Bug#819773: RFS: python-path-and-address/1.0.0-1 [ITP]

[Tiago Ilieve]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-pyt...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "python-path-and-address"

* Package name: python-path-and-address
  Version : 1.0.0-1
  Upstream Author : Joe Esposito 
* URL : https://github.com/joeyespo/path-and-address
* License : MIT
  Section : python

It builds those binary packages:

  python-path-and-address - Functions for server CLI applications used
by humans. (Python 2)
  python3-path-and-address - Functions for server CLI applications
used by humans. (Python 3)

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

http://mentors.debian.net/package/python-path-and-address

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

dget -x 
http://mentors.debian.net/debian/pool/main/p/python-path-and-address/python-path-and-address_1.0.0-1.dsc

-

This package is a dependency of Grip[1], which is also being packaged
(ITP bug #790611[2]).

Regards,
Tiago.

[1]: https://github.com/joeyespo/grip
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790611

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#819772: /var/lib/dkms/fglrx/15.9/build/firegl_public.c:6516:49: error: 'XSTATE_FP' undeclared

[Rudolf Dovičín]

Package: fglrx-modules-dkms
Version: 1:15.9-4~deb8u1
Severity: grave
Justification: renders package unusable


-- Package-specific info:
Full fglrx package list:
ii  fglrx-atieventsd  1:15.9-4~deb8u1   amd64   
  events daemon for the non-free ATI/AMD RadeonHD display driver
ii  fglrx-control 1:15.9-4~deb8u1   amd64   
  control panel for the non-free ATI/AMD RadeonHD display driver
ii  fglrx-driver  1:15.9-4~deb8u1   amd64   
  non-free ATI/AMD RadeonHD display driver
ii  fglrx-modules-dkms1:15.9-4~deb8u1   amd64   
  dkms module source for the non-free ATI/AMD RadeonHD display 
driver
ii  glx-alternative-fglrx 0.7.2 amd64   
  allows the selection of FGLRX as GLX provider
ii  libfglrx:amd641:15.9-4~deb8u1   amd64   
  non-free ATI/AMD RadeonHD display driver (runtime libraries)
ii  libfglrx-amdxvba1:amd64   1:15.9-4~deb8u1   amd64   
  AMD XvBA (X-Video Bitstream Acceleration) backend for VA API
ii  libgl1-fglrx-glx:amd641:15.9-4~deb8u1   amd64   
  proprietary libGL for the non-free ATI/AMD RadeonHD display 
driver

VGA-compatible devices on PCI bus:
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Kaveri [Radeon R6/R7 Graphics] [1002:1309] (prog-if 00 [VGA 
controller])
Subsystem: Lenovo Kaveri [Radeon R6/R7 Graphics] [17aa:3830]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel modules: radeon

DRM and fglrx Informations from dmesg:
[0.811552] Linux agpgart interface v0.103

Bug script output from package glx-alternative-fglrx:
Diversions:
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/libGL

Bug#819760: [Letsencrypt-devel] Bug#819760: Bug#819760: acme-tiny: Please install README

[Mattia Rizzolo]

On Fri, Apr 01, 2016 at 08:55:49PM -0300, Jeremías Casteglione wrote:
> Can someone from the team upload the -4 version please? I've not
> such rights. Thanks!

Uploaded :)

-- 
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#819387: pidgin: system tray icon missing on KDE 4:15.08

[Chip Rosenthal]

The problem is resolved for me by installing the plasma-systray-legacy 
package. Perhaps this could be mentioned in a README.Debian?


--
Chip Rosenthal * 512-573-5174 * KE5VHV * http://www.unicom.com/

Bug#819703: In case you remove xscreensaver from future distributions

[Jamil Said Jr .]

In case you decide to remove xscreensaver from future Debian distributions,
I have a suggestion:

On whatever substitutes xscreensaver, I would like to suggest that you
include the option to turn the screen "blank" in addition to "turn screen
off" when the screensaver kicks in. Some screensavers just turn the screen
off, and upon restart of the screen, some hardware crashes (sometimes
intermittently) and renders the computer unusable. I've seen quite a bit of
that.

Also, I want to point out that I am very in favor of eliminating this rude &
disruptive "warning" ASAP from stable and all other Debian branches. If you
release code with a free, open source license, you must understand and be
prepared that your code may be modified and used as other users see fit.

Cheers,
Jamil

Bug#819771: missing php5-imagick on stretch, php-imagick does not support PHP 5

[Yang Yu]

Package: 
Version: <3.4.0-1>

downstream kali-rolling follows Debian testing, it appears there's no
imagick package for php5

On stretch
1) There is no php5-imagick package
dep: php5-common (<< 7.0.0) [not sh4], dep: php5-common (>= 5.1.3) [not sh4]

2) There is a php-imagick package but the description is incorrect
"This extension requires ImageMagick version 6.2.4+ and PHP 5.1.3+."
however dep: php-common (>= 1:7.0+33~)

I wonder why php5-imagick is missing from stretch. Have most PECL
packages been built for php7 on stretch? Thanks


Yang

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Jamie Zawinski]

Peter Nowee wrote:

> Was I wrong when I said that you value user freedom above your wish
> that we either keep the warning or remove your software from Debian?

Awesome, you seem to be one of those people who think "if it's legal, it must 
be right." That's a common toxin in the software industry these days.

I guess you want Debian to be the kind of operation that uses the work of 
others while blatantly and explicitly ignoring the wishes of the person who 
*did the actual creative work*.

Nice. 

--
Jamie Zawinski  https://www.jwz.org/  https://www.dnalounge.com/

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Peter Nowee]

On Fri, Apr 01, 2016 at 09:04:45PM -0700, Jamie Zawinski wrote:
> Please remove XScreenSaver from Debian.
> 
> Peter Nowee, please take your sanctimony and go fuck yourself with it.
> 

Was I wrong when I said that you value user freedom above your wish
that we either keep the warning or remove your software from Debian?

I mean, you are the one giving mixed signals here: First telling us we
can use, modify and distribute your work, then asking us to "please"
not modify this and "please" not distribute that.

Just change your license if this is really as important to you as your
cursing suggests.


signature.asc
Description: Digital signature

Bug#819343: ITP: r-cran-dplyr -- A Grammar of Data Manipulation for GNU R

[Andreas Tille]

Hi again,

On Fri, Apr 01, 2016 at 07:51:23AM +0200, Andreas Tille wrote:
> > > > [1] 
> > > > svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-dplyr/trunk/
> > > 
> > > One of these decades I'll have to learn how to use VCSes for
> > > packaging. 
> > 
> > I'd recommend using Git in this case since there seem to be a tendency
> > inside Debian into this direction.  While you can see from the URL above
> > I started in SVN.  The rationale is that R packaging is in most cases
> > simple enough that we keep only the debian/ dir which is in line with
> > the usual workflow in SVN while the typical workflow in Git is to store
> > upstream source and packaging in one repository.
> > 
> > Since I think r-cran-dplyr would be sensible inside the Debian Science
> > team you can read how to do it in the Debian Science policy document[2].
> > I would volunteer to inject your packaging into Debian Science Git if
> > this would help you in the beginning.  If you want me to do this simply
> > put somewhere online to enable me downloading it (while it resides in
> > new).
> 
> I noticed that r-cran-dplyr is not listed in the new queue any more but
> is also not in Debian.  Just let us know if you need any help with this
> package.  I'd also volunteer to commit your work to Debian Science VCS
> if you would make it somehow available for the public.
> 
> I have an urgent interest to get this package into Debian quickly.

I have read[1] that r-cran-dplyr was rejected by ftpmaster with:

   Hi Chris,

   this package as the missing-R-data-description as well.

Thorsten

I assume that ftpmaster is refering to data/nasa.rda.  I would happily
help with finalising the package (and can confirm that I have
successfully written).  I have commited a file debian/README.source to
my version of the packaging in Debian Med SVN[2] (which is ready for
upload).  Please let me know what way you would prefer:

   1. You make your packaging available somehow and I migrate it to
  Debian Science Git.
   2. I move my packaging from Debian Med SVN[2] to Debian Science Git
  and add you as Uploader.

It would be simply great if you could confirm that it is OK for you if
the ITP could be closed by the Debian Science team (alternatively the
Debian Med team).  I'd simply interested to push the package as quickly
as possible and thus I would like to help as best as possible - if you
confirm also by simply uploading what I have prepared in SVN.

Kind regards

   Andreas.

[1] 
coccia.debian.org:/srv/ftp-master.debian.org/queue/new/COMMENTS/REJECTED.r-cran-dplyr_0.4.3-1_amd64
[2] svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-dplyr/trunk/

-- 
http://fam-tille.de

Bug#819722: RM: xfce4-artwork -- ROM; obsolete, unmaintained upstream

[Scott Kitterman]

On Fri, 01 Apr 2016 14:52:06 +0200 Yves-Alexis Perez  
wrote:
> Package: ftp.debian.org
> Severity: normal
> Owner: pkg-xfce-de...@lists.alioth.debian.org
> 
> Hi,
> 
> xfce4-artwork is an old (and unmaintained) package containing artwork
> for the Xfce environment. I don't think it make sense to keep it in the
> archive anymore, can you please remove it?

Checking reverse dependencies...
# Broken Depends:
xfce4-goodies: xfce4-goodies

Needs to be removed from xfce4-goodies first.

Please remove the moreinfo tag when that's been addressed.

Scott K

Bug#819026: RM: fonts-mgopen -- ROM; obsolete, abandoned upstream

[Scott Kitterman]

On Wed, 23 Mar 2016 03:36:33 +0200 Faidon Liambotis  
wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> The MgOpen fonts were released by Magenta, a Greek company, back in
> 2005.  At the time finding freely-licensed fonts covering Greek glyphs
> was hard (DejaVu added the Greek basic alphabet in 2006), so I uploaded
> this package in Debian at the time and moved it under the Debian Fonts
> Task Force after a few years, where it has been comaintained since.
> 
> In the meantime, the freely-licensed font ecosystem has bloomed and
> nowadays there are multiple different choices for commodity uses of
> Greek glyphs (DejaVu, Liberation, Droid, Robot/Noto, CrOS etc.). 
> 
> MgOpen suffers from several long-standing issues (such as the lack of
> hinting, #540206), some of which make it completely unsuitable for
> today's use (such as the lack of the Euro sign).
> 
> The font has only seen a couple of releases, the last one being more
> than a decade ago; it has been seemingly abandoned by its upstream. It
> was wasn't that good to begin with, so noone has stepped up to maintain
> it and enhance it and I'm pretty sure noone will given the breadth of
> choices nowadays.
> 
> Please remove it from the archive: it's a small maintenance burden but
> at this point it does more harm than good by confusing potential users.

It has one rdepend that will have to be switched to use something else first:

Checking reverse dependencies...
# Broken Depends:
fretsonfire: fretsonfire-game

Dependency problem found.

Please remove the moreinfo tag once that has been addressed.

Scott K

Bug#818998: RM: zeromq -- RoQA; old, superseeded by zeromq3

[Scott Kitterman]

On Tue, 22 Mar 2016 18:02:03 +0100 Emilio Pozuelo Monfort  
wrote:
> Package: ftp.debian.org
> Severity: normal
> Control: block -1 by 818222
> 
> Hi,
> 
> zeromq is superseeded by zeromq3. There's only one rdep left, so
> this can be removed as soon as that is fixed.

There's actually more than that:

Checking reverse dependencies...
# Broken Depends:
libzeromq-perl: libzeromq-perl [amd64 arm64 armel armhf i386 mips mips64el 
mipsel powerpc ppc64el s390x]

# Broken Build-Depends:
gr-air-modes: libzmq-dev
libzeromq-perl: libzmq-dev

Dependency problem found.

Please remove the moreinfo tag once they have all been addressed.

Scott K

Bug#818848: RM: gccxml -- ROM; Cannot build with GCC 5; replaced by castxml

[Scott Kitterman]

On Sun, 20 Mar 2016 20:26:31 -0500 "Steve M. Robbins"  wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> GCCXML is obsolete, replaced by castxml.  Furthermore, it cannot be
> built by GCC 5 and GCC 4.9 is being removed from the archive
> (c.f. #818773).

As usual, rdepends need to be addressed first:

Checking reverse dependencies...
# Broken Depends:
cableswig: cableswig
pygccxml: python-pygccxml
python-ctypeslib: python-ctypeslib

# Broken Build-Depends:
cableswig: gccxml
insighttoolkit: gccxml (>= 0.9.0+cvs20110723)
pygccxml: gccxml
pyplusplus: gccxml
python-ctypeslib: gccxml

Dependency problem found.

Please remove the moreinfo tag once they have been addressed.

Scott K

Bug#818063: python-pysam: reduce the RM architecture list and bump severity

[Scott Kitterman]

On Thu, 31 Mar 2016 12:01:12 -0700 Afif Elghraoui  wrote:
> Control: retitle -1 RM: python-pysam [i386] -- ROM; BD-uninstallable
> Control: severity -1 important
> 
> The package has recently been able to build for arm64, armel, and
> ppc64el, but still cannot build on i386.
> 
> I would appreciate removal from unstable of the old i386 version in
> order to allow testing migration. Autoremovals of its
> reverse-dependencies are coming up within a week or so. In addition to
> that, I would like to update the version of pysam in jessie-backports
> and I cannot do that without it first migrating to testing.

This removal would make fitgcp uninstallable.  If it really can't be fixed, 
then 
file a separate bug requesting removal of fitgcp on the relevant archs (which 
are actually i386, kfreebsd-i386, and mips64el.

fitgcp | 0.0.20130418-2 | sid | source, amd64, arm64, armel, hurd-
i386, i386, kfreebsd-amd64, kfreebsd-i386, mips64el, mipsel, ppc64el

Please remove the moreinfo tag once this is resolved on way or another.

Scott K

Bug#819387: pidgin: system tray icon missing on KDE 4:15.08

[Chip Rosenthal]

This may be a duplicate of bug #793130

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Jamie Zawinski]

Please remove XScreenSaver from Debian.

Peter Nowee, please take your sanctimony and go fuck yourself with it.

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Holger Levsen]

Hi,

On Sat, Apr 02, 2016 at 05:33:52AM +0200, Adam Borowski wrote:
> > (Also for fixing this in stable it needs to be fixed / not be present in
> > unstable first.)
> Why? 

because that's the usual policy for fixing issues in stable, which was
also confirmed for this particular issue by a SRM on #debian-release
today.

> [...] it looks
> like removal is more likely to happen than forking, so the problem might
> be never fixed in unstable.

Removing the package from unstable will cause the bug not be present in
unstable so that's an ok solution from the POV of getting it fixed in
stable.
 
> The timebomb was introduced in 5.21, oldstable has 5.15, o-o-stable 5.11, so
> neither is affected.

Thanks for the clarification. (Also for checking when it will hit 5.34!)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#819770: transition: bind9

[Michael Gilbert]

package: release.debian.org
user: release.debian@packages.debian.org
usertags: transition
severity: normal
x-debbugs-cc: lam...@debian.org

Hi,

I would like to request a transition for bind9.  Here is the status of the
reverse build dependencies:

bind-dyndb-ldap: a new version is staged in experimental.
isc-dhcp: a new version is staged in experimental.
libnss-lwres: no source changes are needed, will need a binnmu

Ben file:

title = "bind9";
is_affected = .build-depends ~ "libbind-dev" | .build-depends ~
"libbind-export-dev";
is_good = .depends ~
/\b(libbind9\-140|libdns\-export162|libdns\-export162\-udeb|libdns162|libirs\-export141|libirs\-export141\-udeb|libirs141|libisc\-export160|libisc\-export160\-udeb|libisc160|libisccc\-export140|libisccc\-export140\-udeb|libisccc140|libisccfg\-export140|libisccfg\-export140\-udeb|libisccfg140|liblwres141)\b/;
is_bad = .depends ~
/\b(libbind9\-90|libdns\-export100|libdns\-export100\-udeb|libdns100|libirs\-export91|libirs\-export91\-udeb|libisc\-export95|libisc\-export95\-udeb|libisc95|libisccc90|libisccfg\-export90|libisccfg\-export90\-udeb|libisccfg90|liblwres90)\b/;

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Peter Nowee]

I do not agree with the removal of the xscreensaver package.

Thankfully, when writing down his wish regarding this particular piece
of code, the author made sure to write that he did not mean to derogate
the user freedoms provided by the license he chose:

> Of course, my license allows you to ignore me and do whatever the
> fuck you want, but as the author, I hope you will have the common
> courtesy of complying with my request.

He just confirmed to us that he still stands by those words as well.

So, in the end, he values user freedom above his wish that we either
keep the warning or remove the software from our distribution. This
deserves our respect and gratitude.

Considering the issue at hand, I think we should exercise that user 
freedom now by disabling the warning while keeping the software in our 
distribution. For jessie/stable I think there is even no other choice.  

At the same time, we could try to make up for not having the "common
courtesy" he expected from us. For example, we could mention "Bug
reports:" with a Debian URL above his URL in the About dialog. I think
this would greatly reduce the number of bug reports on old versions
directed to him, which he named as the main reason behind his original
wish.

I hope this policy can then be extended to keep xscreensaver in future
Debian releases as well.


signature.asc
Description: Digital signature

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Adam Borowski]

On Fri, Apr 01, 2016 at 11:04:28PM -0400, Holger Levsen wrote:
> On Sat, Apr 02, 2016 at 02:53:30AM +, Daniel Shahaf wrote:
> > Control: notfound -1 5.34-1
> 
> the bug is present in that version. The timebomb just hasn't been triggered
> yet.

For the record, the timebomb for 5.34 will go off on 2017-04-01, ie, shortly
after stretch's expected release date.

> (Also for fixing this in stable it needs to be fixed / not be present in
> unstable first.)

Why?  The fix is a trivial technical matter (Daniel's one-line patch in the
very first mail) and no one questions what to do for stable.

It's the political issue in unstable what needs deliberation.  And it looks
like removal is more likely to happen than forking, so the problem might
be never fixed in unstable.

> and oldstable

The timebomb was introduced in 5.21, oldstable has 5.15, o-o-stable 5.11, so
neither is affected.


-- 
A tit a day keeps the vet away.

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Daniel Shahaf]

Control: found -1 5.34-1

Holger Levsen wrote on Fri, Apr 01, 2016 at 23:04:28 -0400:
> Hi,
> 
> On Sat, Apr 02, 2016 at 02:53:30AM +, Daniel Shahaf wrote:
> > Control: notfound -1 5.34-1
> 
> the bug is present in that version. The timebomb just hasn't been triggered
> yet.

Okay; metadata restored.  (I had removed it because I had only confirmed
5.34-1 was affected by code inspection, as opposed to compiling/running
it and observing the message being displayed.)

Thanks,

Daniel

Bug#819618: openjdk-8-source: "source" package is empty (does not contain src.zip anymore)

[Ben Caradoc-Davies]

Chris,

looks like this just got fixed in 8u77-b03-3.

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Holger Levsen]

Hi,

On Sat, Apr 02, 2016 at 02:53:30AM +, Daniel Shahaf wrote:
> Control: notfound -1 5.34-1

the bug is present in that version. The timebomb just hasn't been triggered
yet.

(Also for fixing this in stable (and oldstable) it needs to be fixed / not be
present in unstable first.)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Daniel Shahaf]

Control: found -1 5.30-1+deb8u1
Control: notfound -1 5.34-1

Axel Beckert wrote on Fri, Apr 01, 2016 at 09:54:39 +0200:
> Daniel Shahaf wrote:
> > P.S. I'm reporting this against the version in stable/jessie,
> 
> Sorry, you didn't. I've added the version (initially) in Jessie now.

Good catch, thank you.  I observed the prompts in the jessie-security
version but did not test the sid version; metadata updated accordingly.

> > diff --git a/driver/prefs.c b/driver/prefs.c
> > index 55bac7b..f9f96c3 100644
> > --- a/driver/prefs.c
> > +++ b/driver/prefs.c
> > @@ -1663,6 +1663,8 @@ stop_the_insanity (saver_preferences *p)
> >  Bool
> >  senescent_p (void)
> >  {
> > +  return 0;
> > +
> >/* If you are in here because you're planning on disabling this warning
> >   before redistributing my software, please don't.
> 
> That doesn't fix the XFCE menu warning, too, right?

For future reference, this patch eliminates both of the prompts the
original report mentions.  (senescent_p() must return true for any of
the warnings to be displayed.)

To clarify: I'm simply stating a technical fact about the patch; I'm not
advocating one way or the other regarding whether the package should be
removed from stretch, since that's a political issue, as opposed
a technical one.  (jwz: the package cannot be removed from jessie and
earlier; it can only be removed from stretch and later.)

That said, for what it's worth, I think it would be unfortunate if the
package is removed from stretch: I run stable, it's a tradeoff
I consciously made, and there is no reason for me to be barred from
using software written by people who use their computers differently
than I do.

Cheers,

Daniel
(I wonder if I would be able to continue using unicode-screensaver under
light-locker, should xscreensaver be removed...)

Bug#819769: ITP: code-maat -- Command line tool used to mine and analyze data from version-control systems

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: "ChangZhuo Chen (陳昌倬)" 

* Package name: code-maat
  Version : 0.9.1
  Upstream Author : Adam Tornhill
* URL : https://github.com/adamtornhill/code-maat
* License : GPL-3
  Programming Lang: Clojure
  Description : Command line tool used to mine and analyze data from 
version-control systems

 Code Maat is a command line tool used to mine and analyze data from
 version-control systems (VCS).

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D
  BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#819768: xfonts-terminus: please consider applying upstream's patch for a vertically centered tilde

[Sean Whitton]

Package: xfonts-terminus
Version: 4.39-1
Severity: wishlist

Dear maintainer,

Please consider applying upstream's patch td1.diff for a
vertically centered tilde in Terminus.  Per the upstream feature request [1],
upstream considers this a "most common form" for the tilde character.

Thanks.

[1] https://sourceforge.net/p/terminus-font/feature-requests/2/

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

Kernel: Linux 4.4.0-1-686-pae (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 xfonts-terminus depends on:
ii  xfonts-utils  1:7.7+3

xfonts-terminus recommends no packages.

Versions of packages xfonts-terminus suggests:
ii  xfonts-terminus-oblique  4.39-1
ii  xserver-xorg [xserver]   1:7.7+14

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#819701: Patch

[gregor herrmann]

On Fri, 01 Apr 2016 17:42:37 -0700, Sean Whitton wrote:

> And here's a (trivial) patch.  So far as I can tell this is the only
> place a change is required.

Thanks for providing a patch!

I came to the same conclusion earlier today but was a bit reluctant
because the change is not covered in the test suite; and adding it
there seems less trivial.

But I guess we can live with that ... unless someone can quickly come
up with an extension of the test suite.


Side note:

> diff --git a/debian/changelog b/debian/changelog
> index 061f412..0af61b7 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -35,7 +35,10 @@ dh-make-perl (0.90-1) UNRELEASED; urgency=medium
>  options. They add (build) dependencies to the automatically found
>  packages since 0.49. (Cf. #813766)
>  
> - -- gregor herrmann   Thu, 01 Oct 2015 23:42:59 +0200
> +  [ Sean Whitton ]
> +  * Add Built-Using: to recognised binary package stanza fields.
> +
> + -- Sean Whitton   Fri, 01 Apr 2016 17:33:27 -0700
>  
>  dh-make-perl (0.89-1) unstable; urgency=medium
>  

A git pull before creating the patch wouldn't have hurt :)
(That's not the state of d/changelog in master.)


I've now comitted and pushed your patch; thanks again.


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: John Lee Hooker: Tupelo


signature.asc
Description: Digital Signature

Bug#819136: Patch updates

[Elliott Mitchell]

Just found I'd goofed in the last revision.  Updated patches
demonstrating my request attached.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445


>From 558c9c2069bc381609b0fa8184ff4d0217d3d667 Mon Sep 17 00:00:00 2001
From: Elliott Mitchell 
Date: Thu, 31 Mar 2016 17:40:07 -0700
Subject: [PATCH 02/10] Introduce variables for many magic constants

Introduce variables for many of the likely to change magic constants.
Notably the version of the upstream firmware tarball, the exact filename
within the tarball, and the base URL for upstream.

Take advantage of the object file name (${WL_APSTA}) to only extract the
relevant object file from the upstream tarball.  This potentially saves a
lot of storage space during extraction, fixes bug #819129.
---
 debian/firmware-b43-installer.postinst |   34 +---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/debian/firmware-b43-installer.postinst b/debian/firmware-b43-installer.postinst
index ed95591..c8d307f 100644
--- a/debian/firmware-b43-installer.postinst
+++ b/debian/firmware-b43-installer.postinst
@@ -1,15 +1,36 @@
 #!/bin/sh
 
+#
+#$Id$	#
+#
+
+VERSION="5.100.138"
+
+BROADCOM_WL="broadcom-wl-${VERSION}"
+
+WL_APSTA="${BROADCOM_WL}/linux/wl_apsta.o"
+
+TARBALL="${BROADCOM_WL}.tar.bz2"
+
+URL="http://www.lwfinger.com/b43-firmware/${TARBALL}";
+
+FIRMWARE_INSTALL_DIR="/lib/firmware"
+
+#
+# stable sections below, not updated for firmware updates		#
+#
+
 set -e
 
 . /usr/share/debconf/confmodule
 
-tmp=`mktemp -q -d`
-
 latest_firmware ()
 {
+umask 027
+
+tmp=`mktemp -q -d`
+
 cd $tmp
-export FIRMWARE_INSTALL_DIR="/lib/firmware"
 
 # use apt proxy
 APT_PROXIES=$(apt-config shell \
@@ -22,12 +43,11 @@ if [ -n "$APT_PROXIES" ]; then
 eval export $APT_PROXIES
 fi
 
-if ! wget --timeout=60 http://www.lwfinger.com/b43-firmware/broadcom-wl-5.100.138.tar.bz2 ; then
+if ! wget --timeout=60 "${URL}"; then
 	echo "Some problem occurred during the firmware download. Please check your internet connection." 
 	exit 0
 fi
-tar xvjf broadcom-wl-5.100.138.tar.bz2
-cd broadcom-wl-5.100.138/linux
+tar xvjf "${TARBALL}" "${WL_APSTA}"
 if [ -d "${FIRMWARE_INSTALL_DIR}/b43" ]; then
 	echo "Deleting old extracted firmware..."
 	xargs -r -0 -a "${FIRMWARE_INSTALL_DIR}/b43/firmware-b43-installer.catalog" dpkg-query -S 2>&1 1>/dev/null | sed -es',[^/]\+,,' | xargs -r rm --
@@ -36,7 +56,7 @@ fi
 mkdir "${FIRMWARE_INSTALL_DIR}/b43" || true
 catalog="${FIRMWARE_INSTALL_DIR}/b43/firmware-b43-installer.catalog"
 retcode=0
-b43-fwcutter -w "${FIRMWARE_INSTALL_DIR}" wl_apsta.o | while read line
+b43-fwcutter -w "${FIRMWARE_INSTALL_DIR}" "${WL_APSTA}" | while read line
 do	echo "${line}"
 	file="${line#Extracting }"
 	if [ "${file}" != "${line}" ]
-- 
1.7.10.4

>From a41cc81f1b2158e4a2b69c43976e71e5817ddfeb Mon Sep 17 00:00:00 2001
From: Elliott Mitchell 
Date: Thu, 31 Mar 2016 17:45:32 -0700
Subject: [PATCH 03/10] Need to get out of temporary directory before removal

...otherwise the removal WILL fail (minor, unreported bug).  Also
implement targeted cleaning that should get rid of all the intermediate
files without the sledgehammer of `rm -rf`.
---
 debian/firmware-b43-installer.postinst |9 +
 1 file changed, 9 insertions(+)

diff --git a/debian/firmware-b43-installer.postinst b/debian/firmware-b43-installer.postinst
index c8d307f..1cc0ccc 100644
--- a/debian/firmware-b43-installer.postinst
+++ b/debian/firmware-b43-installer.postinst
@@ -72,6 +72,15 @@ do	echo "${line}"
 		fi
 	fi
 done
+
+rm "${TARBALL}" "${WL_APSTA}"
+rm -rf "${BROADCOM_WL}"
+
+# otherwise can't delete things
+cd /
+
+rmdir $tmp || echo "$0: DEBUG: targeted cleaning failed" 1>&2
+
 rm -rf $tmp
 [ ${retcode} -eq 0 ] || exit ${retcode}
 }
-- 
1.7.10.4

>From 715a201d7c0d0a9b02a232dc320535c85b7e28b5 Mon Sep 17 00:00:00 2001
From: Elliott Mitchell 
Date: Thu, 31 Mar 2016 17:50:17 -0700
Subject: [PATCH 04/10] Check return codes of all commands, flag errors better

Errors on various commands were being ignored.  Notably failures by
`wget` wouldn't tell `dpkg` that installation had failed.  Other commands
weren't explicitly checked or flagged.  The report of this accidentally
ended up attached to bug #756664.
---
 debian/firmware-b43-installer.postinst |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/debian/firmware-b43-installer.postinst b/debian/firmware-b43-installer.postinst
index 1cc0ccc..8e09ea7 100644
--- a/debian/firmwa

Bug#819705: firmware-b43-installer: Brittle handling of /lib/firmware/b43, can readily conflict with other packages, improper removal during *postrm*

[Elliott Mitchell]

Sigh, the bugs always appear just /after/ you've sent things.  The
removal method was halfway between the two approaches I'd tried.  The
attached version of the patch should actually work.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445


>From bfd679cbe47b705e0c0b0a7d3034d65906a94460 Mon Sep 17 00:00:00 2001
From: Elliott Mitchell 
Date: Thu, 31 Mar 2016 17:33:23 -0700
Subject: [PATCH 01/10] Implement catalog of firmware files installed

This allows for targeted removal of downloaded firmware files, instead of
needing to remove the whole directory.  Also pass paths to be removed
through `dpkg-query -S`, increasing safety of removals.  This is much
safer and allows for other features.
---
 debian/firmware-b43-installer.postinst |   33 +---
 debian/firmware-b43-installer.postrm   |   15 ---
 debian/firmware-b43-installer.prerm|   28 +++
 3 files changed, 54 insertions(+), 22 deletions(-)
 delete mode 100644 debian/firmware-b43-installer.postrm
 create mode 100644 debian/firmware-b43-installer.prerm

diff --git a/debian/firmware-b43-installer.postinst b/debian/firmware-b43-installer.postinst
index 0d9c0e1..ed95591 100644
--- a/debian/firmware-b43-installer.postinst
+++ b/debian/firmware-b43-installer.postinst
@@ -25,16 +25,35 @@ fi
 if ! wget --timeout=60 http://www.lwfinger.com/b43-firmware/broadcom-wl-5.100.138.tar.bz2 ; then
 	echo "Some problem occurred during the firmware download. Please check your internet connection." 
 	exit 0
-else
-	if [ -d /lib/firmware/b43 ]; then
-	   echo "Deleting old extracted firmware..."
-	   rm -rf /lib/firmware/b43
-	fi
 fi
 tar xvjf broadcom-wl-5.100.138.tar.bz2
 cd broadcom-wl-5.100.138/linux
-b43-fwcutter -w "$FIRMWARE_INSTALL_DIR" wl_apsta.o
+if [ -d "${FIRMWARE_INSTALL_DIR}/b43" ]; then
+	echo "Deleting old extracted firmware..."
+	xargs -r -0 -a "${FIRMWARE_INSTALL_DIR}/b43/firmware-b43-installer.catalog" dpkg-query -S 2>&1 1>/dev/null | sed -es',[^/]\+,,' | xargs -r rm --
+	rm "${FIRMWARE_INSTALL_DIR}/b43/firmware-b43-installer.catalog"
+fi
+mkdir "${FIRMWARE_INSTALL_DIR}/b43" || true
+catalog="${FIRMWARE_INSTALL_DIR}/b43/firmware-b43-installer.catalog"
+retcode=0
+b43-fwcutter -w "${FIRMWARE_INSTALL_DIR}" wl_apsta.o | while read line
+do	echo "${line}"
+	file="${line#Extracting }"
+	if [ "${file}" != "${line}" ]
+	then	if [ "${retcode}" -ne 0 ]
+		then	rm "${FIRMWARE_INSTALL_DIR}/${file}"
+
+		elif [ -z "${FIRMWARE_INSTALL_DIR}/${file}" ] || \
+		! printf %s/%s\\x00 "${FIRMWARE_INSTALL_DIR}" "${file}" >> "${catalog}"
+		then	echo "$0: Failed during extraction of ${file} from ${WL_APSTA}" 1>&2
+			echo "$0: Warning, manual removal/cleaning of ${FIRMWARE_INSTALL_DIR}/b43 may be needed!" 1>&2
+			rm "${FIRMWARE_INSTALL_DIR}/${file}"
+			retcode=1
+		fi
+	fi
+done
 rm -rf $tmp
+[ ${retcode} -eq 0 ] || exit ${retcode}
 }
 
 # check environment
@@ -48,7 +67,7 @@ if [ "$(stat -c %d/%i /)" != "$(stat -Lc %d/%i /proc/1/root 2>/dev/null)" ];
 echo "No chroot environment found. Starting normal installation"
 fi
  
- 
+
 
 
 # check kernel version
diff --git a/debian/firmware-b43-installer.postrm b/debian/firmware-b43-installer.postrm
deleted file mode 100644
index 339d140..000
--- a/debian/firmware-b43-installer.postrm
+++ /dev/null
@@ -1,15 +0,0 @@
-#!/bin/sh
-
-set -e
-
-if [ "$1" = purge ] || [ "$1" = remove ]; then
-
-	if [ -d /lib/firmware/b43 ]; then
-		echo "Deleting old extracted firmware..."
-		rm -rf /lib/firmware/b43/*
-	fi
-fi
-
-#DEBHELPER#
-
-exit 0 
diff --git a/debian/firmware-b43-installer.prerm b/debian/firmware-b43-installer.prerm
new file mode 100644
index 000..e60601f
--- /dev/null
+++ b/debian/firmware-b43-installer.prerm
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+#
+#$Id$	#
+#
+
+FIRMWARE_INSTALL_DIR="/lib/firmware"
+
+#
+# stable sections below, not updated for firmware updates		#
+#
+
+
+set -e
+
+if [ "$1" = purge ] || [ "$1" = remove ]; then
+	if [ -s "${FIRMWARE_INSTALL_DIR}/b43/firmware-b43-installer.catalog" ]; then
+		echo "$0: Deleting installed firmware..." 1>&2
+		xargs -r -0 -a "${FIRMWARE_INSTALL_DIR}/b43/firmware-b43-installer.catalog" dpkg-query -S 2>&1 1>/dev/null | sed -es',[^/]\+,,' | xargs -r rm --
+		rm "${FIRMWARE_INSTALL_DIR}/b43/firmware-b43.catalog"
+		rmdir "${FIRMWARE_INSTALL_DIR}/b43" || exit 0
+	fi
+fi
+
+#DEBHELPER#
+
+exit 0
+
-- 
1.7.10.4

Bug#819752: Please package 1.4.1

[Alexandre Viau]

Hello James,

On 01/04/16 09:09 PM, James McCoy wrote:
> On Fri, Apr 01, 2016 at 04:40:00PM -0400, Alexandre Viau wrote:
>> It'd be really helpful if we could get a bump to 1.4.1.
> 
> Specifically 1.4.1 or just the 1.x series?  1.4.0 is already packaged in
> experimental, but I haven't uploaded it to unstable yet since there are
> reverse dependencies which aren't ready[0] for it.

For my particular case, the most recent you can upload in the 1.x series
will do.

Anything >=1.1 will work.

Thanks,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#819703: LXDE also affected by this

[Jamil Said Jr .]

I meant:

"I plead to you to change the current (and future) xscreensaver versions on
Debian stable to make this "warnings" go away, as soon as possible."

Lol! Cheers,

Jamil Said

Bug#266061: Reason inference for unused removals is confused by ORed/virtual dependencies

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


2004-08-16 16:07 Daniel Burrows:

Package: aptitude
Version: 0.2.15.6-1
Severity: normal

 If I have both aptitude-doc-cs installed automatically and
remove aptitude, no dependency information is shown for aptitude-doc-cs
(which gets garbage-collected), presumably because it was being held
on the system via a virtual dependency.


Upon removal of aptitude (which is forbidden now, but I disabled the
check for testing), this is the explanation given for aptitude-doc-en
(marked for removal, because of "pkg_unused_removed"):

===
aptitude-doc-en (remove, 0.7.8-1) was installed automatically; it is
being removed because all of the packages which depend upon it are being
removed:

 * aptitude (remove, 0.7.8-1) recommends aptitude-doc-en | aptitude-doc
   (provided by aptitude-doc-cs 0.7.8-1, aptitude-doc-en 0.7.8-1,
   aptitude-doc-es 0.7.8-1, aptitude-doc-fi 0.7.8-1, aptitude-doc-fr
   0.7.8-1, aptitude-doc-it 0.7.8-1, aptitude-doc-ja 0.7.8-1,
   aptitude-doc-ru 0.7.8-1)
===

However, for aptitude-doc-cs there is/was no information shown.

I changed the implementation so it also takes into account reverse
dependencies of the virtual packages provided by the package under
inspection (which is "aptitude-doc").

So now this also shows identical information, even when it's through a
virtual package:

===
aptitude-doc-cs (remove, 0.7.8-1) was installed automatically; it is
being removed because all of the packages which depend upon it are being
removed:

 * aptitude (remove, 0.7.8-1) recommends aptitude-doc-en | aptitude-doc
   (provided by aptitude-doc-cs 0.7.8-1, aptitude-doc-en 0.7.8-1,
   aptitude-doc-es 0.7.8-1, aptitude-doc-fi 0.7.8-1, aptitude-doc-fr
   0.7.8-1, aptitude-doc-it 0.7.8-1, aptitude-doc-ja 0.7.8-1,
   aptitude-doc-ru 0.7.8-1)
===


So marking as +pending.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#819752: Please package 1.4.1

[James McCoy]

On Fri, Apr 01, 2016 at 04:40:00PM -0400, Alexandre Viau wrote:
> It'd be really helpful if we could get a bump to 1.4.1.

Specifically 1.4.1 or just the 1.x series?  1.4.0 is already packaged in
experimental, but I haven't uploaded it to unstable yet since there are
reverse dependencies which aren't ready[0] for it.

[0]: https://release.debian.org/transitions/html/msgpack-c.html

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#819733: Lintian: extended description is probably too short

[James McCoy]

On Fri, Apr 01, 2016 at 04:56:30PM +0200, Elimar Riesebieter wrote:
> diff --git a/debian/control b/debian/control
> index db7ab87..89dbdd6 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -76,7 +76,8 @@ Depends: ${misc:Depends}
>  Description: Vi IMproved - HTML documentation
>   Vim is an almost compatible version of the UNIX editor Vi.
>   .
> - This package contains the HTML version of the online documentation.
> + This package contains the HTML version of the online documentation. It is
> + built from the runtime/doc directory from the source tree.

I'm not sure that actually adds much useful information for the user,
but I guess I'll include it to silence Lintian.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#819701: Patch

[Sean Whitton]

control: tag -1 +patch

And here's a (trivial) patch.  So far as I can tell this is the only
place a change is required.

-- 
Sean Whitton
From 1a62884f243e0bf45ae7a644bba5bfe3207c Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Fri, 1 Apr 2016 17:40:48 -0700
Subject: [PATCH] Add Built-Using: to recognised binary package stanza fields

---
 debian/changelog| 5 -
 lib/Debian/Control/Stanza/Binary.pm | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 061f412..0af61b7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -35,7 +35,10 @@ dh-make-perl (0.90-1) UNRELEASED; urgency=medium
 options. They add (build) dependencies to the automatically found
 packages since 0.49. (Cf. #813766)
 
- -- gregor herrmann   Thu, 01 Oct 2015 23:42:59 +0200
+  [ Sean Whitton ]
+  * Add Built-Using: to recognised binary package stanza fields.
+
+ -- Sean Whitton   Fri, 01 Apr 2016 17:33:27 -0700
 
 dh-make-perl (0.89-1) unstable; urgency=medium
 
diff --git a/lib/Debian/Control/Stanza/Binary.pm b/lib/Debian/Control/Stanza/Binary.pm
index 4599ec7..6bd6c4b 100644
--- a/lib/Debian/Control/Stanza/Binary.pm
+++ b/lib/Debian/Control/Stanza/Binary.pm
@@ -93,7 +93,7 @@ use base 'Debian::Control::Stanza';
 
 use constant fields => qw(
 Package Architecture Section Priority Essential Depends Recommends Suggests
-Enhances Replaces Pre_Depends Conflicts Breaks Provides Description
+Enhances Replaces Pre_Depends Conflicts Breaks Provides Built_Using Description
 _short_description _long_description
 );
 
-- 
2.8.0.rc3



signature.asc
Description: PGP signature

Bug#819767: libtool: please make the build reproducible (timestamps, fileordering, hostname, umask)

[rain1]

Source: libtool
Version: 2.4.6
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps fileordering hostname umask
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that libtool could not be built reproducibly.

The attached patch removes extra timestamps from the build system and
ensure a stable file order when creating the source archive as well as 
replacing uses of the `hostname` command with the fixed string 
"localhost". Once applied, libtool can be built reproducibly in our 
current experimental framework.


I also added to rules: dh_strip_nondeterminism -i/-a to the makefile 
before the compress stage.


 [1]: https://wiki.debian.org/ReproducibleBuilds   * deterministic tar archives by sorting by name.

Author: rain1 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 

--- libtool-2.4.6.orig/aclocal.m4
+++ libtool-2.4.6/aclocal.m4
@@ -1104,8 +1104,8 @@ m4_if([$1], [v7],
   # Must skip GNU tar: if it does not support --format= it doesn't create
   # ustar tarball either.
   (tar --version) >/dev/null 2>&1 && continue
-  am__tar='tar chf - "$$tardir"'
-  am__tar_='tar chf - "$tardir"'
+  am__tar='tar --sort=name chf - "$$tardir"'
+  am__tar_='tar --sort=name chf - "$tardir"'
   am__untar='tar xf -'
   ;;
 pax)
@@ -1114,8 +1114,8 @@ m4_if([$1], [v7],
   am__untar='pax -r'
   ;;
 cpio)
-  am__tar='find "$$tardir" -print | cpio -o -H $1 -L'
-  am__tar_='find "$tardir" -print | cpio -o -H $1 -L'
+  am__tar='find "$$tardir" -print | LC_ALL=C sort -z | cpio -o -H $1 -L'
+  am__tar_='find "$tardir" -print | LC_ALL=C sort -z | cpio -o -H $1 -L'
   am__untar='cpio -i -H $1 -d'
   ;;
 none)
--- libtool-2.4.6.orig/libltdl/aclocal.m4
+++ libtool-2.4.6/libltdl/aclocal.m4
@@ -1104,8 +1104,8 @@ m4_if([$1], [v7],
   # Must skip GNU tar: if it does not support --format= it doesn't create
   # ustar tarball either.
   (tar --version) >/dev/null 2>&1 && continue
-  am__tar='tar chf - "$$tardir"'
-  am__tar_='tar chf - "$tardir"'
+  am__tar='tar --sort=name chf - "$$tardir"'
+  am__tar_='tar --sort=name chf - "$tardir"'
   am__untar='tar xf -'
   ;;
 pax)
@@ -1114,8 +1114,8 @@ m4_if([$1], [v7],
   am__untar='pax -r'
   ;;
 cpio)
-  am__tar='find "$$tardir" -print | cpio -o -H $1 -L'
-  am__tar_='find "$tardir" -print | cpio -o -H $1 -L'
+  am__tar='find "$$tardir" -print | LC_ALL=C sort -z | cpio -o -H $1 -L'
+  am__tar_='find "$tardir" -print | LC_ALL=C sort -z | cpio -o -H $1 -L'
   am__untar='cpio -i -H $1 -d'
   ;;
 none)
   * set the hostname to a reproducible dummy value.
Author: rain1 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 

--- libtool-2.4.6.orig/m4/autobuild.m4
+++ libtool-2.4.6/m4/autobuild.m4
@@ -22,7 +22,7 @@ AC_DEFUN([AB_INIT],
   fi
   AC_MSG_NOTICE([autobuild revision... $AB_VERSION])
 
-  hostname=`hostname`
+  hostname="debian"
   if test "$hostname"; then
 AC_MSG_NOTICE([autobuild hostname... $hostname])
   fi
   * change all instances of executing `hostname` with constant string "localhost"

Author: rain1 

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: , 
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: 
Reviewed-By: 
Last-Update: 

--- libtool-2.4.6.orig/configure
+++ libtool-2.4.6/configure
@@ -577,7 +577,7 @@ exec 6>&1
 # Name of the host.
 # hostname on some systems (SVR3.2, old GNU/Linux) returns a bogus exit status,
 # so uname gets run too.
-ac_hostname=`(hostname || uname -n) 2>/dev/null | sed 1q`
+ac_hostname="localhost"
 
 #
 # Initializations.
@@ -2259,7 +2259,7 @@ cat <<_ASUNAME
 ## Platform. ##
 ## - ##
 
-hostname = `(hostname || uname -n) 2>/dev/null | sed 1q`
+hostname = "localhost"
 uname -m = `(uname -m) 2>/dev/null || echo unknown`
 uname -r = `(uname -r) 2>/dev/null || echo unknown`
 uname -s = `(uname -s) 2>/dev/null || echo unknown`
@@ -3499,7 +3499,7 @@ $as_echo "$as_me: autobuild project... $
   { $as_echo "$as_me:${as_lineno-$LINENO}: autobuild revisi

Bug#819737: git-remote-gcrypt: Fails to push with “Unable to find remote helper for 'curl'”

[Sean Whitton]

control: tag -1 +moreinfo
control: owner -1 !
control: severity -1 normal

Dear Nicolas,

Thank you for your bug report.

I am pretty sure that the error you are seeing is coming from git, not
git-remote-gcrypt.  Could you confirm that the URL for your antarctica
remote is 'gcrypt::curl://antartica/pass/', please?  And could you
explain why you are using curl://?  I have not come across that URI
scheme before.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#796619: ipsec-tools: Has init script in runlevel S but no matching service file

[Felipe Sateler]

Control: tags -1 patch

On Sat, 22 Aug 2015 22:22:00 -0300 fsate...@debian.org wrote:
> Package: ipsec-tools
> Severity: important
> User: pkg-systemd-maintain...@lists.alioth.debian.org
> Usertags: init-rcs-service
>
> Hi,
>
> Your package ipsec-tools has an initscript that is enabled in
> runlevel S, but it does not provide a corresponding systemd service
> unit.
>
> Systemd generates units for all sysv init scripts that do not have a
> corresponding systemd unit. By default, it sets
> DefaultDependencies=yes, which means they get ordered after early
> boot has finished.
>
> The problem is that to preserve the runlevel S semantics, systemd in
> debian is currently[1] ordering all S services Before=sysinit.target.
> This target is particularly early in the boot sequence, which means
> that it is most of the time too strict. In turn, this means it is
> fairly easy to end up with dependency cycles. For an example, see bug
> [763315]. Do note that the cycle still exists with sysvinit, it is
> just that systemd complains more loudly.
>
> Please add a systemd unit for the given service with the appropriate
> dependencies, which most of the time will be less strict than
> Before=sysinit.target. In other cases, the script is simply not
> applicable in systemd, in which case the package should ship a
> symlink to /dev/null as /lib/systemd/system/.service.


Please find attached a debdiff for a systemd unit that wraps the
current init script.

Saludos


ipsec-tools.debdiff
Description: Binary data

Bug#796603: closed by Anton Zinoviev (Bug#796603: fixed in console-setup 1.138)

[Felipe Sateler]

On 19 March 2016 at 06:55, Anton Zinoviev  wrote:
> On Wed, Mar 16, 2016 at 03:22:42PM -0300, Felipe Sateler wrote:
>>
>> Yet another one would be to have setupcon itself detect the existence
>> of the cached scripts.
>
> The only reason there are cached scripts is that people are complaining
> that console-setup is slow at boot.  The cached scripts contain the
> mininum configuration sufficient to configure the console.  If we run
> setupcon, we don't need cached scripts.
>
>> Would you be OK, until further development comes along, to use a
>> wrapper unit like this:
>
> Yes and thank you!
>
>> I plan to do a NMU fixing this bug via a unit like the above, please
>> tell me if you want to address this in some other way.
>
> However, I don't think it is appropriate to do a NMU with such changes.
> Instead you should make a regular upload of the package.  I don't know
> whether you have commit rights in the repository of Debian installer
> (where the sources of console-setup are), or not, but in any case I
> think you can obtain such rights in no time.

I have uploaded a new version. I have not yet, however, secured commit
rights to d-i git repository. If you want to pull the changes before I
get the access, you can pull the signed tag from my fork:

git pull https://anonscm.debian.org/git/users/fsateler/console-setup.git
debian/1.141

-- 

Saludos,
Felipe Sateler

Bug#819703: LXDE also affected by this

[Jamil Said Jr .]

Hello all,

I want to bring to your attention that LXDE is also affect by this. I am
also getting this disruptive and rude "warnings" every time that I start my
(fully updated, stable version) Debian Jessie LXDE computers.

It seems that the author does not understand (or doesn't care) that if you
use stable versions of Debian (and other distributions), it is because you
are willing to trade off "cutting edge" for stability. There are many, many
scenarios where the stable version is much preferred over the "latest"; as a
matter of fact, I almost always use and recommend stable versions.

I work with people who are quite "beginners" at using computers; many are
beginners at the level of not knowing to send email or even double-clicking
a .desktop file to launch an application - warnings like those implemented
on xscreensaver are bound to "scare" and "confuse" users of various levels
of knowledge, specially beginners. In addition to that (as others
commented), such warnings certainly make the OS less usable, and also cast a
bad light on the EXCELLENT Debian stable. This should be against policy, can
you imagine if all Debian packages start showing this kind of "warnings"?
The stable versions would be a mess.

I pledge to you to change the current (and future) xscreensaver versions on
Debian stable to make this "warnings" go away, as soon as possible.

Respectfully,
Jamil Said

Bug#819766: pesign: new upstream release out

[Tollef Fog Heen]

Package: pesign
Version: 0.110-2
Severity: wishlist

0.111 seems to be out, can this be packaged please?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#819760: [Letsencrypt-devel] Bug#819760: acme-tiny: Please install README

[Jeremías Casteglione]

Hi:

On Fri, 01 Apr 2016 15:31:42 -0700
Vagrant Cascadian  wrote:

> Please consider shipping the README.md file in the acme-tiny package,
> as it provides useful information about how to use acme-tiny.

Thanks for the report and for the patch! It's indeed useful to install
it.

I already pushed commit d931550 to package repo.

Can someone from the team upload the -4 version please? I've not
such rights. Thanks!

Cheers,


-- 
Jeremías


pgp2YA1jO9H9u.pgp
Description: OpenPGP digital signature

Bug#819765: new upstream version 1.2.2 available

[Steinar H. Gunderson]

Package: cubemap
Version: 1.2.1-1
Severity: wishlist

Hi Philipp,

I've released cubemap 1.2.2; please give it a shot. Update should be trivial.
It contains a fix for an access.log bug that's quite bad, but thankfully that 
was
introduced in 1.2.0, so jessie is safe (otherwise I might have discussed the 
possibility of a stable update with you :-P).

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

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

Versions of packages cubemap depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.22
ii  libc62.19-18+deb8u3
ii  libgcc1  1:4.9.2-10
pn  libprotobuf7 
ii  libstdc++6   4.9.2-10
ii  lsb-base 4.1+Debian13+nmu1

cubemap recommends no packages.

Versions of packages cubemap suggests:
ii  logrotate   3.8.7-1+b1
ii  munin-node  2.0.25-1

Bug#819764: readline() on closed filehandle GZ at /usr/bin/helpztags line 64.

[Josh Triplett]

Package: vim-common
Version: 2:7.4.1689-1
Severity: normal
File: /usr/bin/helpztags

When upgrading to this version of vim:

Setting up vim-common (2:7.4.1689-1) ...
Setting up vim-runtime (2:7.4.1689-1) ...
Processing /usr/share/vim/addons/doc
readline() on closed filehandle GZ at /usr/bin/helpztags line 64.


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

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 vim-common depends on:
ii  libc6  2.22-5

Versions of packages vim-common recommends:
ii  vim  2:7.4.1689-1

vim-common suggests no packages.

-- no debconf information

Bug#817874: linux-image-3.16.0-4-amd64: 3.16.7-ckt25-1 freeze with radeon driver

[Steve VanDevender]

Package: src:linux
Version: 3.16.7-ckt25-1
Followup-For: Bug #817874

I'm also seeing freezes with a system using the radeon driver.  Here's
the first logged kernel oops (the subsequent oopses basically look the
same):

Apr  1 14:43:01 hexadecimal kernel: [90926.018227] *pdpt = 07ac4001 
*pde =  
Apr  1 14:43:01 hexadecimal kernel: [90926.018260] Oops: 0002 [#1] SMP 
Apr  1 14:43:01 hexadecimal kernel: [90926.018282] Modules linked in: nls_utf8 
nls_cp437 vfat fat usb_storage cpufreq_powersave cpufreq_userspace 
cpufreq_stats cpufreq_conservative radeon dell_wmi snd_hda_codec_analog 
snd_hda_codec_generic sparse_keymap iTCO_wdt iTCO_vendor_support coretemp 
kvm_intel dcdbas kvm lpc_ich mfd_core snd_hda_intel snd_hda_controller ttm 
snd_hda_codec drm_kms_helper drm pcspkr snd_hwdep snd_pcm_oss i2c_i801 evdev 
i2c_algo_bit serio_raw i2c_core snd_mixer_oss mei_me mei snd_pcm snd_timer wmi 
snd soundcore shpchp tpm_tis tpm button acpi_cpufreq processor thermal_sys fuse 
parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid 
hid sg sr_mod sd_mod cdrom crc_t10dif crct10dif_generic crct10dif_common ahci 
libahci ata_generic libata scsi_mod ehci_pci uhci_hcd ehci_hcd e1000e ptp 
pps_core usbcore usb_common
Apr  1 14:43:01 hexadecimal kernel: [90926.018913] EIP: 0060:[] 
EFLAGS: 00010286 CPU: 0
Apr  1 14:43:01 hexadecimal kernel: [90926.018952] EIP is at 
radeon_fence_ref+0x10/0x50 [radeon]
Apr  1 14:43:01 hexadecimal kernel: [90926.018980] EAX: 0001 EBX:  
ECX:  EDX: 
Apr  1 14:43:01 hexadecimal kernel: [90926.019013] ESI: e7285288 EDI: 0008 
EBP: c8a03c8c ESP: c8a03c88
Apr  1 14:43:01 hexadecimal kernel: [90926.019045]  DS: 007b ES: 007b FS: 00d8 
GS: 00e0 SS: 0068
Apr  1 14:43:01 hexadecimal kernel: [90926.019073] CR0: 8005003b CR2: 0004 
CR3: 31262000 CR4: 000407f0
Apr  1 14:43:01 hexadecimal kernel: [90926.019116]  c8a03cd8 c8a03d1c f8563865 
f47b3010 f47b3010 f6f7 c8a03db0 
Apr  1 14:43:01 hexadecimal kernel: [90926.019169]  0020 f6f71138 0006f840 
f6f710e4 c8a03cf4  052b25d0 f758a048
Apr  1 14:43:01 hexadecimal kernel: [90926.019221]  c8a03cf4 c1084eb3 f6f49ca0 
    
Apr  1 14:43:01 hexadecimal kernel: [90926.019303]  [] ? 
radeon_sa_bo_new+0x1f5/0x390 [radeon]
Apr  1 14:43:01 hexadecimal kernel: [90926.019338]  [] ? 
update_cfs_rq_blocked_load+0x133/0x180
Apr  1 14:43:01 hexadecimal kernel: [90926.019383]  [] ? 
radeon_ib_get+0x2f/0xd0 [radeon]
Apr  1 14:43:01 hexadecimal kernel: [90926.019425]  [] ? 
radeon_cs_ioctl+0x131/0x6b0 [radeon]
Apr  1 14:43:01 hexadecimal kernel: [90926.019459]  [] ? 
update_rq_clock.part.82+0x18/0x50
Apr  1 14:43:01 hexadecimal kernel: [90926.019501]  [] ? 
radeon_cs_parser_init+0x4b0/0x4b0 [radeon]
Apr  1 14:43:01 hexadecimal kernel: [90926.019541]  [] ? 
drm_ioctl+0x1cf/0x530 [drm]
Apr  1 14:43:01 hexadecimal kernel: [90926.019580]  [] ? 
radeon_cs_parser_init+0x4b0/0x4b0 [radeon]
Apr  1 14:43:01 hexadecimal kernel: [90926.019616]  [] ? 
try_to_wake_up+0x136/0x290
Apr  1 14:43:01 hexadecimal kernel: [90926.019646]  [] ? 
__pm_runtime_resume+0x51/0x70
Apr  1 14:43:01 hexadecimal kernel: [90926.019683]  [] ? 
radeon_drm_ioctl+0x3e/0x70 [radeon]
Apr  1 14:43:01 hexadecimal kernel: [90926.019720]  [] ? 0xf84e8fff
Apr  1 14:43:01 hexadecimal kernel: [90926.019742]  [] ? 
do_vfs_ioctl+0x2f2/0x4d0
Apr  1 14:43:01 hexadecimal kernel: [90926.019770]  [] ? 
SyS_futex+0x8c/0x140
Apr  1 14:43:01 hexadecimal kernel: [90926.019796]  [] ? 
SyS_ioctl+0x60/0x90
Apr  1 14:43:01 hexadecimal kernel: [90926.019822]  [] ? 
sysenter_do_call+0x12/0x12
Apr  1 14:43:01 hexadecimal kernel: [90926.020105] CR2: 0004
Apr  1 14:43:01 hexadecimal kernel: [90926.027602] ---[ end trace 
ad087539d71c4c47 ]---
Apr  1 14:43:22 hexadecimal kernel: [90947.032000] sending NMI to all CPUs:
Apr  1 14:43:22 hexadecimal kernel: [90947.032000] NMI backtrace for cpu 1
Apr  1 14:43:22 hexadecimal kernel: [90947.032000] EIP: 0060:[] 
EFLAGS: 0026 CPU: 1
Apr  1 14:43:22 hexadecimal kernel: [90947.032000] EIP is at 
__const_udelay+0x3/0x20
Apr  1 14:43:22 hexadecimal kernel: [90947.032000] EAX: 01062560 EBX: 2710 
ECX: f000 EDX: f000
Apr  1 14:43:22 hexadecimal kernel: [90947.032000] ESI: c1614f80 EDI: f7593620 
EBP: f4d4fe74 ESP: f4d4fe64
Apr  1 14:43:22 hexadecimal kernel: [90947.032000]  DS: 007b ES: 007b FS: 00d8 
GS: 00e0 SS: 0068
Apr  1 14:43:22 hexadecimal kernel: [90947.032000] CR0: 80050033 CR2: b2a6c000 
CR3: 33d66000 CR4: 000407f0
Apr  1 14:43:22 hexadecimal kernel: [90947.032000]  c104038a c1548401 c157a0ce 
c1614f80 f4d4febc c10ac95d c1557924 1483
Apr  1 14:43:22 hexadecimal kernel: [90947.032000]  002ca9ee 002ca9ed 03af 
0001 f4d4febc c1084790 0001 c166a5ec
Apr  1 14:43:22 hexadecimal kernel: [90947.032000]  c1614f80 f7593620 0001 
f6f1e560  0001 f4d4fed0 c1062dac
Apr  1 14:43:22 hexadecimal kernel: [90947.0

Bug#819538: gnome-builder: build against vala 0.32

[peter green]

Found 819538 3.18.1-1
Thanks

> Your package needs to be updated to build against the new vala
0.32.

Testing is also affected by this issue.

Bug#819763: Please drop or demote dependency on xscreensaver packages

[Michael Biebl]

Package: cinnamon-screensaver
Version: 2.8.0-1
Severity: normal

Hi,

please consider removing the recommends on
 xscreensaver-data
 xscreensaver-data-extra
 xscreensaver-gl
 xscreensaver-gl-extra

or at least demoting it to suggests, so those packages aren't installed
by default.
cinnamon-screensaver is perfectly usable without xscreensaver and most
users will be perfectly fine with the default cinnamon screen locker.
Installing the above 4 packages pulls in a whopping 30+ MB here, so
trimming the footprint of a default cinnamon installation will be
appreciated.

Regards,
Michael




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

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

Versions of packages cinnamon-screensaver depends on:
ii  cinnamon-desktop-data  2.8.1-1
ii  dbus-x11   1.10.8-1
ii  gir1.2-webkit2-4.0 2.12.0-1
ii  gnome-icon-theme   3.12.0-1
ii  libc6  2.22-5
ii  libcairo2  1.14.6-1
ii  libcinnamon-desktop4   2.8.1-1
ii  libdbus-1-31.10.8-1
ii  libdbus-glib-1-2   0.106-1
ii  libgdk-pixbuf2.0-0 2.32.3-1.2
ii  libglib2.0-0   2.48.0-1
ii  libgnomekbd8   3.6.0-1
ii  libgtk-3-0 3.18.9-1
ii  libpam0g   1.1.8-3.2
ii  libsystemd0229-3
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1
ii  libxklavier16  5.2.1-1
ii  libxxf86vm11:1.1.4-1
ii  python 2.7.11-1

Versions of packages cinnamon-screensaver recommends:
ii  cinnamon-common  2.8.7-1
ii  gnome-power-manager  3.18.0-1
ii  libpam-gnome-keyring 3.18.3-1
pn  xscreensaver-data
pn  xscreensaver-data-extra  
pn  xscreensaver-gl  
pn  xscreensaver-gl-extra

cinnamon-screensaver suggests no packages.

-- no debconf information

Bug#819762: clang: -shared-libasan is unusable

[Ben Longbons]

Package: clang
Version: 1:3.6-33
Severity: normal

Dear Maintainer,

With the latest available versions of clang-3.{5..9}
( 1:3.5.2-3 1:3.6.2-3 1:3.7.1-2 1:3.8-2 1:3.9~svn262954-1 )
it is impossible to build and run programs using the shared version
of libasan.

For 3.5 through 3.7, the error is at link time:

/usr/bin/x86_64-linux-gnu-ld.bfd.real: cannot find 
/usr/lib/llvm-3.5/bin/../lib/clang/3.5.2/lib/linux/libclang_rt.asan-preinit-x86_64.a:
 No such file or directory
/usr/bin/x86_64-linux-gnu-ld.bfd.real: cannot find 
/usr/lib/llvm-3.5/bin/../lib/clang/3.5.2/lib/linux/libclang_rt.asan-x86_64.so: 
No such file or directory

The debian packaging appears to simply not include the shared versions
of the files. Since these are older versions, it may not be worth fixing.

For 3.8 and 3.9, the error is at load time:

libclang_rt.asan-x86_64.so => not found

exporting LD_LIBRARY_PATH works, but is not .

Among other things, this makes it impossible to use ASAN with shared
libraries, though there are reasons to want shared ASAN for binaries too.

Additionally, `-print-file-name=libasan.so` should do the right thing
like it does for GCC, to avoid both clang-specific behavior *and* trying
to guess the right architecture for the current set of CC and CFLAGS.

Particularly, for shared libraries, it is expected that you can do:
LD_PRELOAD=$(${CC} ${CFLAGS} -print-file-name=libasan.so):$LD_PRELOAD

# BEGIN TEST SCRIPT
#!/bin/bash

# ASAN is available since CLANG 3.1 and since GCC 4.8
# To test with a single version, do something like:
# LD_LIBRARY_PATH=/usr/lib/llvm-3.8/lib/clang/3.8.0/lib/linux/ CC=clang-3.8 
./test.sh

ALL_VERSIONS=$(echo gcc-4.{8..9} gcc-{5..6} clang-3.{1..9})

for CC in ${CC:-${ALL_VERSIONS}}
do
CFLAGS=-fsanitize=address
if [ "${CC}" != "${CC#clang}" ]
then
CFLAGS="$CFLAGS -shared-libasan"
fi
if ! ${CC} --version &> /dev/null
then
echo ${CC} is not installed.
continue
fi
if ! echo 'int main(){}' | ${CC} ${CFLAGS} -x c - &> /dev/null
then
echo ${CC} failed to compile/link the program.
continue
fi
if ldd a.out | grep -q 'not found'
then
echo ${CC} failed to create a loadable binary.
continue
fi
ACTUAL_ASAN=$(ldd a.out | grep asan | sed 's/.*=> *//;s/ *(.*) *//')
if ! DECLARED_ASAN=$(${CC} ${CFLAGS} -print-file-name=libasan.so 
2>/dev/null)
then
echo ${CC} failed to print filename.
continue
fi
if [ "$(realpath ${ACTUAL_ASAN})" != "$(realpath ${DECLARED_ASAN})" ]
then
echo ${CC} printed a different version than it actually used.
continue
fi
echo ${CC} is okay!
done
# END TEST SCRIPT

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

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

Versions of packages clang depends on:
ii  clang-3.6  1:3.6.2-3

clang recommends no packages.

clang suggests no packages.

-- no debconf information

Bug#819761: Root partition should use ext4 instead of ext3

[Vincent Bernat]

Package: openstack-debian-images
Version: 1.6
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

The default filesystem since Wheezy is ext4. However, the Openstack
images are using ext3. ext4 brings more performance that some cloud
user may appreciate.

Thanks.

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

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJW/vxEAAoJEJWkL+g1NSX5dMQP/0IiWwS+B1YgrqkILtJkc9en
3A28rntiUyg/8xaecCJXygk5vv1tywk/IP7W7iz19anBSOUHw+tnJ+GVh1Q4Ph/k
q3Afw5c1MEh9TvR9uJM14DZkeU7/bJsUH+Id3jCn7+sdRmEzmdzFfExInnayQ9B8
DbEv8P7xWpSJGzLEQ01MoMYuTseKaBZROC37nqVbqhGpundQ5t8SaU5GlUQiIoSp
aMEqHxKu5IJM/rJ0UqakC7IojNdgc7vd8HoVWAasFpjM6CQyVYO8BR+ckpajCfqx
OxtH1NGj1uxhhR+n4IcNzqW5/vNyaq/u9G4M80EDbOau7XNucmRNx2PpQznLa3+5
uQd+kD1sZKmU/UWWLVsQYI8z/01MnOHo8R/YGgdS9leH38U1+oiPzwlKAH7noGMa
69YACOng+D0B9p1VKlUernLnIjQhS84xT6B9f36MF9gfSHmB8yHTS1TAL2iC66Y9
HzEvATqZV1U4LwVKXUWHXGVqzOSQI1PvJVDmkBQYIWr8ebfzMMydf5nD/x82TWn3
HML8LPszwL7Lh3wxK2R2AY/Sb6Y1glaz/LCiqlQ3KbUd64lMWJVVdVp7McAyBBHe
ChHShKP/O1uW2bytDSSPC902/Iw68yrP8t5HTkzxodqhx8SDEl27xFpO+6NQ1dZl
pSR/4MDLl3XYoVEXppg5
=9lNN
-END PGP SIGNATURE-

Bug#765682: w3m: help page generation does not allow internationalization

[Tatsuya Kinoshita]

On October 17, 2014 at 12:19PM +0200, markus.hiereth (at freenet.de) wrote:
> In contrast, the help-dialogue still brings English explanations to
> the keybindings. This dialogue is created dynamically. It is not
> clear. what files of the source package and of the binary package are
> involved.

Though not gettextized, I've added support for German translated
help messages in the development repo.

Please translate these files:

  - 
https://anonscm.debian.org/cgit/collab-maint/w3m.git/plain/doc-de/README.func
  - 
https://anonscm.debian.org/cgit/collab-maint/w3m.git/plain/scripts/w3mhelp-funcdesc.de.pl.in

Thanks,
--
Tatsuya Kinoshita


pgpMqpDDbxDHz.pgp
Description: PGP signature

Bug#772341: w3m: i18n, l10n for FAQ.html, MANUAL.html and README.func.gz for German

[Tatsuya Kinoshita]

On February 23, 2016 at 11:11PM +0100, markus.hiereth (at freenet.de) wrote:
>   FAQ.html,
>   as attachment to message
>   https://lists.debian.org/debian-l10n-english/2014/12/msg2.html
>
>   MANUAL.html
>   as attachment to message
>   https://lists.debian.org/debian-l10n-english/2014/12/msg00030.html
>
>   README.func.gz
>   as attachment to message
>   https://lists.debian.org/debian-l10n-english/2015/02/msg00011.html
>
> Please introduce these improved documentation files to the sources of
> w3m. They shall serve as basics for my translation into German.

Merged in the development repo, see the latest master branch.

  - https://anonscm.debian.org/cgit/collab-maint/w3m.git/tree/doc

Though not gettextized, if these documents are translated into
German, I'll include them in the doc-de directory (will be
installed in /usr/share/doc/w3m/de for Debian packages).

Note that README.func is needed to display translated help messages.
cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765682

Thanks,
--
Tatsuya Kinoshita


pgpGZ45daX9Rr.pgp
Description: PGP signature

Bug#819760: acme-tiny: Please install README

[Vagrant Cascadian]

Package: acme-tiny
Version: 20151229-3
Severity: wishlist
Tags: patch

Thanks for maintaining acme-tiny!

Please consider shipping the README.md file in the acme-tiny package,
as it provides useful information about how to use acme-tiny.

diff --git a/debian/docs b/debian/docs
new file mode 100644
index 000..b43bf86
--- /dev/null
+++ b/debian/docs
@@ -0,0 +1 @@
+README.md


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#819757: Patch to enable UEFI Secure Boot in qemu-efi

[Linn Crosetto]

Attaching a patch without the changelog entry.
From 99d3ceb650d4a05fdc26987e3dd436dccf3206bb Mon Sep 17 00:00:00 2001
From: Linn Crosetto 
Date: Fri, 1 Apr 2016 10:44:15 -0600
Subject: [PATCH] Add support for UEFI Secure Boot to qemu-efi

Add SECURE_BOOT_ENABLE flag to aarch64 build to enable support for UEFI
Secure Boot.

Signed-off-by: Linn Crosetto 
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 13560c2..54e22e1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -49,11 +49,11 @@ setup-build:
 	# single shell invocation
 	. ./edksetup.sh
 	QUILT_PC=.pc-post QUILT_PATCHES=debian/post-patches quilt push -a || [ $$? = 2 ]
+	cd CryptoPkg/Library/OpensslLib/ && ./Install.sh
 
 build-ovmf: EDK2_ARCH_DIR=X64
 build-ovmf:
 ifneq (,$(findstring ovmf, $(shell dh_listpackages)))
-	cd CryptoPkg/Library/OpensslLib/ && ./Install.sh
 	cd UefiCpuPkg/ResetVector/Vtf0 && python Build.py
 	mkdir -p EdkShellBinPkg/FullShell/$(EDK2_ARCH_DIR) \
 	 FatBinPkg/EnhancedFatDxe/$(EDK2_ARCH_DIR)
@@ -86,6 +86,7 @@ build-qemu-efi:
 		GCC49_AARCH64_PREFIX=$(GCC49_AARCH64_PREFIX) build -a $(EDK2_HOST_ARCH) \
 			-t $(EDK2_TOOLCHAIN) \
 			-p ArmVirtPkg/ArmVirtQemu.dsc \
+			-DSECURE_BOOT_ENABLE=TRUE \
 			-DINTEL_BDS \
 			-b RELEASE
 
-- 
2.8.0.rc3



signature.asc
Description: Digital signature

Bug#588017: perl: current directory in @INC potentially harmful

[Dominic Hargreaves]

Control: forwarded -1 https://rt.perl.org/Public/Bug/Display.html?id=127810

On Mon, Mar 12, 2012 at 09:49:59PM +0200, Niko Tyni wrote:
> Just a note that this topic has resurfaced upstream; the thread starts at
>  http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2012-03/msg00265.html

And again, this time with a patch:

https://rt.perl.org/Public/Bug/Display.html?id=127810

I think that we would want to apply this as soon as practical (assuming
it gets merged to blead) but I'm not sure if that extends as far as
us patching 5.24 in Debian. An experimental rebuild would be worthwhile,
at least.

Dominic.

Bug#790612: ITP: python-path-and-address -- Functions for server CLI applications used by humans.

[Tiago Ilieve]

control: owner -1 !

Hi Gustavo,

I'm taking the ownership of this ITP bug too, as we talked about
packaging Grip[1] in #790611.

Regards,
Tiago.

[1]: https://github.com/joeyespo/grip
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790611#17

-- 
Tiago "Myhro" Ilieve
Blog: https://blog.myhro.info/
GitHub: https://github.com/myhro
LinkedIn: https://br.linkedin.com/in/myhro
Montes Claros - MG, Brasil

Bug#732209: Fix or workaround?

[Joseph Hurtado]

Is there a fix or workaround for this bug?

Bug#819759: youtube-dl: needs ca-certificates but doesn't "require" it

[Brian Sammon]

Package: youtube-dl
Version: 2016.02.22-1
Severity: normal

Dear Maintainer,

I installed youtube-dl on a relatively new system.  The ca-certificates
package was not installed, as it is not "required" by any other packages on
the system, and I do not install "recommends" by default.

With the (strict) dependencies satisfied, I tried to use it:

# youtube-dl https://www.youtube.com/watch?v=qwVKDXw3TB8 
[youtube] qwVKDXw3TB8: Downloading webpage
ERROR: Unable to download webpage:  (caused
by URLError(SSLError(1, u'[SSL: CERTIFICATE_VERIFY_FAILED] certificate
verify failed (_ssl.c:581)'),))

When I installed "ca-certificates", the problem went away.

youtube-dl does not require , and does not even recommend or suggest
ca-certificates.  I think it should require it.

I suppose it's rare to install (and use) youtube-dl before any of the
various other packages that require ca-certificates.  It's certainly never
happened to me before on at least a half-dozen other systems I've used
youtube-dl on.



-- System Information:
Debian Release: 7.7
Architecture: i386 (i686)

Kernel: Linux 3.10-3-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 youtube-dl depends on:
ii  python-pkg-resources  18.8-1
pn  python:any

Versions of packages youtube-dl recommends:
ii  curl  7.38.0-4+deb8u3
pn  ffmpeg | libav-tools  
pn  mpv | mplayer | mplayer2  
pn  rtmpdump  
ii  wget  1.13.4-3+deb7u1

youtube-dl suggests no packages.

-- no debconf information


-- 
Brian Sammon 

Bug#819725: ext4 missing softdep on crc32c module

[Ben Hutchings]

Control: tag -1 sid upstream
Control: found -1 4.4.6-1
Control: retitle -1 ext4 missing softdep on crc32c module
Control: severity -1 important

On Fri, 2016-04-01 at 14:51 +, Mattia Rizzolo wrote:
> control: reassign -1 src:linux
> 
> please don't use html in your emails, it'll probably make our tooling
> grumpy (as it did in this case).
> Also, 1) there are no packages "linux-image" 2) 4.4.0-1 is surely
> something non-current

It is the current ABI version though.

> Then I haven't read the bug report, though I'm somehow confident this is
> not a *critical* bug (as in our meaning of critical, at least), but I'll
> let the linux maintainers deal with it.

It would be if a default installation was broken, but the default
installation builds a generic initramfs (MODULES=most) which won't have
this problem.

> On Fri, Apr 01, 2016 at 01:25:19PM +, Raymond Burkholder wrote:
[...]
> > Here is the final output of the boot sequence to console:
> > =
> > Loading Linux 4.4.0-1-amd64 ...
> > Loading initial ramdisk ...
> > modprobe: module btrfs not found in modules.dep
> > /dev/sda2: clean, 24088/137088 files, 160700/547840 blocks
> > [1.486902] EXT4-fs (sda2): Cannot load crc32c driver.
[...]

It appears that the initramfs is missing the crc32c driver, even though
ext4 needs it.  The ext4 module doesn't have a static dependency on it
so mkinitramfs does not know that it should be included.  (The same is
true for btrfs but we already have a workaround for that.)

The dynamic loading of crc32c was added way back in Linux 3.5 *but*
only for filesystems with the metadata_csum option turned on, which was
not the default.  So the regression is triggered by a change in
e2fsprogs:

> e2fsprogs (1.43~WIP.2015.05.18-1) unstable; urgency=low
[...]
>   * Mke2fs will now create file systems with metadata_csum and 64bit
>     enabled by default.

Until this is fixed in the kernel package, you can work around it by
either:

- Setting base-installer/initramfs-tools/driver-policy to "most"
  instead of "dep"
- Setting base-config/late_command to a script that adds crc32c to
  /etc/initramfs-tools/modules

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

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

Bug#819758: jessie-pu: package perl/5.20.2-3+deb8u5

[Dominic Hargreaves]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

The attached patch improves binary compatibility for debugperl (provided
in the perl-debug package) and fixes

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

Thanks,
Dominic.

-- 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/bash
Init: sysvinit (via /sbin/init)
diff --git a/debian/.git-dpm b/debian/.git-dpm
index 1ea6490..23337bd 100644
--- a/debian/.git-dpm
+++ b/debian/.git-dpm
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-1237ea93fb2475a5ae576d5ee1358a5bb4ebe426
-1237ea93fb2475a5ae576d5ee1358a5bb4ebe426
+b40a8334d0a81d88be7371fa2124ce30994d4f94
+b40a8334d0a81d88be7371fa2124ce30994d4f94
 708ce0747a55640ef1136be276185cc1a5a82564
 708ce0747a55640ef1136be276185cc1a5a82564
 perl_5.20.2.orig.tar.bz2
diff --git a/debian/changelog b/debian/changelog
index df53340..d1e9660 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+perl (5.20.2-3+deb8u5) UNRELEASED; urgency=medium
+
+  * Apply patch from Niko Tyni fixing debugperl crashes with XS
+modules (Closes: #816280)
+
+ -- Dominic Hargreaves   Fri, 01 Apr 2016 22:13:30 +0100
+
 perl (5.20.2-3+deb8u4) jessie-security; urgency=high
 
   * Work around a t/op/stat.t failure on GNU/kFreeBSD, possibly related
diff --git a/debian/patches/debian/debugperl-compat-fix.diff b/debian/patches/debian/debugperl-compat-fix.diff
new file mode 100644
index 000..07547e4
--- /dev/null
+++ b/debian/patches/debian/debugperl-compat-fix.diff
@@ -0,0 +1,30 @@
+From b40a8334d0a81d88be7371fa2124ce30994d4f94 Mon Sep 17 00:00:00 2001
+From: Niko Tyni 
+Date: Fri, 8 Jan 2016 14:27:36 +0200
+Subject: Disable PERL_TRACK_MEMPOOL for debugging builds
+
+This is a workaround for an ABI incompatibility between
+-DDEBUGGING and normal builds.
+
+Bug-Debian: https://bugs.debian.org/810326
+Bug: https://rt.perl.org/Public/Bug/Display.html?id=127212
+Patch-Name: debian/debugperl-compat-fix.diff
+---
+ perl.h | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/perl.h b/perl.h
+index 1325de9..8f19b28 100644
+--- a/perl.h
 b/perl.h
+@@ -176,7 +176,9 @@
+ #  define pTHX_8	9
+ #  define pTHX_9	10
+ #  define pTHX_12	13
+-#  if defined(DEBUGGING) && !defined(PERL_TRACK_MEMPOOL)
++/* PERL_TRACK_MEMPOOL temporarily disabled for DEBUGGING */
++/* see https://bugs.debian.org/810326 */
++#  if 0 && defined(DEBUGGING) && !defined(PERL_TRACK_MEMPOOL)
+ #define PERL_TRACK_MEMPOOL
+ #  endif
+ #else
diff --git a/debian/patches/series b/debian/patches/series
index 3251835..0f4ce8a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -45,3 +45,4 @@ fixes/encode-unicode-bom.diff
 debian/encode-unicode-bom-doc.diff
 debian/kfreebsd-softupdates.diff
 fixes/CVE-2016-2381_duplicate_env.diff
+debian/debugperl-compat-fix.diff
diff --git a/perl.h b/perl.h
index 1325de9..8f19b28 100644
--- a/perl.h
+++ b/perl.h
@@ -176,7 +176,9 @@
 #  define pTHX_8	9
 #  define pTHX_9	10
 #  define pTHX_12	13
-#  if defined(DEBUGGING) && !defined(PERL_TRACK_MEMPOOL)
+/* PERL_TRACK_MEMPOOL temporarily disabled for DEBUGGING */
+/* see https://bugs.debian.org/810326 */
+#  if 0 && defined(DEBUGGING) && !defined(PERL_TRACK_MEMPOOL)
 #define PERL_TRACK_MEMPOOL
 #  endif
 #else

Bug#816280: Binary incompatibility between debugperl and perl

[Dominic Hargreaves]

On Sun, Mar 13, 2016 at 01:24:09PM +0200, Niko Tyni wrote:
> On Mon, Feb 29, 2016 at 12:17:39PM +, Dominic Hargreaves wrote:
> > Control: forwarded -1 https://rt.perl.org/Public/Bug/Display.html?id=127212
> > Control: tags -1 + fixed-upstream confirmed
> > 
> > On Mon, Feb 29, 2016 at 12:53:33PM +0100, Nick Wellnhofer wrote:
> > > Package: perl-debug
> > > Version: 5.20.2-2
> > > 
> > > The layout of interpreter variables is different in the debug and normal
> > > version of the perl binary. This means that XS extensions might read from 
> > > or
> > > write to the wrong area of the interpreter variable struct, causing 
> > > crashes
> > > and other strange behavior.
> > > 
> > > Here's an example, originally reported by me at
> > > https://rt.cpan.org/Public/Bug/Display.html?id=111211
> > > 
> > > $ PERL_DESTRUCT_LEVEL=2 debugperl -MList::Util=shuffle -e shuffle
> > > Segmentation fault
> 
> > This was discovered as part of the investigation into 
> >  (which is
> > not quite the same bug) and was fixed upstream. This fix should be in
> > 5.24 which should be in stretch. However, the fix by its nature breaks
> > binary compatibility, so it will unfortunately not be possible to apply
> > it to a stable release.
> 
> The workaround in sid/stretch disabling PERL_TRACK_MEMPOOL for the debug
> build (debian/debugperl-compat-fix.diff) should be applicable to jessie
> too. We should probably push it into a stable update.

Right, I see that the effect is expected to be different on jessie
and applying that patch does fix the problem.

Unfortunately we're too late for the next stable update, but I'll get
it queued up for the one after that.

Dominic.

Bug#819757: edk2: Add support for UEFI Secure Boot to qemu-efi

[Linn Crosetto]

Package: edk2
Version: 0~20160104.c2a892d7-1
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Adding SECURE_BOOT_ENABLE option to qemu-efi build will allow UEFI Secure
Boot support on aarch64, as is already enabled on x86.

I have attached a patch to debian/rules to enable this. Thanks.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJW/vENAAoJEF/3aG7d/FTWSzMP/1GDypwjEDVIWS0vUwS7XjEI
c04RzG+1my6VLEHAwBwsj2pZfrFIgKBthifa/oX9uIPOApAqUlKjFTFpgCnwReB8
N4wUIvd/M9gJnOo20fBlLH7rjWf0/Qhy1Lue+86R+DNhSaBbx9TKmP1kNnVUFJBz
AMLgx1eShQ9xEVeUlWGAXBKZ0ccKE4UJOXq8gVKgavSt8iGTEJjFGD4tx5bhqrxF
5sn26JYOE2Nxf+ONxLYapfT9KJff1HW8KjgNGbVH9n0HdxcYxCXLVozkCVhbIffa
hIf7lXW9I+vnlBzPiIrjdtFwyIfKg6PKU09jqza60+8o7oUOo6V5VfI2SuWbW9qM
L458C7SZa5KoL9Ujex+rUk68O9AQQU8scIvMUvNkrfXQ5PbjR1y/FiiCPumlRGWx
aCnVjgKFcIkijmC1EBheLnk1p93LjKFSBwqlvYgrU2pIBKxId3kyPCjckbJh4rOm
h1Duzhvp7WY+vojWwaw3dWnqu8SvytBdrpNmrBQgF7qndhR3+pmth+uTANr4tDbX
z7auGSQCDOf5RILqxmM1Y6bc0zgHoFtwIkbZJB9cichU4iMh5eefpYQwPRUV7XNG
o/xnVL6eUtt45qtu2Xp6SbqZbhV6VbQFSIaS1/rJ+Zdzea3Ux1LG+OPpGlTyfm6R
HMwXQMYiVJ2Jz/Gsh9vZ
=yE2S
-END PGP SIGNATURE-
>From 0d62883b306cb31f9e536b1fa7f3ebc1d595aecf Mon Sep 17 00:00:00 2001
From: Linn Crosetto 
Date: Fri, 1 Apr 2016 10:44:15 -0600
Subject: [PATCH] Add support for UEFI Secure Boot to qemu-efi

Add SECURE_BOOT_ENABLE flag to aarch64 build to enable support for UEFI
Secure Boot.

Signed-off-by: Linn Crosetto 
---
 debian/changelog | 1 +
 debian/rules | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 6578138..3539c95 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
 edk2 (0~20160104.c2a892d7-2+l4tm1) UNRELEASED; urgency=low
 
   * Initial release for L4TM based on Debian's source
+  * Add support for UEFI Secure Boot to qemu-efi
 
  -- Linn Crosetto   Thu, 31 Mar 2016 17:21:41 -0600
 
diff --git a/debian/rules b/debian/rules
index 13560c2..54e22e1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -49,11 +49,11 @@ setup-build:
 	# single shell invocation
 	. ./edksetup.sh
 	QUILT_PC=.pc-post QUILT_PATCHES=debian/post-patches quilt push -a || [ $$? = 2 ]
+	cd CryptoPkg/Library/OpensslLib/ && ./Install.sh
 
 build-ovmf: EDK2_ARCH_DIR=X64
 build-ovmf:
 ifneq (,$(findstring ovmf, $(shell dh_listpackages)))
-	cd CryptoPkg/Library/OpensslLib/ && ./Install.sh
 	cd UefiCpuPkg/ResetVector/Vtf0 && python Build.py
 	mkdir -p EdkShellBinPkg/FullShell/$(EDK2_ARCH_DIR) \
 	 FatBinPkg/EnhancedFatDxe/$(EDK2_ARCH_DIR)
@@ -86,6 +86,7 @@ build-qemu-efi:
 		GCC49_AARCH64_PREFIX=$(GCC49_AARCH64_PREFIX) build -a $(EDK2_HOST_ARCH) \
 			-t $(EDK2_TOOLCHAIN) \
 			-p ArmVirtPkg/ArmVirtQemu.dsc \
+			-DSECURE_BOOT_ENABLE=TRUE \
 			-DINTEL_BDS \
 			-b RELEASE
 
-- 
2.8.0.rc3

Bug#819756: ITP: python-path-and-address -- Functions for command-line server tools used by humans

[Tiago Ilieve]

Package: wnpp
Severity: wishlist
Owner: Tiago Ilieve 

* Package name: python-path-and-address
  Version : 1.0.0
  Upstream Author : Joe Esposito 
* URL : https://github.com/joeyespo/path-and-address
* License : MIT
  Programming Lang: Python
  Description : Functions for command-line server tools used by humans

Path-and-address resolves ambiguities for command-line interface applications
with the following pattern:

$ your_app [] []

The library applies the principal of least surprise to command-line interfaces.

Some examples:

$ your_app .
 * Serving . on http://localhost:5000/

$ your_app 80
 * Serving . on http://localhost:80/

$ your_app ./80
 * Serving ./80 on http://localhost:5000/

$ your_app path/to/file
 * Serving path/to/file on http://localhost:5000/

$ your_app 0.0.0.0
 * Serving 0.0.0.0 on http://localhost:5000/

$ your_app . 0.0.0.0
 * Serving . on http://0.0.0.0:5000/

$ your_app 0.0.0.0:8080
 * Serving . on http://0.0.0.0:8080/

-

This library is a dependency of Grip[1], which is being packaged in ITP bug
#790611[2].

I plan to maintain it alone, but will evaluate joining Debian Python Modules
Team (DPMT) in the process.

Regards,
Tiago.

[1]: https://github.com/joeyespo/grip
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790611

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Yves-Alexis Perez]

[note: if you don't CC: me, then I don't get your mail]

On Fri, 1 Apr 2016 22:33:31 +0200 Adam Borowski  wrote:
> On Fri, Apr 01, 2016 at 09:26:23PM +0200, Yves-Alexis Perez wrote:
> > That's definitely something to consider for stretch. I wasn't really willing
> > to do that before because without having an Xfce locker I preferred staying
> > with the common ground, but I also had bad interaction with the upstream
> > developer and am not really interested in having more interactions.
> > 
> > Right now, there's a way to switch to something else, which is light-locker,
> > so it might be a good idea to do that indeed. I'll update the tasksel 
> > package
> > with that in mind.
> 
> light-locker has a hard dependency on lightdm, and if I read its description
> right, it's impossible to remove.  I don't think we should tie xfce to a
> single display manager.  It also does weird VT switching that's
> disconcerting enough to be called a bug.

Xfce is not tied to lightdm or light-locker. Current situation is:

- task-xfce-desktop depends on xfce4, lightdm
- xfce4 depends on xfce4-session
- xfce4-session recommends xscreensaver

I've switched that (for stretch) to:

- task-xfce-desktop depends on xfce4, lightdm, light-locker
- xfce4 depends on xfce4-session
- xfce4-session recommends light-locker

So you'll have lightdm + light-locker by default when you select Xfce desktop
when installing, but you can remove it and if you manually install xfce4 and
don't install recommends you won't have it either.

Regards,
-- 
Yves-Alexis



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

Bug#819742: man firehol.conf results in undesired behavior

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Alexander, thanks for your report.

On 01/04/16 18:07, Alexander Perlis wrote:
> Package: firehol Version: 3.0.1+ds-1
> 
> The package firehol contains /usr/share/man/man5/firehol.conf.5.gz
> which references the non-existent "man5/firehol-conf.5" (which
> doesn't exist in this package; it is part of firehol-doc, but that
> package might not be installed). The command "man firehol.conf"
> results in:
> 
> man: can't open /usr/share/man/man5/firehol-conf.5: No such file or
> directory Manual page firehol.conf(5) line ?/? (END) (press h for
> help or q to quit)

The man firehol-conf.5 page appears to be present in the two packages:
this is not expected and confuse the apt  machinery.
[I have just removed the firehol-doc package from my box, and the 
firehol.conf(5)
is present and contains `.so man5/firehol-conf.5'.]

The package firehol must contain the man page firehol, which refers to 
firehol.conf.
Both contains basic information, and as such they can be used as quick reminder 
or introduction.
The package firehol-doc contains far more advanced information.
So, for consistency reasons (and historical reasons [there was a time when the 
firehol-doc
document was non-existent]), firehol.conf must be in the firehol package.
Nevertheless, it is true that the manpage firehol.conf is somewhere between the 
two packages
firehol and firehol.conf.


> 
> It would be better if the firehol.conf.5.gz were moved to
> firehol-doc,

 see above.


 and it would be even better if firehol.conf.5 were a
> stub that said to install firehol-doc for access to the
> documentation, and that stub were to be substituted with the real
> thing if firehol-doc were in fact installed.

I guess this is implicit.
Some line in the README.Debian may be added to precise this point.
I am not that comfortable to touch the original material. 

> 
> Note: The same issues exist with fireqos and fireqos-doc, but I'm not
> filing a separate bug report.

This is consistent and expected.

[I plan to fix this issue at the next release].


Jerome




- -- 
Jerome BENOIT, Ph.D. | jgmbenoit-at+rezozer*dot_net
http://www.rezozer.net/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJW/uuvAAoJEIC/w4IMSybj3PgH/RiTgDF9DR3q3oG1D92TdgR8
qBlC+9JEYQORqQttLWZB7hwG1qQWNdktCUtxiEynIw2zmQIr4joPgyFFBmzS4rL1
584WgqwkjhefgT/37IILYVpB//CL63APn1mEdh8xqFOWQyPQrYS//snmxZWiouJv
W5ZxDQ2m2r1aOwaTBv04HXLcdftE+/rTQlE+n5mZfaFgZDGHYgGSsIaUEvJo2Ia8
brrHpSFA4J07wkW/PgXZsiZg/1JupWFAhPozVPtTsY81aZIrFHwFIEjhbK2f2AO2
TwDfyFCzNmUr8pC1pjwAi64IoCVajPawMeG/KrsI+bNfnQPJvc82Rqg2PBNqvUE=
=AZuL
-END PGP SIGNATURE-

Bug#819713: osm2pgsql: segfault

[Sebastiaan Couwenberg]

Control: tags -1 fixed-upstream pending

I've included the upstream commit fixing this issue as a patch in
osm2pgsql (0.90.0+ds-2) which will be available in unstable shortly.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#819755: qemu-user-static: "Temporary failure in name resolution" with qemu-{mips, mipsel, s390x}-static

[Luca Falavigna]

Package: qemu-user-static
Version: 1:2.5+dfsg-5
Severity: important

Dear Maintainer,

I just created a fresh mips schroot using qemu-debootstrap to emulate mips
architecture.

Unfortunately, I cannot resolve any name because it seems DNS resolution is not
working anymore. Attached is strace log of a simple ping against ftp.debian.org

This behaviour happens at least under mips, mipsel and s390x.



-- 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=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.1.6-1

Versions of packages qemu-user-static suggests:
ii  sudo  1.8.15-1.1

-- no debconf information
(unstable-mips-test)root@winterfell:~# qemu-mips-static -strace /bin/ping -c 1 
ftp.debian.org
31258 brk(NULL) = 0x00442000
31258 mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 
0x767ca000
31258 uname(0x76fff600) = 0
31258 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
31258 access("/etc/ld.so.preload",R_OK) = -1 errno=2 (No such file or directory)
31258 open("/etc/ld.so.cache",O_RDONLY|O_CLOEXEC) = 3
31258 fstat64(3,0x76fff220) = 0
31258 mmap(NULL,9662,PROT_READ,MAP_PRIVATE,3,0) = 0x767c7000
31258 close(3) = 0
31258 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
31258 open("/lib/mips-linux-gnu/libcap.so.2",O_RDONLY|O_CLOEXEC) = 3
31258 read(3,0x76fff364,512) = 512
31258 prctl(46,8,1996485476,512,1988124672,0) = -1 errno=22 (Invalid argument)
31258 fstat64(3,0x76fff228) = 0
31258 mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 
0x767c6000
31258 mmap(NULL,82288,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 
0x767b1000
31258 mprotect(0x767b5000,61440,PROT_NONE) = 0
31258 
mmap(0x767c4000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x3000)
 = 0x767c4000
31258 close(3) = 0
31258 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
31258 open("/usr/lib/mips-linux-gnu/libidn.so.11",O_RDONLY|O_CLOEXEC) = 3
31258 read(3,0x76fff34c,512) = 512
31258 prctl(46,8,1996485452,512,1988124672,0) = -1 errno=22 (Invalid argument)
31258 fstat64(3,0x76fff210) = 0
31258 mmap(NULL,266688,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 
0x7676f000
31258 mprotect(0x767a,61440,PROT_NONE) = 0
31258 
mmap(0x767af000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x3)
 = 0x767af000
31258 close(3) = 0
31258 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
31258 open("/lib/mips-linux-gnu/libresolv.so.2",O_RDONLY|O_CLOEXEC) = 3
31258 read(3,0x76fff334,512) = 512
31258 prctl(46,9,1996485428,512,1988124672,0) = -1 errno=22 (Invalid argument)
31258 lseek(3,724,0,1988008292,0,0) = 724
31258 read(3,0x76fff298,32) = 32
31258 fstat64(3,0x76fff1f8) = 0
31258 mmap(NULL,157936,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 
0x76748000
31258 mprotect(0x7675b000,65536,PROT_NONE) = 0
31258 
mmap(0x7676b000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x13000)
 = 0x7676b000
31258 
mmap(0x7676d000,6384,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0)
 = 0x7676d000
31258 close(3) = 0
31258 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
31258 open("/lib/mips-linux-gnu/libc.so.6",O_RDONLY|O_CLOEXEC) = 3
31258 read(3,0x76fff31c,512) = 512
31258 prctl(46,13,1996485404,512,1988124672,0) = -1 errno=22 (Invalid argument)
31258 lseek(3,520,0,0,0,0) = 520
31258 read(3,0x76fff278,36) = 36
31258 lseek(3,828,0,1988008292,0,0) = 828
31258 read(3,0x76fff250,32) = 32
31258 fstat64(3,0x76fff1e0) = 0
31258 mmap(NULL,1572624,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 
0x765c8000
31258 mprotect(0x7673,65536,PROT_NONE) = 0
31258 
mmap(0x7674,24576,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x168000)
 = 0x7674
31258 
mmap(0x76746000,7952,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0)
 = 0x76746000
31258 close(3) = 0
31258 access("/etc/ld.so.nohwcap",F_OK) = -1 errno=2 (No such file or directory)
31258 open("/lib/mips-linux-gnu/libattr.so.1",O_RDONLY|O_CLOEXEC) = 3
31258 read(3,0x76fff254,512) = 512
31258 prctl(46,8,1996485204,512,1988124672,0) = -1 errno=22 (Invalid argument)
31258 fstat64(3,0x76fff118) = 0
31258 mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 
0x765c7000
31258 mmap(NULL,82176,PROT_EXEC|PROT_READ,MAP_PRIVATE|MAP_DENYWRITE,3,0) = 
0x765b2000
31258 mprotect(0x765b6000,61440,PROT_NONE) = 0
31258 
mmap(0x765c5000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_DENYWRITE|MAP_FIXED,3,0x3000)
 = 0x765c5000
31258 close(3) = 0
31258 mmap(NULL,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS,-1,0) = 
0x76

Bug#819754: kfreebsd-10: GCC build: stack protector panic on boot

[Steven Chamberlain]

Package: src:kfreebsd-10
Version: 10.3~svn296998-1
Severity: normal

Hi,

When compiled with GCC (rather than upstream default compiler Clang),
WITH_SSP (Stack Smashing Protection), kfreebsd-10 panics on boot.

The panic is in taskqueue_start_threads, just before it would start
zfskern I think.

WITHOUT_SSP it boots fine.  SSP has always been problematic when Debian
built kfreebsd with recent versions of GCC, and it has been disabled for
past releases.  This bug will be kept open though for any followup on
what causes this;  but we'd like to turn this feature back on someday.

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

Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#819732: gnome-terminal: [csd] window enlarges on startup, focus, unfocus, Enter keypress, resize

[Simon McVittie]

On Fri, 01 Apr 2016 at 15:52:31 +0100, Simon McVittie wrote:
> 1. Log in to GNOME (Wayland) session; I'm using gnome-session 3.20
>where this is just called "GNOME"

This appears to be triggered by client-side decorations, which are
always-on in Wayland, but can also be enabled on X11 via

GTK_CSD=1 GDK_BACKEND=x11 /usr/lib/gnome-terminal/gnome-terminal-server &
GTK_CSD=1 GDK_BACKEND=x11 gnome-terminal

S

Bug#819190: libgl1-nvidia-legacy-340xx-glx: post-installation-Skript returns error code 137

[Luca Boccassi]

Control: tags -1 unreproducible
Control: severity -1 normal

On Sun, 2016-03-27 at 15:35 +0100, Luca Boccassi wrote:
> Control: tags -1 moreinfo
> 
> On Thu, 2016-03-24 at 18:14 +0100, Peter Schütt wrote:
> > Package: libgl1-nvidia-legacy-340xx-glx
> > Version: 340.96-3
> > Severity: critical
> > Justification: breaks the whole system
> > 
> > First I deinstalled all of nvidia
> > 
> > apt-get --purge remove *nvidia*
> > 
> > apt-get install nvidia-detect
> > 
> > Check for needed legacy-driver
> > 
> > apt-get install nvidia-legacy-340xx-driver
> > 
> > libgl1-nvidia-legacy-340xx-glx:amd64 (340.96-3) wird eingerichtet ...
> > Killed
> > dpkg: Fehler beim Bearbeiten des Paketes 
> > libgl1-nvidia-legacy-340xx-glx:amd64
> > (--configure):
> >  Unterprozess installiertes post-installation-Skript gab den Fehlerwert 137
> > zurück
> > 
> > libgl1-nvidia-legacy-340xx-glx:i386 (340.96-3) wird eingerichtet ...
> > 
> > And after this line the installation process hangs.
> > I have to kill the processes from another console.
> 
> Hi Peter,
> 
> Unfortunately I cannot reproduce this in a clean sid amd64 chroot with
> neither:
> 
> apt-get install nvidia-legacy-340xx-driver
> 
> nor
> 
> apt-get install nvidia-legacy-340xx-driver
> libgl1-nvidia-legacy-340xx-glx:i386
> 
> After the apt-get remove, are you sure there was no leftover? Have you
> checked with dpkg -l? What version of the driver did you have installed
> before?
> 
> Also, when posting the output of commands, could you please prefix them
> with: LC_ALL=C this way the output is in English and it's easier for
> non-German speaker to understand :-)

Tried again to reproduce this. Again in a Sid chroot amd64, this time
also adding i386 architecture with dpkg.

Tried installing nvidia-driver, and then nvidia-legacy-340xx-driver,
works fine.

Tried installing nvidia-driver, purging it away with the same command
you used, and then installing nvidia-legacy-340xx-driver, works fine.

Tried installing nvidia-driver, libgl1-nvidia-glx:i386 and then purging
and then installing nvidia-legacy-340xx-driver and
libgl1-nvidia-legacy-340xx-glx:i386, works fine as well.

Sorry, but without more information I don't know what else to try to
reproduce your problem.

So for now I'll mark as unreproducible and reduce the severity to avoid
autoremoval.

Kind regards,
Luca Boccassi


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

Bug#819753: texlive-latex-extra-doc: please compress all PDF files

[Christian T. Steigies]

Package: texlive-latex-extra-doc
Version: 2015.20160320-1
Severity: wishlist

Dear Maintainer,
I am trying to upgrade texlive on my notebook but it is running out of space
while setting up texlive-latex-extra-doc. This is a big package, it contains
many large PDF files. evince and xpdf can handle gz compressed PDF files, I
don't know if all supported PDF viewers can, but it would save quite some
diskspace if you could ship all PDF files compressed.

thanks,
Christian

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Paul R. Tagliamonte]

Sadsies. xscreensaver is my screensaver of choice.

Sounds fine, let's file a RoM

Cheers,
  Paul

On Fri, Apr 1, 2016 at 4:37 PM, Michael Biebl  wrote:

> On Fri, 1 Apr 2016 10:10:40 -0700 Jamie Zawinski  wrote:
> > For those of you who can't be bothered to read the code, here's what the
> comment says.
> >
> > I stand by my words here: If you are considering removing this warning,
> then I ask that instead, you remove the XScreenSaver software from Debian
> entirely. I believe Gnome-Screensaver will be more to your liking anyway.
>
> Sounds like we should do that indeed.
> CCing our ftp-masters.
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>


-- 
:wq

Bug#819002: aptitude: can't remove user tag by the 'aptitude remove-user-tag tag package' command

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi Vladislav,

2016-03-22 17:31 Vladislav:

Package: aptitude
Version: 0.7.8-1
Severity: important

Dear Maintainer,

  * What led up to the situation?
I added the user tag to package meld, than tried to remove it.
  * What exactly did you do (or not do) that was effective (or
ineffective)?
'aptitude --add-user-tag meld install meld'
'aptitude remove-user-tag meld meld'
Last command must remove the user tag (according to manual), but this does not 
worked.
Then I tried:
'aptitude --remove-user-tag meld reinstall meld'
This also does not worked.
  * What was the outcome of this action?
Nothing happens.
  * What outcome did you expect instead?
Removing user tag meld from package meld.


This will be fixed in the next version, marking as +pending, thanks for
the report.

If it still doesn't work after that, please reopen (or open a new report
if it's related to user-tags but a different problem).


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#819752: Please package 1.4.1

[Alexandre Viau]

Package: src:msgpack
Version: 0.5.7-3

Hello,

It'd be really helpful if we could get a bump to 1.4.1.

I need this for ring.cx, which I am packaging at the moment.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Michael Biebl]

On Fri, 1 Apr 2016 10:10:40 -0700 Jamie Zawinski  wrote:
> For those of you who can't be bothered to read the code, here's what the 
> comment says.
> 
> I stand by my words here: If you are considering removing this warning, then 
> I ask that instead, you remove the XScreenSaver software from Debian 
> entirely. I believe Gnome-Screensaver will be more to your liking anyway.

Sounds like we should do that indeed.
CCing our ftp-masters.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Adam Borowski]

On Fri, Apr 01, 2016 at 09:26:23PM +0200, Yves-Alexis Perez wrote:
> On ven., 2016-04-01 at 18:54 +0200, Michael Biebl wrote:
> > On Fri, 1 Apr 2016 18:11:15 +0200 Samuel Thibault 
> > > (That gives a really bad impression: Jessie is just one year old, we
> > > told the installer to install the XFCE desktop, and the first thing we
> > > got after rebooting from the installer was that fat warning...)

I wonder, perhaps this could warrant pushing an expedited update somehow?  A
popup blocking Xsession startup on every login shows Debian in a pretty bad
light.  Yeah, it's not a data-loss bug merely a bad PR bug but still...

> > Maybe the best course of action would be, if xfce didn't install
> > xscreensaver by default (but would choose a more lightweight / better
> > integrated alternative).
>
> That's definitely something to consider for stretch. I wasn't really willing
> to do that before because without having an Xfce locker I preferred staying
> with the common ground, but I also had bad interaction with the upstream
> developer and am not really interested in having more interactions.
> 
> Right now, there's a way to switch to something else, which is light-locker,
> so it might be a good idea to do that indeed. I'll update the tasksel package
> with that in mind.

light-locker has a hard dependency on lightdm, and if I read its description
right, it's impossible to remove.  I don't think we should tie xfce to a
single display manager.  It also does weird VT switching that's
disconcerting enough to be called a bug.

I took a look at alternatives:
* gnome-screensaver has OMGWTFBBQ-level insanity that makes it useless for
  anyone but Gnome3 lovers
* mate-screensaver isn't that much better (jwz is quite right...)
* cinnamon-screensaver is surprisingly sane.  Its depends/recommends would
  need trimming for reasonable use outside Cinnamon but I guess that's a
  matter of asking Cinnamon guys nicely.  After all, it wasn't envisioned
  to be used elsewhere...
* i3lock and slock[suckless-tools] lack a GUI

Another option could be forking xscreensaver, it could use some trimming and
fixing (for things where jwz disagreed).  (I don't volunteer here, though --
I see a bunch of things I could help with drive-by patching, but no full
maintenance, as I don't know xlib, details of DPMS handling or such).

So, other than the obvious "return 0;" fix in jessie, I'd recommend not
being hasty and think things through before updating all tasks, etc.


Meow!
-- 
A tit a day keeps the vet away.

Bug#819675: request-tracker4: RT4 upgrade from Wheezy to Jessie fails due to missing dependency

[Nicolas Braud-Santoni]

Oh, indeed.

Thanks a lot for the swift reply, and sorry for the erroneous bug report.


Best,

  nicoo


pgpcb93RXAL_x.pgp
Description: PGP signature

Bug#760301: [Openjdk] Bug#760301: openjdk-8: Missing links to jawt_md.h and jni_md.h in /usr/lib/jvm/java-8-openjdk-amd64/include

[Hilko Bengen]

* Matthias Klose:

>> Additionally passing -I${JAVA_HOME}/include/linux to gcc seems to work
>> around the problem in my Linux-specific case, but that can't be the
>> proper solution, can it?
>
> It is the proper solution. Same as for other openjdk/java distributions.

Could you please enlighten us on *why* this is the proper solution?

At the moment, the only thing I see is some JNI-related packages being
broken by this change -- and adding stuff to the compiler's search path
this way still seems somewhat like a hack/workaround to me that only
complicates things. What am I missing?

Cheers,
-Hilko

Bug#791652: [mwm] maximize window button stretches across 2-4x the screen width on certain apps

[Graham Inggs]

Reported at Mozilla: 'Firefox doesn't maximize properly'

https://bugzilla.mozilla.org/show_bug.cgi?id=851930

Bug#814291: RFS: libneo4j-client/0.8.0-1

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo



hi, lets review

changelog: single entry
control: std-version is 3.9.7
please use dh-autoreconf (control, rules)
"libc6-dev" <-- why?

check-all-the-things review
$ codespell --quiet-level=3

$ cppcheck -j1 --quiet -f . | grep -vF 'cppcheck: error: could not find or open 
any of the paths given.'

$ flawfinder -Q -c .


other stuff looks good to me.
I dind't run yet lintian and the package, will do when you fix the above



Il Mercoledì 10 Febbraio 2016 2:30, Chris Leishman  ha 
scritto:



Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "libneo4j-client"

Package name: libneo4j-client
Version : 0.8.0-1
Upstream Author : Chris Leishman (myself)
URL : https://github.com/cleishm/libneo4j-client
License : Apache-2.0
Section : devel

It builds those binary packages:


libneo4j-client-doc - Documentation for libneo4j-client, a client library for 
Neo4j
libneo4j-client5 - Client library for the Neo4j graph database
libneo4j-client5-dev - Development files for libneo4j-client, a client library 
for Neo4j
neo4j-client - Command line shell for the Neo4j graph database

To access further information about this package, please visit the following 
URL: http://mentors.debian.net/package/libneo4j-client


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

dget -x 
http://mentors.debian.net/debian/pool/main/libn/libneo4j-client/libneo4j-client_0.8.0-1.dsc


More information about libneo4j-client can be obtained from 
https://git.io/libneo4j-client.

Regards,
Chris Leishman

Bug#813603: RFS: libcxl/1.3-1 [ITP] -- libcxl -- Coherent accelerator shared library

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi,

control: std-version 3.9.7
copyright: please don't mix GPL and Apache, or other people won't be able to 
forward patches upstream.

outfile <-- remove?

rules:

make --> $(MAKE) please

mkdir -p $(CURDIR)/debian/tmp/usr/$(LIBDIR) $(CURDIR)/debian/tmp/usr/include
cp libcxl.a libcxl.so.$(VERS_LIB) $(CURDIR)/debian/tmp/usr/$(LIBDIR)
cp libcxl.h $(CURDIR)/debian/tmp/usr/include
cd $(CURDIR)/debian/tmp/usr/$(LIBDIR) && ln -sf libcxl.so.$(VERS_LIB) 
libcxl.so.1
cd $(CURDIR)/debian/tmp/usr/$(LIBDIR) && ln -sf libcxl.so.1 libcxl.so


this should be handled by upstream makefile, there is no good reason for doing 
it
in rules (and other linux distro won't benefit from it)

check-all-the-things:
$ flawfinder -Q -c .
$ codespell --quiet-level=3

the other stuff looks good to me, but I didn't try to build it yet.



Il Mercoledì 3 Febbraio 2016 16:15, Frederic Bonnard 
 ha scritto:
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

Package name: libcxl
Version : 1.3-1
Upstream Author : CAPI team
URL : https://github.com/ibm-capi/libcxl
License : Apache-2.0
Section : libs

It builds those binary packages:

  libcxl-dev - Coherent accelerator shared library development files
  libcxl1- Coherent accelerator shared library

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

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


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

dget -x 
http://mentors.debian.net/debian/pool/main/libc/libcxl/libcxl_1.3-1.dsc

More information about libcxl can be obtained from 
https://github.com/ibm-capi/libcxl

Note:
This library is specific to ppc64 and ppc64el architectures and requires
a specific CAPI FPGA accelerator card.

Regards,
Frederic Bonnard

Bug#791724: RFS: w1retap/1.4.4-1 [ITP] -- Data logger for 1-Wire weather sensors

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi,
control:
"retrieved   data" <-- double space
std version is 3.9.7 now
please run wrap-and-sort
please remove quilt from b-d

changelog:
one single changelog entry please

-rm -f $(CURDIR)/debian/w1retap.1 $(CURDIR)/debian/w1find.1 -> debian/clean 
might be easier to maintain

rules:
dh_auto_install is a no-op please remove

dh_makeshlibs --noscripts <-- why?
remove quilt


libw1retap0-odbc.install <-- is that the mysql wrapper?

service file:
ExecStop=/bin/kill $MAINPID

really needed?

patches: remove-data-time-macro.patch
you can dpkg-parsechangelog and export the changelog date an build date.
(this will make the package reproducible I think)

question:
usually libraries are ship in this way

libfooSONAME shipping libfoo.so.SONAME

libfoo-dev with an hard dependency on libfooSONAME
and a libfoo.so symlink to libfoo.so.SONAME and /usr/include/foo
headers files.

In your package you are shipping them together

not an issue, but do you know what you are doing here?
are them useful and being linked outside the package?
are them just internal?

lots of stuff (systemd script udev rules) should be upstreamed to me
check-all-the-things review:
codespell --quiet-level=3
cppcheck -j1 --quiet -f .
grep -riE 'fixme|todo|hack|xxx' .
grep -r '/tmp/' .


cheers,

G.




Il Martedì 19 Gennaio 2016 19:27, Thomas Stewart  ha 
scritto:
Dear mentors,

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

* Package name: w1retap
  Version : 1.4.4-1
  Upstream Author : Jonathan Hudson 
* URL : http://www.zen35309.zen.co.uk/wx/tech.html
* License : GPL with some Expat
  Programming Lang: C
  Description : Data logger for 1-Wire weather sensors

It builds those binary packages:
  libw1retap0 - Data logger for 1-Wire weather sensors
  libw1retap0-mongo - Data logger for 1-Wire weather sensors
  libw1retap0-odbc - Data logger for 1-Wire weather sensors
  libw1retap0-pgsql - Data logger for 1-Wire weather sensors
  libw1retap0-sqlite - Data logger for 1-Wire weather sensors
  w1retap - Data logger for 1-Wire weather sensors

To access further information about this package, please visit the following 
URL:
http://mentors.debian.net/package/w1retap

Alternatively, one can download the package with dget using this command:
dget -x http://mentors.debian.net/debian/pool/main/w/w1retap/w1retap_1.4.4-1.dsc

More information about hello can be obtained from 
http://www.zen35309.zen.co.uk/wx/tech.html.

Changes since the last upload:
w1retap (1.4.4-1) unstable; urgency=medium
.
   * New upstream release.

Kind Regards
--
Tom

Bug#819751: nginx-common: wrong owner for /var/log/nginx and files, causes dac_override in AA

[Jerome Poulin]

Package: nginx-common
Version: 1.6.2-5+deb8u1
Severity: normal

Dear Maintainer,

After using aa-logprof to generate a profile for nginx, it seems that it
requests the dac_override capability because logs are located in a
folder which is not accessible by root thereby causing an access denied
in the logs and preventing the server to start.

I searched bug reports and found the security issue #701112
(CVE-2013-0337) to be what caused the problem in the first place. It
seems that the bug was about the log files being "world readable",
however, now that the log folder is owned by www-data, it means that the
web server process now has full control over the log folder.

I noted that message #44 says that log parsers need www-data on the log
folder to work, however, apache2 package has no issue with its folder
and log files being root:adm/0750.

To fix the issue, used chown -R root:adm /var/log/nginx and replaced
www-data:adm to root:adm in logrotate.d.  I can now use an AA profile
without dac_override being set.


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

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

Versions of packages nginx-common depends on:
ii  init-system-helpers  1.22
ii  lsb-base 4.1+Debian13+nmu1

nginx-common recommends no packages.

Versions of packages nginx-common suggests:
pn  fcgiwrap   
pn  nginx-doc  
pn  ssl-cert   

-- Configuration Files:
/etc/logrotate.d/nginx changed [not included]

-- no debconf information

Bug#811455: RFS: qhttpengine/0.1.0+dfsg1-1 [ITP]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

hi,

control:
please drop dbg package
std-version 3.9.7

lintian override please remove, it isn't a false positive.

testsuite fails in a clean pbuilder sid environment

check-all-the-things review.
flawfinder -Q -c .

the other stuff looks good, even if I didn't try to run the package right now.


cheers,

G.


Il Martedì 19 Gennaio 2016 8:03, Nathan Osman  
ha scritto:
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

  * Package name: qhttpengine
Version : 0.1.0+dfsg1-1
Upstream Author :Nathan Osman 
  * URL :https://github.com/nitroshare/qhttpengine
  * License : MIT
Section : libs

It builds those binary packages:

   libqhttpengine-dbg - HTTP server for Qt applications - debug info
   libqhttpengine-dev - HTTP server for Qt applications - development files
   libqhttpengine-doc - HTTP server for Qt applications - documentation
   libqhttpengine-examples - HTTP server for Qt applications - examples
   libqhttpengine0 - HTTP server for Qt applications

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

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


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

 dget -x 
http://mentors.debian.net/debian/pool/main/q/qhttpengine/qhttpengine_0.1.0+dfsg1-1.dsc

More information about qhttpengine can be obtained 
fromhttps://github.com/nitroshare/qhttpengine.

   Regards,
Nathan Osman

Bug#817546: Pending fixes for bugs in the libquantum-entanglement-perl package

[pkg-perl-maintainers]

tag 817546 + pending
thanks

Some bugs in the libquantum-entanglement-perl package are closed in
revision 5d11c175f92314a303dc1a41cbe4edec05a0d9db in branch 'master'
by Dominic Hargreaves

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libquantum-entanglement-perl.git/commit/?id=5d11c17

Commit message:

Switch to minimal dh style rules, and modernize deps and Standards-Version 
(Closes: #817546)

Bug#819703: xscreensaver: please disable "This version of XScreenSaver is very old! Please upgrade!" message

[Yves-Alexis Perez]

On ven., 2016-04-01 at 18:54 +0200, Michael Biebl wrote:
> On Fri, 1 Apr 2016 18:11:15 +0200 Samuel Thibault 
> wrote:
> > 
> > Samuel Thibault, on Fri 01 Apr 2016 18:09:53 +0200, wrote:
> > > 
> > > I have hit the same exact bug this morning, while installing Debian
> > > Jessie, which is the latest Debian stable release.
> > (That gives a really bad impression: Jessie is just one year old, we
> > told the installer to install the XFCE desktop, and the first thing we
> > got after rebooting from the installer was that fat warning...)
> Maybe the best course of action would be, if xfce didn't install
> xscreensaver by default (but would choose a more lightweight / better
> integrated alternative).
> 
That's definitely something to consider for stretch. I wasn't really willing
to do that before because without having an Xfce locker I preferred staying
with the common ground, but I also had bad interaction with the upstream
developer and am not really interested in having more interactions.

Right now, there's a way to switch to something else, which is light-locker,
so it might be a good idea to do that indeed. I'll update the tasksel package
with that in mind.

Regards,
-- 
Yves-Alexis



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

Bug#791652: [mwm] maximize window button stretches across 2-4x the screen width on certain apps

[Graham Inggs]

Control: tags -1 confirmed

Opening Firefox and then maximizing causes the window to resize to
7680x2160 pixels.
It didn't happen with Libre Office.

Has a similar bug been reported upstream or in other distributions?

Bug#819750: kdenlive: Crash from clip properties

[Mikko Rapeli]

Package: kdenlive
Version: 15.12.3-1
Severity: normal

Dear Maintainer,

I was viewing clip properties when kdenlive crashed:

Thread 408 (Thread 0x8764ab40 (LWP 8833)):
#0  0xb7774a44 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb420d9eb in pthread_cond_wait@@GLIBC_2.3.2 ()
at ../sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
No locals.
#2  0xb467b00d in __pthread_cond_wait (cond=0x82286ff0, mutex=0x82286fd8)
at forward.c:149
__p = 
#3  0xb020f131 in ?? () from /usr/lib/i386-linux-gnu/mlt/libmltsdl.so
No symbol table info available.
#4  0xb42082ce in start_thread (arg=0x8764ab40) at pthread_create.c:334
__res = 
pd = 0x8764ab40
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1272856576, 0, 4001536, 
-2023447832, -383061596, 1634443714}, mask_was_saved = 0}}, 
  priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, 
  cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#5  0xb466e36e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:122
No locals.

Thread 407 (Thread 0x994fdb40 (LWP 8832)):
#0  0xb7774a44 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb4663982 in __GI_ppoll (fds=0x8442fe58, nfds=3, timeout=0x0, sigmask=0x0)
at ../sysdeps/unix/sysv/linux/ppoll.c:50
resultvar = 
_xv = -1267490816
resultvar = 
sc_cancel_oldtype = 2
sc_ret = 
tval = {tv_sec = -1269175163, tv_nsec = -1311649898}
result = 
#2  0xb38ce9b3 in pa_mainloop_poll ()
   from /usr/lib/i386-linux-gnu/libpulse.so.0
No symbol table info available.
#3  0xb38cf00f in pa_mainloop_iterate ()
   from /usr/lib/i386-linux-gnu/libpulse.so.0
No symbol table info available.
#4  0xb017e55d in ?? () from /usr/lib/i386-linux-gnu/libSDL-1.2.so.0
No symbol table info available.
#5  0xb014e538 in ?? () from /usr/lib/i386-linux-gnu/libSDL-1.2.so.0
No symbol table info available.
#6  0xb0158155 in ?? () from /usr/lib/i386-linux-gnu/libSDL-1.2.so.0
No symbol table info available.
#7  0xb019c048 in ?? () from /usr/lib/i386-linux-gnu/libSDL-1.2.so.0
No symbol table info available.
#8  0xb42082ce in start_thread (arg=0x994fdb40) at pthread_create.c:334
__res = 
pd = 0x994fdb40
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1272856576, 0, 4001536, 
-1722821912, -1077218920, 1634443714}, mask_was_saved = 0}}, 
  priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, 
  cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#9  0xb466e36e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:122
No locals.

Thread 406 (Thread 0x91ff5b40 (LWP 8831)):
#0  0xb7774a44 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb420d9eb in pthread_cond_wait@@GLIBC_2.3.2 ()
at ../sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
No locals.
#2  0xb467b00d in __pthread_cond_wait (cond=0x8228808c, mutex=0x82288074)
at forward.c:149
__p = 
#3  0xb74259aa in ?? () from /usr/lib/i386-linux-gnu/libmlt.so.6
No symbol table info available.
#4  0x80374433 in RenderThread::run (this=0x83f7b250)
at /build/kdenlive-KOLzQo/kdenlive-15.12.3/src/monitor/glwidget.cpp:1169
No locals.
#5  0xb49a63fb in ?? () from /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5
No symbol table info available.
#6  0xb42082ce in start_thread (arg=0x91ff5b40) at pthread_create.c:334
__res = 
pd = 0x91ff5b40
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1272856576, 0, 4001536, 
-1845538072, -557125239, 1634443714}, mask_was_saved = 0}}, 
  priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, 
  cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#7  0xb466e36e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:122
No locals.

Thread 405 (Thread 0x895cfb40 (LWP 8830)):
#0  0xb7774a44 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb420d9eb in pthread_cond_wait@@GLIBC_2.3.2 ()
at ../sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
No locals.
#2  0xb467b00d in __pthread_cond_wait (cond=0x82287024, mutex=0x82287054)
at forward.c:149
__p = 
#3  0xb020fc1b in ?? () from /usr/lib/i386-linux-gnu/mlt/libmltsdl.so
No symbol table info available.
#4  0xb42082ce in start_thread (arg=0x895cfb40) at pthread_create.c:334
__res = 
pd = 0x895cfb40
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1272856576, 0, 4001536, 
-1990397208, -1718947400, 1634443714}, mask_was_saved = 0}}, 
  priv = {pad = {0x0, 0x0, 0x0, 0x0

Bug#819749: mesa-utils: The system always freezes when I run glxinfo

[Luis Felipe López Acevedo]

Package: mesa-utils
Version: 8.2.0-1
Severity: normal

Dear Maintainer,

I installed mesa-utils to use glxinfo, but every time I run it, the system gets
frozen, the screen gets full of graphical artifacts instead of showing the
windows, and I can't interact with the system anymore (graphically or using the
terminals).

I have to restart the computer using the physical button to be able to use the
system again.

Thanks,



-- 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=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mesa-utils depends on:
ii  libc6 2.19-18+deb8u3
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libglew1.10   1.10.0-3
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libx11-6  2:1.6.2-3
ii  libxext6  2:1.3.3-1

mesa-utils recommends no packages.

mesa-utils suggests no packages.

-- no debconf information

Bug#819748: [linux-source-4.4] aufs patching outdated - unable to compile aufs4.4 based off this kernel code

[OmegaPhil]

Package: linux-source-4.4
Version: 4.4.6-1
Severity: normal


In the aufs project aufs4.4 branch, commit
969b710f2860b8d5660ac9e6f96e886ae29b4dfa (Tue Mar 1 20:27:32 2016
+0900)[0] has updated aufs4-base.patch to expose setfl in fs/fcntl.c -
this is now relied on in aufs4.4, and it fails to compile against the
current Debian v4.4 kernel source.

Please can you update the aufs patches for this kernel package.

Thanks


0:
https://github.com/sfjro/aufs4-standalone/commit/969b710f2860b8d5660ac9e6f96e886ae29b4dfa



signature.asc
Description: OpenPGP digital signature

Bug#651410: aptitude: in dependency resolutions, aptitude should favor library removal

[Manuel A. Fernandez Montecelo]

2016-03-22 13:27 Vincent Lefevre:

Hi Manuel,

On 2016-03-18 15:15:11 +, Manuel A. Fernandez Montecelo wrote:

2011-12-08 11:53 Vincent Lefevre:
> The second solution is OK, as only a library package is removed, and
> such a package with no dependencies on it is useless.

Not necessarily.  The library might have been installed by hand for
extra sound plugins or other codecs, mesa libraries not strictly needed
according to the dependency system but worthy to have in that machine,
dvd decoding, or to support something installed in the system outside of
the package managers (e.g. a special version of a webserver or other
software, compiled in /usr/local, mounted through NFS, etc).

If it's not really installed for a special purpose, should have been
marked as automatically installed to get rid of it sooner.


All my libraries are automatically installed. However some
automatically installed packages are not marked as automatically
installed. Perhaps due to some aptitude bug. I had reported a
bug in the past:

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


Yeah, there were dozens of bugs like that.  Some were addressed a while
ago and some are WIP, but still a few/many problems still remain.



Now, the fact that a library was automatically installed doesn't
mean that it is safe to remove. For instance:

1. The user installed libfoo-dev to compile a program using
  library foo. This automatically installs libfoo. It may also
  happens that both were already installed for some other reason
  (e.g. as a dependency).

2. The user compiles and installs his program.

3. After an upgrade, there is an ABI incompatibility in library foo,
  so that libfoo-dev now depends on libfoo3. At this point, there is
  no longer a dependency on libfoo, so that it will automatically be
  removed.

Of course, the user may have marked package libfoo as manually
installed, but I wonder whether most users do so. It is not always
obvious to know which library packages were needed.


Package manager tools don't have any knowledge of the system outside of
the dependencies, so if there are local software needing packages (be
that a library or any other package/command, the same bad effects happen
if other packages get removed) only the user can act upon that.

About your phrase if "a library was automatically installed doesn't mean
that it is safe to remove", seems to argue about the very title of this
report and what you were saying in it ("The second solution is OK, as
only a library package is removed, and such a package with no
dependencies on it is useless"); and goes in favour of what I was saying
in the previous message -- I don't think that libs should be favoured to
be removed in conflict resolutions, as originally proposed.

(Besides, deciding which packages are libraries is not trivial nor
accurate, there are many packages badly classified as section "libs"
which are not libs or the other way around; and weirdness with non-C/C++
languages).



Also, a long time after marking some library package as manually
installed, one may no longer remember the reason.


If the user cannot, the packaging system cannot know either.

Still, either we remove completely the mechanism of auto-installed
(which will not happen) or we have to admit that removing as soon as
there are no rev-deps is the best thing to do, and the way that this
auto-installed thing was designed to work (and copied to apt afterwards,
I believe).

If this is somehow undesired, one can always resort to manage all
packages manually.



IMHO, the right thing to do would be to write some tool that manages
such dependencies, possibly in some automatic way (e.g. with ldd and
dpkg -S).


That's not the job of a tool like aptitude, though.

It's would be relatively easy to build such a tool and then regularly to
call apt/aptitude to unmark such packages as auto; or possibly hook on
apt updates a-la apt-listchanges or apt-listbugs.



But more seriously, I think that the real problem is prefering many
removals and some keeps rather than a few upgrades and a single removal,
but not because it's specifically a library involved in that.


A single removal is bad if it is an application.


That's strange coming from you, who use the resolver costs of minimizing
removals ;-)

aptitude and apt have sometimes to remove, not install or do other nasty
actions when packages conflict, there's no way around that.  Removals
are critical to deal e.g. with obsolete packages and upgrades, even if
the removal of that library could end up breaking packages (your example
above).

My sentence above was about the original report.  If removals are
necessary, as they were in that case, better /offer first/ to remove 1
and upgrade 11 than to remove 20 and leaving others untouched (the 2
solutions mentioned in the original report).

If the user is not happy with the offer, s/he can always ask aptitude
for another solution, and reject those who doesn't like to guide the
resolution quickl

Bug#803207: gnome-settings-daemon: uses far too much memory (5.5GB currently)

[Enrico Maria Casarotti]

Package: gnome-settings-daemon
Version: 3.18.2-1
Followup-For: Bug #803207

Dear Maintainer,
after the last dist-upgrade on stretch/sid testing, all the system became very
slow,
I noticed a high memory usage of gnome-settings-daemon process, currently 2,4
GB and increasing with time
Thanks



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

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

Versions of packages gnome-settings-daemon depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gsettings-desktop-schemas3.18.1-1
ii  libc62.22-4
ii  libcairo21.14.6-1
ii  libcanberra-gtk3-0   0.30-2.1
ii  libcanberra0 0.30-2.1
ii  libcolord2   1.2.12-1
ii  libcups2 2.1.3-5
ii  libfontconfig1   2.11.0-6.3
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libgeocode-glib0 3.20.0-1
ii  libglib2.0-0 2.48.0-1
ii  libgnome-desktop-3-123.18.2-1
ii  libgtk-3-0   3.18.9-1
ii  libgudev-1.0-0   230-3
ii  libgweather-3-6  3.20.0-1
ii  liblcms2-2   2.6-3+b3
ii  libnm-glib4  1.1.91-3
ii  libnm-util2  1.1.91-3
ii  libnotify4   0.7.6-2
ii  libnspr4 2:4.12-1
ii  libnspr4-0d  2:4.12-1
ii  libnss3  2:3.23-1
ii  libnss3-1d   2:3.23-1
ii  libpam-systemd   229-3
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpolkit-gobject-1-00.105-14.1
ii  libpulse-mainloop-glib0  8.0-1
ii  libpulse08.0-1
ii  librsvg2-2   2.40.13-3
ii  libupower-glib3  0.99.4-2
ii  libwacom20.18-1
ii  libwayland-client0   1.9.0-1
ii  libx11-6 2:1.6.3-1
ii  libxext6 2:1.3.3-1
ii  libxi6   2:1.7.6-1
ii  libxtst6 2:1.2.2-1+b1
ii  nautilus-data3.18.5-1

Versions of packages gnome-settings-daemon recommends:
ii  iio-sensor-proxy  1.1-1
ii  pulseaudio8.0-1

gnome-settings-daemon suggests no packages.

-- no debconf information

Bug#819595: debian supports building with any LANG set

[Holger Levsen]

Dear Tormod, 

please include the patch from this bug report. Debian supports building
in a variety of build environments, including using the users (=builders)
locale.

(Modifying debian/rules to call "make" with the locale set to C would
also work, but is inferior, as this will result in all build messages to be
in english instead of the users choosen locale. Thus modifying
hacks/Makefile.in as the provided patch does is actually superior.)

Thanks.


--
cheers,
Holger



signature.asc
Description: Digital signature

Bug#819731: r-cran-hdf5: crash on loading hdf objects with empty TITLE attribute

[Zack Weinberg]

On Fri, Apr 1, 2016 at 2:12 PM, Dirk Eddelbuettel  wrote:
> Only thing to add is that IIRC the BioConductor folks also have a package for
> R + hdf5:
>
>http://bioconductor.org/packages/release/bioc/html/rhdf5.html
>
> I am not a user of HDF5 so not sure if this is preferable over h5.

I am the wrong person to ask; I don't need to do anything
_complicated_ with HDF5, nor am I much of an R programmer.

zw

Bug#819747: icedove: STARTTLS fails silently for no apparent reason

[Dr. Lars Hanke]

Package: icedove
Version: 38.7.0-1~deb8u1
Severity: normal
Tags: upstream

Dear Maintainer,

I'm running icedove for years as MUA via IMAP for my Cyrus2 mail
server. Access has been encrypted using TLS on port 143 for many
years. Recently, it suddenly ceased working. In the relevant time
frame I updated icedove and had to renew the server certificate.

I can contact the mail server using openssl s_client. And of course by
falling back to plain text access. Wireshark shows that an apparently
normal STARTTLS sequence is answered by icedove with "Bad
Certificate", immediately. However, from UI perspective icedove seems
to hang infinitely. There is no message about problems with
certificates shown to the user. This at least should be considered a
bug.

Beyond that I cannot find any actual problems with the certificates in
the chain. I am able to import both, server and CA, into icedoves
certificate store. Inspecting the details of the server certificate
correctly lists the CA certificate in the tree view. But still
connection fails the same way.

I'd expect icedove to complain about the certificates also when
importing them into the store, if there is actually an issue with
them.

Some more information can be found at
http://serverfault.com/questions/766389/thunderbird-starttls-fails-connecting-to-cyrus-imap-2-2-13

The example log using NSPR_LOG_MODULES=all:5 published there neither
revealed anything useful.

Kind regards,
 - lars.

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

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

Versions of packages icedove depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18+deb8u3
ii  libcairo2 1.14.0-2.1
ii  libdbus-1-3   1.8.20-0+deb8u1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:4.9.2-10
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u4
ii  libglib2.0-0  2.42.1-1
ii  libgtk2.0-0   2.24.25-3
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libpixman-1-0 0.32.6-3
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstartup-notification0  0.12-4
ii  libstdc++64.9.2-10
ii  libx11-6  2:1.6.2-3
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.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  iceowl-extension38.7.0-1~deb8u1
ii  myspell-de-at [myspell-dictionary]  20131206-5
ii  myspell-de-ch [myspell-dictionary]  20131206-5
ii  myspell-de-de [myspell-dictionary]  20131206-5
ii  myspell-en-us [myspell-dictionary]  1:3.3.0-4

Versions of packages icedove suggests:
ii  fonts-lyx 2.1.2-2
ii  libgssapi-krb5-2  1.12.1+dfsg-19+deb8u2

-- no debconf information

Bug#819731: r-cran-hdf5: crash on loading hdf objects with empty TITLE attribute

[Dirk Eddelbuettel]

On 1 April 2016 at 13:51, Zack Weinberg wrote:
| On Fri, Apr 1, 2016 at 11:30 AM, Dirk Eddelbuettel  wrote:
| >
| > Sadly this package is not longer maintained upstream:
| >
| >   https://cloud.r-project.org/web/packages/hdf5/index.html
| >
| > Somehow R never had real good support for HDF5 files--maybe the newer h5
| > package could be an alternative?
| >
| >   https://cloud.r-project.org/web/packages/h5/index.html
| 
| Yeah, I noticed that too.  But a crasher seemed worth putting on the
| record even for something that's dead upstream.
| 
| I also filed RFP bug #819735 for h5.  It looks like the only rdepends
| for r-cran-hdf5 is the science-statistics metapackage; probably they
| would be willing to switch over to h5?

Three to four thumbs way up.  That is exactly the way forward.

Only thing to add is that IIRC the BioConductor folks also have a package for
R + hdf5:

   http://bioconductor.org/packages/release/bioc/html/rhdf5.html

I am not a user of HDF5 so not sure if this is preferable over h5.

Dirk

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