Bug#814310: Debian Edu's /etc/lsb-release lacks (distro) version information

[Mike Gabriel]

Package: debian-edu-config
Severity: normal
Version: 1.818

The file etc/lsb-release lacks information as of now regarding what  
underlying Debian version is used.


Normally, I'd expect the file to report something similar like found  
in /etc/os-release of a Debian system.


Status quo:

"""
DISTRIB_DESCRIPTION="DebianEdu/Skolelinux"¬
"""

Suggestion (for jessie):

"""
DISTRIB_ID=Skolelinux
DISTRIB_RELEASE=8
DISTRIB_CODENAME=jessie
DISTRIB_DESCRIPTION="DebianEdu / Skolelinux (jessie)"
"""

Suggestion (for testing/unstable):

(1)

"""
DISTRIB_ID=Skolelinux
DISTRIB_RELEASE=9
DISTRIB_CODENAME=testing/unstable
DISTRIB_DESCRIPTION="DebianEdu / Skolelinux (testing/unstable)"
"""


This file requires to be update with every major release, of course.

Greets,
Mike
--

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

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

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


pgpSEAcKB7Ieu.pgp
Description: Digitale PGP-Signatur

Bug#812922: RFS: classic-theme-restorer/1.4.7-1 [ITP] -- customize the new Iceweasel look

[Andrew Shadura]

On 10 Feb 2016 04:51, "Adam Borowski"  wrote:
> Besides, thanks for packaging this!  It's a mandatory extension, no idea
> what Mozilla guys were smoking when they made Australis but it must have
> been something nasty.

I think you're overstating, Australis isn't bad at all, at least, at this
moment. In fact, I like it :-)

-- 
Cheers,
  Andrew

Bug#557765: libfishsound1-dev: The -dev package should be named libfishsound-dev

[Petter Reinholdtsen]

So, six years ago there was a proposal to rename libfishsound1-dev
to libfishsound-dev.  This sound like a good idea, but will
require some work.  Is it worth it?

A quick search on https://codesearch.debian.net/ indicate that
at least the following packages need to have their build dependencies
changed:

  roaraudio
  sonic-visualiser

So not too bad, and should be doable with NMUs in an evening.  What do the
rest of you think?  Should we drop the idea or go for it?

Is there a better way to find all packages build-depending on
libfishsound1-dev?

-- 
Happy hacking
Petter Reinholdtsen

Bug#811347: newer 1.3.2 debian package available for review

[Chris Knadle]

Hey, Tino.

Okay I've compared the package you've put together with the one I had
assembled to see the differences, and the result looks okay to me.  A minor
suggestion to consider for the debian/changelog would be to separate
contributions similar to how other packages do it such as:

-
xca (1.3.2-1) unstable; urgency=medium

[ Tino Mettler ]
  * New upstream release (Closes: #706539, #811347)
  * Switch to dh build
  ...

[ Chris Knadle ]
  * Bump standards version to 3.9.6, no changes needed
  * Add 0001-Use-Debian-specific-CPPFLAGS.patch to use hardening flags
(This also replaces the change from the previous NMU.)
  ...
-

It's fine to leave the debian/changelog as-is (other than changing the
release distribution from "UNRELEASED" to "unstable", obviously) if you'd
prefer the current form.



The other thing to note is that debhelper now automatically makes an
xca-dbgsym package by default.  Normally switching from a -dbg package to a
-dbgsym package requires a transition (see 'man dh_strip' and the
--dbgsym-migration option), but since no -dbg package was shipped previously
I don't think any transition is needed.  If for some reason you'd rather not
ship a -dbgsym package there's a --no-automatic-dbgsym dh_strip option.
(Mentioning this because it's quite new.)



Tino Mettler:
> On Mon, Feb 01, 2016 at 22:07:53 +, Chris Knadle wrote:
>> Tino Mettler:
> 
>>> The package also closes your bug #811347.
>>
>> Yes, as it should.  ;-)
> 
> Hi Chris,
> 
> it's your bug about your package, so I mentioned it in the case that
> there are some aspects in my package that justify to keep the bug open.

Thanks.  ;-)  No need, the package you've put together looks good.

[...]
>>> I forgot to ask: do you plan to upload that package? If not, I'll ask
>>> my usual sponsor.
>>
>> Well I'm not a DD (yet) so I can't upload it directly -- I'm a DM.
> 
> sorry, I thought you uploaded the NMU. I should use
> tracker.debian.org more often.

Yeah it took me a bit to get used to using Tracker, and after using it for
some time it becomes invaluable.

>> DMs can only directly upload packages that they are the
>> maintainer/uploader for, and only if a DD has requested that the DM
>> be given permission to upload that specific package.
>>
>> ftp-master.debian.org has the following link for details:
>>
>>https://lists.debian.org/debian-devel-announce/2012/09/msg8.html
> 
> I alread read about the basic aspects of becoming a DM or DD and even
> talked to the local Debian folks about this.  However, family life
> currently sets strong timing contraints. :-)

Yep, understood.  ;-)

>> Side notes:
>>
>> One of the most recent 2 messages in this thread was signed, and I see the
>> key was revoked -- looks like it was signed with your old key rather than
>> your newer one.  ;-)
> 
> I'm an idiot. Thanks for the hint.

Please be kind to yourself.  :)  I now realize this is a whole lot more
important than I would have realized earlier.

And -- we all make honest mistakes from time to time, so it's important that
that be something that's okay.  So when this happens it seems best to simply
admit the err and move on.

>> If you're interested in becoming a DM, what you'll need is 2 GPG signatures
>> from DDs (on your newer key)
> 
> This is WIP, I already got one signature on the new key.

Cool.  :)

>> (And now also an Alioth guest
>> account, apparently.)  See the "Join the NM process" link at:
> 
> I already have one and use it for collab-maint for another package.
> 
> Thanks for all your remarks, I'll send the package to my usual sponsor.

Very good.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#767145: That long-standing nasty Tcl/Tk-bug with autodocktools Re: Bitte weiterleiten (Re: [Pkg-tcltk-devel] Tcl/Tk help needed (Was: Bug#767145: autodocktools: fails to start the GUI))

[Andreas Tille]

Hi Michel,

thanks for the attempt to help.  To answer your question from the other
mail: In Debian we need to build from source and build against the
current development tools - thus the usage of higher Tcl/Tk version.
(Just a personal remark: I think there are better GUI tools available
for Python than Tcl/Tk - but that's just a side note and I have not
investigated how much work droping Tcl/Tk might create).

Regarding your attached file:  I tried to test it but I realised that we
are running into another issue first:

$ autodocktools 
Run ADT from  /usr/lib/python2.7/dist-packages/AutoDockTools
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/AutoDockTools/__init__.py", line 420, 
in runADT
from mglutil.splashregister.splashscreen import SplashScreen
  File 
"/usr/lib/python2.7/dist-packages/mglutil/splashregister/splashscreen.py", line 
7, in 
from mglutil.util.misc import ensureFontCase
  File "/usr/lib/python2.7/dist-packages/mglutil/util/misc.py", line 19, in 

import numpy.oldnumeric as Numeric
ImportError: No module named oldnumeric
hit enter to continue


I think the following files are affected by this issue:

$ grep -Rw oldnumeric | grep -v '#.*oldnumeric'
AutoDockTools/AutoDockBondClassifier.py:import numpy.oldnumeric as Numeric, 
math
AutoDockTools/autogpfCommands.py:import numpy.oldnumeric as Numeric
AutoDockTools/autogpfCommands.py:import numpy.oldnumeric as Numeric
AutoDockTools/histogram.py:import numpy.oldnumeric as Numeric; N = Numeric
AutoDockTools/Conformation.py:import numpy.oldnumeric as Numeric
AutoDockTools/pixelMap2D.py:import Image, numpy.oldnumeric as Numeric
AutoDockTools/pixelMap2D.py:import numpy.oldnumeric as Numeric
AutoDockTools/Tests/test_PyAutoDock.py:import numpy.oldnumeric as Numeric
AutoDockTools/Utilities24/prepare_dpf42.py:from numpy import oldnumeric as 
Numeric
AutoDockTools/Utilities24/compute_interatomic_distance_per_vina_pose.py:import 
numpy.oldnumeric as Numeric
AutoDockTools/Utilities24/summarize_docking_directory.py:import 
numpy.oldnumeric as Numeric
AutoDockTools/Utilities24/prepare_covalent_flexres.py:import 
numpy.oldnumeric as Numeric
AutoDockTools/Utilities24/rotate_molecule.py:import numpy.oldnumeric as Numeric
AutoDockTools/Utilities24/summarize_epdb_results4.py:from numpy import 
oldnumeric as Numeric
AutoDockTools/Utilities24/summarize_wcg_docking.py:import os, glob, 
numpy.oldnumeric as Numeric
AutoDockTools/Utilities24/compute_rms_between_methods.py:import 
numpy.oldnumeric as Numeric
AutoDockTools/Utilities24/write_clustering_histogram_postscript.py:import os, 
glob, Tkinter, numpy.oldnumeric as Numeric
AutoDockTools/Utilities24/compute_consensus_maps_from_dlgs.py:import os, glob, 
numpy.oldnumeric as Numeric, math
AutoDockTools/Utilities24/score_atoms_by_component.py:from numpy import 
oldnumeric as Numeric
AutoDockTools/Utilities24/compute_rms_between_conformations.py:import 
numpy.oldnumeric as Numeric
AutoDockTools/Utilities24/summarize_results_vif.py:from numpy import oldnumeric 
as Numeric
AutoDockTools/Utilities24/compute_interatomic_distance_per_pose.py:import 
numpy.oldnumeric as Numeric
AutoDockTools/Utilities24/summarize_time.py:import os, glob, numpy.oldnumeric 
as Numeric
AutoDockTools/AutoLigand.py:from numpy.oldnumeric import zeros
AutoDockTools/autoanalyzeCommands.py:import numpy.oldnumeric as Numeric, math
AutoDockTools/autodpfCommands.py:import os, numpy.oldnumeric as Numeric
AutoDockTools/DlgParser.py:import numpy.oldnumeric as Numeric
AutoDockTools/autoflexCommands.py:import numpy.oldnumeric as Numeric
AutoDockTools/autotorsCommands.py:import numpy.oldnumeric as Numeric
AutoDockTools/DlgFilters.py:from numpy import oldnumeric as Numeric
AutoDockTools/cluster.py:import numpy.oldnumeric as Numeric
AutoDockTools/pyAutoDockCommands.py:import Tkinter, numpy.oldnumeric as 
Numeric, Pmw
AutoDockTools/GridParameters.py:import numpy.oldnumeric as Numeric
AutoDockTools/ConfPlayer.py:import numpy.oldnumeric as Numeric
AutoDockTools/InteractionDetector.py:from numpy import oldnumeric as Numeric
AutoDockTools/InteractionDetector.py:import numpy.oldnumeric as Numeric
AutoDockTools/LigandMixin.py:import numpy.oldnumeric as Numeric, math, types, os
AutoDockTools/cluster_ad.py:import numpy.oldnumeric as Numeric
AutoDockTools/energyCalculator.py:import numpy.oldnumeric as Numeric
AutoDockTools/MoleculePreparation.py:import numpy.oldnumeric as Numeric, math 


As far as I dived into a websearch the needed replacements are not
really complex but I would consider it more sensible if you do it
right on your side to be prepared for latest numpy.

Kind regards

  Andreas.

On Tue, Feb 09, 2016 at 04:23:36PM -0800, Michel Sanner wrote:
> Steffen
> 
> 
> could you please check is replacing the file
> mglutil/gui/BasicWidgets/Tk/vector3DGUI.py with the one attached solves the
> problem ?
> 
> Thanks
> 
> On 12/29/2015 05:00 PM, Steffen Möller wrote:
> >Hello Michel, hello Stefano,
> >
> >nic

Bug#814309: ITP: puppet-module-puppetlab-rabbitmq -- Puppet module for rabbitmq, manage everything from vhosts to exchanges

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-puppetlab-rabbitmq
  Version : 5.3.1
  Upstream Author : Ashley Penney 
* URL : https://github.com/puppetlabs/puppetlabs-rabbitmq
* License : Apache-2.0
  Programming Lang: Ruby, Puppet
  Description : Puppet module for rabbitmq, manage everything from vhosts 
to exchanges

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 The rabbitmq module sets up rabbitmq and has a number of providers to manage
 everything from vhosts to exchanges after setup.

Bug#814308: chewing-editor: Cannot load zh_TW.UTF-8 translation when LC_ALL=zh_TW.UTF-8

[陳昌倬]

Package: chewing-editor
Version: 0.0.1-3
Severity: normal
Tags: l10n


The zh_TW.UTF-8 translation is not loaded when using the following
command to launch chewing-editor

LC_ALL=zh_TW.UTF-8 chewing-editor


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

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

Versions of packages chewing-editor depends on:
ii  libc6   2.21-7
ii  libchewing3 0.4.0-4
ii  libgcc1 1:6-20160117-1
ii  libqt5core5a5.5.1+dfsg-13
ii  libqt5widgets5  5.5.1+dfsg-13
ii  libstdc++6  6-20160117-1

chewing-editor recommends no packages.

chewing-editor suggests no packages.

-- no debconf information

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D


signature.asc
Description: PGP signature

Bug#814307: sddm: installing sddm pulling in too many dependencies

[sharuzzaman]

Package: sddm
Version: 0.13.0-1
Severity: important

Dear Maintainer,

To install sddm that sized about 1.2 MB, it pulls in total 223 packages with 
total size about 89.8 MB. After unpacking, 352 MB will be used. 

I disabled APT install-suggest and install-recommend on my laptop, but if by 
using default, more packages will be pulled in by the suggest and recommend.

That is way too much, considering that I only want to install just one package. 

There could be bigger issue with QT/KDE packages on the whole where the 
dependencies does not make sense.

Example, why should I need vlc and freerdp to be installed just to have a login 
manager?

Full aptitude output here:

--start-aptitude-output--

root@debian:~# aptitude install sddm
The following NEW packages will be installed:
  fonts-freefont-ttf{a} fonts-noto-hinted{a} frameworkintegration{a} 
gdb-minimal{a} kactivities{a} kde-cli-tools{a} 
  kde-cli-tools-data{a} kded5{a} kinit{a} kio{a} ktexteditor-data{a} libcln6{a} 
libdbusmenu-qt5-2{a} 
  libdouble-conversion1{a} libfam0{a} libfreerdp-cache1.1{a} 
libfreerdp-client1.1{a} libfreerdp-codec1.1{a} 
  libfreerdp-common1.1.0{a} libfreerdp-core1.1{a} libfreerdp-crypto1.1{a} 
libfreerdp-gdi1.1{a} libfreerdp-locale1.1{a} 
  libfreerdp-primitives1.1{a} libfreerdp-utils1.1{a} libgles1-mesa{a} 
libgles2-mesa{a} libgps22{a} libinput10{a} 
  libjs-underscore{a} libkf5activities5{a} libkf5archive5{a} libkf5attica5{a} 
libkf5auth-data{a} libkf5auth5{a} 
  libkf5baloo5{a} libkf5balooengine5{a} libkf5bookmarks-data{a} 
libkf5bookmarks5{a} libkf5codecs-data{a} 
  libkf5codecs5{a} libkf5completion-data{a} libkf5completion5{a} 
libkf5config-data{a} libkf5configcore5{a} 
  libkf5configgui5{a} libkf5configwidgets-data{a} libkf5configwidgets5{a} 
libkf5coreaddons-data{a} libkf5coreaddons5{a} 
  libkf5crash5{a} libkf5dbusaddons-data{a} libkf5dbusaddons5{a} 
libkf5declarative-data{a} libkf5declarative5{a} 
  libkf5filemetadata-data{a} libkf5filemetadata3{a} libkf5globalaccel-bin{a} 
libkf5globalaccel-data{a} 
  libkf5globalaccel5{a} libkf5globalaccelprivate5{a} libkf5gpgmepp5{a} 
libkf5guiaddons5{a} libkf5i18n-data{a} 
  libkf5i18n5{a} libkf5iconthemes-data{a} libkf5iconthemes5{a} 
libkf5idletime5{a} libkf5itemviews-data{a} 
  libkf5itemviews5{a} libkf5jobwidgets-data{a} libkf5jobwidgets5{a} 
libkf5js5{a} libkf5jsembed-data{a} libkf5jsembed5{a} 
  libkf5kcmutils-data{a} libkf5kcmutils5{a} libkf5kdelibs4support-data{a} 
libkf5kdelibs4support5{a} libkf5kiocore5{a} 
  libkf5kiofilewidgets5{a} libkf5kiontlm5{a} libkf5kiowidgets5{a} 
libkf5networkmanagerqt6{a} libkf5newstuff-data{a} 
  libkf5newstuff5{a} libkf5notifications-data{a} libkf5notifications5{a} 
libkf5notifyconfig-data{a} 
  libkf5notifyconfig5{a} libkf5package-data{a} libkf5package5{a} 
libkf5parts-data{a} libkf5parts5{a} libkf5plasma5{a} 
  libkf5plasmaquick5{a} libkf5pty-data{a} libkf5pty5{a} libkf5quickaddons5{a} 
libkf5runner5{a} libkf5screen6{a} 
  libkf5service-bin{a} libkf5service-data{a} libkf5service5{a} libkf5solid5{a} 
libkf5solid5-data{a} 
  libkf5sonnet5-data{a} libkf5sonnetcore5{a} libkf5sonnetui5{a} 
libkf5su-data{a} libkf5su5{a} libkf5sysguard-data{a} 
  libkf5texteditor5{a} libkf5textwidgets-data{a} libkf5textwidgets5{a} 
libkf5threadweaver5{a} libkf5wallet-bin{a} 
  libkf5wallet-data{a} libkf5wallet5{a} libkf5waylandclient5{a} 
libkf5waylandserver5{a} libkf5webkit5{a} 
  libkf5widgetsaddons-data{a} libkf5widgetsaddons5{a} 
libkf5windowsystem-data{a} libkf5windowsystem5{a} 
  libkf5xmlgui-data{a} libkf5xmlgui5{a} libkf5xmlrpcclient-data{a} 
