Bug#791150: liborigin: diff for NMU version 20080225-2.2

[Gudjon I. Gudjonsson]

Hi Johathan

Sorry for my silence.
> Dear maintainer,
> 
> I've prepared an NMU for liborigin (versioned as 20080225-2.2) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
Thanks a lot for the patch.
Do you use the library? When I packaged it I used it for QtiPlot but since 
then QtiPlot has started using its own version of liborigin and now  it seems 
like no package is depending on it.

I am wondering if it is time to remove the package from Debian.

Regards
Gudjon


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794995: lintian: false positive in non-consecutive-debian-revision

[Joao Eriberto Mota Filho]

Package: lintian
Version: 2.5.35
Severity: normal

Dear Maintainer,

After rename a binary inside a package (in debian/control), I received a
message from lintian saying about non-consecutive-debian-revision.

The package is afflib and the binary libafflib0 was renamed to libafflib0v5.
This package will be uploaded to unstable soon (I think that today).

The lintian messages are:

X: afflib-dbg: non-consecutive-debian-revision
X: libafflib-dev: non-consecutive-debian-revision
X: libafflib0v5: non-consecutive-debian-revision
X: afflib-tools: non-consecutive-debian-revision
X: libafflib0: non-consecutive-debian-revision

My current changelog sequence is:

afflib (3.7.6-5) unstable; urgency=medium
[...]
afflib (3.7.6-4) unstable; urgency=medium

This bug is relative to #789820. (thanks for implement it)

Thanks in advance.

Regards,

Eriberto


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794994: graphite2: FTBFS on !linux archs

[Pino Toscano]

Source: graphite2
Version: 1.3.0-1
Severity: important
Tags: patch

Hi,

graphite2 1.3.0-1 fails to build on kFreeBSD [1][2] and Hurd [3].

The problem is that tests/graphite.py does not have any library item
for these platforms registered in the grfiles dictionary, so the script
will fail with a KeyError exception.

The fix, which is suitable for upstream (so please do forward it),
is to slightly rework the logic for knowing the library name on the
current platform: since there will be far more platforms with the name
libgraphite2.so (Linux, kFreeBSD, Hurd, and any other BSD platform for
sure), then fallback to that name for missing items in the grfiles
dictionary. Hence, that dictionary contains now only platforms where
the library name is not libgraphite2.so, and the linux2 mapping is no
more needed.
Patch attached for this.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=graphite2&arch=kfreebsd-amd64&ver=1.3.0-1&stamp=1439034142
[2] 
https://buildd.debian.org/status/fetch.php?pkg=graphite2&arch=kfreebsd-i386&ver=1.3.0-1&stamp=1439034476
[3] 
https://buildd.debian.org/status/fetch.php?pkg=graphite2&arch=hurd-i386&ver=1.3.0-1&stamp=1439070777

Thanks,
-- 
Pino
--- a/tests/graphite.py
+++ b/tests/graphite.py
@@ -30,9 +30,9 @@ else :
 #basedir = os.path.join(os.path.dirname(__file__), '..', '..', 'build', 'src')
 basedirs = [os.path.join('..', '..'), os.path.join('..'), os.path.join('..','build')]
 
+# systems with a library filename different than libgraphite2.so
 grfiles = {
 'darwin' : 'libgraphite2.dylib',
-'linux2' : 'libgraphite2.so',
 'win32' : 'graphite2.dll',
 'win64' : 'graphite2-x64.dll'
 }
@@ -40,7 +40,10 @@ gr2 = None
 if sys.platform == 'win32' and sys.maxsize > (1 << 32) :
 grfile = grfiles['win64']
 else :
-grfile = grfiles[sys.platform]
+try :
+grfile = grfiles[sys.platform]
+except KeyError :
+grfile = 'libgraphite2.so'
 for b in (os.path.join(b,'src',c) for b in basedirs for c in ('', 'Debug', 'Release', 'DebWithRelInfo', 'MinSizeRel')):
 testfile = os.path.join(b, grfile)
 print "Trying " + testfile

Bug#793939: [RFR] templates://publicfile-installer/{templates}

[Christian PERRIER]

Quoting Justin B Rye (justin.byam@gmail.com):

> But why does it need a special script to install a package?  (Goes and
> looks...)  Yipe!  It just checks I'm root and then runs
> 
>   dpkg -i /tmp/publicfile-installer/publicfile*_*.deb
> 
> Does the build really leave its output in a predictable location in a
> world-writable directory?  (Checks)  Yes, so if my evil kid brother
> has created a /tmp/publicfile-installer/publicfile_0.52-0_amd64.deb,
> the build-script will happily dump its .deb alongside it.  Then when I
> run "sudo install-publicfile" it'll install the bogus package first,
> executing its install-scripts as root.

That seems correct and probably deserves another bug report, in my
opinion. Thanks for pointing this, Justin...



signature.asc
Description: Digital signature

Bug#765567: xsltproc: bus error on some architectures

[Douglas Bagnall]

See later comments in 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1471029

The depth of recursion is not excessive, but the kernel is laying out
the memory in a way that squishes the stack into the heap.

This (from memory of tests I don't have right now) was fixed between 4.0 and 
4.1.

Douglas

On Wed, 4 Jun 2014 22:27:03 +0200 Ivo De Decker  wrote:
> package: xsltproc
> version: 1.1.28-2
> severity: important
> 
> Hi,
> 
> On some architectures (like i386), xsltproc fails with Bus error when running
> /usr/bin/xsltproc --nonet -o smb.conf.5 man.xsl smb.conf.5.tmp.xml
> with the attached version of man.xsl and smb.conf.5.tmp.xml.
> 
> This is done during the samba build. It fails on armel, armhf and i386, but
> doesn't fail on other architectures.
> 
> fail:
> 
> https://buildd.debian.org/status/fetch.php?pkg=samba&arch=armel&ver=2%3A4.1.7%2Bdfsg-2%2Bb1&stamp=1401742626
> https://buildd.debian.org/status/fetch.php?pkg=samba&arch=armhf&ver=2%3A4.1.7%2Bdfsg-2%2Bb1&stamp=1401738640
> https://buildd.debian.org/status/fetch.php?pkg=samba&arch=i386&ver=2%3A4.1.7%2Bdfsg-2%2Bb1&stamp=1401787651
> 
> ok:
> 
> https://buildd.debian.org/status/fetch.php?pkg=samba&arch=amd64&ver=2%3A4.1.7%2Bdfsg-2%2Bb1&stamp=1401735339
> 
> The failure happened for a binnmu. The previous build went fine:
> 
> https://buildd.debian.org/status/fetch.php?pkg=samba&arch=i386&ver=2%3A4.1.7%2Bdfsg-2&stamp=1397997714
> 
> I wasn't able to find a clear change between these builds which could explain
> why the failure happens now but didn't in the past (but there could be a
> change I overlooked).
> 
> 
> Cheers,
> 
> Ivo
> 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794993: libsnappy1: library transition may be needed when GCC 5 is the default

[GCS]

Package: src:snappy
Version: 1.1.3-1
Severity: serious
Tags: sid stretch patch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

Control: block 794931 with -1

