Bug#826905: armhf tegra package contains symlink for arm64 package

[Vagrant Cascadian]

Control: tags 826905 pending

On 2016-06-09, Martin Michlmayr wrote:
> I just noticed that the armhf tegra package contains this symlink:
>
> lrwxrwxrwx root/root 0 2016-06-09 19:10 
> ./usr/lib/u-boot/p2371-2180/u-boot -> uboot.elf

Thanks for catching this!


> This as introduced by my patch to add p2371-2180 support for arm64.
> Unfortunately, I don't know of a way to add the symlink only to the
> arm64 package.

I made debian/u-boot-tegra.links an executable file that only outputs
the link on arm64 systems:

  
https://anonscm.debian.org/cgit/collab-maint/u-boot.git/commit/?h=experimental-2016.07&id=53a877e858e6a5215101b489a3653eafaa5c8a77


> Note that this breaks the multiarch assumption discussed in #788689
> that no u-boot package with the same name on different arches would
> include the same board directory.

Yeah, that's not good, will upload fixes soon...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#826859: sqlite3 quickly corrupts its own database

[GCS]

Hi Cristoph,

On Thu, Jun 9, 2016 at 4:55 PM, Christoph Egger  wrote:
>   This is the second time sqlite managed to corrupt its database in
> the last week on this system. The sqlite is located on a ext3
> filesystem with lots of free space. Unfortunately the corrupted
> sqlite3 contains private keys so I can't provide the database or one
> of the daily backups.
 May you give me pointers? Is it a big database, uses concurrent
access, is the CPU load high? Any chance you may reproduce it with a
non-confidental dataset?
I think the best would be to subscribe to the SQLite3 users list[1];
upstream may help without giving out your data.

Regards,
Laszlo/GCS
[1] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Bug#826931: gitlab: page with diffs (commits) - error 500

[Libor Klepáč]

Package: gitlab
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,
thanks for packing 8.8.2 gitlab.

We have upgraded yesterday and have problem with commits pages
- -
Started GET "/group/project/commit/xx53b0d3b0d0d87cf6f478b150ce689b8151a1b6" 
for 127.0.0.1 at 2016-06-10 08:25:33 +0200
Processing by Projects::CommitController#show as HTML
  Parameters: {"namespace_id"=>"group", "project_id"=>"project", 
"id"=>"xx53b0d3b0d0d87cf6f478b150ce689b8151a1b6"}
Completed 500 Internal Server Error in 343ms (ActiveRecord: 22.0ms)