libkf5xmlrpcclient5{a} libksgrd7{a} 
  libkwalletbackend5-5{a} libkworkspace5-5{a} liblmdb0{a} libpcre16-3{a} 
libphonon4qt5-4{a} 
  libplasma-geolocation-interface5{a} libpolkit-qt5-1-1{a} libprocesscore7{a} 
libprocessui7{a} libqalculate5-data{a} 
  libqalculate5v5{a} libqt5clucene5{a} libqt5core5a{a} libqt5dbus5{a} 
libqt5designer5{a} libqt5designercomponents5{a} 
  libqt5gui5{a} libqt5help5{a} libqt5network5{a} libqt5opengl5{a} 
libqt5printsupport5{a} libqt5qml5{a} libqt5quick5{a} 
  libqt5quickwidgets5{a} libqt5script5{a} libqt5sql5{a} libqt5sql5-sqlite{a} 
libqt5svg5{a} libqt5webkit5{a} 
  libqt5widgets5{a} libqt5x11extras5{a} libqt5xml5{a} libsdl-image1.2{a} 
libtaskmanager5{a} libva-drm1{a} libva-x11-1{a} 
  libvncclient1{a} libweather-ion7{a} libwinpr-crt0.1{a} libwinpr-crypto0.1{a} 
libwinpr-dsparse0.1{a} 
  libwinpr-environment0.1{a} libwinpr-file0.1{a} libwinpr-handle0.1{a} 
libwinpr-heap0.1{a} libwinpr-input0.1{a} 
  libwinpr-interlocked0.1{a} libwinpr-library0.1{a} libwinpr-path0.1{a} 
libwinpr-pool0.1{a} libwinpr-registry0.1{a} 
  libwinpr-rpc0.1{a} libwinpr-sspi0.1{a} libwinpr-synch0.1{a} 
libwinpr-sysinfo0.1{a} libwinpr-thread0.1{a} 
  libwinpr-utils0.1{a} libxcb-composite0{a} libxcb-damage0{a} libxcb-icccm4{a} 
libxcb-image0{a} libxcb-keysyms1{a} 
  libxcb-render-util0{a} libxcb-xkb1{a} libxcb-xv0{a} libxkbcommon-x11-0{a} 
milou{a} phonon4qt5{a} 
  phonon4qt5-backend-vlc{a} plasma-framework{a} p

Bug#811366: RM: jlint -- RoQA; orphaned; low popcon; depends on orphaned packages; no recent updates

[Iain R. Learmonth]

Hi,

On Wed, Feb 10, 2016 at 05:19:06PM +1100, Paul Wise wrote:
> Any particular reason you didn't contact the debian-java mailing list
> about this software, which is pretty important for Java development?
> I've done that just now in this post:
> 
> https://lists.debian.org/msgid-search/1455084815.15189.5.ca...@debian.org

popcon showed only 62 installations with only 5 recent users. The last
update was in 2012 which means it would likely struggle with Java 8, given
Java 8 hadn't been released at that time.

> Please be a bit less trigger-happy with removals, especially with
> software that has reverse dependencies (check-all-the-things).

While I probably could have CC'd the Java list, I did have an important
severity bug on the package for more than a month before requesting removal,
stating that I would request removal to give anyone interested a chance to
register their interest.

This was a very clear candidate for removal from Debian, as it was not a
high quality package, due to it being outdated and so not supporting the
latest language features, and no one was stepping forward to improve it.

Thanks,
Iain.

-- 

Bug#814143: Depends on zendframework, but zendframework is going away

[Thomas Gelf]

NB: thanks for the DomPDF hint. I created a related upstream issue:

https://dev.icinga.org/issues/7

The problems should not affect us as we do not publicly expose any of
the DomPDF files. We wrap it's functionality and render only carefully
escaped HTML, it is not allowed to fetch foreign content. Nonetheless,
it absolutely makes sense to upgrade it, especially to avoid doubts and
uncertainty.

Cheers,
Thomas

Bug#814305: ITP: puppet-module-puppetlabs-rsync -- Puppet module for rsync clients, repositories, and servers

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-puppetlabs-rsync
  Version : 0.2.0
  Upstream Author : Garrett Honeycutt 
* URL : https://github.com/puppetlabs/puppetlabs-rsync
* License : Apache-2.0
  Programming Lang: Ruby, Puppet
  Description : Puppet module for rsync clients, repositories, and servers

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 puppetlabs-rsync manages rsync clients, repositories, and servers as well as
 providing defines to easily grab data via rsync.

Bug#814143: Depends on zendframework, but zendframework is going away

[Thomas Gelf]

Hi David,

upstream author here. ZF2 was already a thing (and stable) once we
started developing Icinga Web 2. We consciously opted for ZF1 at that
time. In my believes ZF2 is over-engineered and slow. Some of the
changes going on for ZF3 are telling me that we were not completely wrong ;)

We are not the only PHP project that decided to take this path. We
wrapped ZF1 with our framework, tried to follow ZF1 design principles in
a more modern way. ZF1 is still alive, supported, ships security fixes
and has never been declared EOL. ZF2 and ZF3 are not successors but
completely different frameworks with different architectures and design
goals.

Icinga will never move to ZF2. In case ZF1 will once be declared EOL we
will probably prefer to replace the functionality we use with our own
code before moving to ZF3. We might change our opinion on this. ZF3
feels like an attempt to find a compromise between becoming a framework
again (IMO they lost the frame in ZF2) while not breaking ZF2
components. Sounds promising, but probably comes too late for us.

As a PHP project it is hard enough to build software based on libraries
shipped with various distributions. We support Debian, RHEL, SLES and of
course all kind of variants in various versions. It would be easier for
us to be allowed to ship our own stripped down php-icinga-vendor-zf1
package. Could you give me any hint how this could be accomplished and
whether or not it fits Debian's packaging guidelines for PHP projects?

Let me give you just one concrete example, where the current way of
packaging really, really hurts us: one of the most important upcoming
Icinga Web 2 modules (publicly available, neither tagged nor packaged
yet) works with binary data (mostly checksums) in databases:

https://github.com/Icinga/icingaweb2-module-director

Now ZF1 broke binary data in a security fix erroneously applied to all
adapters while required only for two of them.

Not a big thing, we plan to blacklist the affected versions once we tag
the director module stable. However, that wouldn't work for Jessie.
Jessie is lagging behind 8 patch versions - it ships ZF 1.12.9 from
2014. What we didn't grasp until very recently was that
1.12.9+dfsg-2+deb8u4 backported that security fix from 1.12.16.

