Bug#758853: gpsbabel: Unknown option '-c'
Package: gpsbabel Version: 1.5.0-3 Severity: normal Dear Maintainer, gpsbabel option '-c' doesn't work anymore. You cannot select character set for next operation. All my old scripts using this option abort with error: Unknown option '-c' Replacing gpsbabel with version 1.4 solve this problem, but going back is no solution. -- System Information: Debian Release: jessie/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-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 Versions of packages gpsbabel depends on: ii libc6 2.19-7 ii libgcc1 1:4.9.1-4 ii libqtcore44:4.8.6+git49-gbc62005+dfsg-1 ii libstdc++64.9.1-4 ii libusb-0.1-4 2:0.1.12-24 ii zlib1g1:1.2.8.dfsg-1 Versions of packages gpsbabel recommends: ii gpsbabel-doc 1.5.0-3 gpsbabel 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#758854: etckeeper pre-commit ignores .hgignore
Package: etckeeper Version: 1.12 I'm tracking whole root path / and have a .hgignore that ignores everything. That lets me add files only explicitly allover / like /etc /usr/local or even /.hg/hgignore.local The pre-commit currently runs a find on / which does not return for long time. Please take care of the ignore file and only run pre-commit on not ignored files. As for /etc/etckeeper/pre-commit.d/20warn-problem-files I already disabled the expensive check by moving the $AVOID check earlier: if [[ -n $AVOID_SPECIAL_FILE_WARNING ]]; then if [ $VCS = bzr ] || [ $VCS = darcs ]; then ... But then 30store-metadata has the same issue with find. I'm not sure how to solve it, maybe run the check only on files in $(hg manifest) that are already tracked. https://forums.gentoo.org/viewtopic-p-7604234.html#7604234 Best regards, Massimo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758855: openlp: presentation plugin is 'active' but config dialog says 'not available'
Package: openlp Version: 2.0.4-1 Severity: normal Dear Maintainer, Using OpenLP with Libre Office Impress presentation. I activated all plugins except remote control during first run wizard. But in Presentation selection of 'Media Manager', when I choose Open, there is nothing in the list of Files of type:, it just has: Presentations () When I go to 'Settings-Configure OpenLP' and select 'Presentations', I see under available controllers three check boxes, all checked but grey'd out, with the name followed by '(unavailable)'. I've searched for information on installing plugins, but haven't yet found anything useful. This installation is running under Openbox VM running on Debian 7.6 I downloaded the BD iso 1 for installing the base environment and GUI, but had to manually set up /etc/apt/sources.list with jessie to find OpenLP. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openlp depends on: ii libjs-jquery 1.7.2+dfsg-3 ii python-beautifulsoup 3.2.1-1 ii python-chardet2.2.1-2 ii python-enchant1.6.6-1 ii python-lxml 3.3.5-1+b1 ii python-mako 1.0.0-1 ii python-migrate0.9.1-1 ii python-qt44.11.1+dfsg-1 ii python-qt4-gl 4.11.1+dfsg-1 ii python-qt4-phonon 4.11.1+dfsg-1 ii python-sqlalchemy 0.9.7-1 ii python-sqlite 1.0.1-11 pn python:anynone Versions of packages openlp recommends: ii python-xdg 0.25-4 openlp 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#648240: Cause and workaround
I found the cause and a workaround for this bug.
The cause is, that blanking the display and switching off backlight is
done through 2 separate processes: gnome-screensaver blanks the display
and gnome-powermanager switches backlight off. These two are in conflict
when happening at the same time.
One workaround is to set the backlight off timeout higher than the
lock timeout.
Another workaround is the following script running in background, which
monitors dbus messages from screensaver and switches backlight off when
screensaver is activated.
##!/bin/sh
function activated ()
{
xset dpms force off
}
function deactivated ()
{
return
}
dbus-monitor --session type='signal',interface='org.gnome.ScreenSaver'
|
( while read X; do
case $X in
boolean true)
activated;;
boolean false)
deactivated;;
esac
done
)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672742: [tex-live] Bug#672742: (fwd) Bug#672742: /usr/bin/xetex: xetex fails to compile documents with defaultfontfeatures set
found 672742 2014.20140528.34243-5 stop On 28.05.13 Arthur Reutenauer (arthur.reutena...@normalesup.org) wrote: Hi, About the Polyglossia bug: I still don't know exactly what's happening, but I am now reasonably convinced that it happens within Polyglossia's code (even though it's provoked by issuing fontspec commands), and that defining \cyrillicfont will reliably work around the problem -- see attachments. To be continued for a proper bugfix. Just noticed that the issue is stuill there in TL 2014. Hilmar -- sigmentation fault signature.asc Description: Digital signature
Bug#758856: apt-build: repository error when multiarch is enabled
Package: apt-build Version: 0.12.44 Severity: important Dear Maintainer, When installing apt-build, it automatically adds the repository to sources.list.d/, but with multiarch apt spits out errors on the repository. the default entry for apt-build.list is: deb file:/var/cache/apt-build/repository apt-build main when modified to: deb [arch=amd64] file:/var/cache/apt-build/repository apt-build main this takes care of the errors (amd64 being `dpkg --print-architecture') -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15-10.dmz.1-liquorix-amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apt-build depends on: ii apt1.0.6 ii apt-utils 1.0.6 ii debconf [debconf-2.0] 1.5.53 ii devscripts 2.14.6 ii dpkg 1.17.13 ii dpkg-dev 1.17.13 ii g++4:4.9.1-3 ii gcc4:4.9.1-3 ii libappconfig-perl 1.66-1 ii libapt-pkg-perl0.1.29+b2 ii libc6 2.19-9 ii perl 5.20.0-4 Versions of packages apt-build recommends: ii build-essential 11.7 ii fakeroot 1.20.1-1.1 apt-build suggests no packages. -- debconf information: * apt-build/olevel: Medium * apt-build/build_dir: /var/cache/apt-build/build apt-build/arch_alpha: native * apt-build/make_options: -j3 apt-build/archtype: native * apt-build/repository_dir: /var/cache/apt-build/repository apt-build/arch_arm: native * apt-build/options: * apt-build/arch_amd64: native apt-build/arch_amd: native apt-build/arch_intel: native apt-build/arch_sparc: native * apt-build/add_to_sourceslist: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755154: vlc cache gen should happen at runtime, not buildtime
Le 2014-08-22 08:25, Harald Sitter a écrit : That is one good reason to generate the cache at build time, where any problem can be detected early on. Crashing during dpkg postinst script is much worse. || true? Then there will be no cache, and you are not solving the problem you want to solve. I fail to see how exactly the additions could make the maintainer scripts fail to be honest, other than having a broken cache-gen which surely is the sign of a much deeper problem that should not have gotten beyond build time to begin with. Experience has shown that changes to certain libraries causes the cache generation to crash, and the maintainers of those libraries do not test against VLC before uploading to Debian. I mean glib, gobject, Qt, GL, libav to name the obvious ones... -- Rémi Denis-Courmont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758858: autopkg tests fail
Package: src:planet-venus Version: 0~git9de2109-3 Tags: patch the autopkg tests fail, missing test dependency on python-xslt1. plus the build-dependency on python-support is obsolete. test log at http://ci.debian.net/data/packages/unstable/amd64/p/planet-venus/20140821_051130.autopkgtest.log patch at http://launchpadlibrarian.net/182935310/planet-venus_0~git9de2109-3_0~git9de2109-3ubuntu1.diff.gz this fixes four xslt related failures, one is remaining: == ERROR: test_foaf_document (tests.test_foaf.FoafTest) -- Traceback (most recent call last): File /tmp/adt-run.n5M0Rc/build.lSO/planet-venus-0~git9de2109/tests/test_foaf.py, line 61, in test_foaf_document foaf2config(test_foaf_document, self.config) File /tmp/adt-run.n5M0Rc/build.lSO/planet-venus-0~git9de2109/planet/foaf.py, line 61, in foaf2config model = load_model(rdf, section) File /tmp/adt-run.n5M0Rc/build.lSO/planet-venus-0~git9de2109/planet/foaf.py, line 31, in load_model model = Model() File /usr/lib/python2.7/dist-packages/RDF.py, line 687, in __init__ storage = MemoryStorage() File /usr/lib/python2.7/dist-packages/RDF.py, line 1589, in __init__ options_string = options_string) File /usr/lib/python2.7/dist-packages/RDF.py, line 1536, in __init__ args['storage_name'], args['name'], args['options_string']) RedlandError: 'XML parser error: Document is empty' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755154: vlc cache gen should happen at runtime, not buildtime
On Fri, Aug 22, 2014 at 9:14 AM, Rémi Denis-Courmont r...@remlab.net wrote: Le 2014-08-22 08:25, Harald Sitter a écrit : That is one good reason to generate the cache at build time, where any problem can be detected early on. Crashing during dpkg postinst script is much worse. || true? Then there will be no cache, and you are not solving the problem you want to solve. True enough, that still beats having a bogus cache 100% of the time though. So, if it is waiting 3 years for someone to do the proper fix vs. getting a not 100% reliable fix now, I'll go out and say that not having stuff explode for the next 3 years is a viable option. All that being said perhaps the more interesting bit is why exactly VLC thinks the cache is invalid to begin with. In particular considering we only have one build that builds with all plugins we have packaged and there are no third party plugins in any package anywhere ever. So the cache should always have a superset of what is available on a system. I fail to see how exactly the additions could make the maintainer scripts fail to be honest, other than having a broken cache-gen which surely is the sign of a much deeper problem that should not have gotten beyond build time to begin with. Experience has shown that changes to certain libraries causes the cache generation to crash, and the maintainers of those libraries do not test against VLC before uploading to Debian. I mean glib, gobject, Qt, GL, libav to name the obvious ones... How does that work? Wouldn't that also defunct the plugins themselves? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757575: transition: libgcrypt20
Hi!
the incompatibility with libgnutls26 can be fixed by using the patch
below. We use this in Gpg4win.
(patches/gnutls-2.12.23/fix-gcrypt-private-api-usage.patch)
Salam-Shalom,
Werner
#! /bin/sh
patch -p0 -l -f $* $0
exit $?
2014-08-06 Andre Heinecke aheine...@intevation.de
* lib/gcrypt/init.c: Use GCRY_THREAD_OPTION_PTHREAD_IMPL macro
instead of defining the gcry_thread_cbs structure itself.
--- lib/gcrypt/init.c.oirg 2014-08-06 11:52:26.858064946 +
+++ lib/gcrypt/init.c 2014-08-06 12:10:31.121726144 +
@@ -32,16 +32,9 @@
/* Functions that refer to the initialization of the libgcrypt library.
*/
-static struct gcry_thread_cbs gct = {
- .option = (GCRY_THREAD_OPTION_PTHREAD | (GCRY_THREAD_OPTION_VERSION 8)),
- .init = NULL,
- .select = NULL,
- .waitpid = NULL,
- .accept = NULL,
- .connect = NULL,
- .sendmsg = NULL,
- .recvmsg = NULL,
-};
+GCRY_THREAD_OPTION_PTHREAD_IMPL;
+
+static struct gcry_thread_cbs gct;
int
gnutls_crypto_init (void)
@@ -53,11 +46,12 @@
if (gnutls_mutex_init != NULL)
{
+#if GCRYPT_VERSION_NUMBER 0x010600
gct.mutex_init = gnutls_mutex_init;
gct.mutex_destroy = gnutls_mutex_deinit;
gct.mutex_lock = gnutls_mutex_lock;
gct.mutex_unlock = gnutls_mutex_unlock;
-
+#endif
gcry_control (GCRYCTL_SET_THREAD_CBS, gct);
}
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758857: buildbot: Unable to upgrade master
Package: buildbot Version: 0.8.9-1 Severity: grave Justification: renders package unusable Dear Maintainer, I'm unable to use buildbot after update, doing: $ buildbot --verbose upgrade-master buildBot-master returns: 014-08-22 08:30:48+0200 [-] Log opened. 2014-08-22 08:30:48+0200 [-] /usr/lib/python2.7/dist-packages/twisted/internet/endpoints.py:30: exceptions.DeprecationWarning: twisted.internet.interfaces.IStreamClientEndpointStringParser was deprecated in Twisted 14.0.0: This interface has been superseded by IStreamClientEndpointStringParserWithReactor. 2014-08-22 08:30:48+0200 [-] /usr/lib/python2.7/dist-packages/twisted/spread/jelly.py:93: exceptions.DeprecationWarning: the sets module is deprecated 2014-08-22 08:30:48+0200 [-] checking basedir 2014-08-22 08:30:48+0200 [-] checking for running master 2014-08-22 08:30:48+0200 [-] WARNING: rotateLength is a string, it should be a number 2014-08-22 08:30:48+0200 [-] Main loop terminated. and exits with 1 If I try to start master, then it says: $ buildbot start buildBot-master Following twistd.log until startup finished.. 2014-08-22 08:56:33+0200 [-] Log opened. 2014-08-22 08:56:33+0200 [-] twistd 14.0.0 (/usr/bin/python 2.7.8) starting up. 2014-08-22 08:56:33+0200 [-] reactor class: twisted.internet.epollreactor.EPollReactor. 2014-08-22 08:56:33+0200 [-] Starting BuildMaster -- buildbot.version: 0.8.9 2014-08-22 08:56:33+0200 [-] Loading configuration from '/home/lkepa/buildBot-master/master.cfg' 2014-08-22 08:56:34+0200 [-] Setting up database with URL 'sqlite:///state.sqlite' 2014-08-22 08:56:34+0200 [-] setting database journal mode to 'wal' 2014-08-22 08:56:34+0200 [-] The Buildmaster database needs to be upgraded before this version of 2014-08-22 08:56:34+0200 [-] buildbot can run. Use the following command-line 2014-08-22 08:56:34+0200 [-] 2014-08-22 08:56:34+0200 [-] buildbot upgrade-master path/to/master 2014-08-22 08:56:34+0200 [-] 2014-08-22 08:56:34+0200 [-] to upgrade the database, and try starting the buildmaster again. You may 2014-08-22 08:56:34+0200 [-] want to make a backup of your buildmaster before doing so. 2014-08-22 08:56:34+0200 [-] Main loop terminated. 2014-08-22 08:56:34+0200 [-] Server Shut Down. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages buildbot depends on: ii adduser 3.113+nmu3 ii dpkg 1.17.10 ii libjs-sphinxdoc 1.2.2+dfsg-2 ii python2.7.8-1 ii python-dateutil 1.5+dfsg-1 ii python-jinja2 2.7.3-1 ii python-migrate0.9.1-1 ii python-sqlalchemy 0.9.7-1 ii python-twisted14.0.0-2 ii python-twisted-core 14.0.0-2 ii python-twisted-web14.0.0-2 ii python-twisted-words 14.0.0-2 Versions of packages buildbot recommends: ii buildbot-slave 0.8.9-1 ii libaprutil1 1.5.3-2 ii python-twisted-mail 14.0.0-2 Versions of packages buildbot suggests: ii git 1:2.1.0~rc1-1 ii subversion 1.8.9-2 -- 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#755154: vlc cache gen should happen at runtime, not buildtime
Le 2014-08-22 10:31, Harald Sitter a écrit : All that being said perhaps the more interesting bit is why exactly VLC thinks the cache is invalid to begin with. In particular considering we only have one build that builds with all plugins we have packaged and there are no third party plugins in any package anywhere ever. So the cache should always have a superset of what is available on a system. Changed file name, file size, or file modification time. I fail to see how exactly the additions could make the maintainer scripts fail to be honest, other than having a broken cache-gen which surely is the sign of a much deeper problem that should not have gotten beyond build time to begin with. Experience has shown that changes to certain libraries causes the cache generation to crash, and the maintainers of those libraries do not test against VLC before uploading to Debian. I mean glib, gobject, Qt, GL, libav to name the obvious ones... How does that work? Wouldn't that also defunct the plugins themselves? VLC would probably crash too, but a crashing program is not as bad and as likely to be reported as a crashing installation procedure. -- Rémi Denis-Courmont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757554: swift-im-2.0+dev6 failes to build on debian/kfreebsd
On Sat, Aug 16, 2014 at 9:32 PM, Yves Fischer yv...@xapek.org wrote: is there any problem with this patch or can I help with anything? Hi Yves, Thanks. I believe this one has been fixed upstream - I'll take a look at it. /K -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758860: /usr/bin/apt-get: [kfreebsd] fails to set terminal properly
Package: apt Version: 1.1~exp2 Severity: normal File: /usr/bin/apt-get Dear Maintainer, When running apt-get, the termimal output is screwed up. Here is an example from installing htop (make sure your e-mail client's font is fixed width): ioctl(TIOCSCTTY) failed for fd: 18 Setting up htop (1.0.3-1) ... root@debian:~# Note that this bug also affects the version in testing. (In fact, apt is the only experimental package on the system at the moment.) -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture kfreebsd-amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image-10\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-headers-10\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-10\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-10\.0-1-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-10\.0-1-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-10\.0-1-amd64$; APT::NeverAutoRemove:: ^gnumach-image-10\.0-1-amd64$; APT::NeverAutoRemove:: ^.*-modules-10\.0-1-amd64$; APT::NeverAutoRemove:: ^.*-kernel-10\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-10\.0-1-amd64$; APT::NeverAutoRemove:: ^linux-tools-10\.0-1-amd64$; APT::VersionedKernelPackages ; APT::VersionedKernelPackages:: linux-image; APT::VersionedKernelPackages:: linux-headers; APT::VersionedKernelPackages:: linux-image-extra; APT::VersionedKernelPackages:: linux-signed-image; APT::VersionedKernelPackages:: kfreebsd-image; APT::VersionedKernelPackages:: kfreebsd-headers; APT::VersionedKernelPackages:: gnumach-image; APT::VersionedKernelPackages:: .*-modules; APT::VersionedKernelPackages:: .*-kernel; APT::VersionedKernelPackages:: linux-backports-modules-.*; APT::VersionedKernelPackages:: linux-tools; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Architectures ; APT::Architectures:: kfreebsd-amd64; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ; APT::Compressor::gzip::Name gzip; APT::Compressor::gzip::Extension .gz; APT::Compressor::gzip::Binary gzip; APT::Compressor::gzip::Cost 2; APT::Compressor::gzip::CompressArg ; APT::Compressor::gzip::CompressArg:: -9n; APT::Compressor::gzip::UncompressArg ; APT::Compressor::gzip::UncompressArg:: -d; APT::Compressor::bzip2 ; APT::Compressor::bzip2::Name bzip2; APT::Compressor::bzip2::Extension .bz2; APT::Compressor::bzip2::Binary bzip2; APT::Compressor::bzip2::Cost 3; APT::Compressor::bzip2::CompressArg ; APT::Compressor::bzip2::CompressArg:: -9; APT::Compressor::bzip2::UncompressArg ; APT::Compressor::bzip2::UncompressArg:: -d; APT::Compressor::xz ; APT::Compressor::xz::Name xz; APT::Compressor::xz::Extension .xz; APT::Compressor::xz::Binary xz; APT::Compressor::xz::Cost 4; APT::Compressor::xz::CompressArg ; APT::Compressor::xz::CompressArg:: -6; APT::Compressor::xz::UncompressArg ; APT::Compressor::xz::UncompressArg:: -d; APT::Compressor::lzma ; APT::Compressor::lzma::Name lzma; APT::Compressor::lzma::Extension .lzma; APT::Compressor::lzma::Binary xz; APT::Compressor::lzma::Cost 5; APT::Compressor::lzma::CompressArg ; APT::Compressor::lzma::CompressArg:: --format=lzma; APT::Compressor::lzma::CompressArg:: -9; APT::Compressor::lzma::UncompressArg ; APT::Compressor::lzma::UncompressArg:: --format=lzma; APT::Compressor::lzma::UncompressArg:: -d; Dir /; Dir::State var/lib/apt/; Dir::State::lists lists/; Dir::State::cdroms cdroms.list; Dir::State::mirrors mirrors/; Dir::State::extended_states extended_states; Dir::State::status /var/lib/dpkg/status; Dir::Cache var/cache/apt/; Dir::Cache::archives archives/; Dir::Cache::srcpkgcache srcpkgcache.bin; Dir::Cache::pkgcache pkgcache.bin; Dir::Etc etc/apt/; Dir::Etc::sourcelist sources.list; Dir::Etc::sourceparts sources.list.d; Dir::Etc::vendorlist vendors.list; Dir::Etc::vendorparts vendors.list.d; Dir::Etc::main apt.conf; Dir::Etc::netrc auth.conf; Dir::Etc::parts apt.conf.d; Dir::Etc::preferences preferences; Dir::Etc::preferencesparts preferences.d; Dir::Etc::trusted trusted.gpg; Dir::Etc::trustedparts trusted.gpg.d; Dir::Bin ; Dir::Bin::methods /usr/lib/apt/methods; Dir::Bin::solvers ; Dir::Bin::solvers:: /usr/lib/apt/solvers; Dir::Bin::dpkg /usr/bin/dpkg;
Bug#758833: mumble-server: Installation failed if the user mumble-server is already created
Hi, Many thanks for your quick answer. The way that MySQL do it works fine. It's in two step, create the group then the user. # creating mysql group if he isn't already there if ! getent group mysql /dev/null; then # Adding system group: mysql. addgroup --system mysql /dev/null fi # creating mysql user if he isn't already there if ! getent passwd mysql /dev/null; then # Adding system user: mysql. adduser \ --system \ --disabled-login \ --ingroup mysql \ --no-create-home \ --home /nonexistent \ --gecos MySQL Server \ --shell /bin/false \ mysql /dev/null fi William On Fri, Aug 22, 2014 at 3:38 AM, Chris Knadle chris.kna...@coredump.us wrote: On Thursday, August 21, 2014 22:37:13 William MARTIN wrote: Package: mumble-server Version: 1.2.3-349-g315b5f5-2.2+deb7u1 Severity: important Dear Maintainer, I am installing mumble on a HA cluster with gluster filesystem. To ensure that all servers have the same id for users and groups on shared folders, i create manually all users/groups needed with custom id (i.e. 1000+). Unfortunately, the mumble-server configure script failed if the user is already created. The create user command failed because the user is already created, so funny ! Issue is in debian rules, file is mumble-server.postinst, on the following line : adduser --system --quiet --home /var/lib/mumble-server --group mumble-server Best regards, William MARTIN I had a look through other packages to see how other maintainers have handled this; most packages do exactly the same thing that the mumble-server.postinst does and simply call 'adduser' and would have the same error. However there were a couple of notable exceptions that I think would handle this case: dnsmasq-base.postinst: if [ $1 = configure ]; then if [ -z `id -u dnsmasq 2 /dev/null` ]; then adduser --system --home /var/lib/misc --gecos dnsmasq \ --no-create-home --disabled-password \ --quiet dnsmasq || true fi exim4-base.postinst: case $1 in configure) if ! getent passwd Debian-exim /dev/null ; then echo 'Adding system-user for exim (v4)' 12 adduser --system --group --quiet --home /var/spool/exim4 \ --no-create-home --disabled-login --force-badname Debian-exim fi wicd-daemon.postinst: case $1 in configure) if [ ! $(getent group netdev) ]; then addgroup --quiet --system netdev fi Out of curiosity let me know which of the three examples above you like most. Whether I can get the fix into the -349 package in Wheezy in a point release is something I'll need to discuss with the Release Team. -- Chris -- Chris Knadle chris.kna...@coredump.us -- William MARTIN http://www.power-lan.com/ 15 rue de la Noé des Yonnières 44850 Saint-Mars-du-Désert Email : william.mar...@power-lan.com Tel : 02 85 52 12 74 - 06 49 23 59 68 Fax : 02 85 52 13 72
Bug#629650: gvfs: Same problem seen under /run/user/uid
Package: gvfs Version: 1.20.2-1 Followup-For: Bug #629650 Hi maintainers, Just observed yesterday: # ll /run/user/1000/ ls: cannot access /run/user/1000/gvfs: Permission denied total 0 drwx-- 2 mones mones 60 Aug 22 07:54 dconf drwx-- 3 mones mones 60 Aug 21 17:10 gnome-shell d? ? ? ? ?? gvfs drwx-- 2 mones mones 40 Aug 21 17:17 gvfs-burn drwx-- 2 mones mones 80 Aug 21 17:28 pulse Looks like same instance of this bug, but in other location. BTW I logged out correctly from GNOME session, no message about errors or warnings was displayed. Thanks in advance for any hint, -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gvfs depends on: ii gvfs-common 1.20.2-1 ii gvfs-daemons 1.20.2-1 ii gvfs-libs 1.20.2-1 ii libc6 2.19-9 ii libglib2.0-0 2.40.0-4 ii libudev1 208-7 gvfs recommends no packages. Versions of packages gvfs suggests: ii gvfs-backends 1.20.2-1 -- 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#758861: php-dropbox: generates Curl error: (77) due to missing rootca
Package: php-dropbox Version: 1.0.0-1~bpo70+1 Severity: normal Dear Maintainer, /usr/share/php/Dropbox/OAuth/Curl.php contains the line: curl_setopt($ch, CURLOPT_CAINFO, rootca); causing it to fail with: Curl error: (77) error setting certificate verify locations: CAfile: rootca CApath: /etc/ssl/certs The file 'rootca' does not appear to exist in ca-certificates-20130119, or anywhere else on the system. Commenting out the curl_setopt line, php-dropbox functions as expected. Am I missing something? -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750910: Status of sitplus (Was: Bug#750910: sitplus: Please update to use wxwidgets3.0)
Hi Luis, I had another look into sitplus 1.1.0 upstream and it seems there is a split between libsitplus and sitplus. From the download file layout libsitplus looks similar to our packaged sitplus 1.0.3 and the upstream sitplus-1.1.0 has a structure which I would consider broken considering that the root of the source tree is featuring only the dir /usr. Luis, you have spent some time into packaging sitplus but did not responded to later pings. It would help if you could raise your voice about your future plans with sitplus. If you stopped your engagement I'm afraid we can not keep this software inside Debian which would be a shame. I also noticed that upstream is providing packages targeting at Squeeze which is lagging a behind current Debian development. Perhaps there is some chance to join forces here with upstream to provide recent upstream versions on recent Debian releases. However, if nobody volunteers for this job I would ask ftpmaster for removal from Debian since I have neither time nor the required background to test for this package. Kind regards Andreas. On Wed, Jun 25, 2014 at 02:44:39PM +0200, Andreas Tille wrote: Hi Olly, thanks for spotting the new version which was hidden from our sentinel due to an insufficient debian/watch file. Luis or Dmitrijs, you both touched the package before. Would you volunteer to work on the new upstream version? I did some minor polishing of the debian/ dir (including fixing the watch file) but I noticed that the upstream download tarball is a bit broken since it puts all stuff into a main dir /usr which would require to change our build system. I wonder whether it might be better to repack the upstream source. Any volunteer? Kind regards Andreas. On Sun, Jun 08, 2014 at 11:00:39PM +1200, Olly Betts wrote: Source: sitplus Version: 1.0.3-4 Severity: important Tags: sid jessie User: freewx-ma...@lists.alioth.debian.org Usertags: wx3.0 Control: block 748169 by -1 Dear maintainer, We're aiming to migrate the archive to using wxwidgets3.0 instead of wxwidgets2.8, and intend to drop wxwidgets2.8 before jessie is released. I tried rebuilding the current sitplus package with the B-D updated, but the build fails. Looking at upstream's website, I see there's a newer release 1.1.0 made 2013-04-23: http://sourceforge.net/projects/sitplus/files/1.1.0/ While this release pre-dates the wx3.0.0 release, it may have fixes for compatibility with wx2.9.x (the development series which lead to 3.0.0). It would probably make sense to update to 1.1.0 first even if further fixes are needed to work with wx3.0. If you hit any problems with getting packages working with wxwidgets3.0 which you can't overcome, let me know and I'll try to help. Cheers, Olly ___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de ___ Debian-med-packaging mailing list debian-med-packag...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758755: [pkg-cryptsetup-devel] Bug#758755: Bug#758756: libgcrypt20: missing udeb: libgcrypt20-udeb
Hey Andreas and Cyril, Am 21.08.2014 um 19:25 schrieb Cyril Brulebois: Andreas Metzler ametz...@bebt.de (2014-08-21): On 2014-08-21 Cyril Brulebois k...@debian.org wrote: Package: libgcrypt20 [...] but there's no libgcrypt20-udeb! (in the archive or in NEW) [...] I have just uploaded 1.6.1-3 with the udeb included. I hope NEW processing works out well. Thanks a lot Andreas, it's much appreciated! I'll try poking ftpmasters to see if it can get accepted soon. That'd avoid thinking about a revert on the cryptsetup side. Thanks for your help Cyril. Does this mean, that you're ok with cryptsetup keeping libgcrypt20 dependency now that the corresponding udeb will be in Debian soon? Sorry that I didn't coordinate with debian-boot. I simply didn't think about the consequences enough. I guess that's due to me not being involved in library transitions too often :-/ *sorry* Kind regards, jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755539: transition: hdf5
Gilles Filippini a écrit , Le 20/08/2014 19:50: Gilles Filippini a écrit , Le 15/08/2014 20:59: = Package ready = cmor flann gnuplot-iostream gpiv gpivtools magics++ octave-bim octave-msh pktools pygpiv python-shogun syrthes vtk = Useless build depends on hdf5 (package ready anyway) = getdp #755973 insighttoolkit4 #756015 oasis3 #755681 slepc #755180 = binNMU required = adios armadillo aster cdo code-saturne dolfin (not in testing) dynare (after octave) exodusii feel++ (not in testing) gdal gmsh grads h5py h5utils hdf-eos5 jhdf libcgns libgpiv libmatio libpdl-io-hdf5-perl (not in testing) libvigraimpex mathgl med-fichier meep meep-lam4 meep-mpich2 meep-mpi-default meep-openmpi minc mlpack mpb ncl netcdf nexus nifti2dicom (after vtk6) nip2 (after vips) octave ovito paraview petsc pytables r-cran-hdf5 ruby-hdfeos5 salome-kernel scilab shogun silo-llnl stimfit tessa(not in testing) vips (after libmatio) vtk6 xdmf xmds2 yorick-hdf5 = Others - Not in testing anyway = gnudatalanguage FTBFS blocked by plplot openmeeg FTBFS on sid - #730904 plplot FTBFS on sid - #713309 and more Looking at the packages listed on the auto-hdf5 transition page I realize that I missed two affected packages: These two packages were uploaded to unstable with a fix. Their status are now: = binNMU required = octave-communications = Others - Not in testing anyway = mapsempler2 unrelated FTBFS on sid - the version in testing doesn't depend on HDF5 Thanks, _g. signature.asc Description: OpenPGP digital signature
Bug#755416: shotwell adoption
Hi Jörg, How the Shotwell adoption goes? I'm a DD and have an almost ready package to upload. If you just need more time, I can can step back. Otherwise I'd be glad to continue with the package maintenance. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758862: mirror submission for mirror.transip.net
Package: mirrors Severity: wishlist Submission-Type: new Site: mirror.transip.net Type: leaf Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc Archive-ftp: /debian/debian-archive/ Archive-http: /debian/debian-archive/ Archive-rsync: debian/debian-archive/ Backports-ftp: /debian/debian-backports/ Backports-http: /debian/debian-backports/ Backports-rsync: debian/debian-backports/ CDImage-ftp: /debian/debian-cdimage/ CDImage-http: /debian/debian-cdimage/ CDImage-rsync: debian/debian-cdimage/ IPv6: yes Archive-upstream: ftp.nl.debian.org Backports-upstream: ftp.nl.debian.org CDImage-upstream: ftp.nl.debian.org Updates: four Maintainer: Transip devn...@transip.nl Country: NL Netherlands Location: Amsterdam Sponsor: Transip http://transip.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755154: vlc cache gen should happen at runtime, not buildtime
On Fri, Aug 22, 2014 at 9:38 AM, Rémi Denis-Courmont r...@remlab.net wrote: Le 2014-08-22 10:31, Harald Sitter a écrit : All that being said perhaps the more interesting bit is why exactly VLC thinks the cache is invalid to begin with. In particular considering we only have one build that builds with all plugins we have packaged and there are no third party plugins in any package anywhere ever. So the cache should always have a superset of what is available on a system. Changed file name, file size, or file modification time. But how could either of those happen if the only supplier of plugins are the VLC packages and so all of the cases you mentioned should be reflected in a new cache file provided by a new version of vlc-nox? Or more to the point... how could a completely new installation with a matching version of vlc-nox and vlc end up thinking the cache is invalid? I fail to see how exactly the additions could make the maintainer scripts fail to be honest, other than having a broken cache-gen which surely is the sign of a much deeper problem that should not have gotten beyond build time to begin with. Experience has shown that changes to certain libraries causes the cache generation to crash, and the maintainers of those libraries do not test against VLC before uploading to Debian. I mean glib, gobject, Qt, GL, libav to name the obvious ones... How does that work? Wouldn't that also defunct the plugins themselves? VLC would probably crash too, but a crashing program is not as bad and as likely to be reported as a crashing installation procedure. I think installation aborting if the cache generation actually doesn't work because of ABI breakage or whatever in an underlying library seems like a very appropriate course of action given that all libvlc applications would potentially end up broken at that point. It's not the libvlc applications that are broken, so willingly letting them crash rather than making sure we end up with a working set of plugins + cache seems ill-advised at best. Alas, this can be argued back and forth, it sounds like a less than optimal situation to begin with. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755539: transition: hdf5
Le vendredi 22 août 2014 à 10:03 +0200, Gilles Filippini a écrit : = binNMU required = octave-communications Note that this binNMU needs to be done after octave's binNMU. -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Bug#758863: plasma-nm: NM applet significantly delays KDE logon, does not connect to WiFi properly thereafter
Package: plasma-nm Version: 0.9.3.4-1 Severity: important Dear Maintainer, since I upgraded plasma-nm from 0.9.3.3-4 to 0.9.3.4-1, logging in to KDE is significantly delayed: The splash screen shows the first three icons, but after showing the blue globe, it stops. Only ~5-10sec later, logging in goes on. When the splash screen disappears, there's a window asking for the password of a wireless network (even though I stored that PW in the wallet). When I Cancel that window, the KWallet password dialogue appears. However, the applet still shows the wireless as not being connected. I downgraded back to 0.9.3.3-4, and everything behaves as expected again. Kind regards Ralf -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15.8 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages plasma-nm depends on: ii kde-runtime 4:4.13.3-1 ii libc6 2.19-9 ii libgcc1 1:4.9.1-4 ii libkdecore5 4:4.13.3-2 ii libkdeui5 4:4.13.3-2 ii libkio5 4:4.13.3-2 ii libknotifyconfig4 4:4.13.3-2 ii libmodemmanagerqt1 1.0.1-2 ii libnetworkmanagerqt10.9.8.2-1 ii libopenconnect3 6.00-1 ii libplasma3 4:4.13.3-2 ii libqt4-dbus 4:4.8.6+git49-gbc62005+dfsg-1 ii libqt4-declarative 4:4.8.6+git49-gbc62005+dfsg-1 ii libqt4-network 4:4.8.6+git49-gbc62005+dfsg-1 ii libqt4-svg 4:4.8.6+git49-gbc62005+dfsg-1 ii libqt4-xml 4:4.8.6+git49-gbc62005+dfsg-1 ii libqtcore4 4:4.8.6+git49-gbc62005+dfsg-1 ii libqtgui4 4:4.8.6+git49-gbc62005+dfsg-1 ii libsolid4 4:4.13.3-2 ii libstdc++6 4.9.1-4 ii mobile-broadband-provider-info 20140317-1 ii network-manager 0.9.10.0-1 Versions of packages plasma-nm recommends: ii kwalletmanager 4:4.13.3-1 ii network-manager-openvpn 0.9.10.0-1 ii network-manager-pptp 0.9.10.0-1 ii network-manager-vpnc 0.9.10.0-1 Versions of packages plasma-nm suggests: ii kde-workspace-bin4:4.11.11-1 ii network-manager-openconnect 0.9.8.6-1+b1 -- 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#755154: vlc cache gen should happen at runtime, not buildtime
Le 2014-08-22 11:24, Harald Sitter a écrit : On Fri, Aug 22, 2014 at 9:38 AM, Rémi Denis-Courmont r...@remlab.net wrote: Le 2014-08-22 10:31, Harald Sitter a écrit : All that being said perhaps the more interesting bit is why exactly VLC thinks the cache is invalid to begin with. In particular considering we only have one build that builds with all plugins we have packaged and there are no third party plugins in any package anywhere ever. So the cache should always have a superset of what is available on a system. Changed file name, file size, or file modification time. But how could either of those happen if the only supplier of plugins are the VLC packages and so all of the cases you mentioned should be reflected in a new cache file provided by a new version of vlc-nox? You tell me; I have never reproduced the alleged crash. Or more to the point... how could a completely new installation with a matching version of vlc-nox and vlc end up thinking the cache is invalid? It can't, unless something mucks with the modification time or some data corruption happens. I think installation aborting if the cache generation actually doesn't work because of ABI breakage or whatever in an underlying library seems like a very appropriate course of action given that all libvlc applications would potentially end up broken at that point. It's not the libvlc applications that are broken, so willingly letting them crash rather than making sure we end up with a working set of plugins + cache seems ill-advised at best. Alas, this can be argued back and forth, it sounds like a less than optimal situation to begin with. For a dedicated installer, I would agree that failing to install straight up is better than failing to run later. But we are talking about the Debian packaging system here. Failing to install means screwing up the whole oeprating system. -- Rémi Denis-Courmont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758864: cups: jessie update/upgrade - cups fails libcups2 (= 1.7.4-4) but 1.7.5-1 is installed
Package: cups Version: 1.7.5-1 Severity: normal Tags: upstream Perform sudo apt-get update / upgrade Upgrade terminates with:- The following packages have unmet dependencies: cups : Depends: cups-daemon (= 1.7.5-1) cups-core-drivers : Depends: cups-daemon (= 1.7.5-1) cups-daemon : Depends: libcups2 (= 1.7.4-4) but 1.7.5-1 is installed -f doesn't help Had the same problem few weeks ago where the libcups2 (= xxx) was previous version and this prevented upgrade and dist-upgrade - but this appeared to have been cured a week or so ago as the upgrade decided to work. Now it seems to have gone xxxs up again. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cups depends on: iu cups-client1.7.5-1 iu cups-common1.7.5-1 iu cups-core-drivers 1.7.5-1 ii cups-daemon1.7.4-4 ii cups-filters 1.0.57-1 iu cups-ppdc 1.7.5-1 iu cups-server-common 1.7.5-1 ii debconf [debconf-2.0] 1.5.53 ii ghostscript9.05~dfsg-9 ii libavahi-client3 0.6.31-4 ii libavahi-common3 0.6.31-4 ii libc-bin 2.19-9 ii libc6 2.19-9 iu libcups2 1.7.5-1 iu libcupscgi11.7.5-1 iu libcupsimage2 1.7.5-1 iu libcupsmime1 1.7.5-1 iu libcupsppdc1 1.7.5-1 ii libgcc11:4.9.1-4 ii libstdc++6 4.9.1-4 ii libusb-1.0-0 2:1.0.19-1 ii lsb-base 4.1+Debian13 ii poppler-utils 0.26.3-1 ii procps 1:3.3.9-7 Versions of packages cups recommends: ii avahi-daemon 0.6.31-4 ii colord 1.2.1-1 ii cups-filters [ghostscript-cups] 1.0.57-1 ii printer-driver-gutenprint5.2.10-3 Versions of packages cups suggests: iu cups-bsd 1.7.5-1 pn cups-pdf none ii foomatic-db20140730-1 ii hplip 3.14.6-1 ii printer-driver-hpcups 3.14.6-1 ii smbclient 2:4.1.11+dfsg-1 ii udev 208-6 -- debconf information: cupsys/raw-print: true cupsys/backend: lpd, socket, usb, snmp, dnssd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758865: r-cran-rcppeigen: embedded copy of eigen3-library
Package: r-cran-rcppeigen Version: 0.3.2.2.0-1 Severity: serious Justification: Policy 4.13 Dear Maintainer, r-cran-rcppeigen ships an embedded copy of eigen3-library. Please, remove it and use for compilation the packaged version of this library. Thanks Anton -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757797: Missing dependencies
Some additional information after mail discussion with Sylvestre. Here is an example log of the problem when rebuilding libclc package with llvm 3.5, after adding libedit-dev to libclc as a workaround but still with missing libz-dev: https://launchpadlibrarian.net/182793059/buildlog_ubuntu-utopic-i386.libclc_0~ https://launchpadlibrarian.net/182793059/buildlog_ubuntu-utopic-i386.libclc_0~git20140820.1830.7bd485~gd~u_FAILEDTOBUILD.txt.gz git20140820.1830.7bd485 https://launchpadlibrarian.net/182793059/buildlog_ubuntu-utopic-i386.libclc_0~git20140820.1830.7bd485~gd~u_FAILEDTOBUILD.txt.gz ~ https://launchpadlibrarian.net/182793059/buildlog_ubuntu-utopic-i386.libclc_0~git20140820.1830.7bd485~gd~u_FAILEDTOBUILD.txt.gz gd https://launchpadlibrarian.net/182793059/buildlog_ubuntu-utopic-i386.libclc_0~git20140820.1830.7bd485~gd~u_FAILEDTOBUILD.txt.gz ~ https://launchpadlibrarian.net/182793059/buildlog_ubuntu-utopic-i386.libclc_0~git20140820.1830.7bd485~gd~u_FAILEDTOBUILD.txt.gz u_FAILEDTOBUILD.txt.gz https://launchpadlibrarian.net/182793059/buildlog_ubuntu-utopic-i386.libclc_0~git20140820.1830.7bd485~gd~u_FAILEDTOBUILD.txt.gz Actually I am not sure if the two dependencies have to be added to llvm-3.5-dev or to a different binary package. For example mesa builds fine with current llvm-3.5-dev, so I think they should be added to clang-3.5, which is used by libclc but not mesa. I added them to libclc just as a workaround to be able to build it.
Bug#757906: Dependency solution problems currently with gnuplog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello David, thanks for your very, very great answer. Am Sa den 16. Aug 2014 um 13:43 schrieb David Kalnischkies: [Dependency resolving] Sounds easy, right? Well, I know what it is to resolve dependencies. I did create some solutions in the past that was heavily resolving dependencies. So I know that it is not an easy job. - Pick one out of the conflicting packages to keep and upgrade and deinstall the other. That would be not the best solution but at least allows to update them. The user can choose afterwards to install the other package. (Maybe taking the one that has the least dependencies.) ??? which apt really really really hates to do ??? so it usually doesn't ??? for good reason: How on earth should apt be able to decide for you if you want -x11 or -nox? I am fully with you. Thats the reason why I wrote That would not be the best solution. You have both installed, so you seem to want both after all??? Or maybe it was old dependencies. I, to be true, don't know. - Inform the user clearly _why_ they are not updated. At the moment it only shows that they have been kept back but not for what reason. Again, this sounds easy, but in practice it means that with the completion of this project we have created an artificial human-like intelligence (well, given that even I usually don't know why without a lot of debugging, probably well beyond human ???). Well, I don't think that it is this hard to print out the dependency tree just in conflict situation. (Nicely formated...) However, I did not have a peek into the internal structure in apt. You can get a glimpse of this with -o Debug::pkgProblemResolver=1 and it will tell you in its strange way what you want to know, but only because this situation here is trivial as -x11 and -nox conflict explicitly. The new versions, right. Now imagine a situation in which some obscure package on the 10th level in the tree makes a 2nd level or-group decision impossible??? in an algorithm which is designed to decide once and never questions this decision again (as reconsidering means we are prune to run into an endless loop ??? in practice, we have some points where we carefully do backtracking, but that is hard???). That's true. I would propose a shortest path resolving for such. As apt is asking the user anyway, it is with him to accept or decline the solution. With some more informations what triggers the decission it really would help the user (admin in this case) to resolve the problem by hand. Anyway, all three are generalisations of smaller bugs we already have reported in the BTS (multiple times) we are hopeful to tackle one at the time as time permits, so I hope you understand that I am not cloning or otherwise retaining this bugreport as a sort of never-closeable metabug. :-D With this packages it is just annoying and maybe is not good for SSDs as they would wear out. But for other packages that problem can get really problematic so I think it should be solved. I should really get an SSD, so that I might understand the constant fear of everyone with one that it could wear out, but I somehow doubt many people do an endless loop of installautoremove cycles to make a considerable dent in this problem space??? Well, just some thoughts I had with that. I myself have only one (private) system with SSD and the bug does not happens there. - in other words: Please don't try to invent arguments as it spoils the good arguments before??? Sorry about, was not meant this way. When I will have some spare time I might peek into resolving code of apt once. Maybe I can bring some knowledge in. As I told, I have some experiences in creating resolvers. But I don't want to make any promise as I lag a bit on time. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen kl...@ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJT9xDKAAoJEKZ8CrGAGfasyDwMAMcSMuO7zUyyYvGQtDdmNCXh 7yUiytVtiVZA2QKRbxtT1nxBnTmuonyO3JS/HF9LZrasuPweRZOlsN3bdySpNv9S iHCY/QFU6ozVG38JQlOsfjtchnbo1XBXUKxlmLHXTSxuMcPNXLENOhYatGmXuJXk 5+SlN01vfcxCwfO91Xc9xU3xI759GLXI3IFVYPDsLcyPCc32/Cdtg4fGTwyJNY7Z 3SfgwcX3VjaPYB9x3/oxxo5Vk6oeQOr36mR+M3lAmjEH0twTE9m2nVDLckbIs1Nu EPSQxc1sPv3ZRdYT7uDxsQNALbgn2BqyXIKNaJ83DkdCfmzjUWlCiCmHRLFKwT5f 5NrvKp+qoy8zxUn4Aa//LGvPQHpN+ZtiXCK7b16/iSfXDYkTNMs9mQ2rx+XMRrX7 AkszQce/wlJyONwYPsuq/rPDwbcrdhiMZI0/khxpsqzrvqfGfzvddL4oM37Z4SZl slszTPON/D3n+4kumDG07tM2WCHlPbRn9K96kl0olw== =NY2T -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#758616: dpkg: support installing M-A:same packages with different binNMU version
On 21/08/14 00:21, Guillem Jover wrote: Control: forcemerge 684625 -1 On Tue, 2014-08-19 at 11:25:19 +0200, Emilio Pozuelo Monfort wrote: Package: dpkg Version: 1.17.11 Severity: wishlist Currently M-A:same packages with different versions can't be co-installed. That prevents packages that have been binNMUed in one architecture but not another to be co-installed, e.g. libfoo_1.1-1:i386 libfoo_1.1-1+b1:amd64 or libfoo_1.1-1+b1:i386 libfoo_1.1-1+b2:amd64 Can't be co-installed. This is problematic because packages get binNMU on a subset of architectures very often (whenever it's not needed to binNMU them everywhere). See e.g. #758527. Yes, extensively discusssed in the mailing lists and already filed, this is just a different side of the same assumptions. Merging. I saw #684625 but thought it was the old problem that installing +b1:i386 and +b1:amd64 failed because of the different changelogs, problem that was solved / worked around by adding binnmu changelog entries in separate changelogs. Anyway, can you provide an update on this? Has there been any progress? Thanks, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758866: Upstream missing / dependency
Package: libconstantine-java Version: 0.7-5 Hi, the Homepage link (http://github.com/wmeissner/jnr-constants/) is broken; maybe https://github.com/jnr/jnr-constants is upstream now? Also is the dependency on default-jre really necessary or would default-jre-headless do? Because of this jenkins is pulling in all the X/gl/drm libraries. regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758831: w3m segfaults due to infinite recursion if GC issues warning
Control: tags -1 + pending On August 21, 2014 at 1:14PM -0700, micah (at addictivecode.org) wrote: Will attach a proposed replacement for 080_gc72.patch shortly. Looks fine. Will be merged soon. Thanks, -- Tatsuya Kinoshita pgpkaG2exybaQ.pgp Description: PGP signature
Bug#755154: vlc cache gen should happen at runtime, not buildtime
On Fri, Aug 22, 2014 at 10:58 AM, Rémi Denis-Courmont r...@remlab.net wrote: Le 2014-08-22 11:24, Harald Sitter a écrit : On Fri, Aug 22, 2014 at 9:38 AM, Rémi Denis-Courmont r...@remlab.net wrote: Le 2014-08-22 10:31, Harald Sitter a écrit : All that being said perhaps the more interesting bit is why exactly VLC thinks the cache is invalid to begin with. In particular considering we only have one build that builds with all plugins we have packaged and there are no third party plugins in any package anywhere ever. So the cache should always have a superset of what is available on a system. Changed file name, file size, or file modification time. But how could either of those happen if the only supplier of plugins are the VLC packages and so all of the cases you mentioned should be reflected in a new cache file provided by a new version of vlc-nox? You tell me; I have never reproduced the alleged crash. Ah, reproducing this is easy: debootstrap sid apt-get install qtbase5-dev libvlc-dev cmake build-essential vlc-nox vlc; wget http://people.ubuntu.com/~apachelogger/src/vq5.tar.xz; tar -xf vq5.tar.xz; cd vq5 mkdir build cd build cmake ..; ./vq5; - Segmentation fault (core dumped) Or more to the point... how could a completely new installation with a matching version of vlc-nox and vlc end up thinking the cache is invalid? It can't, unless something mucks with the modification time or some data corruption happens. Maybe the build itself messes up the mtime, although that would be rather odd I guess. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758869: librrd-dev: crashes due to use-after-free bugs
Package: librrd-dev Version: 1.4.8-1.1+b1 Severity: important Hi, I'm generating graphs using librrd from within a c++ program. I link against the _th version which should be thread safe. My c++ program contains a webserver. If I keep F5 pressed in my browser and thus let tons of graphs be drawn in paralel, then rrdtool crashes and goes into a loop spewing glib errors. I tried wrapping the call to rrd_graph in a mutex so that only one instance is running at a time but that did not help. According to valgrind the following goes wrong: ==29025== Thread 8: ==29025== Invalid read of size 8 ==29025==at 0xADD6C2E: pango_cairo_font_map_create_context (pangocairo-fontmap.c:285) ==29025==by 0x6470CF9: rrd_graph_init (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x647581E: rrd_graph_v (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x6475B62: rrd_graph (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x41B761: draw_RRD_file(char const*, char const*, char**, unsigned long*) (rrdtool.cpp:114) ==29025==by 0x417F4D: get_graph_cgi(MHD_Connection*, std::vectorstd::pairstd::string, std::string, std::allocatorstd::pairstd::string, std::string *) (webserver.cpp:451) ==29025==by 0x4182FD: request_handler(void*, MHD_Connection*, char const*, char const*, char const*, char const*, unsigned long*, void**) (webserver.cpp:551) ==29025==by 0x4E38011: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10.27.0) ==29025==by 0x4E391FF: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10.27.0) ==29025==by 0x4E3CEED: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10.27.0) ==29025==by 0x6EB50A3: start_thread (pthread_create.c:309) ==29025==by 0x71AFFBC: clone (clone.S:111) ==29025== Address 0x12558bc0 is 112 bytes inside a block of size 176 free'd ==29025==at 0x4C2970C: free (vg_replace_malloc.c:468) ==29025==by 0xB25CE31: g_type_free_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4000.0) ==29025==by 0xAFF4831: pango_context_finalize (pango-context.c:118) ==29025==by 0xB240316: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4000.0) ==29025==by 0xAFFC176: pango_layout_finalize (pango-layout.c:286) ==29025==by 0xB240316: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4000.0) ==29025==by 0x6469E52: im_free (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x64759FB: rrd_graph_v (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x6475B62: rrd_graph (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x41B761: draw_RRD_file(char const*, char const*, char**, unsigned long*) (rrdtool.cpp:114) ==29025==by 0x417F4D: get_graph_cgi(MHD_Connection*, std::vectorstd::pairstd::string, std::string, std::allocatorstd::pairstd::string, std::string *) (webserver.cpp:451) ==29025==by 0x4182FD: request_handler(void*, MHD_Connection*, char const*, char const*, char const*, char const*, unsigned long*, void**) (webserver.cpp:551) So it looks like either rrdtool or pango are trying to use memory that already had been freed. It also does something odd when setting up a cairo font map: ==29025== Invalid read of size 8 ==29025==at 0xADD6C36: pango_cairo_font_map_create_context (pangocairo-fontmap.c:285) ==29025==by 0x6470CF9: rrd_graph_init (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x647581E: rrd_graph_v (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x6475B62: rrd_graph (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x41B761: draw_RRD_file(char const*, char const*, char**, unsigned long*) (rrdtool.cpp:114) ==29025==by 0x417F4D: get_graph_cgi(MHD_Connection*, std::vectorstd::pairstd::string, std::string, std::allocatorstd::pairstd::string, std::string *) (webserver.cpp:451) ==29025==by 0x4182FD: request_handler(void*, MHD_Connection*, char const*, char const*, char const*, char const*, unsigned long*, void**) (webserver.cpp:551) ==29025==by 0x4E38011: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10.27.0) ==29025==by 0x4E391FF: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10.27.0) ==29025==by 0x4E3CEED: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10.27.0) ==29025==by 0x6EB50A3: start_thread (pthread_create.c:309) ==29025==by 0x71AFFBC: clone (clone.S:111) ==29025== Address 0xb9b9b9b9b9b9b9b9 is not stack'd, malloc'd or (recently) free'd Note that the 0xb9... pattern comes from the valgrind command-line I use: valgrind --show-reachable=yes --leak-check=full --read-var-info=yes --track-origins=yes --malloc-fill=93 --free-fill=b9 --error-limit=no The errors outputted are by the way: (process:10571): Pango-CRITICAL **: pango_cairo_font_map_create_context: assertion 'PANGO_IS_CAIRO_FONT_MAP (fontmap)' failed (process:10571): GLib-GObject-CRITICAL **: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed (process:10571): GLib-GObject-CRITICAL **: g_object_replace_qdata: assertion 'G_IS_OBJECT (object)' failed (process:10571):
Bug#758868: librrd-dev: crashes due to use-after-free bugs
Package: librrd-dev Version: 1.4.8-1.1+b1 Severity: important Hi, I'm generating graphs using librrd from within a c++ program. I link against the _th version which should be thread safe. My c++ program contains a webserver. If I keep F5 pressed in my browser and thus let tons of graphs be drawn in paralel, then rrdtool crashes and goes into a loop spewing glib errors. I tried wrapping the call to rrd_graph in a mutex so that only one instance is running at a time but that did not help. According to valgrind the following goes wrong: ==29025== Thread 8: ==29025== Invalid read of size 8 ==29025==at 0xADD6C2E: pango_cairo_font_map_create_context (pangocairo-fontmap.c:285) ==29025==by 0x6470CF9: rrd_graph_init (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x647581E: rrd_graph_v (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x6475B62: rrd_graph (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x41B761: draw_RRD_file(char const*, char const*, char**, unsigned long*) (rrdtool.cpp:114) ==29025==by 0x417F4D: get_graph_cgi(MHD_Connection*, std::vectorstd::pairstd::string, std::string, std::allocatorstd::pairstd::string, std::string *) (webserver.cpp:451) ==29025==by 0x4182FD: request_handler(void*, MHD_Connection*, char const*, char const*, char const*, char const*, unsigned long*, void**) (webserver.cpp:551) ==29025==by 0x4E38011: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10.27.0) ==29025==by 0x4E391FF: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10.27.0) ==29025==by 0x4E3CEED: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10.27.0) ==29025==by 0x6EB50A3: start_thread (pthread_create.c:309) ==29025==by 0x71AFFBC: clone (clone.S:111) ==29025== Address 0x12558bc0 is 112 bytes inside a block of size 176 free'd ==29025==at 0x4C2970C: free (vg_replace_malloc.c:468) ==29025==by 0xB25CE31: g_type_free_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4000.0) ==29025==by 0xAFF4831: pango_context_finalize (pango-context.c:118) ==29025==by 0xB240316: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4000.0) ==29025==by 0xAFFC176: pango_layout_finalize (pango-layout.c:286) ==29025==by 0xB240316: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4000.0) ==29025==by 0x6469E52: im_free (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x64759FB: rrd_graph_v (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x6475B62: rrd_graph (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x41B761: draw_RRD_file(char const*, char const*, char**, unsigned long*) (rrdtool.cpp:114) ==29025==by 0x417F4D: get_graph_cgi(MHD_Connection*, std::vectorstd::pairstd::string, std::string, std::allocatorstd::pairstd::string, std::string *) (webserver.cpp:451) ==29025==by 0x4182FD: request_handler(void*, MHD_Connection*, char const*, char const*, char const*, char const*, unsigned long*, void**) (webserver.cpp:551) So it looks like either rrdtool or pango are trying to use memory that already had been freed. It also does something odd when setting up a cairo font map: ==29025== Invalid read of size 8 ==29025==at 0xADD6C36: pango_cairo_font_map_create_context (pangocairo-fontmap.c:285) ==29025==by 0x6470CF9: rrd_graph_init (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x647581E: rrd_graph_v (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x6475B62: rrd_graph (in /usr/lib/librrd_th.so.4.2.1) ==29025==by 0x41B761: draw_RRD_file(char const*, char const*, char**, unsigned long*) (rrdtool.cpp:114) ==29025==by 0x417F4D: get_graph_cgi(MHD_Connection*, std::vectorstd::pairstd::string, std::string, std::allocatorstd::pairstd::string, std::string *) (webserver.cpp:451) ==29025==by 0x4182FD: request_handler(void*, MHD_Connection*, char const*, char const*, char const*, char const*, unsigned long*, void**) (webserver.cpp:551) ==29025==by 0x4E38011: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10.27.0) ==29025==by 0x4E391FF: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10.27.0) ==29025==by 0x4E3CEED: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.10.27.0) ==29025==by 0x6EB50A3: start_thread (pthread_create.c:309) ==29025==by 0x71AFFBC: clone (clone.S:111) ==29025== Address 0xb9b9b9b9b9b9b9b9 is not stack'd, malloc'd or (recently) free'd Note that the 0xb9... pattern comes from the valgrind command-line I use: valgrind --show-reachable=yes --leak-check=full --read-var-info=yes --track-origins=yes --malloc-fill=93 --free-fill=b9 --error-limit=no The errors outputted are by the way: (process:10571): Pango-CRITICAL **: pango_cairo_font_map_create_context: assertion 'PANGO_IS_CAIRO_FONT_MAP (fontmap)' failed (process:10571): GLib-GObject-CRITICAL **: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed (process:10571): GLib-GObject-CRITICAL **: g_object_replace_qdata: assertion 'G_IS_OBJECT (object)' failed (process:10571):
Bug#758756: [pkg-cryptsetup-devel] Bug#758755: Bug#758756: libgcrypt20: missing udeb: libgcrypt20-udeb
Jonas Meurer jo...@freesources.org (2014-08-22): Thanks for your help Cyril. Does this mean, that you're ok with cryptsetup keeping libgcrypt20 dependency now that the corresponding udeb will be in Debian soon? It's already in. ;) https://packages.qa.debian.org/libg/libgcrypt20/news/20140821T210007Z.html I was just waiting confirmation and indeed last run has: | Newly-fixed packages in unstable | cryptsetup-udeb amd64 armel armhf i386 mipsel powerpc s390x sparc | libcryptsetup4-udeb amd64 armel armhf i386 mipsel powerpc s390x sparc | partman-crypto-dmamd64 armel armhf i386 mipsel powerpc s390x sparc | rescue-mode amd64 i386 mipsel powerpc sparc | | Uninstallability trend: better (+0/-29) | Uninstallability count: 494 → Closing this bug report accordingly. :) Sorry that I didn't coordinate with debian-boot. I simply didn't think about the consequences enough. I guess that's due to me not being involved in library transitions too often :-/ *sorry* Don't worry, that's fine. That was caught by the (un)installability checker, fixed in a few days; nothing to worry about. udebs are a bit special and it's not as easy to make sure everything is fine as it is for regular packages. I haven't checked cryptsetup works fine yet, though. But that's another story. :) Mraw, KiBi. signature.asc Description: Digital signature
Bug#758870: nfs-common: nfs v4: uid/gid lookup fails for some of the users
Package: nfs-common Version: 1:1.2.8-9 Severity: important Dear Maintainer, I'm reporting this bug in nfs (4)? where client's uid's/gid's are shown as them instead of their regular ownerships. This has been puzzling me for over a month now. The problem appeared after a system upgrade in jessie. Before this update everything worked well. More details are below. Problem description: We (a school) serve home directories over nfs from a wheezy system. The clients mount them using nfs v4. Some client systems were upgraded to jessie. On jessie systems, nfs v4 clients worked ok, until some day (about half of july) systemd, a new libc6 and a new kernel appeared. Since then, identities of the users home directories are shown as 4294967294. When the main login directory has the right identities, subdirectories and files within it still can have the 4294967294 for uid and gid. This bahaviour is consistent on all the jessie systems I upgraded. And yes, identities for the users, as shown with id, _are_ available in all cases. When booting, I see that systemd registers the id_resolver in the kernel, as well as the id_legacy resolver. Since the id_resolver is supposed to call nfsidmap, I raised Verbosity in /etc/idmapd.conf to 65535. This shows that nfsidmap is simply not called for some users, some random, some rather consistent. About a third is lacking a call. When a user lookup is succesful, the corresponding group is looked up as well. From time to time users, whether logged in or not, lose their identities. This can be inidivdual files or directories. Lateron all identities are present again. I see no request-key program, it looks like systemd performs this role. I've been debugging a lot, and still have no clue who is actually calling the id_resolver (as defined in /etc/request-key.d/id_resolver.conf). When I remove the file, _all_ users and groups immediately show up as 4294967294. I have no idea what happens when the nfsidmap key expires after 600 seconds, tracing listings show that known users stay known, and some of the unknown ones become known over time. System setup: The nfs server is an up-to-date wheezy system. The partition with the home directory is an xfs partition. The export entry looks like: client(rw,secure,no_subtree_check,sync) The mount option on the client looks like: nfs rw,vers=4,proto=tcp,rsize=524288,wsize=524288,nosuid,nodev,noatime There is no gss setup here. Identities are distributed through nis. Identities on the clients (as shown by id) are always avalable. Ideas: The problem suggests something is in the way. This might be the rpc.idmap daemon. Killing it did not resolve the problem. Bug #744768 might be related, although I don't see the (null) so often. Maybe there is some 32-bit/16-bit uid/gid mixup. Tested if uid/gid's of the users correspond to some kind of a pattern. No, these are just in-between other users. Same for permissions nfv4 patches in kernel 3.14.11 (in jessie from 3.14.12)? looks like bug #562821, but we're talking clients instead of server. Debugging: I'm willing to help debugging this, but I'm out of options. * What led up to the situation? An regular upgrade in jessie about half of july 2014 * What exactly did you do (or not do) that was effective (or ineffective)? aptitude update, which pulled in kernel 3.14.12, systemd for the first time, and libc6 2.19.9? Problem has also been reproduced on older libc6's * What was the outcome of this action? uid's/gid's did show up as 4294967294 instead; id lists id's correctly * What outcome did you expect instead? user directories with user id'a and group id's shown correctly Thanks, Piet -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 172 udp 37063 ypbind 171 udp 37063 ypbind 172 tcp 48220 ypbind 171 tcp 48220 ypbind 1000241 udp 60043 status 1000241 tcp 45346 status -- /etc/default/nfs-common -- NEED_STATD= STATDOPTS= NEED_IDMAPD= NEED_GSSD= -- /etc/idmapd.conf -- [General] Verbosity = 0 Pipefs-Directory = /run/rpc_pipefs [Mapping] Nobody-User = nobody Nobody-Group = nogroup [Translation] Method = nsswitch -- /etc/fstab -- # nfshost nfshost:/homes/homes nfs4 rw,vers=4,proto=tcp,rsize=524288,wsize=524288,nosuid,nodev,noatime 0 0 -- /proc/mounts -- -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64
Bug#758871: rrdtool-dbg: does not contain debug symbols for librrd_th
Package: rrdtool-dbg Version: 1.4.8-1.1+b1 Severity: normal rrdtool-dbg: does not contain debug symbols for librrd_th e.g. valgrind gives: ==12723==by 0x6470CF9: rrd_graph_init (in /usr/lib/librrd_th.so.4.2.1) ==12723==by 0x647581E: rrd_graph_v (in /usr/lib/librrd_th.so.4.2.1) ==12723==by 0x6475B62: rrd_graph (in /usr/lib/librrd_th.so.4.2.1) which is not too helpful :-) -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-rc6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rrdtool-dbg depends on: ii libc6 2.19-9 ii librrd4 1.4.8-1.1+b1 ii python-dbg 2.7.8-1 ii rrdtool 1.4.8-1.1+b1 Versions of packages rrdtool-dbg recommends: ii liblua5.1-rrd0 1.4.8-1.1+b1 pn librrds-perlnone ii python-all-dbg 2.7.8-1 ii python-rrdtool 1.4.8-1.1+b1 ii rrdtool-tcl 1.4.8-1.1+b1 ii ruby-rrd1.4.8-1.1+b1 rrdtool-dbg 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#758815: RFS: libircclient/1.8-1 [ITA]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 21.08.2014 21:16, Eriberto Mota wrote:
tags 758815 moreinfo thanks
Hi Dariusz.
Please:
1. d/changelog: add an explanation about why your removed the -dfsg. Please,
see the field 'Source' in d/copyright header.
Done, good catch thanks.
2. d/control: in 'Package: libircclient-dev', remove 'Pre-Depends:
${misc:Pre-Depends}'.
Done.
3. d/copyright: - Fix the 'Source' field in header.
Fixed.
- See it[1] and put the correct range of the years for each Debian
maintainer.
Fixed.
- Update the upstream copyright years (2004-2013).
Fixed.
- Search with 'grep -sri copyright * | grep -v Georg' for other authors.
Did that. Added Authors from cocoa/ folder.
[1] https://packages.qa.debian.org/libi/libircclient.html
4. libircclient-dev.install: remove .a. From Maintainers Guide[2]:
Shared libraries are distributed as *.so files. (Neither *.a files nor *.la
files)
[2] https://www.debian.org/doc/manuals/maint-guide/advanced.en.html[2]
I will leave them if it is ok with you.
5. Remove useless file README.source.
Done.
6. Please, tell me why you make a patch. Your package is installing
libircclient.h only. The original program is installing libirc_options.h,
libircclient.h, libirc_errors.h, libirc_rfcnumeric.h and libirc_events.h.
Good catch, super thanks. I added installing of other header files. I made patch
because the legacy build system builds only one .so file, and I was advised on
#debian-mentors that it is better to patch build system than to make symlinks
for ldconfig in d/rules.
7. The upstream site has lot[3] of instructions about the library. I suggest
you create a README.Debian with notice about it.
[3] http://www.ulduzsoft.com/libircclient
I added this, you are right it is nice to have some doc.
I reuploaded to mentors, also this can be found in my collab-maint repo.
- --
Dariusz Dwornikowski,
Institute of Computing Science, Poznań University of Technology
www.cs.put.poznan.pl/ddwornikowski/
room 2.7.2 BTiCW | tel. +48 61 665 29 41
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBCAAGBQJT9xlYAAoJECEac8aaew/HcTsP/1VgYlvF9tStexwMEKogLRm/
3HUHFiStFwJ094m2GbECfEKaIMclHcVqSbQVLGpOqESOgDmhsIEXS3E8pNe3qOxr
nb3pzTIhNOLo97CCR6zoMKQRMjPNp1BiQweQYuFw+UtwZobdBz5y2KEwBugCYSmg
K3wFthwL5P2shc9yUvvpJJJyrJfe6YixhlwGiBh+gP1h5XdkjmtSH/UOfPP7ib0G
J+cjTLmKu8ydeedKaItPOE4waCF8a6HzAWeWvH62u/wSTqg7J50rTSqYB6CSe4P2
EqG8UL9eJnbGwBP7I5ZoorctqCuoCsYoeoWELRoU+yqIPvOgHpt7OLwPV55Lxj68
LdGTyynjb5kzUf/pT9ErVxE4eFlPOoB9VZ0KiSSvwv2/gTWTKVq+C0RboreJ2Qz7
LjOsaxipe2bz/2iGT+MngleS6Ljt/Cn2f1q6G8ATMYnZi4pzldlqT5mJbMNyTrAu
/sZSGYd4GF2tKkHsZYKdMeCg0w/ogrEfQwlAKZECk6hsiWrxBMhGkYnb8Ngm1yXs
Q1f3Fa6o4+dGuzkzwACZUB7msew2pv4bNaceKBcFrQmkkKcM3OUbmtMCy9/kw6QC
b875AH6fY+5xoWrfplrTWMlk8bk8MrXEqg0+Njh2IQxwEUMmBIR3yjwsu0v9LVOS
OnsHK4Jk964V8XxkQKVF
=ZgKY
-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#758872: jessie: nemo 2.2.4 After upgrade on 21/8/14 not all bookmarks directly accessible on LHS
Package: nemo Version: 2.2.4-1 Severity: important Tags: upstream Running Jessie - updating every day or so to keep up Have several Bookmarks defined which (used to until last night) show up under My Computer on Sidebar These bookmarks relate to both network and local extra physical HDD's After updating on 21/8/14 the bookmarks are behaving strangely On startup not all are shown in sidebar under My Computer Some network ones are shown on startup but others (actually on the same remote NAS) don't show One of the extra HDD ones does show after I mount the drive but another, on a different drive, doesn't I can access the drives by going into the Edit Bookmarks and doing a Jump To! I have also tried Nautilus - which I don't use generally as the user i/f isn't as nice - and the bookmarks are all listed under bookmarks - but some twice (that's not really an issue as I may have added the ones I couldn't see under nemo twice!!!). Can't see a Help About on Nautilus so can't easily tell version. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nemo depends on: ii desktop-file-utils 0.22-1 ii gsettings-desktop-schemas 3.12.2-1 ii gvfs 1.20.2-1 ii libatk1.0-02.12.0-1 ii libc6 2.19-9 ii libcairo-gobject2 1.12.16-2 ii libcairo2 1.12.16-2 ii libcinnamon-desktop4 2.2.3-2 ii libexempi3 2.2.1-2 ii libexif12 0.6.21-1 ii libgail-3-03.12.2-2 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-4 ii libglib2.0-data2.40.0-4 ii libgtk-3-0 3.12.2-2 ii libnemo-extension1 2.2.4-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-01.36.3-1 ii libx11-6 2:1.6.2-2 ii libxml22.9.1+dfsg1-4 ii nemo-data 2.2.4-1 ii shared-mime-info 1.3-1 Versions of packages nemo recommends: pn cinnamon-l10nnone ii eject2.1.5+deb1+cvs20081104-13.1 ii gvfs-backends1.20.2-1 ii librsvg2-common 2.40.2-1 ii nemo-fileroller 1.8.0-1 Versions of packages nemo suggests: ii eog 3.12.2-1 ii evince-gtk [pdf-viewer] 3.12.1-1 ii totem3.12.1-1 ii vlc [mp3-decoder]2.1.5-1 ii vlc-nox [mp3-decoder]2.1.5-1 ii xdg-user-dirs0.15-1 -- 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#758873: migemo-el: installation failure with emacs20/emacs19
Package: migemo-el
Version: 1:1.2+gh0.20140306-3
Severity: minor
Tags: patch
Typo in the recent change:
```
diff --git a/debian/migemo-el.emacsen-install b/debian/migemo-el.emacsen-install
index 2b4ed8d..57a80cc 100644
--- a/debian/migemo-el.emacsen-install
+++ b/debian/migemo-el.emacsen-install
@@ -5,7 +5,7 @@ set -e
FLAVOR=$1
PACKAGE=migemo-el
case ${FLAVOR} in
-emacs|emacs23|emacs22|emacs21|emacs20emacs19|mule2|xemacs*)
+emacs|emacs23|emacs22|emacs21|emacs20|emacs19|mule2|xemacs*)
exit 0
;;
*)
```
which may cause an installation failure if emacs20 or emacs19
still exists in the system.
Thanks,
--
Tatsuya Kinoshita
pgpSBDYSm1u7m.pgp
Description: PGP signature
Bug#758874: ITP: python3-pyelliptic -- High level Python 3 wrapper for OpenSSL
Package: wnpp Severity: wishlist Owner: Riley bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch * Package name: python3-pyelliptic Version : 1.5.3 Upstream Author : Yann Guibet yanngui...@gmail.com * URL : https://github.com/yann2192/pyelliptic/ * License : GPL-3+ with OpenSSL linking exception Programming Lang: Python 3 Description : High level Python 3 wrapper for OpenSSL PyElliptic is a Python 3 module that provides high level access to the OpenSSL library, featuring elliptic curve cryptography (ECC), symmetric cryptography and more. The full list of functions is below: Key agreement : ECDH Digital signatures : ECDSA Hybrid encryption : ECIES (like RSA) AES-128 (CBC, OFB, CFB, CTR) AES-256 (CBC, OFB, CFB, CTR) Blowfish (CFB and CBC) RC4 CSPRNG HMAC (using SHA512) PBKDF2 (SHA256 and SHA512) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748752: issue fixed ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The issue seems to be fixed now at least when using the GNOME-desktop: andrew@s5:~$ aptitude show liferea Package: liferea State: installed Automatically installed: no Version: 1.10.9-1 Priority: optional Section: gnome Maintainer: David Michael Smith sidic...@gmail.com Architecture: amd64 Uncompressed Size: 653 k Depends: dbus-x11, gir1.2-peas-1.0, liferea-data (= 1.10.9-1), python-gi, gir1.2-gtk-3.0, dconf-gsettings-backend | gsettings-backend, python:any (= 2.6.6-7~), libatk1.0-0 (= 1.12.4), libc6 (= 2.14), libcairo2 (= 1.2.4), libgdk-pixbuf2.0-0 (= 2.22.0), libgirepository-1.0-1 (= 0.9.3), libglib2.0-0 (= 2.37.3), libgtk-3-0 (= 3.0.0), libindicate5 (= 0.4.90), libjson-glib-1.0-0 (= 0.12.0), libnotify4 (= 0.7.0), libpango-1.0-0 (= 1.14.0), libpeas-1.0-0 (= 1.1.0), libsoup2.4-1 (= 2.33.92), libsqlite3-0 (= 3.5.9), libwebkitgtk-3.0-0 (= 1.3.10), libxml2 (= 2.7.4), libxslt1.1 (= 1.1.25) Recommends: gir1.2-gnomekeyring-1.0, gnome-icon-theme, gnome-keyring, steadyflow | kget Suggests: network-manager Replaces: liferea-data ( 1.4.26-4) Description: feed/news/podcast client with plugin support Liferea is a feed reader, a news reader, and a podcast client that brings together all of the content from your favorite web subscriptions into a simple interface with an embedded graphical browser that's easy to organize and browse. It supports: * aggregating feeds in all the major syndication formats (including RSS/RDF, Atom, CDF, and more); * synchronizing feeds across devices, with TinyTinyRSS and TheOldReader support; * downloading articles for offline reading; * permanently saving headlines in news bins; * playing podcasts directly in Liferea's browser interface; * social networking / web integration so you can share your favorite news articles to Facebook, Google+, Reddit, Twitter, Slashdot, Digg, Yahoo and many more. Liferea is an abbreviation for Linux Feed Reader. Homepage: http://liferea.sourceforge.net/ Tags: implemented-in::c, interface::x11, network::client, protocol::http, role::program, scope::application, suite::gnome, uitoolkit::gtk, use::browsing, use::downloading, web::blog, works-with-format::xml, works-with-format::xml:rss, x11::application -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlP3GawACgkQ5+rBHyUt5wuEwgCfQY9QHXOIfUaVP47ZIn7ubyRD ssQAnRwFcaYyNyK2oeLB2sAHbRdXcdZJ =GLdn -END PGP SIGNATURE-
Bug#758875: A few bugs from the very first usage in Italian
Package: lyx Version: 2.0.6-1+b2 Hello, I just installed LyX and had a first look at its welcome page, i.e., the content shown when you run it without arguments. My user is in Italian, so I got an Italian document. The first problem is that at point 3, the text suggest to check the menu ViewDVI in order to see how great it is the printed output, but I cannot see and DVI in the View menu. I think the correct menuitem is ViewDisplay(Other formats)DVI or ViewPDF. The second problem is that selecting any of the mentioned menuitem, I get a box that display this error message: ...ry to proceed from here, type x to quit.} You need to specify a language, either as a global option or as an optional argument to the \usepackage command; You shouldn't try to proceed from here, type x to quit. So, I cannot see any printed document. The third problem is in the Italian translation, still at point 3 of the list shown in the document, the word constatrlo should be constatarlo. Moreover, the welcome page says that the menu is called View (as in the English GUI probably), while the real menu is called Vista. All other references to menu names are correctly translated into Italian and match the real menu names. Bye, Giuseppe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758876: blender: Freestyle rendering does not work (rendering never finishes)
Package: blender Version: 2.71+dfsg0-4 Severity: normal Dear Maintainer, Freestyle rendering works differently in the Debian-packaged version of blender compared to the version from the upstream blender.org. In the upstream version, Freestyle rendering works and produces the expected result. In the version provided by Debian, enabling Freestyle rendering causes the render never to finish. I have been able to reproduce this using the following steps: 1. Start with a new default blender scene (either by starting blender afresh or by pressing Ctrl N and selecting Reload startup file -- this assumes the startup file is unaltered). 2. In the properties in the right-hand area below the object outline, select Render (the camera icon). 3. Check the Freestyle option. 4. Press the Render button or F12. The default cube will now be rendered, after which blender will start the Freestyle rendering phase. The status bar at the top of the rendering view displays Freestyle: Mesh loading 100%. Blender will stop here and nothing will happen. Some of the GUI is still working, but new renders cannot be started, the ongoing render cannot be stopped (using the X button at the top of the view beside the Render progress bar), and blender cannot be exited. The only option is to kill it. Using the prebuilt version downloaded from the upstream web site, Freestyle rendering finishes correctly using the same steps. Maybe one of the Debian patches could have caused this? Thanks, -- Fabian Fagerholm fa...@paniq.net -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages blender depends on: ii blender-data 2.71+dfsg0-4 ii fonts-droid 1:4.4.3r1.1-1 ii libavcodec55 6:10.3-1 ii libavdevice54 6:10.3-1 ii libavformat55 6:10.3-1 ii libavutil53 6:10.3-1 ii libboost-date-time1.55.0 1.55.0+dfsg-2 ii libboost-filesystem1.55.0 1.55.0+dfsg-2 ii libboost-locale1.55.0 1.55.0+dfsg-2 ii libboost-regex1.55.0 1.55.0+dfsg-2 ii libboost-system1.55.0 1.55.0+dfsg-2 ii libboost-thread1.55.0 1.55.0+dfsg-2 ii libc6 2.19-9 ii libfftw3-double3 3.3.4-1 ii libfreetype6 2.5.2-1.1 ii libgcc1 1:4.9.1-4 ii libgl1-mesa-glx [libgl1] 10.2.5-1 ii libglew1.10 1.10.0-3 ii libglu1-mesa [libglu1]9.0.0-2 ii libgomp1 4.9.1-4 ii libilmbase6 1.0.1-6 ii libjack-jackd2-0 [libjack-0.116] 1.9.10+20140719git3eb0ae6a~dfsg-1 ii libjpeg8 8d1-1 ii libjs-jquery 1.7.2+dfsg-3 ii libjs-jquery-ui 1.10.1+dfsg-1 ii libopenal11:1.15.1-3 ii libopencolorio1 1.0.9~dfsg0-2 ii libopenexr6 1.6.1-7 ii libopenimageio1.4 1.4.12~dfsg0-1 ii libopenjpeg5 1.5.2-2 ii libpng12-01.2.50-2 ii libpython3.4 3.4.1-9 ii libsdl1.2debian 1.2.15-10 ii libsndfile1 1.0.25-9 ii libspnav0 0.2.2-1 ii libstdc++64.9.1-4 ii libswscale2 6:10.3-1 ii libtiff5 4.0.3-9 ii libx11-6 2:1.6.2-2 ii libxi62:1.7.4-1 ii libxxf86vm1 1:1.1.3-1 ii zlib1g1:1.2.8.dfsg-1 blender recommends no packages. blender 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#758877: isc-dhcp-client: [kfreebsd] dhclient-script does not use addresses from dhcp6.ia-na
Package: isc-dhcp-client Version: 4.2.2.dfsg.1-5+deb70u6 Severity: normal Dear Maintainer, Both stable and current unstable versions of isc-dhcp-client in Debian/kFreeBSD do not configure network interface with address received from DHCPv6 server (ia-na dhcp6 option). In fact, dhclient-script currently lacks the handling of BOUND6 and all other 'reasons' that dhclient should give to the dhclient-script for ipv6. Since ifconfig they put in Debian/kFreeBSD is perfectly able to add (or remove) an ipv6 address to the interface - dhclient-script should be updated to support ia-na, as it does in Linux already. Documenting above-mentioned fact in README.Debian would be welcome too. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 9.0-2-amd64 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 Versions of packages isc-dhcp-client depends on: ii debianutils 4.3.2 ii inetutils-ping 2:1.9-2 ii isc-dhcp-common 4.2.2.dfsg.1-5+deb70u6 ii libc0.1 2.13-38+deb7u3 isc-dhcp-client recommends no packages. Versions of packages isc-dhcp-client suggests: pn avahi-autoipd none pn resolvconf none -- Configuration Files: /etc/dhcp/dhclient-enter-hooks.d/debug changed [not included] /etc/dhcp/dhclient.conf changed [not included] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758868: crash
The problem can fairly easy be triggered using this test-code: http://vps001.vanheusden.com/~folkert/pango-crash.tgz
Bug#758878: ITP: node-temp -- Temporary files, directories, and streams for Node.js
Package: wnpp Severity: wishlist Owner: Tim Retout dioc...@debian.org * Package name: node-temp Version : 0.8.1 Upstream Author : Bruce Williams brwco...@gmail.com * URL : https://github.com/bruce/node-temp * License : Expat Programming Lang: JavaScript Description : Temporary files, directories and streams for Node.js This library handles generating a unique file/directory name under the appropriate system temporary directory, changing the file to an appropriate mode, and supports automatic removal (if asked). . Node.js is an event-based server-side JavaScript engine. I will maintain this as part of the javascript team. This is a build-dep for statsd (bug #705758). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758815: RFS: libircclient/1.8-1 [ITA]
Hi Dariusz,
Thanks for your reply. Sorry, but I have some little adjustments yet. Let's go:
d/changelog: put the 'new maintainer' line in the first position.
d/copyright:
- New licenses (coccoa) added lots of blank spaces. To see, you can
use mcedit (apt-get install mc) or 'cat -A copyright' . Please,
remove. (Tip: in mcedit you can use F4 to replace it)
- The last line has an extra dot (GPL-2.).
- The line 'Files: cocoa/Classes/IRCClientChannel.*
cocoa/Classes/IRCClientSessionDelegate.h
cocoa/Classes/IRCClientSession.*
cocoa/Classes/IRCClientChannelDelegate.h' can be split. Example:
Files: cocoa/Classes/IRCClientChannel.*
cocoa/Classes/IRCClientSessionDelegate.h
cocoa/Classes/IRCClientSession.*
cocoa/Classes/IRCClientChannelDelegate.h
Thanks a lot for your work. I am waiting your final package for upload.
Cheers,
Eriberto
2014-08-22 7:20 GMT-03:00 Dariusz Dwornikowski
dariusz.dwornikow...@cs.put.poznan.pl:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 21.08.2014 21:16, Eriberto Mota wrote:
tags 758815 moreinfo thanks
Hi Dariusz.
Please:
1. d/changelog: add an explanation about why your removed the -dfsg. Please,
see the field 'Source' in d/copyright header.
Done, good catch thanks.
2. d/control: in 'Package: libircclient-dev', remove 'Pre-Depends:
${misc:Pre-Depends}'.
Done.
3. d/copyright: - Fix the 'Source' field in header.
Fixed.
- See it[1] and put the correct range of the years for each Debian
maintainer.
Fixed.
- Update the upstream copyright years (2004-2013).
Fixed.
- Search with 'grep -sri copyright * | grep -v Georg' for other authors.
Did that. Added Authors from cocoa/ folder.
[1] https://packages.qa.debian.org/libi/libircclient.html
4. libircclient-dev.install: remove .a. From Maintainers Guide[2]:
Shared libraries are distributed as *.so files. (Neither *.a files nor *.la
files)
[2] https://www.debian.org/doc/manuals/maint-guide/advanced.en.html[2]
I will leave them if it is ok with you.
5. Remove useless file README.source.
Done.
6. Please, tell me why you make a patch. Your package is installing
libircclient.h only. The original program is installing libirc_options.h,
libircclient.h, libirc_errors.h, libirc_rfcnumeric.h and libirc_events.h.
Good catch, super thanks. I added installing of other header files. I made
patch
because the legacy build system builds only one .so file, and I was advised on
#debian-mentors that it is better to patch build system than to make symlinks
for ldconfig in d/rules.
7. The upstream site has lot[3] of instructions about the library. I suggest
you create a README.Debian with notice about it.
[3] http://www.ulduzsoft.com/libircclient
I added this, you are right it is nice to have some doc.
I reuploaded to mentors, also this can be found in my collab-maint repo.
- --
Dariusz Dwornikowski,
Institute of Computing Science, Poznań University of Technology
www.cs.put.poznan.pl/ddwornikowski/
room 2.7.2 BTiCW | tel. +48 61 665 29 41
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBCAAGBQJT9xlYAAoJECEac8aaew/HcTsP/1VgYlvF9tStexwMEKogLRm/
3HUHFiStFwJ094m2GbECfEKaIMclHcVqSbQVLGpOqESOgDmhsIEXS3E8pNe3qOxr
nb3pzTIhNOLo97CCR6zoMKQRMjPNp1BiQweQYuFw+UtwZobdBz5y2KEwBugCYSmg
K3wFthwL5P2shc9yUvvpJJJyrJfe6YixhlwGiBh+gP1h5XdkjmtSH/UOfPP7ib0G
J+cjTLmKu8ydeedKaItPOE4waCF8a6HzAWeWvH62u/wSTqg7J50rTSqYB6CSe4P2
EqG8UL9eJnbGwBP7I5ZoorctqCuoCsYoeoWELRoU+yqIPvOgHpt7OLwPV55Lxj68
LdGTyynjb5kzUf/pT9ErVxE4eFlPOoB9VZ0KiSSvwv2/gTWTKVq+C0RboreJ2Qz7
LjOsaxipe2bz/2iGT+MngleS6Ljt/Cn2f1q6G8ATMYnZi4pzldlqT5mJbMNyTrAu
/sZSGYd4GF2tKkHsZYKdMeCg0w/ogrEfQwlAKZECk6hsiWrxBMhGkYnb8Ngm1yXs
Q1f3Fa6o4+dGuzkzwACZUB7msew2pv4bNaceKBcFrQmkkKcM3OUbmtMCy9/kw6QC
b875AH6fY+5xoWrfplrTWMlk8bk8MrXEqg0+Njh2IQxwEUMmBIR3yjwsu0v9LVOS
OnsHK4Jk964V8XxkQKVF
=ZgKY
-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#758879: gnome-core: my /etc/gdm3/daemon.conf have this srokes AutomaticLoginEnable=true AutomaticLogin=kim , but still if you boot the computer requires a password
Package: gnome-core Version: 1:3.8+8 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-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 Versions of packages gnome-core depends on: ii at-spi2-core 2.12.0-2 ii baobab 3.12.1-1 ii brasero3.10.0-1 ii caribou0.4.13-1 ii caribou-antler 0.4.13-1 ii dconf-gsettings-backend0.20.0-2 ii dconf-tools0.20.0-2 ii empathy3.12.4-2 ii eog3.12.2-1 ii evince 3.12.1-1 ii evolution-data-server 3.12.2-1 ii fonts-cantarell0.0.15-1 ii gconf2 3.2.6-2 ii gdm3 3.12.2-2.1 ii gkbd-capplet 3.6.0-1 ii glib-networking2.40.1-2 ii gnome-backgrounds 3.12.2-1 ii gnome-bluetooth3.12.0-5 ii gnome-calculator 3.12.2-1 ii gnome-contacts 3.12.0-1+b2 ii gnome-control-center 1:3.12.1-4 ii gnome-dictionary 3.10.0-1 ii gnome-disk-utility 3.12.1-1 ii gnome-font-viewer 3.12.0-1+b1 ii gnome-icon-theme 3.12.0-1 ii gnome-icon-theme-extras3.12.0-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii gnome-keyring 3.8.2-2+b1 ii gnome-menus3.13.3-1 ii gnome-online-accounts 3.12.4-1 ii gnome-packagekit 3.12.2-1 ii gnome-screenshot 3.12.0-1 ii gnome-session 3.12.1-3 ii gnome-settings-daemon 3.12.2-1 ii gnome-shell3.12.2-3 ii gnome-sushi3.12.0-2 ii gnome-system-log 3.9.90-2 ii gnome-system-monitor 3.12.2-1 ii gnome-terminal 3.12.3-2 ii gnome-themes-standard 3.12.0-1 ii gnome-user-guide 3.12.2-1 ii gnome-user-share 3.10.2-1 ii gsettings-desktop-schemas 3.12.2-1 ii gstreamer1.0-plugins-base 1.4.0-1 ii gstreamer1.0-plugins-good 1.4.0-1 ii gstreamer1.0-pulseaudio1.4.0-1 ii gtk2-engines 1:2.20.2-3 ii gucharmap 1:3.12.1-1 ii gvfs-backends 1.20.2-1 ii gvfs-bin 1.20.2-1 ii gvfs-fuse 1.20.2-1 ii iceweasel 31.0-3 ii libatk-adaptor 2.12.1-1+b1 ii libcanberra-pulse 0.30-2 ii libcaribou-gtk-module 0.4.13-1 ii libcaribou-gtk3-module 0.4.13-1 ii libgtk-3-common3.12.2-2 ii libpam-gnome-keyring 3.8.2-2+b1 ii metacity 1:3.12.0-2 ii mousetweaks3.12.0-1 ii nautilus 3.12.2-1 ii notification-daemon0.7.6-1 ii policykit-1-gnome 0.105-2 ii pulseaudio 5.0-6 ii sound-theme-freedesktop0.8-1 ii tracker-gui1.0.2-1+b1 ii vino 3.12.0-2 ii yelp 3.12.0-1 ii zenity 3.12.1-1.1 Versions of packages gnome-core recommends: ii anacron2.3-21 ii network-manager-gnome 0.9.10.0-2 Versions of packages gnome-core suggests: pn gnome none -- no debconf information # GDM configuration storage # # See /usr/share/gdm/gdm.schemas for a list of available options. [daemon] # Enabling automatic login # AutomaticLoginEnable = true # AutomaticLogin = user1 # Enabling timed login # TimedLoginEnable = true # TimedLogin = user1 # TimedLoginDelay = 10 AutomaticLoginEnable=true AutomaticLogin=kim [security] [xdmcp] [greeter] # Only include selected logins in the greeter # IncludeAll = false # Include = user1,user2 [chooser] [debug] # More verbose logs # Additionally lets the X server dump core if it crashes # Enable = true
Bug#758880: linux-image-3.14-0.bpo.2-powerpc64: [ppc64] Kernel panic on shutdown
Package: src:linux Version: 3.14.13-2~bpo70+1 Severity: normal Dear Maintainer, Current backported version of Linux kernel running in qemu-system-ppc64 panics on shutdown with: [ 567.737855] Oops: Exception in kernel mode, sig: 4 [#1] [ 567.738864] SMP NR_CPUS=32 NUMA pSeries [ 567.739615] Modules linked in: loop ext4 crc16 mbcache jbd2 virtio_blk virtio_net virtio_pci virtio_ring virtio [ 567.740337] CPU: 0 PID: 4106 Comm: echo Not tainted 3.14-0.bpo.2-powerpc64 #1 Debian 3.14.13-2~bpo70+1 [ 567.740611] task: c0003ab2a410 ti: c0003ffe4000 task.ti: c0003e6f8000 [ 567.740692] NIP: d01f5258 LR: d01f5610 CTR: d01f5570 [ 567.740762] REGS: c0003ffe7830 TRAP: 0700 Not tainted (3.14-0.bpo.2-powerpc64 Debian 3.14.13-2~bpo70+1) [ 567.740830] MSR: 80089032 SF,EE,ME,IR,DR,RI CR: 48422028 XER: [ 567.741096] CFAR: d01f51e4 SOFTE: 0 GPR00: c0003ffe7ab0 d01ff108 3b72a7c0 GPR04: 0002 0002 1b1e GPR08: 0001 c0003ac68020 c0003ac68000 24fe GPR12: d024f118 cfffa000 0001 c08354b8 GPR16: c09d5af0 c0003aa40430 0017 0001 GPR20: c09d25c8 c09d25c8 c0003aa40380 GPR24: c0987800 c0ac5c68 GPR28: c0003abc4690 c0003ab89800 0020 c0003ab89800 [ 567.742593] NIP [d01f5258] .detach_buf+0xb8/0xe0 [virtio_ring] [ 567.742652] LR [d01f5610] .virtqueue_get_buf+0xa0/0x180 [virtio_ring] [ 567.742732] Call Trace: [ 567.742894] [c0003ffe7ab0] [d01f5268] .detach_buf+0xc8/0xe0 [virtio_ring] (unreliable) [ 567.743019] [c0003ffe7b40] [d01f5610] .virtqueue_get_buf+0xa0/0x180 [virtio_ring] [ 567.743088] [c0003ffe7bc0] [d024d35c] .virtblk_done+0x7c/0x100 [virtio_blk] [ 567.743161] [c0003ffe7c70] [d01f594c] .vring_interrupt+0x7c/0x100 [virtio_ring] [ 567.743543] [c0003ffe7cf0] [c011b688] .handle_irq_event_percpu+0xc8/0x370 [ 567.743606] [c0003ffe7e00] [c011b988] .handle_irq_event+0x58/0xb0 [ 567.743686] [c0003ffe7e80] [c0120060] .handle_fasteoi_irq+0xd0/0x1d0 [ 567.743754] [c0003ffe7f00] [c0011104] .__do_irq+0xb4/0x200 [ 567.743820] [c0003ffe7f90] [c00229e8] .call_do_irq+0x14/0x24 [ 567.743886] [c0003e6fb720] [c00112dc] .do_IRQ+0x8c/0x100 [ 567.743953] [c0003e6fb7c0] [c0002268] hardware_interrupt_common+0x168/0x180 [ 567.744061] --- Exception: 501 at .arch_local_irq_restore+0x74/0x90 [ 567.744061] LR = .arch_local_irq_restore+0x74/0x90 [ 567.744152] [c0003e6fbab0] [c00108b8] .arch_local_irq_restore+0x38/0x90 (unreliable) [ 567.744241] [c0003e6fbb20] [c00e95e4] .finish_task_switch+0x74/0x190 [ 567.744316] [c0003e6fbbb0] [c06e792c] .__schedule+0x2dc/0x860 [ 567.744402] [c0003e6fbe30] [c000a788] .ret_from_except_lite+0x34/0x60 [ 567.744475] Instruction dump: [ 567.744731] 38090001 901f002c e8010010 ebc1fff0 ebe1fff8 7c0803a6 4e800020 6000 [ 567.744863] 6000 6000 7c6af02a 3800 0001 7844 [ 567.745331] ---[ end trace 3a346b1e72d4d1aa ]--- [ 567.761814] [ 569.762595] Kernel panic - not syncing: Fatal exception in interrupt Currently I don't have a spare LPAR to test this on a real hardware, but using latest qemu from the backports this issue reproduces 100%. Qemu commandline is (using libvirt, sorry for the length): /usr/bin/qemu-system-ppc64 -name wheezy-ppc -S -machine pseries,accel=tcg,usb=off -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 2dfb78af-46ee-4540-8814-971d1797c910 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/wheezy-ppc.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -drive file=/var/lib/libvirt/images/wheezy_ppc.raw,if=none,id=drive-virtio-disk0,format=raw,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x2,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:16:3e:f1:db:16,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,reg=0x3000 -global spapr-nvram.reg=0x3000 -cpu POWER7 -- Package-specific info: ** Version: Linux version 3.14-0.bpo.2-powerpc64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-11) ) #1 SMP Debian 3.14.13-2~bpo70+1 (2014-07-31) ** Command line: root=UUID=e17a8c34-1eb6-4a70-a536-d215abcb84ae ro quiet ** Not tainted ** Kernel log: [0.023957] Yama: disabled by default; enable with sysctl kernel.yama.* [0.027287] Dentry cache hash table entries: 131072
Bug#721352: ustr: do not use cross-built binaries during the build
Dear Peter, Thank you very much for your precise step by step guide! I think you should public it somewhere, maybe wiki.debian.org. On Sun, Aug 17, 2014 at 10:51:11PM +0300, Peter Pentchev wrote: ... OK, so it wasn't quite simple, but, well, I do believe this is still one of the simplest ways to create a cross-build environment from scratch on a recent Debian system. Here's hoping that this didn't scare you too much, and here's hoping that it actually helped :) :). I started to play with bootstrap.sh. (There are some chunks of patches, that are applied upstream (gcc-4.9) and need to be dropped in bootstrap.sh.) Thank you very much for your great help! Cheers -- Zito -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702882: Status of igraph packaging for Debian
On Thu, Aug 21, 2014 at 8:33 AM, Andreas Tille andr...@fam-tille.de wrote: Hi Tamás, I realised that there remains an open bug to version 0.6.5. Could you please check whether this exists or not. Mathieu, what do you think? I am not interested in igraph anymore: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729516 the remaining bug is still the same as back with our previous discussion: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702882#77 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725411: gnupg: gpg blindly imports keys from keyserver responses
Hi Paul, tags 725411 + security This bug has been fixed in GnuPG 1.4.17. Although it's a good robustness and anti-keyring-polution measure, I don't think it's an acute security issue in stable that needs to be fixed in a DSA, because the threat model is unclear to me. I think it's well understood that keyservers are not trustworthy per se and that the web of trust is to be used to verify which keys are to be trusted. If you need to rely on a keyserver not being rogue you've already lost. Any key injected in such a download would still not pass web of trust validation. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758881: qemu-system-x86: VNC server can't get all sent chars correctly
Package: qemu-system-x86 Version: 2.1+dfsg-3 Severity: normal Dear Maintainer, To reproduce it: Install vncdo: $ sudo apt-get install python-twisted python-imaging $ git clone https://github.com/sibson/vncdotool $ cd vncdotool/ $ sudo python setup.py install $ curl -L -z linux -o linux http://ftp.it.debian.org/debian/dists/wheezy/main/installer-amd64/current/images/netboot/gtk/debian-installer/amd64/linux $ curl -L -z initrd.gz -o initrd.gz http://ftp.it.debian.org/debian/dists/wheezy/main/installer-amd64/current/images/netboot/gtk/debian-installer/amd64/initrd.gz $ sudo qemu-system-x86_64 -display vnc=localhost:10 -enable-kvm -cpu host -m 1024 -net nic,vlan=0 -net user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254 --kernel linux --initrd initrd.gz --append locale=en_US keymap=us video=vesa:ywrap,mtrr vga=788 To follow installation: $ gvncviewer localhost:10 Few seconds and install will stop at Configure the network - Enter hostname Quit gvncviewer. $ vncdo -s localhost:10 type insecure [ insecure is current jenkins user password in g-i-installation jobs at jenkins.debian.net] $ gvncviewer localhost:10 Sometimes first e is not received (inscure), last one always gets repeated as if e key was kept pressed, sometimes both. Downgrading qemu to 2.0.0+dfsg-7, everything works fine. Same behavior with backported packages, jenkins.d.n uses wheezy-backports ones (2.1+dfsg-2~bpo70+2 KO, 2.0.0+dfsg-4~bpo70+1 OK). -- G..e -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758882: isc-dhcp-client: dhclient prevents remounting / in read-only when jessie booted in recovery mode
Package: isc-dhcp-client Version: 4.3.1-1 Severity: important Dear Maintainer, I'm not sure this really belongs to isc-dhcp-client, and may deserve attention from other maintainers, but I couldn't find a better place for reportbug. If a debian jessie system is rebooted with grub's default recovery mode, and if there's no separate /var partition, the / partition cannot be remunted read-only, because there's a lease file used by dhclient inside /var. mount -n -o remount,ro will report : mount: / is busy Indeed /var/lib/dhcp/dhclient.eth0.leases is reported as opened in w mode by lsof. I believed it may not be ideal to keep dhclient running when in recovery mode, although I'm not qualified enough to know whether it's systemd's duty to stop it for instance. In any case, killall dhclient is a workaround that allows remounting / read-only. Hope this helps. Thanks in advance. Best regards, -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages isc-dhcp-client depends on: ii debianutils 4.4 ii iproute2 3.16.0-1 ii isc-dhcp-common 4.3.1-1 ii libc62.19-9 isc-dhcp-client recommends no packages. Versions of packages isc-dhcp-client suggests: ii avahi-autoipd 0.6.31-4 ii resolvconf 1.75 -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758883: check-mk: CVE-2014-5339 CVE-2014-5340
Source: check-mk Version: 1.2.2p3-1 Severity: grave Tags: security upstream fixed-upstream Hi, the following vulnerabilities were published for check-mk. CVE-2014-5339[0]: Write access to config (.mk) files in arbitrary places on the filesystem CVE-2014-5340[1]: Code executing due to insecure input handling If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2014-5339 [1] https://security-tracker.debian.org/tracker/CVE-2014-5340 [2] http://packetstormsecurity.com/files/127941/DTC-A-20140820-001.txt Regards, Salvatore -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
On Thu, 21 Aug 2014 19:26:44 -0400 (EDT)
Stephen Powell zlinux...@wowway.com wrote:
Here are the last few instructions prior to the failure on the failing
version, thanks to the CP TRACE facility under z/VM on a real IBM z/890:
2A78 STG E310F0A80024 FEB0 CC 2
2A7E LG E320300401B0 CC 2
2A84 LG E3103008000401B8 CC 2
2A8A STG E3403024 01B0 CC 2
2A90 LA 4140F0A0 = FEA8 CC 2
2A94 LARLC05BCC 2
2A9A STG E35040080024 FEB0 CC 2
2AA0 STG E35030080024 01B8 CC 2
2AA6 LPSWE B2B2F0A0FEA8 CC 0
2AAA LMG EBDFF0B4 CC 0
2AB0 STG E3203024 01B0 CC 0
2AB6 STG E31030080024 01B8 CC 0
2ABC BR 07FE - 32E6 CC 0
- 32E6 LH 481000860086 CC 0
32EA BRU A7F40001 - 32EC CC 0
- 32EC 0001
*** 32EC PROG0001 - 39A8
And here is what appears to be the equivalent code on the working
version, compiled under wheezy:
2A38 STG E310F0A80024 FEA0 CC 2
2A3E LG E320300401B0 CC 2
2A44 LG E3103008000401B8 CC 2
2A4A STG E3403024 01B0 CC 2
2A50 LA 4140F0A0 = FE98 CC 2
2A54 LARLC05BCC 2
2A5A STG E35040080024 FEA0 CC 2
2A60 STG E35030080024 01B8 CC 2
2A66 LPSWE B2B2F0A0FE98 CC 0
2A6A LMG EBDFF0B4 CC 0
2A70 STG E3203024 01B0 CC 0
2A76 STG E31030080024 01B8 CC 0
2A7C BR 07FE - 32C0 CC 0
- 32C0 LLGHE310008600910086 CC 0
32C6 CHI A71E1004CC 2
32CA BRZ A784000A32DE CC 2
...
And on we go from there. The BRU instruction in the first sequence
is clearly bad. In assembler language format, the equivalent instruction
would be BRU *+2. This is a bad branch. The instruction branches
into the middle of itself, picking up 0001 as the next machine instruction,
which causes an operation exception. Since the failing instruction
starts at storage address 32EC, and is two bytes long, that means that
the updated instruction address in the PSW at the time of the program
interruption will be 32EE, which is the value used in the disabled wait
PSW.
Hi Stephen,
You can get a disassembly for the eckd boot loader code when you go
to s390-tools/zipl/boot and:
1) make
2) objdump -S eckd2.exec eckd2.list
I think the corresponding code in zipl is load_wait_psw() in libc.c:
__attribute__ ((noinline)) void load_wait_psw(uint64_t psw_mask, struct psw_t
*psw)
{
struct psw_t wait_psw = { .mask = psw_mask, .addr = 0 };
2df6: e3 20 f0 a0 00 24 stg %r2,160(%r15)
struct psw_t old_psw, *wait_psw_ptr = wait_psw;
unsigned long addr;
old_psw = *psw;
psw-mask = 0x00018000ULL;
2dfc: e3 10 30 00 00 24 stg %r1,0(%r3)
asm volatile(
2e02: 41 20 f0 a0 la %r2,160(%r15)
{
struct psw_t wait_psw = { .mask = psw_mask, .addr = 0 };
struct psw_t old_psw, *wait_psw_ptr = wait_psw;
unsigned long addr;
old_psw = *psw;
2e06: e3 10 30 08 00 04 lg %r1,8(%r3)
psw-mask = 0x00018000ULL;
asm volatile(
2e0c: c0 50 00 00 00 0b larl%r5,2e22 load_wait_psw+0x5a
2e12: e3 50 20 08 00 24 stg %r5,8(%r2)
2e18: e3 50 30 08 00 24 stg %r5,8(%r3)
2e1e: b2 b2 f0 a0 lpswe 160(%r15)
.Lwait:\n
: [addr] =d (addr)
: [wait_psw] Q (wait_psw), [wait_psw_ptr] a (wait_psw_ptr),
[psw] a (psw)
: cc, memory);
*psw = old_psw;
2e22: e3 40 30 00 00 24 stg %r4,0(%r3)
2e28: e3 10 30 08 00 24 stg %r1,8(%r3)
}
2e2e: eb df f0 b0 00 04 lmg %r13,%r15,176(%r15)
2e34: 07 fe br %r14
load_wait_psw() is called from
Bug#758884: jenkins.d.n: broken qemu vncserver, please downgrade or apply workaround
Package: qa.debian.org Severity: wishlist User: qa.debian@packages.debian.org Usertags: jenkins Dear Maintainer, qemu 2.1 vncserver is broken, see #758881. Please downgrade qemu to 2.0.0+dfsg-4~bpo70+1 and apt-mark-hold it or apply patch from my vncdoworkaround branch@github. Thanks for considering. -- G..e -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742508: [Python-modules-team] Bug#742508: python-rgain: collectiongain is unusable
Control: tag -1 pending Hi Christian Quoting Christian Marillat (2014-03-24 16:23:57) Package: python-rgain Version: 1.2-1 Severity: serious Dear Maintainer, collectiongain (amd replaygain) doesn't work at all : Dispatching jobs ... Now waiting for results ... Unfortunately, there were some errors: 10cc - The original soundtrack: Calculating Replay Gain information ... Musique/10cc/1975 - The original soundtrack/01 - Nuit a Paris, pt. 1- one night in Paris-pt. 2- the same night in Paris.mp3: Error while calculating gain - GST error: Your GStreamer installation is missing a plug-in. (gstdecodebin2.c(3928): gst_decode_bin_expose (): /GstPipeline:pipeline0/GstDecodeBin:decbin: no suitable plugins found) The plugin in question is actually needed to play MP3 files, and isn't in the same package as the replaygain package. I've added it to the recommends, it is in gstreamer1.0-plugins-bad (you might want to install it manually since I have to find a sponsor for the upload). Sorry for the delay! Cheers, Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758885: Please support compilation of non-native ruby interpreter support
Package: ruby-passenger Severity: wishlist Version: 4.0.37-3 Please install these files into the ruby-passenger binary package: dh_install: usr/share/passenger/ruby_extension_source/extconf.rb exists in debian/tmp but is not installed to anywhere dh_install: usr/share/passenger/ruby_extension_source/passenger_native_support.c exists in debian/tmp but is not installed to anywhere Ruby Passenger 4 can handle utilizing different ruby interpreter versions on different passenger instances simultaneous. For some ruby interpreter versions native extensions are already provided / compiled. For other ruby interpreter versions, the site admin can compile an extension for his/her favourite ruby interpreter version post-package-installation. For this to work, the above files need to be installed into bin:package ruby-interpreter. Greets+Thanks, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgp39oWQIDwE8.pgp Description: Digitale PGP-Signatur
Bug#754286: [Python-modules-team] Bug#754286: python-rgain: new upstream version (1.3.2) supports more file types
Control: tag -1 pending Hi Rogério, Quoting Rogério Brito (2014-07-09 16:28:49) Package: python-rgain Version: 1.2-1 Severity: wishlist Hi. The version of python-rgain that we have in Debian is very old and doesn't support some file formats that the new upstream (version 1.3.2, from 2014-05-24) supports. It would be super nice to have a new version of python-rgain in Debian, so that those files can be properly controlled without clipping. It would be nice, indeed :-). I've committed a new version to the team's SVN repo, it should get sponsored really soon. Cheers, Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758886: sunxi-tools: Requires u-boot-tools to build which is no longer available for powerpc
Package: sunxi-tools Version: 1.2-1 Severity: serious Justification: fails to build from source (but built successfully in the past) u-boot has dropped powerpc from its supported architectures, so this package will no longer build on powerpc as currently packaged. It needs to be adapted to build on powerpc without u-boot-tools. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751907: libffi6: cannot enable executable stack as shared object requires: Permission denied
Control: severity -1 important when using grsecurity/pax protections so nothing is broken for a default install. patch should be available from: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=blob;f=dev-libs/libffi/files/libffi-3.0.12-emutramp_pax.patch;h=4799b227e8510c3a254a97355f341d7f8af404f0;hb=6eeb6a6c620ee84e411f989cc246212422e8b636 no, it is not. times out. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#134661: Fw: util-linux patch - add option to whereis
Adding a [-q, --quiet] option does not seem necessary. Requested output format can be created on fly with a simple output filter without making the whereis(1) more complex. $ ls -l $(whereis command | cut -d: -f 2) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758887: RM: stomper -- ROM; Dropped by its rdep, moksha
Package: ftp.debian.org Severity: normal Hi, This package used to be a dependency of the moksha suite, but this dependency has been dropped some time ago. Since I don't have any interest in the package itself, nor does it have a high popcon, I suggest dropping it from the archive. Cheers, Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758888: lmms: Provide links to LADSPA plugins in /usr/lib/ladspa
Package: lmms Version: 1.0.0-1 Severity: wishlist Dear Maintainer, lmms provides quite a few LADSPA plugins, what about making them available to other programs too? Other programs look for LADSPA plugins in some standard location like for instance /usr/lib/ladspa, if the plugins provided by lmms were reachable from there they could be shared with those other programs. For example I wanted to use the vocoder plugin with GStreamer or with Audacity, in order to do that it was enough to create a symlink to the shared object in the aforementioned location: $ ln -s /usr/lib/x86_64-linux-gnu/lmms/ladspa/vocoder_1337.so /usr/lib/ladspa Now GStreamer finds the plugin: $ gst-inspect-1.0 ladspa | grep vocoder ladspa-vocoder-1337-so-vocoder-lmms: Vocoder for LMMS Maybe as a long term solution an lmms-plugins package could be created putting the shared objects in /usr/lib/ladspa and have lmms look for them in there. Similar packages exist already, you can see them with apt-file: $ apt-file search /usr/lib/ladspa/ I don't know if this will play nicely with multi-arch, and there will be some conflicts if plugins with the same name are provided by different packages, but it's still worth considering IMHO. Thanks, Antonio -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-ao2 (SMP w/1 CPU core) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lmms depends on: ii libasound21.0.28-1 ii libc6 2.19-9 ii libfftw3-single3 3.3.4-1 ii libfluidsynth11.1.6-2 ii libfontconfig12.11.0-6.1 ii libgcc1 1:4.9.1-8 ii libjack0 [libjack-0.116] 1:0.124.1+20140122git5013bed0-3 ii libogg0 1.3.2-1 ii libportaudio2 19+svn20140130-1 ii libpulse0 5.0-6 ii libqt4-xml4:4.8.6+git49-gbc62005+dfsg-1 ii libqtcore44:4.8.6+git49-gbc62005+dfsg-1 ii libqtgui4 4:4.8.6+git49-gbc62005+dfsg-1 ii libsamplerate00.1.8-8 ii libsdl1.2debian 1.2.15-10 ii libsndfile1 1.0.25-9 ii libstdc++64.9.1-8 ii libstk0c2a4.4.4-5+b1 ii libvorbis0a 1.3.2-1.4 ii libvorbisenc2 1.3.2-1.4 ii libvorbisfile31.3.2-1.4 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.2-1 ii libxft2 2.3.2-1 ii libxinerama1 2:1.1.3-1 ii lmms-common 1.0.0-1 ii stk 4.4.4-5+b1 ii zlib1g1:1.2.8.dfsg-2 Versions of packages lmms recommends: ii caps 0.9.23-1 ii tap-plugins 0.7.3-1 Versions of packages lmms suggests: pn fil-plugins none ii fluid-soundfont-gm 3.1-5 ii freepats20060219-1 pn mcp-plugins none pn omins none -- no debconf information -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748983: xcb-util: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4
Hi Cyril, On 08/21/2014 04:49 PM, Mauricio Faria de Oliveira wrote: I'm anyway attaching the list of packages installed on one of these chroots, in case it helps someone figure out what the problem is. Ok, thanks. I'll take a look at it. I looked at it, reproduced the package list to what was possible, forced things a bit, but still could not reproduce that failure. Details of those points: 1) package list I reproduced the package list you sent to the extent it was possible -- some packages don't exist anymore (boost1.53, python3.3, libgnutls28). Some have been gone for a while now (libgnutls28 is June 5 IIRC), so the failure might be related to an old environment as well. I am attaching the package-list diff between my environment and yours. I can't find anything on it that seems to influence autoreconf programs. 2) differences in CDBS? (forced things a bit) I noticed the build log you pasted have no output for 2 CDBS targets: update-config and reverse-config (/usr/share/cdbs/1/rules/buildcore.mk), My 'debuild -b' build log diffs here: rm -f Doxyfile .gitmodules autogen.sh +for i in ./config.guess ./config.sub ; do \ + if test -e $i.cdbs-orig ; then \ + mv $i.cdbs-orig $i ; \ + fi ; \ +done if test -e debian/autoreconf.before; then \ [...] mkdir -p . +if test -e /usr/share/misc/config.guess ; then \ + for i in ./config.guess ; do \ + if ! test -e $i.cdbs-orig ; then \ + mv $i $i.cdbs-orig ; \ + cp --remove-destination /usr/share/misc/config.guess $i ; \ + fi ; \ + done ; \ +fi +if test -e /usr/share/misc/config.sub ; then \ + for i in ./config.sub ; do \ + if ! test -e $i.cdbs-orig ; then \ + mv $i $i.cdbs-orig ; \ + cp --remove-destination /usr/share/misc/config.sub $i ; \ + fi ; \ + done ; \ +fi dh_autoreconf By reading those build targets' source, the only way I can reproduce that text to be missing (trying to match your build) is by *removing* config.guess/sub. But even with that, autoreconf (and the build) finished successfully: $ rm -f config.guess config.sub $ debuild -b [...] rm -f Doxyfile .gitmodules autogen.sh if test -e debian/autoreconf.before; then \ dh_autoreconf_clean ; \ fi dh_clean rm -f debian/stamp-autotools-files debian/rules build test -x debian/rules mkdir -p . dh_autoreconf libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' libtoolize: Remember to add `LT_INIT' to configure.ac. configure.ac:10: installing './compile' configure.ac:10: installing './config.guess' configure.ac:10: installing './config.sub' test -f configure || sh ./autogen.sh [...] touch configure-stamp [...] That said (i.e., our builds have the 'same' package list, and the same build log until dh_autoreconf is run), now I ran out of things to try. I would ask you please consider testing the build on another environment -- more closely matching an official build one. .. or to provide me some more clues about your build environment. Thank you, -- Mauricio Faria de Oliveira IBM Linux Technology Center --- mauricfo.packages.list.pkg_ver 2014-08-22 09:27:38.155310189 -0300 +++ packages.list.pkg_ver 2014-08-22 08:55:40.851192806 -0300 @@ -125,0 +126 @@ +libboost-iostreams1.53.0 1.53.0-6+b2 @@ -135 +136 @@ -libcap-ng0:amd64 0.7.4-2 +libcap-ng0:amd64 0.7.4-1 @@ -146 +146,0 @@ -libcryptsetup4:amd64 2:1.6.6-1 @@ -153,0 +154 @@ +libdb5.1:amd64 5.1.29-7 @@ -158 +158,0 @@ -libdevmapper1.02.1:amd64 2:1.02.88-1 @@ -167,2 +167,2 @@ -libegl1-mesa:amd64 10.2.6-1 -libegl1-mesa-drivers:amd64 10.2.6-1 +libegl1-mesa:amd64 10.2.5-1 +libegl1-mesa-drivers:amd64 10.2.5-1 @@ -190 +190 @@ -libgbm1:amd64 10.2.6-1 +libgbm1:amd64 10.2.5-1 @@ -200,3 +200,3 @@ -libgl1-mesa-dri:amd64 10.2.6-1 -libgl1-mesa-glx:amd64 10.2.6-1 -libglapi-mesa:amd64 10.2.6-1 +libgl1-mesa-dri:amd64 10.2.5-1 +libgl1-mesa-glx:amd64 10.2.5-1 +libglapi-mesa:amd64 10.2.5-1 @@ -212,0 +213 @@ +libgnutls28:amd64 3.2.14-1 @@ -257,0 +259 @@ +liblognorm0 0.3.7-1 @@ -271,0 +274 @@ +libmozjs24d 24.5.0esr-1 @@ -291 +294 @@ -libopenvg1-mesa:amd64 10.2.6-1 +libopenvg1-mesa:amd64 10.2.5-1 @@ -315,0 +319,2 @@
Bug#750631: [bug #750631] kbd does not set settings
Hi, I also stumbled over this bug when testing Jessie Beta 1 (which uses systemd). Extending /etc/init.d/kbd with debug information showed that following part of the setup function causes it to exit: if [ ! $CONSOLE_TYPE = serial ]; then readlink /proc/self/fd/0 | grep -q -e /dev/vc -e '/dev/tty[^p]' -e /dev/console if [ $? -eq 0 ]; then VT=yes fi fi [ $VT = no ] return $(readlink /proc/self/fd/0) returns /dev/null. Therefore VT stays at no and the kbd init script exits before setting anything. How should it be fixed? -- Benjamin Drung System Developer ProfitBricks GmbH - The IaaS-Company Greifswalder Str. 207 D - 10405 Berlin Mail: benjamin.dr...@profitbricks.com Fax: +49 30 577 008 598 URL: http://www.profitbricks.com Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506 B. Geschäftsführer: Andreas Gauger, Achim Weiss. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748983: xcb-util: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4
Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com (2014-08-22): That said (i.e., our builds have the 'same' package list, and the same build log until dh_autoreconf is run), now I ran out of things to try. I would ask you please consider testing the build on another environment -- more closely matching an official build one. .. or to provide me some more clues about your build environment. Oh. Since the whole idea was committing stuff to git and uploading, I'm “of course” (at least to me but I should really have mentioned that) building from a “debcheckout xcb-util”. It looks possible that differences in behaviour might be caused by the files that are(n't) tracked in git, as opposed to those in the tarball. :/ It'd be nice if a regular maintainer would comment on this. Mraw, KiBi. signature.asc Description: Digital signature
Bug#755416: shotwell adoption
Hallo László, Am Freitag, den 22.08.2014, 10:14 +0200 schrieb László Böszörményi: Hi Jörg, How the Shotwell adoption goes? I'm a DD and have an almost ready package to upload. If you just need more time, I can can step back. Otherwise I'd be glad to continue with the package maintenance. My package is uploaded to mentors and I'm waiting for the upload of my sponsor. But if you want to take over Shotwell you can adopt it gladly. Regards, Laszlo/GCS CU Jörg -- pgp Fingerprint: 7D13 3C60 0A10 DBE1 51F8 EBCB 422B 44B0 BE58 1B6E pgp Key: BE581B6E CAcert Key S/N: 0E:D4:56 Jörg Frings-Fürst D-54526 Niederkail Threema: SYR8SJXB IRC: j_...@freenode.net j_...@oftc.net signature.asc Description: This is a digitally signed message part
Bug#758289: package in NEW not listed as pending upload
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 22 August 2014 12:29, Jonas Smedegaard d...@jones.dk wrote: The package libmoox-cmd-perl is in the NEW queue: https://ftp-master.debian.org/new/libmoox-cmd-perl_0.009-1.html ...but still - after several days - lists as Owned WNPP bugs, not Pending uploads at my DDPO page: https://qa.debian.org/developer.php?login=d...@jones.dkcomaint=yes There is already a bug report about it, replying to it right now. As an additional data point, it seems to have stopped working early this month, probably Mon, 04 Aug 2014, since php-symfony-icu is marked as NEW for 20 hours [0] while it was uploaded on Sun, 03 Aug 2014. 0: https://qa.debian.org/developer.php?login=pkg-php-p...@lists.alioth.debian.org#php-symfony-icu Regards David -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJT90J4AAoJEAWMHPlE9r08lAAH/2/F03PBvdLPVgJ1SvFz35BY iOkFvAYS7b7yFYWYT93WBs8V7OlvOZDO8PZy38PalmpImXzWUxA/C3xYg+py+BX1 aHBuyJiMn0Eb72w7+uabYEM/uE/p29aLMaPe38MEizdFr2Vg28755LGFfpEyWu+v 03yN3jziKKFZMM+RrE+cA+EbkrqzZXBivwrf3AtoAZpC5rqaUj/FDxpH8CKWWL34 hPHWCUUX/jn6HT9KDe2NL9DcrMNvtj3aIFaVv7eG75AtWGJTbyaFo456wsrc9CdF muA9YtyvoJEfHrK5aGPQMwFZYq5dtV+KbJ3cn9zXX6xJ/AIhZ721cQ1Pa59yNP4= =v1nx -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#758889: RFP: node-yamlish -- Parser/encoder for the YAMLish format
Package: wnpp Severity: wishlist * Package name: node-yamlish Version : 0.0.6 Upstream Author : Isaac Z. Schlueter i...@izs.me * URL : https://github.com/isaacs/yamlish * License : Expat Programming Lang: JavaScript Description : Parser/encoder for the YAMLish format for Node.js This library parses the YAMLish format used to serialize objects in the TAP format. YAMLish is a small subset of YAML (originally that implemented by the Perl module YAML::Tiny), making it easy to implement in other languages. . Node.js is an event-based server-side JavaScript engine. I will maintain this in the Javascript team. This is a dependency of node-tap (bug #661779). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757987: kfreebsd: cannot create swap space
reassign 757987 partman-basicfilesystems found 757987 partman-basicfilesystems/96 tags 757987 + patch user debian-...@lists.debian.org usertags + kfreebsd thanks Hi, partman-basicfilesystems 96 added commit.d/format_swap, which uses mkswap (a Busybox utility for formatting Linux swap space) for any type of swap partition. mkswap, and the whole format_swap script, is of no use to kfreebsd (or hurd I presume - please correct me if I'm wrong); on kfreebsd we don't need to format our swap space to use it. This patch exits early from the script on non-Linux architectures. I've used $(archdetect) here to be consistent with check.d/ext2_boot; the limitation is that this doesn't allow for a linux-* pattern patch, so I had to list all (2) of the non-linux architecture prefixes. I've tested this on kfreebsd-amd64, and also that swap space still gets mounted when partman is finished. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org * Skip commit.d/format_swap on kfreebsd-* and hurd-*, which don't need to format their swap partitions diff --git a/commit.d/format_swap b/commit.d/format_swap index e2dc4b0..dc72032 100755 --- a/commit.d/format_swap +++ b/commit.d/format_swap @@ -1,5 +1,17 @@ #!/bin/sh +ARCH=$(archdetect) + +# The mkswap utility only supports Linux swap partitions; skip running +# the rest of this script on other architectures +case $ARCH in +hurd-*|kfreebsd-*) +exit 0 +;; +*) +;; +esac + . /lib/partman/lib/base.sh for dev in $DEVICES/*; do
Bug#757987: kfreebsd: cannot create swap space
Steven Chamberlain, le Fri 22 Aug 2014 14:42:45 +0100, a écrit : mkswap, and the whole format_swap script, is of no use to kfreebsd (or hurd I presume - please correct me if I'm wrong) hurd uses the same format as Linux, do not disable formatting swap there. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757987: kfreebsd: cannot create swap space
On 22/08/14 14:48, Samuel Thibault wrote: hurd uses the same format as Linux, do not disable formatting swap there. Thanks, that's surprising; glad I asked. New patch attached. Regards, -- Steven Chamberlain ste...@pyro.eu.org * Skip commit.d/format_swap on kfreebsd-*, whose swap partitions do not need to be formatted (Closes: #757987) diff --git a/commit.d/format_swap b/commit.d/format_swap index e2dc4b0..dc3ea08 100755 --- a/commit.d/format_swap +++ b/commit.d/format_swap @@ -1,5 +1,18 @@ #!/bin/sh +ARCH=$(archdetect) + +# The mkswap utility only supports Linux-type swap partitions, used +# on Linux and Hurd; do not use it on kfreebsd which does need to +# format swap partitions +case $ARCH in +kfreebsd-*) +exit 0 +;; +*) +;; +esac + . /lib/partman/lib/base.sh for dev in $DEVICES/*; do
Bug#758616: dpkg: support installing M-A:same packages with different binNMU version
Control: unmerge -1 On Fri, 2014-08-22 at 11:46:54 +0200, Emilio Pozuelo Monfort wrote: On 21/08/14 00:21, Guillem Jover wrote: On Tue, 2014-08-19 at 11:25:19 +0200, Emilio Pozuelo Monfort wrote: Package: dpkg Version: 1.17.11 Severity: wishlist Currently M-A:same packages with different versions can't be co-installed. That prevents packages that have been binNMUed in one architecture but not another to be co-installed, e.g. libfoo_1.1-1:i386 libfoo_1.1-1+b1:amd64 or libfoo_1.1-1+b1:i386 libfoo_1.1-1+b2:amd64 Can't be co-installed. This is problematic because packages get binNMU on a subset of architectures very often (whenever it's not needed to binNMU them everywhere). See e.g. #758527. Yes, extensively discusssed in the mailing lists and already filed, this is just a different side of the same assumptions. Merging. I saw #684625 but thought it was the old problem that installing +b1:i386 and +b1:amd64 failed because of the different changelogs, problem that was solved / worked around by adding binnmu changelog entries in separate changelogs. Right, and although both issues prevent co-installation, thinking about it, that issue has not been fixed in dpkg itself, and they might require different fixes. So, yeah I guess it does make sense to have in different bug reports. Umerging. Anyway, can you provide an update on this? Has there been any progress? I'm still not very comfortable with the possible implications of the proposed solution (i.e. using the source version for comparison). I'll be pondering about it, because I want to resolve most if not all multi-arch issues in dpkg before the freeze, though. 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#758890: lua-filesystem: FTBFS on hurd-i386
Source: lua-filesystem Version: 1.6.2-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, lua-filesystem fails to build from source on GNU/Hurd due to MAXPATHLEN usage in src/lfs.c, which is not defined. Since the source comment says that getcwd(NULL,0) is not guaranteed to work, use _POSIX_PATH_MAX as a last resort. The attached patch fixes this problem. Additionally the six tests pass enabling the packages to build. In case the package had been using configure a test for a working getcwd (NULL, 0) could have been included, and the source modified accordingly. Thanks! --- a/src/lfs.c.orig 2012-10-04 16:00:22.0 +0200 +++ b/src/lfs.c 2014-08-22 15:29:44.0 +0200 @@ -84,7 +84,12 @@ #define LFS_MAXPATHLEN MAX_PATH // MAX_PATH seems to be 260. Seems kind of small. Is there a better one? #else #include sys/param.h // for MAXPATHLEN -#define LFS_MAXPATHLEN MAXPATHLEN +#ifdef MAXPATHLEN + #define LFS_MAXPATHLEN MAXPATHLEN +#else + #include limits.h // for _POSIX_PATH_MAX + #define LFS_MAXPATHLEN _POSIX_PATH_MAX +#endif #endif #endif
Bug#755154: vlc cache gen should happen at runtime, not buildtime
Am Freitag, den 22.08.2014, 11:58 +0300 schrieb Rémi Denis-Courmont: But we are talking about the Debian packaging system here. Failing to install means screwing up the whole oeprating system. I agree with Harald that it IMHO makes more sense to generate the plugin cache at install time against what is actually installed on the harddrive of the same system that vlc is going to get installed to. However, I think it would be a good idea to add plugin cache generation as an additional test during build phase. How about that? - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755154: vlc cache gen should happen at runtime, not buildtime
Le 2014-08-22 17:02, Fabian Greffrath a écrit : However, I think it would be a good idea to add plugin cache generation as an additional test during build phase. How about that? Unless Debian has pro-actively patched it out of the upstream build system, it's already being done. -- Rémi Denis-Courmont -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758725: package mrpt_1:1.2.1-1 FTBFS on i386, amd64, mips*
I will try to fix de-serialization problems on big endian.
For now i have tried to build package with your patches
1)
https://github.com/jlblancoc/mrpt/commit/9a878c0950edd8ca7de6f4584f920c4e0db05ecc
2)
https://github.com/jlblancoc/mrpt/commit/289498fc34703c2fcf6b61e72c3311144e5fb570
and ifdef workaround
3)
https://github.com/jlblancoc/mrpt/commit/c06ed1c384ba2e719c52f65a1a49bddcf7d261e5
and the patch
4) mips-patch.diff (attached in this mail)
With these changes I was able to build package on mips*
For strict alignment, as far as I know, there is no macro that could be used
for detecting if a strict alignment is necessary.
I think that sparc also has alignment rules.
(maybe the best way to be sure about this is to ask porters for other
architectures to help with this issue).
Regards,
Jurica
From: Jose Luis Blanco [joseluisblan...@gmail.com]
Sent: 21 August 2014 19:11
To: Jurica Stanojkovic
Cc: 758...@bugs.debian.org
Subject: Re: Bug#758725: package mrpt_1:1.2.1-1 FTBFS on i386, amd64, mips*
So, the #ifdef workaround was incorrectly placed, to start with!
This patch will solve it:
https://github.com/jlblancoc/mrpt/commit/c06ed1c384ba2e719c52f65a1a49bddcf7d261e5
But obviously, that's not the ideal solution because that's resigning
trying to fix de-serialization problems!
I didn't know that issue about #pragma pack, it will be a problem.
Let me check it more in depth, but I'm sure the struct pack'ing is
taken for granted in some parts of the code. Actually, there's even
one unit test checking it...
Please, let me know whatever other unit tests don't pass in MIPS while
I think what to do with the pragmas.
BTW: Is there any macro to detect architectures with strict alignment rules?
JL
diff -upNr mrpt-1.2.1-old/libs/base/include/mrpt/math/lightweight_geom_data.h mrpt-1.2.1/libs/base/include/mrpt/math/lightweight_geom_data.h
--- mrpt-1.2.1-old/libs/base/include/mrpt/math/lightweight_geom_data.h 2014-07-10 16:18:40.0 +
+++ mrpt-1.2.1/libs/base/include/mrpt/math/lightweight_geom_data.h 2014-08-01 17:40:08.0 +
@@ -25,7 +25,9 @@ namespace math {
* @{ */
//Pragma defined to ensure no structure packing
+#ifndef __mips__
#pragma pack(push,1)
+#endif
//Set of typedefs for lightweight geometric items.
/**
* Lightweight 2D point. Allows coordinate access using [] operator.
@@ -238,7 +240,9 @@ namespace math {
static size_t size() { return 3; }
};
+#ifndef __mips__
#pragma pack(pop) // NOTE: Don't force TPoint3Df to be mem aligned (may break CPU mem access alignment in ARM)
+#endif
/** Lightweight 3D point (float version).
* \sa mrpt::poses::CPoint3D, mrpt::math::TPoint3D
@@ -261,7 +265,9 @@ namespace math {
};
+#ifndef __mips__
#pragma pack(push,1) //Pragma defined to ensure no structure packing
+#endif
/**
* Lightweight 3D point. Allows coordinate access using [] operator.
* \sa mrpt::poses::CPoint3D, mrpt::math::TPoint3Df
@@ -550,7 +556,9 @@ namespace math {
void fromString(const std::string s);
static size_t size() { return 7; }
};
+#ifndef __mips__
#pragma pack(pop)
+#endif
// Text streaming functions:
std::ostream BASE_IMPEXP operator (std::ostream o, const TPoint2D p);
@@ -621,7 +629,9 @@ namespace math {
struct BASE_IMPEXP TObject3D;
//Pragma defined to ensure no structure packing
+#ifndef __mips__
#pragma pack(push,1)
+#endif
/**
* 2D segment, consisting of two points.
* \sa TSegment3D,TLine2D,TPolygon2D,TPoint2D
@@ -761,7 +771,9 @@ namespace math {
bool operator(const TSegment3D s) const;
};
+#ifndef __mips__
#pragma pack(pop)
+#endif
inline bool operator==(const TSegment2D s1,const TSegment2D s2) {
return (s1.point1==s2.point1)(s1.point2==s2.point2);
Bug#757961: Does not work with GCC 4.9, default GCC in Jessie
On 21/08/2014 23:02, Tomasz Rybak wrote: Not necessarily. I'll build (and test) PyCUDA on my machine, then build amd64 and i386 packages in pbuilder. As building does not require running any kernels, but only presence of CUDA headers, it'll work without any problems. OK, great. BTW - do you plan to upload 6.0, or 6.5 before Jessie freeze? If so, I'll need to rebuild PyCUDA with new CUDA. I have a mostly working CUDA 6.0 package in my Ubuntu PPA. I am just waiting on someone to increase my PPA size so I can upload another version, hopefully in the next day or so. I think it then be will be ready to test and for Vincent to review and possibly upload to Experimental. It will still be missing a fix for #755513, but it can go through NEW without that. I'd still like to get 5.5 fixed for Ubuntu Utopic and Trusty though. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758891: lintian: False positive for dh_xine
Package: lintian Version: 2.5.25 Severity: normal Dear Maintainer, When I did a xine-ui rebuild lintian report : E: xine-ui source: missing-build-dependency-for-dh-addon xine = libxine-dev dh_xine is now packaged in libxine2-dev and not libxine-dev. Christian -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.16.1 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lintian depends on: ii binutils 2.24.51.20140818-1 ii bzip2 1.0.6-7 ii diffstat 1.58-1 ii file 1:5.19-1 ii gettext0.19.2-1 ii hardening-includes 2.5+nmu1 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.29+b2 ii libarchive-zip-perl1.37-2 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.37-1+b1 ii libdigest-sha-perl 5.92-1+b1 ii libdpkg-perl 1.17.13 ii libemail-valid-perl1.194-1 ii libfile-basedir-perl 0.03-1 ii libipc-run-perl0.92-1 ii liblist-moreutils-perl 0.33-2+b1 ii libparse-debianchangelog-perl 1.2.0-1 ii libtext-levenshtein-perl 0.09-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.64-1 ii man-db 2.6.7.1-1 ii patchutils 0.3.3-1 ii perl [libdigest-sha-perl] 5.20.0-4 ii t1utils1.37-2 Versions of packages lintian recommends: pn libperlio-gzip-perl none ii perl-modules [libautodie-perl] 5.20.0-4 Versions of packages lintian suggests: pn binutils-multiarch none ii dpkg-dev 1.17.13 ii libhtml-parser-perl3.71-1+b2 ii libtext-template-perl 1.46-1 ii libyaml-perl 1.01-1 ii xz-utils 5.1.1alpha+20120614-2 -- 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#758892: boost/thread.hpp: compilation fails with clang for particular CPUs
Package: boost1.55
Version: 1.55.0+dfsg-2
Severity: normal
Dear maintainer,
programs using boost thread fail to compile with clang for particular CPUs:
#include boost/thread.hpp
int main() { return 0; }
$ clang++-3.4 -march=corei7 -o test test.cpp -lboost_system
In file included from test.cpp:5:
In file included from /usr/include/boost/thread.hpp:17:
In file included from /usr/include/boost/thread/once.hpp:20:
In file included from /usr/include/boost/thread/pthread/once_atomic.hpp:20:
In file included from /usr/include/boost/atomic.hpp:12:
In file included from /usr/include/boost/atomic/atomic.hpp:17:
In file included from /usr/include/boost/atomic/detail/platform.hpp:22:
/usr/include/boost/atomic/detail/gcc-atomic.hpp:961:64: error: no
matching constructor for initialization of 'storage_type' (aka
'boost::atomics::detail::storage128_type')
explicit base_atomic(value_type const v) BOOST_NOEXCEPT : v_(0)
^ ~
/usr/include/boost/atomic/detail/gcc-atomic.hpp:932:28: note:
candidate constructor (the implicit copy constructor) not viable: no
known conversion from 'int' to
'const boost::atomics::detail::storage128_type' for 1st argument
struct BOOST_ALIGNMENT(16) storage128_type
^
/usr/include/boost/atomic/detail/gcc-atomic.hpp:932:28: note:
candidate constructor (the implicit default constructor) not viable:
requires 0 arguments, but 1 was provided
/usr/include/boost/atomic/detail/gcc-atomic.hpp:968:22: error: no
viable conversion from 'int' to 'storage_type' (aka
'boost::atomics::detail::storage128_type')
storage_type tmp = 0;
^ ~
/usr/include/boost/atomic/detail/gcc-atomic.hpp:932:28: note:
candidate constructor (the implicit copy constructor) not viable: no
known conversion from 'int' to
'const boost::atomics::detail::storage128_type ' for 1st argument
struct BOOST_ALIGNMENT(16) storage128_type
^
/usr/include/boost/atomic/detail/gcc-atomic.hpp:983:22: error: no
viable conversion from 'int' to 'storage_type' (aka
'boost::atomics::detail::storage128_type')
storage_type tmp = 0;
^ ~
/usr/include/boost/atomic/detail/gcc-atomic.hpp:932:28: note:
candidate constructor (the implicit copy constructor) not viable: no
known conversion from 'int' to
'const boost::atomics::detail::storage128_type ' for 1st argument
struct BOOST_ALIGNMENT(16) storage128_type
^
/usr/include/boost/atomic/detail/gcc-atomic.hpp:997:22: error: no
viable conversion from 'int' to 'storage_type' (aka
'boost::atomics::detail::storage128_type')
storage_type expected_s = 0, desired_s = 0;
^~
/usr/include/boost/atomic/detail/gcc-atomic.hpp:932:28: note:
candidate constructor (the implicit copy constructor) not viable: no
known conversion from 'int' to
'const boost::atomics::detail::storage128_type ' for 1st argument
struct BOOST_ALIGNMENT(16) storage128_type
^
/usr/include/boost/atomic/detail/gcc-atomic.hpp:997:38: error: no
viable conversion from 'int' to 'storage_type' (aka
'boost::atomics::detail::storage128_type')
storage_type expected_s = 0, desired_s = 0;
^ ~
/usr/include/boost/atomic/detail/gcc-atomic.hpp:932:28: note:
candidate constructor (the implicit copy constructor) not viable: no
known conversion from 'int' to
'const boost::atomics::detail::storage128_type ' for 1st argument
struct BOOST_ALIGNMENT(16) storage128_type
^
/usr/include/boost/atomic/detail/gcc-atomic.hpp:1013:22: error: no
viable conversion from 'int' to 'storage_type' (aka
'boost::atomics::detail::storage128_type')
storage_type expected_s = 0, desired_s = 0;
^~
/usr/include/boost/atomic/detail/gcc-atomic.hpp:932:28: note:
candidate constructor (the implicit copy constructor) not viable: no
known conversion from 'int' to
'const boost::atomics::detail::storage128_type ' for 1st argument
struct BOOST_ALIGNMENT(16) storage128_type
^
/usr/include/boost/atomic/detail/gcc-atomic.hpp:1013:38: error: no
viable conversion from 'int' to 'storage_type' (aka
'boost::atomics::detail::storage128_type')
storage_type expected_s = 0, desired_s = 0;
^ ~
/usr/include/boost/atomic/detail/gcc-atomic.hpp:932:28: note:
candidate constructor (the implicit copy constructor) not viable: no
known conversion from 'int' to
'const boost::atomics::detail::storage128_type ' for 1st argument
struct BOOST_ALIGNMENT(16) storage128_type
^
7 errors generated.
$
This was reported in [1] and seems to be fixed 5 month ago by [2].
What do you think about adding this patch?
Thanks,
Andrey
[1] https://svn.boost.org/trac/boost/ticket/9610
[2]
Bug#758893: ebhttpd outputs invalid HTML for superscripts
Package: ebhttpd
Version: 1:1.0.dfsg.1-4.3
Severity: minor
Tags: patch
ebhttpd currently outputs invalid HTML to represent superscripts,
the correct tag is sup, not super.
Patch:
--- a/ebhttpd/hookset.c
+++ b/ebhttpd/hookset.c
@@ -537,7 +537,7 @@ hook_begin_superscript(book, appendix, container, code,
argc, argv)
int argc;
const unsigned int *argv;
{
-eb_write_text_string(book, super);
+eb_write_text_string(book, sup);
return EB_SUCCESS;
}
@@ -554,7 +554,7 @@ hook_end_superscript(book, appendix, container, code, argc,
argv)
int argc;
const unsigned int *argv;
{
-eb_write_text_string(book, /super);
+eb_write_text_string(book, /sup);
return EB_SUCCESS;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756055: RM: git-stuff -- RoM
ping. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756903: systemd: Boot hangs if filesystems unavailable
- If a mount fails, keep on booting. And then do your best to try and bring this problem to the attention of someone (mentioning the nofail option in that same message). Only stop the boot if the partition is explicitly marked as critical or stoponfail. Well, 'fail', which is the default, means just that. Not sure what that means here. Does your that mean that which you just described or does it mean fail? Systemd tries to do the corrent and safe thing by default. I'd hope so, but here's my case: - a machine somewhat far away with an old and unimportant fstab entry that refers to a drive that's rarely connected. - after upgrading to systemd, the fstab entry caused systemd to stop the boot (presumably asking for the operator to do something on console). - with the boot stopped, I (the operator who is not on console, since it's a remote machine), I can't fix the fstab entry. In which way is it safe and correct to interrupt the boot in this case? I can understand that making the mount wait (rather than just fail right away) might be made necessary by the fact that systemd changes the order in which operations are performed. I.e. I understand why the change nb 1 might be needed. But that doesn't explain why change number 2 was needed. Apparently you think Michael's response explains it, but I failed to see how. Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704467: Suppress deprecated address
Over one year gone I found a bug in your patch: for the if method, you need to add | grep -v deprecated to the filter of the ip command. BTW, wise decision to use ip rather than ifconfig: you have no chance with the former, afaik. Cheers and thanks for the patch! Andreas.
Bug#758894: texmaker: print offset when using internal pdf viewer
Package: texmaker Version: 4.3-1 Severity: normal When printing letters created with dinbrief or scrlttr2, the foldmarks (and as such the whole page) are ca. 3 mm too low. When using the external viewer (okular) and printing from there, the print is correct. Which means the foldmarks are ca. 3 mm closer to the top edge. This can easily be verified by creating an empty letter and folding it at the middle foldmark. When using the internal PDF viewer for printing, the foldmark is not directly half way on the page. When using the external viewer (okular) for printing the foldmark is right in the middle. Printer is an HP CP1525n. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-rc6-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages texmaker depends on: ii libc6 2.19-9 ii libgcc1 1:4.9.1-4 ii libgl1-mesa-glx [libgl1] 10.2.5-1 ii libpoppler-qt5-1 0.26.3-1 ii libqt5concurrent5 5.3.1+dfsg-3 ii libqt5core5a 5.3.1+dfsg-3 ii libqt5gui55.3.1+dfsg-3 ii libqt5network55.3.1+dfsg-3 ii libqt5opengl5 5.3.1+dfsg-3 ii libqt5printsupport5 5.3.1+dfsg-3 ii libqt5qml55.3.1-3 ii libqt5quick5 5.3.1-3 ii libqt5script5 5.3.1+dfsg-3 ii libqt5webkit5 5.3.1+dfsg-3 ii libqt5widgets55.3.1+dfsg-3 ii libqt5xml55.3.1+dfsg-3 ii libstdc++64.9.1-4 ii libsynctex1 2014.20140528.34243-5 ii texmaker-data 4.3-1 ii zlib1g1:1.2.8.dfsg-1 Versions of packages texmaker recommends: ii aspell0.60.7~20110707-1.1 ii asymptote 2.31-1 ii ghostscript 9.05~dfsg-9 ii hunspell-de-at [hunspell-dictionary] 20131206-5 ii hunspell-de-ch [hunspell-dictionary] 20131206-5 ii hunspell-en-us [hunspell-dictionary] 20070829-6 ii latex-beamer 2014.20140717-01 ii myspell-de-de [myspell-dictionary]20131206-5 ii netpbm2:10.0-15+b2 ii psutils 1.17.dfsg-2 ii texlive-lang-english 2014.20140717-1 ii texlive-latex-extra 2014.20140717-1 ii texlive-latex-recommended [latex-beamer] 2014.20140717-01 Versions of packages texmaker suggests: pn texlive-lang-all none -- 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#757762: [Pkg-owncloud-maintainers] Bug#757762: owncloud-client: Confusing NEWS.Debian entry
Hi Sandro Sandro Knauß b...@sandroknauss.de writes: Hey, Thanks for your bugreport. It is quite hard to say if it still valid, that the oCC will sqash your configuration. We just tried the instalation 1.5 - 1.6.0~beta and were faced with this issue, thats why created the NEWS entry. But maybe the problem was solved and occ is not showing the config dialog at all. It would be great if you could test more upgrade 1.5 - 1.6 with different configurations (actually add more folders etc.). If all works fine, we can skip the NEWS entry completly :) That would be the best solution for all. Do you have some more hints on what to try? The configuration I tried has 3 different synchronization folders. So it's already quite complex. Gaudenz Regads, sandro -- In default installations apt-listchanges is installed and configured to show NEWS entries without asking for confirmation. Because of this it's important that these entries understandable to the average user of a package and offer advice on how to solve the described problems. The NEWS.Debian entry for version 1.6.0~beta1+dfsg-1 is quite confusing because it does not offer any solution to the described problems and the nature and implications of the problem are quite unclear (at least to me). Guessing from what's not really spelled out in the text but probably implied, the problem seems to be that all client settings are reset or appear to be reset. Is this correct? I could not verify this because at least for me when upgrading from 1.5.0+dfsg-4 to 1.6.2+dfsg-1 the problem did not show up. All settings were preserved and I did not see the setup wizard again. Please also add clear instructions on how to remedy the situation. Including on how to abort updating if not all required credentials are known. At least in the default configuration apt-listchanges does not offer the option to abort the installation. The current english text reads quite bumpy. Some suggestions to improve the wording. This is based on my understanding of what's happening. It may be wrong. I'm not a native english speaker either, so best let your your final wording review by someone on the debian-i10l-engl...@lists.debian.org mailinglist. This list was created to aid everyone review their user visible texts like NEWS entries and debconf templates. After upgrading from version 1.5.X all settings can be reset and the setupWizard may be shown again. This happens if . * Make sure you know your OwnCloud password as you will be required to enter it again. * While all settings are reset, synchronization will continue in the background without any visual feedback. If needed you can check this in the log window. Thanks for maintaining and improving owncloud-client! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758826: [patch] fix if $HOME is not writable
Hi!
On Thu, 2014-08-21 at 21:12:20 +0200, Michael Vogt wrote:
Package: debsig-verify
Version: 0.10
I ran into a issue today that debsig-verify would fail if $HOME was
not writable to the debsig-verify progress. The reason is that gpg
tries to create/read a ~/.gnupg/{pubring,secring}.gpg.
Attached is a patch that run gpg with its own GNUPGHOME instead of the
users.
Ah, makes sense, given that the gpg invoked is not using any default
options nor default keyrings. It should also have a more predictable
behavior. Thanks for the patch!
diff -Nru debsig-verify-0.10/gpg-parse.c debsig-verify-0.10ubuntu1/gpg-parse.c
--- debsig-verify-0.10/gpg-parse.c2014-06-07 22:17:34.0 +0200
+++ debsig-verify-0.10ubuntu1/gpg-parse.c 2014-08-21 20:59:04.0
+0200
@@ -32,16 +32,28 @@
#include debsig.h
static int gpg_inited = 0;
+static char gpg_tmpdir[256] = {0,};
No need to initialize static variables, in any case see below.
-/* Crazy damn hack to make sure gpg has created ~/.gnupg, else it will
- * fail first time called */
+/* Crazy damn hack to make sure gpg has a writable HOME to put its
+ trustdb and secret keyring etc */
I don't think the new behavior is crazy at all anymore, :) so the
comment would need to be updated.
+static void cleanup_gpg_tmpdir(void) {
+ execl(/bin/rm, rm, -rf, gpg_tmpdir, NULL);
+}
Please do not hardcode pathnames, use execlp() instead (I know the
existing codebase does not follow that, though :).
For new functions, or when changing function signatures, please use
the form:
,---
type
func_name(type)
{
body
}
`--
I'll try to add a coding-style file, probably referencing the one in
dpkg.
static void gpg_init(void) {
int rc;
-if (gpg_inited) return;
-rc = system(GPG_PROG --options /dev/null /dev/null /dev/null 21);
-if (rc 0)
-ds_fail_printf(DS_FAIL_INTERNAL, error writing initializing gpg);
+if (gpg_inited)
+ return;
This conditional was not changed, so leave it as it was.
+char *tmpdir = getenv(TMPDIR);
+if(!tmpdir)
+ tmpdir = /tmp;
+snprintf(gpg_tmpdir, sizeof(gpg_tmpdir) -1,
+ %s/%s, tmpdir, debsig-verify.XX);
Use dpkg's path_make_temp_template() instead.
+if(!mkdtemp(gpg_tmpdir))
+ ds_fail_printf(DS_FAIL_INTERNAL, mkdtemp() failed for '%s',
gpg_tmpdir);
Use rc here instead of having function calls inside conditionals
(this also fixes rc not being used anymore and possible a warning).
And please spell the error message in a more user understandable form,
like cannot create directory or similar.
+setenv(GNUPGHOME, gpg_tmpdir, 1);
+atexit(cleanup_gpg_tmpdir);
You should check the return values for both calls.
gpg_inited = 1;
}
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#753487: RFS: stda/1.3.1-1 -- new upstream release (package already in Debian)
Hello Eriberto,
I implemented most of the changes you requested.
On Wed, 20 Aug 2014, Eriberto Mota wrote:
tags 753487 moreinfo
thanks
Hi Dimitar.
Please:
1. d/compat: change to 9.
Done.
2. d/control:
- Set 9 to debhelper.
- Consider change the priority to optional. Please, read it[1].
- Create a VCS to control your debian/ versions. You can use github
or other. So, add the Vcs-Browser and Vcs-{Git|Svn|Cvs} to d/control.
- Add a punctuation in each item in long description.
[1] https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities
Done, except the VCS stuff.. Because I'm not sure what kind of a
VCS-entiries should I define in d/control, I'll write you a separate mail
related to what exactly and how it should be version-controlled. May be
presently you can review the new package which don't include VCS-entries,
and later I can produce a new debian-release where Vcs-Browser and
Vcs-{Git|Svn|Cvs} are defined in d/control.
3. Update the d/copyright to 1.0 format. See it[2]. An example here[3].
[2] http://dep.debian.net/deps/dep5/
[3] http://sources.debian.net/src/gconjugue/0.7.5-2/debian/copyright/
Done.
4. d/rules: please, update to new (reduced) format. Your package is
very simple and it will work. Ask me if you have doubts. An example:
http://sources.debian.net/src/pcapfix/1.0.2-3/debian/rules/
Done.
5. d/watch: add escapes before tarball dot (\.tar\.gz). Your watch is
showing the version 1.3.1. I already read about it in previous
messages. I need the final program in your site to check the
integrity.
Well, since '.tar.gz' is at the end of the string, and since I'm not going
to create on my web-page some other package-related files with funny
filenames ending with some chartarsome_chargz, I think that
.tar.gz without escapes is ok - it is not 100% exact but it is more
readable and 'uscan --verbose' works perfectly. But if you mind, I can
change it as requested.
You can download the package source by:
wget http://gnu.mirendom.net/download.cgi/gnu/stda/stda-1.3.1.tar.gz
6. Please, register all modifications in d/changelog.
Done.
Thanks for your work. I am waiting your package.
Cheers,
Eriberto
You can download the new package from m.d.n:
dget -x http://mentors.debian.net/debian/pool/main/s/stda/stda_1.3.1-1.dsc
Thanks,
Dimitar
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758895: Postfix: can't upgrade when in ltsp chroot due to relayhost==myhostname
Package: postfix Version: 2.11.1-1 I run postfix on thin client in a LTSP environment. I am trying to upgrade from 2.10-2 to 2.11.1-1. However, the upgrade doesn't work any more, because I have the relayhost set to the hostname of the LTSP master, and myhostname is not set on the chroot master, but is set once the clients boot. I realize that bad things presumably happen if the relayhost is set to the current hostname, but perhaps it could give a warning, rather than failing the install at the dpkg level. I guess the workaround is to change the relayhost to something else, run the upgrade, and then set it back again, but that is kind of annoying. If the dpkg code can't be changed, is there anything I can do to get around this without making config changes on every upgrade? Thanks. -- Jon Daley http://jon.limedaley.com ~~ When a dog bites a man that is not news, but when a man bites a dog that is news. -- Charles A. Dana -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758218: live-build: Packages helper includes packages excluded by tasksel
having though about this again, i think we should do two things: * keep the Packages helper as is - it's a 'stupid' tool that just does exactly what told: trying to install all packages matching a certain criteria without exception/automagics etc. * either, directly use tasksel to install the standard task and any other tasks (i remember that there was a reason why we haven't used tasksel in the first place, but i don't remember what it was; i think it was because it was pulling in aptitude or something like that)... ..or add a copy of Packages named Tasksel or so which mimics tasksel and we would use Tasksel instead of Packages in live-images configs. i'll check next week about this and get it done either way. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758897: Should not be shipped in jessie
Package: fckeditor Severity: serious fckeditor is an old version of the ckeditor package also present in the archive. fckeditor is already out of testing due to unrelated RC bugs, but I'm filing this separate bug to prevent it from entering jessie again. Packages still using fckeditor should migrate to ckeditor. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758896: witty: FTBFS on all buildds: fails to remove /usr/share/doc/libwt-doc/examples': Directory not empty
Source: witty Version: 3.3.3+dfsg-3 Severity: serious Justification: FTBFS Hi, your package FTBFS everywhere so far due to: | make[1]: Leaving directory '/«BUILDDIR»/witty-3.3.3+dfsg/build-shared' | mkdir -p /«BUILDDIR»/witty-3.3.3+dfsg/debian/tmp/usr/share/doc/libwt-doc/ | mkdir -p /«BUILDDIR»/witty-3.3.3+dfsg/debian/tmp/usr/share/doc/witty-examples/ | cp -R /«BUILDDIR»/witty-3.3.3+dfsg/doc/* /«BUILDDIR»/witty-3.3.3+dfsg/debian/tmp/usr/share/doc/libwt-doc/ | mv /«BUILDDIR»/witty-3.3.3+dfsg/debian/tmp/usr/share/doc/libwt-doc/examples/html /«BUILDDIR»/witty-3.3.3+dfsg/debian/tmp/usr/share/doc/witty-examples/ | rmdir /«BUILDDIR»/witty-3.3.3+dfsg/debian/tmp/usr/share/doc/libwt-doc/examples | rmdir: failed to remove '/«BUILDDIR»/witty-3.3.3+dfsg/debian/tmp/usr/share/doc/libwt-doc/examples': Directory not empty | make: *** [install] Error 1 | debian/rules:181: recipe for target 'install' failed Full build logs linked from: https://buildd.debian.org/status/package.php?p=wittysuite=sid Probably reproducible locally by passing -B to dpkg-buildpackage. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756469: libfuntools-dev and libbsd-dev: error when trying to install together
Hi! On Wed, 2014-07-30 at 08:57:06 +0200, Ralf Treinen wrote: Package: libbsd-dev,libfuntools-dev Version: libbsd-dev/0.7.0-1 Version: libfuntools-dev/1.4.4+dfsg-1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2014-07-30 Architecture: amd64 Distribution: sid automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: [file conflict log…] This is a serious bug as it makes installation fail, and violates sections 7.6.1 and 10.1 of the policy. An optimal solution would consist in only one of the packages installing that file, and renaming or removing the file in the other package. Depending on the circumstances you might also consider Replace relations or file diversions. If the conflicting situation cannot be resolved then, as a last resort, the two packages have to declare a mutual Conflict. Please take into account that Replaces, Conflicts and diversions should only be used when packages provide different implementations for the same functionality. Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/share/man/man3/funopen.3.gz This bug has been filed against both packages. If you, the maintainers of the two packages in question, have agreed on which of the packages will resolve the problem please reassign the bug to that package. You may then also register in the BTS that the other package is affected by the bug. Thanks! I fixed this locally, just need to upload the packages. I think it also should be fixed in funtools (upstream), because it will collide with system man pages on BSD systems, even if this was caused by introducing this in libbsd. BTW Ralf, it seems due to the bug being assigned to two packages, britney didn't notice which versions this was affecting, and let it migrate to testing. I don't think tools in general handle very well bugs assigned to multiple packages, so maybe you might need to reconsider that practice? Either that or talk with relevant teams to see what can be done (debbugs perhaps, and release-team at least). 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#758898: filezilla: assertion failures at start
Package: filezilla Version: 3.9.0.1-0.1 Severity: minor Dear Maintainer, When I start filezilla, I get assertion errors. This doesn't seem to affect the functionality, but it's a little annoying. ASSERT INFO: .../include/wx/string.h(1536): assert !empty() failed in Last(): wxString: index out of bounds The first: BACKTRACE: [1] wxMimeTypesManagerImpl::Initialize(int, wxString const) [2] wxMimeTypesManagerImpl::InitIfNeeded() [3] wxMimeTypesManagerImpl::GetFileTypeFromExtension(wxString const) [4] wxMimeTypesManager::GetFileTypeFromExtension(wxString const) [5] wxTextAttr::~wxTextAttr() [6] wxStringTokenizer::~wxStringTokenizer() [7] wxGenericListCtrl::OnGetItemColumnImage(long, long) const [8] wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent), wxEvent) const [9] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor, wxEvent) const [10] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const, wxEvtHandler*, wxEvent) [11] wxEventHashTable::HandleEvent(wxEvent, wxEvtHandler*) [12] wxEvtHandler::TryHereOnly(wxEvent) [13] wxEvtHandler::ProcessEventLocally(wxEvent) [14] wxEvtHandler::ProcessEvent(wxEvent) [15] wxEvtHandler::SafelyProcessEvent(wxEvent) [16] wxWindowBase::HandleWindowEvent(wxEvent) const [17] wxWindow::GTKSendPaintEvents(_GdkRegion const*) [18] g_closure_invoke [19] g_signal_emit_valist [20] g_signal_emit [21] gtk_main_do_event [22] gdk_window_process_updates [23] wxWindow::Update() [24] wxStatusBar::DoUpdateStatusText(int) [25] wxStatusBarBase::SetStatusText(wxString const, int) [26] wxAnyButton::~wxAnyButton() [27] wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent), wxEvent) const [28] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor, wxEvent) const [29] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const, wxEvtHandler*, wxEvent) [30] wxEventHashTable::HandleEvent(wxEvent, wxEvtHandler*) [31] wxEvtHandler::TryHereOnly(wxEvent) [32] wxEvtHandler::ProcessEventLocally(wxEvent) [33] wxEvtHandler::ProcessEvent(wxEvent) [34] wxEvtHandler::SafelyProcessEvent(wxEvent) [35] wxTimerImpl::SendEvent() [36] wxTimer::Notify() [37] g_main_context_dispatch [38] g_main_loop_run [39] gtk_main [40] wxGUIEventLoop::DoRun() [41] wxEventLoopBase::Run() [42] wxAppConsoleBase::MainLoop() [43] wxAppConsoleBase::OnRun() [44] wxAppBase::OnRun() [45] wxEntry(int, wchar_t**) [46] wxEntry(int, char**) [47] __libc_start_main The Second: ASSERT INFO: .../include/wx/string.h(1536): assert !empty() failed in Last(): wxString: index out of bounds BACKTRACE: [1] wxMimeTypesManagerImpl::Initialize(int, wxString const) [2] wxMimeTypesManagerImpl::InitIfNeeded() [3] wxMimeTypesManagerImpl::GetFileTypeFromExtension(wxString const) [4] wxMimeTypesManager::GetFileTypeFromExtension(wxString const) [5] wxTextAttr::~wxTextAttr() [6] wxStringTokenizer::~wxStringTokenizer() [7] wxGenericListCtrl::OnGetItemColumnImage(long, long) const [8] wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent), wxEvent) const [9] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor, wxEvent) const [10] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const, wxEvtHandler*, wxEvent) [11] wxEventHashTable::HandleEvent(wxEvent, wxEvtHandler*) [12] wxEvtHandler::TryHereOnly(wxEvent) [13] wxEvtHandler::ProcessEventLocally(wxEvent) [14] wxEvtHandler::ProcessEvent(wxEvent) [15] wxEvtHandler::SafelyProcessEvent(wxEvent) [16] wxWindowBase::HandleWindowEvent(wxEvent) const [17] wxWindow::GTKSendPaintEvents(_GdkRegion const*) [18] g_closure_invoke [19] g_signal_emit_valist [20] g_signal_emit [21] gtk_main_do_event [22] gdk_window_process_updates [23] wxWindow::Update() [24] wxStatusBar::DoUpdateStatusText(int) [25] wxStatusBarBase::SetStatusText(wxString const, int) [26] wxAnyButton::~wxAnyButton() [27] wxAppConsoleBase::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent), wxEvent) const [28] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor, wxEvent) const [29] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const, wxEvtHandler*, wxEvent) [30] wxEventHashTable::HandleEvent(wxEvent, wxEvtHandler*) [31] wxEvtHandler::TryHereOnly(wxEvent) [32] wxEvtHandler::ProcessEventLocally(wxEvent) [33] wxEvtHandler::ProcessEvent(wxEvent) [34] wxEvtHandler::SafelyProcessEvent(wxEvent) [35] wxTimerImpl::SendEvent() [36] wxTimer::Notify() [37] g_main_context_dispatch [38] g_main_loop_run [39] gtk_main [40] wxGUIEventLoop::DoRun() [41] wxEventLoopBase::Run() [42] wxAppConsoleBase::MainLoop() [43] wxAppConsoleBase::OnRun() [44] wxAppBase::OnRun() [45] wxEntry(int, wchar_t**) [46] wxEntry(int, char**) [47] __libc_start_main Keep up the good work! mo -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.10-2-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8,
Bug#758249: transition: liblas
On 08/21/2014 06:09 PM, Ross Gammon wrote: 5) binNMU pktools Once the mips build is done in a couple of days, I think dep-wait requests for the BD-Uninstallable architectures should be used just in case the GDAL build is fixed in the mean time. I think the syntax for the nmu and dw commands should be: nmu pktools_2.5.3-1 . ALL . -m Rebuild against libLAS 1.8.0. dw pktools_2.5.3-1 . arm64 hurd-i386 ppc64el . -m liblas-c-dev (= 1.8.0-1) Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