ActionView::Template::Error (undefined method `diffable?' for 
#):
42: - return unless blob.respond_to?(:text?)
43: - if diff_file.too_large?
44:   .nothing-here-block This diff could not be displayed because it 
is too large.
45: - elsif blob_text_viewable?(blob) && 
!project.repository.diffable?(blob)
46:   .nothing-here-block This diff was suppressed by a .gitattributes 
entry.
47: - elsif blob_text_viewable?(blob)
48:   - if diff_view == 'parallel'
  app/models/repository.rb:439:in `method_missing'
  app/views/projects/diffs/_file.html.haml:45:in 
`_app_views_projects_diffs__file_html_haml__2130845417718406234_70613300'
  app/views/projects/diffs/_diffs.html.haml:28:in `block in 
_app_views_projects_diffs__diffs_html_haml__1571110138484770322_71701000'
  app/views/projects/diffs/_diffs.html.haml:23:in `each_with_index'
  app/views/projects/diffs/_diffs.html.haml:23:in 
`_app_views_projects_diffs__diffs_html_haml__1571110138484770322_71701000'
  app/views/projects/commit/show.html.haml:12:in 
`_app_views_projects_commit_show_html_haml___791189859704013076_79050720'
  app/controllers/projects/commit_controller.rb:30:in `show'
  lib/gitlab/middleware/go.rb:16:in `call'
- 

I seems, that it needs newer ruby-gitlab-git package.
This method is in master
https://gitlab.com/gitlab-org/gitlab_git/blob/master/lib/gitlab_git/repository.rb


Thanks,
Libor

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

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXWmDrAAoJEPDvjG7Cn0eO7xYP/1GHdZuT10JJ/P9Xj2XotkGk
3vFzchr+Iq7B5Co/ldSGU88+L484/MP4fg7ZhcBAbx/mEZT7MzTl7gBfHnUf6qrl
InxmFVlwCkiC/p/dsdoHxjqvrpm8kK6hpbFtGvG7kCpxeD11LU57avFaOEnKRm3x
7G9jdLDSJTwTC+8MkYr+U/iK0QYaS8bWqgnyjk3wwjjRSpXbLjVXZbvprOXdvlvP
pofKmks9ZY4tLg0qBUfyVvSAK81yhcbD7FaoZ6w7QFu6avhYxg+ZQRBnokSgMyXl
KIYx+mWckmghDRrXdFEReo9oyDa6q5C1fH+H4cjLe8tCFfeAvnhNSOTqeFpTQCTr
/i+1WmPbKAdjeEiXsUjgxUm80l4GErRB6UTSSeyFtSxwEpmf6ekO3ZpD7xovuD0i
jy4HIyYX/HcDnSRlfOq4FnEFfTpJjrut/m1Vup4JhMOtIWQsK9Jqp5mju0tNRUZC
4bqOl+ETNTXP8raxWDZT01I70BpHjCXdBO/iGoDQ2NStyvWPaz46094ro9Nl3mBz
Nd5H7ivJt76braHgnb6Is8n1sssf0r7TvfzP26GNe12yKkgqk4PttCdisay7sQV4
FTR3rVsnoh9+S+ArKjzyqsHPukHnCO5aVzkxReAwYdsMNlhZ0dEumzHM/m0OuIu1
nkFJn+6+Jnbckr1QKBIZ
=ksvf
-END PGP SIGNATURE-

Bug#784612: [anki] Qt4's WebKit removal

[Richard Möhn]

On Fri, 3 Jun 2016 03:01:06 +0200 Andreas Bombe  wrote:
[…]
> Right, until there's a Qt5 port, little can be done. I have actually
[…]

This is not a good solution for everyone, but I'm now running Anki
inside a Debian Jessie Docker container. See here for how to do it:
http://cloj.de/AnkiDocker/

Best,

Richard


signature.asc
Description: PGP signature

Bug#819903: gitlab: runners page not showing

[Libor Klepáč]

Package: gitlab
Followup-For: Bug #819903

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,
still happening in 8.8.2-3

Libor


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

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXWl/LAAoJEPDvjG7Cn0eO4dMQAKzCfIk0u64PXLz2Mct2ud8B
X8Zpio96tQYETGrssAFtN8hJb0koCZWeUFZemXSIULMHho2OiW1MRwZZnjDvH53b
jY+XHxRLHUFLY87EPnKzcntQPPzrUmIBr/MAWnrSNpdzvM0BfihEn+XninhUCsYg
ftelZhf6vAscFzbO4YU8fDyh5qaIqJtpsj0qj2m4ncsYC7virxYqTyUFK+v5pMD5
PAgVkiL9R2W/Bl+E4Wn2bjSLH21bVwayz/pil72FNKH5usVVpY0iEv3idX/Ti3je
loIo3OE1MMoLbKruSoYFDnkkAdvPilm95idZwApVXAG0djzRdjYtwdLSv1v4wUp0
FiRqJjsTRgTZSQm4xeq3s5d9pHcn+oZVtVRPNcf8YnMx+it3iDmLzjrUzAzvQr8V
wQt1/hwRA/QN+6vPXsE6r9QUixW9Q8NZhG7V6JFXHWNpOV4h7KgumxIGAfWEW+O4
aMIAFJS/lDEKCBgdS/yyMIspgjxAwIWm9o1RnBVMTa//3EQ/Emfhmp1iDs0174L7
29wzEg52JisD09zjQwfnx3SU0C+0xtV0hBgaWOdmEna+G4E1GZEJHsFh3I2ApNTu
CPd4305Byes2nn4SqswkCbcjw8P6ACz0w8Sdz8ePJsjvu3egQmgUyvb5MU187+rV
a4wCF9NpA9twmxlcFQmB
=2XP5
-END PGP SIGNATURE-

Bug#826882: [Pkg-javascript-devel] Bug#826882: create package from git

[Mike Gabriel]

Hi Thorsten, hi Leo,

On  Do 09 Jun 2016 20:08:13 CEST, Thorsten Alteholz wrote:


Package: npm2deb
Version: 0.2.5-1
Severity: whishlist
Tags: patch
thanks

Hi Leo,

as you know, not every developer of npm modules does release a  
tarball for new versions. Some of them commit something to github  
and just put the new

version in their package.json.

With this patch npm2deb is able to work with such repositoies.
If you do something like (the -b is new):
 ./npm2deb.py  create -b hashish
it will create a different debian/watch file (just saying that you  
can not use uscan to get a new version), it will add a new target


Is that a good idea? Not having an actual URL in debian/watch? When  
obtaining upstream projects from Github, I recommend using a watch  
file of this kind:


"""
version=3
opts=filenamemangle=s/.*\/v?([\d\.-]+)\.tar\.gz/-$1.tar.gz/ \
https://github.com///tags  
.*/archive/v?([\d\.]+).tar.gz

"""

This, although not used with uscan, provides upstream release tracking  
in DDPO.


get-orig-source to debian/rules and it will create a  
debian/get-orig-source script that pulls the latest commit from the  
repository, creates a orig.tar and puts something like X.Y.Z~git  
as version in debian/changelog.


This we may need to improve. E.g.:

  o pull latest tag, not HEAD from a Github repo
  o pull HEAD from a non-default branch


What do you think of it?


Thanks for working on this!

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

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

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


pgppR1s9nW3e3.pgp
Description: Digitale PGP-Signatur

Bug#826930: Default browser changed to chromium after iceweasel->firefox migration

[Jean-Michel Vourgère]

Package: firefox-esr
Version: 45.2.0esr-1~deb8u1
Severity: normal

Hi

After upgrading to debian 8.5, iceweasel became rebranded into firefox.

However, now, when I click on a link, chromium is starting.

Here's the result of "update-alternatives --config x-www-browser":
There are 3 choices for the alternative x-www-browser (providing 
/usr/bin/x-www-browser).
  SelectionPath  Priority   Status

* 0/usr/bin/iceweasel 70auto mode
  1/usr/bin/chromium  40manual mode
  2/usr/bin/firefox-esr   70manual mode
  3/usr/bin/iceweasel 70manual mode

I expected alternatives to be changed automatically.

Thanks

-- Addons package information
ii  firefox-esr45.2.0esr-1~ amd64Mozilla Firefox web browser - Ext
ii  xul-ext-adbloc 2.6.6+dfsg-1 all  advertisement blocking extension 
ii  xul-ext-certif 2.0.14-4 all  Certificate Monitor for Iceweasel
ii  xul-ext-cookie 1.2.0-1  all  manage cookies in a whitelist-bas
ii  xul-ext-firetr 0.5.3~rc1+df all  system tray extension for Iceweas
ii  xul-ext-grease 2.2-2all  customization of webpages with us
ii  xul-ext-https- 4.0.2-3  all  extension to force the use of HTT
ii  xul-ext-https- 091-1all  extension that detects valid HTTP
ii  xul-ext-liveht 0.17-3   all  Adds information about the HTTP h
ii  xul-ext-toggle 1.8-1all  status bar icon to toggle between
ii  xul-ext-uppity 1.5.8-3  all  toolbar button to "go up" on the 
ii  xul-ext-y-u-no 2013052401-2 all  browser extension to make securit

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages firefox-esr 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+deb8u4
ii  libcairo2 1.14.0-2.1+deb8u1
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+deb8u5
ii  libglib2.0-0  2.42.1-1+b1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.3-0 1.3.3-3
ii  libpango-1.0-01.36.8-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  procps2:3.3.9-9
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages firefox-esr recommends:
ii  gstreamer1.0-libav 1:1.4.5-dmo1
ii  gstreamer1.0-plugins-good  1.4.4-2

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.4-5
ii  fonts-stix [otf-stix]  1.1.1-1
ii  libcanberra0   0.30-2.1
ii  libgnomeui-0   2.24.5-3
ii  libgssapi-krb5-2   1.12.1+dfsg-19+deb8u2
pn  mozplugger 

-- no debconf information

Bug#826929: RFS: helm/1.9.7-1 -- Emacs incremental completion and selection narrowing framework

[Sean Whitton]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for an update to helm.

* Package name: helm
  Version : 1.9.7-1
  Upstream Author : Thierry Volpiatto 
* URL : https://emacs-helm.github.io/helm/
* License : GPL-3+
  Section : lisp

Changes since the last upload:

  * Package new upstream version.
  * Refresh patch.

Download with dget:

dget -x http://mentors.debian.net/debian/pool/main/h/helm/helm_1.9.7-1.dsc

Or build it with gbp:

gbp clone --pristine-tar 
https://anonscm.debian.org/git/pkg-emacsen/pkg/helm.git
cd helm
gbp buildpackage

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#821676: graphviz: Disable PHP bindings

[GCS]

Hi Ondřej,

On Fri, Jun 10, 2016 at 7:54 AM, Ondřej Surý  wrote:
> could you please apply attached patch that disable PHP bindings. It
> doesn't look like swig is going to be updated any time soon and graphviz
> is one of the last packages preventing src:php5 removal from testing.
 I had a false hope upstream will do the update; as the
bugreport[1][2] states: "I've done most of the PHP backend work
recently, but this is not something I'm likely to have time to work on
in the near future." But it seems things don't improve, will do the
upload to disable the PHP5 bindings in the afternoon.

Thanks for the heads-up,
Laszlo/GCS
[1] http://www.graphviz.org/mantisbt/view.php?id=2584
[2] https://github.com/swig/swig/issues/571

Bug#823186: chromium: crashes on many websites

[Michael Gilbert]

> How about stack traces from a first message? Are they useless?

Without debugging symbols, basically yes.

> If you want full backtrace from gdb then describe how to get if, because
> usual approach (gdb  --> run --> segfault --> bt full) will not
> work with chromium as far as I understand.

https://wiki.debian.org/AutomaticDebugPackages

Also see "man chromium".

Best wishes,
Mike

Bug#813096: ITP: logdata-anomaly-miner -- lightweight tool for log checking, log analysis

[Fiedler Roman]

> Von: Gianfranco Costamagna [mailto:locutusofb...@debian.org]
>
> Hi,
>
> new issues:
>
> please change python-dev to python-all (you have an arch:all package here)

Changed the Build-Depends, binary depends  are now generated by dh_python2.

> patches have useless description, please make a real one (bonus if you
> rename patches to end with .patch)

Ah, I see. I assumed that the patch editor would cut the lower part in same 
fashion as git/svn would do. Fixed.

> rules: useless the dk_link stuff (you already have a file.link).

Done.

> you can grab some of the above fixes from here, please do the remaining 
> stuff
> http://debomatic-amd64.debian.net/debomatic/unstable/pool/logdata-anomaly-miner_0.0.2-1/logdata-anomaly-miner_0.0.2-1_sourceupload.changes
> (debdiff is a good friend, to show them)

I will check, if the above link contains more useful fix when back home from 
travelling, here this is somehow problematic.

Package with fixes for changes mentioned above uploaded to mentors, should be 
visible in some minutes hopefully.

Roman



smime.p7s
Description: S/MIME cryptographic signature

Bug#821676: graphviz: Disable PHP bindings

[Ondřej Surý]

Control: tags -1 +patch

Hi Laszlo,

could you please apply attached patch that disable PHP bindings. It
doesn't look like swig is going to be updated any time soon and graphviz
is one of the last packages preventing src:php5 removal from testing.

If you don't have a time, I am prepared to do an NMU. Please let me know
how to proceed.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Potřeby pro pečení chleba
všeho druhu

Bug#821617: Bumping severity of PHP 7.0 transition bugs to serious

[Ondřej Surý]

Hi Jeremy,

the lintian hasn't been updated yet, so please ignore the warnings about
php-cli and go ahead and upload the package if it works for you.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Potřeby pro pečení chleba
všeho druhu

On Fri, Jun 10, 2016, at 06:40, Jeremy T. Bouse wrote:
> Haven't reached out to confirm with upstream but as the website states
> "Swift Mailer integrates into any web app written in PHP 5, ..." I'm not
> exactly certain PHP 7 is a concern. I have attempted to build latest
> version 5.4.2 under Sid following the suggestions in the ticket and the
> package doesn't pass lintian checks when it uses php-cli instead of
> php5-cli. The build itself is using pkg-php-tools to build and it is
> simply a PHP class not compiled code.
> 
> On 5/5/2016 4:20 AM, Ondřej Surý wrote:
> > Dear maintainer(s),
> >
> > I am bumping the severity of this bug to serious, as we are going to
> > remove src:php5 from Debian and your package is blocking the first
> > step which is removal of php5 from testing.  Please either update your
> > package to support PHP 7.0 or remove the package from Debian unstable
> > alltogether.
> >
> > Cheers,
> > Ondrej
> >
> 

Bug#826928: lsb-release: Error while kernel installation

[Roman Horn�k]

Package: lsb-release
Version: 9.20160601
Severity: normal


/etc/kernel/header_postinst.d/dkms:
Traceback (most recent call last):
  File "/usr/bin/lsb_release", line 25, in 
import lsb_release
ImportError: No module named 'lsb_release'



-- Package-specific info:
lsb_release output
-*- -*- -*- -*- -*-
-*- -*- -*- -*- -*-
Apt policy
-*- -*- -*- -*- -*-
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 http://linux.dropbox.com/debian sid/main amd64 Packages
 release o=Dropbox.com,a=sid,n=sid,l=Dropbox Debian 
Repository,c=main,b=amd64
 origin linux.dropbox.com
 500 http://linux.dropbox.com/debian sid/main i386 Packages
 release o=Dropbox.com,a=sid,n=sid,l=Dropbox Debian Repository,c=main,b=i386
 origin linux.dropbox.com
 500 http://mozilla.debian.net experimental/firefox-aurora i386 Packages
 release o=Debian Mozilla Team,a=experimental,n=experimental,l=Debian 
Mozilla Team,c=firefox-aurora,b=i386
 origin mozilla.debian.net
 500 http://mozilla.debian.net experimental/firefox-aurora amd64 Packages
 release o=Debian Mozilla Team,a=experimental,n=experimental,l=Debian 
Mozilla Team,c=firefox-aurora,b=amd64
 origin mozilla.debian.net
   1 http://ftp.cz.debian.org/debian experimental/main i386 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=i386
 origin ftp.cz.debian.org
   1 http://ftp.cz.debian.org/debian experimental/main amd64 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=amd64
 origin ftp.cz.debian.org
   1 http://ftp.cz.debian.org/debian experimental/non-free i386 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=non-free,b=i386
 origin ftp.cz.debian.org
   1 http://ftp.cz.debian.org/debian experimental/non-free amd64 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=non-free,b=amd64
 origin ftp.cz.debian.org
   1 http://ftp.cz.debian.org/debian experimental/contrib i386 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=contrib,b=i386
 origin ftp.cz.debian.org
   1 http://ftp.cz.debian.org/debian experimental/contrib amd64 Packages
 release o=Debian,a=experimental,n=experimental,l=Debian,c=contrib,b=amd64
 origin ftp.cz.debian.org
 500 http://ftp.cz.debian.org/debian sid/main i386 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=i386
 origin ftp.cz.debian.org
 500 http://ftp.cz.debian.org/debian sid/main amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
 origin ftp.cz.debian.org
 500 http://ftp.cz.debian.org/debian sid/non-free i386 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=i386
 origin ftp.cz.debian.org
 500 http://ftp.cz.debian.org/debian sid/non-free amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=amd64
 origin ftp.cz.debian.org
 500 http://ftp.cz.debian.org/debian sid/contrib i386 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=i386
 origin ftp.cz.debian.org
 500 http://ftp.cz.debian.org/debian sid/contrib amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=amd64
 origin ftp.cz.debian.org
Pinned packages:
-*- -*- -*- -*- -*-
   sources.list
-*- -*- -*- -*- -*-
deb http://ftp.cz.debian.org/debian/ sid contrib non-free main 
deb-src http://ftp.cz.debian.org/debian/ sid main non-free contrib  
deb http://ftp.cz.debian.org/debian/ experimental contrib non-free main  
deb http://mozilla.debian.net/ experimental firefox-aurora 
-*- -*- -*- -*- -*-
 /etc/lsb_release
-*- -*- -*- -*- -*-
- none

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

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

Versions of packages lsb-release depends on:
ii  distro-info-data  0.29
pn  python3:any   

Versions of packages lsb-release recommends:
ii  apt  1.3~exp1

Versions of packages lsb-release suggests:
pn  lsb  

-- no debconf information

Bug#822197: sphinx: please remove memory addresses from generated python documentation

[Alexis Bienvenüe]

Control: tags -1 + fixed-upstream

Now fixed upstream:
https://github.com/sphinx-doc/sphinx/commit/09c25443ff8bbfb745b717658523f2c218bbf843

Regards,
Alexis Bienvenüe.

Bug#826910: libpam-modules: pam_open_session() causes libasan to report a memory leak

[Nye Liu]

On Jun 9, 2016 7:43 PM, Steve Langasek  wrote:
>
> And what makes you so sure this is a pam bug, rather than a libasan bug (or
> a glibc bug)?

Definitely not sure. I tried various apps dlopening other libraries (both PAM 
and nonPAM) and none showed a leak, only pam_open_session().

> Compiling without -lasan and running under valgrind doesn't show any such
> leak.

I can confirm this. I had the same result (no leak) with valgrind. Did not 
check if it was a default suppression though.

>And running pamtest under 'ltrace -e dlopen+dlclose -l
> /lib/x86_64-linux-gnu/libdl.so.2' shows an equal number of calls to dlopen()
> and dlclose().
>
> So I don't see any way that this is a pam bug.

If you think it appropriate I can log it against both glibc and libasan.



MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.

Bug#826646: Incorrect handling with initial_cwd variable

[Серж ИвановЪ]

Our friends at Ubuntu released initial_cwd security patch correctly from
the start.

Here is a relevant change log:
http://changelogs.ubuntu.com/changelogs/pool/main/e/exim4
/exim4_4.82-3ubuntu2.1/changelog

"debian/patches/CVE-2016-1531-4.patch: delay chdir(/) until we opened the
main config."

Some feedback would be greatly appreciated.

Bug#826896: xul-ext-noscript: incompatible with firefox-esr in jessie

[Vagrant Cascadian]

Control: fixed 826896 2.9.0.11-1

On 2016-06-09, David Prévot wrote:
> On Thu, Jun 09, 2016 at 03:39:00PM -0700, Vagrant Cascadian wrote:
>> Apparently, the xul-ext-noscript package in jessie is incompatible
>> with the new firefox-esr security update just released.
>
> Thank you for your report.

Thanks for the quick response!


>> I presume this is fixed in stretch/sid versions of xul-ext-noscript.
>
> Can you please check that it does? I just rebuilt it in a Jessie chroot:
>
> https://people.debian.org/~taffit/xul/xul-ext-noscript_2.9.0.11-1~deb8u1_all.deb

I tried this myself (rebuilding 2.9.0.11-1 on jessie), and it appears to
work.


FWIW, I also did the same with xul-ext-tabmixplus, though I should
probably report a separate bug about that...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#826927: new upstream (2.1.0.0)

[Daniel Baumann]

Package: ansible
Severity: wishlist

Hi,

it would be nice if you could upgrade to the current upstream version 
(2.1.0.0).


Regards,
Daniel

Bug#821617: Bumping severity of PHP 7.0 transition bugs to serious

[Jeremy T. Bouse]

Haven't reached out to confirm with upstream but as the website states
"Swift Mailer integrates into any web app written in PHP 5, ..." I'm not
exactly certain PHP 7 is a concern. I have attempted to build latest
version 5.4.2 under Sid following the suggestions in the ticket and the
package doesn't pass lintian checks when it uses php-cli instead of
php5-cli. The build itself is using pkg-php-tools to build and it is
simply a PHP class not compiled code.

On 5/5/2016 4:20 AM, Ondřej Surý wrote:
> Dear maintainer(s),
>
> I am bumping the severity of this bug to serious, as we are going to
> remove src:php5 from Debian and your package is blocking the first
> step which is removal of php5 from testing.  Please either update your
> package to support PHP 7.0 or remove the package from Debian unstable
> alltogether.
>
> Cheers,
> Ondrej
>

Bug#826661: RFS: groonga/6.0.4-1

[Kentaro Hayashi]

Hi,

Thank you for reviewing!

> Hi, I did a debdiff between them, and I see some changes that might be ABI 
> breaking the library:
> 
> -GRN_API grn_rc grn_timeval_now(grn_ctx *ctx, grn_timeval *tv);
> -GRN_API grn_rc grn_timeval2str(grn_ctx *ctx, grn_timeval *tv, char *buf, 
> size_t buf_size);
> -struct tm *grn_timeval2tm(grn_ctx *ctx, grn_timeval *tv, struct tm 
> *tm_buffer);
> -grn_rc grn_str2timeval(const char *str, uint32_t str_len, grn_timeval *tv);
> 
> 
> removing symbols might be an ABI break

The above functions are kept in lib/time.c. They are not removed.

> also adding a field to a struct
> +  grn_bool is_dirty;
> 
> (not always)
> 
> as well as adding them in the middle of a struct
> -  uint32_t reserved[1003];
> +  uint32_t n_dirty_opens;
> +  uint32_t reserved[1002];
> grn_pat_delinfo delinfos[GRN_PAT_NDELINFOS];
> grn_id garbages[GRN_PAT_MAX_KEY_SIZE + 1];

The n_dirty_opens is added, but it is just allocated from reserved area. 
so it keeps compatibility.
 
> so, please answer wrt ABI/API breakage.

I've contacted upstream author, and heard the following policy about Groonga 
ABI.

There are two kind of policy about ABI for Groonga.

* experimental APIs
  Groonga is shipped every month. The new release sometimes contains 
experimental API.
  There is no guarantee for it. It may be suddenly changed. Even though such a 
case,
  it doesn't regarded as ABI breakage because it is experimental.
* stable APIs
  if this kind of APIs are changed, it needs to be raise ABI version, 
  but these APIs are not changed yet.


pgpxPRwzegvjw.pgp
Description: PGP signature

Bug#826924: O: xpad -- sticky notes

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I don't intend to maintain it anymore since I
lost interest. Anyone interested... go ahead. 

Bug#826926: O: gnome-mastermind -- mastermind clone for gnome

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I don't intend to maintain it anymore since I
lost interest. Anyone interested... go ahead. 

Bug#826925: O: pipewalker -- puzzle game

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I don't intend to maintain it anymore since I
lost interest. Anyone interested... go ahead. 

Bug#826923: O: speedcrunch -- calculator

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I don't intend to maintain it anymore since I
lost interest. Anyone interested... go ahead. 

Bug#823917: strip-nondeterminism: strip timestamps from nested zip files

[Andrew Ayer]

On Tue, 10 May 2016 13:58:21 +0200
Emmanuel Bourg  wrote:

> I noticed that the bnd package fails to build reproducibly because
> one of the jar files installed (/usr/share/java/bnd-2.4.1.jar)
> contains a nested jar (embedded-repo.jar) that isn't processed by
> dh_strip_nondeterminism. The timestamps in bnd-2.4.1.jar are properly
> replaced, but the ones in embedded-repo.jar still reflect the actual
> build date.
> 
> It would be nice if strip-nondeterminism was able to process the
> nested zip files automatically.

Excellent idea!  I've implemented this in strip-nondeterminism 0.019,
which I'm uploading right now.

Cheers,
Andrew

Bug#826922: openafs-modules-dkms: FTBFS against linux 4.6: errors in function afs_linux_read_cache: PAGE_CACHE_SIZE undeclared

[Carl Suster]

Package: openafs-modules-dkms
Version: 1.6.18-1
Severity: important

Dear Maintainer,

Trying to build the openafs dkms module against kernel 4.6.0-1-amd64 results in
the following errors taken from the attached log:

/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:
 In function ‘afs_linux_read_cache’:
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:1987:29:
 error: ‘PAGE_CACHE_SIZE’ undeclared (first use in this function)
  zero_user_segment(page, 0, PAGE_CACHE_SIZE);
 ^
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:1987:29:
 note: each undeclared identifier is reported only once for each function it 
appears in
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:1996:54:
 error: ‘PAGE_CACHE_SHIFT’ undeclared (first use in this function)
 pageindex = (offset - AFS_CHUNKTOBASE(chunk)) >> PAGE_CACHE_SHIFT;
  ^
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:2014:10:
 error: implicit declaration of function ‘page_cache_get’ 
[-Werror=implicit-function-declaration]
  page_cache_get(cachepage);
  ^
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:2019:3:
 error: implicit declaration of function ‘page_cache_release’ 
[-Werror=implicit-function-declaration]
   page_cache_release(newpage);
   ^
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:
 In function ‘afs_linux_bypass_readpages’:
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:2331:52:
 error: ‘PAGE_CACHE_SHIFT’ undeclared (first use in this function)
  isize = (i_size_read(fp->f_mapping->host) - 1) >> PAGE_CACHE_SHIFT;
^
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:
 In function ‘afs_linux_bypass_readpage’:
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:2418:27:
 error: ‘PAGE_CACHE_SIZE’ undeclared (first use in this function)
  zero_user_segment(pp, 0, PAGE_CACHE_SIZE);
   ^
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:
 In function ‘afs_linux_writepage’:
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:2766:23:
 error: ‘PAGE_CACHE_SIZE’ undeclared (first use in this function)
 unsigned int to = PAGE_CACHE_SIZE;
   ^
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:
 In function ‘afs_linux_prepare_write’:
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:2934:44:
 error: ‘PAGE_CACHE_SIZE’ undeclared (first use in this function)
  zero_user_segments(page, 0, from, to, PAGE_CACHE_SIZE);
^
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:
 In function ‘afs_linux_write_end’:
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:2958:32:
 error: ‘PAGE_CACHE_SIZE’ undeclared (first use in this function)
 unsigned int from = pos & (PAGE_CACHE_SIZE - 1);
^
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:
 In function ‘afs_linux_write_begin’:
/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:2973:28:
 error: ‘PAGE_CACHE_SHIFT’ undeclared (first use in this function)
 pgoff_t index = pos >> PAGE_CACHE_SHIFT;

/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.c:2974:32:
 error: ‘PAGE_CACHE_SIZE’ undeclared (first use in this function)
 unsigned int from = pos & (PAGE_CACHE_SIZE - 1);
^
cc1: some warnings being treated as errors
/usr/src/linux-headers-4.6.0-1-common/scripts/Makefile.build:296: recipe for 
target 
'/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.o'
 failed
make[6]: *** 
[/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP/osi_vnodeops.o]
 Error 1
/usr/src/linux-headers-4.6.0-1-common/Makefile:1446: recipe for target 
'_module_/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP'
 failed
make[5]: *** 
[_module_/var/lib/dkms/openafs/1.6.18/build/src/libafs/MODLOAD-4.6.0-1-amd64-SP]
 Error 2
Makefile:146: recipe for target 'sub-make' failed



Cheers,
Carl


-- 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.5.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to

Bug#826919: O: berusky -- game

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I don't intend to maintain it anymore since I
lost interest. Anyone interested... go ahead. 

Bug#826920: O: berusky-data -- game data

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I don't intend to maintain it anymore since I
lost interest. Anyone interested... go ahead. 

Bug#826921: O: freedroidrpg -- RPG

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I don't intend to maintain it anymore since I
lost interest. Anyone interested... go ahead. 

Bug#826917: O: catdvi

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I don't intend to maintain it anymore since I
lost interest. Anyone interested... go ahead. 

Bug#826918: qcomicbook -- viewer for comic books

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I don't intend to maintain it anymore since I
lost interest. Anyone interested... go ahead. 

Bug#826915: O: gxmessage -- xmessage clone based on GTK+

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I don't intend to maintain it anymore since I
lost interest. Anyone interested... go ahead. 

Bug#826914: O: nethogs -- net top tool

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I don't intend to maintain it anymore since I
lost interest. Anyone interested... go ahead. 

Bug#826916: O: gnubik -- Rubik's cube game

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I don't intend to maintain it anymore since I
lost interest. Anyone interested... go ahead. 

Bug#826913: O: abe -- side scrolling game

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package. I don't intend to maintain it anymore since I 
lost interest. Anyone interested... go ahead.

Bug#826909: Module load path apparently changed, many programs don't work

[Diederik de Haas]

Package: python3.5
Version: 3.5.1-14
Followup-For: Bug #826909

I can confirm this issue (with lsb_release) and I also get a similar 
error on debtags:

root@bagend:/home/diederik# aptitude update
Hit http://debug.mirrors.debian.org/debian-debug unstable-debug InRelease
Hit http://ftp.nl.debian.org/debian testing InRelease
Hit http://ftp.nl.debian.org/debian sid InRelease
Hit http://ftp.nl.debian.org/debian experimental InRelease
Hit http://debug.mirrors.debian.org/debian-debug experimental-debug
InRelease
100% [Working]Traceback (most recent call last):
  File "/usr/bin/debtags", line 25, in 
  import apt
  ImportError: No module named 'apt'


Downgrading idle-python3.5 libpython3.5 libpython3.5-minimal
libpython3.5-stdlib python3.5 python3.5-minimal (the python3.5 package I
have installed) to version 3.5.1-13 fixes this issue.


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

Kernel: Linux 4.6.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 python3.5 depends on:
ii  libpython3.5-stdlib  3.5.1-14
ii  mime-support 3.60
ii  python3.5-minimal3.5.1-14

python3.5 recommends no packages.

Versions of packages python3.5 suggests:
ii  binutils2.26-10
pn  python3.5-doc   
pn  python3.5-venv  

-- no debconf information

Bug#826891: disorderfs: Files created on a disorderfs mount don't seem to respect umask

[Andrew Ayer]

Hi Ceridwen,

Thanks for reporting this!  I've identified and fixed the bug.  This fix
is in disorderfs 0.4.3-1, which I'm uploading to Unstable right now.

Cheers,
Andrew

Bug#826912: override: gnome-taquin:games/optional

[Jeremy Bicha]

Package: ftp.debian.org
Severity: normal

In version 3.20.2-2, I corrected the installation of the game
executable to /usr/games/ instead of /usr/bin/ . Lintian then warned
me about games-package-should-be-section-games so I changed the
section to games too.

Thanks,
Jeremy Bicha

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.4.0-23-generic
Debian Release: stretch/sid

Bug#826864: epubcheck doesn't run anymore

[Markus Koschany]

On 09.06.2016 19:20, Eugene Zhukov wrote:
> Hi Joseph,
> 
> Thank you for the bug report. Unfortunately I'm away from keyboard until
> Monday.
> I see you found this bug in Debian stable release, can you also
> reproduce this with Debian testing/unstable (if you have a possibility
> to try of course)?
> 
> @debian-java the package is team maintained, if anyone has time
> ATM please take a look, it's marked as 'grave'.
> 
> Eugene

Hi,

FYI, it is team-maintained but not by debian-java.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#826301: flashplugin-nonfree: update-flashplugin-nonfree --install fails to download updated version

[Marc J. Driftmeyer]

Good. Glad we did. The thing has been outdated and crapping on every web 
site across the Internet. It takes 5 minutes to build a new hash and 
update the package being pulled.


It only took nearly 2 weeks of it to get your attention. Don't fret 
none. In a year or so all sites will have flash removed and you can go 
eventually abandon the package.


It may annoy you, but you took on the responsibility for such an 
irritating package, which such broad impact, that you'd think making a 
cron job that weekly checks whether a newer update is ready and then 
sends you a note when it is would help you monitor the package in a more 
timely manner.


- Marc



On 06/09/2016 03:06 PM, John Paul Adrian Glaubitz wrote:

Jesus Christ, people! There are actually seven duplicates of the *SAME* bug 
report?

Do you people even bother these days to check for existing bug reports or do 
you just
file a new bug right away and always assume you're the first one?

Seriously, how hard is it to open your browser and point it to bugs.debian.org, 
then
type "flashplugin-nonfree" and then hit "Search"? And if you're using 
"reportbug",
it *will* actually show you all the existing bug reports.

Please be more considerate in the future. You guys produced a lot of 
unnecessary noise!

There is no need to assume what with a package that is being installed by 
thousands of
users, that *you* will have been the first one to discover this particular 
issue.
Is there?

So, for the next time: *Before* reporting a bug, *please* check for existing 
bug reports!

Thank you!

Adrian



--

Marc J. Driftmeyer

main: m...@reanimality.com 
book: m...@holoworlds.net 
main:www.reanimastudios.com 
book:www.holoworlds.net 

Bug#826824: openslide: OpenJPEG removal

[Benjamin Gilbert]

OpenSlide 3.4.1 supports the new API.

Bug#826301: flashplugin-nonfree: update-flashplugin-nonfree --install fails to download updated version

[John Paul Adrian Glaubitz]

On 06/10/2016 05:06 AM, jerojasro wrote:
> Regardless of whether what you say is correct or not (it's not, but let's

Yes, it is. Go to the actual URL of this bug report and check what it says
at the top:

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

"Merged with 820583, 820975, 820993, 824367, 826369, 826618, 826777"

When you reported the bug report, there have been already four people
before you reporting this bug report. And you even used the "reportbug"
utility which was actually showing you existing bug reports on this
package. Yet you couldn't be bothered to read what's on the screen,
you typed "skip and file a new bug report".

Why did you think it was good idea to file the same bug report again?

> not lose ourselves nitpicking), you are being needlessly rude/patronizing to
> other people; what might be obvious to you is not necessarily so to us bug
> reporters.

No, you guys were being rude by ignoring the guidelines for reporting bugs [1].

It clearly says:

"If there is an existing bug report #, you should submit your comments
 by sending e-mail to @bugs.debian.org instead of reporting a new bug."

> Please leave that attitude outside Debian; you achieve nothing, damage the
> reputation of the project, and discourage people from contributing with bug
> reports.

Please learn how to use the bug tracker properly. Be more considerate and check
for existing bug reports before opening a new one. Read the guidelines, check
for the output of "reportbug" and don't just ignore what's on the screen
before hitting "submit".

> Go enjoy the summer, I hear it's nice and warm in Berlin.

Don't be ridiculous. Don't try to distract from the topic!

Thanks!
Adrian

> [1] https://www.debian.org/Bugs/Reporting

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#808626: [pkg-boost-devel] Bug#808626: NMU diff

[Steve M. Robbins]

On June 9, 2016 02:17:58 PM dann frazier wrote:
> Here's an updated NMU diff for #808626 that also addresses
> #819090. I've gone ahead and uploaded this to the DELAYED/10
> queue. Happy to accelerate or remove it based on feedback from the
> boost maintainers.

Thanks for this!  Looks OK to me.  I have no problem with you accelerating it.

-Steve


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

Bug#826301: flashplugin-nonfree: update-flashplugin-nonfree --install fails to download updated version

[jerojasro]

Dear John Paul Adrian,

Regardless of whether what you say is correct or not (it's not, but let's
not lose ourselves nitpicking), you are being needlessly rude/patronizing to
other people; what might be obvious to you is not necessarily so to us bug
reporters.

Please leave that attitude outside Debian; you achieve nothing, damage the
reputation of the project, and discourage people from contributing with bug
reports.

Go enjoy the summer, I hear it's nice and warm in Berlin.

Cheers,

-- 
Javier Rojas

Bug#825695: udd todo: List unsolved security issues in the TODO list?

[Paul Wise]

On Fri, Jun 10, 2016 at 6:19 AM, Petter Reinholdtsen wrote:

> I am not quite sure what the ** part of the urgency mean.

Not sure why they are showing up in the UDD database, but the
explanations are at the bottom of this:

https://security-tracker.debian.org/tracker/status/release/stable

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1

[Joe Stringer]

On 9 June 2016 at 08:50, Terry Wilson  wrote:
> On Thu, Jun 9, 2016 at 3:07 AM, Russell Bryant  wrote:
>> The real solution to making this less awkward would be to split the Python
>> library out of the OVS git tree so that it can be released independently of
>> OVS itself.  That way a proper verison could be released that includes
>> Python 3 support.
>
> This would be very nice. There are some challenges to overcome. The
> testing infrastructure between the Python and C implementations is
> shared. Out of tree it becomes more a bit more difficult to make sure
> that they stay in sync both feature and compatibility-wise. My gut
> feeling is that it would still be worth the work, though. There's no
> good reason for releases of the Python library to be tied OVS
> releases.

Setting aside the python3 compatibility issues, the typical number of
commits to this library between releases is pretty small (<10). They
seem to be largely independent of other changes in the OVS tree, but
occasionally they are coupled to other changes.

Is the proposal really fixing an ongoing issue or just a one-off? It
seems like a lot of effort unless the pace of development on this
library significantly increases and users really need a more frequent
release cycle (for example, because they're releasing versions of
their software more regularly than the OVS and need the latest and
greatest python-ovs).

Bug#826910: libpam-modules: pam_open_session() causes libasan to report a memory leak

[Steve Langasek]

Control: tags -1 moreinfo

On Thu, Jun 09, 2016 at 07:09:46PM -0700, Nye Liu wrote:
> Package: libpam-modules
> Version: 1.1.8-3.3
> Severity: minor

> Dear Maintainer,

> pam_open_session() causes libasan to report a memory leak due to dl_open:

> ==32701==ERROR: LeakSanitizer: detected memory leaks

> Direct leak of 4096 byte(s) in 1 object(s) allocated from:
> #0 0x7f44685c8f4a in malloc 
> (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x93f4a)
> #1 0x7f446964e101  ()

> A dump of proc/xxx/maps shows 0x7f446964e101 to be in ld-2.22.so, dl_open

> pamtest.c to demonstrate the bug:
> 
> // compile with: gcc pamtest.c -lasan -lpam -lpam_misc -o pamtest
> // "pamtest" will fail, "pamtest 0" succeeds

And what makes you so sure this is a pam bug, rather than a libasan bug (or
a glibc bug)?

Compiling without -lasan and running under valgrind doesn't show any such
leak.

And running pamtest under 'ltrace -e dlopen+dlclose -l
/lib/x86_64-linux-gnu/libdl.so.2' shows an equal number of calls to dlopen()
and dlclose().

So I don't see any way that this is a pam bug.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

Bug#814316: Fetch flashplugin-nonfree archive from Macromedia directly?

[Elliott Mitchell]

The problem for flashplugin-nonfree is verifying the tarball that is
downloaded.  Adobe isn't making this easy since they don't provide any
form of conventional signature (PGP).  Thus Bart Martens had been doing
the rather unenviable job of having to approve Flash Player somehow.  The
approach had been from signatures downloaded from people.debian.org.

Problem is this only works as long as Bart Martens is able to check and
sign the releases promptly.  This is now breaking down since Bart Martens
is either having difficulty verifying the current release, is unavailable
(I hope Bart hasn't met an unfortunate end!), or is otherwise indisposed.


The only thing approximating an alternative I'm aware of is the one that
has been pointed out earlier on this bug (#814316).  Adobe now has HTTPS
available on the webserver where Flash Player gets downloaded from.
Problem is SSL/TLS isn't really meant as a strong verifier for the source
of downloads and I doubt they're using sufficiently long keys to provide
good verification anyway.

Net result, we've got a bunch of Truly Bad(tm) "alternatives" that are
all horrendously insecure.  I suppose HTML5 may provide something that
is less Bad(tm), but that merely means different forms of Bad(tm).


Thank you Bart Martens for your long reasonably sane handling of this
stupidly insecure insanity, I hope you merely needed a break and haven't
met your end.

Now we need to do something about this Bad(tm) situation that isn't
absolutely horrible.

Looks like we've currently got eight bugs that duplicate #814316 (820583,
820975, 820993, 824367, 826301, 826369, 826618, 826777) and I'm
suspecting there will be more new bugs before this is solved.  :-(


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

Bug#826911: pepperflashplugin-nonfree: Missing man page for update-pepperflashplugin-nonfree

[Carl Suster]

Package: pepperflashplugin-nonfree
Version: 1.8.2+nmu1
Severity: normal

Dear Maintainer,

The binary for updating pepperflash is missing a man page.

Additionally, the help text leaves out some flags such as --unverified which
are only discoverable by inspecting the source.

-- 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.5.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pepperflashplugin-nonfree depends on:
ii  binutils   2.26-10
ii  ca-certificates20160104
ii  debconf [debconf-2.0]  1.5.59
ii  gnupg  1.4.20-6
ii  libatk1.0-02.20.0-1
ii  libcairo2  1.14.6-1+b1
ii  libcurl3-gnutls7.47.0-1
ii  libfontconfig1 2.11.0-6.4
ii  libfreetype6   2.6.3-3+b1
ii  libgcc11:6.1.1-5
ii  libglib2.0-0   2.48.1-1
ii  libgtk2.0-02.24.30-2
ii  libnspr4   2:4.12-2
ii  libnss32:3.23-2
ii  libpango-1.0-0 1.40.1-1
ii  libpango1.0-0  1.40.1-1
ii  libstdc++6 6.1.1-5
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1
ii  libxt6 1:1.1.5-1
ii  wget   1.17.1-2

pepperflashplugin-nonfree recommends no packages.

Versions of packages pepperflashplugin-nonfree suggests:
pn  chromium   
pn  hal
pn  ttf-dejavu 
ii  ttf-mscorefonts-installer  3.6
pn  ttf-xfree86-nonfree

-- no debconf information

Bug#726148: confirmed in Jessie

[Raphaël]

Confirmed in Debian Jessie.
It incidentally affects the dpkg_reconfigure Ansible module.

> Subroutine Debconf::FrontEnd::Editor::SUPER::screenwidth redefined at 
> /usr/share/perl5/Debconf/Base.pm line 31,  line 14.
> Subroutine Debconf::FrontEnd::Editor::SUPER::screenwidth redefined at 
> /usr/share/perl5/Debconf/Base.pm line 31,  line 14.
> Subroutine Debconf::Element::Editor::Select::SUPER::value redefined at 
> /usr/share/perl5/Debconf/Base.pm line 31.
> OK

(In my case, new debconf values passed via the Ansible module are not stored on 
the remote.)

Bug#826910: libpam-modules: pam_open_session() causes libasan to report a memory leak

[Nye Liu]

Package: libpam-modules
Version: 1.1.8-3.3
Severity: minor

Dear Maintainer,

pam_open_session() causes libasan to report a memory leak due to dl_open:

==32701==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7f44685c8f4a in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x93f4a)
#1 0x7f446964e101  ()

A dump of proc/xxx/maps shows 0x7f446964e101 to be in ld-2.22.so, dl_open

pamtest.c to demonstrate the bug:

// compile with: gcc pamtest.c -lasan -lpam -lpam_misc -o pamtest
// "pamtest" will fail, "pamtest 0" succeeds

#include 
#include 

static void dump_map(int pid)
{
char cmd[80];
snprintf(cmd, 80, "cat /proc/%d/maps", pid);
system(cmd);
}

int main(int argc, char *argv[])
{
int testleak=1;
static struct pam_conv conv = { misc_conv, NULL };
char user[80];
pam_handle_t *pamh;
int ret;

if (argc>1)
testleak = atoi(argv[1]);

getlogin_r(user, 80);

ret=pam_start("pamtest", user, &conv, &pamh);

if (testleak) pam_open_session(pamh, 0);

dump_map(getpid());

if (testleak) ret=pam_close_session(pamh, PAM_SILENT);

pam_end(pamh, ret);

return 0;
}


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

Kernel: Linux 4.3.0-1-amd64 (SMP w/16 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 libpam-modules depends on:
ii  debconf [debconf-2.0]  1.5.57
ii  libaudit1  1:2.4.2-1
ii  libc6  2.22-9
ii  libdb5.3   5.3.28-11
ii  libpam-modules-bin 1.1.8-3.3
ii  libpam0g   1.1.8-3.3
ii  libselinux12.3-2+b1

libpam-modules recommends no packages.

libpam-modules suggests no packages.

-- debconf information:
  libpam-modules/disable-screensaver:


MRV Communications is a global supplier of packet and optical solutions that 
power the world’s largest networks. Our products combine innovative hardware 
with intelligent software to make networks smarter, faster and more efficient.

Bug#826909: Module load path apparently changed, many programs don't work

[Russ Allbery]

Package: python3.5
Version: 3.5.1-14
Severity: important

With the upgrade to 3.5.1-14, apparently something changed about the
module load path, and Python 3 no longer sees any modules in
/usr/lib/python3/dist-packages (maybe it expects /usr/lib/python3.5
instead?).  This broke, at least, assword, lsb-release, and pep8.

$ lsb_release 
Traceback (most recent call last):
  File "/usr/bin/lsb_release", line 25, in 
import lsb_release
ImportError: No module named 'lsb_release'

If this was an intentional transition, it probably needs Breaks or
something to indicate the incompatibility, but I don't see a mention
of it in the changelog, so I'm guessing it may be an accident of some
kind.

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

Kernel: Linux 4.5.0-2-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 python3.5 depends on:
ii  libpython3.5-stdlib  3.5.1-14
ii  mime-support 3.60
ii  python3.5-minimal3.5.1-14

python3.5 recommends no packages.

Versions of packages python3.5 suggests:
ii  binutils2.26-10
pn  python3.5-doc   
pn  python3.5-venv  

-- no debconf information

Bug#826895: slack: Consider bumping epoch

[Andrew Pollock]

On Thu, Jun 09, 2016 at 06:13:07PM -0400, Jeremy Bicha wrote:
> Package: slack
> Version: 0.15.2-7
> 
> Slack (the popular proprietary collaboration app and service) ships a
> .deb that by default adds its own apt repository.[1] Unfortunately,
> they created a naming conflict (perhaps unknowingly). Since then, it
> looks like they've renamed their package to slack-desktop but kept the
> old slack package as a transitional package, apparently about 9 months
> ago.[2]
> 
> In this case, perhaps an epoch would be appropriate if you want users
> to be able to easily install both slack-desktop and your packaged
> slack, "the configuration management program".

Thanks for the heads up, I'll get onto this soon.


signature.asc
Description: Digital signature

Bug#826908: python3-sphinx can't find rst2pdf.pdfbuilder

[Trent W. Buck]

Package: rst2pdf
Version: 0.93-4
Severity: wishlist

I'd like to use python3-sphinx instead of python-sphinx,
but doing this in sphinx's conf.py:

extensions = ['rst2pdf.pdfbuilder','sphinxcontrib.blockdiag']

...doesn't Just Work.

What steps are needed to make rst2pdf & python3-sphinx work together?

(I don't really NEED to use python3,
 I'm just trying to phase out python 2.x where I can.)


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

Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages rst2pdf depends on:
ii  python2.7.8-2
ii  python-docutils   0.12+dfsg-1
ii  python-pdfrw  0.1-3
ii  python-pkg-resources  5.5.1-1
ii  python-pygments   2.0.1+dfsg-1.1+deb8u1
ii  python-reportlab  3.1.8-3
ii  python-setuptools 5.5.1-1
ii  python-simplejson 3.6.5-1
pn  python:any

rst2pdf recommends no packages.

Versions of packages rst2pdf suggests:
pn  python-aafigure  
ii  python-imaging   2.6.1-2+deb8u2
pn  python-matplotlib
pn  python-sphinx
pn  python-uniconvertor  

-- no debconf information

Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1

[Russell Bryant]

On Thu, Jun 9, 2016 at 11:50 AM, Terry Wilson  wrote:

> On Thu, Jun 9, 2016 at 3:07 AM, Russell Bryant  wrote:
> > The real solution to making this less awkward would be to split the
> Python
> > library out of the OVS git tree so that it can be released independently
> of
> > OVS itself.  That way a proper verison could be released that includes
> > Python 3 support.
>
> This would be very nice. There are some challenges to overcome. The
> testing infrastructure between the Python and C implementations is
> shared. Out of tree it becomes more a bit more difficult to make sure
> that they stay in sync both feature and compatibility-wise. My gut
> feeling is that it would still be worth the work, though. There's no
> good reason for releases of the Python library to be tied OVS
> releases.


The next step in turning this into a real proposal would be to prototype
the split to show what the two repos would look like after the split.  It
should also document the impact on developers who need to change both, as
well as people working on just ovs (as the build system uses the python
lib).

To be clear, even though I think this is the "right" thing to do, I don't
expect I will do the work any time soon.
-- 
Russell Bryant

Bug#826907: mdadm: please configure either component device timeout or scterc to guard against scsi layer timeouts

[Henrique de Moraes Holschuh]

Package: mdadm
Version: 3.3.2-5+deb8u1
Severity: normal

madam waits forever for component devices to complete operations, but
the kernel scsi layer doesn't and may offline the device, causing md to
kick it off the array.

This is actually a very long-standing "stack integration" issue and not
an mdadm bug by itself.  I'd say it is an "integration deficiency" which
creates a risk with high impact (grave damage, low probability) on
systems not using enterprise-class hardware.  It can be fixed in several
ways, but doing it in mdadm would be the best place to deploy sanity for
this issue from a usability PoV, IMO.

Basically, most SATA HDDs will block on read-errors for up to two
minutes (during which it will retry, retry with reposition, sometimes
retry with lower spindle speed, and on the more insane firmware, even do
sync sector reallocation instead of punting it to a background task),
which is four times more than the Linux scsi layer will be willing to
wait for by default.

Enterprise HDDs are usually the only exception: even NAS-class HDDs will
cause trouble, as nearly all of them default to SCTERC (aka TLER, CCTL)
disabled at power-on (let's hope it won't get disabled by a device reset
during EH, that requires a kernel-level fix to address).

One must enable SCTERC (e.g. with smartctl -l scterr,70,500) before
starting the array (initramfs included).  Fortunately, suport for SCTERC
can be detected, and it can be queried, so one would only mess with it
when unset.  A longer write timeout might help ensure the HDD has time
to relocate the sector (there's never a good reason for an HDD with
spare sectors still available to return a write error other than a
SCTERC write timeout, or the spare tracks going bad/full).

Alternatively, mdadm could increase the timeout of sat/ata component
devices in the scsi layer, from 30s to something like 120s through
/sys/block/###/device/timeout.  This avoids worse data-loss in many
cases, but md will hang for far longer when the component device really
has gone to lalalala land...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#826906: uid-wrapper: FTBFS[!linux]: only supports libc.so.[0-9] filename

[Steven Chamberlain]

Package: uid-wrapper
Version: 1.2.0+dfsg1-1
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd

Hi,

uid-wrapper FTBFS on kfreebsd because of segfaults running every test:

| Program terminated with signal 11, Segmentation fault.
| #0  0x0008006156e1 in _dl_close () from /lib/ld-kfreebsd-x86-64.so.1
| #1  0x00080060f7d4 in _dl_catch_error () from /lib/ld-kfreebsd-x86-64.so.1
| #2  0x000800f99511 in _dlerror_run () from 
/lib/x86_64-kfreebsd-gnu/libdl.so.2
| #3  0x000800f98fef in dlclose () from /lib/x86_64-kfreebsd-gnu/libdl.so.2
| #4  0x000800825281 in uwrap_destructor () at
| /home/steven/uid-wrapper-1.2.0+dfsg1/src/uid_wrapper.c:2133
| u = 
| #5  0x00080060ff17 in _dl_fini () from /lib/ld-kfreebsd-x86-64.so.1
| #6  0x000800c69a78 in __run_exit_handlers () from 
/lib/x86_64-kfreebsd-gnu/libc.so.0.1
| #7  0x000800c69ac5 in exit () from /lib/x86_64-kfreebsd-gnu/libc.so.0.1
| #8  0x000800c551a7 in __libc_start_main () from 
/lib/x86_64-kfreebsd-gnu/libc.so.0.1
| #9  0x00400847 in _start ()
https://buildd.debian.org/status/fetch.php?pkg=uid-wrapper&arch=kfreebsd-amd64&ver=1.2.0%2Bdfsg1-1&stamp=1449681825

I found this happens because src/uid_wrapper.c doesn't detect the libc's
filename.  It matches libc.so.[0-9] whereas on kfreebsd it is named
libc.so.0.1 currently.

The same problem will affect hurd too, which has libc.so.0.3 (although
there are other reasons for FTBFS on hurd).

Please consider the attached patch to detect libc.so.0.[0-9] as well.
Unless there is some neater way to do this.  Thanks a lot!

-- 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
Init: sysvinit (via /sbin/init)
Date: Fri, 10 Jun 2016 02:06:45 +0100
From: Steven Chamberlain 
Subject: support libc soname 0.x

On some glibc-based platforms, the libc soname is not an integer, such
as 0.1 on kfreebsd and 0.3 on hurd.

--- a/src/uid_wrapper.c
+++ b/src/uid_wrapper.c
@@ -407,6 +407,11 @@
 if (handle != NULL) {
 	break;
 }
+snprintf(soname, sizeof(soname), "libc.so.0.%d", i);
+handle = dlopen(soname, flags);
+if (handle != NULL) {
+	break;
+}
 			}
 
 			uwrap.libc.handle = handle;

Bug#826905: armhf tegra package contains symlink for arm64 package

[Martin Michlmayr]

Package: u-boot
Version: 2016.03+dfsg1-5
Severity: minor

I just noticed that the armhf tegra package contains this symlink:

lrwxrwxrwx root/root 0 2016-06-09 19:10 
./usr/lib/u-boot/p2371-2180/u-boot -> uboot.elf

This as introduced by my patch to add p2371-2180 support for arm64.
Unfortunately, I don't know of a way to add the symlink only to the
arm64 package.

Note that this breaks the multiarch assumption discussed in #788689
that no u-boot package with the same name on different arches would
include the same board directory.

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

Bug#826257: jetty9: Installation fails "jetty9.pid exists, but jetty was not running"

[Jörg Plate]

> > Setting up jetty9 (9.2.16-1) ...
> > Job for jetty9.service failed because the control process exited with error 
> > code.
> > See "systemctl status jetty9.service" and "journalctl -xe" for details.
> > invoke-rc.d: initscript jetty9, action "start" failed.

> Are you able to start the service after removing the /var/run/jetty9.pid file?

# rm /var/run/jetty9.pid
# env LC_ALL=C apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up jetty9 (9.2.16-1) ...
Job for jetty9.service failed because the control process exited with
error code.
See "systemctl status jetty9.service" and "journalctl -xe" for details.
invoke-rc.d: initscript jetty9, action "start" failed.
dpkg: error processing package jetty9 (--configure):
 subprocess installed post-installation script returned error exit
 status 1
Errors were encountered while processing:
 jetty9
E: Sub-process /usr/bin/dpkg returned an error code (1)

# rm /var/run/jetty9.pid
# systemctl start jetty9
Job for jetty9.service failed because the control process exited with
error code.
See "systemctl status jetty9.service" and "journalctl -xe" for details.

Bug#826904: php-zeroc-ice: fails to upgrade from 'jessie': php-zeroc-ice.postinst: phpenmod: not found

[Andreas Beckmann]

Package: php-zeroc-ice
Version: 3.6.2-stretch+git1+6f49504-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'sid' fails.

>From the attached log (scroll to the bottom...):

  Setting up php-zeroc-ice (3.6.2-stretch+git1+6f49504-2) ...
  /var/lib/dpkg/info/php-zeroc-ice.postinst: 18: 
/var/lib/dpkg/info/php-zeroc-ice.postinst: phpenmod: not found
  dpkg: error processing package php-zeroc-ice (--configure):
   subprocess installed post-installation script returned error exit status 127


cheers,

Andreas


php-zeroc-ice_3.6.2-stretch+git1+6f49504-2.log.gz
Description: application/gzip

Bug#826836: bmon: FTBFS on kfreebsd: error: 'struct if_data' has no member named 'ifi_recvquota'

[Steven Chamberlain]

Package: bmon
Version: 1:3.8-2
Followup-For: Bug #826836

Hi,

In upstream code for BSD-ish systems, support was added for some Apple
Darwin features that are not available on other platforms.

Please find a patch attached for this.  I've run-time tested it on
kfreebsd-amd64 and it works beautifully, I wish I'd known about this
tool a long time ago!

Thanks.

-- 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
Init: sysvinit (via /sbin/init)
Date: Fri, 10 Jun 2016 01:36:33 +0100
From: Steven Chamberlain 
Subject: guard Darwin-specific features with #ifdef

Fix building on FreeBSD-based systems, by guarding Darwin-specific
features with an #ifdef

--- a/src/in_sysctl.c
+++ b/src/in_sysctl.c
@@ -232,11 +232,13 @@
 		snprintf(info_buf, sizeof(info_buf), "%u", ifm->ifm_data.ifi_metric);
 		element_update_info(e, "Metric", info_buf);
 
+#ifdef __APPLE__
 		snprintf(info_buf, sizeof(info_buf), "%u", ifm->ifm_data.ifi_recvquota);
 		element_update_info(e, "RX-Quota", info_buf);
 
 		snprintf(info_buf, sizeof(info_buf), "%u", ifm->ifm_data.ifi_xmitquota);
 		element_update_info(e, "TX-Quota", info_buf);
+#endif
 
 		element_notify_update(e, NULL);
 		element_lifesign(e, 1);

Bug#816764: zfsutils: Could be switched to use system libmd

[Steven Chamberlain]

Control: tags -1 + pending

Hi Guillem,

Guillem Jover wrote:
> On Sat, 2016-03-05 at 00:30:23 +0100, Guillem Jover wrote:
> > I noticed that this package contains an embedded version of libmd from
> > FreeBSD. This package could be switched to use the now packaged libmd
> > from the system.
> 
> I've implemented this now, but not build-tested it, just made sure the
> patch applies. Attached.

This is great, thanks a lot!

I've applied this against new upstream version 10.3, and I'm uploading
this to experimental for now.

I've done some simple run-time tests, but I think the parts that use
libmd are mostly zfs send/receive, when pools have de-duplication
enabled, which I haven't tried.

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


signature.asc
Description: Digital signature

Bug#826896: xul-ext-noscript: incompatible with firefox-esr in jessie

[David Prévot]

Hi Vagrant,

On Thu, Jun 09, 2016 at 03:39:00PM -0700, Vagrant Cascadian wrote:
> Package: xul-ext-noscript
> Version: 2.6.9.3-1

> Apparently, the xul-ext-noscript package in jessie is incompatible
> with the new firefox-esr security update just released.

Thank you for your report.

> I presume this is fixed in stretch/sid versions of xul-ext-noscript.

Can you please check that it does? I just rebuilt it in a Jessie chroot:

https://people.debian.org/~taffit/xul/xul-ext-noscript_2.9.0.11-1~deb8u1_all.deb

Thanks in advance.

Regards

David


signature.asc
Description: PGP signature

Bug#826903: biomaj: installation with skipping mysql database configuration breaks package manager

[Matthias Ernst]

Package: biomaj
Version: 1.2.3-7
Severity: critical
Tags: d-i
Justification: breaks the whole system

Dear Maintainer,

I installed a fresh debian testing using net installer.
I have used advanced graphical setup.
I selected DebianScience. When asked to configure MySQL database connection
for BioMAJ, I chose to don't configure it.
The installer preceeds some hours configuring other packages.
When configuring BioMAJ, it broke up. At this moment, GRUB has not been 
installed.
>From this point, apt-get did not do anything. It just told me it could not 
>connect to the server.
I had to reboot without grub and install grub manually in recovery mode.
sudo has not been installed at this moment. I had to apt-get purge biomaj
in recovery mode to get sudo working (I had disabled the root user).


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

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

Versions of packages biomaj depends on:
ii  ant1.9.7-3
ii  ant-contrib1.0~b3+svn177-7
ii  ant-optional   1.9.7-3
ii  debconf [debconf-2.0]  1.5.59
ii  default-jre [java6-runtime]2:1.8-57
ii  junit4 4.12-4
ii  libcommons-cli-java1.3.1-3
ii  libcommons-codec-java  1.10-1
ii  libcommons-dbcp-java   1.4-5
ii  libcommons-httpclient-java 3.1-12
ii  libcommons-logging-java1.2-1
ii  libcommons-net-java3.4-2
ii  libcommons-pool-java   1.6-2
ii  libhsqldb-java 2.3.4-1
ii  libjcommon-java1.0.16-5
ii  libjdom1-java  1.1.3-1
ii  libjets3t-java 0.8.1+dfsg-2
ii  libjgoodies-forms-java 1.6.0-4
ii  libjsch-java   0.1.53-1
ii  liblog4j1.2-java   1.2.17-7
ii  libmail-java   1.5.5-1
ii  libmysql-java  5.1.38-1
ii  liboro-java2.0.8a-11
ii  libregexp-java 1.5-3
ii  libsaxonhe-java9.5.1.1+dfsg-1
ii  mysql-client   5.6.30-1
ii  openjdk-8-jre [java6-runtime]  8u91-b14-2
ii  perl   5.22.2-1

biomaj recommends no packages.

Versions of packages biomaj suggests:
ii  blast2  1:2.2.26.20120620-10+b1
pn  mysql-server
ii  ncbi-tools-bin  6.1.20120620-10+b1

-- debconf information:
  biomaj/mysql_host:
* biomaj/mysql: false
  biomaj/mysql_login:

Bug#826890: [Pkg-javascript-devel] Bug#826890: nodejs: not Multi-Arch: foreign

[Jonas Smedegaard]

Quoting Thorsten Glaser (2016-06-10 00:38:25)
> Jonas Smedegaard dixit:
>> Uhm, wouldn't it make more sense to instead file bugreports against 
>> stuff like node-iglify, to get _more_ of Debian multiarch'ified?
>
> node-uglify is arch:all, therefore there’s nothing to be done
> for this package.

Ahh, right.  Thanks for pointing out the (now) obvious) :-)

 - Jonas

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

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


signature.asc
Description: signature

Bug#826902: inform6-compiler: Add pblorb.pl and scanblorb.pl to package

[David Griffith]

Package: inform6-compiler
Version: 6.33-1
Severity: wishlist

Dear Maintainer,

The tarball edition of the Inform6 for Unix package contains two Perl 
scripts in the contrib/ directory: pblorb.pl and scanblorb.pl These are 
for creating and extracting Blorb files.  They are required when 
compiling programs that include audio and graphical components.  Please 
add them to the Debian package.


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

Kernel: Linux 4.1.0-x86_64-linode59 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#826900: chromium: after click on a webpage, trackpad scrolling down does scroll very up

[David Côté-Tremblay]

I see that it does scroll up exactly to the point where I clicked before
scrolling down

2016-06-09 19:32 GMT-04:00 David Côté-Tremblay 
:

> Package: chromium
> Version: 51.0.2704.79-1~deb8u1
> Severity: normal
>
> Dear Maintainer,
>
> When I am on a web page, and I scroll (with trackpad) down on the page ..
> Its
> okay, but when I click somewhere on the page (even in something that does
> not
> cause any action, like clicking on "empty" space on a webpage, after that,
> if I
> scroll down, it does instead scroll up alot before letting me scroll down.
>
> This weird scrolling up happens too when I am switching from mouse scroll
> to
> trackpad scroll (but not at the other way)
>
> It is supposed to not scroll up alot when I scroll down before actually
> scrolled down. It didn't happen in past chromium versions.
>
> Thank you very much and have a great day !
>
>
>
> -- System Information:
> Debian Release: 8.5
>   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/2 CPU cores)
> Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages chromium depends on:
> ii  libasound2   1.0.28-1
> ii  libatk1.0-0  2.14.0-1
> ii  libc62.19-18+deb8u4
> ii  libcairo21.14.0-2.1+deb8u1
> ii  libcups2 1.7.5-11+deb8u1
> ii  libdbus-1-3  1.8.20-0+deb8u1
> ii  libexpat12.1.0-6+deb8u2
> ii  libfontconfig1   2.11.0-6.3
> ii  libfreetype6 2.5.2-3+deb8u1
> ii  libgcc1  1:4.9.2-10
> ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
> ii  libglib2.0-0 2.42.1-1+b1
> ii  libgnome-keyring03.12.0-1+b1
> ii  libgtk2.0-0  2.24.25-3+deb8u1
> ii  libharfbuzz0b0.9.35-2
> ii  libjpeg62-turbo  1:1.3.1-12
> ii  libnspr4 2:4.10.7-1+deb8u1
> ii  libnss3  2:3.17.2-1.1+deb8u2
> ii  libpango-1.0-0   1.36.8-3
> ii  libpangocairo-1.0-0  1.36.8-3
> ii  libpci3  1:3.2.1-3
> ii  libspeechd2  0.8-7
> ii  libstdc++6   4.9.2-10
> ii  libx11-6 2:1.6.2-3
> ii  libxcomposite1   1:0.4.4-1
> ii  libxcursor1  1:1.1.14-1+b1
> ii  libxdamage1  1:1.1.4-2+b1
> ii  libxext6 2:1.3.3-1
> ii  libxfixes3   1:5.0.1-2+b2
> ii  libxi6   2:1.7.4-1+b2
> ii  libxml2  2.9.1+dfsg1-5+deb8u2
> ii  libxrandr2   2:1.4.2-1+b1
> ii  libxrender1  1:0.9.8-1+b1
> ii  libxslt1.1   1.1.28-2+b2
> ii  libxss1  1:1.2.2-1
> ii  libxtst6 2:1.2.2-1+b1
> ii  x11-utils7.7+2
> ii  xdg-utils1.1.0~rc1+git20111210-7.4
>
> chromium recommends no packages.
>
> Versions of packages chromium suggests:
> pn  chromium-inspector  
> ii  chromium-l10n   51.0.2704.79-1~deb8u1
>
> -- no debconf information
>



-- 
David Côté-Tremblay
Programmeur Web / Administrateur Linux
imdc.technolog...@gmail.com

Services corporatifs : http://www.solib.ca/
Réparation d'ordinateurs : http://particuliers.solib.ca/
Blogue : http://www.dctremblay.com/
Twitter : http://twitter.com/DavidCTremblay
Facebook : https://www.facebook.com/dctremblay007

Bug#637386: vnc4server: blacklists wrong IP: 0.0.0.0, can lead to DoS

[Mitch Deoudes]

On 6/9/2016 5:36 PM, Ola Lundqvist wrote:

Hi Mitch

I'm not fully sure whether the remote IP address is available through
the socket. If it is, then we could probably fetch it in some way.

A possible workaround would be to avoid banning 0.0.0.0.

Patches are welcome.



I'm a bit confused...  The current code doesn't fetch the remote IP at 
all?  (It's not clear to me that it's an IPv6 vs IP4 issue in my case.  
I regularly get ssh hack attempts from IPv4 addresses.  So I'm not sure 
where the 0.0.0.0 is coming from.)  If so, then how does blacklisting 
*ever* work?


Hmm - looks like maybe that's true.  I just checked my vnc log, and saw 
the following after connecting from another machine on my local LAN.  
Looks like all connections are reported as 0.0.0.0.  I'm really 
surprised this has gone unnoticed (judging by the low post rate on this 
bug) for so long...


Thu Jun  9 19:20:46 2016
Connections: accepted: 0.0.0.0::5432

I'm afraid a patch is beyond me, though.  I've got a CS degree, but it's 
about 3 decades old, so the amount of time it would take for me to sift 
through the code to find the problem is likely very large.


Meantime, I'm happy to script up a fail2ban jail, if the IP info is 
available elsewhere.  I've seen mention that iptables can be configured 
to log such stuff, but haven't yet had the time to figure it out.  
Suggestions welcome.


mitch

Bug#826901: xrdp: use dpkg-maintscript-helper rm_conffile

[Andreas Beckmann]

Package: xrdp
Version: 0.9.0~20160601+git703fedd-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package does not properly
handle the obsolete conffile /etc/pam.d/sesman

Please use dpkg-maintscript-helper rm_conffile to properly remove this
old file also from dpkg's database, otherwise debsums will report this
as "missing":

0m41.7s ERROR: FAIL: debsums reports modifications inside the chroot:
  debsums: missing file /etc/pam.d/sesman (from xrdp package)


The following (completely untested) debian/xrdp.maintscript file should
take care of this, additionally you just need to drop the now obsolete
code from the postinst.

= 8< =
rm_conffile /etc/pam.d/sesman 0.9~
= >8 =


Cheers,

Andreas

Bug#826900: chromium: after click on a webpage, trackpad scrolling down does scroll very up

[David Côté-Tremblay]

Package: chromium
Version: 51.0.2704.79-1~deb8u1
Severity: normal

Dear Maintainer,

When I am on a web page, and I scroll (with trackpad) down on the page .. Its
okay, but when I click somewhere on the page (even in something that does not
cause any action, like clicking on "empty" space on a webpage, after that, if I
scroll down, it does instead scroll up alot before letting me scroll down.

This weird scrolling up happens too when I am switching from mouse scroll to
trackpad scroll (but not at the other way)

It is supposed to not scroll up alot when I scroll down before actually
scrolled down. It didn't happen in past chromium versions.

Thank you very much and have a great day !



-- System Information:
Debian Release: 8.5
  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/2 CPU cores)
Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages chromium depends on:
ii  libasound2   1.0.28-1
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u4
ii  libcairo21.14.0-2.1+deb8u1
ii  libcups2 1.7.5-11+deb8u1
ii  libdbus-1-3  1.8.20-0+deb8u1
ii  libexpat12.1.0-6+deb8u2
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-3+deb8u1
ii  libgcc1  1:4.9.2-10
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgnome-keyring03.12.0-1+b1
ii  libgtk2.0-0  2.24.25-3+deb8u1
ii  libharfbuzz0b0.9.35-2
ii  libjpeg62-turbo  1:1.3.1-12
ii  libnspr4 2:4.10.7-1+deb8u1
ii  libnss3  2:3.17.2-1.1+deb8u2
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpci3  1:3.2.1-3
ii  libspeechd2  0.8-7
ii  libstdc++6   4.9.2-10
ii  libx11-6 2:1.6.2-3
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.1-2+b2
ii  libxi6   2:1.7.4-1+b2
ii  libxml2  2.9.1+dfsg1-5+deb8u2
ii  libxrandr2   2:1.4.2-1+b1
ii  libxrender1  1:0.9.8-1+b1
ii  libxslt1.1   1.1.28-2+b2
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  x11-utils7.7+2
ii  xdg-utils1.1.0~rc1+git20111210-7.4

chromium recommends no packages.

Versions of packages chromium suggests:
pn  chromium-inspector  
ii  chromium-l10n   51.0.2704.79-1~deb8u1

-- no debconf information

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

[Ryan Kavanagh]

Sorry Jerad for having misspelled your name in my last message. —RAK


signature.asc
Description: PGP signature

Bug#826899: inform6-library: Inform6 Library has been updated to 6.12.1

[David Griffith]

Package: inform6-library
Version: 6.12~dfsg.1-1
Severity: normal

Dear Maintainer,

I released version 6.12.1 of the Inform 6 Standard Library a couple days 
ago.  It includes several fixes for annoying, embarrassing, and 
potentially showstopping bugs.

Here are the changes:

* TAKE ROCKS, TAKE ALL, TAKE ROCKS mistakenly tried to take things from
  an NPC if one was in the room.

* DM4 Exercise 32 failure corrected.  Also fixed a problem that caused
  Glulx to get stuck in a loop.

* L__M(##Give, 2) wasn't correctly parameterized for voices and tenses.

* Improved some nonsensical responses to DROP.

* Corrected ordering NPC to take and drop multiple objects.

* Corrected problems with DropSub and ImplicitTake.

* Faulty OOPS correction partially fixed.


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

Kernel: Linux 4.1.0-x86_64-linode59 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

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

[Ryan Kavanagh]

package opensmtpd
tags 816873 + moreinfo
thanks

Dear Jerard,

On Sat, Mar 05, 2016 at 10:50:37PM -0500, Jerad Simpson wrote:
> It seems confusing to have the debconf option, but then have it do
> nothing.

This isn't the expected behaviour :) I've tried it here and it seems to
work with various values. All of /etc/aliases, /etc/aliases.db, and
/etc/mailname are supopsed to be updated.

Perhaps you could try adding a line containing only "set -x" above the
line "set -e" in /var/lib/dpkg/info/opensmtpd.postinst and
/var/lib/dpkg/info/opensmtpd.config and sending me the output of
running "dpkg-reconfigure -phigh opensmtpd" as root?

Note that the aforementioned files will not be automatically regenerated
if you delete them: you'll need to rerun debconf/dpkg-reconfigure to
regenerate them.

Best wishes,
Ryan

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


signature.asc
Description: PGP signature

Bug#826898: dbgsym packages for conflicting packages should conflict with each other

[Ryan Kavanagh]

Package: debhelper
Version: 9.20160403
Severity: normal

[ I hope this is the right package against which to file dbgsym bugs, ]
[ if not, sorry for the noise and please feel free to reassign.   ]

In the case that packages A and B conflict with each other, packages A-dbgsym
and B-dbgsym should also conflict with each other. In no cases are A-dbgsym and
B-dbgsym ever installable together (they respectively depend on A and B), so
adding this conflicts relation shouldn't cause any problems. It would however
solve problems like the following:

W: rxvt-unicode source: binaries-have-file-conflict 
rxvt-unicode-256color-dbgsym rxvt-unicode-dbgsym 
usr/lib/debug/.build-id/15/f145db97092d59cacd8ea8df5d7ba00932f49d.debug
N:
N:The binaries appears to have overlapping files without proper conflicts
N:relation.
N:
N:Note the check is completely based on the file index for the packages.
N:Possible known false-positives include dpkg-diverts in maintainer
N:scripts.
N:
N:Severity: normal, Certainty: possible
N:
N:Check: group-checks, Type: source
N:
W: rxvt-unicode source: binaries-have-file-conflict 
rxvt-unicode-256color-dbgsym rxvt-unicode-lite-dbgsym 
usr/lib/debug/.build-id/15/f145db97092d59cacd8ea8df5d7ba00932f49d.debug
W: rxvt-unicode source: binaries-have-file-conflict rxvt-unicode-dbgsym 
rxvt-unicode-lite-dbgsym 
usr/lib/debug/.build-id/15/f145db97092d59cacd8ea8df5d7ba00932f49d.debug
etc.

Best wishes,
Ryan

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20160430.1
ii  binutils 2.26-10
ii  dh-autoreconf12
ii  dh-strip-nondeterminism  0.018-2
ii  dpkg 1.18.7
ii  dpkg-dev 1.18.7
ii  file 1:5.25-2
ii  libdpkg-perl 1.18.7
ii  man-db   2.7.5-1
ii  perl 5.22.2-1
ii  po-debconf   1.0.19

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201606

-- no debconf information

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


signature.asc
Description: PGP signature

Bug#686130: still not booting from BTRFS RAID 1 on two LVs out of the box

[Ben Hutchings]

On Thu, 2016-06-09 at 18:24 +0200, Martin Steigerwald wrote:
> Hi!
> 
> With todays Debian Sid/Experimental on my laptop this still doesn´t work 
> right, I still have to add something like – I just recognized after I 
> reinstalled initramfs-tools in a crude way after having messed it up by 
> accidentally delete /var/lib/initramfs-tools (and then recognizing that it 
> may 
> have been easier to recover it than what I did):
[...]
> So whatever local-premount/btrfs does it not sufficient for the BTRFS RAID on 
> two LVs case.

Indeed.  As explained in #565676, lvm2 only activates the VGs
containing the root, /usr and hibernate/resume devices (and only if it
can recognise that they are on LVM).  Apparently it is not generally
safe to activate all visible VGs.  But perhaps that behaviour should be
available as an *option*.  That is safe for most systems and I think it
would resolve all the issues blocking this.

(I don't really understand the purpose of running btrfs on LVM, though.
btrfs integrates logical volume management and I was under the
impression that that's the main reason to use it.  If you still need
another layer underneath then why use it at all?)

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.


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

Bug#826714: jessie-pu: package biber/1.9-3+deb8u1

[Dominic Hargreaves]

On Thu, Jun 09, 2016 at 10:00:18PM +0100, Adam D. Barratt wrote:
> On Wed, 2016-06-08 at 10:34 +0100, Dominic Hargreaves wrote:
> > As per #826667 the last perl update unfortunately broke biber too
> > (at least it causes a test failure; the actual cause is a bit unclear,
> > but the fix is taken straight from the upstream perl 5.22 fixes).
> 
> Do we know what the specific failure is? It wasn't very clear from the
> log (or I was misreading).

I don't think anyone really knows more than what's on the bug log.
There was some suggestion that really the bug is in perl, but I don't
think it's been reported as such upstream - and it does seem to only
affect this particular case.

Dominic.

Bug#826897: fai: Please avoid "fcopy: nonexisting directory error" for "default" files

[Christian Meyer]

Source: fai
Severity: normal

Hello Thomas,

I'm using FAI-server from Debian stable and basically created my very own
FAI_CONFIG.
fai.log shows various "fcopy: Nonexisting directory
/var/lib/fai/config/files/etc/..." errors.
See: http://fai-project.org/screenshots/fai.txt

The mentioned files (resolv.conf, hosts, apt/preferences) are never fcopied by
me or my configspace, but I take care about them with ainsl. Since I'm
analyzing fai-logs with faiwatch (http://wiki.fai-project.org/wiki/Faiwatch)
the error messes up the output. Of course I could filter out these lines but I
rather think these error messages should not appear since it's no error: I
don't want those files to be fcopied.

I found that /usr/lib/fai/subroutines wants to copy these files with "fcopy
-BMv".
So: Isn't it possible to test if that file(s) exist before copying them? (I
don't know: what about "fcopy -i"?)



-- System Information:
Debian Release: 8.4
  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.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#826896: xul-ext-noscript: incompatible with firefox-esr in jessie

[Vagrant Cascadian]

Package: xul-ext-noscript
Version: 2.6.9.3-1
Severity: grave
Justification: renders package unusable

Apparently, the xul-ext-noscript package in jessie is incompatible
with the new firefox-esr security update just released.

This pretty much defeats the purpose of this extension in jessie.

I presume this is fixed in stretch/sid versions of xul-ext-noscript.

live well,
  vagrant

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (130, 'testing'), (120, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

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

Versions of packages xul-ext-noscript depends on:
ii  iceweasel  45.2.0esr-1~deb8u1

xul-ext-noscript recommends no packages.

xul-ext-noscript suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#826890: [Pkg-javascript-devel] Bug#826890: nodejs: not Multi-Arch: foreign

[Thorsten Glaser]

Jonas Smedegaard dixit:

>Uhm, wouldn't it make more sense to instead file bugreports against 
>stuff like node-iglify, to get _more_ of Debian multiarch'ified?

node-uglify is arch:all, therefore there’s nothing to be done
for this package.

I even edited /var/lib/dpkg/status with sudo, to add the M-A:foreign
line to nodejs (and bump the version so apt doesn't remove it), and
then could successfully install node-uglify on x32.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#826257: jetty9: Installation fails "jetty9.pid exists, but jetty was not running"

[Emmanuel Bourg]

Le 3/06/2016 à 19:38, Jörg Plate a écrit :

> Setting up jetty9 (9.2.16-1) ...
> Job for jetty9.service failed because the control process exited with error 
> code.
> See "systemctl status jetty9.service" and "journalctl -xe" for details.
> invoke-rc.d: initscript jetty9, action "start" failed.

Hi Jörg,

Thank you for the report. Are you able to start the service after
removing the /var/run/jetty9.pid file?

Emmanuel Bourg

Bug#826835: src:libcork: please add dependency “Suggests: libcork-doc”

[Ben Finney]

Control: retitle -1 src:libcork: please add dependency “Suggests: libcork-doc”

On 09-Jun-2016, Roger Shimizu wrote:

> Actually, Gianfranco pointed this out [0] when he sponsored the
> upload. Because it's minor, he allow me to fix it afterwards.
> 
> It's already in git repo, and it will be included in next release.
> Since your report this bug, so I'll add a bug closure to d/changelog
> later.

Thank you for fixing the bug before it was reported to BTS :-)

-- 
 \ “I must say that I find television very educational. The minute |
  `\   somebody turns it on, I go to the library and read a book.” |
_o__)—Groucho Marx |
Ben Finney 