It's perfectly fine that a stable Debian release stays with a specific
minor release. But I do not understand why patch versions are not
shipped as upstream provides them. Following this policy the fix for the
mentioned issue (https://github.com/zendframework/zf1/issues/655) will
not make it into Jessie as it will definitively not be flagged as a
security issue once released with 1.12.18 (pull request is still pending).

The result of this are databases with irreversibly broken binary data.
And as an upstream author I have no real chance to protect my users from
this as Zend_Version in Jessie is basically lying to me.

Please forgive me this slight OT drift, and please do not get me wrong
on this. I absolutely appreciate the effort you are spending on shipping
ZF with Debian. I picked this example to show the problems we are facing
and to explain why we would really love to ship "vendored vendor
packages". Having an php-Icinga-vendor-zf1 package putting files into
/usr/share/icingaweb2/library/vendor/Zend would be great for us. And I
guess as you are already planning to not ship ZF1 with Stretch this
should be fine also policy-wise.

Regards,
Thomas Gelf

Bug#811366: RM: jlint -- RoQA; orphaned; low popcon; depends on orphaned packages; no recent updates

[Paul Wise]

On Mon, 18 Jan 2016 10:00:50 + Iain R. Learmonth wrote:

> See also #804362 where warning was given that removal would be
> requested, with no reply.

Any particular reason you didn't contact the debian-java mailing list
about this software, which is pretty important for Java development?
I've done that just now in this post:

https://lists.debian.org/msgid-search/1455084815.15189.5.ca...@debian.org

Please be a bit less trigger-happy with removals, especially with
software that has reverse dependencies (check-all-the-things).

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#814306: ITP: spin -- a software verification tool

[Tom Lee]

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

I'm working on Debian packages for Gerard J. Holzmann's Spin software
verification tool, which has recently become available under the BSD
3-Clause license. Holzmann's original paper "The Model Checker: SPIN" has
been cited over a thousand times in academia according to ACM. Spin has
also seen success in a number of commercial and government projects,
including NASA's investigation of alleged unintended acceleration in the
Toyota Camry MY05's control software.

Packaging WIP is available here: https://github.com/thomaslee/spin-debian

Initial indications are the packaging will be relatively simple with some
minimal patches.

Further reading:

http://spinroot.com
https://en.wikipedia.org/wiki/SPIN_model_checker
https://en.wikipedia.org/wiki/Promela
http://spinroot.com/spin/success.html



-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#814304: ITP: puppet-module-puppetlabs-mongodb -- Puppet module for managing mongodb installation and configuration

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-puppetlabs-mongodb
  Version : 0.7.0
  Upstream Author : Chris Hoge 
* URL : https://github.com/puppetlabs/puppetlabs-mongodb
* License : Apache-2.0
  Programming Lang: Ruby, Puppet
  Description : Puppet module for managing mongodb installation and 
configuration

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 The MongoDB module manages mongod server installation and configuration of the
 mongod daemon. For the time being it supports only a single MongoDB server
 instance, without sharding functionality.

Bug#814303: ITP: puppet-module-puppetlabs-vcsrepo -- use Puppet to easily deploy content from your version control system (VCS)

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-puppetlabs-vcsrepo
  Version : 1.3.2
  Upstream Author : Hunter Haugen 
* URL : https://github.com/puppetlabs/puppetlabs-vcsrepo
* License : GPL-2+
  Programming Lang: Ruby, Puppet
  Description : use Puppet to easily deploy content from your version 
control system (VCS)

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 The vcsrepo module lets you use Puppet to easily deploy content from your
 version control system (VCS).

Bug#814290: libvorbis0a: Missing libvorbis0a/libvorbisenc2 packages for amd64

[Petter Reinholdtsen]

[Ben Caradoc-Davies]
> Dear Maintainer,
>
> the libvorbis0a/libvorbisenc2 1.3.5-2 packages for amd64 are missing. This
> causes the i386 packages on multiarch to be held back.

I know.  But there is nothing I can do about it, as the autobuilders
report that it built just fine, and was uploaded, but never made it into
the archive.  I believe this must be fixed by a buildd maintainer.  See
https://buildd.debian.org/status/package.php?p=libvorbis&suite=unstable >

--
Happy hacking
Petter Reinholdtsen

Bug#814302: ITP: puppet-module-puppet-community-mcollective -- puppet-module-puppet-community-mcollective

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-puppet-community-mcollective
  Version : 0.6.2
  Upstream Author : Jeff McCune 
* URL : https://github.com/voxpupuli/puppet-mcollective
* License : Apache-2.0
  Programming Lang: Ruby, Puppet
  Description : puppet-module-puppet-community-mcollective

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 The mcollective module handles installing and configuring mcollective across a
 range of operating systems and distributions. Where possible we follow the
 standards laid down by the MCollective Standard Deployment guide.

Bug#814301: initramfs-tools: module microcode not found in modules.dep

[Kevin Locke]

Package: initramfs-tools
Version: 0.120
Severity: minor

Dear Maintainer,

When the intel-microcode package is installed and the running kernel
configured with CONFIG_MICROCODE=y, the following message is printed at
boot:

Loading, please wait...
modprobe: module microcode not found in modules.dep

It is likely invisible to most users, but appears immediately before the
cryptsetup prompt if the root filesystem is encrypted.

The cause appears to be that intel-microcode calls `force_load
microcode` from its hook script[1] which unconditionally adds its
arguments to /conf/modules in the initramfs, which results in the above
error when the module is not present.

Although this could be considered a bug in intel-microcode, the other
uses of force_load that I could find do not appear to protect against
this case, so it seems appropriate to fix it there.  But do reassign if
you disagree.

Thanks,
Kevin

1.  
https://anonscm.debian.org/cgit/users/hmh/intel-microcode.git/tree/debian/initramfs.hook?h=debian/3.20151106.1_deb8u1#n123


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

Kernel: Linux 4.4.1+kevinoid1+ (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 initramfs-tools depends on:
ii  busybox  1:1.22.0-18
ii  cpio 2.11+dfsg-4.1
ii  klibc-utils  2.0.4-7
ii  kmod 22-1
ii  udev 228-6

Versions of packages initramfs-tools recommends:
ii  busybox  1:1.22.0-18

Versions of packages initramfs-tools suggests:
ii  bash-completion  1:2.1-4.2

-- no debconf information

Bug#814300: ITP: puppet-module-richardc-datacat -- Puppet module for data structure rendered using a template

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-richardc-datacat
  Version : 0.6.2
  Upstream Author : Richard Clamp 
* URL : https://github.com/richardc/puppet-datacat
* License : Apache-2.0
  Programming Lang: Ruby, Puppet
  Description : Puppet module for data structure rendered using a template

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 The datacat and datacat_fragment types allow you to build up a data structure
 which is rendered using a template. This is similar to some of the common
 concatenation patterns though the intent should be clearer as it pushes the
 boilerplate down into the type.

Bug#812994: apt 1.2.1 fails to configure packages

[James McCoy]

On Fri, Feb 05, 2016 at 12:35:11AM +0100, Julian Andres Klode wrote:
> On 4 February 2016 at 23:44, Guillem Jover  wrote:
> > On Thu, 2016-02-04 at 08:39:30 -0500, James McCoy wrote:
> >> On Thu, Feb 04, 2016 at 12:56:53AM +0100, Guillem Jover wrote:
> >> > Just to make sure, if you have the libjpeg62-turbo_1%3a1.4.2-2_amd64.deb
> >> > around could you check that it really contains the libjpec62-turbo
> >> > package inside with say dpkg-deb, or manually with ar+tar?

After some discussion with Julian on IRC about some of the issues I've
been seing lately, and his suggestion that a parse change might be
related, I'm thinking that's more likely.

Just as a recap, yesterday I was hitting #813000 (corrupt package index,
can't find Filename:).  I mentioned that it happened even after I
removed the Packages file and re-ran "apt update", so it's not PDiff
related.

Today, after an update, I tried to install the same package I was trying
to install last night and ran into the "Writing more data than expected"
error while downloading the deb.  The interesting part is that apt
reported it got that error while trying to download a deb that it
shouldn't have been downloading:

└[jamessan@freya] 0 % sudo apt install abi-dumper
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  elfutils libasm1 vtable-dumper
The following NEW packages will be installed:
  abi-dumper elfutils libasm1 vtable-dumper
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 353 kB of archives.
After this operation, 1,155 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://httpredir.debian.org/debian sid/main amd64 libasm1 amd64 
0.165-3 [27.6 kB]
Get:2 http://httpredir.debian.org/debian sid/main amd64 elfutils amd64 
0.165-3 [293 kB]
Get:3 http://httpredir.debian.org/debian sid/main amd64 vtable-dumper amd64 
1.1-1 [6,870 B]
Err:3 http://httpredir.debian.org/debian sid/main amd64 vtable-dumper amd64 
1.1-1
  Writing more data than expected (27304 > 25526)
Get:4 http://httpredir.debian.org/debian sid/main i386 abi-dumper all 
0.99.12-1 [25.5 kB]
Fetched 346 kB in 1s (228 kB/s)
E: Failed to fetch 
http://httpredir.debian.org/debian/pool/main/r/r-cran-teachingdemos/r-cran-teachingdemos_2.9-1_all.deb
  Writing more data than expected (27304 > 25526)

E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-missing?

Apt is supposed to be downloading abi-dumper, but it then reports it
failed to fetch r-cran-teachingdemos.

Seeing that reminded me of this email, so I checked
/var/cache/apt/archives/partial:

└[jamessan@freya] 0 % sudo dpkg-deb -I 
/var/cache/apt/archives/partial/vtable-dumper_1.1-1_amd64.deb.FAILED
 new debian package, version 2.0.
 size 65536 bytes: control archive=1338 bytes.
 608 bytes,14 lines  control
2223 bytes,26 lines  md5sums
 Package: r-cran-teachingdemos
 Version: 2.9-1
 Architecture: all
 Maintainer: Debian Science Team 

 Installed-Size: 1741
 Depends: r-base-core (>= 3.0.1-1)
 Recommends: r-cran-misc3d, r-recommended, r-cran-mapproj
 Section: gnu-r
 Priority: optional
 Homepage: http://cran.r-project.org/web/packages/TeachingDemos/
 Description: GNU R Demonstrations for teaching and learning
  This package is a set of demonstration functions that can be used in a
  classroom to demonstrate statistical concepts, or on your own to better
  understand the concepts or the programming.

After another dinstall run, I still can't install abi-dumper, but now
apt is downloading r-cran-surveillance instead of r-cran-teachingdemos.

I've made the two Packages files available at:
https://people.debian.org/~jamessan/tmp/r-cran-teachingdemos-amd64_Packages.lz4
https://people.debian.org/~jamessan/tmp/r-cran-surveillance-amd64_Packages.lz4

> On IRC it was mentioned that bug #813000 mentions that the update can
> generate Packages files in the APT dir with messed up contents.

>From at least visual inspection, it isn't corrupted.  Also, given that
both a PDiff generated and downloaded Packages file show this issue, it
seems to be something in apt's parsing.

> I'm
> not entirely sure it's related, but maybe it is. That must be a very
> unlikely incarnation of that bug though (two packages would need their
> Filename and various hash sum fields replaced by that of another
> package).

A quick check of the file doesn't show anything as obvious as that.

> We cannot reproduce that one yet, but I'm working on it (running apt
> update manually now, and backing up lists before update).

Another interesting data point is that “apt install abi-dumper” fails
trying to acquire vtable-dumper, as I described above, but “apt install
vtable-dumper” works just fine.  After that, I can install abi-dumper 

Bug#814299: plast: FTBFS without SSE2

[Aaron M. Ucko]

Source: plast
Version: 2.3.1+dfsg-1
Severity: serious
Justification: fails to build from source

Hi, Andreas.

Builds of plast for architectures besides the handful that (always)
support SSE2 have been failing, per the log excerpt below.  Please
take a look, and either arrange to accommodate the remaining platforms
or officially declare plast to be

  Architecture: any-amd64 x32

Thanks!

  
/«BUILDDIR»/plast-2.3.1+dfsg/src/algo/hits/gap/SmallGapHitIteratorSSE8.cpp:28:10:
 warning: #warning error undefined __SSE3__ or __SSE2__ [-Wcpp]
   #warning error undefined __SSE3__ or __SSE2__
^
  /«BUILDDIR»/plast-2.3.1+dfsg/src/algo/hits/gap/SmallGapHitIteratorSSE8.cpp: 
In member function 'void 
algo::hits::gapped::SmallGapHitIteratorSSE8::computeScores(size_t, const 
LETTER*, const LETTER*, int*)':
  
/«BUILDDIR»/plast-2.3.1+dfsg/src/algo/hits/gap/SmallGapHitIteratorSSE8.cpp:294:5:
 error: '__m128i' was not declared in this scope
   __m128i vscore_gap_col;
   ^
  [...]
  
/«BUILDDIR»/plast-2.3.1+dfsg/src/algo/hits/gap/SmallGapHitIteratorSSE8.cpp:306:13:
 error: expected ';' before 'vtemp1'
   __m128i vtemp1;
   ^
  
/«BUILDDIR»/plast-2.3.1+dfsg/src/algo/hits/gap/SmallGapHitIteratorSSE8.cpp:309:5:
 error: 'vgap_extend' was not declared in this scope
   vgap_extend = _mm_set1_epi16 (-_parameters->extendGapCost);
   ^
  
/«BUILDDIR»/plast-2.3.1+dfsg/src/algo/hits/gap/SmallGapHitIteratorSSE8.cpp:309:62:
 error: '_mm_set1_epi16' was not declared in this scope
   vgap_extend = _mm_set1_epi16 (-_parameters->extendGapCost);
^
  [...]
  
/«BUILDDIR»/plast-2.3.1+dfsg/src/algo/hits/gap/SmallGapHitIteratorSSE8.cpp:450:54:
 error: '_mm_extract_epi16' was not declared in this scope
   scores[0] =  _mm_extract_epi16 (vbest_score,0);
^
  CMakeFiles/PlastLibrary.dir/build.make:1193: recipe for target 
'CMakeFiles/PlastLibrary.dir/src/algo/hits/gap/SmallGapHitIteratorSSE8.cpp.o' 
failed

Bug#807457: initramfs-tools: Add command to unpack initramfs

[Kevin Locke]

On Wed, 2015-12-09 at 03:23 +, Ben Hutchings wrote:
> Rather than duplicating code, please combine this with lsinitramfs
> (checking $0 to determine which command was invoked) or move the common
> code into a shell library.

I've taken a slightly different tact and implemented uninitramfs as a
thin wrapper for cpio.  It is designed as a drop-in replacement for
cpio wherever an initramfs may be present, and passes through all
options unmodified.  With this, I changed lsinitramfs to call
uninitramfs instead of cpio.

See what you think.

Thanks,
Kevin

P.S.  I named it "uninitramfs" instead of "unmkinitramfs" since it
does not depend on mkinitramfs specifically, and it seemed to fit with
"lsinitramfs" and the "initramfs" format.  But if you would prefer
"unmkinitramfs", I can change it.

-- 
Cheers,  |  ke...@kevinlocke.name| XMPP: ke...@kevinlocke.name
Kevin|  https://kevinlocke.name  | IRC:   kevinoid on freenode
>From a45f16697106d36993762c39ffa82e28e201b72a Mon Sep 17 00:00:00 2001
From: Kevin Locke 
Date: Tue, 9 Feb 2016 20:01:05 -0800
Subject: [PATCH] Create uninitramfs command

This command supports extracting files from an initramfs image.  It is
designed to be a drop-in for cpio wherever an initramfs may be present.

It is implemented using the code from lsinitramfs, which now delegates
to uninitramfs instead of cpio.

Signed-off-by: Kevin Locke 
---
 lsinitramfs   | 71 ++
 lsinitramfs.8 |  1 +
 mkinitramfs.8 |  3 +-
 uninitramfs   | 99 +++
 uninitramfs.8 | 59 +++
 5 files changed, 163 insertions(+), 70 deletions(-)
 create mode 100755 uninitramfs
 create mode 100644 uninitramfs.8

diff --git a/lsinitramfs b/lsinitramfs
index 34d84e4..5a5a049 100755
--- a/lsinitramfs
+++ b/lsinitramfs
@@ -12,7 +12,7 @@ if [ "$#" -eq 0 ] ; then
 	exit 1
 fi
 
-cpio_args="--extract --quiet --list"
+cpio_args="--quiet --list"
 
 OPTIONS=`getopt -o hl --long help,long -n "$0" -- "$@"`
 # Check for non-GNU getopt
@@ -40,73 +40,6 @@ while true; do
 	esac
 done
 
-listarchive()
-{
-	archive="$1"
-	if zcat -t "${archive}" >/dev/null 2>&1 ; then
-		zcat "${archive}" | cpio ${cpio_args}
-	elif xzcat -t "${archive}" >/dev/null 2>&1 ; then
-		xzcat "${archive}" | cpio ${cpio_args}
-	elif bzip2 -t "${archive}" >/dev/null 2>&1 ; then
-		bzip2 -c -d "${archive}" | cpio ${cpio_args}
-	elif lzop -t "${archive}" >/dev/null 2>&1 ; then
-		lzop -c -d "${archive}" | cpio ${cpio_args}
-	fi
-}
-
-# Read bytes out of a file, checking that they are valid hex digits
-readhex()
-{
-	dd < "$1" bs=1 skip="$2" count="$3" 2> /dev/null | \
-		LANG=C grep -E "^[0-9A-Fa-f]{$3}\$"
-}
-
-# Check for a zero byte in a file
-checkzero()
-{
-	dd < "$1" bs=1 skip="$2" count=1 2> /dev/null | \
-		LANG=C grep -q -z '^$'
-}
-
 for initramfs in "$@" ; do
-	if ! [ -r "${initramfs}" ] ; then
-		echo "Specified file could not be read." >&2
-		exit 1
-	else
-		echo "${initramfs}"
-
-		# There may be a prepended uncompressed archive.  cpio
-		# won't tell us the true size of this so we have to
-		# parse the headers and padding ourselves.  This is
-		# very roughly based on linux/lib/earlycpio.c
-		offset=0
-		while true; do
-			if checkzero "$initramfs" $offset; then
-offset=$((offset + 4))
-continue
-			fi
-			magic="$(readhex "$initramfs" $offset 6)" || break
-			test $magic = 070701 || test $magic = 070702 || break
-			namesize=0x$(readhex "$initramfs" $((offset + 94)) 8)
-			filesize=0x$(readhex "$initramfs" $((offset + 54)) 8)
-			offset=$(((offset + 110)))
-			offset=$(((offset + $namesize + 3) & ~3))
-			offset=$(((offset + $filesize + 3) & ~3))
-		done
-
-		if [ $offset -ne 0 ]; then
-			# List uncompressed archive
-			cpio ${cpio_args} < "$initramfs"
-
-			# List main archive
-			subarchive=$(mktemp ${TMPDIR:-/var/tmp}/lsinitramfs_XX)
-			trap "rm -f $subarchive" EXIT
-			dd < "$initramfs" bs="$offset" skip=1 2> /dev/null \
-> $subarchive
-			listarchive $subarchive
-		else
-			listarchive "${initramfs}"
-		fi
-
-	fi
+	uninitramfs $cpio_args < "$initramfs"
 done
diff --git a/lsinitramfs.8 b/lsinitramfs.8
index a717113..4082e3b 100644
--- a/lsinitramfs.8
+++ b/lsinitramfs.8
@@ -50,4 +50,5 @@ and numerous others.
 .BR
 .IR initramfs-tools (8),
 .IR mkinitramfs (8),
+.IR uninitramfs (8),
 .IR update-initramfs (8).
diff --git a/mkinitramfs.8 b/mkinitramfs.8
index 0a109f6..74a68dc 100644
--- a/mkinitramfs.8
+++ b/mkinitramfs.8
@@ -155,4 +155,5 @@ Jeff Bailey  and numerous others.
 .IR initramfs.conf (5),
 .IR initramfs-tools (8),
 .IR update-initramfs (8),
-.IR lsinitramfs (8).
+.IR lsinitramfs (8),
+.IR uninitramfs (8).
diff --git a/uninitramfs b/uninitramfs
new file mode 100755
index 000..bca2f1d
--- /dev/null
+++ b/uninitramfs
@@ -0,0 +1,99 @@
+#!/bin/sh
+
+set -eu
+
+usage()
+{
+	echo "Usage: $(basename "$0") [cpio options ...] < "
+}
+
+# Abort if stdin is a terminal.
+#
+# Although cpio su

Bug#814298: ITP: puppet-module-puppetlabs-tftp -- Puppet module for managing tftp-hpa

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-puppetlabs-tftp
  Version : 0.2.3
  Upstream Author : Nan Liu 
* URL : https://puppetlabs/puppetlabs-tftp
* License : Apache-2.0
  Programming Lang: Ruby, Puppet
  Description : Puppet module for managing tftp-hpa

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module will install tftp-hpa as a xinetd service by default. It can be
 overridden to run as a standalone daemon by setting the inetd parameter to
 false.
 .
 Parameters:
  * username: tftp daemon user, default tftp
  * directory: service directory, deafult see params class.
  * address: bind address, default 0.0.0.0.
  * port: bind port, default 69.
  * options: service option, default --secure.
  * inetd: run service via xinetd, default true.

Bug#662895: closed by Ben Hutchings (Closing bugs assigned to linux-2.6 package)

[GSR]

reopen 662895
reassign 662895 src:linux 4.4-1~exp1
quit

Hi,
ow...@bugs.debian.org (2016-02-09 at 1528.20 +):
> If you can still reproduce this bug in a newer release, please reopen
> the bug report and reassign it to 'src:linux' and the affected version
> of the package.  You can find the package version for the running
> kernel by running:
> 
> uname -v

I have been using "#1 SMP Debian 3.16.7-ckt11-1 (2015-05-24)" for some
time, and today installed a new kernel "#1 SMP Debian 4.4-1~exp1
(2016-01-19)". It keeps happening with both. It took over 7 hours to
happen with the 4.4, but still seems the ATK0110 or something else in
ACPI system is not playing nice, like reading too much or too few from
a stack and then crap spreading.

All these years I just managed to keep the system "usable" by brute
forcing constant resets of the keyboard. Side effect: sometimes normal
keys get stuck until all settles, sometimes modifiers get stuck (even
if not pressed before... shift tends to do that) and you have to
manually release & press them so they really release.

GSR
 

Bug#814297: ITP: puppet-module-adrienthebo-filemapper -- Puppet module for mapping files to resources and back

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-adrienthebo-filemapper
  Version : 1.1.3
  Upstream Author : Adrien Thebo 
* URL : https://github.com/adrienthebo/puppet-filemapper
* License : Apache-2.0
  Programming Lang: Ruby, Puppet
  Description : Puppet module for mapping files to resources and back

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages mapping of files to resources and back.

Bug#814296: ITP: puppet-module-jbussdieker-monit -- Puppet module for installing configuring and running processes using monit

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-jbussdieker-monit
  Version : 1.5.0
  Upstream Author : Joshua B. Bussdieker 
* URL : https://github.com/jbussdieker/puppet-monit
* License : Unkown yet (currently clarifying with upstream)
  Programming Lang: Ruby, Puppet
  Description : Puppet module for installing configuring and running 
processes using monit

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages installing, configuring and running processes using monit.

Bug#812922: RFS: classic-theme-restorer/1.4.7-1 [ITP] -- customize the new Iceweasel look

[Adam Borowski]

On Mon, Feb 01, 2016 at 09:58:57PM -0700, Sean Whitton wrote:
> * Package name: classic-theme-restorer

In the copyright file, you wrote:

License: MPL-2.0
 This Source Code Form is subject to the terms of the Mozilla Public License,
 v. 2.0. If a copy of the MPL was not distributed with this file,
 You can obtain one at http://mozilla.org/MPL/2.0/.

but the text of the MPL is not actually provided.


Besides, thanks for packaging this!  It's a mandatory extension, no idea
what Mozilla guys were smoking when they made Australis but it must have
been something nasty.

-- 
A tit a day keeps the vet away.

Bug#814253: antlr4: can't run TestRig / grun

[Ximin Luo]

On Tue, 09 Feb 2016 15:35:44 +0100 Ximin Luo  wrote:
>  /usr/share/antlr4/grun
> #!/bin/sh
> exec java -cp /usr/share/java/antlr4.jar:/usr/share/java/antlr4-runtime.jar 
> org.antlr.v4.gui.TestRig
> 

Whoops, you should add a "$@" to the end of that line of course.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

Bug#766811: spurious library links

[Nathan Scott]

- Original Message -
> [..]
> Right. Nathan, this code path is not used on Red Hat and SuSE, which
> already implemented a merged /usr, and it has always been wrong on
> Debian: I think it should just be removed from the upstream package.
> Should I NMU?

Please go right ahead Marco - many thanks!

--
Nathan

Bug#766811: spurious library links

[Marco d'Itri]

On Feb 06, Jakub Wilk  wrote:

> AFAICS this is the code responsible for creating /lib/libfoo <->
> /usr/lib/libfoo symlinks (see include/buildmacros:79):
> 
> if [ "x$(shell readlink -f $(PKG_LIB_DIR))" != \
> "x$(shell readlink -f $(PKG_ROOT_LIB_DIR))" ]; then \
>../$(INSTALL) -S $(PKG_LIB_DIR)/$(LIBNAME).a 
> $(PKG_ROOT_LIB_DIR)/$(LIBNAME).a; \
>../$(INSTALL) -S $(PKG_LIB_DIR)/$(LIBNAME).la 
> $(PKG_ROOT_LIB_DIR)/$(LIBNAME).la; \
>../$(INSTALL) -S $(PKG_ROOT_LIB_DIR)/$(LIBNAME).so 
> $(PKG_LIB_DIR)/$(LIBNAME).so; \
> fi

Right. Nathan, this code path is not used on Red Hat and SuSE, which 
already implemented a merged /usr, and it has always been wrong on 
Debian: I think it should just be removed from the upstream package.
Should I NMU?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#814295: ITP: puppet-module-camptocamp-openssl -- Puppet module for managing openssl configuration

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-camptocamp-openssl
  Version : 1.5.0
  Upstream Author : Raphaël Pinson 
* URL : https://github.com/camptocamp/puppet-openssl
* License : Apache-2.0
  Programming Lang: Ruby, Puppet
  Description : Puppet module for managing openssl configuration

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages both the installation and configuration of OpenSSL.

Bug#814294: ITP: puppet-module-nanliu-staging -- Puppet module for the management of staging directory

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-nanliu-staging
  Version : 1.0.4
  Upstream Author : Nan Liu 
* URL : https://github.com/nanliu/puppet-staging
* License : Apache-2.0
  Programming Lang: Ruby, Puppet
  Description : Puppet module for the management of staging directory

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages staging directory, along with download/extraction of
 compressed files.

Bug#814235: RFS: swi-prolog [ITA] -- ISO/Edinburgh-style Prolog interpreter

[Adam Borowski]

On Tue, Feb 09, 2016 at 05:13:50PM +0500, Lev Lamberov wrote:
> I would like to take care of swi-prolog in Debian.
> 
> [2] https://anonscm.debian.org/cgit/collab-maint/swi-prolog.git/

Alas, I'm afraid the package ships a minified sourceless copy of jquery,
both in the source and in swi-prolog-nox.  Please remove it and
depend on libjs-jquery.

I did not find any other issues beside this.

-- 
A tit a day keeps the vet away.

Bug#814293: ITP: puppet-module-saz-ssh -- Puppet module for Ssh configuration (client and server)

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: puppet-module-saz-ssh
  Version : 2.8.1
  Upstream Author : Steffen Zieger 
* URL : https://github.com/saz/puppet-ssh
* License : Apache-2.0
  Programming Lang: Ruby, Puppet
  Description : Puppet module for Ssh configuration (client and server)

 Puppet lets you centrally manage every important aspect of your system using a
 cross-platform specification language that manages all the separate elements
 normally aggregated in different files, like users, cron jobs, and hosts,
 along with obviously discrete elements like packages, services, and files.
 .
 This module manages both the installation and configuration of Ssh (client and
 server).

Bug#814292: Missing python-setuptools dependency

[Brandon Chothia]

Package: python-pip
Version: 8.0.2-3

The python-pip seems to be missing the python-setuptools dependency.

When I run apt-get update && apt-get -assume-yes install python python-dev 
python-pip && pip install credstash, I get the following error

ImportError: No module named setuptools

In version 1.5.6-6, python-setuptools was automatically installed when running 
apt-get install python-pip.

Bug#812841: gitlab: Still present in 8.4.0+dfsg-2 and 8.4.3+dfsg-1

[Viktor Malyarchuk]

Package: gitlab
Version: 8.4.3+dfsg-1
Followup-For: Bug #812841

Dear Maintainer,

this bug is still present in 8.4.0+dfsg-2 and 8.4.3+dfsg-1

Best regards,
Viktor

Bug#586680: Misnamed option --tls/smtptls with misleading docs and missing SMTP+TLS support

[Ben Caradoc-Davies]

Further notes:

(1) There was an old issue that this flag should have been called 
--smtptls/smtptls for consistency. When making braking changes, perhaps 
this suggestion should be implemented?


(2) Auto-enabling SMTP+TLS on port 465 and SMTP+STARTTLS on port 587 
would enhance usability.


Many of the changes I have suggested break backwards compatibility with 
existing .reportbugrc and scripts.


Kind regards,

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

Bug#807011: ksh: Conditional variable expansion problem in while loop

[SATOH Fumiyasu]

Hi,

On Sat, 05 Dec 2015 08:03:32 +0900,
Nicholas Bamber wrote:
>   It is not releveant how this works in other shells (or even other 
> versions of ksh). All that matters is whether this syntax is defined  by the 
> POSIX standard. It's not even documented as a bash feature let alone a POSIX 
> standard.

The POSIX standard defines ${parameter+word} behavior:

  
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02

and old ksh 93s+20080202-1 (Debian jessie, squeeze) behaves
as I and POSIX standard expected.

>   It may be of interest to you to be reminded that this version of ksh is 
> dead upstream, so even if I agreed it really was a problem it is very 
> possible the most I would do is tag it confirmed.
> 
>   As it is I believe you are trying to use an undocumented syntax that 
> just happens to do something you like in lots of other shells. I would 
> however be interested to know what YOU think the "${v+set}" syntax should do.

No. I use the documented syntax.

Regards,

-- 
-- Name: SATOH Fumiyasu @ OSS Technology Corp. (fumiyas @ osstech co jp)
-- Business Home: http://www.OSSTech.co.jp/
-- GitHub Home: https://GitHub.com/fumiyas/
-- PGP Fingerprint: BBE1 A1C9 525A 292E 6729  CDEC ADC2 9DCA 5E1C CBCA

Bug#586680: Misnamed option --tls/smtptls with misleading docs and missing SMTP+TLS support

[Ben Caradoc-Davies]

--tls/smtptls should be renamed --starttls/smtpstarttls and the 
documentation should be corrected to note that the implementation uses 
STARTTLS not TLS when this flag is enabled. This type of connection is 
typically used on port 587. Updating the documentation to clarify this 
port number would be quite helpful and time saving for users.


The incorrect docs justify elevating the severity of this issue to normal.

A workaround for the lack of support for SMTP+TLS is to use 
SMTP+STARTTLS, typically on port 587, if available. Some providers do 
not support this.


The original wishlist item is support for SMTP+TLS; this could be 
enabled with a new flag --tls/smtptls (same as the old flag) with an 
implementation that does what --tls/smtptls was originally and 
incorrectly documented to do: SMTP over a connection that starts with a 
TLS handshake.


I have merged #586680 #740124 #412914 as they all report users 
struggling with SMTP+TLS on port 465.


Kind regards,

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

Bug#813550: gitlab: Fixed if gitlab home directory is removed before install.

[Viktor Malyarchuk]

Package: gitlab
Followup-For: Bug #813550

Dear Maintainer,

this bug do not show up if gitlab home directory is removed before install.

Best regards,
Viktor

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

[Chris Leishman]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

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

It builds those binary packages:

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

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

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

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

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

Regards,
Chris Leishman

Bug#792171: util-linux - sulogin, no way to continue

[Andreas Henriksson]

Control: tags -1 + upstream help
Control: severity -1 wishlist
Control: retitle -1 sulogin: no way to continue on dumb terminals (s390*)

Hello Bastian Blank.

Thanks for your bug report, and sorry for the late reply

On Sun, Jul 12, 2015 at 01:42:29PM +0200, Bastian Blank wrote:
> Package: util-linux
> Version: 2.26.2-6
> Severity: grave
> 
> sulogin have no other way then Ctrl-D to continue.  On s390* only dumb
> terminals without any control characters exists, so there is no way to
> provide this input.

... but I personally have no interest in s390* and apparently this bug
report hasn't generated anyone else to jump on fixing this either
(despite having it sit at grave severity for a long time to make it as
discoverable as possible).

I would like to consider this a problem that s390* porters should work
out together with upstream. (Feel free to poke me once this is sorted
out upstream if you consider backporting it urgent enough to not wait
for next upstream stable release.) It's in my opinion a new feature
since sulogin has as far as I know never supported anything but non-dumb
terminals. Either way I doubt this would be considered a release
blocker by the release team if there genuinely is noone willing to fix
this. If you disagree, please ask their opinion and quote it here.

I'm thus tagging and adjusting severity accordingly.

Regards,
Andreas Henriksson

Bug#814290: libvorbis0a: Missing libvorbis0a/libvorbisenc2 packages for amd64

[Ben Caradoc-Davies]

Package: libvorbis0a
Version: 1.3.5-2
Severity: normal

Dear Maintainer,

the libvorbis0a/libvorbisenc2 1.3.5-2 packages for amd64 are missing. This
causes the i386 packages on multiarch to be held back.

Kind regards,
Ben.



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

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

Bug#814289: python3-pdfrw: wrongly provides/conflicts (python-)pdfrw

[Aaron M. Ucko]

Package: python3-pdfrw
Version: 0.2-2
Severity: normal

AFAICT, the only reason the python-pdfrw package
Replaces/Provides/Conflicts pdfrw is that the very first pdfrw upload
accidentally left "python-" off of the binary module package name.  As
such, these settings make no sense for python3-pdfrw, and moreover
block coinstallability with python-pdfrw.  Please remove them from
python3-pdfrw; it should also be safe to retire them from
python-pdfrw, as the original pdfrw binary package was never part of a
release, and hasn't existed in years.

Thanks!

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

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

Bug#813313: [planet-venus] planet-venus fails on SNI enabled websites

[Jakub Wilk]

* anarcat , 2016-02-09, 09:33:

This is typical of Python apps that depend only on urllib and so on.


Not really. Python's stdlib supports SNI since 2.7.9, which was the 
first version that enabled certificate verification by default, and 
what's in jessie.


Here the culrprit is httplib2:

$ python -c 'import urllib; urllib.urlopen("https://blog.windfluechter.net/";).read()' 
&& echo yay
yay

$ python -c 'import httplib2; 
httplib2.Http().request("https://blog.windfluechter.net/";)'
Traceback (most recent call last):
 File "", line 1, in 
 File "/usr/lib/python2.7/dist-packages/httplib2/__init__.py", line 1607, in 
request
   (response, content) = self._request(conn, authority, uri, request_uri, 
method, body, headers, redirections, cachekey)
 File "/usr/lib/python2.7/dist-packages/httplib2/__init__.py", line 1349, in 
_request
   (response, content) = self._conn_request(conn, request_uri, method, body, 
headers)
 File "/usr/lib/python2.7/dist-packages/httplib2/__init__.py", line 1271, in 
_conn_request
   conn.connect()
 File "/usr/lib/python2.7/dist-packages/httplib2/__init__.py", line 1046, in 
connect
   'host %s: %s' % (hostname, cert), hostname, cert)
httplib2.CertificateHostnameMismatch: Server presented certificate that does not match host 
blog.windfluechter.net: {'subjectAltName': (('DNS', 'abi94oesede.de'), ('DNS', 
'www.abi94oesede.de')), 'notBefore': u'Jan 26 18:05:00 2016 GMT', 'caIssuers': 
(u'http://cert.int-x1.letsencrypt.org/',), 'OCSP': (u'http://ocsp.int-x1.letsencrypt.org/',), 
'serialNumber': u'01839A051BF9D2873C0A3BAA9FD0227C54D1', 'notAfter': 'Apr 25 18:05:00 2016 GMT', 
'version': 3L, 'subject': ((('commonName', u'abi94oesede.de'),),), 'issuer': ((('countryName', 
u'US'),), (('organizationName', u"Let's Encrypt"),), (('commonName', u"Let's Encrypt 
Authority X1"),))}

--
Jakub Wilk

Bug#813848: bumblebee: bbswitch will not disable nvidia card after optirun finishes.

[Luca Boccassi]

On Sat, 2016-02-06 at 15:26 +, Gary Preston wrote:
> On 06/02/16 15:16, Luca Boccassi wrote:
> > Could you please install also nvidia-support from backports and try
> > again without the symlinks?
> > 
> 
> Updated nvidia-support to the backports version, without the symlinks
> however the problem remains. bumblebeed fails to unload the nvidia
> kernel module and likewise I cannot unload it manually via "modprobe -r
> nvidia" I still have to use the "modprobe -r nvidia-current" or "rmmod
> nvidia" version.

In your modprobe.d directory there's the bumblebee.conf and
nvidia-kernel-common.conf, but not nvidia.conf. It should be there as a
symlink:

ls -l /etc/modprobe.d/ | grep nvidia.conf
lrwxrwxrwx 1 root root  43 Oct 17 11:46 nvidia.conf
-> /etc/alternatives/glx--nvidia-modprobe.conf

Try to run:

sudo update-glx --config glx

and choose "bumblebee", see if that reinstalls the symlink.

Did you fiddle with that file or with update-alternatives manually by
any chance?

Kind regards,
Luca Boccassi


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

Bug#571136: 1.0.76 breaks qemu'd debootstrap (1.0.78)

[Marco d'Itri]

On Feb 10, Jason Heeris  wrote:

> I've just tried a live-build cross build of an armhf image from a stretch
> amd64
> VM, with debootstrap 1.0.78, and had it fail this way too.
This is about #813232. I posted a candidate patch, but nobody cared.
Feel free to test it and report if it works.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#743251: packagekitd runs indefinitely

[Francois Gouget]

Package: packagekit
Version: 1.0.11-1
Followup-For: Bug #743251

Dear Maintainer,

Regularly my computer is getting slow and when I bring up top, packagekitd is 
always the
process eating all the memory:

$ ps aux | grep packagekitd
USER   PID %CPU %MEM   VSZ  RSS TTY  STAT START   TIME COMMAND
root 28767  0.2 41.9 10080776 6850012 ?Ssl  févr.04  19:34 
/usr/lib/packagekit/packagekitd

Incidentally the above line also shows it has been running for 5 days which I'm 
not sure
is normal. Note that I've also been having "Hash sum mismatch" errors lately 
(it seems
I finally got rid of them by switching the apt source from ftp.fr.debian.org to
ftp.debian.org and back). Maybe that's related.

Also this bug sounds very much like bug 802306.


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

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

Versions of packages packagekit depends on:
ii  gdebi-core  0.9.5.7
ii  libapt-inst2.0  1.2.1
ii  libapt-pkg5.0   1.2.1
ii  libc6   2.21-7
ii  libgcc1 1:5.3.1-7
ii  libglib2.0-02.46.2-3
ii  libglib2.0-bin  2.46.2-3
ii  libgstreamer1.0-0   1.6.3-1
ii  libpackagekit-glib2-18  1.0.11-1
ii  libpolkit-gobject-1-0   0.105-14.1
ii  libsqlite3-03.10.2-1
ii  libstdc++6  5.3.1-7
ii  libsystemd0 228-4+b1
ii  policykit-1 0.105-14.1

Versions of packages packagekit recommends:
ii  packagekit-tools  1.0.11-1

Versions of packages packagekit suggests:
ii  appstream [appstream-index]  0.9.0-3
ii  appstream-index  0.9.0-3

-- no debconf information

Bug#571136: 1.0.76 breaks qemu'd debootstrap (1.0.78)

[Jason Heeris]

I've just tried a live-build cross build of an armhf image from a stretch
amd64
VM, with debootstrap 1.0.78, and had it fail this way too.

live-build: 1:20151215 (but reports as 5.0~a11-1)
debootstrap: 1.0.78
qemu: 1:2.5+dfsg-5

The command to reproduce the error is:

  lb config \
--apt-indices none \
--apt-source-archives false \
--distribution wheezy \
--binary-images hdd \
--hdd-size 512 \
--architectures armhf \
--bootstrap-qemu-arch armhf \
--bootstrap-qemu-static /usr/bin/qemu-arm-static \
--firmware-binary false \
--firmware-chroot false

  sudo lb build 2>&1 | tee build_log

The final part of the build log says:

  P: Running debootstrap second stage under QEMU
  I: Keyring file not available at
/usr/share/keyrings/debian-archive-keyring.gpg; switching to https mirror
https://mirrors.kernel.org/debian
  P: Begin unmounting filesystems...
  P: Saving caches...
  /usr/bin/env: apt-get: No such file or directory

The full log is attached.

Cheers,
Jason Heeris

PS. Sorry for (a) not using reportbug, but I'm not at that machine right
now;
and (b) the multiple postings.


build_log
Description: Binary data

Bug#814221: gnat currently ftbfs with GCC trunk (GCC 6) on m68k

[Andreas Schwab]

Matthias Klose  writes:

> trying to build a cross compiler:
>
> checking size of int... Run-time library configured incorrectly
> (requesting support for Frontend ZCX exceptions)

You probably need to add the Frontend_Exceptions flag like all others,
see .

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Bug#808920: calligrastage not installable / [calligra-libs] not installable

[peter green]

If you use and care about calligra can you please try building with the 
patch I posted at


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797389#17

And tell me

1. Is that patch still sufficient to make the package build in current sid?
2. Are the resulting packages installable?
3. Do the resulting packages actually work?

If I can get some confirmation that the patch results in packages that 
actually works then I will NMU my patch.

Bug#796118: Re: Should djbdns be removed?

[Robert Edmonds]

Hi, Matija:

Matija Nalis wrote:
> On Tue, Oct 06, 2015 at 04:26:49PM +0200, Ondřej Surý wrote:
> > > On Tue, Sep 08, 2015 at 08:29:18PM +0200, Moritz Mühlenhoff wrote:
> > > > On Wed, Aug 19, 2015 at 05:45:30PM +0200, Moritz Muehlenhoff wrote:
> > > > > djbdns is RC-buggy for many years now and was out of testing since 
> > > > > 2009.
> > > > > Should we remove it from unstable?
> > > 
> > > No, I don't think so.
> > 
> > Any solid arguments supporting your opinion?
> > 
> > djbdns is RC buggy, upstream orphaned, outdated, has to be heavily
> > patched, doesn't support recent DNS standards and it still even carries
> > old J-ROOT IP address that was decommissioned a ***13*** years ago.
> 
> dnscache component only is RC-buggy. The solution has been proposed
> by Robert Edmonds (remove only buggy component /usr/bin/dnscache).
> 
> It is not upstream orphaned.

As far as I can tell, the only maintenance activity that djbdns has
received from its upstream developer has been the release of a two-line
patch, about 7 years ago:

http://marc.info/?l=djbdns&m=123613000920446&w=2

That email states that "The next release of djbdns will be backed by a
new security guarantee", but no new release has been published since
then.  The latest version on cr.yp.to is still djbdns 1.05, released
about 15 years ago, so presumably the original djbdns security guarantee
is still in effect:

https://cr.yp.to/djbdns/guarantee.html

The only upstream maintenance attention djbdns has received in the past
15 years has been related to the security guarantee, and that security
guarantee is very narrowly tailored to problems that DJB finds
worthwhile; attacks enabled by the ease of forging UDP packets on the
Internet, or denial-of-service attacks are both specifically excluded
classes of problems.

Other routine maintenance such as updating the list of root nameserver
address hints has simply been neglected.  E.g., the dnsroots.global file
shipped in djbdns-1.05 lists five IP addresses (out of thirteen) that
are no longer official root server IP addresses, if I counted correctly.
Developers of actively maintained recursive DNS servers promptly update
these values in their next scheduled release, especially after the
widely publicized "old L-root" incident:

http://research.dyn.com/2008/05/identity-theft-hits-the-root-n-1/

djbdns may not be "orphaned" upstream in the literal definition, but it
is certainly unmaintained by now.

> It is just stable piece of software which does not change often, as it
> was engineered on KISS principle, so it does not *need* to be changed.
> That is great engineering feat, and I'd love if way more software
> would be like that instead of having everincreasing featurecreep.

Many djbdns users speak about how well engineered or elegant the servers
are, but I suspect this comes from the experience of configuring the
daemons (which have very few configuration knobs compared to other DNS
implementations), rather than reading the code.  Here are comments from
a security researcher with extensive experience analyzing source code:

tptacek 2304 days ago

DJB's code is a lot of things, but when someone says "beautiful" is
one of them, I start thinking about how I might quiz them to get
them to prove that they've actually read it. Smarter coders than me
have sat in rooms for nightlong studies of qmail and come to the
conclusion that, while clever, the C code in qmail and djbdns has
clearly been compiled down from some higher level language[1]. If
that code is anything, it is idiosyncratic.

[1] Having asked this question directly to DJB in person, I can say
that I am at least convinced he wrote this stuff in C.

[...]

tptacek 2304 days ago

The formatting, the heavy reliance on idiosyncratic CPP macros,
and more than anything else the repetitively procedural nature
of it is what set off alarm bells for us.

But really that's just the way he codes. It's very intricate.
It's like a very ugly Swiss watch.

[...]

(https://news.ycombinator.com/item?id=890558)

> I do not know why you think it *has* to be heavily patched. 
> It works for me without patching just fine, for example.

Many users have requirements that are not satisfied by the original
djbdns-1.05 source release.  For example, the following post from a
Facebook developer mentions that tinydns is used at Facebook, with
multiple patches, including an in-house IPv6 support patch:


https://lists.dns-oarc.net/pipermail/dns-operations/2016-February/014250.html

> The recent DNS standards (DNSSEC, I assume) it doesn't support is by
> design, as it is deemed broken by upstream author (see
> http://dnscurve.org/ for more details, for example) and the whole
> point of KISS principle is to keep it simple and use modular design
> for extra bloat if wanted (for example, even DJB's dnscurve is to be 
> implemented as separate independent softwa

Bug#814288: Generates corrupt (?) initrd images

[Christopher David Howie]

Package: initramfs-tools
Version: 0.120

I have a rather odd case where update-initramfs sometimes generates good
initrds and sometimes it does not.  I'm not sure if the bug lies here or
in the kernel, but after sinking hours into investigating this issues
I'm very confident there is a bug somewhere.  I figure I will start with
this package and see where we get.

Kernel info, for the record:

-
Linux debian-workstation 3.16.0-4-amd64 #1 SMP Debian
3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux
-

Every initrd generated on the target machine with "update-initramfs -k
all -u" causes a kernel panic on the next boot:

-
Initramfs unpacking failed: no cpio magic
/bin/sh: error while loading shared libraries: libc.so.6: cannot open
shared object file: No such file or directory
(usual "attempted to kill init" flood)
-

However, if I boot from the amd64-8.1.0 netinstall CD in rescue mode and
select the options that will chroot me into the root volume of the
target machine and run the same update-initramfs command there, then the
machine boots.

I captured an example of a working and a broken initrd.  If I extract
them (gunzip < $file | cpio -i -dv) and diff the two trees, only one
file reports as being different: /etc/boottime.kmap.gz .  If I gunzip
this file in both trees, diff reports no differences.

I am at a total loss to explain this behavior.  The same
update-initramfs / mkinitramfs are used to build both, since I am
chroot'd into the root volume when building from the rescue CD.  The
only different pieces are the running kernel, and various mounts (/dev,
/proc, etc.).  The same kernel is used to actually boot both generated
initrds.

Since the initrds are not small, I'm linking them instead of attaching them.

Working:


Broken:


Thanks for your time,

-- 
Chris Howie
http://www.chrishowie.com
http://en.wikipedia.org/wiki/User:Crazycomputers

If you correspond with me on a regular basis, please read this document:
http://www.chrishowie.com/email-preferences/

PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5


IMPORTANT INFORMATION/DISCLAIMER

This document should be read only by those persons to whom it is
addressed.  If you have received this message it was obviously addressed
to you and therefore you can read it.

Additionally, by sending an email to ANY of my addresses or to ANY
mailing lists to which I am subscribed, whether intentionally or
accidentally, you are agreeing that I am "the intended recipient," and
that I may do whatever I wish with the contents of any message received
from you, unless a pre-existing agreement prohibits me from so doing.

This overrides any disclaimer or statement of confidentiality that may
be included on your message.





signature.asc
Description: OpenPGP digital signature

Bug#814240: systemd triggers break upgrades within unstable

[Zack Weinberg]

On Tue, Feb 9, 2016 at 9:46 AM, Michael Biebl  wrote:
>>
>> It's possible to recover by manually installing the new versions of
>> libpam-systemd, systemd, and libsystemd0, but there's got to be some
>> way to make apt do the Right Thing, right?  (I don't really understand
>> triggers.  I thought they were supposed to postpone work until the *end*
>> of a large upgrade, but they seem to go off all the time in the middle.)
>>
>
> This looks like something which needs to be fixed in either dpkg or
> aptitude.
>
> Fwiw, I've never seen such a problem using apt.

I do not have either the time or the skills to dig into this any
further, but I suggest you reassign the bug to dpkg and maybe they can
do something with it?

zw

Bug#814286: RFP: node-resumer -- a through stream that starts paused and resumes on the next tick

[Ross Gammon]

Package: wnpp
Severity: wishlist

* Package name: node-resumer
  Version : 0.0.0
  Upstream Author : James Halliday  (http://substack.net)
* URL : https://github.com/substack/resumer
* License : Expat
  Programming Lang: JavaScript
  Description : a through stream that starts paused and resumes on the next
tick

 Return a through stream that starts out paused and resumes on the next tick,
unless somebody called .pause().
 .
 This module has the same signature as through.
 .
 Node.js is an event-based server-side JavaScript engine.

Node-resumer is a dependency of node-tape (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=798278) and should probably be maintained within the
Debian Javascript Team.

Bug#814287: Recent security fix for symlinks renders root filesystem exports unusable

[Petr Vandrovec]

Package: samba
Version: 2:4.3.3+dfsg-1+b1
Severity: important

Since I updated samba package to latest version, I cannot access my exports:
==
> net use w: \\petr-dev3\rootfs\bhavesh\home\petr  /user:petr
System error 5 has occurred.

Access is denied.
==

It seems to me that there is a thinko in how export of '/' directory is 
handled, ending up with:


check_reduced_name: Bad access attempt: bhavesh/home/petr is a symlink 
outside the share path

conn_rootdir =/
resolved_name=/bhavesh/home/petr

despite there being no symlinks involved, and /bhavesh/home/petr being 
inside / space.


For now I've worked around the problem by setting

follow symlinks = yes
wide links = yes
allow insecure wide links = yes

but I do not think I should be forced to enable 'follow symlinks' to use 
symlink-less share.


Petr
[2016/02/09 13:11:33.139038,  5, pid=17936, effective(0, 0), real(0, 0)] 
../source3/auth/token_util.c:639(debug_unix_user_token)
  UNIX token of user 884
  Primary group is 201 and contains 20 supplementary groups
  Group[  0]: 201
  Group[  1]: 0
  Group[  2]: 4
  Group[  3]: 5
  Group[  4]: 6
  Group[  5]: 7
  Group[  6]: 15
  Group[  7]: 20
  Group[  8]: 24
  Group[  9]: 25
  Group[ 10]: 26
  Group[ 11]: 27
  Group[ 12]: 29
  Group[ 13]: 44
  Group[ 14]: 46
  Group[ 15]: 50
  Group[ 16]: 118
  Group[ 17]: 1010
  Group[ 18]: 1031
  Group[ 19]: 104310
[2016/02/09 13:11:33.139074,  5, pid=17936, effective(884, 201), real(884, 0)] 
../source3/smbd/uid.c:363(change_to_user_internal)
  Impersonated user: uid=(884,884), gid=(0,201)
[2016/02/09 13:11:33.139081,  4, pid=17936, effective(884, 201), real(884, 0), 
class=vfs] ../source3/smbd/vfs.c:844(vfs_ChDir)
  vfs_ChDir to /
[2016/02/09 13:11:33.139093,  4, pid=17936, effective(884, 201), real(884, 0), 
class=vfs] ../source3/smbd/vfs.c:855(vfs_ChDir)
  vfs_ChDir got /
[2016/02/09 13:11:33.139102, 10, pid=17936, effective(884, 201), real(884, 0)] 
../source3/smbd/smb2_create.c:501(smbd_smb2_create_send)
  smbd_smb2_create: name[bhavesh\home\petr]
[2016/02/09 13:11:33.139110, 10, pid=17936, effective(884, 201), real(884, 0)] 
../source3/smbd/smb2_create.c:932(smbd_smb2_create_send)
  smbd_smb2_create_send: open execution phase
[2016/02/09 13:11:33.139121,  5, pid=17936, effective(884, 201), real(884, 0)] 
../source3/smbd/filename.c:257(unix_convert)
  unix_convert called on file "bhavesh/home/petr"
[2016/02/09 13:11:33.139129, 10, pid=17936, effective(884, 201), real(884, 0)] 
../source3/smbd/statcache.c:244(stat_cache_lookup)
  stat_cache_lookup: lookup failed for name [BHAVESH/HOME/PETR]
[2016/02/09 13:11:33.139136, 10, pid=17936, effective(884, 201), real(884, 0)] 
../source3/smbd/statcache.c:244(stat_cache_lookup)
  stat_cache_lookup: lookup failed for name [BHAVESH/HOME]
[2016/02/09 13:11:33.139141, 10, pid=17936, effective(884, 201), real(884, 0)] 
../source3/smbd/statcache.c:244(stat_cache_lookup)
  stat_cache_lookup: lookup failed for name [BHAVESH]
[2016/02/09 13:11:33.139148,  5, pid=17936, effective(884, 201), real(884, 0)] 
../source3/smbd/filename.c:449(unix_convert)
  unix_convert begin: name = bhavesh/home/petr, dirpath = , start = 
bhavesh/home/petr
[2016/02/09 13:11:33.139158,  5, pid=17936, effective(884, 201), real(884, 0)] 
../source3/smbd/statcache.c:143(stat_cache_add)
  stat_cache_add: Added entry (56549fbbc990:size 11) BHAVESH/HOME/PETR -> 
bhavesh/home/petr
[2016/02/09 13:11:33.139164,  5, pid=17936, effective(884, 201), real(884, 0)] 
../source3/smbd/filename.c:472(unix_convert)
  conversion of base_name finished bhavesh/home/petr -> bhavesh/home/petr
[2016/02/09 13:11:33.139171, 10, pid=17936, effective(884, 201), real(884, 0), 
class=vfs] ../source3/smbd/vfs.c:1147(check_reduced_name)
  check_reduced_name [bhavesh/home/petr] [/]
[2016/02/09 13:11:33.139182, 10, pid=17936, effective(884, 201), real(884, 0), 
class=vfs] ../source3/smbd/vfs.c:1207(check_reduced_name)
  check_reduced_name realpath [bhavesh/home/petr] -> [/bhavesh/home/petr]
[2016/02/09 13:11:33.139189,  2, pid=17936, effective(884, 201), real(884, 0), 
class=vfs] ../source3/smbd/vfs.c:1240(check_reduced_name)
  check_reduced_name: Bad access attempt: bhavesh/home/petr is a symlink 
outside the share path
  conn_rootdir =/
  resolved_name=/bhavesh/home/petr
[2016/02/09 13:11:33.139198,  5, pid=17936, effective(884, 201), real(884, 0)] 
../source3/smbd/filename.c:1078(check_name)
  check_name: name bhavesh/home/petr failed with NT_STATUS_ACCESS_DENIED
[2016/02/09 13:11:33.139204,  3, pid=17936, effective(884, 201), real(884, 0)] 
../source3/smbd/filename.c:1431(filename_convert_internal)
  filename_convert_internal: check_name failed for name bhavesh/home/petr with 
NT_STATUS_ACCESS_DENIED

petr-dev3:/bhavesh/home/petr/debian/samba-4.3.3+dfsg$ ls -lad /
drwxr-xr-x 84 root root 4096 Aug 10  2015 /
petr-dev3:/bhavesh/home/petr/debian/samba-4.3.3+dfsg$ ls -lad /bhavesh
drwxr-xr-x 13 root root 4096 Jan  6  2014 /bhavesh

Bug#814285: debhelper: dh_ucf must be called after dh_installinfo

[Дилян Палаузов]

Package: debhelper
Version: 9.20150101
Severity: normal

Dear Maintainer,

because on "dh install" dh_installinit is called before db_ucf, the generated 
poistinst file first tries to execute the daemon, and then to install its 
configuration files.

Please move dh_ucf before dh_installinit in the dh script.

Kind regards
  Dilian

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

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

Versions of packages debhelper depends on:
ii  binutils  2.25-5
ii  dpkg  1.17.26
ii  dpkg-dev  1.17.26
ii  file  1:5.22+15-2+deb8u1
ii  libdpkg-perl  1.17.26
ii  man-db2.7.0.2-5
ii  perl  5.20.2-3+deb8u3
ii  po-debconf1.0.16+nmu3

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#814284: RFP: node-object-inspect -- string representations of objects in node and the browser

[Ross Gammon]

Package: wnpp
Severity: wishlist

* Package name: node-object-inspect
  Version : 1.1.0
  Upstream Author : James Halliday  (http://substack.net)
* URL : https://github.com/substack/object-inspect
* License : Expat
  Programming Lang: JavaScript
  Description : string representations of objects in node and the browser

 Node-object-inspect provides string representations of objects in node and the
browser.
 .
 Node.js is an event-based server-side JavaScript engine.

Node-object-inspect is a dependency of node-tape (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=798278) and should probably be maintained within the
Debian Javascript Team.

Bug#814272: simgrid: FTBFS: Could not figure the stack direction.

[Aaron M. Ucko]

Martin Quinson  writes:

> I would say that the fallback works, as it managed to compile on i386 ;)

It failed on kfreebsd-* with this same error, though.

> Many thanks to you for investigating so far. 

Thanks for the quick response.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#814283: RFP: node-has -- Object.prototype.hasOwnProperty.call shortcut

[Ross Gammon]

Package: wnpp
Severity: wishlist

* Package name: node-has
  Version : 1.0.1
  Upstream Author : Thiago de Arruda 
* URL : https://github.com/tarruda/has
* License : Expat
  Programming Lang: JavaScript
  Description : Object.prototype.hasOwnProperty.call shortcut

 Has is a shortcut for Object.prototype.hasOwnProperty.call.
 .
 Node.js is an event-based server-side JavaScript engine.

Node-has is a dependency of node-tape (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=798278) and should probably be maintained within the
Debian Javascript Team.

Bug#792239: sessionclean does not support tiered session directory structure)

[Justin Pasher]

Still no update?

Justin Pasher

Bug#814272: simgrid: FTBFS: Could not figure the stack direction.

[Martin Quinson]

Hello,

On Tue, Feb 09, 2016 at 03:09:09PM -0500, Aaron M. Ucko wrote:
> 
> Automated builds of simgrid generally failed:

Yes, that hurts. It's all red! pitty.

>   ERRORCould not figure the stack direction.
>   -- LTO seems usable.
>   -- Add CFLAGS: "-g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -O3" to CMAKE_C_FLAGS
>   [...]
>   /«PKGBUILDDIR»/src/simix/smx_context.c:142:16: error: 'PTH_STACKGROWTH' 
> undeclared (first use in this function)
> 
> It's not entirely clear from the public logs what went wrong, but I
> suspect CMake may have tried to build prog_stackgrowth.c with -O3,
> which turns on -finline-functions, breaking the test.

Parallel building does not help here, for sure. And the diagnosis
further is complicated by the fact that my cmake output was broken
when the stack direction detection fails (I'm in the upstream team). 
I just commited a fix for that message, so that we get more info.

That is why the build starts even after the line "ERRORCould not
figure the stack direction", sorry.

Your analysis would be correct: these flags clearly break the stack
test. That is why they get added at the end of the configuration, once
all tests are ran. So, this is not it.

> The fallback
> logic didn't help even on the limited set of processor types it tried
> to cover because CMAKE_SYSTEM_PROCESSOR corresponds to the output of
> uname -p (typically "unknown" on Debian) rather than uname -m.

I would say that the fallback works, as it managed to compile on i386 ;)

But this is not an option, I'll investiguate further. Right now, I
forgot my laptop adapter at lab, and I will soon be offline... If you
want to give it a spin, the modified version is in the package git.

> Could you please take a look?

Many thanks to you for investigating so far. 

Bye, Mt.

-- 
It is not in improving the candle technology that 
electricty was discovered, understood and mastered.


signature.asc
Description: PGP signature

Bug#814281: RFP: node-function-bind -- Implementation of Function.prototype.bind

[Ross Gammon]

Package: wnpp
Severity: wishlist

* Package name: node-function-bind
  Version : 1.0.2
  Upstream Author : Raynos 
* URL : https://github.com/Raynos/function-bind
* License : Expat
  Programming Lang: JavaScript
  Description : Implementation of Function.prototype.bind

 Function-bind can be used for unit tests, and is useful for webframeworks that
do not have the function-bind.
 .
 Node.js is an event-based server-side JavaScript engine.

Node-function-bind is a dependency of node-tape (https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=798278), and should probably be maintained within the
Debian Javascript Team.

Bug#814282: ports lists unofficial ports as official

[Martin Michlmayr]

Package: www.debian.org

https://www.debian.org/ports/ says that ia64, s390 and sparc are
official ports.  Neither are official ports anymore.  I believe they
are all discontinued but I'm not 100% sure if they are still around in
some unofficial capacity.

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

Bug#814280: qt4-x11: please support fixed timestamps in qhelpgenerator

[Dhole]

Source: qt4-x11
Version: 4:4.8.7+dfsg-5
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

While working on the "reproducible builds" effort [1], we have noticed
that the qhelpgenerator tool from qt4-x11 embeds timestamps on the
creation of qch files.

Some months ago I sent a patch to fix this issue by enabling
qhelpgenerator to use the environment variable SOURCE_DATE_EPOCH when
embedding timestamps [1]. 

Sune Vuorela suggested that it would be better to backport the solution
he implemented for qt5 to solve this same issue, which consists in
replacing the embedded timestamp by a fixed one [2] and which is already
upstream.

The attached patch solves the reproducible timestamps issue in the same
way as it is solved in qt5 upstream.  With the attached patch packages
using qhelpgenerator would then automatically embed reproducible
timestamps in qch files.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794681
[2] https://codereview.qt-project.org/#/c/106296/

Cheers
-- 
Dhole
diff -Nru qt4-x11-4.8.7+dfsg/debian/changelog 
qt4-x11-4.8.7+dfsg/debian/changelog
--- qt4-x11-4.8.7+dfsg/debian/changelog 2015-11-30 20:13:35.0 +0100
+++ qt4-x11-4.8.7+dfsg/debian/changelog 2016-02-09 18:43:42.0 +0100
@@ -1,3 +1,12 @@
+qt4-x11 (4:4.8.7+dfsg-5.0~reproducible0) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport patch from qttools5 [1] to make qch files reproducible by
+replacing the current time by a fixed date.  
+[1] https://codereview.qt-project.org/#/c/106296/
+
+ -- Eduard Sanou   Tue, 09 Feb 2016 13:34:21 +0100
+
 qt4-x11 (4:4.8.7+dfsg-5) unstable; urgency=medium
 
   * Add no-ssl3.patch to avoid calling SSLv3 functions as they have been 
removed
diff -Nru 
qt4-x11-4.8.7+dfsg/debian/patches/replace_timestamps_with_fixed_date_in_qhelpgenerator.patch
 
qt4-x11-4.8.7+dfsg/debian/patches/replace_timestamps_with_fixed_date_in_qhelpgenerator.patch
--- 
qt4-x11-4.8.7+dfsg/debian/patches/replace_timestamps_with_fixed_date_in_qhelpgenerator.patch
1970-01-01 01:00:00.0 +0100
+++ 
qt4-x11-4.8.7+dfsg/debian/patches/replace_timestamps_with_fixed_date_in_qhelpgenerator.patch
2016-02-09 18:49:02.0 +0100
@@ -0,0 +1,51 @@
+Description: Replace timestamps from qhelpgenerator by a fixed date 
+ In order to make qhelpgenerator output reproducible, we need a way to get
+ deterministic embedded timestaps.  Backport the patch from qttools5 [1] to
+ make qch files reproducible by replacing the current time by a fixed date.  
+
+ [1] https://codereview.qt-project.org/#/c/106296/
+Author: Eduard Sanou 
+
+---
+
+Index: qt4-x11-4.8.7+dfsg/tools/assistant/lib/qhelpgenerator.cpp
+===
+--- qt4-x11-4.8.7+dfsg.orig/tools/assistant/lib/qhelpgenerator.cpp
 qt4-x11-4.8.7+dfsg/tools/assistant/lib/qhelpgenerator.cpp
+@@ -380,9 +380,7 @@ bool QHelpGenerator::createTables()
+ 
+ d->query->exec(QLatin1String("INSERT INTO MetaDataTable 
VALUES('qchVersion', '1.0')"));
+ 
+-d->query->prepare(QLatin1String("INSERT INTO MetaDataTable 
VALUES('CreationDate', ?)"));
+-d->query->bindValue(0, 
QDateTime::currentDateTime().toString(Qt::ISODate));
+-d->query->exec();
++d->query->exec(QLatin1String("INSERT INTO MetaDataTable 
VALUES('CreationDate', '2012-12-20T12:00:00Z')"));
+ 
+ return true;
+ }
+Index: qt4-x11-4.8.7+dfsg/tools/assistant/tools/qcollectiongenerator/main.cpp
+===
+--- qt4-x11-4.8.7+dfsg.orig/tools/assistant/tools/qcollectiongenerator/main.cpp
 qt4-x11-4.8.7+dfsg/tools/assistant/tools/qcollectiongenerator/main.cpp
+@@ -521,7 +521,7 @@ int main(int argc, char *argv[])
+ CollectionConfiguration::setAddressBarVisible(helpEngine,
+  !config.hideAddressBar());
+ CollectionConfiguration::setCreationTime(helpEngine,
+-QDateTime::currentDateTime().toTime_t());
++QDateTime::fromString("2012-12-20T12:00:00Z", 
Qt::ISODate).toUTC().toTime_t());
+ CollectionConfiguration::setFullTextSearchFallbackEnabled(helpEngine,
+ config.fullTextSearchFallbackEnabled());
+ 
+Index: 
qt4-x11-4.8.7+dfsg/tools/assistant/tools/shared/collectionconfiguration.cpp
+===
+--- 
qt4-x11-4.8.7+dfsg.orig/tools/assistant/tools/shared/collectionconfiguration.cpp
 qt4-x11-4.8.7+dfsg/tools/assistant/tools/shared/collectionconfiguration.cpp
+@@ -282,7 +282,7 @@ const QDateTime CollectionConfiguration:
+ 
+ void CollectionConfiguration::updateLastRegisterTime(QHelpEngineCore 
&helpEngine)
+ {
+-helpEngine.setCustomValue(LastRegisterTime, QDateTime::currentDateTime());
++helpEngine.setCustomValue(LastRegisterTime, 
QDateTime::fromString("2012-12-20T12:00:00Z", Qt::ISODate).toUTC());
+ }
+ 
+ bool CollectionConfiguration::isNewe

Bug#814279: Suspend/resume brightness issue Debian 8 with i965 integrated video controller

[r]

Package: kernel
Version: 3.16.7-ckt20-1+deb8 amd64

The issue is related to the suspend/resume brightness with i965 integrated video
controller. I am able to hibernate and resume but I'm not able to resume from 
suspend. When I try to suspend both from GUI than from terminal (pm-suspend or
systemctl suspend) I get only a black screen on resume. The computer works but 
it seems that the brightness is set to zero and I can not turn the screen on. 
If I try to hibernate, on resume all works well. I try to switch from tt1 to 
tt6 
but nothing changes, the screen remain black. I also tried to use the 
brightness 
key but nothing happens.

I discovered the bug was not present in the previous debian
stable kernel 3.2 but is still present in the 4.2 and 4.3 kernel from
backports. I compiled my own 4.4 kernel and now all seems to work.

I run debian on a macbook 13". 

This is the C shared lib:
-
:~$ dpkg -l libc6
libc6:amd64  2.19-18+deb8u2 amd64
-

This is my graphic card:
-
:~$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 
Integrated Graphics Controller (primary) (rev 03)
-

This is dmesg after system resumed:
--
:~# echo mem > /sys/power/state; dmesg > dmesg_after_resume; reboot

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) 
(gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt20-1+deb8u3 
(2016-01-17)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 
root=UUID=c19ecd0c-f686-4d8e-b258-68744fb5d7ee ro quiet
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbdd30fff] usable
[0.00] BIOS-e820: [mem 0xbdd31000-0xbdf31fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbdf32000-0xbdfe3fff] ACPI data
[0.00] BIOS-e820: [mem 0xbdfe4000-0xbdfe5fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbdfe6000-0xbeec2fff] ACPI data
[0.00] BIOS-e820: [mem 0xbeec3000-0xbeec4fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbeec5000-0xbeec7fff] ACPI data
[0.00] BIOS-e820: [mem 0xbeec8000-0xbeecafff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbeecb000-0xbeecbfff] ACPI data
[0.00] BIOS-e820: [mem 0xbeecc000-0xbeedefff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbeedf000-0xbeef8fff] ACPI data
[0.00] BIOS-e820: [mem 0xbeef9000-0xbeefefff] reserved
[0.00] BIOS-e820: [mem 0xbeeff000-0xbeef] ACPI data
[0.00] BIOS-e820: [mem 0xbef0-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xffe0-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00013fff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Apple Inc. MacBook4,1/Mac-F22788A9, BIOS 
MB41.88Z.00C1.B00.0802091535 02/09/08
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] AGP: No AGP bridge found
[0.00] e820: last_pfn = 0x14 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-D uncachable
[0.00]   E-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0FFE0 mask FFFE0 write-protect
[0.00]   1 base 0 mask F8000 write-back
[0.00]   2 base 08000 mask FC000 write-back
[0.00]   3 base 1 mask FC000 write-back
[0.00]   4 base 0BF00 mask FFF00 uncachable
[0.00]   5 base 0BEF0 mask 0 uncachable
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] e820: last_pfn = 0xbdd31 max_arch_pfn = 0x4
[0.000

Bug#770369: I may have a solution for the bug 770369

[S Andreason]

Arnaud Ceyrolle wrote:
Hello, I think I might have found why Eterm is behaving like this and 
have also a solution.


From the source tarball listed in the page:
https://packages.debian.org/jessie/eterm

at the link in the right :
eterm_0.9.6.orig.tar.gz 



My modification is to just change the line 1564 in src/command.c
from
unsigned short i;
to
unsigned long i;

and recompile, it works for me.

Let me know if it works for you.


Hi Arnaud,

Good job! That fixes the bug.
Eterm is working now.

Stewart

Bug#814058: borgbackup: FTBFS on jessie: wrong build-deps and failing unittests

[Daniel Reichelt]

Thanks, Danny.

Hauler if you require manpower to test the packaging.

Thomas Waldmann gave his ok to use the upstream ML for coordination "if
they behave" ;-))

I think in the long run, borg-dev and borg-users lists on l.d.o would be
helpful.


Cheers

Daniel

Bug#811708: [PKG-OpenRC-Debian] Bug#811708: need help?

[Svante Signell]

On Mon, 2016-02-08 at 13:13 +0100, Svante Signell wrote:
> On Mon, 2016-02-08 at 08:26 +0100, Adam Borowski wrote:
> > > init-system-helpers: file conflict with openrc: /usr/sbin/update-rc.d
> > 
> > Uhm, guys... are you alive?  This bug keeps openrc uninstallable, and will
> > cause its autoremoval soon.
> > 
> > If you're too busy and need help, I could help with fixing or NMUing, but
> > you need to decide whether to:
> > * cooperate with init-system-helpers and put the logic there (like sysv-rc)
> > * divert update-rc.d (like file-rc)
> > 
> > Note that I'm not the best person to help, though, as I use openrc only on a
> > single desktop and thus don't know anything about its advanced features nor
> > internals.
> 
> Hi Adam,
> Cc: Roger
> 
> I sent the following mail to the openrc maintainers: Benda Xu, Thomas Goirand
> and Roger Leigh on Friday February 5th (no reply so far). The mail to Roger
> bounced, he is no longer a Debian maintainer.
> 
> > Hello,
> > 
> > Due to the serious bug 811708 openrc (0.18.3-1) will be removed from Debian
> > testing on February 18. In my opinion it would be a pity if it disappears.
> > 
> > Is it possible to do as file-rc (0.8.17) did in bug 812337: add a diversion?
> > 
> > From changelog: divert update-rc.d + invoke-rc.d files to cooperate with
> > init-
> > system-helpers >=1.25. It seems like only divert() in preinst and
> > undivert() in
> > postrm scripts has to be created and called.

Attached are patches of debian/changelog and new files debian/preinst and
debian/postrm. Maybe the debian/control file has to be modified too. Are they
sufficient to create a diversion of openrc so that bug 811708 can be closed? I
have not yet had time to test-install, the plan is to do that for GNU/Linux and
GNU/Hurd.

--- a/debian/changelog.orig	2015-11-09 15:11:35.0 +0100
+++ b/debian/changelog	2016-02-09 22:41:37.0 +0100
@@ -1,3 +1,11 @@
+openrc (0.18.3-2) unstable; urgency=medium
+  * Create debian/{preinst,postrm} scripts as for file-rc to
+divert update-rc.d + invoke-rc.d files to cooperate with
+init-system-helpers >=1.25
+(Closes: #811708)
+
+ -- Svante Signell   Tue, 09 Feb 2016 16:53:58 +0100
+
 openrc (0.18.3-1) unstable; urgency=medium
 
   [ Dmitry Yu Okunev ]


postrm
Description: application/shellscript


preinst
Description: application/shellscript

Bug#213013: Account Verification

[PayPal Online Security]

Dear Valued User,

Our automatic security system indicates that someone was trying to use your 
account without your consent.

When PayPal limits an account, we are simply asking you to provide information 
which verifies your identity that links to your account.

We have sent you this notification hoping that you would provide some 
information with us; thus verifying that you are the legitimate account holder.
By downloading and filling in the form that we have supplied in the 
'attachment', you may proceed to verifying your account.

Please note that your account will be restored back to its normal state after 
you have provided valid information in the form.

We apologize for the inconvenience this may have caused. We hope this issue 
gets resolved today.

Sincerely,
PayPal Account Security Team



verification.html
Description: Binary data

Bug#811172: Fixed upstream

[Tristan Seligmann]

This is fixed in e7316a1 [1] upstream, may be worth backporting that patch.

[1] https://bitbucket.org/durin42/hg-git/commits/e7316a1

Bug#784673: cloud-utils: growpart fails with gpt

[Tiago Ilieve]

Hi Frederic,

I've tried to reproduce this issue using cloud-utils (0.26-2) on Jessie:

root@virtualbox:~# growpart -v /dev/sda 1
geometry is -C 2610 -H 255 -S 63. total size=41929650
max_end=41929650 tot=41929650 pt_end=41943040 pt_start=1 pt_size=41943039
NOCHANGE: partition 1 could only be grown by -13390 [fudge=20480]

And the output was a little bit different, but the result is the same,
as it could not grow the partition.

Then I've tried using cloud-utils (0.27-2) from Stretch on Jessie:

root@virtualbox:~# growpart -v /dev/sda 1
update-partition set to true
FAILED: GPT partition found but no sgdisk

And after installing "gdisk":

root@virtualbox:~# growpart -v /dev/sda 1
update-partition set to true
found GPT partition table (id = ee)
disk=/dev/sda partition=1: original sgdisk info:
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 4F846BCA-2671-486C-AFD7-6DBA157FDDD1
First sector: 2048 (at 1024.0 KiB)
Last sector: 15624191 (at 7.5 GiB)
Partition size: 15622144 sectors (7.4 GiB)
Attribute flags: 
Partition name: ''
Disk /dev/sda: 41943040 sectors, 20.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D9C74796-7ED9-49AA-84C7-808685BC8ED7
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 41943006
Partitions will be aligned on 2048-sector boundaries
Total free space is 26320829 sectors (12.6 GiB)

Number  Start (sector)End (sector)  Size   Code  Name
   1204815624191   7.4 GiB 8300
disk=/dev/sda partition=1: pretend sgdisk info
Disk /dev/sda: 41943040 sectors, 20.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): D9C74796-7ED9-49AA-84C7-808685BC8ED7
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 41943006
Partitions will be aligned on 2048-sector boundaries
Total free space is 26320829 sectors (12.6 GiB)

Number  Start (sector)End (sector)  Size   Code  Name
   1204815624191   7.4 GiB 8300
disk=/dev/sda partition=1: pt_start=2048 pt_end=15624191
pt_size=15622143 pt_max=41943006 last=41943006
disk=/dev/sda partition=1: code=0FC63DAF-8483-4772-8E79-3D69D8477DE4
guid=4F846BCA-2671-486C-AFD7-6DBA157FDDD1 name=''
CHANGED: disk=/dev/sda partition=1: start=2048 old:
size=15622143,end=15624191 new: size=41940958,end=41943006

Everything went fine and "resize2fs" is now able to expand the filesystem:

root@virtualbox:~# resize2fs /dev/sda1
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/sda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/sda1 is now 5242619 (4k) blocks long.

root@virtualbox:~# df -h | grep sda1
/dev/sda120G  951M   18G   5% /

Then I've restored a snapshot, upgraded the machine to sid/unstable
and tried again.

Using cloud-utils (0.27-2) from Sid:

root@virtualbox:~# growpart -v /dev/sda 1
update-partition set to true
found MBR partition table (id = 0FC63DAF-8483-4772-8E79-3D69D8477DE4)
total number of sectors of /dev/sda is 41943040
## sfdisk --dump /dev/sda
label: gpt
label-id: D9C74796-7ED9-49AA-84C7-808685BC8ED7
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 41943006

/dev/sda1 : start=2048, size=15622144,
type=0FC63DAF-8483-4772-8E79-3D69D8477DE4,
uuid=4F846BCA-2671-486C-AFD7-6DBA157FDDD1
max_end=41943040 tot=41943040 pt_end=15624192 pt_start=2048 pt_size=15622144
attempt to resize /dev/sda failed. sfdisk output below:
| The last usable GPT sector is 41943006, but 41943039 is requested.
| Failed to add partition: Invalid argument
| Backup files:
| PMBR (offset 0, size   512):
/tmp/growpart.YN5dSL/backup-sda-0x.bak
|   GPT Header (offset   512, size   512):
/tmp/growpart.YN5dSL/backup-sda-0x0200.bak
|  GPT Entries (offset  1024, size 16384):
/tmp/growpart.YN5dSL/backup-sda-0x0400.bak
|
| Disk /dev/sda: 20 GiB, 21474836480 bytes, 41943040 sectors
| Units: sectors of 1 * 512 = 512 bytes
| Sector size (logical/physical): 512 bytes / 512 bytes
| I/O size (minimum/optimal): 512 bytes / 512 bytes
| Disklabel type: gpt
| Disk identifier: D9C74796-7ED9-49AA-84C7-808685BC8ED7
|
| Old situation:
|
| Device Start  End  Sectors  Size Type
| /dev/sda1   2048 15624191 15622144  7.5G Linux filesystem
|
| >>> Script header accepted.
| >>> Script header accepted.
| >>> Script header accepted.
| >>> Script header accepted.
| >>> Script header accepted.
| >>> Script header accepted.
| >>> Created a new GPT disklabel (GUID: D9C74796-7ED9-49AA-84C7-808685BC8ED7).
| Leaving.
|
FAILED: failed to resize
* WARNING: Resize failed, attempting to revert **
512+0 records in
512+0 records out
512 bytes copied, 0.00159423 s, 321 kB/s
* Appears to have gone OK 

The partition could not be grown and now "resize2fs" can't do anything:

root@virtualbox:~# resize2fs /dev/sda1
resize2fs 1.42.13 (17-May-2015)
The filesystem is already 1952768 (4k) blocks long.

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

[Jose M Calhariz]

On 08/02/16 21:57, Mattia Rizzolo wrote:
> On Mon, Feb 08, 2016 at 09:29:55PM +, Jose M Calhariz wrote:
>> Today I didn't review all yours remarks.  But in the spirit of release
>> early and release often here goes my today effort.
> yay, I definitely approve this ;)
> I hadn't gone deeper, just commented on your last changes here.
>
>> On 07/02/16 22:01, Mattia Rizzolo wrote:
>>> On Sun, Feb 07, 2016 at 08:40:10PM +, Jose M Calhariz wrote:
 On 06/02/16 23:41, Mattia Rizzolo wrote:
> Umh, couldn't you turn d/rules to use the dh sequencer?
 I don't know enough and lintian show many problems with upstream d/rules.
>>> well, let's fix them, then :)
>>> Attached there is a d/rules using short dh, may you try it and bend it
>>> better to the needs of this package?
>> I managed to make it compile, but for a reason I don't know I needed to
>> add the following lines:
>>
>> override_dh_auto_configure:
>> cp /usr/share/misc/config.guess .
>> cp /usr/share/misc/config.sub .
>> dh_auto_configure --parallel
> that's so weird.
>
> even more in light of the new dh_update_autotools_config which is run
> automatically by dh >= 9.20160114 and do exactly that.
> Are you testing your package in an update sid chroot?

Maybe the difference is that I build the software using:

time gbp buildpackage --git-pbuilder --git-ignore-new

or in a recent sid chroot:

time debuild -uc -us

I found another way to fix it, that seams to me to be more correct.

override_dh_clean:
dh_clean --exclude=config.sub --exclude=config.guess


>
>> I have tried many ideas but was only this way that it build
> also, it did build here without them.
>
> * d/copyright: consider write a copyright-format 1.0 one?  at a first
>   sight doesn't look too much work.
 Done
>>> though it's not compliant, and indeed lintian is noisy on it, please try
>>> to figure out what's wrong with it and fix it.
>>> I believe blindly following lintian here is enough, though it would be
>>> nice if you could understand what's the problem by yourself :)
>> I fix it, but I don't understand why :-)
> ok, I'm going to assume you read all of
> https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ and
> somehow did not understand it.
>
> DEP-5 copyright is RFC 822-compliant file where there are basically 3
> types of paragraphs:
>  * the header paragraph => you know it
>  * the file paragraphs
>  * the stand alone license paragraphs
>
> the file paragraph is composed by at least
>  * Files:
>  * Copyright:
>  * License:
>
> in your earlier attempt at it you put a blank line between Copyright and
> License, and de-facto created a separated pargraph, totally disconnected
> from the previous one.  That one by itself was a compliant stand alone
> license paragraph, but
>  1) it was repeated by another one later
>  2) it was not refereced by a License: line from a file paragraph.
>
>
> I hope I made the thing at least clearer.

Thank you.

>
> * please try to get a reproducible buildable package, from what I see it
>   wouldn't be difficult at all.
> ♥ THANK YOU! :D
>
> there are 57 open bugs, are you telling me none of them get closed by
> this upload? :\
> ok, I saw you added some closes: to the bug, and added a line to the
> changelog saying that you closed those bugs.  meh.
> you should explicitly list what you are closing, briefly; probably the
> best way is in a indented list, something like
>   * New upstream version.
> + Fix blabla due to fofo.  Closes: #x
> + Fix ciaciaaicegow.  Closes: #y
> And adding to the changelog a sentence like "I closed bugs" is totally
> useless, just remove it :)
>

Ok.  I estimate this will take some days.





signature.asc
Description: OpenPGP digital signature

Bug#814278: quassel-data contains a far outdated version of inxi

[Alf Gaida]

Package: quassel-data
Version: 1:0.12.2-3
Severity: normal

Dear Maintainer,
quassel-data contain a far outdated version of inxi. There are a few possible 
solutions:
* simply delete the script
* let quassel-data depend on inxi and link to inxi which is packaged in debian

Thanks Alf

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

Kernel: Linux 4.4.1-towo.1-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
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)

quassel-data depends on no packages.

Versions of packages quassel-data recommends:
ii  oxygen-icon-theme  4:4.14.0-1

quassel-data suggests no packages.

-- no debconf information

Bug#814277: Please update to dfu-util 0.9

[Tormod Volden]

Package: dfu-util
Severity: wishlist

Dear maintainer,

dfu-util 0.9 has been released and it would be great to see it in unstable.

I have attached a patch for the debian directory. Notably, the
upstream location has changed, and the watch file has been corrected.

Please let me know if there is something I can do to help.

Best regards,
Tormod
diff -Nurp dfu-util-0.8/debian/changelog dfu-util-0.9/debian/changelog
--- dfu-util-0.8/debian/changelog	2014-10-04 16:48:11.0 +0200
+++ dfu-util-0.9/debian/changelog	2016-02-09 21:47:40.433422482 +0100
@@ -1,3 +1,10 @@
+dfu-util (0.9-1) unstable; urgency=medium
+
+  * New upstream release
+  * Updated upstream location in control/copyright/watch
+
+ -- Tormod Volden   Tue, 09 Feb 2016 21:20:40 +0100
+
 dfu-util (0.8-1) unstable; urgency=medium
 
   * New upstream release (Closes: #696866).
diff -Nurp dfu-util-0.8/debian/control dfu-util-0.9/debian/control
--- dfu-util-0.8/debian/control	2014-10-04 16:49:24.0 +0200
+++ dfu-util-0.9/debian/control	2016-02-09 21:23:46.106317588 +0100
@@ -4,7 +4,7 @@ Priority: extra
 Maintainer: Uwe Hermann 
 Build-Depends: cdbs, debhelper (>= 9), autotools-dev, libusb-1.0-0-dev, pkg-config
 Standards-Version: 3.9.6
-Homepage: http://dfu-util.gnumonks.org/
+Homepage: http://dfu-util.sourceforge.net
 
 Package: dfu-util
 Architecture: any
diff -Nurp dfu-util-0.8/debian/copyright dfu-util-0.9/debian/copyright
--- dfu-util-0.8/debian/copyright	2014-10-04 16:36:43.0 +0200
+++ dfu-util-0.9/debian/copyright	2016-02-09 21:41:29.074231284 +0100
@@ -1,10 +1,10 @@
 Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: dfu-util
-Source: http://dfu-util.gnumonks.org
+Source: http://dfu-util.sourceforge.net
 
 Files: *
 Copyright: 2005-2006 Weston Schmidt 
-   2011-2014 Tormod Volden 
+   2011-2016 Tormod Volden 
 License: GPL-2+
  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
diff -Nurp dfu-util-0.8/debian/dfu-util.install dfu-util-0.9/debian/dfu-util.install
--- dfu-util-0.8/debian/dfu-util.install	2014-10-04 16:27:01.0 +0200
+++ dfu-util-0.9/debian/dfu-util.install	2016-02-09 21:27:10.307695568 +0100
@@ -1 +1,2 @@
 dfuse-pack.py usr/share/doc/dfu-util/examples
+doc/40-dfuse.rules usr/share/doc/dfu-util/examples

Bug#813125: pkg-php-tools for php7? [Was: phpcs upstream issue]

[David Prévot]

Hi,

> I guess nothing is stopping us to upload […]
> php-proxy-manager 2.0.0 to experimental.

Actually, it requires "php": "~7.0" in composer.json, that is currently
translated as php5-common (>= 7.0) by pkg-php-tools, and is thus is pretty
useless.

Mathieu, what are the blockers in pkg-php-tools preventing us from
starting the PHP 7 transition?

https://lists.debian.org/debian-devel-announce/2016/01/msg2.html

Regards

David

Bug#790271: Fix build failure in stable/jessie

[Petter Reinholdtsen]

[Petter Reinholdtsen]
> I do not remember the procedure for getting changes into stable, but
> hope to find time to investigate that some time in the future.

I did, and submitted https://bugs.debian.org/814266 > to request
an update.  If it is accepted, we can upload to stable to get the fix
into the next point release.

-- 
Happy hacking
Petter Reinholdtsen

Bug#778543: ITP: libffi-platypus-perl -- Perl FFI interface to non-Perl libraries without XS

[Jonas Smedegaard]

Hi Peter,

Quoting Peter Pentchev (2015-02-16 15:16:45)
> * Package name: libffi-platypus-perl

What is status of this package?

I have come to need it for recent releases of Message::Passing::ZeroMQ.

 - 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#814276: Non-Free file: src/stdlib/SDL_qsort.c

[stressware2]

Package: libsdl2
Version: 2.0.2+dfsg1-6
Severity: serious

The file 'src/stdlib/SDL_qsort.c' in SDL2 seems to disallow
modification.

The Debian copyright file simply mentions the license as:

  You may use it in anything you like; you may make money
  out of it; you may distribute it in object form or as
  part of an executable without including source code;
  you don't have to credit me. (But it would be nice if
  you did.)'.

What it does not mention is the text before that:

  * This code may be reproduced freely provided
  *   - this file is retained unaltered apart from minor
  * changes for portability and efficiency
  *   - no changes are made to this comment
  *   - any changes that *are* made are clearly flagged
  *   - the _ID string below is altered by inserting, after
  * the date, the string " altered" followed at your option
  * by other material. (Exceptions: you may change the name
  * of the exported routine without changing the ID string.
  * You may change the values of the macros TRUNC_* and
  * PIVOT_THRESHOLD without changing the ID string, provided
  * they remain constants with TRUNC_nonaligned, TRUNC_aligned
  * and TRUNC_words/WORD_BYTES between 8 and 24, and
  *   PIVOT_THRESHOLD between 32 and 200.)'.

Although the file states 'You may use it in anything you like', it
either contradicts itself, or is simply talking about using the
unmodified file in any program you like. The part before that clearly
says that the file cannot be 'reproduced freely' unless '[the] file is
retained unaltered apart from minor changes for portability and
efficiency'.

Bug#801925: NULL pointer dereference: IP: [] sr_runtime_suspend+0xc/0x20 [sr_mod]

[Ben Hutchings]

On Tue, 2016-02-09 at 20:56 +0100, Alexandre Rossi wrote:
> Hi,
> 
> netconsole does not seem to work so early in the boot process this time.
> 
> > As this is Linux 4.3 and not 4.4, I guess this is a different problem
> > though. Alexandre, where you able to capture the stack trace? I’d submit
> > a new bug report with this.
> 
> Here is a photo. Please ping me if you need to test some debugging patches.

I'm pretty sure this crash is fixed by commit 4fd41a8552af ("SCSI: Fix NULL
pointer dereference in runtime PM"), which I've now queued up for 4.3
(though it's already in 4.4 which I'll probably upload to unstable soon).

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.

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

Bug#814275: xserver-xorg-video-intel: pointer constrained to original display area after xrandr --scale with positive number

[Brian Ristuccia]

Package: xserver-xorg-video-intel
Version: 2:2.21.15-2+b2
Severity: normal


   * I ran "xrandr --output eDP1 --scale 1.2x1.2" to increase the effective
destop area
   * The area was increased, but the pointer cannot be moved beyond the
original dimensions
 of the screen.
   * I expected that the pointer could reach all of the effective desktop area



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Oct  8  2014 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 2401376 Feb 10  2015 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/libGLESv2.so to /usr/lib/mesa-diverted/libGLESv2.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so to /usr/lib/mesa-diverted/libGLESv1_CM.so 
by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu

Bug#814274: ITP: libffi-checklib-perl -- check that a library is available for FFI

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libffi-checklib-perl
  Version : 0.14
  Upstream Author : Graham Ollis 
* URL : http://perl.wdlabs.com/FFI-CheckLib
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : check that a library is available for FFI

 FFI::CheckLib checks whether a particular dynamic library is available
 for FFI to use.  It is modeled heavily on Devel::CheckLib, but will
 find dynamic libraries even when development packages are not
 installed.  It also provides a find_lib function that will return the
 full path to the found dynamic library, which can be feed directly into
 FFI::Platypus or FFI::Raw.

Package is needed for recent releases of libmessage-passing-zeromq-perl.

It will be maintained in the Perl team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWulDaAAoJECx8MUbBoAEhA/8P/1VerbXzp0RUTMVE5rDoXGRi
UUrJ+DHAJmVcxhWUFPh6pH6GIhnd52DDqyTREVyCJjjb64dx+tbjLfPCuKSNiUc9
1wFdOnHWFkE8fAfvswgwifWr0l0D0riUB5qil7gY/wm9peSZFAvLcx3/fcRtItaW
6Y9Mj7Z5dx8m5rnBJutKkMyPcxJWYxz0SXI5j+B3PT+29uzPuachm8XH1aPiF4FX
MKdwrt0bxdihKX43ksVrm1QlnongkySlHyaGWYRIq4Gk6RrEI40/B+0yU6jSbd0y
qxjLxfg153p6x9lmU96bPb4GHO1u1pHh/76p0D5gY6+jn/tt2Nvdp74HHns7vx9L
K/l8/KsLqwiJjynH3ktnRnTMg5U4wAA3aENZy+H7qwPg1nCekwMWv+X0p8sTG0Xo
5hp6lRZIOFoXSC9CoO1TqENtmBNppP6wdLaGM0kn2nSxiHaszGqveRmXPRiRJvky
yLfs8JQwVWMty1qPlrnoC1lddD8Qah7wVifhT3H1D9mkZsY46/pD0mD6Q7PQI+gM
sx+qmnNMZiS8u12LJsh5YyePFjwr+xvwtQnSOJTo41AlGuixb94KkSoL57ssgI+g
9cyY0BjIqFVfCABwjRs/NedoVcQd2H8hL016dhyUe0mbZNgfocIB/GMk3slDmJHI
yaOA+vWhuUiWa14phfXT
=XNHg
-END PGP SIGNATURE-

Bug#813125: [pkg-php-pear] Bug#813125: phpcs upstream issue [was: php-proxy-manager 2.0.0* has a dependency on a new PHP API PackageVersions]

[David Prévot]

Hi Nish,

>> On 09.02.2016 [15:17:17 -0400], David Prévot wrote:
>>> Le 09/02/2016 15:05, Nish Aravamudan a écrit :
>>>
 I was finally able to get to this, and I see build failures using that
 base (due to phpcs issues):
> […]
 I can fix this up on my end by putting in a staged build, but it seems
 like something needs to be fixed still?
>>>
>>> That’s probably caused by a new issue in php-codesniffer 2.5.1, e.g.,
>>>
>>> https://github.com/squizlabs/PHP_CodeSniffer/issues/876
>>
>> Did you mean an issue with 2.5.0?
>
> No. I believed 2.5.1 introduced an indent issue, and that
> php-proxy-manager was (probably automatically, with phpcbf) fixed to use
> the new (broken) phpcs behavior. I just run phpcbf/2.5.0 and now believe
> that I was wrong, so I’ll have a closer look at what broke with
> phpcs/2.5.1, and may upload the updated packages, or file/document a
> proper upstream issue.

Filed as https://github.com/squizlabs/PHP_CodeSniffer/issues/889

I guess nothing is stopping us to upload both php-codesniffer 2.5.1 and
php-proxy-manager 2.0.0 to experimental. I’ll upload a recent
php-codesniffer to unstable once the aforementioned upstream issue will be
fixed (one way or the other ;).

Regards

David

Bug#788257: Info received and FILED only (SSH packet_write_wait: Connection to ...: Broken pipe / Marvell 88E8071 PCI-E Gigabit Ethernet)

[Sebastian Andrzej Siewior]

Control: reassign -1 linux 3.16.7-ckt9-3~deb8u1
Control: retitle -1 sky2 NIC driver freezes the system (Marvell 0x436B / 
88E8071)

I hereby reassing the bug to the linux package since it has nothing to
do with openssh. Based on the last feedback from the submitter he
replaced the NIC and the problem is gone is it is looks like the sky2
driver. I assume it is the sky2 driver due to
|git grep 88E8071
|drivers/net/ethernet/marvell/sky2.c:{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 
0x436B) }, /* 88E8071 */

I kept the severity as-is and leave to the maintainer in charge to deal
with it as appropriate.

Sebastian

Bug#814273: ITP: libzmq-ffi-perl -- version agnostic Perl bindings for ZeroMQ using FFI

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libzmq-ffi-perl
  Version : 1.11
  Upstream Author : Dylan Cali 
* URL : https://metacpan.org/release/ZMQ-FFI
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : version agnostic Perl bindings for ZeroMQ using FFI

 ZMQ::FFI exposes a high level, transparent, OO interface to ZeroMQ
 independent of the underlying libzmq version.  Where semantics differ,
 it will dispatch to the appropriate backend for you.  As it uses FFI,
 there is no dependency on XS or compilation.

Package is needed for recent releases of libmessage-passing-zeromq-perl.

It will be maintained in the Perl team.

 - Jonas

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWulBCAAoJECx8MUbBoAEhD4AP/3LDgywHRsRWcJB7pAOn7hSA
ItcGn13cglCyxsNjgz7wKz9riB/jrDuCGS4r/2YSfSEXTd4oX2e34b3GmzUL2Azx
H2WhfNFvEQ+as3dBo/l58eyBvavfTy78NyDTpYmdyA6qq//oVVB+8DWCO2HLQVVh
HhVpK+Xu8e5ZCc3NwPBEpzw5jW5wJ+3fayn04jRfwz9OW+6H8RiH2QYqZyBIjtBt
7+pyJ+j0EKCPEi0RngsHMr62DHWQRL9PFSO/2yM36cWH0TljuZ3mzZLLbDTpkHix
KdCeLkTZoHhTD3zpcAngS5PQN2kRH4q9HR0OvleWS4SpmGeuWdPwoEwjLH0CaDsY
lxpY8Rj/kood8/3otf6fEr4us8sEfmL/iWp9wFnEU+Fy/55DryO2WSzRcqJpfiyv
Jyzh75J5gXTBol/Q+76u+qmft6X4nYY5Q38eXjMlWTOGfhd/gRPOSK/3WUrFDfg8
cHnqkRkaoTpPHlyERV0nOls63OVMmMqqbUGIFtzP8MVB5EIHEWibKzaYjMErFkDr
97PtaO18C2Ml7PwH1j/YcbWpzwwrNIelze3nfRG+g8oDl9L0+nKUKZ7ortx3cRp7
684wGq6vU/EqiP5wqSXm5asDiIxvDzOWPDJc6peHSobTElRYXQQgbloOle5YcP51
+uHfMn6fBYHuBE5vLrXw
=Ytq1
-END PGP SIGNATURE-

Bug#812750: wine: Gecko integration is broken

[Stephen Kitt]

On Tue, 9 Feb 2016 21:06:29 +0100, Stephen Kitt  wrote:
> * updating the licensing information for each new wine-gecko release is
>   extraordinarily time-consuming, on the order of 150-200h per release (and
>   even then I miss issues) – TBH I've stalled on this, I'm thinking of

Just to be clear, I haven't spent that amount of time on any release yet,
that's just what 2.40 feels like (I'm about a quarter of the way through).

Stephen


pgpUMhSadUHL2.pgp
Description: OpenPGP digital signature

Bug#761128: Processed: closing 761128

[Emilio Pozuelo Monfort]

Control: reopen -1

On 07/02/16 17:18, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
>> close 761128
> Bug #761128 [release.debian.org] transition: oce
> Marked Bug as done

This isn't finished yet; the old libraries are still in testing.

Cheers,
Emilio

Bug#791232: openvrml NMU

[Wookey]

OK. I just tested the fixes in openvrml for building on new arches (arm64, 
ppc64le, ppc64)
And I included the java fixes so that it would build.
But now neither of us can upload our NMU due to this g++-5 ABI issue.

The maintainer seems to be MIA (Sam - are you out there?) so I'd very
much like to just upload something if we can.

If we were really keen we'd do a library transition just to be on the
safe side. Does anyone know what's involved with that?

openvrml is kind of old and unloved these days, but I would expect
some software to be using it as it's a file format still supported by
some things. libg3d, meshlab and openscenegraph claim vrml support for
example? Did they drop it, do we not build the osg-vrml plugin,
perhaps they have internal code for reading? These are questions the
maintainer should be able to help answer.

I've tried a build but it failed after the src build, because debian
patches back in Makefile.am a 'lookat' target into, the source file
for which was removed in 2006! after dh_autoreconfing this gets back
into the build and it barfs.

GUess I'd better fix that and try again...

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#814272: simgrid: FTBFS: Could not figure the stack direction.

[Aaron M. Ucko]

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

Automated builds of simgrid generally failed:

  ERRORCould not figure the stack direction.
  -- LTO seems usable.
  -- Add CFLAGS: "-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -O3" to CMAKE_C_FLAGS
  [...]
  /«PKGBUILDDIR»/src/simix/smx_context.c:142:16: error: 'PTH_STACKGROWTH' 
undeclared (first use in this function)

It's not entirely clear from the public logs what went wrong, but I
suspect CMake may have tried to build prog_stackgrowth.c with -O3,
which turns on -finline-functions, breaking the test.  The fallback
logic didn't help even on the limited set of processor types it tried
to cover because CMAKE_SYSTEM_PROCESSOR corresponds to the output of
uname -p (typically "unknown" on Debian) rather than uname -m.

Could you please take a look?

Thanks!

Bug#812750: wine: Gecko integration is broken

[Stephen Kitt]

Hi Jens,

On Tue, 9 Feb 2016 19:49:43 +0100, Jens Reyer  wrote:
> Stephen, can you shed some light on the main problem(s) blocking
> frequent Gecko releases? Let's say, there's some chance that I help.

There are two issues:
* wine-gecko typically requires a git snapshot of mingw-w64, so supporting
  its build in Debian (with the aim of stable releases) requires identifying
  and porting the required patches to the current mingw-w64 release (upstream
  are quite helpful with this)
* updating the licensing information for each new wine-gecko release is
  extraordinarily time-consuming, on the order of 150-200h per release (and
  even then I miss issues) – TBH I've stalled on this, I'm thinking of
  working on a new approach where I just package the files that actually get
  used for the build and worry about the licensing information once I've
  figured that out

Ideally we could piggy-back on the iceweasel licensing information, since the
upstream code is pretty much the same, but that doesn't get updated all that
often so it isn't necessarily all that accurate. (Take that with a pinch of
salt though, I haven't checked the situation recently.)

Regards,

Stephen


pgptPDnMjjWrr.pgp
Description: OpenPGP digital signature

Bug#814271: php7.0-dev: ltmain.sh was moved, symlink broken

[Boris Madzar]

Package: php7.0-dev
Version: 7.0.3-3
Severity: important

Dear Maintainer,

/usr/lib/php/20151012/build/ltmain.sh links to 
../../../../share/libtool/config/ltmain.sh, however this target was moved to 
../../../../share/libtool/build-aux/ltmain.sh as of libtool 2.4.6-0.1
This breaks phpize entirely.

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

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

Versions of packages php7.0-dev depends on:
ii  autoconf   2.69-9
ii  automake   1:1.15-3
ii  libpcre3-dev   2:8.38-1
ii  libssl-dev 1.0.2f-2
ii  libtool2.4.6-0.1
ii  php7.0-cli 7.0.3-3
ii  php7.0-common  7.0.3-3
ii  shtool 2.0.8-8

Versions of packages php7.0-dev recommends:
ii  dh-php 0.5
ii  pkg-php-tools  1.31

php7.0-dev suggests no packages.

-- no debconf information

Bug#814269: jessie-pu: package nettle/2.7.1-5

[Magnus Holmgren]

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

OK to upload fix for https://bugs.debian.org/813679 (CVE-2015-8803 
CVE-2015-8804 CVE-2015-8805), as
suggested by (a member of) the security team? (Security-related bugs but 
unlikely to be exploitable.)

-- 
Magnus Holmgren
Debian Developer

diff -Nru nettle-2.7.1/debian/changelog nettle-2.7.1/debian/changelog
--- nettle-2.7.1/debian/changelog   2015-01-11 20:27:22.0 +0100
+++ nettle-2.7.1/debian/changelog   2016-02-07 19:52:57.0 +0100
@@ -1,3 +1,9 @@
+nettle (2.7.1-5+deb8u1) stable; urgency=low
+
+  * Fix CVE-2015-8803, CVE-2015-8804, and CVE-2015-8805 (Closes: #813679).
+
+ -- Magnus Holmgren   Sat, 06 Feb 2016 20:01:37 +0100
+
 nettle (2.7.1-5) unstable; urgency=medium
 
   * Add code to transition /usr/share/doc/nettle-dbg from directory to
diff -Nru nettle-2.7.1/debian/patches/cve-2015-8803_8805.patch 
nettle-2.7.1/debian/patches/cve-2015-8803_8805.patch
--- nettle-2.7.1/debian/patches/cve-2015-8803_8805.patch1970-01-01 
01:00:00.0 +0100
+++ nettle-2.7.1/debian/patches/cve-2015-8803_8805.patch2016-02-07 
19:40:25.0 +0100
@@ -0,0 +1,27 @@
+From: Niels Möller 
+Origin: upstream, 
https://git.lysator.liu.se/nettle/nettle/commit/c71d2c9d20eeebb985e3872e4550137209e3ce4d
+Subject: CVE-2015-8803 and CVE-2015-8805: Miscomputation bugs in secp-256r1 
modulo functions.
+
+--- a/ecc-256.c
 b/ecc-256.c
+@@ -108,7 +119,10 @@ ecc_256_modp (const struct ecc_curve *ec
+   u0 -= t;
+   t = (u1 < cy);
+   u1 -= cy;
+-  u1 += cnd_add_n (t, rp + n - 4, ecc->p, 3);
++
++  cy = cnd_add_n (t, rp + n - 4, ecc->p, 2);
++  u0 += cy;
++  u1 += (u0 < cy);
+   u1 -= (-t) & 0x;
+ }
+   rp[2] = u0;
+@@ -195,7 +209,7 @@ ecc_256_modq (const struct ecc_curve *ec
+ 
+   /* Conditional add of p */
+   u1 += t;
+-  u2 += (t<<32) + (u0 < t);
++  u2 += (t<<32) + (u1 < t);
+ 
+   t = cnd_add_n (t, rp + n - 4, ecc->q, 2);
+   u1 += t;
diff -Nru nettle-2.7.1/debian/patches/cve-2015-8804.patch 
nettle-2.7.1/debian/patches/cve-2015-8804.patch
--- nettle-2.7.1/debian/patches/cve-2015-8804.patch 1970-01-01 
01:00:00.0 +0100
+++ nettle-2.7.1/debian/patches/cve-2015-8804.patch 2016-02-06 
19:50:51.0 +0100
@@ -0,0 +1,252 @@
+Origin: upstream, 
https://git.lysator.liu.se/nettle/nettle/commit/fa269b6ad06dd13c901dbd84a12e52b918a09cd7
+From: Niels Möller 
+Subject: CVE-2015-8804: Carry folding bug in x86_64 ecc_384_modp.
+
+--- a/x86_64/ecc-384-modp.asm
 b/x86_64/ecc-384-modp.asm
+@@ -20,7 +20,7 @@ C MA 02111-1301, USA.
+   .file "ecc-384-modp.asm"
+ 
+ define(, <%rsi>)
+-define(, <%rax>)
++define(, <%rax>)
+ define(, <%rbx>)
+ define(, <%rcx>)
+ define(, <%rdx>)
+@@ -35,8 +35,8 @@ define(, <%r13>)
+ define(, <%r14>)
+ define(, <%r15>)
+ define(, H5)  C Overlap
+-define(, RP)  C Overlap
+-define(, H4) C Overlap
++define(, RP) C Overlap
++
+ 
+ PROLOGUE(nettle_ecc_384_modp)
+   W64_ENTRY(2, 0)
+@@ -48,34 +48,38 @@ PROLOGUE(nettle_ecc_384_modp)
+   push%r14
+   push%r15
+ 
+-  C First get top 2 limbs, which need folding twice
++  C First get top 2 limbs, which need folding twice.
++  C B^10 = B^6 + B^4 + 2^32 (B-1)B^4.
++  C We handle the terms as follow:
+   C
+-  C   H5 H4
+-  C -H5
+-  C  --
+-  C   H0 D4
++  C B^6: Folded immediatly.
+   C
+-  C Then shift right, (H1,H0,D4)  <--  (H0,D4) << 32
+-  C and add
++  C B^4: Delayed, added in in the next folding.
+   C
+-  C H5 H4
+-  C H1 H0
+-  C --
+-  C  C2 H1 H0
+-
+-  mov 80(RP), D4
+-  mov 88(RP), H0
+-  mov D4, H4
+-  mov H0, H5
+-  sub H0, D4
+-  sbb $0, H0
+-
+-  mov D4, T2
+-  mov H0, H1
+-  shl $32, H0
+-  shr $32, T2
++  C 2^32(B-1) B^4: Low half limb delayed until the next
++  C folding. Top 1.5 limbs subtracted and shifter now, resulting
++  C in 2.5 limbs. The low limb saved in D5, high 1.5 limbs added
++  C in.
++
++  mov 80(RP), H4
++  mov 88(RP), H5
++  C Shift right 32 bits, into H1, H0
++  mov H4, H0
++  mov H5, H1
++  mov H5, D5
+   shr $32, H1
+-  or  T2, H0
++  shl $32, D5
++  shr $32, H0
++  or  D5, H0
++
++  C   H1 H0
++  C   -  H1 H0
++  C   
++  C   H1 H0 D5
++  mov H0, D5
++  neg D5
++  sbb H1, H0
++  sbb $0, H1
+ 
+   xor C2, C2
+   add H4, H0
+@@ -114,118 +118,95 @@ PROLOGUE(nettle_ecc_384_modp)
+   adc H3, T5
+   adc $0, C0
+ 
+-  C   H3 H2 H1 H0  0
+-  C - H4 H3 H2 H1 H0
+-  C  ---
+-  C   H3 H2 H1 H0 D0
+-
+-  mov XREG(D4), XREG(D4)
+-  mov H0, D0

Bug#809685: lvm2 on sparc64 = bus error

[John Paul Adrian Glaubitz]

Hi Anatoly!

On 02/09/2016 08:15 PM, Anatoly Pugachev wrote:
> continue from https://bugs.debian.org/809685

You don't have to mention the previous bug report here, your
message is automatically appended to the existing bug report
the moment you CC the bug report's address :).

> if I get lvm2 source from git , compile and try to run , there's no "bus 
> error":
> (...)
> root@deb4g:/mnt/1/lvm2# tools/lvm version
>   LVM version: 2.02.142(2)-git (2016-01-25)
>   Library version: 1.02.116-git (2016-01-25)
>   Driver version:  4.34.0

Interesting. Can you post the version numbers for lvm2 taken from
the Debian package? I have had a look at the lvm2 git repository
and there don't seem be any big changes after 2.02.142 which
could cause this issue. If we can pinpoint the change that fixed
the bug, we could just cherry-pick the necessary patch.

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#811693: GCC 6 and OpenJDK

[Andrew Hughes]

We've just hit the same issue with OpenJDK 8 and the GCC 6 build
now in Fedora rawhide. This error is down to the switch to a default
of C++ 2014. Changing back to the old default allows the build
to succeed.

However, there are other issues with optimisations in the product
builds of OpenJDK on GCC 6, causing an immediate crash.

The following at least gets the build to complete:

https://github.com/gnu-andrew/java-1.8.0-openjdk/commit/b2be771ef60191e6fa24bd7db5b815167ff95f6d

but only armv7hl is successful [0]. On x86_64 and i686 [1,2], the main
build crashes when compiling the simple Java application, TestCryptoLevel
(you can find this in the IcedTea repositories).
The debug build succeeds, so this is something related to optimisations in
GCC 6 which are only enabled in the product build. I've scaled down our
default build flags but to no avail.

+ export 
JAVA_HOME=/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.72-5.b15.fc24.x86_64/openjdk/build/jdk8.build/images/j2sdk-image
+ 
JAVA_HOME=/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.72-5.b15.fc24.x86_64/openjdk/build/jdk8.build/images/j2sdk-image
+ 
/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.72-5.b15.fc24.x86_64/openjdk/build/jdk8.build/images/j2sdk-image/bin/javac
 -d
 . /builddir/build/SOURCES/TestCryptoLevel.java
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7f6b25ed736b, pid=5973, tid=140097488013056
#
# JRE version: OpenJDK Runtime Environment (8.0_72-b15) (build 1.8.0_72-b15)
# Java VM: OpenJDK 64-Bit Server VM (25.72-b15 mixed mode linux-amd64 
compressed oops)
# Problematic frame:
# V  [libjvm.so+0x88636b]  Node::Node(unsigned int)+0x2b
#
# Failed to write core dump. Core dumps have been disabled. To enable core 
dumping, try "ulimit -c unlimited" before starting \
Java again
#
# An error report file with more information is saved as:
# 
/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.72-5.b15.fc24.x86_64/hs_err_pid5973.log
[thread 140097475966720 also had an error]
[thread 140097474914048 also had an error]
[thread 140097473861376 also had an error]
[thread 140097477019392 also had an error]
[error occurred during error reporting , id 0xb]

[0] http://koji.fedoraproject.org/koji/taskinfo?taskID=12911780
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=12916611
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=12916617

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

Bug#814268: nethogs: New upstream release and homepage

[Diederik de Haas]

Package: nethogs
Version: 0.8.0-1+b2
Severity: wishlist
Tags: upstream

Nethogs seems to have a new homepage: https://raboof.github.io/nethogs/
And on that new home, you can also find a 0.8.1 release, which
supposedly fixes bug #808433 (and #811273).

While you're at it, could you also provice the Vcs-* fields?

Cheers,
  Diederik

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

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

Versions of packages nethogs depends on:
ii  libc62.21-7
ii  libgcc1  1:5.3.1-8
ii  libncurses5  6.0+20151024-2
ii  libpcap0.8   1.7.4-2
ii  libstdc++6   5.3.1-8
ii  libtinfo56.0+20151024-2

nethogs recommends no packages.

nethogs suggests no packages.

-- no debconf information

Bug#814267: gosa: annoying warning on each login with debian-edu

[Holger Levsen]

package: gosa
severity: important
version: 2.7.4+reloaded2-1+deb8u1
x-debbugs-cc: debian-...@lists.debian.org

On Montag, 7. September 2015, Wolfgang Schweer wrote:
> One drawback: each time logging into the GOsa² web gui a misleading (and
> annoying) warning pops up stating that the configuration has changed.
> just click it away as Debian Edu isn't concerned. (This is due to gosa
> package version 2.7.4+reloaded2-1+deb8u1 fixing a bug concerning default
> Debian gosa installs.)
> 
> Edit the line containing the config version in /etc/gosa/gosa.conf
> (head of the file) to look like this:
> 
> 
>  will be OK as well.
> 
> The message won't appear any more.

It would be more than nice to have this fixed for our Debian Edu Jessie 
release.


cheers,
Holger




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

Bug#814183: openmpi 1.10.2 is broken on powerpc

[Graham Inggs]

Petsc rebuilt successfully [1] a couple of hours ago on poulenc.d.o. [2].
My previous tests were done on partch.d.o. [3].  Partch has 2GB of RAM
vs Poulenc's 5GB, I don't know if this is significant.


[1] 
https://buildd.debian.org/status/fetch.php?pkg=petsc&arch=powerpc&ver=3.6.2.dfsg1-3%2Bb3&stamp=1455016089
[2] https://db.debian.org/machines.cgi?host=poulenc
[3] https://db.debian.org/machines.cgi?host=partch

Bug#814266: jessie-pu: package pagekite/0.5.6d-3+deb8u1

[Petter Reinholdtsen]

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

The pagekite package in stable is affected by RC bug #790271.  The
problem is a build failure when python-openssl isn't installed (ie
missing build dependency) because the test code in this case take a
non-working code path and break the build.  This patch fixes the
problem:

diff --git a/debian/changelog b/debian/changelog
index bd8aad3..6f623c5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pagekite (0.5.6d-3+deb8u1) stable; urgency=low
+
+  * Add missing build dependency python-openssl to fix test
+failure (Closes: #790271).
+
+ -- Petter Reinholdtsen   Tue, 09 Feb 2016 20:32:34 +0100
+
 pagekite (0.5.6d-3) unstable; urgency=low
 
   * Add debian/watch file to track new upstream versions.
diff --git a/debian/control b/debian/control
index 6707331..ad84d22 100644
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,7 @@ Uploaders: Petter Reinholdtsen 
 Build-Depends:
  debhelper (>= 9)
  , python (>= 2.4)
+ , python-openssl
  , python-support (>= 0.8.4)
  , python-setuptools
  , dh-python

I would like to update the stable version of pagekite to fix this bug.
Are you OK with me uploading a package with this change?

I would also love to replace the non-encrypted Vcs links with encrypted
versions, if that is ok with you:

diff --git a/debian/control b/debian/control
index 6707331..ad84d22 100644
--- a/debian/control
+++ b/debian/control
@@ -13,8 +14,8 @@ Build-Depends:
 X-Python-Version: >= 2.3, << 3.0
 Standards-Version: 3.9.5
 Homepage: https://pagekite.net/
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/pagekite.git
-Vcs-Git: git://anonscm.debian.org/collab-maint/pagekite.git
+Vcs-Browser: https://anonscm.debian.org/gitweb/?p=collab-maint/pagekite.git
+Vcs-Git: https://anonscm.debian.org/git/collab-maint/pagekite.git
 
 Package: pagekite
 Section: net

-- 
Happy hacking
Petter Reinholdtsen

Bug#813125: phpcs upstream issue [was: php-proxy-manager 2.0.0* has a dependency on a new PHP API PackageVersions]

[David Prévot]

Hi Nish,

> On 09.02.2016 [15:17:17 -0400], David Prévot wrote:
>> Le 09/02/2016 15:05, Nish Aravamudan a écrit :
>>
>>> I was finally able to get to this, and I see build failures using that
>>> base (due to phpcs issues):
[…]
>>> I can fix this up on my end by putting in a staged build, but it seems
>>> like something needs to be fixed still?
>>
>> That’s probably caused by a new issue in php-codesniffer 2.5.1, e.g.,
>>
>> https://github.com/squizlabs/PHP_CodeSniffer/issues/876
>
> Did you mean an issue with 2.5.0?

No. I believed 2.5.1 introduced an indent issue, and that
php-proxy-manager was (probably automatically, with phpcbf) fixed to use
the new (broken) phpcs behavior. I just run phpcbf/2.5.0 and now believe
that I was wrong, so I’ll have a closer look at what broke with
phpcs/2.5.1, and may upload the updated packages, or file/document a
proper upstream issue.

Regards

David