The short note.
Background [1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
and dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

It seems Matthias missed this C++ library transition. Maybe due to the
old style packaging and that this package doesn't provide a symbols
file. But please see the attached symbols change when built with
gcc-4.9 and gcc-5.2 , thus __cxx11 symbols show up.
At the moment it breaks building of mongodb, but may break other
packages as well.

I propose the attached NMU if you don't have time for now - or I can
help update and maintain the packaging as co-maintainer if you want.

Regards,
Laszlo/GCS
[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
--- debian/libsnappy1.symbols   2015-08-08 23:54:52.415075073 +
+++ debian/libsnappy1/DEBIAN/symbols2015-08-08 23:59:25.046660564 +
@@ -1,5 +1,5 @@
 libsnappy.so.1 libsnappy1 #MINVER#
- _ZN6snappy10UncompressEPKcmPSs@Base 1.1.3
+ 
_ZN6snappy10UncompressEPKcmPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 1.1.3
  _ZN6snappy10UncompressEPNS_6SourceEPNS_4SinkE@Base 1.1.3
  _ZN6snappy11RawCompressEPKcmPcPm@Base 1.1.3
  _ZN6snappy13RawUncompressEPKcmPc@Base 1.1.3
@@ -38,8 +38,8 @@
  _ZN6snappy6SourceD0Ev@Base 1.1.3
  _ZN6snappy6SourceD1Ev@Base 1.1.3
  _ZN6snappy6SourceD2Ev@Base 1.1.3
- _ZN6snappy6Varint8Append32EPSsj@Base 1.1.3
- _ZN6snappy8CompressEPKcmPSs@Base 1.1.3
+ 
_ZN6snappy6Varint8Append32EPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEj@Base
 1.1.3
+ 
_ZN6snappy8CompressEPKcmPNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 1.1.3
  _ZN6snappy8CompressEPNS_6SourceEPNS_4SinkE@Base 1.1.3
  _ZN6snappy8internal13WorkingMemory12GetHashTableEmPi@Base 1.1.3
  _ZN6snappy8internal16CompressFragmentEPKcmPcPti@Base 1.1.3
diff -u snappy-1.1.3/debian/changelog snappy-1.1.3/debian/changelog
--- snappy-1.1.3/debian/changelog
+++ snappy-1.1.3/debian/changelog
@@ -1,3 +1,10 @@
+snappy (1.1.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename library to libsnappy1v5 for GCC 5 transition.
+
+ -- Laszlo Boszormenyi (GCS)   Sun, 09 Aug 2015 07:28:37 +0200
+
 snappy (1.1.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -u snappy-1.1.3/debian/control snappy-1.1.3/debian/control
--- snappy-1.1.3/debian/control
+++ snappy-1.1.3/debian/control
@@ -10,7 +10,7 @@
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: libsnappy1 (= ${binary:Version}), ${misc:Depends}
+Depends: libsnappy1v5 (= ${binary:Version}), ${misc:Depends}
 Description: fast compression/decompression library (development files)
  Snappy is a compression/decompression library. It does not aim for
  maximum compression, or compatibility with any other compression  
@@ -26,12 +26,14 @@
  This package contains the development files required to build programs
  against Snappy.
 
-Package: libsnappy1
+Package: libsnappy1v5
 Section: libs
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Conflicts: libsnappy1
+Replaces: libsnappy1
 Description: fast compression/decompression library
  Snappy is a compression/decompression library. It does not aim for
  maximum compression, or compatibility with any other compression  
reverted:
--- snappy-1.1.3/debian/libsnappy1.dirs
+++ snappy-1.1.3.orig/debian/libsnappy1.dirs
@@ -1 +0,0 @@
-usr/lib
reverted:
--- snappy-1.1.3/debian/libsnappy1.install
+++ snappy-1.1.3.orig/debian/libsnappy1.install
@@ -1 +0,0 @@
-usr/lib/*/lib*.so.*
only in patch2:
unchanged:
--- snappy-1.1.3.orig/debian/libsnappy1v5.dirs
+++ snappy-1.1.3/debian/libsnappy1v5.dirs
@@ -0,0 +1 @@
+usr/lib
only in patch2:
unchanged:
--- snappy-1.1.3.orig/debian/libsnappy1v5.install
+++ snappy-1.1.3/debian/libsnappy1v5.install
@@ -0,0 +1 @@
+usr/lib/*/lib*.so.*

Bug#794835: assimp: FTBFS with g++-5

[Michael Gilbert]

control: tag -1 patch

Hi,

Here is a trivial patch.  Updating the symbols file is a better
solution since neither of the reverse dependencies rely on the changed
symbols.  I've tested that doomsday builds fine after this patch.
mrpt does fail to build with g++ 5 (I've submitted bug #794990 about
that), which is due to a different problem, not the symbol change from
this package.

Best wishes,
Mike
diff -Nru assimp-3.0~dfsg/debian/changelog assimp-3.0~dfsg/debian/changelog
--- assimp-3.0~dfsg/debian/changelog	2015-04-27 20:28:02.0 +
+++ assimp-3.0~dfsg/debian/changelog	2015-08-09 05:12:07.0 +
@@ -1,3 +1,11 @@
+assimp (3.0~dfsg-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with g++ 5 and update symbols for the libstdc++ ABI change
+(closes: #794835).
+
+ -- Michael Gilbert   Sat, 08 Aug 2015 20:57:10 +
+
 assimp (3.0~dfsg-4) unstable; urgency=medium
 
   * Export "ai*" in C++-scope (Closes: #775890)
diff -Nru assimp-3.0~dfsg/debian/control assimp-3.0~dfsg/debian/control
--- assimp-3.0~dfsg/debian/control	2015-04-27 20:26:56.0 +
+++ assimp-3.0~dfsg/debian/control	2015-08-09 05:04:05.0 +
@@ -11,6 +11,7 @@
  python,
  python-dev (>= 2.3.5-7),
  dpkg-dev (>= 1.15.6),
+ g++ (>=4:5.2.1-1),
  pkg-kde-tools,
  cmake,
  libboost-dev,
diff -Nru assimp-3.0~dfsg/debian/libassimp3.symbols assimp-3.0~dfsg/debian/libassimp3.symbols
--- assimp-3.0~dfsg/debian/libassimp3.symbols	2015-01-22 23:51:40.0 +
+++ assimp-3.0~dfsg/debian/libassimp3.symbols	2015-08-09 00:42:07.0 +
@@ -23,7 +23,6 @@
  (c++)"Assimp::DefaultLogger::m_pLogger@Base" 2.0.863
  (c++)"Assimp::DefaultLogger::DefaultLogger(Assimp::Logger::LogSeverity)@Base" 2.0.863
  (c++)"Assimp::DefaultLogger::~DefaultLogger()@Base" 2.0.863
- (c++|optional)"Assimp::ProgressHandler::~ProgressHandler()@Base" 2.0.863
  (c++)"Assimp::Intern::AllocateFromAssimpHeap::operator delete[](void*)@Base" 2.0.863
  (c++)"Assimp::Intern::AllocateFromAssimpHeap::operator delete(void*)@Base" 2.0.863
  (c++|subst)"Assimp::Intern::AllocateFromAssimpHeap::operator new[]({c++:size_t})@Base" 2.0.863
@@ -34,7 +33,6 @@
  (c++)"Assimp::Logger::warn(char const*)@Base" 3.0~
  (c++)"Assimp::Logger::debug(char const*)@Base" 3.0~
  (c++)"Assimp::Logger::error(char const*)@Base" 3.0~
- (c++|optional)"Assimp::Logger::~Logger()@Base" 2.0.863
  (c++)"Assimp::Exporter::ExportToBlob(aiScene const*, char const*, unsigned int)@Base" 3.0~
  (c++)"Assimp::Exporter::SetIOHandler(Assimp::IOSystem*)@Base" 3.0~
  (c++)"Assimp::Exporter::RegisterExporter(Assimp::Exporter::ExportFormatEntry const&)@Base" 3.0~
@@ -43,8 +41,6 @@
  (c++)"Assimp::Exporter::FreeBlob()@Base" 3.0~
  (c++)"Assimp::Exporter::Exporter()@Base" 3.0~
  (c++)"Assimp::Exporter::~Exporter()@Base" 3.0~
- (c++|optional)"Assimp::IOStream::~IOStream()@Base" 2.0.863
- (c++|optional)"Assimp::IOSystem::~IOSystem()@Base" 2.0.863
  (c++)"Assimp::Importer::SetIOHandler(Assimp::IOSystem*)@Base" 2.0.863
  (c++)"Assimp::Importer::RegisterLoader(Assimp::BaseImporter*)@Base" 2.0.863
  (c++)"Assimp::Importer::RegisterPPStep(Assimp::BaseProcess*)@Base" 2.0.863
@@ -53,7 +49,7 @@
  (c++)"Assimp::Importer::SetPropertyFloat(char const*, float, bool*)@Base" 2.0.863
  (c++)"Assimp::Importer::UnregisterLoader(Assimp::BaseImporter*)@Base" 2.0.863
  (c++)"Assimp::Importer::UnregisterPPStep(Assimp::BaseProcess*)@Base" 2.0.863
- (c++)"Assimp::Importer::SetPropertyString(char const*, std::basic_string, std::allocator > const&, bool*)@Base" 2.0.863
+ (c++)"Assimp::Importer::SetPropertyString(char const*, std::__cxx11::basic_string, std::allocator > const&, bool*)@Base" 3.0~dfsg-4.1 
  (c++|subst)"Assimp::Importer::ReadFileFromMemory(void const*, {c++:size_t}, unsigned int, char const*)@Base" 2.0.863
  (c++)"Assimp::Importer::SetProgressHandler(Assimp::ProgressHandler*)@Base" 2.0.863
  (c++)"Assimp::Importer::SetPropertyInteger(char const*, int, bool*)@Base" 2.0.863
@@ -64,7 +60,6 @@
  (c++)"Assimp::Importer::Importer()@Base" 2.0.863
  (c++)"Assimp::Importer::~Importer()@Base" 2.0.863
  (c++)"Assimp::LogStream::createDefaultStream(aiDefaultLogStream, char const*, Assimp::IOSystem*)@Base" 2.0.863
- (c++|optional)"Assimp::LogStream::~LogStream()@Base" 2.0.863
  (c++)"Assimp::Exporter::GetIOHandler() const@Base" 3.0~
  (c++)"Assimp::Exporter::GetErrorString() const@Base" 3.0~
  (c++)"Assimp::Exporter::GetOrphanedBlob() const@Base" 3.0~
@@ -83,7 +78,7 @@
  (c++)"Assimp::Importer::GetImporterCount() const@Base" 3.0~
  (c++)"Assimp::Importer::GetImporterIndex(char const*) const@Base" 3.0~
  (c++)"Assimp::Importer::GetPropertyFloat(char const*, float) const@Base" 2.0.863
- (c++)"Assimp::Importer::GetPropertyString(char const*, std::basic_string, std::allocator > const&) const@Base" 2.0.863
+ (c++)"Assimp::Importer::GetPropertyString(char const*, std::__cxx11::basic_string, std::allocator > const&) const@Base" 3.0~dfsg-4.1
  (c++)"Assimp::Importer::GetProgressHandler() const@Base" 2.0.86

Bug#794992: RM: neutron-vpnaas/2015.1.0-2

[Scott Kitterman]

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

The python-sqlalchemy transition was all set to finish today when the
maintainer (zigo) uploaded neutron-vpnaas and so set the whole thing back
by five days (at least, who knows what else he uploads in the mean time).

If we can just remove this one package from testing, then sqlalchemy and the
rest of the rdepends will migrate.  That'll get rid of the risk of something
else getting uploaded and delaying it further.  In the meantime, this
shouldn't be gone from testing long unless it's otherwise buggy.

Scott K


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794991: libsixel: upstream bug fixes

[Tatsuya Kinoshita]

Package: libsixel
Version: 1.4.2-1

New upstream v1.4.13 is available which includes many bug fixes.
Please package it.

Thanks,
--
Tatsuya Kinoshita


pgp3aNSQJqvAY.pgp
Description: PGP signature

Bug#794990: mrpt: ftbfs with new libstdc++ ABI

[Michael Gilbert]

Source: mrpt
Version: 1:1.2.2-1.1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

This package fails to build with the new libstdc++ ABI (with updated
libassimp3, #794835).

The error has to do with undefined references to c++11 symbols:

../../lib/libmrpt-vision.so.1.3.1: undefined reference to
`cv::Exception::Exception(int, std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, int)'
../../lib/libmrpt-hwdrivers.so.1.3.1: undefined reference to
`cv::FileStorage::FileStorage(std::__cxx11::basic_string, std::allocator > const&, int,
std::__cxx11::basic_string,
std::allocator > const&)'
../../lib/libmrpt-vision.so.1.3.1: undefined reference to
`cv::Algorithm::_create(std::__cxx11::basic_string, std::allocator > const&)'
collect2: error: ld returned 1 exit status
apps/camera-calib/CMakeFiles/camera-calib.dir/build.make:215: recipe
for target 'bin/camera-calib' failed

Forcing the build to use g++-4.9 or -std=c++98 doesn't help.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794989: nmu: xsdcxx_4.0.0-1

[Diane Trout]

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

nmu xsdcxx_4.0.0-1 . ALL . unstable . -m "Rebuild for new libstdc++6"

This is happening because of the libstdc++6 transition.

Technically this is only happening because libstdc++6 declared a breaks
xsdcxx-4.0.0-1 because of https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=793289

xsd has no library for the change in C++ API to cause trouble with so the g++
bug shouldn't be relevant. I was able to download version in 4.0.0-1, unpacked
it manually, and was still able to run the application. For further testing I
built my own test binNMU and used it to generate code for libkolabxml

Diane

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

Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794688: marked as pending

[Guillem Jover]

Hi!

On Sat, 2015-08-08 at 10:13:50 +0200, Sven Joachim wrote:
> On 2015-08-06 04:16 +0200, Guillem Jover wrote:
> > Control: tag 794688 pending
> >
> > Bug #794688 reported by you has been fixed in the Git repository. You can
> > see the changelog below, and you can check the diff of the fix at:
> >
> > https://anonscm.debian.org/cgit/dpkg/dpkg.git/diff/?id=629f067
> 
> The help text could still use a little improvement, I think.  Since the
> --predep-package prints a single package, using plural is not really
> correct, I think.  How about this change?

Actually, given #539133, I think I'll change the man page instead to
state that the option might print more than one package, for the time
the code is fixed, so that there are no surprises for its users.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#783478: texi2html: [PATCH] Please make the build reproducible

[Juan Picca]

You are right, Johannes.
I changed the flag name without notice it.
With the change done by Maria (#783475) now we can remove the
--build-date flag (i hope)
Also, now the reproducible build fails due the date in copied files,
(dist_images_DATA in Makefile.am, etc).
Please, give me some days to figure it and fix it.
Greetings,
JMPC

On Sat, Aug 8, 2015 at 3:41 AM, Johannes Schauer  wrote:
> Hi Juan,
>
> On Mon, 27 Apr 2015 08:09:03 -0300 Juan Picca  wrote:
>> The attached patch removes extra timestamps from the build system and
>> ensure a stable file order when creating the source archive. Once
>> applied, texi2html can be built reproducibly in our current experimental
>> framework.
>
> thanks for your patch!
>
> I'm considering to NMU this package together with this patch of yours but am
> having some questions about your patch before.
>
>  1. In your patch you remove ./mdate-sh and ./doc/mdate-sh. This removal makes
> your patch quite big. Why do those files have to be removed and cannot 
> stay
> to minimize the size of the patch?
>
>  2. you call texi2html.pl with --use-date but in #783475 you renamed the
> command line option to --build-date
>
>  3. the updated patch in #783475 allows texi2html to use $SOURCE_DATE_EPOCH. 
> So
> maybe instead of patching upstreams ./doc/Makefile.am and
> ./doc/Makefile.in, you should instead not patch these files but just 
> export
> $SOURCE_DATE_EPOCH in debian/rules
>
>  4. in doc/Makefile.in you are moving the line calling mdate-sh around. Why?
>
>  5. you are patching ./configure.ac in addition to ./configure. But either
> ./configure does get regenerated from ./configure.ac (and in this case you
> do not need to patch ./configure) or ./configure does not get regenerated
> from ./configure.ac (and in this case you do not need to patch
> ./configure.ac). I'd prefer if configure was regenerated at build time.
>
> Thanks again for your contribution!
>
> cheers, josch


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794881: My mistake

[Celejar]

Hi,

Really sorry for the noise - ERRNOCOFFEE - I had a typo in the key file
names. Once again, sorry.

Celejar


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794988: node-htmlparser2: throws "Cannot find module 'domhandler'"

[Jason Woofenden]

Package: node-htmlparser2
Version: 3.7.3-1
Severity: important

Dear Maintainer,

I tried the example in the htmlparser2 readme, and it throws an
error while trying to load the module:

$ cat test.js
var htmlparser = require("htmlparser2");
var parser = new htmlparser.Parser({
onopentag: function(name, attribs){
if(name === "script" && attribs.type === "text/javascript"){
console.log("JS! Hooray!");
}
},
ontext: function(text){
console.log("-->", text);
},
onclosetag: function(tagname){
if(tagname === "script"){
console.log("That's it?!");
}
}
}, {decodeEntities: true});
parser.write("Xyz var foo = '<>';");
parser.end();


$ node test.js

module.js:340
throw err;
  ^
Error: Cannot find module 'domhandler'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Module.require (module.js:364:17)
at require (module.js:380:17)
at Object. (/usr/lib/nodejs/htmlparser2/lib/index.js:2:18)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.require (module.js:364:17)
zsh: exit 8 node test.js


Thanks.

-- Jason


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

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

Versions of packages node-htmlparser2 depends on:
ii  node-entities  1.1.1-1
ii  nodejs 0.10.38~dfsg-1

node-htmlparser2 recommends no packages.

node-htmlparser2 suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#780177: Still occurs with 24.5+1-1

[Adam Porter]

This problem still occurs with the 24.5+1-1 package currently in
unstable.  Trying to build it on Ubuntu Trusty, I get:

debian/patch-to-news: line 9:
0001-Prefer-usr-share-info-emacs-24-over-usr-share-info.patch: No such
file or directory
debian/patch-to-news: line 9:
0002-Run-debian-startup-and-set-debian-emacs-flavor.patch: No such
file or directory
debian/patch-to-news: line 9:
0003-Remove-files-that-appear-to-be-incompatible-with-the.patch: No
such file or directory
debian/patch-to-news: line 9:
0004-Adjust-documentation-references-for-Debian.patch: No such file or
directory
debian/patch-to-news: line 9:
0005-Modify-the-output-of-version-to-indicate-Debian-modi.patch: No
such file or directory
debian/patch-to-news: line 9:
0006-Look-for-NEWS-in-order-to-find-etc-rather-than-GNU.patch: No such
file or directory
debian/patch-to-news: line 9:
0007-Don-t-try-to-build-src-macuvs.h-via-IVD_Sequences.tx.patch: No
such file or directory
make[1]: *** [debian/emacs24-common.README.Debian] Error 1
make[1]: Leaving directory `/home/me/tmp/emacs/emacs24-24.5+1'
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794987: mercurial-git: failed to import extension hgext.git: No module named ignore

[James McCoy]

Package: mercurial-git
Version: 0.8.1-2
Severity: important

In a repository using hg-git:

$ hg status
*** failed to import extension hgext.git: No module named ignore
** unknown exception encountered, please report by visiting
** http://mercurial.selenic.com/wiki/BugTracker
** Python 2.7.10 (default, Jul  1 2015, 10:54:53) [GCC 4.9.2]
** Mercurial Distributed SCM (version 3.5)
** Extensions loaded: color, graphlog, hgk, strip, mq, pager, purge, record, 
rebase, histedit, gpg
Traceback (most recent call last):
  File "/usr/bin/hg", line 43, in 
mercurial.dispatch.run()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 30, in run
sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 92, in 
dispatch
ret = _runcatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 163, in 
_runcatch
return _dispatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 862, in 
_dispatch
repo = hg.repository(ui, path=path)
  File "/usr/lib/python2.7/dist-packages/mercurial/hg.py", line 136, in 
repository
peer = _peerorrepo(ui, path, create)
  File "/usr/lib/python2.7/dist-packages/mercurial/hg.py", line 123, in 
_peerorrepo
obj = _peerlookup(path).instance(ui, path, create)
  File "/usr/lib/python2.7/dist-packages/mercurial/hg.py", line 93, in 
_peerlookup
return thing(path)
  File "/usr/lib/python2.7/dist-packages/hgext/git/__init__.py", line 84, in 
_local
p = urlcls(path).localpath()
TypeError: 'NoneType' object is not callable

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

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

Versions of packages mercurial-git depends on:
ii  mercurial   3.5-1
ii  python-dulwich  0.10.1-1
pn  python:any  

mercurial-git recommends no packages.

mercurial-git suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#717778: checkinstall: mkdir -p fails (fstrans broken again?)

[nerdopolis]

Hi. 

I also confim I get this error. It seems to happen in both Debian Testing, and 
Ubuntu Vivid chroots on Kernel 3.19

I get these errors


libtool: install: /usr/bin/install -c .libs/libwayland-server.a 
/opt/lib/i386-linux-gnu/libwayland-server.a
libtool: install: chmod 644 /opt/lib/i386-linux-gnu/libwayland-server.a
libtool: install: ranlib /opt/lib/i386-linux-gnu/libwayland-server.a
ranlib: could not create temporary file whilst writing archive: No more 
archived files
Makefile:1138: recipe for target 'install-libLTLIBRARIES' failed
make[3]: *** [install-libLTLIBRARIES] Error 1

Thanks


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794986: Does not scale up fonts on a high-DPI display (Xft.dpi)

[Josh Triplett]

Package: stellarium
Version: 0.13.3-2
Severity: normal

On a high-DPI display, with Xft.dpi set to a large value, stellarium
does not scale up the fonts in its rendering window to match, making
them unreadably small.  Please scale these fonts up based on Xft.dpi.

Thanks,
Josh Triplett

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

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

Versions of packages stellarium depends on:
ii  libc6 2.19-19
ii  libgcc1   1:5.1.1-14
ii  libgl1-mesa-glx [libgl1]  10.6.3-1
ii  libqt5concurrent5 5.4.2+dfsg-8
ii  libqt5core5a  5.4.2+dfsg-5
ii  libqt5declarative55.4.2-2
ii  libqt5gui55.4.2+dfsg-8
ii  libqt5network55.4.2+dfsg-8
ii  libqt5opengl5 5.4.2+dfsg-8
ii  libqt5script5 5.4.2+dfsg-4
ii  libqt5widgets55.4.2+dfsg-8
ii  libstdc++65.1.1-14
ii  qtquick1-qml-plugins  5.4.2-2
ii  stellarium-data   0.13.3-2
ii  zlib1g1:1.2.8.dfsg-2+b1

stellarium recommends no packages.

stellarium suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794985: Fonts not scaled up on high-DPI display

[Josh Triplett]

Source: celestia
Severity: normal

On a high-DPI display, with Xft.dpi set to a large value, the fonts used
in the rendering window don't scale up, making them unreadably small.
Please scale the rendering fonts up proportionally to the DPI.

Thanks,
Josh Triplett

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

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794984: On high-DPI display, does not scale up all fonts

[Josh Triplett]

Package: gitk
Version: 1:2.5.0+next.20150727-1
Severity: normal

On a high-DPI display, with Xft.dpi set to a large value, gitk scales up
some but not all of its fonts.  For instance, the menus and content
fonts seem to be scaled up, but the UI font for "Find ... commit
containing" and the fonts in the preferences dialog remain small.  gitk
should consistently scale up all fonts by the appropriate amount.

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

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

Versions of packages gitk depends on:
ii  git  1:2.5.0+next.20150727-1
ii  tk   8.6.0+8

gitk recommends no packages.

Versions of packages gitk suggests:
pn  git-doc  

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794983: vlc does weird things with the .lock file

[sacrificial-spam-address]

Package: vlc
Version: 2.2.1-2+b2
Architecture: i386
Severity: minor

Somehow (it may have been a transient error caused by C++ ABI upgrades),
I ended up with:

$ ls ~/.config/vlc/
vlc-qt-interface.conf
vlc-qt-interface.conf.lock
vlc-qt-interface.conf.lock.rmlock
vlc-qt-interface.conf.lock.rmlock.rmlock
vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock
vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock
vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock
vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock
vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock
...
vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock

and ended up with vlc stuck looping retrying

open("/home/xxx/.config/vlc/vlc-qt-interface.conf.lock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock.rmlock",
 O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE|O_CLOEXEC, 0644) = -1 ENAMETOOLONG (File 
name too long)

(Note that at no point did I have more than two copies of vlc running.)


Once I deleted all those files, things started working.  But shouldn't it be
able to figure out that ENAMETOOLONG won't be solved by retrying?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794937: Applications crash with phonon-backend-vlc

[Lisandro Damián Nicanor Pérez Meyer]

tag 794937 moreinfo
thanks

Hi Michael! I have just uploaded a new version, can you check it works for 
you? (and yes, you might need to wait for the gcc5 transition to be in a more 
advanced state :-/ )

Kinds regards, Lisandro.

-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#732723: cegui-mk2: Please upgrade OGRE dependency to 1.9 when upstream ready

[Corey Hickey]

Hi,

This package is apparently not installable on sid now.

1. libcegui-mk2-0.7.6 requires libogre-1.8.0
2. libstdc++6 "Breaks" libogre-1.8.0 <= 1.8.0+dfsg1-7+b1

Updating libogre-1.8.0 is apparently a wontfix:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791222

Can you please prepare a new upload as mentioned?

Thanks,
Corey


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794967: zsh: please enhance /etc/zshrc

[Carsten Hey]

* Frank Terbeck [2015-08-08 23:46 +0200]:
> Carsten Hey wrote:
> [...]
>
> >- Maybe F1 could invoke run-help?  But then the output of run-help
> >  w/o arguments should be more useful for new users.
> >
> >- Red Hat maps or mapped space to magic-space, I think Debian should
> >  _not_ do this, but initially I thought that this would be a good
> >  idea.
>
> Again, this fits into the recommended setup file

Btw., we agree on this part, "Space -> magic-space" and "F1 -> run-help"
are possible candidates for a recommended setup file, but not for
a global zshrc (I should have waited a few minutes after having the idea
to map F1, instead of immediately sending the bug report).


Carsten


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794982: alarm-clock: doesn't play any sound while "Play sound during event" is ticked

[Vincent Lefevre]

Package: alarm-clock
Version: 1.2.5-1.2
Severity: important

"Play sound during event" is ticked (this is the default), and when
there's an alarm, a "Stop the sound" button appears, but no sound
is played (ogg123 shows that the sound is working on the machine).

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=POSIX, 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 alarm-clock depends on:
ii  libatk1.0-0 2.16.0-2
ii  libc6   2.19-19
ii  libcairo2   1.14.2-2
ii  libfontconfig1  2.11.0-6.3
ii  libfreetype62.5.2-4
ii  libgdk-pixbuf2.0-0  2.31.5-1
ii  libglib2.0-02.44.1-1.1
ii  libgstreamer0.10-0  0.10.36-1.5
ii  libgtk2.0-0 2.24.28-1
ii  libnotify4  0.7.6-2
ii  libpango1.0-0   1.36.8-3
ii  libxml2 2.9.1+dfsg1-5

alarm-clock recommends no packages.

alarm-clock suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794967: zsh: please enhance /etc/zshrc

[Carsten Hey]

* Frank Terbeck [2015-08-08 23:46 +0200]:
> Carsten Hey wrote:
> [...]
> >  * Please add some additional keybindings, at least for the emacs keymap:
> >
> >- bind PageUp "${terminfo[kpp]}" to history-search-backward
> >- bind PageDown "${terminfo[knp]}" to history-search-forward
> >- bind BackTabKey "${terminfo[kcbt]}" to reverse-menu-complete
>
> I firmly believe, that a vendor's *global* setup file should be as
> minimal as possible, which is why I really don't want to add anything
> that's more than making the zsh defaults behave more robustly across
> multiple terminals or deal with stuff specific to Debian.

It looks like you changed your opinion since you wrote
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622933#10

> >  In terminfo(5), the capname cbt is described as "back tab (P)"
> >  and kcbt is described as "back-tab key", therefore the suggested
> >  'BackTabKey' instead of 'BackTab' - even though grml confuses
> >  people that know terminfo(5) by using 'BackTab' as name.
>
> By that logic, kpp would need to be mapped to "PreviousPageKey". I think
> the current naming is fine.

No, there is no such name collusion with kpp.  What would be the name of
cbt if kcbt is BackTab?  Actually, the name does not matter ;)

> >  ...
> >
> >- Red Hat maps or mapped space to magic-space, I think Debian should
> >  _not_ do this, but initially I thought that this would be a good
> >  idea.
>
> Again, this fits into the recommended setup file

The difference is that Red Hat destroys or destroyed existing mappings
with binding Space to magic-space.  Binding BackTab, which is unbound by
default, does not annoy or harm anybody.  The same applies to PageUp and
PageDown.  Nothing you wrote changed my opinion that BackTab, PageUp and
PageDown should by bound to something useful by default.

> >  * $key should be unset unless there is a reason for not doing so.
>
> The reason I left it set, is because its layout matches the $key
> dictionary, that zsh's "zkbd" function produces and can be used as a
> drop-in replacement. I still think that's a reasonable idea, even though
> it slightly violates the "A vendor's global setup needs to be minimal"
> rule.

If you can imagine a real world use case and nobody complains, it's fine :)

> >  * (( ${+aliases[run-help]} )) requires the zsh/parameter module.  If,
> >in rare cases, possibly involving zsh-static, there is a chance that
> >this module is not loaded successfully, you should consider doing
> >this instead to remove the alias w/o error message:
> >
> >  alias run-help=
> >  unalias run-help
>
> That's a good point. I think we can do it like this:
>
> unhash -a -m 'run-help' || true
>
> -a removes alias from its hash table. -m uses the argument as a pattern.
> Since there's no character that's significant to pattern matching, this
> will work. This way, there is no error message. The '|| true' is to make
> sure the setup file exits with successful status.

A sole : as last line instead of appending '|| true' to the last command
would make this intension more clear.

> We could also just do this:
>
> unalias run-help 2>/dev/null || true
>
> …if that's more straight-forward to read.

If there is a reason to write something in a way that is less
straight-forward to read, one could add a comment that explains the
code.

debootstrap --foreign ... enters a chroot without /dev/null, there might
be other rare but valid cases where /dev/null is not available.
Normally this is not a problem (everybody does this, POSIX allows it,
...), but I'd like to avoid such things in default shell rc files and
especially in global shell rc files to avoid issues in rare corner
cases.


Carsten


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#787892: realmd: Suffers from bug #735255 - missing /var/lib/samba/private

[Michael Biebl]

Control: reassign -1 samba-common-bin
Control: found -1 2:4.1.17+dfsg-2

On Sat, 06 Jun 2015 14:55:21 +1000 Jason Lingohr  wrote:
> Package: realmd
> Version: 0.15.1-1+b2
> Severity: important
> 
> Dear Maintainer,
> 
> Hi, fresh install of jessie.  Installed realmd and get:
> 
> root@debian8:~# realm join --verbose --user=someone the.domain
>  * Resolving: _ldap._tcp.the.domain
>  * Performing LDAP DSE lookup on: 1.1.1.1
>  * Performing LDAP DSE lookup on: 1.1.1.2
>  * Successfully discovered: the.domain
> Password for someone:
>  * Unconditionally checking packages
>  * Resolving required packages
>  * Installing necessary packages: sssd-tools, libpam-sss, libnss-sss, sssd, 
> samba-common-bin
>  * LANG=C LOGNAME=root /usr/bin/net -s 
> /var/cache/realmd/realmd-smb-conf.Z2P0ZX -U someone ads join the.domain
> Enter someone's password:Failed to open /var/lib/samba/private/secrets.tdb
> 
> Failed to join domain: Unable to open secrets database
>  ! Joining the domain the.domain failed
> realm: Couldn't join realm: Joining the domain the.domain failed
> 
> This is resolved by mkdir'ing the above before doing the above.
> 
> This bug also leaves sssd in a strange state, whereby I had to leave the 
> domain
> and rejoin before things worked.
> 
> Versions of packages that realmd installed:
> 
> ii  libnss-sss:amd64  1.11.7-3
> ii  libpam-sss:amd64  1.11.7-3
> ii  samba-common-bin  2:4.1.17+dfsg-2

/usr/bin/net is shipped by samba-common-bin, so this looks like a bug in
this package. Thus reassigning.

Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#794981: libnet-xmpp-perl: Please recommend/suggest libdigest-hmac-perl

[Christoph Biedl]

Package: libnet-xmpp-perl
Version: 1.02-4
Severity: wishlist

Dear Maintainer,

after spending literally hours trying to provide a reproducer for
#794963 but all I got was the dreaded ...

| No SASL mechanism found
|  at /usr/share/perl5/Authen/SASL.pm line 77.
|  at /usr/share/perl5/XML/Stream.pm line 2155.

... finally https://bugs.archlinux.org/task/30337 gave the right hint:
Appearently the libdigest-hmac-perl package is needed by Net::XMPP, at
least in some scenarios when running against the Prosody XMPP server.
So please depend, recommend or just suggest that package so other
people will save time.

Christoph

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

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



signature.asc
Description: Digital signature

Bug#794977: dselect: no access methods are available

[Guillem Jover]

Hi!

On Sat, 2015-08-08 at 23:52:38 +0200, Daniel Leidert wrote:
> Package: dselect
> Version: 1.18.2
> Severity: normal

> Since a short time (not sure, since when), dselect refuses to work with
> the error mentioned in the subject. Even if I start it to choose an
> access method, this error is given.

> A downgrade of dpkg to version 1.18.1 does not help.

From my testing it should. This seems to be caused by the
multiarchification of the libdpkg-dev package. I'll fix it for a quick
1.18.3 release.

Thanks,
Guillem


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794964: gettext: must redo libstdc++ ABI transition because not done right

[Thorsten Glaser]

Santiago Vila dixit:

>The library was included in gettext-base but it was splitted to its
>own package in version 0.18.1.1-6 and a compatibility dependency was
>added.

Ah.

>We could drop this dependency for stretch, yes, but even in such case

OK.

>I don't have an answer for that, but for very slow systems like m68k
>it is probably not a good idea to have a buildd chroot too much clean

Yes, we usually do add debhelper and eatmydata. But that would
eventually not pull this library, then.

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794968: zsh: please clear console on logout (if recommended config is used)

[Carsten Hey]

* Frank Terbeck [2015-08-08 23:51 +0200]:
> Carsten Hey wrote:
> > Please clear console on logout if the recommended config for new users
> > is used.
>
> I think this should be doable with a zshexit hook like this:
>
> function debian_clear_upon_exit () {
> clear
> }
> add-zsh-hook zshexit debian_clear_upon_exit

Interesting :)  This could indeed avoid the need to ship a .zlogout for
new users.  (An ugly alternative would be to set some variable and clear
consoles in /etc/zsh/zlogout if this variable is set.)

By console I meant the thing you get if you press Ctrl-Alt-F1.  The
usual use case is to clear the console on logout for privacy reasons (an
other one is that the user might not want to be annoyed by things she/he
did in previous sessions whilst logging in again).

A minimal console_clear implementation with some tiny bugs could be
(this might fail to compile):

#include "required_headers.h"

void main(void) {
int mode;
if (ioctl(STDOUT_FILENO, KDGKBMODE, &mode) != 0)
exit(EXIT_SUCCESS); /* not a console, exit successfully */
if (access("/usr/bin/clear", R_OK | X_OK) == 0)
execl("/usr/bin/clear", "/usr/bin/clear", (char *) NULL);
exit(EXIT_FAILURE);
}

To meet the requirements of this use case, but not clearing the terminal
if it is not required, the shell needs to check if the terminal is
a console (or rather let clear_console do this check), ensure that it is
not a subshell and check that ${0##*/} does not match (-su|su).  Also
checking if $SSH_CONNECTION is set would avoid some useless calls to
console_clear.

console_clear could be replaced by checking $(tty) and running clear if
the output indicates that the terminal is a console.  But relying on
ttyname() and correctly interpreting its result is not the clean
solution I would prefer.  I'd rather wait until doko has the time to fix
/usr/bin/clear_console, i.e., presumably after the gcc transition is
done.  Nevertheless, using an zshexit hook seems to be worth
considering.


Carsten


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794895: chromium: Segmentation fault for some website

[Michael Gilbert]

control: tag -1 unreproducible, moreinfo
control: severity -1 minor

> The current release crashes regularly. For example the following link
> reproducibly crashes the browser:
>
>ftp://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-monitor.html

I'm not able to reproduce this with a clean install (i.e. no plugins,
apps, or extensions).

Have you tried disabling or removing the flash plugin, other apps, and
extensions?

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794964: gettext: must redo libstdc++ ABI transition because not done right

[Santiago Vila]

On Sat, Aug 08, 2015 at 10:21:23PM +, Thorsten Glaser wrote:
> Santiago Vila dixit:
> 
> >In the meantime there is nothing to fix because there is not a *single*
> >package in debian linked against this library.
> 
> … wait, what? Why is the package then installed on all systems, even
> in the supposedly clean and minimal buildd chroot?

The library was included in gettext-base but it was splitted to its
own package in version 0.18.1.1-6 and a compatibility dependency was
added.

We could drop this dependency for stretch, yes, but even in such case
you could still ask "why gettext-base is installed on all systems,
even in the supposedly clean and minimal buildd chroots".

I don't have an answer for that, but for very slow systems like m68k
it is probably not a good idea to have a buildd chroot too much clean
and minimal. You would spend a lot of time installing and uninstalling
debhelper and its dependencies over and over again.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#790125: RFS: dropbear/2015.67-1.1 NMU

[Guilhem Moulin]

Hi Helmut,

On Fri, 31 Jul 2015 at 07:46:26 +0200, Helmut Grohne wrote:
> That was quick. Let me answer some of your comments already. I intend
> to take another stab at the upload when I find more time, but that
> shall not prevent other interested sponsors from uploading it earlier.
> Possibly Gerrit replied by then.

I still have a hope to make it to Debconf (I'm currently on the waiting
list :-/).  Would be great to make it happen there!

FYI upstream made a new release today.  That includes a fix to the two
issues you reported in #27;  my own patches included in patches/series
have been applied as well.

  http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2015q3/001777.html

However, this time I didn't pull in the changes (although Debian is now 3
releases behind…)

> On Fri, Jul 31, 2015 at 05:44:09AM +0200, Guilhem Moulin wrote:
>> Alright, this one is new to me.  I'm not sure how blindly I can follow
>> 
>>https://wiki.debian.org/Multiarch/Implementation#dh.281.29_and_autotools
>> 
>> because dropbear-bin ships an executable ‘/usr/lib/dropbear/dropbearconvert’.
>> So checked the package source for openssh and found that openssh-server
>> uses Multi-Arch:foreign, but openssh-sftp-server, which ships
>> ‘/usr/lib/openssh/sftp-server’, doesn't.  So all in all I'm unsure what
>> to in my case.
> 
> It is actually much easier than that. Since dropbear does not ship any
> libraries or similar, the only Multi-Arch tag that makes sense is
> "foreign". So this is mostly a matter of asking: Does a package expose
> its architecture via one of its public interfaces? If the answer is
> "no", then "foreign" is appropriate.
> […]
> I didn't spot any reason for not marking all of the dropbear packages
> M-A:foreign, but this probably warrants a closer look.

Thanks for the explanation.  Yes, ‘Multi-Arch: foreign’ is the right tag
in that case.  I have updated my debian/control, but I'll wait for a
second round of feedback before uploading the package to mentors.

-- 
Guilhem.


signature.asc
Description: Digital signature

Bug#794964: gettext: must redo libstdc++ ABI transition because not done right

[Thorsten Glaser]

Santiago Vila dixit:

>Ports that do not even exist yet will definitely need a working gcc-5
>if they ever expect to be released architectures some day.
>
>So the natural thing to do (which I think it is what we have always done,
>but I may be wrong) is to use unstable as their starting point, not stable.

The problem here is ordering.

Assuming you can take an up-to-date unstable and bootstrap another
architecture using cross-compiling (Helmut Grohne does this regularily)
you have no troubles.

But often, people take other distros as starting point, compiling
things peu à peu, using older versions of packages if newer ones
don’t work OOTB as long as they fulfil the B-D, etc. which is all
perfectly valid.

Especially, packages pre-installed in the buildd chroots can be
out of date for quite some time.

But since this discussion is copied to the m68k list, I hope that
everyone upgrades their chroots right now ;)

gn8,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794974:

[Michael Gilbert]

control: tag -1 moreinfo, unreproducible

This isn't enough information to debug the problem.  Please attach
your ~/.steam/error.log file.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#791486: /usr/bin/rkhunter: 7439: [: Binary: unexpected operator

[Craig Small]

Package: rkhunter
Version: 1.4.2-3
Followup-For: Bug #791486

It's not actually the version check, it is how the verison is extracted
by the program. Looking in the logs:

[08:06:10] Info: This version  : Binary file /var/lib/rkhunter/db/i18n/zh 
matches 
  
[08:06:10] Info: Latest version: 2009091601

That looks like a grep message, grep is unhappy :(

# grep 'Version:' /var/lib/rkhunter/db/i18n/zh
Binary file /var/lib/rkhunter/db/i18n/zh matches
# LANG=C grep 'Version:' /var/lib/rkhunter/db/i18n/zh
Version:2009091601

I'm not sure where GREP_OPT is used elsewhere, so the fix is either:
Line 18470:
GREP_OPT="-a"

or line 7419:
Add -a after GREP_OPT


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

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

Versions of packages rkhunter depends on:
ii  binutils   2.25-10
ii  debconf [debconf-2.0]  1.5.57
ii  file   1:5.22+15-2
ii  lsof   4.86+dfsg-1
ii  net-tools  1.60-26+b1
ii  perl   5.20.2-6
ii  ucf3.0030

Versions of packages rkhunter recommends:
ii  bsd-mailx [mailx]   8.1.2-0.20150408cvs-1
ii  curl7.43.0-1
ii  iproute24.0.0-1
ii  postfix [mail-transport-agent]  2.11.3-1
ii  unhide  20121229-1+b1
ii  unhide.rb   22-1
ii  wget1.16.3-3

Versions of packages rkhunter suggests:
ii  liburi-perl 1.64-1
ii  libwww-perl 6.13-1
ii  powermgmt-base  1.31+nmu1

-- Configuration Files:
/etc/logcheck/ignore.d.server/rkhunter [Errno 13] Permission denied: 
u'/etc/logcheck/ignore.d.server/rkhunter'
/etc/rkhunter.conf changed [not included]

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794980: ITP: python-gssapi, python3-gssapi -- Python & Python3 interfaces to GSSAPI

[Robbie Harwood]

Package: wnpp
Version: N/A; reported 2015-08-08
Severity: wishlist

* Package name  : python-gssapi, python3-gssapi
  Version   : 1.1.2
  Upstream Author   : The Python GSSAPI Team
* URL   : https://github.com/pythongssapi/python-gssapi/
* License   : ISC
  Programming Lang  : Python
  Description   : Python interface to GSSAPI

Python Bindings for GSSAPI.  These bindings are for both RFC 2743/2744
and many extensions.  They are native bindings produced using Cython.

This package will be needed by at least the next release of freeipa, and
can also be consumed python3-ldap3, among others.

I am an upstream author with commit access.  Dafydd Harries
 has agreed to sponsor this package.


signature.asc
Description: PGP signature

Bug#794964: gettext: must redo libstdc++ ABI transition because not done right

[Thorsten Glaser]

Santiago Vila dixit:

>In the meantime there is nothing to fix because there is not a *single*
>package in debian linked against this library.

… wait, what? Why is the package then installed on all systems, even
in the supposedly clean and minimal buildd chroot?

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794911: bind9: bind9 update does not work, impossible to install

[Michael Gilbert]

control: tag -1 moreinfo, unreproducible, -security
control: severity -1 important

On Fri, Aug 7, 2015 at 7:08 PM, reinhard wrote:
> Package: bind9-host
> Version: 1:9.8.4.dfsg.P1-6+nmu2+deb7u4
> Severity: serious
> File: bind9
> Tags: security
> Justification: fails to build from source (but built successfully in the past)

Which of these problems you're actually facing?  Are you unable to
install bind9-host or are you unable to build the package from source?

Both work fine for me in wheezy.

Maybe try installing +deb7u6, which is on debian-security now, instead
of +deb7u4?

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781927: RFS: qemuctl/0.3.1-4 [ITA] -- control gui for qemu

[Gianfranco Costamagna]

Hi Antti,




>Not changed yet, but inquiry sent to 
>http://lists.alioth.debian.org/cgi-bin/mailman/private/pkg-qemu-devel/2015-August/006604.html
>so if they have good suggestions, then one more upload to mentors
>will be needed.


I can't/won't read, but ok, it is good as-is, let me know if you will need a 
new upload.

>> 6) d/watch file: you might want to use the Debian redirector instead of 
>> pointing directly to sf
>> https://qa.debian.org/cgi-bin/fakeupstream.cgi?upstream=sf/qemuctl
>
>Ok, didn't know such thing was in place. Qemuctl is not listed
>in re-director so adding it there would require another ticket into BTS.
>To avoid this hassle, I'm leaving the current URL because it is working 
>ok with uscan. 


Actually it is listed, but as said on irc, if the sf link is automatically 
translated by uscan
maybe it is better to leave it

[snip]
>dget -x 
>http://mentors.debian.net/debian/pool/main/q/qemuctl/qemuctl_0.3.1-4.dsc


last two nitpicks and issues:

1) there is no need to call the files under debian directory
"qemuctl.manpages" as long as you have only one binary package "manpages" is 
good enough.

(note: I'm not asking to change that)


2) you might find useful to remove the "debian/dirs" file, because it should be
useless since you already have your install file.


3) the license of the package seems to be wrong:

accoding to licensecheck and manual checks I did, the files have a license
GPL-3+, not GPL-2+
(and thanks for promptly replying to the feedbacks)



please let me know how do you feel about the last three things,
and I'll do the final checks&upload.


cheers,

Gianfranco


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#790796: sensord: RRD data loss

[Vincent Lefevre]

Hi,

On 2015-08-08 23:30:26 +0200, Aurelien Jarno wrote:
> From what I have been able to get the problem is that when using a
> single rrd file for all data, the number of columns (ie sensors) is
> defined when the file is created. Therefore the upgrade of your kernel
> changed the number of sensors, and caused this issue.
> 
> From what I have been able to read in the documentation, one solution
> would be to use the MULTIPLE mode of RRD, which create one file per
> column or sensor. But this format is incompatible with the current one,
> which means people will have to recreate their database, and possibly
> the scripts extracting the data for them.

This could be an option (set by default to avoid problems in the
future). But anyway, after upgrading the kernel (even a security
update!), the database is currently no longer usable. So, this
would not be worse than the current situation.

> I don't really know what is the solution for this bug, one might be to
> stop shipping sensord in Debian as it is kind of dead upstream and not
> build by default.

Is there a replacement?

Or perhaps it's easy enough for the user to write a daemon in a
shell/Perl/whatever script by executing the sensors utility. BTW,
I already have written such a utility in Perl, which supports
CPU load, disk usage and entropy. Adding sensors support would
really be easy.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794964: gettext: must redo libstdc++ ABI transition because not done right

[Thorsten Glaser]

Santiago Vila dixit:

>In the meantime there is nothing to fix because there is not a *single*
>package in debian linked against this library.

Ah, okay then.

Then I agree with the severity downgrade, too.

(Still… building GCC takes about a week, so we could not have
been earlier. Plus it’s about 250 MiB fatter now…)

Meh anyway… going to bed, and offloading the discussion onto
the other porters.

bye,
//mirabilos
-- 
18:47⎜ well channels… you see, I see everything in the
same window anyway  18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794979: Should probably depend on packagekit

[Michael Biebl]

Package: gnome-software
Version: 3.16.5-2
Severity: important

gnome-software uses the PackageKit (D-Bus) API, so we should probably
add a dependency on the "packagekit" package.


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

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

Versions of packages gnome-software depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gnome-software-common3.16.5-2
ii  gsettings-desktop-schemas3.16.1-1
ii  libappstream-glib7   0.4.1-1
ii  libatk1.0-0  2.16.0-2
ii  libc62.19-19
ii  libcairo-gobject21.14.2-2
ii  libcairo21.14.2-2
ii  libgdk-pixbuf2.0-0   2.31.5-1
ii  libglib2.0-0 2.44.1-1.1
ii  libgnome-desktop-3-103.16.2-2
ii  libgtk-3-0   3.16.6-1
ii  libpackagekit-glib2-18   1.0.6-1+b1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpolkit-gobject-1-00.105-11
ii  libsoup2.4-1 2.50.0-2
ii  libsqlite3-0 3.8.11.1-1

gnome-software recommends no packages.

gnome-software suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794964: gettext: must redo libstdc++ ABI transition because not done right

[Santiago Vila]

On Sat, Aug 08, 2015 at 09:45:33PM +, Thorsten Glaser wrote:
> including ports that don’t yet exist.

Hmm. I don't think we should really worry about that case.

Ports that do not even exist yet will definitely need a working gcc-5
if they ever expect to be released architectures some day.

So the natural thing to do (which I think it is what we have always done,
but I may be wrong) is to use unstable as their starting point, not stable.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794964: gettext: must redo libstdc++ ABI transition because not done right

[Santiago Vila]

On Sat, Aug 08, 2015 at 09:45:33PM +, Thorsten Glaser wrote:
> I would like to hear from either of you two how we can fixup the
> situation for m68k in the meantime.

In the meantime there is nothing to fix because there is not a *single*
package in debian linked against this library.

This is only a problem for whoever has a m68k machine (or, for the
matter, any other non-released architecture) meeting the following
conditions:

* running *unstable*.
* in a *production* environment.
* and having a third party package linked against libasprintf.

Frankly, the number of people affected is probably zero.


We are at the beginning of a release cycle. There will be more gettext
releases in the following two years, and if not, you can always
trigger a binary-only NMU for m68k once gcc-5 is in unstable.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794978: python-cobra: Package new release 0.4.0b2

[Afif Elghraoui]

Package: python-cobra
Severity: normal
Control: block -1 by 794511

Packaging of 0.4.0b2 is delayed until cython again becomes installable
in unstable.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794977: dselect: no access methods are available

[Daniel Leidert]

Package: dselect
Version: 1.18.2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Since a short time (not sure, since when), dselect refuses to work with
the error mentioned in the subject. Even if I start it to choose an
access method, this error is given.

A downgrade of dpkg to version 1.18.1 does not help.

Anything I can do to debug the situation?

Regards, Daniel



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

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

Versions of packages dselect depends on:
ii  dpkg  1.18.2
ii  libc6 2.19-19
ii  libgcc1   1:5.1.1-14
ii  libncursesw5  5.9+20150516-2
ii  libstdc++65.1.1-14
ii  libtinfo5 5.9+20150516-2

dselect recommends no packages.

Versions of packages dselect suggests:
ii  perl  5.20.2-6

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJVxnogAAoJEEvNBWfCltBdqOIQALOFWlpPx5REa8eP6YW1ZWGo
srcFkSEJfhzOGXL0eA71ev8IvHMLXgIgmbgMwdu7jqI8iKw7/U72Ypp/Jc0aKwyh
NoUGOlv9qcF7M9q6gSAFz9iZXymL024h8egxAtn4BKClF91cehvfhzAgzXRUO2Y0
cr37e39QWCdVlLLap0r59yINZPsrSOU3RiOV1A/tOVwJ/IU6ZcNbLihHuDRs+1Yy
V3VNhTHH2xhXykcVWTnvxudASC/V+qJ9IFPV3mseEVL4N0Gp4H464lkas7DH3vWO
uMQmdt/H/NguqzP1pcLQW/ox+gkVBdh0FGqrnNkjABANeCEsmBOScVi+f0UveCTn
4s6ov0A4Wxy6jUllWrK95ftjvwDmSfwXJfcsUOFtTAATxEWrUuW/jc/8cdCxgLrp
oVmt1RdsI7Zw0U9MAi2T/oshTM/PAnoCA3YcLR8FkRdTNZfOP9vsG9anNUluSNR8
oiBEAsj58O7lMGCE4LHL9CQjEoIBWYNUexV3KKfUPm+bL0+hLCPUVNN77SATqIv8
IDPHyqG+nQrtrsuJjUWXVMwDmA6tGodXwPKdv7L3SSEJBRZD5fuDjdE/D9NyT0ms
Mh5MRkCRsE5fbR6cUskKUQ2Y4M8sKU74Dczd1Msn1SFYavF5DmwIcr55efc2X3yp
HRfxCMjrbU4qiudcniyw
=mvlI
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781927: RFS: qemuctl/0.3.1-4 [ITA] -- control gui for qemu

[Antti Järvinen]

Hello Gianfranco and thank you for your review,

> 1) d/changelog: please update the changelog to point to unstable suite
> (maybe also refresh the timestamp)

Ok. 

> 2) d/changelog might benefit of a "\n" in the first comment line
> (after a full stop it is good to go in a new line)