signature.asc
Description: PGP signature

Bug#825371: python-lldb-3.9: Actually depends on python-six

[Pablo Oliveira]

Hi,

On 05/26/2016 02:36 PM, Askar Safin wrote:
> Package: python-lldb-3.9
> Version: 1:3.9~svn262954-1
> Severity: normal
>
> I just created fresh Debian sid chroot environment using my tool
similar to debootstrap. I installed clang-3.9 and lldb-3.9 and started
lldb. It showed me error message about missing python module "six". So,
please, mention "python-six" (or similar) as a dependency of
"python-lldb-3.9" (or similar).

Thanks for reporting the missing dependency which has been added on the
package svn. Next package release should fix this problem.

Pablo

Bug#805067: Updated patch for #805067 (kerneloops: stop doesn't work, restart adds another kerneloops process)

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> the following patch works for me:

Unfortunately only start and stop work with that patch, but restart
does not work. :-/

Here's a bigger, but fully working patch -- with a different strategy:

--- /etc/init.d/kerneloops.backup   2015-11-14 19:35:37.0 +0100
+++ /etc/init.d/kerneloops  2016-06-10 00:13:24.356604992 +0200
@@ -19,6 +19,7 @@
 PATH=/sbin:/usr/sbin:/bin:/usr/bin
 DESC="Kernel crash collector"
 NAME=kerneloops
+DAEMON_ARGS=--nodaemon
 DAEMON=/usr/sbin/$NAME
 PIDFILE=/var/run/$NAME.pid
 SCRIPTNAME=/etc/init.d/$NAME
@@ -46,12 +47,11 @@
#   0 if daemon has been started
#   1 if daemon was already running
#   2 if daemon could not be started
-   start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON 
--test > /dev/null \
+   start-stop-daemon --start --quiet --make-pidfile --pidfile $PIDFILE 
--exec $DAEMON --background --test > /dev/null \
|| return 1
-   start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
+   start-stop-daemon --start --quiet --make-pidfile --pidfile $PIDFILE 
--exec $DAEMON --background -- \
$DAEMON_ARGS \
|| return 2
-   pidofproc $DAEMON > $PIDFILE
 }
 
 #

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

Bug#825695: udd todo: List unsolved security issues in the TODO list?

[Petter Reinholdtsen]

I had a look at the code available from
 and came up with this
drafth patch proposal.  Note, I do not really know ruby and have no way
to test if this is working as intended, so please take it as a early
draft to get some feedback.

Is this the way to get security issues into the todo list?  Note, I
decided to ignore issues with urgency unimportant.  I'm not sure if this
is a good idea, as some of those would be fit for an update via
stable-proposed-updates even if the security team do not want to release
a DSA for the issue.