Ok. 

> 3) d/copyright file lists twice GPL-2+ licensethis isn't a problem, but you 
> can do something like
> 
> License: GPL-2+
> [snip]
> License: GPL-2+
> and at the end
> License: GPL-2+
> [license text]

Ok. 

> 4) d/copyright: you should add yourself to the copyright file, since you are 
> going to work
> on the packaging of qemuctl

Ok. 

> 5) d/control: what about team maintaining the tool and setting you as 
> uploader?
> pkg-qemu-devel team might want to have that package under the team umbrella
> https://qa.debian.org/developer.php?login=pkg-qemu-de...@lists.alioth.debian.org

Not changed yet, but inquiry sent to 
http://lists.alioth.debian.org/cgi-bin/mailman/private/pkg-qemu-devel/2015-August/006604.html
so if they have good suggestions, then one more upload to mentors
will be needed.

> 6) d/watch file: you might want to use the Debian redirector instead of 
> pointing directly to sf
> https://qa.debian.org/cgi-bin/fakeupstream.cgi?upstream=sf/qemuctl

Ok, didn't know such thing was in place. Qemuctl is not listed
in re-director so adding it there would require another ticket into BTS.
To avoid this hassle, I'm leaving the current URL because it is working 
ok with uscan. 

> 7) d/rules,d/clean: instead of override_dh_clean you might want to create a 
> debian/clean, and add
> "debian/qemuctl.1" as content, to save some bits in your rules file