diff --git a/web/inc/dmd-data.rb b/web/inc/dmd-data.rb
index 55a1ec3..ac78934 100755
--- a/web/inc/dmd-data.rb
+++ b/web/inc/dmd-data.rb
@@ -22,7 +22,7 @@ end
 
 class UDDData
   attr_accessor :debug
-  attr_reader :sources, :versions, :all_bugs, :bugs_tags, :bugs_count, 
:migration, :buildd, :dmd_todos, :ubuntu_bugs, :autoremovals, :qa, :ubuntu, 
:ustb, :udev, :dr, :doostb, :dostb, :dstb, :dtst, :lintian
+  attr_reader :sources, :versions, :all_bugs, :bugs_tags, :bugs_count, 
:migration, :buildd, :dmd_todos, :ubuntu_bugs, :autoremovals, :qa, :ubuntu, 
:ustb, :udev, :dr, :doostb, :dostb, :dstb, :dtst, :lintian, :security_issues
 
   def UDDData.parse_cgi_params(cgiparams)
 three = {'1' => '', '2' => '', '3' => ''}
@@ -119,6 +119,7 @@ class UDDData
 get_qa
 get_sources_dirty
 get_autoremovals
+get_security_issues
 get_dmd_todos
 get_ubuntu_bugs
 get_ubuntu_dirty
@@ -729,6 +730,20 @@ and source not in (select source from upload_history where 
date > (current_date
   end
   end
 
+  def get_security_issues
+@security_issues = {}
+return if @sources.empty?
+q = "SELECT sir.source, sir.release, sir.urgency, sir.issue
+   FROM security_issues_releases sir
+   WHERE sir.status != 'resolved' AND urgency != 'unimportant' AND
+ sir.source IN (SELECT source FROM mysources) 
+   GROUP BY sir.source, sir.release, sir.urgency, sir.issue;"
+rows = dbget(q)
+rows.each do |r|
+  @autoremovals[r['source']] = r.to_h
+end
+  end
+
   def get_dmd_todos
 @dmd_todos = []
 rc_bugs = @all_bugs.select { |b| ['serious', 'grave', 
'critical'].include?(b['severity']) }
@@ -894,6 +909,19 @@ and source not in (select source from upload_history where 
date > (current_date
   }
 end
 
+@security_issues.each_pair do |src, v|
+  # v: source, release, urgency, issue
+
+  @dmd_todos << {
+:shortname => "security_issue_#{src}_#{v['release']}_#{v['issue']}",
+:type => 'security issue',
+:source => src,
+:link => "http://security-tracker.debian.org/tracker/#{v['issue']}",
+:description => "Open security issue",
+:details => "#{v['issue']} for #{v['release']} (#{urgency} urgency)"
+  }
+end
+
 @dmd_todos.map do |t|
   t[:reason] = @sources[t[:source]][:reason]
   t

I've tested the SQL statement, and it present me with this list when I
run it for myself:

source| release | urgency  | issue 
--+-+--+---
 sssd | wheezy  | low  | CVE-2014-0249
 vorbis-tools | jessie  | low  | CVE-2014-9639
 vorbis-tools | wheezy  | low  | CVE-2014-9639
 vorbis-tools | wheezy  | medium** | CVE-2014-9640
 sssd | jessie  | medium** | CVE-2015-5292
 vorbis-tools | jessie  | medium** | CVE-2015-6749
 vorbis-tools | wheezy  | medium** | CVE-2015-6749

I am not quite sure what the ** part of the urgency mean.

-- 
Happy hacking
Petter Reinholdtsen

Bug#826895: slack: Consider bumping epoch

[Jeremy Bicha]

Package: slack
Version: 0.15.2-7

Slack (the popular proprietary collaboration app and service) ships a
.deb that by default adds its own apt repository.[1] Unfortunately,
they created a naming conflict (perhaps unknowingly). Since then, it
looks like they've renamed their package to slack-desktop but kept the
old slack package as a transitional package, apparently about 9 months
ago.[2]

In this case, perhaps an epoch would be appropriate if you want users
to be able to easily install both slack-desktop and your packaged
slack, "the configuration management program".


Thanks,
Jeremy Bicha

[1] deb https://packagecloud.io/slacktechnologies/slack/debian/ jessie main
[2] https://packagecloud.io/slacktechnologies/slack?page=2

$ apt show slack
Package: slack
Version: 1.2.1
Priority: optional
Section: misc
Maintainer: Slack Technologies 
Installed-Size: 25.6 kB
Depends: slack-desktop
Download-Size: 1,550 B
APT-Sources: https://packagecloud.io/slacktechnologies/slack/debian
jessie/main amd64 Packages
Description: This package moves Slack beta users over to the released
package name, 'slack-desktop'

N: There are 11 additional records. Please use the '-a' switch to see them.
$ apt show slack-desktop
Package: slack-desktop
Version: 2.0.6
Priority: optional
Section: misc
Maintainer: Slack Technologies 
Installed-Size: 148 MB
Depends: gconf2, gconf-service, libgtk2.0-0, libudev0 | libudev1,
libgcrypt11 | libgcrypt20, libnotify4, libxtst6, libnss3, python,
gvfs-bin, xdg-utils, apt-transport-https, libxss1
Suggests: libgnome-keyring0, gir1.2-gnomekeyring-1.0
Download-Size: 45.2 MB
APT-Manual-Installed: yes
APT-Sources: https://packagecloud.io/slacktechnologies/slack/debian
jessie/main amd64 Packages
Description: Slack Desktop

N: There are 12 additional records. Please use the '-a' switch to see them.

Bug#826301: flashplugin-nonfree: update-flashplugin-nonfree --install fails to download updated version

[John Paul Adrian Glaubitz]

Jesus Christ, people! There are actually seven duplicates of the *SAME* bug 
report?

Do you people even bother these days to check for existing bug reports or do 
you just
file a new bug right away and always assume you're the first one?

Seriously, how hard is it to open your browser and point it to bugs.debian.org, 
then
type "flashplugin-nonfree" and then hit "Search"? And if you're using 
"reportbug",
it *will* actually show you all the existing bug reports.

Please be more considerate in the future. You guys produced a lot of 
unnecessary noise!

There is no need to assume what with a package that is being installed by 
thousands of
users, that *you* will have been the first one to discover this particular 
issue.
Is there?

So, for the next time: *Before* reporting a bug, *please* check for existing 
bug reports!

Thank you!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#826893: [Piuparts-devel] Bug#826893: piuparts aborts with "RuntimeError: maximum recursion depth exceeded"

[Holger Levsen]

control: severiy -1 normal

On Thu, Jun 09, 2016 at 11:43:25PM +0200, Andreas Beckmann wrote:
> I never used (nor tested) the -lvm* options ...
[...] 
> My gut feeling says that this is unrelated to piuparts and you have some
> problem with your disk or lvm or the chroot. piuparts just puts a lot of
> stress on these.

Completly agreed.

;)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#805067: Patch for #805067 (kerneloops: stop doesn't work, restart adds another kerneloops process)

[Axel Beckert]

Control: tags -1 + patch

Hi,

the following patch works for me:

--- /etc/init.d/kerneloops~ 2016-06-09 23:38:45.0 +0200
+++ /etc/init.d/kerneloops  2016-06-09 23:42:08.778826206 +0200
@@ -64,7 +64,7 @@
#   1 if daemon was already stopped
#   2 if daemon could not be stopped
#   other if a failure occurred
-   start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile 
$PIDFILE --name $NAME
+   start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --name $NAME
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.

Reason seems to be that /var/run/kerneloops.pid is always empty, so
the above ignores it. (Surely not a perfect patch, but as mentioned,
it works for me).

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

Bug#826888: Spanish locale seems to use wrong 1st week definition

[Aurelien Jarno]

control: tag -1 + fixed-upstream

On 2016-06-09 21:48, Michael Meskes wrote:
> Package: locales
> Version: 2.22-11
> Severity: normal
> 
> es_ES defines week as "7;19971130;5". However, Spain should follow ISO 8601 
> which defines the first week of the year as the one containing the first 
> Thursday (aka day number 4, not 5).

The bug has been fixed upstream not so long ago by the following commit:


https://sourceware.org/git/?p=glibc.git;a=commit;h=0a410e76f551c6e6cf6d128f618208049d6a952c

It hasn't appeared in a released version yet, and will be in 2.24. We
might backport it before.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#826893: piuparts aborts with "RuntimeError: maximum recursion depth exceeded"

[Andreas Beckmann]

On 2016-06-09 23:00, Ryan Kavanagh wrote:

>  piuparts -d unstable --single-changes-list --lvm-volume 
> /dev/wd/sid-chroot ../freetuxtv_0.6.8\~dfsg1-1_amd64.changes

I never used (nor tested) the -lvm* options ...

> causes piuparts to enter an infinite loop and abort with:
> 
> RuntimeError: maximum recursion depth exceeded
> 
> This happens after a long string of errors like the following:
> 
>   dpkg: error processing archive 
> /var/cache/apt/archives/freetuxtv_0.6.6~dfsg1-1_amd64.deb (--unpack):
>unable to sync file '/var/lib/dpkg/tmp.ci//md5sums': Input/output error
>   Processing triggers for libc-bin (2.22-11) ...
>   dpkg: unrecoverable fatal error, aborting:
>unable to fsync updated status of 'libc-bin': Input/output error
>   E: Sub-process /usr/bin/dpkg returned an error code (2)
> 
> 2m15.5s DEBUG: Starting command: ['umount', '/tmp/tmpm8VEae/dev/shm']
> 2m15.5s DUMP:
>   umount: /tmp/tmpm8VEae/dev/shm: mountpoint not found
> 2m15.5s DEBUG: Command failed (status=32), but ignoring error: ['umount', 
> '/tmp/tmpm8VEae/dev/shm']

My gut feeling says that this is unrelated to piuparts and you have some
problem with your disk or lvm or the chroot. piuparts just puts a lot of
stress on these.


Andreas

Bug#765166: lintian -- False positives on - license-problem-gfdl-invariants

[Ryan Kavanagh]

Package: lintian
Version: 2.5.44
Followup-For: Bug #765166

The following License section also causes a false positive:

#
License: GFDL-1.1+
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.1 or
 any later version published by the Free Software Foundation; with no
 Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
 Texts.
#

The exact lintian error is:

E: vera source: license-problem-gfdl-invariants debian/copyright invariant part 
is: with no invariant sections, with no front-cover texts, and with no 
back-cover texts. comment: upstream comments:

AFAICT, according to [0], the above license is OK.

Adding a separate warning mentioning that the DEP5 license name should
be GFDL-NIV-1.1+ in the above case would help.

[0] https://wiki.debian.org/qa.debian.org/gfdlinvariant

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

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

Versions of packages lintian depends on:
ii  binutils  2.26-10
ii  bzip2 1.0.6-8
ii  diffstat  1.61-1
ii  file  1:5.25-2
ii  gettext   0.19.7-2
ii  hardening-includes2.8+nmu2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.29+b5
ii  libarchive-zip-perl   1.57-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-1+b1
ii  libdata-alias-perl1.20-1+b1
ii  libdpkg-perl  1.18.7
ii  libemail-valid-perl   1.198-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.413-1+b1
ii  libparse-debianchangelog-perl 1.2.0-8
ii  libperl5.22 [libdigest-sha-perl]  5.22.2-1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.41-6+b1
ii  man-db2.7.5-1
ii  patchutils0.3.4-1
ii  perl  5.22.2-1
ii  t1utils   1.39-2
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg 1.18.7
ii  libperlio-gzip-perl  0.19-1+b1
ii  perl 5.22.2-1
ii  perl-modules-5.22 [libautodie-perl]  5.22.2-1

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.7
ii  libhtml-parser-perl3.72-1
ii  libtext-template-perl  1.46-1

-- no debconf information

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


signature.asc
Description: PGP signature

Bug#825431: vlc: SIGFPE (divide by zero) while transcoding in line 551 of modules/stream_out/transcode/video.c (transcode_video_encoder_init)

[Will Aoki]

On Thu, Jun 09, 2016 at 03:27:32PM -0600, Will Aoki wrote:
> On Wed, Jun 08, 2016 at 10:14:03AM +0200, Sebastian Ramacher wrote:
> > The mail to wa...@umnh.utah.edu bounced. So let's assume it's fixed.
> 
> Fix confirmed; not replying to the bug to avoid reopening it.

I spoke too soon. The bug is not fixed in vlc 2.2.4-1~deb8u1.

Bug#637386: vnc4server: blacklists wrong IP: 0.0.0.0, can lead to DoS

[Ola Lundqvist]

Hi Mitch

I'm not fully sure whether the remote IP address is available through
the socket. If it is, then we could probably fetch it in some way.

A possible workaround would be to avoid banning 0.0.0.0.

Patches are welcome.

Best regards,

// Ola

On Thu, Jun 9, 2016 at 5:23 PM, Mitch Deoudes  wrote:
> Apparently, this is still an issue as of Xvnc 4.1.1.  (Up to date on Linux
> Mint / Ubuntu.)
>
> Last week, I started getting vnc password attempts from an unknown IP,
> resulting in the "blacklisted: 0.0.0.0" messages in the log, and the server
> refusing all connections.
>
> I would prefer not to disable blacklisting, as that just gives the attacker
> a free hand to try and brute-force my password all day. (And it seems that
> there's no way to use an encryption key instead of a password?)
>
> Is there any other way to determine the actual IP of the attacker? I could
> set up a fail2ban jail for vnc, if I could get that info from some other
> log.
>
> mitch



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

Bug#826894: diffoscope --help isn't clear that it operates on directories as well as files

[Ceridwen]

Source: diffoscope
Version: 54
Severity: minor
User: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

The --help text for diffoscope gives no indication that it operates on
directories as well as files:

usage: diffoscope [-h] [--version] [--list-tools [LIST_TOOLS]] [--debug]
  [--debugger] [--html output] [--html-dir output]
  [--text output] [--max-report-size BYTES]
  [--separate-file-diff-size BYTES]
  [--max-diff-block-lines MAX_DIFF_BLOCK_LINES]
  [--max-diff-input-lines MAX_DIFF_INPUT_LINES]
  [--fuzzy-threshold FUZZY_THRESHOLD] [--new-file] [--css url]
  [--jquery url]
  file1 file2

Highlight differences between two builds of Debian packages

positional arguments:
  file1 first file to compare
  file2 second file to compare


This should give some indication that diffoscope can compare
directories as well as files.

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

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

Bug#820982: Bug#821811: [Pkg-samba-maint] Bug#821811: samba: badlock patch breaks trust relationship

[Andrew Bartlett]

On Thu, 2016-05-26 at 11:40 +0200, Santiago Ruano Rincón wrote:
> El 23/05/16 a las 22:28, Andrew Bartlett escribió:
> > 
> > On Wed, 2016-05-18 at 15:47 -0400, Antoine Beaupré wrote:
> > > 
> > > On 2016-04-29 08:55:43, Santiago Ruano Rincón wrote:
> > > > 
> > > > Dear Samba maintainers,
> > > > 
> > > > Any updates about this bug?
> > > > 
> > > > LTS Team, anyone could help to handle it?
> > > > 
> > > > According to comment#17 in
> > > > https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1572122
> > > > Andreas Schneider prepared a fix for 3.6.25.
> > > Hi again!
> > > 
> > > Should the LTS team prepare a regression update to the wheezy
> > > version
> > > at
> > > least?
> > That would be a good idea at this point.
> > 
> > I'm happy to review things, just not had the time to switch back on
> > to
> > debian matters.
> > 
> > Andrew Bartlett
> Hi,
> 
> To the current package in git, I have added some patches imported
> from
> the Ubuntu package, versions 2:3.6.25-0ubuntu0.12.04.3 and
> 2:3.6.25-0ubuntu0.12.04.4. The debdiff is attached. Andrew, could you
> please take a look on it? Also, test package is available at:
> 
> deb https://people.debian.org/~santiago/debian santiago-wheezy/
> deb-src https://people.debian.org/~santiago/debian santiago-
> wheezy/
> 
> Please, test them. I don't have the infrastructure to actually verify
> they solve the regressions. So, if somebody else would like to claim
> this package, please do it!

Given that we have a confirmation that this addresses the issue, and
that the patches match the recommendations from upstream, I approve
this update.  Please go ahead and push it out.

Andrew Bartlett

-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba







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

Bug#826829: jessie-pu: package vorbis-tools/1.4.0-6+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Thu, 2016-06-09 at 12:22 +0200, Petter Reinholdtsen wrote:
> [Adam D. Barratt]
> > Please go ahead.
> 
> Thank you.  I uploaded the package a few seconds ago, and pushed the tag
> to git.

Flagged for acceptance.

Regards,

Adam

Bug#826335: jessie-pu: package e2fsprogs/1.42.12-2

[Adam D. Barratt]

Control: tags -1 + pending

On Tue, 2016-06-07 at 19:11 -0400, Theodore Ts'o wrote:
> On Tue, Jun 07, 2016 at 07:30:33PM +0100, Adam D. Barratt wrote:
> > 
> > It's on my to-do list to review.
> > 
> > fwiw there's not been any need to formally acknowledge NMUs via closing
> > bugs in the changelog since the BTS gained version-tracking some years
> > ago, so long as the changelog for the subsequent upload incorporates the
> > stanza from the NMU.
> 
> OK, I'll wait for you to give me a formal review of things you'd like
> change, and then I'll re-upload at that time.

After some consideration, I've decided that I'm okay with accepting the
fixes as uploaded, and as the package has already been uploaded it's not
worth a reject-and-reupload cycle purely for the package version; please
bear the convention in mind for any future uploads.

Regards,

Adam

Bug#826714: jessie-pu: package biber/1.9-3+deb8u1

[Adam D. Barratt]

On Wed, 2016-06-08 at 10:34 +0100, Dominic Hargreaves wrote:
> As per #826667 the last perl update unfortunately broke biber too
> (at least it causes a test failure; the actual cause is a bit unclear,
> but the fix is taken straight from the upstream perl 5.22 fixes).

Do we know what the specific failure is? It wasn't very clear from the
log (or I was misreading).

Regards,

Adam

Bug#826662: jessie-pu: package cmake/3.0.2-1+deb8u1

[Adam D. Barratt]

Control: tags -1 + pending

On Tue, 2016-06-07 at 16:55 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On 2016-06-07 16:22, Felix Geyer wrote:
> > The openssl 1.0.1t stable update broke the FindOpenSSL module in cmake.
> 
> It really seems like there should be a better way of implementing that 
> logic...
> 
> Please go ahead.

Uploaded and flagged for acceptance.

Regards,

Adam