Ok. 

> 8) d/rules: you might want to remove lines from 3 to 8, they are autogenerated

Ok. 

> 9) d/rules, please add
> export QT_SELECT=4
> because otherwise compilation might fail if you have both installed in your 
> system

Ok. 

> 10) d/*.lintian-overrides: I see twice the lintian override
> 
> "no-upstream-changelog", are you sure it is needed for both binary and source 
> packages?
> (note: I didn't check this)

https://lintian.debian.org/tags/no-upstream-changelog.html seems to suggest 
it makes sense only with binary package. So removed from source package
and lintian is not causing trouble.

There is now a new version uploaded to mentors that includes the changes
described above. The source package can be obtained using
dget -x http://mentors.debian.net/debian/pool/main/q/qemuctl/qemuctl_0.3.1-4.dsc

--
Antti Järvinen


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794968: zsh: please clear console on logout (if recommended config is used)

[Frank Terbeck]

Carsten Hey wrote:
> Please clear console on logout if the recommended config for new users
> is used.

I think this should be doable with a zshexit hook like this:

function debian_clear_upon_exit () {
clear
}
add-zsh-hook zshexit debian_clear_upon_exit

That hook could be installed in the recommended setup file.

Disclaimer: I didn't try this. :-)


Regards, Frank


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794964: gettext: must redo libstdc++ ABI transition because not done right

[Thorsten Glaser]

Matthias Klose dixit:

>the package maintainers. Halt the buildds and re-enable them once you have
>updated your buildds.

Erm. This is so wrong on several counts.

• What builds gcc-5 if not the buildds?

• There *will* be people later who build packages for other,
  e.g. new (think arm64) architectures. They need to build them
  in order. Build-Depends is what defines that order; otherwise
  any old package in any version is fine.


Santiago Vila dixit:

>Thorsten, your work on the m68k arch is really amazing, but I don't
>think that submitting "grave" bugs for bugs that only happen in m68k

Who says this only happens on m68k?

>I'll be happy to add a versioned B-D in the next upload just in case
>it helps

It helps for those architectures who did not build the new gettext
yet, including ports that don’t yet exist.


I would like to hear from either of you two how we can fixup the
situation for m68k in the meantime.

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794967: zsh: please enhance /etc/zshrc

[Frank Terbeck]

Carsten Hey wrote:
[...]
>  * Please add some additional keybindings, at least for the emacs keymap:
>
>- bind PageUp "${terminfo[kpp]}" to history-search-backward
>- bind PageDown "${terminfo[knp]}" to history-search-forward
>- bind BackTabKey "${terminfo[kcbt]}" to reverse-menu-complete

I firmly believe, that a vendor's *global* setup file should be as
minimal as possible, which is why I really don't want to add anything
that's more than making the zsh defaults behave more robustly across
multiple terminals or deal with stuff specific to Debian.

This is stuff for the recommended setup file.

>  In terminfo(5), the capname cbt is described as "back tab (P)"
>  and kcbt is described as "back-tab key", therefore the suggested
>  'BackTabKey' instead of 'BackTab' - even though grml confuses
>  people that know terminfo(5) by using 'BackTab' as name.

By that logic, kpp would need to be mapped to "PreviousPageKey". I think
the current naming is fine.

>- Maybe F1 could invoke run-help?  But then the output of run-help
>  w/o arguments should be more useful for new users.
>
>- Red Hat maps or mapped space to magic-space, I think Debian should
>  _not_ do this, but initially I thought that this would be a good
>  idea.

Again, this fits into the recommended setup file

>  * $key should be unset unless there is a reason for not doing so.

The reason I left it set, is because its layout matches the $key
dictionary, that zsh's "zkbd" function produces and can be used as a
drop-in replacement. I still think that's a reasonable idea, even though
it slightly violates the "A vendor's global setup needs to be minimal"
rule.

>  * (( ${+aliases[run-help]} )) requires the zsh/parameter module.  If,
>in rare cases, possibly involving zsh-static, there is a chance that
>this module is not loaded successfully, you should consider doing
>this instead to remove the alias w/o error message:
>
>  alias run-help=
>  unalias run-help

That's a good point. I think we can do it like this:

unhash -a -m 'run-help' || true

-a removes alias from its hash table. -m uses the argument as a pattern.
Since there's no character that's significant to pattern matching, this
will work. This way, there is no error message. The '|| true' is to make
sure the setup file exits with successful status.

We could also just do this:

unalias run-help 2>/dev/null || true

…if that's more straight-forward to read.


Regards, Frank


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794466: Virtualbox might not be suitable for Stretch

[Gianfranco Costamagna]

Hi Debian Security Team,


(Dear Jonathan, thanks for the heads-up, I tried to avoid cross-posting,
and I thought release was a better place then security, so dropping
-release from the mail cc, let me know if I have to readd it)


I would like to ask you whether is possible to have an exception for
Virtualbox Stable Releases.

To avoid duplication, please read bug #794466 for the discussion and my
personal POV of the story, I tried to be as much verbose as possible,
please do not hesitate to ask anything you want if something is not
clear enough.

(or if you want debdiffs, git diff --stat between versions, changelogs or
whatever).


(below a little snippet of the last two bug messages)


cheers,

Gianfranco



Il Sabato 8 Agosto 2015 23:42, Jonathan Wiltshire  ha scritto:
On Sat, Aug 08, 2015 at 09:23:31PM +, Gianfranco Costamagna wrote:

> Virtualbox suffers of  many security issues in Debian,
> specially because Upstream (Oracle) refuses to give
> patches for CVEs, and (you can see in the Debian bug
> 794466 an analysis of the Oracle policy and discussion)
> this makes difficult to handle security uploads in stable
> releases.
> 
> 
> The only patch they give for a CVE is "upgrade to the
> next version of the stable branch", and extracting patches
> from the code is not trivial, specially for such a huge package.

You should bring this up with the security team and see whether they are
satisfied that previous upstream releases have been of sufficient quality
for this to be feasible in the future.


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developerhttp://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794976: nagios3: loads remote web resources

[Matt Taggart]

Package: nagios3-cgi
Version: 3.5.1.dfsg-2+b1
Severity: wishlist

The main nagios webpage
  /usr/share/nagios3/htdocs/index.php
loads
  /usr/share/nagios3/htdocs/main.php
which cotains some javascript that loads
  /usr/share/nagios3/htdocs/rss-feed.php
  /usr/share/nagios3/htdocs/rss-newsfeed.php
which pull remote RSS feeds from
  http://www.nagios.org/backend/feeds/corepromo
  http://www.nagios.org/backend/feeds/frontpage/

This might be undesirable for a couple reasons:
1) it would reveal to a network evesdropper that a system has
  nagios installed, which could prompt attacks.
2) it will fail if the server does not have a route to the internet
3) it uses a tiny amount of bandwidth

These are all relatively minor issues, but in general it would be
better if debian packages did not load remote resources (although it's
not strictly against policy) so I think this is only 'wishlist'
severity.

Thanks,

-- 
Matt Taggart
tagg...@debian.org


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794466: Virtualbox might not be suitable for Stretch

[Jonathan Wiltshire]

On Sat, Aug 08, 2015 at 09:23:31PM +, Gianfranco Costamagna wrote:
> Virtualbox suffers of  many security issues in Debian,
> specially because Upstream (Oracle) refuses to give
> patches for CVEs, and (you can see in the Debian bug
> 794466 an analysis of the Oracle policy and discussion)
> this makes difficult to handle security uploads in stable
> releases.
> 
> 
> The only patch they give for a CVE is "upgrade to the
> next version of the stable branch", and extracting patches
> from the code is not trivial, specially for such a huge package.

You should bring this up with the security team and see whether they are
satisfied that previous upstream releases have been of sufficient quality
for this to be feasible in the future.


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51



signature.asc
Description: Digital signature

Bug#794964: gettext: must redo libstdc++ ABI transition because not done right

[Matthias Klose]

Control: severity -1 wishlist

On 08/08/2015 09:25 PM, Thorsten Glaser wrote:
> Source: gettext
> Version: 0.19.5.1-1
> Severity: grave
> Justification: renders package unusable
> 
> I just noticed we already have libasprintf0v5 in Debian/m68k unstable.
> This cannot be, because we haven’t started the GCC 5 transition yet (I
> know because src:gcc-defaults is currently building on one of my boxen
> and src:gcc-5 has just finished building).
> 
> Evidently, src:gettext was uploaded, with the new binary package name,
> without adding a versioned B-D on gcc (>= 4:5).
> 
> This means that src:gettext must re-do the transition after adding the
> versioned B-D, changing soname and binary package name yet again.

no, there were several announcements on d-d-a that we would start the transition
on July 31.  If you don't read it, and don't prepare for it, not a problem for
the package maintainers. Halt the buildds and re-enable them once you have
updated your buildds.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794466: I: Bug#794466: Virtualbox might not be suitable for Stretch

[Gianfranco Costamagna]

Hi Frank and Release Team,


>Oracle at this moment maintains a 4.0.x 4.1.x 4.2.x 4.3.x 5.0.x
>branches where security fixes seems to be addressed all.
>
>(virtualbox-ose from o-o-s still needs some pinpoint fixes)


virtualbox-ose is at version 3.2.10, and the last release from [1]
is 3.2.28, and released two months ago.

Does this mean that CVE gets fixed on 3.2.x too?


[1] https://www.virtualbox.org/wiki/Changelog-3.2

thanks,

Gianfranco


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794975: mixxx: will FTBFS with unsatisfiable dependencies due to libstdc++ transition

[Simon McVittie]

Package: mixxx
Version: 1.11.0~dfsg-4
Severity: serious
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11
Tags: patch

A binNMU of mixxx failed to build from source prior to the transition
from libvamp-hostsdk3 to libvamp-hostsdk3v5. It has not yet been retried,
but when it is, it will likely stop at BD-Uninstallable or continue
to fail, because it specifically build-depends on the old libvamp-hostsdk3.

It is unusual to build-depend on library packages, because the
corresponding -dev usually pulls them in, but I assume there is some
special reason in this case.

The attached patch appears to resolve this. I'm happy to NMU this
(with the addition of this bug number) if necessary.

Regards,
S
>From a0156952b92336f21642a9cd31c317f933510919 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 8 Aug 2015 16:51:35 +0100
Subject: [PATCH] debian/control: change build-dependency on libvamp-hostsdk3
 to libvamp-hostsdk3v5 for stdc++ transition

---
 debian/changelog | 8 
 debian/control   | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index f923767..d108522 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+mixxx (1.11.0~dfsg-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: change build-dependency on libvamp-hostsdk3 to
+libvamp-hostsdk3v5 for stdc++ transition
+
+ -- Simon McVittie   Sat, 08 Aug 2015 16:51:14 +0100
+
 mixxx (1.11.0~dfsg-4) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 6b63635..ae0e57f 100644
--- a/debian/control
+++ b/debian/control
@@ -30,7 +30,7 @@ Build-Depends:
  libsoundtouch-dev (>= 1.5.0),
  libtag1-dev,
  libusb-1.0-0-dev,
- libvamp-hostsdk3,
+ libvamp-hostsdk3v5,
  libvorbis-dev,
  pkg-config,
  portaudio19-dev,
-- 
2.5.0

Bug#790796: sensord: RRD data loss

[Aurelien Jarno]

Hi,

On 2015-07-01 21:08, Vincent Lefevre wrote:
> Package: sensord
> Version: 1:3.3.5-2
> Severity: grave
> Justification: causes non-serious data loss
> 
> It seems that sensord uses an inconsistent set of data for its
> RRD update, yielding data loss. "rrd update" no longer updates
> the sensord.rrd database:
> 
> -rw-r--r-- 1 root root 82480 2015-05-13 00:25:00 /var/log/sensord.rrd
> 
> due to the following errors seen in my /var/log/syslog file:
> 
> [...]
> Jul  1 20:30:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
> /var/log/sensord.rrd: found extra data on update argument: 
> 67.0:67.0:66.0:74.0:1.58
> Jul  1 20:30:00 xvii sensord: rrd update error (-1)
> Jul  1 20:35:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
> /var/log/sensord.rrd: found extra data on update argument: 
> 62.0:54.0:57.0:69.0:0.52
> Jul  1 20:35:00 xvii sensord: rrd update error (-1)
> Jul  1 20:40:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
> /var/log/sensord.rrd: found extra data on update argument: 
> 66.0:62.0:64.0:72.0:1.33
> Jul  1 20:40:00 xvii sensord: rrd update error (-1)
> Jul  1 20:45:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
> /var/log/sensord.rrd: found extra data on update argument: 
> 63.0:54.0:57.0:70.0:0.54
> Jul  1 20:45:00 xvii sensord: rrd update error (-1)
> Jul  1 20:50:00 xvii sensord: Error updating RRD file: /var/log/sensord.rrd: 
> /var/log/sensord.rrd: found extra data on update argument: 
> 60.0:54.0:59.0:66.0:0.30
> Jul  1 20:50:00 xvii sensord: rrd update error (-1)
> [...]

From what I have been able to get the problem is that when using a
single rrd file for all data, the number of columns (ie sensors) is
defined when the file is created. Therefore the upgrade of your kernel
changed the number of sensors, and caused this issue.

From what I have been able to read in the documentation, one solution
would be to use the MULTIPLE mode of RRD, which create one file per
column or sensor. But this format is incompatible with the current one,
which means people will have to recreate their database, and possibly
the scripts extracting the data for them.

I don't really know what is the solution for this bug, one might be to
stop shipping sensord in Debian as it is kind of dead upstream and not
build by default.

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


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794466: Virtualbox might not be suitable for Stretch

[Gianfranco Costamagna]

Hi Debian Release Team,


TLTR:


Virtualbox suffers of  many security issues in Debian,
specially because Upstream (Oracle) refuses to give
patches for CVEs, and (you can see in the Debian bug
794466 an analysis of the Oracle policy and discussion)
this makes difficult to handle security uploads in stable
releases.


The only patch they give for a CVE is "upgrade to the
next version of the stable branch", and extracting patches
from the code is not trivial, specially for such a huge package.


My request, based on Markus mail quoted below

(something I pondered already, I was just waiting for somebody
to do the first move), would be to have a sort of permission
to do the updates to newer stable releases in s-p-u.

e.g.


On oldstable, version 4.1.18-dfsg-2+deb7u5 might become 4.1.30

on stable version 4.3.18 might become 4.3.30 and so on.

Oracle at this moment maintains a 4.0.x 4.1.x 4.2.x 4.3.x 5.0.x
branches where security fixes seems to be addressed all.

(virtualbox-ose from o-o-s still needs some pinpoint fixes)


So, even if the debdiff might look scary, we might want to
update at least to the correspondant stable branch
to fix bugs and security issues.

Honestly I *never* found a regression in Virtualbox maintainance
releases, neither in backports, and the huge popcon makes difficult
to just let the package disappear.

I maintain Virtualbox since ~2013 or so, and I can say that the
maintainance branches does not require new dependencies
(at least they never did, the only build-dependencies we added
in maintainance releases were due to packaging bugs that had to
be fixed, not something that upstream added)



Thanks for your attention,

(note: I did not find any reference on google about this sort
of exceptions, please feel free to point me on some documentation,
if adding -release to the bug is not enough, or feel free to reassing
to the best meta package bug)


Gianfranco

>Hi Gianfranco,
>thanks for your summary.
>
>Although I'm not involved in maintaining virtualbox, still a few
>thoughts:
>
>* What would that mean for Jessie updates?
>* Isn't that basically the same problem we have with MySQL,
>  or even Iceweasel?
>
>So I think the question is either drop, or work with upstream releases,
>from which I'd personally prefer.
>
>Even popcon isn't too bad: 
>https://qa.debian.org/popcon.php?package=virtualbox
>
>Leaving users with the possibility to use upstream packages is also not
>very attractive.
>
>Just me few cents :)
>Markus 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794973: Upgrade to Jessie kernel 3.16 breaks Xserver early in boot process with old nVidia card[Quadro NVS 440]

[Barry Say]

Package: linux-image-3.16
Version: 3.16.7


Upgrading to Jessie (kernel 3.16) lost my display. Early in the boot 
process, (when the resolution changes) no further output occurs. The 
boot process is successful in that I can access via ssh.
Reverting to kernel 3.2 avoids the problem. An installation of testing 
(kernel 4.0) works well, as does unstable (4.1).



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794974: steam : commande introuvable - steam : command not found

[Marc]

Package:steam
Version:1.0.0.50
Severity:important

Dear Maintainer,

When I launch steam, the application say "bash: steam : commande 
introuvable".


I do an "apt-get remove steam",  an "apt-purge steam" and delete the 
"./steam" folder in my home folder before re-installing steam.


$ dpkg --status steam
Package: steam
Status: install ok installed
Priority: extra
Section: non-free/games
Installed-Size: 3972
Maintainer: Debian Games Team 
Architecture: i386
Multi-Arch: foreign
Version: 1.0.0.50-3
Depends: debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.15), libstdc++6 (>= 
4.3), libx11-6, xz-utils, libudev1, libxinerama1, libtxc-dxtn0, 
libgl1-mesa-dri, libgl1-mesa-glx, xterm | x-terminal-emulator

Pre-Depends: debconf
Recommends: zenity, fonts-liberation
Description: Valve's Steam digital software delivery system
Steam (http://www.steampowered.com) is a software content delivery system
developed by Valve software (http://www.valvesoftware.com).  There is
some free software available, but for the most part the content delivered
is non-free.
.
This package comes with a fairly substantial non-free license agreement
that must be accepted before installing the software.  If you have any
opposition to non-free work, please select "I DECLINE" during the package
installation dialogs.   There are also additional agreements in various
parts of the application that differ from the original agreement.  In
other words, pay attention and read carefully if you're worried about your
rights.
Homepage: http://www.steampowered.com

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

Kernel: Linux 4.1.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 steam depends on:
ii  debconf [debconf-2.0] 1.5.57
ii  konsole [x-terminal-emulator] 4:15.04.3-2
ii  libc6 2.19-19
ii  libgl1-mesa-dri   10.6.3-1
ii  libgl1-mesa-glx   10.6.3-1
ii  libstdc++65.2.1-14
ii  libtxc-dxtn-s2tc0 [libtxc-dxtn0]  0~git20131104-1.1
ii  libudev1  224-1
ii  libx11-6  2:1.6.3-1
ii  libxinerama1  2:1.1.3-1+b1
ii  xterm [x-terminal-emulator]   318-2
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages steam recommends:
ii  fonts-liberation  1.07.4-1
ii  zenity3.16.3-1

steam suggests no packages.

-- debconf information:
* steam/license:

Bug#794933: apache2-suexec-custom: prompting due to modified conffiles which were not modified by the user: /etc/apache2/conf-available/security.conf

[Andreas Beckmann]

On 2015-08-08 22:34, Stefan Fritsch wrote:
> On Saturday 08 August 2015 11:38:14, Andreas Beckmann wrote:
>> This was observed while doing a wheezy -> jessie -> stretch upgrade
>> test. I did not see such behavior while testing the other apache
>> packages.

This now shows up on all (or at least a lot of) upgrade paths involving
apache packages (many php packages among them), so apache2-suexec-custom
was only the first to fail.
Always while "Setting up apache2 (2.4.16-1)".

> AFAICS, this happens when one upgrades from wheezy from a state where 
> only apache2.2-common is installed but not apache2. There is a bug in 
> apache2's preinst in jessie that makes it not recognize this case and 
> not execute the conffile handling.
> 
> While I think I have a fix, I am not not sure that I want to change 
> the upgrade logic in a stable point release.

I haven't seen this bug in upgrades to jessie so far, only in the
followup upgrade to stretch. This could be the case if that conffile has
not changed between wheezy and jessie, but changes from jessie to
stretch ... (and it would blow up in jessie, too, if you would ever have
to ship an updated version of that conffile in jessie).
So maybe it is not neccessary to fix it in jessie if it can be fixed in
stretch instead.

If you have a patch, I could check the specific upgrade paths in my
piuparts setup (without uploading to sid and waiting for a migration to
testing).

> I will have to think about it. If you are at debconf, maybe we can 
> talk about it there.

No, I'll be on holidays then ...

Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794972: gksu: Environment variable XDG_RUNTIME_DIR is not reset, renders gnome unusable.

[Klaus Stein]

Package: gksu
Version: 2.0.2-9
Severity: important

After upgrading to Jessie sometimes Gnome got unusable as
/run/user/1000/steink/dconf was suddenly owned by root and not writeable by
steink (Gnome hangs, /var/log/messages grew to some GB etc.).

According to
 this is
caused by XDG_RUNTIME_DIR not being properly reset when switching to root with
su/sudo/…

Su and sudo are fixed, but with gksu XDG_RUNTIME_DIR=/run/user/1000 survives
(which causes the problem).

I think this should not happen without -k.

A quick fix would be to at least change /usr/share/applications/gksu.desktop:
Exec=gksu /usr/bin/x-terminal-emulator
to
Exec=gksu -l /usr/bin/x-terminal-emulator

I am not sure whether root should be allowed to use XDG_RUNTIME in this way and
change file ownership, so maybe the bug (partly) belongs to another package.

Thanks,

Klaus



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

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

Versions of packages gksu depends on:
ii  gconf-service 3.2.6-3
ii  libatk1.0-0   2.14.0-1
ii  libc6 2.19-18
ii  libcairo2 1.14.0-2.1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3
ii  libgconf-2-4  3.2.6-3
ii  libgdk-pixbuf2.0-02.31.1-2+b1
ii  libgksu2-02.0.13~pre1-8
ii  libglib2.0-0  2.42.1-1
ii  libgnome-keyring0 3.12.0-1+b1
ii  libgtk2.0-0   2.24.25-3
ii  libpango-1.0-01.36.8-3
ii  libpangocairo-1.0-0   1.36.8-3
ii  libpangoft2-1.0-0 1.36.8-3
ii  libstartup-notification0  0.12-4
ii  sudo  1.8.10p3-1+deb8u2

Versions of packages gksu recommends:
ii  gnome-keyring  3.14.0-1+b1

gksu suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794971: lvm2: Volume group not found, unable to find LVM during boot

[Ertuğrul Harman]

Package: lvm2
Version: 2.02.111-2.2
Severity: normal

Dear Maintainer,

During every boot time after a fresh installation of debian jessie, I get 
following errors after grub screen passes:

Volume group "ert-debian-vg" not found.
Skipping volume group "ert-debian-vg"
Unable to find LVM "volume ert-debian-vg/root"
Volume group "ert-debian-vg" not found
Skipping volume group "ert-debian-vg"
Unable to find LVM "volume ert-debian-vg/swap_1"
Please unlock disk sd3_crypt:

I enter my password and boot continues.

-- System Information:
Debian Release: 8.1
  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=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 lvm2 depends on:
ii  dmeventd  2:1.02.90-2.2
ii  dmsetup   2:1.02.90-2.2
ii  init-system-helpers   1.22
ii  initscripts   2.88dsf-59
ii  libc6 2.19-18
ii  libdevmapper-event1.02.1  2:1.02.90-2.2
ii  libdevmapper1.02.12:1.02.90-2.2
ii  libreadline5  5.2+dfsg-2
ii  libudev1  215-17+deb8u1
ii  lsb-base  4.1+Debian13+nmu1

lvm2 recommends no packages.

Versions of packages lvm2 suggests:
pn  thin-provisioning-tools  

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794933: apache2-suexec-custom: prompting due to modified conffiles which were not modified by the user: /etc/apache2/conf-available/security.conf

[Stefan Fritsch]

On Saturday 08 August 2015 11:38:14, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package failed the
> piuparts upgrade test because dpkg detected a conffile as being
> modified and then prompted the user for an action. As there is no
> user input, this fails. But this is not the real problem, the real
> problem is that this prompt shows up in the first place, as there
> was nobody modifying this conffile at all, the package has just
> been installed and upgraded...


> This was observed while doing a wheezy -> jessie -> stretch upgrade
> test. I did not see such behavior while testing the other apache
> packages.

AFAICS, this happens when one upgrades from wheezy from a state where 
only apache2.2-common is installed but not apache2. There is a bug in 
apache2's preinst in jessie that makes it not recognize this case and 
not execute the conffile handling.

While I think I have a fix, I am not not sure that I want to change 
the upgrade logic in a stable point release.

I will have to think about it. If you are at debconf, maybe we can 
talk about it there.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy -> jessie upgrade

[Stefan Fritsch]

On Saturday 08 August 2015 09:34:52, Andreas Beckmann wrote:
> > With apache2.2-common being gone this should be rather easy.
> > IIRC these conffiles were taken over by the apache2 package, so
> > all that should be needed are unversioned
> >
> >  Breaks+Replaces: apache2.2-common
> >
> > in the apache2 package.
> 
> Or rather make the Conflicts already existing in apache2
> unversioned.

Do you know if there is any practical difference between conflicts and 
breaks+replaces in this case?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy -> jessie upgrade

[Andreas Beckmann]

On 2015-08-08 22:36, Stefan Fritsch wrote:
> Do you know if there is any practical difference between conflicts and 
> breaks+replaces in this case?

I don't think so. All dependencies on apache-2.2-common should be gone
by now, so removal of that package could happen anytime without
influencing any other package upgrade path.
BTW, Conflicts should come with Replaces, too.

Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#792624: Fwd: Fwd: Re: multiarch = same and different date-entries in generated man page of i32/i64

[Roelof Berg]

Possibly a help2man  version below 
1.47.1 is used on the build server and help2man doesn't support 
SOURCE_DATE_EPOCH before this date. (See: 
https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal). I'm not 
familiar with the debian automated build infrastructure, and I will have 
to ask some newsgroups how to examine the build toolchain.


Roelof

Bug#794970: ejabberd: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Adriano Rafael Gomes]

Package: ejabberd
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


pt_BR.po.gz
Description: application/gzip


signature.asc
Description: Digital signature

Bug#794969: udev: change in network device naming scheme unnecessarily and incorrectly renames WiMAX devices

[brian m. carlson]

Package: udev
Version: 224-1
Severity: normal

Previously, my WiMAX device was named something like wmx0.  Now, it
appears it's been renamed to enx.  First of all, the name
has changed from what it used to be, and now I have to check that it's
not broken anything.  There wasn't supposed to be a naming change for
people with the persistent-net rules in place.

Secondly, this is not an Ethernet device, so en is not correct (it
should be ww).  The device is on the USB bus (using the driver
i2400m-usb).

For an example why this matters, think firewall rules: while I might
legitimately want to SSH into my laptop over Ethernet or WiFi (e.g. from
my phone when I'm in the other room), there's no reason I would want
arbitrary people on the Internet (WiMAX) to SSH in.  Of course, I have
appropriate security measures in place, but I'd still want to firewall
incoming WiMAX connections, and using an appropriate naming scheme makes
that possible.

-- Package-specific info:

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

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

Versions of packages udev depends on:
ii  adduser 3.113+nmu3
ii  cdebconf [debconf-2.0]  0.195
ii  debconf [debconf-2.0]   1.5.57
ii  dpkg1.18.2
ii  libacl1 2.2.52-2
ii  libblkid1   2.26.2-9
ii  libc6   2.19-19
ii  libkmod221-1
ii  libselinux1 2.3-2+b1
ii  libudev1224-1
ii  lsb-base4.1+Debian13+nmu1
ii  procps  2:3.3.10-2
ii  util-linux  2.26.2-9

udev recommends no packages.

udev suggests no packages.

-- debconf information excluded

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Bug#794383: apache2: Upgrade to apache2-2.2.22-13+deb7u5 breaks CA certificate chain

[Stefan Fritsch]

On Saturday 08 August 2015 00:25:37, Felicitus wrote:
> > Please try the version from https://people.debian.org/~sf/794383/
> > and check if it either fixes the problem or at least gives some
> > more information in the error log. You may either replace all
> > packages with dpkg or only the /usr/lib/apache2/modules/mod_ssl.so
> > 
> >  file by hand.
> 
> I will try that after my holiday. Note that there were _no_
> additional log entries.

I know. I have added one more log message. Maybe it will help.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794967: zsh: please enhance /etc/zshrc

[Carsten Hey]

Package: zsh
Severity: wishlist

Please enhance /etc/zshrc:

 * Please add some additional keybindings, at least for the emacs keymap:

   - bind PageUp "${terminfo[kpp]}" to history-search-backward

   - bind PageDown "${terminfo[knp]}" to history-search-forward

 The bash like history-search-end magic would be an alternative for
 PageUp and PageDown, but history-search-backward does not require
 running zle -N ...

   - bind BackTabKey "${terminfo[kcbt]}" to reverse-menu-complete

 In terminfo(5), the capname cbt is described as "back tab (P)"
 and kcbt is described as "back-tab key", therefore the suggested
 'BackTabKey' instead of 'BackTab' - even though grml confuses
 people that know terminfo(5) by using 'BackTab' as name.

   - Maybe F1 could invoke run-help?  But then the output of run-help
 w/o arguments should be more useful for new users.

   - Red Hat maps or mapped space to magic-space, I think Debian should
 _not_ do this, but initially I thought that this would be a good
 idea.

 * $key should be unset unless there is a reason for not doing so.

 * (( ${+aliases[run-help]} )) requires the zsh/parameter module.  If,
   in rare cases, possibly involving zsh-static, there is a chance that
   this module is not loaded successfully, you should consider doing
   this instead to remove the alias w/o error message:

 alias run-help=
 unalias run-help


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794968: zsh: please clear console on logout (if recommended config is used)

[Carsten Hey]

Package: zsh
Severity: wishlist

There are more important things that involve less work to do, therefore
this is intended as a low priority wishlist bug.

Please clear console on logout if the recommended config for new users
is used.

This requires:
 * a console_clear (currently part of the bash package) that is not
   completely broken
 * a patched zsh-newuser-install that also installs the file
   /etc/zsh/newuser.zlogout.recommended if available
 * a newuser.zlogout.recommended that handles everything console_clear
   does not and should not handle, for example, don't clear the console
   if $0 is -su (such a file is currently available in a bug report
   against bash and might in future be part of bash)
 * doko relicensing a trivial shell snippet used in /etc/.bash_logout
   (this shouldn't be a problem)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794966: RFS: python-dtcwt/0.10.1+dfsg1-2

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-dtcwt"

* Package name: python-dtcwt
  Version : 0.10.1+dfsg1-2
  Upstream Author : Rich Wareham 
* URL : https://github.com/rjw57/dtcwt
* License : BSD
  Section : science

It builds those binary packages:

python-dtcwt - Dual-Tree Complex Wavelet Transform library for Python 2
python-dtcwt-doc - Documentation of the Python implementation of the DT-CWT
python3-dtcwt - Dual-Tree Complex Wavelet Transform library for Python 3

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


http://mentors.debian.net/package/python-dtcwt

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

dget -x 
http://mentors.debian.net/debian/pool/main/p/python-dtcwt/python-dtcwt_0.10.1+dfsg1-2.dsc


Changes since the last upload:

  * Make build reproducible. (Closes: #794005)
Thanks to Chris Lamb for providing the patch.

Best regards,
Ghislain Vaillant


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794916: aptitude is uninstallable

[Andreas Beckmann]

Control: notfixed -1 0.7-1+b1
Control: found -1 0.7-1
Control: close -1

fixed-in-NMU is not representable in the BTS

Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794964: is normal

[Santiago Vila]

severity 794964 normal
tags 794964 + wontfix
thanks

Thorsten, your work on the m68k arch is really amazing, but I don't
think that submitting "grave" bugs for bugs that only happen in m68k
is a good idea at all.

By definition, a bug which represent a problem only for unreleased
architectures may not be release critical.

I'll be happy to add a versioned B-D in the next upload just in case
it helps, but if it does not help, then I will do nothing and this is
a wontfix, because I don't consider it reasonable at all.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#793939: [RFR] templates://publicfile-installer/{templates}

[Justin B Rye]

Christian PERRIER wrote:
> Rationale:
> --- publicfile-installer.old/debian/templates 2015-07-29 08:21:48.490182705 
> +0200
> +++ publicfile-installer/debian/templates 2015-07-29 13:44:58.140605903 
> +0200
> @@ -1,13 +1,16 @@
>  Template: publicfile-installer/build
>  Type: boolean
>  Default: false
> -_Description: Do you want to get and build publicfile now?
> - Choose wether publicfile should be downloaded and build now.
> +_Description: Download and build publicfile now?
> 
> Matter of taste, but I usually tend to avoid "do you want "

Me too.
 
> + Please choose wether publicfile should be downloaded and built now.
> + .
> 
> We often use "Please " so let's be consistent among packages?

You caught the wrong past tense, but a typo has snuck past you there.
"Whether" is a questionword, "wether" is a castrated ram.
 
>   If you choose not to do this now, you can perform the actions manually 
> later,
> - by running the 'get-publicfile' command (as a normal user, not root) and
> + by running the "get-publicfile" command (as an unprivileged user, not
> + as root) and
>   following the instructions.
> 
> The debian-l10n-english housestyle uses double quptes rather than
> simple quotes We also tend to suggest using
> privileged/unprivileged instead of "normal".

Because normal people can be sysadmins too, in theory.

>   .
> - If you choose to get and build now, both these actions will be performed
> - as root.  For security-aware sites, this might be not appropriate.
> - Once the software has been build, run the 'install-publicfile' command
> + If you choose to download and build publicfile now, both these actions will 
> be performed
> + as root. For security-aware sites, this might be not appropriate.
> + .
> + Once the software has been built, run the "install-publicfile" command
>   (as root) to install the package.
> 
> Be consistent with other changes.
> 

It might simplify the explanation if we reshuffled it slightly:

   _Description: Download and build publicfile now?
Please choose whether publicfile should be downloaded and built now.
.
Alternatively you can do it manually later by running the command
"get-publicfile" and following the instructions. This has the
advantage that it can be run as an unprivileged user, avoiding the
security risks of performing the build as root.
.
Once the software has been built, run the command "install-publicfile"
(as root) to install the package.

But why does it need a special script to install a package?  (Goes and
looks...)  Yipe!  It just checks I'm root and then runs

  dpkg -i /tmp/publicfile-installer/publicfile*_*.deb

Does the build really leave its output in a predictable location in a
world-writable directory?  (Checks)  Yes, so if my evil kid brother
has created a /tmp/publicfile-installer/publicfile_0.52-0_amd64.deb,
the build-script will happily dump its .deb alongside it.  Then when I
run "sudo install-publicfile" it'll install the bogus package first,
executing its install-scripts as root.

This hardly seems appropriate for a package where the main selling
point is that it's secure.  At the very least build-publicfile should
use a *verbose* cp so that it tells me where it has put the output
.deb!  And if it's so hard to remember "sudo dpkg -i foo.deb", it
could finish with a reminder!

In the control file:

> --- publicfile-installer.old/debian/control   2015-07-29 08:21:48.490182705 
> +0200
> +++ publicfile-installer/debian/control   2015-08-08 08:29:31.921329907 
> +0200
>  Depends: wget, debhelper, fakeroot, ${misc:Depends}

And not build-essential?

> +Description: installer package for the publicfile HTTP and FTP server
> + Publicfile is an HTTP and FTP server, written by Daniel J. Bernstein in
> + 1999; it didn't change a lot after that. Modern features are not
> + supported. However, if you're looking for a small, simple and secure
>   webserver, which integrates with the runit and daemontools UNIX service
>   managers, publicfile will suit your needs.
>   .
>   This installer package downloads the publicfile .tar.gz file from
>   the upstream website, combines it with Debian packaging information
>   from the package maintainer's website; then builds a publicfile Debian
>   package, and installs that.  When installing this installer package,
>   one is given the option to postpone downloading and installing
>   publicfile.

There are a few other trivial issues, but I wouldn't have bothered
except that there's quite a lot missing - such as the point of the
exercise.  Why does publicfile need an installer?  Why isn't it an
ordinary package in main like DJB's qmail?  Okay, maybe the reader
might vaguely remember that DJB is virulently opposed to sane software
licenses, but then didn't he change his mind and declare all his
software public domain?  The answer turns out to be: not *quite* all.

Also, it's not clear whether this download-and-build is a one-off
(after which the installer becomes 

Bug#794964: gettext: must redo libstdc++ ABI transition because not done right

[Santiago Vila]

On Sat, Aug 08, 2015 at 07:25:14PM +, Thorsten Glaser wrote:
> Source: gettext
> Version: 0.19.5.1-1
> Severity: grave
> Justification: renders package unusable
> 
> I just noticed we already have libasprintf0v5 in Debian/m68k unstable.
> This cannot be, because we haven’t started the GCC 5 transition yet (I
> know because src:gcc-defaults is currently building on one of my boxen
> and src:gcc-5 has just finished building).
> 
> Evidently, src:gettext was uploaded, with the new binary package name,
> without adding a versioned B-D on gcc (>= 4:5).
> 
> This means that src:gettext must re-do the transition after adding the
> versioned B-D, changing soname and binary package name yet again.

I waited for gcc 5 to be the default as announced by Matthias on 
-devel-announce.

While I agree that a B-D would have been nice for you and the m68k arch,
renaming the packages again is not reasonable for two reasons:

* m68k is not a released architecture.
* There is absolutely no debian package depending on either the old or the new 
library.


So, instead of doing extra work for nothing, can you tell me what kind
of problem will the m68k architecture have if you just trigger
an m68k-binary-only NMU of gettext once you have gcc 5 in unstable?

Also, while we are at it: Considering that there has not been an
emphasis on B-D in the various announcement I've seen about this,
is it really a good idea to have the override file for m68k to be
the same as the one for the released architectures?

(Being it different, you would have detected this problem before
the package arrived at unstable).


[ Cc:ing Matthias ]


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794954: usbutils: update usbutils to git master and get new usbids please

[Aurelien Jarno]

On 2015-08-08 21:49, shirish शिरीष wrote:
> Package: usbutils
> Version: 1:007-2
> Severity: wishlist
> 
> Dear Maintainer,
> It took me a long time to figure out what usb devices I have because
> both usbutils and especially usbids were pretty outdated. Please
> update the same from :-
> 
> https://git.kernel.org/cgit/linux/kernel/git/gregkh/patches.git
> 
> link is from/via http://www.linux-usb.org/

Well it's not that outdated, it just dates from before the Jessie
freeze. I haven't updated it in sid yet, as this new version of usbutils
actually get rids of usb.ids in favor of using the systemd database. I 
still have to see the consequences this new version will have for
non-Linux ports and non-systemd users.

I'll upload a new version which justs updates usb.ids for now. In the
meantime you can run the script /usr/sbin/update-usbids to just fetch
the latest version of usb.ids, without having to wait for a new
package.

Aurelien

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


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794205: closed by Eriberto Mota (reply to eribe...@debian.org) (Re: vokoscreen: does not work with ffmpeg Permission denied error)

[Eriberto Mota]

reopen 794205
severity 794205 important
tags 794205 moreinfo
thanks


Done, as you wish. I look forward to receive news from you soon.

Regards,

Eriberto


2015-08-08 16:41 GMT-03:00 Dominik George :
>>As I said, the bug was closed to avoid an unnecessary remove from
>>testing.
>
> This is entirely wrong.
>
> Marking a bug as done is a clear statement that it was fixed. This is not 
> true in this case.
>
> You could have set...
>
> severity -1 important
> tags -1 + moreinfo
>
> ...to achieve what you claim you wanted to achieve without getting rude 
> towards a contributor.
>
> -nik


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794205: closed by Eriberto Mota (reply to eribe...@debian.org) (Re: vokoscreen: does not work with ffmpeg Permission denied error)

[Dominik George]

>As I said, the bug was closed to avoid an unnecessary remove from
>testing.

This is entirely wrong.

Marking a bug as done is a clear statement that it was fixed. This is not true 
in this case.

You could have set...

severity -1 important
tags -1 + moreinfo

...to achieve what you claim you wanted to achieve without getting rude towards 
a contributor.

-nik


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794965: Dash fail to remove trailing spaces.

[Bize Ma]

Package: dash
Version: dash: 0.5.7-3

This two commands:

dash -c 'echo "a b " | { read var; echo "<$var>"; }'
bash -c 'echo "a b " | { read var; echo "<$var>"; }'

produce:






So, dash is not ignoring trailing spaces of values as defined in POSIX
(and most shells do):

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html


   -  The remaining fields and their delimiters, *with trailing **IFS
white space ignored*


Even with a confirmed default value of IFS:

$ printf "%s" "$IFS"|xxd -p

20090a

Bug#794478: Fwd: Bug#794478: [Security][RC] RFS: imagemagick/8:6.8.9.9-5+deb8u1

[Bastien ROUCARIES]

Dear security team

  I am looking for a sponsor for my package "imagemagick" about a
security fix and I am waiting for your green light.. Fixing  #770009
help buildd but is not a security fix (but nevertheless it will help
the infrastructure).
The other ones are DOS

  Changes since the last upload:

   * Fix build on mips by printing progress (Closes: #770009).
   * Fix four security bugs:
 - A DOS on specially crafted MIFF file (TEMP-000-FDAC72).
 - A DOS on specially crafted Vicar file (TEMP-000-EEF23C).
 - A DOS on specially crafted HDR file (TEMP-000-7C079F).
 - A DOs on specially crafted PDB file (TEMP-000-2FC21E).

Joined debdiff

I Plan to upload oldstable and oldoldstable version, fixing the same
bug and closing all security backlog

  Regards,
   bastien roucaries


debdiff
Description: Binary data

Bug#794964: gettext: must redo libstdc++ ABI transition because not done right

[Thorsten Glaser]

Source: gettext
Version: 0.19.5.1-1
Severity: grave
Justification: renders package unusable

I just noticed we already have libasprintf0v5 in Debian/m68k unstable.
This cannot be, because we haven’t started the GCC 5 transition yet (I
know because src:gcc-defaults is currently building on one of my boxen
and src:gcc-5 has just finished building).

Evidently, src:gettext was uploaded, with the new binary package name,
without adding a versioned B-D on gcc (>= 4:5).

This means that src:gettext must re-do the transition after adding the
versioned B-D, changing soname and binary package name yet again.

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

Kernel: Linux 4.0.0-2-m68k
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794205: closed by Eriberto Mota (reply to eribe...@debian.org) (Re: vokoscreen: does not work with ffmpeg Permission denied error)

[Eriberto]

Dominik,

As I said, the bug was closed to avoid an unnecessary remove from
testing. This is a new situation. So, show me how to reproduce the
problem and I will reopen and solve your problem in less than one week
(the upstream is quick).

Regards,

Eriberto


2015-08-08 16:11 GMT-03:00 Dominik George :
>>Attacking me isn't going to solve your problem. Note that you are
>>accusing me but you didn't reply my last message.
>
> Sure, I was tuning in on you. Your close mail was accusing and insulting. 
> That's how things are - you communicated that I am talking nonsense, am 
> unresponsive and in general, what you do not see does not exist.
>
> I should have stopped caring about vokoscreen before spending hours 
> explaining open source to upstream a few years ago anyway.
>
> -nik


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794963: libnet-xmpp-perl: "Insecure dependency in eval (...) at /usr/share/perl5/Net/XMPP/Protocol.pm line 1007."

[Axel Beckert]

Control: tag -1 + moreinfo

Hi Christoph,

Axel Beckert wrote:
> Christoph Biedl wrote:
> > after upgrading to jessie, an XMPP client application written in Perl
> > failed to start with
> > 
> > | Insecure dependency in eval while running setuid at 
> > /usr/share/perl5/Net/XMPP/Protocol.pm line 1007.

Can you give me some example code which triggers this issue so that I
can test if it's fixed with the new upstream release? The upstream
test suite of the upstream release currently in Debian doesn't seem to
trigger such warnings.

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794205: closed by Eriberto Mota (reply to eribe...@debian.org) (Re: vokoscreen: does not work with ffmpeg Permission denied error)

[Dominik George]

>Attacking me isn't going to solve your problem. Note that you are
>accusing me but you didn't reply my last message.

Sure, I was tuning in on you. Your close mail was accusing and insulting. 
That's how things are - you communicated that I am talking nonsense, am 
unresponsive and in general, what you do not see does not exist.

I should have stopped caring about vokoscreen before spending hours explaining 
open source to upstream a few years ago anyway.

-nik


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794963: libnet-xmpp-perl: "Insecure dependency in eval (...) at /usr/share/perl5/Net/XMPP/Protocol.pm line 1007."

[Axel Beckert]

Hi,

Christoph Biedl wrote:
> after upgrading to jessie, an XMPP client application written in Perl
> failed to start with
> 
> | Insecure dependency in eval while running setuid at 
> /usr/share/perl5/Net/XMPP/Protocol.pm line 1007.
> 
> The offending line
> 
> | eval "\$obj = new $NEWOBJECT{$tag}(\$tree);";
> 
> isn't something I'd call good Perl style. Replacing it with
> 
> | eval { $obj = new {$NEWOBJECT{$tag}}($tree); };
> 
> made the woes go away. This code still exists in stretch.

There is a new upstream release available which also changed that
code, but differently:

https://metacpan.org/source/DAPATRICK/Net-XMPP-1.05/lib/Net/XMPP/Protocol.pm#L1302

| eval "\$obj = $NEWOBJECT{$tag}->new(\$tree);";

Likely the relevant changelog entry is this one:

| Replace indirect object notation with direct invocation notation

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794205: closed by Eriberto Mota (reply to eribe...@debian.org) (Re: vokoscreen: does not work with ffmpeg Permission denied error)

[Eriberto]

Hi Dominik,

Attacking me isn't going to solve your problem. Note that you are
accusing me but you didn't reply my last message.

The bug was closed because is a clear problem in your side and, today,
I received a notice for autorm from testing (and I am sure that the
package is working fine). So, make your problem reproducible and I and
the upstream (very active) are going solve the issue.

I maintain several packages, all updated (see my DDPO). My work is
very seriously. So, please, be polite and I will help you.

A closed bug will not destroy your life. You can reopen or file a new
bug, after check your environment and make the issue reproducible.
Think to do better.

Regards,

Eriberto



2015-08-08 15:45 GMT-03:00 Dominik George :
> Hi,
>
> this is incredible.
>
> There are people who have a job and a life and all that. Giving more than a 
> few days to set up a new system for testing and testing for the bug seems to 
> be granted.
>
> Maybe you should not be a Debian maintainer at all, but just reopening the 
> bug until we found out what is going on might be a good start.
>
> -nik


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#571054: Divert /sbin/initctl to fix start(8) in lucid postinsts.

[Steve Langasek]

Control: reassign -1 pbuilder

This bug was reassigned to upstart, but that is not correct.  The problem
described here is that a bug in the version of *debhelper* in Ubuntu Lucid
caused maintainer scripts for packages that shipped upstart jobs to
incorrectly call 'start' instead of the policy-defined 'invoke-rc.d'
interface.  This was a bug in debhelper in an old version of *Ubuntu*. 
There is nothing that the *Debian* *upstart* package can do to work around
this bug.

The bug was filed against pbuilder, as the tool managing the chroots on top
of the Debian system, requesting that 'start' be diverted in order to give
an effect similar to policy-rc.d.  You might close this bug as wontfix, but
it's nothing that the Debian upstart package can help with.

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


signature.asc
Description: Digital signature

Bug#794955: gperf: Embedded code copy with missing copyright

[Hilko Bengen]

Control: tag -1 moreinfo

> Your packages contains an embedded code copy of texi2html which is
> copyright Lionel Cons and others and is licensed under the GPL and
> Creative Commons Attribution-ShareAlike license. This information is
> missing from debian/copyright of gperf and is thus a violation of policy
> §4.5.

Can you tell me a reliable source for that copyright information?
Online, I have only found old (pre-GNU) versions such as 1.52 with a
weird copyright notice, but no license -- and later versions distributed
by the FSF under the GPL2.

> I found this bug while working on the reproducible builds project [1] to
> make texi2html produce reproducible output.

Thank you, the effort is very much appreciated from my part.

>  1. remove the embedded code copy [2] and build-depend on texi2html
> (this would also make policy §4.13 happy). I would prefer this
> solution and would supply you with a patch if you want. Your package
> would then automatically become reproducible.
>
>  2. keep the embedded code copy and amend your debian/copyright. In this
> case I would open another bug so that your embedded copy of
> texi2html is patched to produce reproducible output.

I'd like to amend debian/copyright, but also change the Makefile so that
the Debian-provided texi2html is used instead. (I did verifiy that it
still builds).

Cheers,
-Hilko


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794945: drivers: Sense Key Medium Error in 8.1 not in 7 for same media

[Ernest Sales]

On ds, 2015-08-08 at 19:56 +0200, Ben Hutchings wrote:
> [...]
> 
> Have you installed libdvdcss?

[...]$ dpkg --list libdvdcss2
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  libdvdcss2 1.2.13-0 amd64library designed for
accessing DV
[...]$ dpkg --status libdvdcss2
Package: libdvdcss2
Status: install ok installed
Priority: extra
Section: libs
Installed-Size: 85
Maintainer: Kubuntu Developers 
Architecture: amd64
Source: libdvdcss
Version: 1.2.13-0
Depends: libc6 (>= 2.7)
Description: library designed for accessing DVDs
 libdvdcss is a simple library designed for accessing DVDs like a
 block device without having to bother about the decryption.
Homepage: http://download.videolan.org/
Original-Maintainer: Jonathan Riddell 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794959: kwin-x11: kwin crashes on startup

[Diederik de Haas]

Downgrade the breeze packages to the version in testing will likely fix it.
See also #794581, #794809 and #794573


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

Bug#794963: libnet-xmpp-perl: "Insecure dependency in eval (...) at /usr/share/perl5/Net/XMPP/Protocol.pm line 1007."

[Christoph Biedl]

Package: libnet-xmpp-perl
Version: 1.02-4
Severity: normal
Tags: patch

Dear Maintainer,

after upgrading to jessie, an XMPP client application written in Perl
failed to start with

| Insecure dependency in eval while running setuid at 
/usr/share/perl5/Net/XMPP/Protocol.pm line 1007.

The offending line

| eval "\$obj = new $NEWOBJECT{$tag}(\$tree);";

isn't something I'd call good Perl style. Replacing it with

| eval { $obj = new {$NEWOBJECT{$tag}}($tree); };

made the woes go away. This code still exists in stretch.

Christoph

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

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


signature.asc
Description: Digital signature

Bug#794915: revised source package uploaded to mentors

[Ghislain Vaillant]

On 08/08/15 15:27, Gianfranco Costamagna wrote:

There still are some copyright issues: e.g.

licensecheck  cmake/FindTBB.cmake
cmake/FindTBB.cmake: MIT/X11 (BSD like)

seems that you missed one :)


No problem, I am the one supposed to get that right. I did not realize 
that licensecheck ignores *.cmake files by default.


Actually both cmake/FindTBB.cmake and cmake/FindEigen.cmake had 
different copyright information. They have been added to d/copyright.


I have uploaded another version. Hopefully, it will be the one.

Cheers,
Ghis


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794205: closed by Eriberto Mota (reply to eribe...@debian.org) (Re: vokoscreen: does not work with ffmpeg Permission denied error)

[Dominik George]

Hi,

this is incredible.

There are people who have a job and a life and all that. Giving more than a few 
days to set up a new system for testing and testing for the bug seems to be 
granted.

Maybe you should not be a Debian maintainer at all, but just reopening the bug 
until we found out what is going on might be a good start.

-nik


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#791081: jags: library transition may be needed when GCC 5 is the default

[Dirk Eddelbuettel]

On 8 August 2015 at 09:03, Dirk Eddelbuettel wrote:
| 
| On 8 August 2015 at 14:34, Jonathan Wiltshire wrote:
| | On 8 August 2015 at 13:08, Julien Cristau wrote:
| | > However, instead of being properly split out as required by
| | > policy, the libraries are shipped as part of the 'jags' binary package,
| | > which makes this a bit of a pain.
| | 
| | On Sat, Aug 08, 2015 at 06:50:44AM -0500, Dirk Eddelbuettel wrote:
| | > I don't see the need for splitting the libraries out of the jags
| | > package. What am I missing?
| | 
| | Making it not be "a bit of a pain" in the future.
| 
| I hear you "in theory", but "in practice" I know the upstream author very
| well, and have a reasonable idea of how this is used (in Bayesian stats
| around R in the large sense).
| 
| This isn't really a library to link against -- all statistical analysis uses
| jags the binary.
| 
| But I look into it.  The debian/rules is (apart from some overrides) just
| 
| %:
|   dh $@
| 
| so I should get by with some simple-enough debian/*.files magic.

Abort.  I just wasted a few hours on this (luckily while doing other
stuff). I am not going to split libjags, libjags-dev off but simply rebuild
depending on g++ (>= 4:5.2).

Chris can then depend on this version, and that is all that there is to the
jags part of the g++5 transition.

Dirk

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#794962: wheezy-pu: package openafs/1.6.1-3+deb7u3

[Benjamin Kaduk]

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

The security update to the linux kernel (3.2.65-1+deb7u2) changed the
KPI by moving d_alias into the d_u union, which causes subsequent
(re)build attempts of the openafs kernel module to fail.  (Existing
openafs kernel modules continued to work due to clever work by
the kernel maintainer.)  This situation was maintained without great
incident until the upload of openafs 1.6.1-3+deb7u3 to the security
repo, which cause most people to attempt to build a new openafs kernel
module and fail.  Two grave bugs (780865 and 794224) reflect that situation.

We had to deal with this problem for jessie back in February, but I
didn't have enough time to fix it for wheezy then.  The jessie updates
also included a fix for a bug causing potential data corruption in
mmapped files; I included the fix for that (778851) in this w-p-u as well.

A debdiff between deb7u3 (from the security repo) and my proposed deb7u4
is attached.

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru openafs-1.6.1/debian/changelog openafs-1.6.1/debian/changelog
--- openafs-1.6.1/debian/changelog	2015-07-30 06:27:51.0 -0400
+++ openafs-1.6.1/debian/changelog	2015-08-08 14:23:47.0 -0400
@@ -1,3 +1,12 @@
+openafs (1.6.1-3+deb7u4) wheezy-proposed-updates; urgency=medium
+
+  * Fix the kernel module build when d_alias is in the d_u union
+(Closes: #780865, Closes: #794224)
+to d_alias being a member of the d_u union.
+  * Fix potential file corruption of mmapped files (Closes: #778851)
+
+ -- Benjamin Kaduk   Sat, 08 Aug 2015 14:19:04 -0400
+
 openafs (1.6.1-3+deb7u3) wheezy-security; urgency=high
 
   * Apply upstream security patches from the 1.6.13 release (thanks to
diff -Nru openafs-1.6.1/debian/patches/debian-changes openafs-1.6.1/debian/patches/debian-changes
--- openafs-1.6.1/debian/patches/debian-changes	2015-07-30 06:34:05.0 -0400
+++ openafs-1.6.1/debian/patches/debian-changes	2015-08-08 14:27:33.0 -0400
@@ -8,6 +8,16 @@
 
 For full commit history and separated commits, see the packaging Git
 repository.
+--- openafs-1.6.1.orig/acinclude.m4
 openafs-1.6.1/acinclude.m4
+@@ -793,6 +793,7 @@ case $AFS_SYSNAME in *_linux* | *_umlinu
+ 		 AC_CHECK_LINUX_STRUCT([backing_dev_info], [name],
+    [backing-dev.h])
+ 		 AC_CHECK_LINUX_STRUCT([ctl_table], [ctl_name], [sysctl.h])
++		 AC_CHECK_LINUX_STRUCT([dentry], [d_u.d_alias], [dcache.h])
+ 		 AC_CHECK_LINUX_STRUCT([inode], [i_alloc_sem], [fs.h])
+ 		 AC_CHECK_LINUX_STRUCT([inode], [i_blkbits], [fs.h])
+ 		 AC_CHECK_LINUX_STRUCT([inode], [i_blksize], [fs.h])
 --- openafs-1.6.1.orig/configure.ac
 +++ openafs-1.6.1/configure.ac
 @@ -50,14 +50,20 @@ MAKE_KRB5="#"
@@ -47,6 +57,301 @@
   RRA_LIB_KRB5_RESTORE])
  AC_SUBST([BUILD_KRB5])
  AC_SUBST([MAKE_KRB5])
+--- openafs-1.6.1.orig/src/afs/LINUX/osi_compat.h
 openafs-1.6.1/src/afs/LINUX/osi_compat.h
+@@ -27,6 +27,10 @@
+ # endif
+ #endif
+ 
++#if defined(STRUCT_DENTRY_HAS_D_U_D_ALIAS)
++# define d_alias d_u.d_alias
++#endif
++
+ #ifndef HAVE_LINUX_DO_SYNC_READ
+ static inline int
+ do_sync_read(struct file *fp, char *buf, size_t count, loff_t *offp) {
+--- openafs-1.6.1.orig/src/afs/LINUX/osi_prototypes.h
 openafs-1.6.1/src/afs/LINUX/osi_prototypes.h
+@@ -79,6 +79,9 @@ extern void osi_VM_FlushPages(struct vca
+ extern void osi_VM_Truncate(struct vcache *avc, int alen,
+ 			afs_ucred_t *acred);
+ 
++/* osi_vcache.c */
++extern void osi_ResetRootVCache(afs_uint32 volid);
++
+ /* osi_vfsops.c */
+ extern void vattr2inode(struct inode *ip, struct vattr *vp);
+ extern int afs_init_inodecache(void);
+--- openafs-1.6.1.orig/src/afs/LINUX/osi_vcache.c
 openafs-1.6.1/src/afs/LINUX/osi_vcache.c
+@@ -13,6 +13,8 @@
+ #include "afs/sysincludes.h"/*Standard vendor system headers */
+ #include "afsincludes.h"/*AFS-based standard headers */
+ 
++#include "osi_compat.h"
++
+ int
+ osi_TryEvictVCache(struct vcache *avc, int *slept, int defersleep) {
+ int code;
+@@ -139,3 +141,64 @@ osi_PostPopulateVCache(struct vcache *av
+ vSetType(avc, VREG);
+ }
+ 
++/**
++ * osi_ResetRootVCache - Reset the root vcache
++ * Reset the dentry associated with the afs root.
++ * Called from afs_CheckRootVolume when we notice that
++ * the root volume ID has changed.
++ *
++ * @volid: volume ID for the afs root
++ */
++void
++osi_ResetRootVCache(afs_uint32 volid)
++{
++struct vrequest *treq = NULL;
++struct vattr vattr;
++cred_t *credp;
++struct dentry *dp;
++struct vcache *vcp;
++struct inode *root = AFSTOV(afs_globalVp);
++
++afs_rootFid.Fid.Volume = volid;
++afs_rootFid.Fid.Vn