Bug#748887: manpages-dev: Mistake in STDIO(3) manpage
tags 748887 fixed-upstream thanks Colin, Thanks for reporting that. That text bug had been there for 20 years! Fixed now, after a patch from Simon Paillard. Cheers, Michael On Wed, May 21, 2014 at 10:26 PM, Colin Williams colinwilliams1...@gmail.com wrote: Package: manpages-dev Version: 3.65-1 Severity: normal Dear Maintainer, The stdio manpage seems to have a mistake in the following sentence: At program startup, three text streams are predefined and need not be opened explicitly: standard input (for reading conventional input), standard output (for writing conventional input), and standard error (for writing diagnostic output). I believe the description of standard output should say: standard output (for writing conventional output). I am running Debian 7.5, however I downloaded the Unstable package (3.65-1), and looked in stdio.3.gz, the error still appears to be there. -- System Information: Debian Release: 7.5 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/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748897: Iceweasel default user agent compromises privacy
On Thu, May 22, 2014 at 02:00:10PM +0900, Mike Hommey wrote: Actually, it's not, but there's a bug that only affects esr. If you look at e.g. iceweasel 23 on snapshot.debian.net, you should see Gecko/20100101. Likewise in unstable and experimental. Aurora builds from mozilla.debian.net don't use Gecko/20100101, but it looks like upstream aurora builds do, despite that not matching what is in the source tree. Must be something set on the build side. Actually, since version 25 the Gecko version string is always Gecko/20100101, whatever setup is used. https://bugzilla.mozilla.org/show_bug.cgi?id=728773 Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748899: smemstat: Typo in the '-q' option description in the manpage
Package: smemstat Version: 0.01.07-1 Severity: minor Dear Maintainer, When reading the smemstat manpage, I found an inconsistency in the '-q' option description : -q run quietly, only really makes sense with -r option Because there isn't any '-r' option. Looking at inline help (smemstat -h), I can see the right option : -qrun quietly, useful for -o output only The '-r' should be replaced by '-o'... with regards, Fred. -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (990, 'stable'), (800, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 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 smemstat depends on: ii libc6 2.13-38+deb7u1 smemstat recommends no packages. smemstat 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#747173: Make dmesg dump configurable
Hi Juerg, On Tue, May 20, 2014 at 10:28:24AM +0200, Juerg Haefliger wrote: John, Any thoughts on this? I haven't had time to look at it (sorry) but it seems like a reasonable feature to add. Louis Bouchard has been actively maintaining makedumpfile, and I believe he is working on adding some features to the kdump-tools script. Louis, can you take a look at this? Juerg filed a wishlist bug including a patch: http://bugs.debian.org/747173 -- John Wright j...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748389: apt: verbose option
On Fri, May 16, 2014 at 10:10:07PM +0200, Reiner wrote: Package: apt Version: 1.0.3 Severity: wishlist Thanks for your bugreport. it would be nice to get a verbose option in apt similar aptitude -v update like this: apt -v update Hit ... Hit ... Current status: 0 broken [+0], 3 updates [+0], 42665 new [+0]. I added a similar feature to my feature/apt-update-info git branch, apt does not currently track what packages are new so thats missing. Would be good to have this directly in libapt though. Cheers, Michael Thank you. -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture i386; 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-3\.14-1-686-pae$; APT::NeverAutoRemove:: ^linux-image-686-pae$; APT::NeverAutoRemove:: ^linux-headers-3\.14-1-686-pae$; APT::NeverAutoRemove:: ^linux-headers-686-pae$; APT::NeverAutoRemove:: ^linux-image-extra-3\.14-1-686-pae$; APT::NeverAutoRemove:: ^linux-image-extra-686-pae$; APT::NeverAutoRemove:: ^linux-signed-image-3\.14-1-686-pae$; APT::NeverAutoRemove:: ^linux-signed-image-686-pae$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.14-1-686-pae$; APT::NeverAutoRemove:: ^kfreebsd-image-686-pae$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.14-1-686-pae$; APT::NeverAutoRemove:: ^kfreebsd-headers-686-pae$; APT::NeverAutoRemove:: ^gnumach-image-3\.14-1-686-pae$; APT::NeverAutoRemove:: ^gnumach-image-686-pae$; APT::NeverAutoRemove:: ^.*-modules-3\.14-1-686-pae$; APT::NeverAutoRemove:: ^.*-modules-686-pae$; APT::NeverAutoRemove:: ^.*-kernel-3\.14-1-686-pae$; APT::NeverAutoRemove:: ^.*-kernel-686-pae$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.14-1-686-pae$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-686-pae$; APT::NeverAutoRemove:: ^linux-tools-3\.14-1-686-pae$; APT::NeverAutoRemove:: ^linux-tools-686-pae$; 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::Periodic ; APT::Periodic::Update-Package-Lists 1; APT::Periodic::Download-Upgradeable-Packages 0; APT::Periodic::AutocleanInterval 0; APT::Update ; APT::Update::Post-Invoke ; APT::Update::Post-Invoke:: touch /var/lib/apt/periodic/update-success-stamp 2/dev/null || true; APT::Update::Post-Invoke-Success ; APT::Update::Post-Invoke-Success:: /usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service /usr/bin/test -S /var/run/dbus/system_bus_socket /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update /dev/null; /bin/echo /dev/null; APT::Archives ; APT::Archives::MaxAge 30; APT::Archives::MinAge 2; APT::Archives::MaxSize 500; APT::Architectures ; APT::Architectures:: i386; 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;
Bug#747173: Make dmesg dump configurable
Hello Juerg, John, Le 22/05/2014 08:19, John Wright a écrit : Hi Juerg, On Tue, May 20, 2014 at 10:28:24AM +0200, Juerg Haefliger wrote: John, Any thoughts on this? I haven't had time to look at it (sorry) but it seems like a reasonable feature to add. Louis Bouchard has been actively maintaining makedumpfile, and I believe he is working on adding some features to the kdump-tools script. Louis, can you take a look at this? Juerg filed a wishlist bug including a patch: http://bugs.debian.org/747173 Juerg, happy to hear from you again. The patch seems reasonable so I'll apply it to 1.5.6 and ask John to upload it to Sid. I don't want to tie it to the new features I'm working on (networked kdump) as I don't know when they will land. So I'll update the bug once I get your patch in. Kind regards, ...Louis -- Louis Bouchard Software engineer, Ubuntu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748900: thunar-archive-plugin: Does not work with recent file-roller
Package: thunar-archive-plugin Version: 0.3.1-2 Severity: normal Dear Maintainer, Does not work with recent file-roller -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.14-1-686-pae (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages thunar-archive-plugin depends on: ii libatk1.0-0 2.12.0-1 ii libc62.18-6 ii libcairo21.12.16-2 ii libexo-1-0 0.10.2-3 ii libfontconfig1 2.11.0-5 ii libfreetype6 2.5.2-1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgtk2.0-0 2.24.23-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpangoft2-1.0-01.36.3-1 ii libthunarx-2-0 1.6.3-1 ii libxfce4util64.10.1-1 ii thunar 1.6.3-1 Versions of packages thunar-archive-plugin recommends: ii ark 4:4.12.4-1 ii file-roller 3.12.2-1 thunar-archive-plugin 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#746998: pyfftw: FTBFS on architectures without long double
Hi Aurelien, Thanks for reporting this issue. I'd have to check with upstream the best approach for dealing with this. I am not sure whether you can enable / disable support for specific precisions in pyfftw. I think the author assumed that all these precisions were available. I could restrict the package build to selected architectures that provide all precisions for now, whilst upstream finds a solution to this. How does that sound ? In this case, I'd need to know which architectures are currently failing besides mips64. Please let me know what you think, Cheers, Ghislain -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748902: ITP: python-sphinxcontrib.youtube -- Sphinx YouTube extension
Package: python-sphinxcontrib.youtube Severity: wishlist
Bug#748901: dma: does not recognize addresses in MIME enocded-word syntax
Package: dma Version: 0.9-1 Severity: important Dear Maintainer, I started using dma to get my mail delivered to the company's smarthost. As long as the addresses are all ASCII this works fine. The trouble is, most of the mail addresses I use contain Japanese and my mail client (Emacs' message-mode) dutifully converts those to MIME encoded-word syntax[1]. Any such address is no longer recognized by dma as a valid email address. In /var/log/mail.log I see entries such as: invalid recipient `=?utf-8?B?QXJubyBUw7ZsbCA8YXJub0BkZWJpYW4ub3JnPgo=?=' FWIW, that's Arno's Debian address which also contains some non-ASCII. I would have expected dma to recognize such addresses as valid. To do so it probably needs to decode them before further processing. Also, it should be able to cope with other encodings than UTF-8/base64. On one of my other machines, Japanese is encoded to iso-2022-jp and I would not be surprised if in certain situations the Q-encoding gets used. [1] https://en.wikipedia.org/wiki/MIME#Encoded-Word -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dma depends on: ii debconf [debconf-2.0] 1.5.53 ii libc6 2.18-5 ii libssl1.0.01.0.1g-4 ii ucf3.0028 dma recommends no packages. dma suggests no packages. -- Configuration Files: /etc/dma/auth.conf [Errno 13] Permission denied: u'/etc/dma/auth.conf' -- debconf information: (manually anonymized) * dma/mailname: workstation.example.com * dma/relayhost: smarthost.example.com -- Olaf Meeuwissen, LPIC-2 FLOSS Engineer -- AVASYS CORPORATION FSF Associate Member #1962 Help support software freedom http://www.fsf.org/jf?referrer=1962 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748896: minetest: Crash when clicking Online mod repository in Mods tab
package: minetest severity 748896 normal merge 748896 733974 thanks Hello, thanks for reporting that issue. It turns out that is was already known, but that's another story: better safe than sorry. it seems also that this bug is not an upstream one but a debian one, as stated in https://github.com/minetest/minetest/issues/1147#issuecomment-36329018 I'm completely puzzled and didn't find the time to dig properly into the issue yet. Bye, Mt. On Wed, May 21, 2014 at 10:55:32PM -0400, Fabian Rodriguez wrote: Package: minetest Version: 0.4.9+repack-5 Severity: important Tags: upstream Dear Maintainer, When trying to install new mods, going to the Mods tab has an Online mod repository button. That should present a list of mods available for download and installation. Instead, the application crashes silently. When run from command line with --trace, the following additional information is shown: terminate called after throwing an instance of 'LuaError' what(): C++ exception Abandon Running with gdb brings this trace information: Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffdeffd700 (LWP 24379)] 0x74d083a9 in __GI_raise (sig=sig@entry=6) at .../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x74d083a9 in __GI_raise (sig=sig@entry=6) at .../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x74d0b4c8 in __GI_abort () at abort.c:89 #2 0x755f6d55 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x755f4dd6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x755f4e21 in std::terminate() () from /usr/lib/x86_64-linux- gnu/libstdc++.so.6 #5 0x755f5038 in __cxa_throw () from /usr/lib/x86_64-linux- gnu/libstdc++.so.6 #6 0x0049623b in script_error (L=optimized out) at /tmp/buildd/minetest-0.4.9+repack/src/script/common/c_internal.cpp:74 #7 0x004a4426 in AsyncWorkerThread::worker_thread_main (this=0xe58bc0) at /tmp/buildd/minetest-0.4.9+repack/src/script/lua_api/l_async_events.cpp:327 #8 0x00484fb5 in JThread::TheThread (param=0xe58bc0) at /tmp/buildd/minetest-0.4.9+repack/src/jthread/pthread/jthread.cpp:203 #9 0x761c1062 in start_thread (arg=0x7fffdeffd700) at pthread_create.c:312 #10 0x74db8bfd in clone () at .../sysdeps/unix/sysv/linux/x86_64/clone.S:111 -- 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-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages minetest depends on: ii libc62.18-5 ii libcurl3-gnutls 7.36.0-2 ii libfreetype6 2.5.2-1 ii libgcc1 1:4.9.0-3 ii libirrlicht1.8 1.8.1+dfsg1-1 ii libjsoncpp0 0.6.0~rc2-3 ii libluajit-5.1-2 2.0.3+dfsg-3 ii libogg0 1.3.1-1 ii libopenal1 1:1.14-4 ii libsqlite3-0 3.8.4.3-3 ii libstdc++6 4.9.0-3 ii libvorbis0a 1.3.2-1.3 ii libvorbisfile3 1.3.2-1.3 ii minetest-data0.4.9+repack-5 ii zlib1g 1:1.2.8.dfsg-1 minetest recommends no packages. Versions of packages minetest suggests: ii minetest-mod-moreblocks 0~20130827+gitee1b3025cc-1 ii minetest-mod-moreores0~20130828+git0977bbc809-1 pn minetest-mod-pipeworks none ii minetest-server 0.4.9+repack-5 -- no debconf information -- There are only two kinds of programming languages: those people always bitch about and those nobody uses. -- Bjarne Stroustrup. signature.asc Description: Digital signature
Bug#748649: php5-fpm: php-fpm segfaulting
Turns out this doesn't happen when I turn off php-apc.
Bug#748903: python-tornado: FTBFS on hurd-i386
Source: python-tornado Version: 3.2.0-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, Currently python-tornado fails to build from source on GNU/Hurd due to two failed tests: test_unix_socket and test_unix_socket_bad_request. The attached patch fixes these failures by not using the options SO_REUSEADDR for setsockopt in tornado/netutil.py and SO_ERROR for getsockopt in tornado/iostream.py since they are not yet implemented. With the patch all 739 tests, with 76 skipped, in the testsuite pass and they are a requisite for the package to build. Thanks! --- a/tornado_netutil.py 2014-01-09 03:57:56.0 +0100 +++ b/tornado/netutil.py 2014-05-21 17:38:42.0 +0200 @@ -20,6 +20,7 @@ import errno import os +import sys import socket import ssl import stat @@ -119,7 +120,8 @@ sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) set_close_exec(sock.fileno()) -sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) +if sys.platform != 'gnu0': +sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.setblocking(0) try: st = os.stat(file) --- a/tornado/iostream.py 2014-01-04 17:51:39.0 +0100 +++ b/tornado/iostream.py 2014-05-21 18:42:37.0 +0200 @@ -687,9 +687,12 @@ self.socket = None def get_fd_error(self): -errno = self.socket.getsockopt(socket.SOL_SOCKET, - socket.SO_ERROR) -return socket.error(errno, os.strerror(errno)) +if sys.platform != 'gnu0': +errno = self.socket.getsockopt(socket.SOL_SOCKET, + socket.SO_ERROR) +return socket.error(errno, os.strerror(errno)) +else: +return None def read_from_fd(self): try: @@ -748,7 +751,10 @@ self._add_io_state(self.io_loop.WRITE) def _handle_connect(self): -err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) +if sys.platform != 'gnu0': +err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) +else: +err = 0 if err != 0: self.error = socket.error(err, os.strerror(err)) # IOLoop implementations may vary: some of them return
Bug#747173: Make dmesg dump configurable
On 05/22/2014 08:54 AM, Louis Bouchard wrote: Hello Juerg, John, Le 22/05/2014 08:19, John Wright a écrit : Hi Juerg, On Tue, May 20, 2014 at 10:28:24AM +0200, Juerg Haefliger wrote: John, Any thoughts on this? I haven't had time to look at it (sorry) but it seems like a reasonable feature to add. Louis Bouchard has been actively maintaining makedumpfile, and I believe he is working on adding some features to the kdump-tools script. Louis, can you take a look at this? Juerg filed a wishlist bug including a patch: http://bugs.debian.org/747173 Juerg, happy to hear from you again. Ditto. What a small world :-) The patch seems reasonable so I'll apply it to 1.5.6 and ask John to upload it to Sid. I don't want to tie it to the new features I'm working on (networked kdump) as I don't know when they will land. So I'll update the bug once I get your patch in. Thanks Louis, very much appreciated. ...Juerg Kind regards, ...Louis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747839: lcms2: build libiccjpeg packages
On Wed, May 14, 2014 at 08:26:44AM +0200, Thomas Weber wrote: package: src:lcms2 forwarded 747839 https://github.com/mm2/Little-CMS/issues/31 thanks On Sun, May 11, 2014 at 09:50:21PM -0400, Michael Gilbert wrote: Hi, chromium currently uses an embedded copy of iccjpeg.c. It would be preferable for lcms to ship libiccjpeg packages that could be used for linking against. Hi Michael, I have forwarded this request to upstream, as it would be preferable if this is done across all distributions. Hi Michael, upstream is unlikely to ship a libiccjpeg library, as lcms2 is agnostic with respect to graphic file formats and iccjpeg.c is only about jpeg. Do you know how other distributions handle this? I just looked and found[1] about Gentoo (in fact, following the link [2] there, I just wasted upstream's time asking him - sigh). I'd like to go for a solution that is more general than just Chromium on Debian. [1] http://phajdan-jr.blogspot.be/2013/11/third-party-libraries-in-chromium.html [2] http://sourceforge.net/mailarchive/message.php?msg_id=30221395 Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748590:
Control: tags -1 fixed-upstream patch it's been fixed upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748904: chicken: CVE-2014-3776
Package: chicken Severity: grave Tags: security This was assigned CVE-2014-3776: http://lists.gnu.org/archive/html/chicken-announce/2014-05/msg1.html 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#748905: urlwatch: OSError: [Errno 2] No such file or directory: ''
Package: urlwatch Version: 1.15-3 Severity: minor urlwatch fails with exception if the URL filename doesn't include the / character. So this works: $ urlwatch --urls=./urls But this, which should be equivalent, doesn't: $ urlwatch --urls=urls Traceback (most recent call last): File /usr/bin/urlwatch, line 244, in module jobs = handler.parse_urls_txt(urls_txt) File /usr/share/urlwatch/urlwatch/handler.py, line 155, in parse_urls_txt dir_st = os.stat(dirname) OSError: [Errno 2] No such file or directory: '' -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages urlwatch depends on: ii python 2.7.6-2 ii python-concurrent.futures 2.1.6-3 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748906: ITP: ruby-omniauth-wordpress -- Wordpress strategy for OmniAuth
Package: wnpp Severity: wishlist Owner: Praveen Arimbrathodiyil prav...@debian.org * Package name: ruby-omniauth-wordpress Version : 0.2.1 Upstream Author : Magda Sikorska * URL : https://rubygems.org/gems/omniauth-wordpress * License : Expat Programming Lang: Ruby Description : Wordpress strategy for OmniAuth -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748903: python-tornado: FTBFS on hurd-i386
Svante Signell, le Thu 22 May 2014 09:20:59 +0200, a écrit : The attached patch fixes these failures by not using the options SO_REUSEADDR for setsockopt in tornado/netutil.py and SO_ERROR for getsockopt in tornado/iostream.py since they are not yet implemented. Just to avoid a misunderstanding: they *are* implemented, but only for TCP/IP sockets. --- a/tornado_netutil.py 2014-01-09 03:57:56.0 +0100 +++ b/tornado/netutil.py 2014-05-21 17:38:42.0 +0200 @@ -119,7 +120,8 @@ sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) set_close_exec(sock.fileno()) -sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) +if sys.platform != 'gnu0': +sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) I would even just drop it completely for all systems: I don't see what SO_REUSEADDR can mean for an AF_UNIX socket. --- a/tornado/iostream.py 2014-01-04 17:51:39.0 +0100 +++ b/tornado/iostream.py 2014-05-21 18:42:37.0 +0200 @@ -687,9 +687,12 @@ self.socket = None def get_fd_error(self): -errno = self.socket.getsockopt(socket.SOL_SOCKET, - socket.SO_ERROR) -return socket.error(errno, os.strerror(errno)) +if sys.platform != 'gnu0': +errno = self.socket.getsockopt(socket.SOL_SOCKET, + socket.SO_ERROR) +return socket.error(errno, os.strerror(errno)) +else: +return None I would rather just catch the ENOSYS error, and return None in that case. Again, the idea is that I don't see what SO_ERROR could actually report for AF_UNIX sockets. @@ -748,7 +751,10 @@ self._add_io_state(self.io_loop.WRITE) def _handle_connect(self): -err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) +if sys.platform != 'gnu0': +err = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) +else: +err = 0 if err != 0: self.error = socket.error(err, os.strerror(err)) # IOLoop implementations may vary: some of them return Same here. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746658: Package: installation-reports
Dear Mr. Cyril Brulebios; CC: Yamane-san My name is Shigeru Oyama, and I listed 746658 on 2nd May. You and Mr.Yamane suggested me to see syslog file, and I checked it. I found the last part of the file was a question, asking if linux-image-3.2.0-4-amd64 dpkg should be installed or not in Japanese. It said also answer Yes or No, so I understand the reason of stopping installation might be not answering to this question. I tried to answer this question to proceed the installation process of Debian 7.5.0, and I typed Yes after this question came out at tty4, but nothing had been started after this. I listed this issue at the forum, 'It always stuck at the Select and Install Software step ', but could not get any clear solutions yet. I really need to install newdebian to re-built our system ASAP, could you be kind to give me suggestion how to exit this problem? Thank you. Shigeru
Bug#748907: ITP: node-with -- Compile time for strict mode JavaScript
Subject: ITP: node-with -- Compile time `with` for strict mode JavaScript Package: wnpp Severity: wishlist Owner: Leo Iannacone l...@ubuntu.com * Package name: node-with Version : 3.0.0 Upstream Author : ForbesLindesay * URL : https://github.com/ForbesLindesay/with * License : Expat Programming Lang: JavaScript Description : Compile time `with` for strict mode JavaScript -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748908: ITP: node-with -- compile time with for strict mode JavaScript
Subject: ITP: node-with -- Compile time `with` for strict mode JavaScript Package: wnpp Severity: wishlist Owner: Leo Iannacone l...@ubuntu.com * Package name: node-with Version : 3.0.0 Upstream Author : ForbesLindesay * URL : https://github.com/ForbesLindesay/with * License : Expat Programming Lang: JavaScript Description : Compile time `with` for strict mode JavaScript -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748881: lintian: please extend eglibc whitelist to glibc
On Thu, May 22, 2014 at 07:56:16AM +0200, Bastien ROUCARIES wrote: Le 21 mai 2014 20:57, Aurelien Jarno aure...@debian.org a écrit : Package: lintian Version: 2.5.22.1 Severity: normal lintian contains a few whitelisted errors when the source package is eglibc. Now that the upstream glibc development is more friendly and that eglibc is stopping being developed, we are in the process of switching back to the upstream glibc. We'll rename the source package with it, which gives us some additional lintian errors and warnings, some of them triggering an automated reject by ftpmasters: E: libc6: embedded-library lib/x86_64-linux-gnu/libm-2.19.so: libm W: libc6: non-multi-arch-lib-dir lib64/ E: libc6-i386: embedded-library lib32/libm-2.19.so: libm W: libc6-i386: non-multi-arch-lib-dir lib32/ W: libc6-i386: non-multi-arch-lib-dir usr/lib32/ W: libc6-dev-x32: non-multi-arch-lib-dir usr/libx32/ W: libc6-dev-i386: non-multi-arch-lib-dir usr/lib32/ E: libc6-x32: embedded-library libx32/libm-2.19.so: libm W: libc6-x32: non-multi-arch-lib-dir libx32/ W: libc6-x32: non-multi-arch-lib-dir usr/libx32/ E: libc6-udeb udeb: embedded-library lib/libm-2.19.so: libm Could you please therefore extent the eglibc whitelist to also cover the glibc source package? Thanks in advance. What is the eta? We plan to do first a eglibc 2.18 - eglibc 2.19 transition, we need to ask a transition slot for that, so we don't fully control the timing for that. Then we'll do the transition eglibc 2.19 - glibc 2.19. It's therefore difficult to give you and exact estimate, but let's say we plan to upload it in about 3-4 weeks. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748878: RFS: mwc/1.7.2-1 ITP
* Paul Wise p...@debian.org, 2014-05-22, 08:49: mwc - Powerful website-tracking tool Sounds almost exactly like the urlwatch package, which is already in Debian. hat type=tired urlwatch user FSVO almost. If you want to do any post-processing in urlwatch, you need to write Python code, which is tedious. On the other hand, expressiveness of mwc filters might not be sufficient for some urlwatch users. /hat hat type=disappointed security researcher But do we really need another SMTP client in the archive? :( /hat -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748903: python-tornado: FTBFS on hurd-i386
On Thu, 2014-05-22 at 09:48 +0200, Samuel Thibault wrote: Svante Signell, le Thu 22 May 2014 09:20:59 +0200, a écrit : The attached patch fixes these failures by not using the options SO_REUSEADDR for setsockopt in tornado/netutil.py and SO_ERROR for getsockopt in tornado/iostream.py since they are not yet implemented. Just to avoid a misunderstanding: they *are* implemented, but only for TCP/IP sockets. I'll add that to the bug report. --- a/tornado_netutil.py2014-01-09 03:57:56.0 +0100 +++ b/tornado/netutil.py2014-05-21 17:38:42.0 +0200 @@ -119,7 +120,8 @@ sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) set_close_exec(sock.fileno()) -sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) +if sys.platform != 'gnu0': +sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) I would even just drop it completely for all systems: I don't see what SO_REUSEADDR can mean for an AF_UNIX socket. Then you should discuss with upstream. BTW: Other packages do the same kind of tests, I've seen this before. --- a/tornado/iostream.py 2014-01-04 17:51:39.0 +0100 +++ b/tornado/iostream.py 2014-05-21 18:42:37.0 +0200 @@ -687,9 +687,12 @@ self.socket = None def get_fd_error(self): -errno = self.socket.getsockopt(socket.SOL_SOCKET, - socket.SO_ERROR) -return socket.error(errno, os.strerror(errno)) +if sys.platform != 'gnu0': +errno = self.socket.getsockopt(socket.SOL_SOCKET, + socket.SO_ERROR) +return socket.error(errno, os.strerror(errno)) +else: +return None I would rather just catch the ENOSYS error, and return None in that case. Again, the idea is that I don't see what SO_ERROR could actually report for AF_UNIX sockets. Well, the test fails if ENOSYS is returned, I can try to fix that but this is probably an upstream issue again :( -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748903: python-tornado: FTBFS on hurd-i386
Svante Signell, le Thu 22 May 2014 10:02:55 +0200, a écrit : --- a/tornado_netutil.py 2014-01-09 03:57:56.0 +0100 +++ b/tornado/netutil.py 2014-05-21 17:38:42.0 +0200 @@ -119,7 +120,8 @@ sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) set_close_exec(sock.fileno()) -sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) +if sys.platform != 'gnu0': +sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) I would even just drop it completely for all systems: I don't see what SO_REUSEADDR can mean for an AF_UNIX socket. Then you should discuss with upstream. BTW: Other packages do the same kind of tests, I've seen this before. That does not necessarily mean that it's a good idea. Putting system tests is a bad habit, it makes the code less readable, and most often than not, brings nasty surprises later. We should really rather wonder what is actually correct. --- a/tornado/iostream.py 2014-01-04 17:51:39.0 +0100 +++ b/tornado/iostream.py 2014-05-21 18:42:37.0 +0200 @@ -687,9 +687,12 @@ self.socket = None def get_fd_error(self): -errno = self.socket.getsockopt(socket.SOL_SOCKET, - socket.SO_ERROR) -return socket.error(errno, os.strerror(errno)) +if sys.platform != 'gnu0': +errno = self.socket.getsockopt(socket.SOL_SOCKET, + socket.SO_ERROR) +return socket.error(errno, os.strerror(errno)) +else: +return None I would rather just catch the ENOSYS error, and return None in that case. Again, the idea is that I don't see what SO_ERROR could actually report for AF_UNIX sockets. Well, the test fails if ENOSYS is returned, I can try to fix that but this is probably an upstream issue again :( It sure is an upstream issue, yes. Here it is precisely an example where we really do *not* want to stuff a system test: get_fd_error may be applied not only on a Unix socket (where GNU/Hurd will return ENOSYS indeed), but also on a TCP/IP socket, where GNU/Hurd will behave as expected, and python-tornado *wants* this to work, to be able to cope with socket errors etc. Putting a system test here would cripple the software, and it will very probably go unnoticed for many years. At best some people may notice that it behaves badly on GNU/Hurd, and would blame GNU/Hurd for that, not python-tornado, while it's actually python-tornado which will have been crippled, and where the fix will be needed. We really don't want that. And no, I don't have time to discuss with upstream myself. If I had, I would have submitted the bug report myself. It's really up to you to submit proper patches. I have time to review your patches to make sure they are proper, I don't have time to fix them and discuss with upstream myself. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748465: Renaming repacked tarball (was Re: Excluded-Files feature reimplemented)
On Thu, May 22, 2014 at 12:45:41AM +0200, Joachim Breitner wrote: Since one can already use opts=uversionmangle=s/$/+dfsg/ in d/watch, maybe there is nothing to fix at all, except perhaps documenting it. The behaviour change can be considered a bug in the initial implementation now fixed, so this bug can be closed without further action if that’s the case. I agree, but Andreas said “I think editing each debian/watch file an mangling names is a bit clumsy.” OK, may be I should ignore I: python-biom-format source: debian-watch-file-should-dversionmangle-not-uversionmangle line 3 after the change you can see here http://anonscm.debian.org/viewvc/debian-med/trunk/packages/python-biom-format/trunk/debian/watch?view=diffr1=16994r2=16525diff_format=h We could actually close the bug ... or me reassign the problem to lintian. (Could anybody do this since I'll go offline quite soon for about one week.) Kind regards Andreas. -- 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#748909: nvidia-settings: nvdia settings now has dependency on nvidia-driver = please build them togheter
Package: nvidia-settings Version: 337.19-1 Severity: normal nvidia-settings ERROR: Error querying target relations ERROR: nvidia-settings could not find the registry key file. This file should have been installed along with this driver at either /usr/share/nvidia/nvidia-application-profiles-331.67-key-documentation or /usr/share/nvidia/nvidia-application-profiles-key-documentation. The application profiles will continue to work, but values cannot be preopulated or validated, and will not be listed in the help text. Please see the README for possible values and descriptions. ls -l /usr/share/nvidia/ total 44 -rw-r--r-- 1 root root 3177 Sep 9 2011 nvidia-195.ids -rw-r--r-- 1 root root 4500 Jun 30 2012 nvidia-295.ids -rw-r--r-- 1 root root 4698 Sep 15 2013 nvidia-304.ids -rw-r--r-- 1 root root 1900 Apr 4 20:47 nvidia-application-profiles-331.67-rc -rw-r--r-- 1 root root 4185 May 6 07:59 nvidia.ids -rw-r--r-- 1 root root 2088 Sep 9 2011 nvidia-legacy-173xx.ids -rw-r--r-- 1 root root 1215 Sep 9 2011 nvidia-legacy-71xx.ids -rw-r--r-- 1 root root 1548 Sep 9 2011 nvidia-legacy-96xx.ids dpkg -S /usr/share/nvidia/nvidia-application-profiles-331.67-rc nvidia-driver: /usr/share/nvidia/nvidia-application-profiles-331.67-rc -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.12.20 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF8) Shell: /bin/sh linked to /bin/bash Versions of packages nvidia-settings depends on: ii libc6 2.18-7 ii libgdk-pixbuf2.0-02.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgtk2.0-0 2.24.23-1 ii libpango-1.0-01.36.3-1 ii libx11-6 2:1.6.2-2 ii libxnvctrl0 337.19-1 ii libxxf86vm1 1:1.1.3-1 ii nvidia-alternative331.67-2 ii nvidia-installer-cleanup 20131102+1 ii pkg-config0.28-1 Versions of packages nvidia-settings recommends: ii libgl1-nvidia-glx 331.67-2 nvidia-settings 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#612893: Fix works
Hello all! I also can confirm that this patch (bugfix-1067) solves the problem and makes newer fluxbox versions usable again. I'd vote for integrating it as soon as possible ;-) Roman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696901: marked as done (chroot-setup.sh: [kfreebsd-*] procfs mounted instead of linprocfs in target)
Steven Chamberlain ste...@pyro.eu.org (2014-05-21): On 22/01/13 06:06, Debian Bug Tracking System wrote: debian-installer-utils (1.92+deb7u1) testing-proposed-updates; urgency=low . * Fix procfs mounting on GNU/kFreeBSD: it's called linprocfs, rather than procfs (Closes: #696901). Thanks, Steven Chamberlain! Was fixed in wheezy p-u, but forgot to apply it in sid! So I've cherry-picked it into Git master branch. http://anonscm.debian.org/gitweb/?p=d-i/debian-installer-utils.git;a=commitdiff;h=f9666f75daa885f1d38f4714be20fd38af289a40 Uh-oh, thanks! (again) Mraw, KiBi. signature.asc Description: Digital signature
Bug#748910: CVE-2014-0240: Possibility of local privilege escalation when using daemon, mode
Package: libapache2-mod-wsgi Version: 3.3-4 Severity: critical Tags: security Justification: root security hole Dear Maintainer, as far as I can tell, CVE-2014-0240 affects the stable package of mod-wsgi. The patch provided by the mod-wsgi team applies wih fuzzing to the source shipped by debian. If a kernel = 2.6.0 and 3.1.0 is installed, this issue might allow local privilege escalation -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- LSE Leading Security Experts GmbH, Postfach 100121, 64201 Darmstadt Unternehmenssitz: Weiterstadt, Amtsgericht Darmstadt: HRB8649 Geschäftsführer: Oliver Michel, Sven Walther commit d9d5fea585b23991f76532a9b07de7fcd3b649f4 Author: Graham Dumpleton graham.dumple...@gmail.com Date: Wed May 21 16:16:47 2014 +1000 Local privilege escalation when using daemon mode. (CVE-2014-0240) diff --git a/mod_wsgi.c b/mod_wsgi.c index 32b2903..3ef911b 100644 --- a/mod_wsgi.c +++ b/mod_wsgi.c @@ -10756,6 +10756,19 @@ static void wsgi_setup_access(WSGIDaemonProcess *daemon) ap_log_error(APLOG_MARK, WSGI_LOG_ALERT(errno), wsgi_server, mod_wsgi (pid=%d): Unable to change to uid=%ld., getpid(), (long)daemon-group-uid); + +/* + * On true UNIX systems this should always succeed at + * this point. With certain Linux kernel versions though + * we can get back EAGAIN where the target user had + * reached their process limit. In that case will be left + * running as wrong user. Just exit on all failures to be + * safe. Don't die immediately to avoid a fork bomb. + */ + +sleep(20); + +exit(-1); } /* smime.p7s Description: S/MIME Cryptographic Signature
Bug#748911: src:opal: FTBFS on 64 bits arch
Package: src:opal Version: 3.10.10~dfsg-2.2 Severity: normal Tags: patch Dear Maintainer, The attached patch has been applied on Ubuntu to fix a FTBFS on 64 bits arch. Thanks for considering the patch. Erwan Prioul. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 3.13-1-powerpc64le (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- a/debian/rules 2013-02-17 14:36:10.0 + +++ b/debian/rules 2014-01-22 18:18:13.0 + @@ -1,6 +1,9 @@ #!/usr/bin/make -f #export DH_VERBOSE:=1 +ifeq (64,$(strip $(shell dpkg-architecture -qDEB_HOST_ARCH_BITS))) + export EXTRA_EXTRA_CPPFLAGS:=-DP_64BIT=1 +endif DEBVERSION := $(shell head -n 1 debian/changelog \ | sed -e 's/^[^(]*(\([^)]*\)).*/\1/') --- a/Makefile.in 2014-03-24 15:58:00.0 + +++ b/Makefile.in 2014-03-24 15:58:01.0 + @@ -530,11 +530,11 @@ DEPS := $(patsubst %.dep, $(OPAL_DEPDIR $(OPAL_OBJDIR)/%.o : %.cxx @if [ ! -d $(OPAL_OBJDIR) ] ; then mkdir -p $(OPAL_OBJDIR) ; fi - $(Q_CC)$(CXX) $(CXXFLAGS) -c $ -o $@ + $(Q_CC)$(CXX) $(CXXFLAGS) $(EXTRA_EXTRA_CPPFLAGS) -c $ -o $@ $(OPAL_OBJDIR)/%.o : %.c @if [ ! -d $(OPAL_OBJDIR) ] ; then mkdir -p $(OPAL_OBJDIR) ; fi - $(Q_CC)$(CC) $(CFLAGS) -c $ -o $@ + $(Q_CC)$(CC) $(CFLAGS) $(EXTRA_EXTRA_CPPFLAGS) -c $ -o $@ # # define rule for .dep files
Bug#748912: ITP: python-sphinxcontrib.youtube -- Sphinx YouTube extension
Package: wnpp Severity: wishlist Owner: Thomi Richards thomi.richa...@canonical.com * Package name: python-sphinxcontrib.youtube Version : 0.1.2 Upstream Author : Chris Pickel sfi...@gmail.com * URL : http://pypi.python.org/pypi/sphinxcontrib-youtube * License : BSD Programming Lang: Python Description : Sphinx YouTube extension This package contains the YouTube Sphinx extension. This extension enables you to insert YouTube videos in your Sphinx documents. This is part of the third party 'sphinxcontrib' repository. The repository contains plugins for the sphinx documentation system. A few of these plugins have already been packaged in Debian. -- Thomi Richards thomi.richa...@canonical.com
Bug#727192: The patch from the gnome bugzilla works for me
I've been running for two days now with the patch from the gnome bugzilla and everything works OK. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745605: apache2: ignores AddDefaultCharset
An update, adding to the form 'enctype=multipart/form-data;charset=utf-8' breaks the file upload so is not a solution. Any advance with this? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748897: Iceweasel default user agent compromises privacy
On Thu, May 22, 2014 at 1:00 AM, Mike Hommey m...@glandium.org wrote: On Wed, May 21, 2014 at 11:19:20PM -0400, Rolf Braun wrote: - Inclusion of the Iceweasel token, which is much rarer than standard Firefox. This one is a tough call. You're actually using a not-Firefox browser. And making Iceweasel not emit that part would require awkward changes that would affect more than Iceweasel. Agreed that it's not obviously the right thing to do, and Debian isn't the only vendor to be adding a vendor-specific token to the UA string. But there are fewer users of Debian on the desktop than e.g. Ubuntu, so the issue of being identifiable by this is more concerning. From my perspective as a user, yes, it's technically a non-Firefox browser. But from any website's perspective, it renders and processes HTML and JavaScript the same as Firefox of that version would; the user-agent isn't required to reveal anything more. I'm not sure what else it would affect, though it seems the UA string is being generated in a standard way by code from upstream, so that would have to be patched. - The Gecko build date in the UA reported by Firefox releases is standardized as 20100101. Inclusion of the actual build date allows individual users, especially users of backports or of unstable releases, to be identified almost uniquely,. Firefox removed this ability in the fix for bug 572661, but Debian is continuing to build Firefox with an identifiable build date. Actually, it's not, but there's a bug that only affects esr. If you look at e.g. iceweasel 23 on snapshot.debian.net, you should see Gecko/20100101. Likewise in unstable and experimental. Aurora builds from mozilla.debian.net don't use Gecko/20100101, but it looks like upstream aurora builds do, despite that not matching what is in the source tree. Must be something set on the build side. So all in all, this is mostly an ESR-only issue (also affecting chemspills like 29.0.1), that is mostly fixed in unstable, and essentially fixed in experimental (except for the Iceweasel part) Actually, since version 25 the Gecko version string is always Gecko/20100101, whatever setup is used. https://bugzilla.mozilla.org/show_bug.cgi?id=728773 So I assume from that, it's also fixed for future ESR releases (31?) in testing/stable? Thanks for looking into this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748913: miniupnpc: Buffer overread in miniwget
Package: miniupnpc Severity: grave Tags: security Justification: user security hole A CVE assignment is pending. The fix is here: https://github.com/miniupnp/miniupnp/commit/3a87aa2f10bd7f1408e1849bdb59c41dd63a9fe9 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#748915: pulseaudio: Microphone input is crackling in skype and sound record program. Output is OK.
Package: pulseaudio Version: 2.0-6.1 Severity: important * What led up to the situation? Using micropohone. * What exactly did you do (or not do) that was effective (or ineffective)? I tried: modifying pulseuadio default.pa and daemon.conf files and even updating the kernel to 3.13 with no effect. What I tried is described here: http://forums.debian.net/viewtopic.php?f=7t=114603p=541465#p541465 * What was the outcome of this action? Crackling output which was present as well dissapeared after updating the pulseaudio files while input stayed crackling. * What outcome did you expect instead? The crackling input to be fixed as well. -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pulseaudio depends on: ii adduser 3.113+nmu3 ii consolekit0.4.5-3.1 ii libasound21.0.25-4 ii libasound2-plugins1.0.25-2 ii libc6 2.13-38+deb7u1 ii libcap2 1:2.22-1.2 ii libdbus-1-3 1.6.8-1+deb7u1 ii libfftw3-33.3.2-3.1 ii libgcc1 1:4.7.2-5 ii libice6 2:1.0.8-2 ii libltdl7 2.4.2-1.1 ii liborc-0.4-0 1:0.4.16-2 ii libpulse0 2.0-6.1 ii libsamplerate00.1.8-5 ii libsm62:1.2.1-2 ii libsndfile1 1.0.25-5 ii libspeexdsp1 1.2~rc1-7 ii libstdc++64.7.2-5 ii libsystemd-daemon044-11+deb7u4 ii libsystemd-login0 44-11+deb7u4 ii libtdb1 1.2.10-2 ii libudev0 175-7.2 ii libwebrtc-audio-processing-0 0.1-2 ii libx11-6 2:1.5.0-1+deb7u1 ii libx11-xcb1 2:1.5.0-1+deb7u1 ii libxcb1 1.8.1-2+deb7u1 ii libxtst6 2:1.2.1-1+deb7u1 ii lsb-base 4.1+Debian8+deb7u1 ii udev 175-7.2 Versions of packages pulseaudio recommends: ii gstreamer0.10-pulseaudio 0.10.31-3+nmu1 ii pulseaudio-module-x11 2.0-6.1 ii rtkit 0.10-2+wheezy1 Versions of packages pulseaudio suggests: pn paman none pn paprefs none pn pavucontrol none pn pavumeter none ii pulseaudio-utils 2.0-6.1 -- Configuration Files: /etc/pulse/daemon.conf changed: ; daemonize = no ; fail = yes ; allow-module-loading = yes ; allow-exit = yes ; use-pid-file = yes ; system-instance = no ; local-server-type = user ; enable-shm = yes ; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB ; lock-memory = no ; cpu-limit = no ; high-priority = yes ; nice-level = -11 ; realtime-scheduling = yes ; realtime-priority = 5 ; exit-idle-time = 20 ; scache-idle-time = 20 ; dl-search-path = (depends on architecture) ; load-default-script-file = yes ; default-script-file = /etc/pulse/default.pa ; log-target = auto ; log-level = notice ; log-meta = no ; log-time = no ; log-backtrace = 0 ; resample-method = speex-float-3 ; enable-remixing = yes ; enable-lfe-remixing = no flat-volumes = no ; rlimit-fsize = -1 ; rlimit-data = -1 ; rlimit-stack = -1 ; rlimit-core = -1 ; rlimit-as = -1 ; rlimit-rss = -1 ; rlimit-nproc = -1 ; rlimit-nofile = 256 ; rlimit-memlock = -1 ; rlimit-locks = -1 ; rlimit-sigpending = -1 ; rlimit-msgqueue = -1 ; rlimit-nice = 31 ; rlimit-rtprio = 9 ; rlimit-rttime = 100 ; default-sample-format = s16le default-sample-rate = 48000 ; alternate-sample-rate = 48000 ; default-sample-channels = 2 ; default-channel-map = front-left,front-right ; default-fragments = 4 ; default-fragment-size-msec = 25 ; enable-deferred-volume = yes ; deferred-volume-safety-margin-usec = 8000 ; deferred-volume-extra-delay-usec = 0 /etc/pulse/default.pa changed: ..nofail ..fail load-module module-device-restore load-module module-stream-restore load-module module-card-restore load-module module-augment-properties ..ifexists module-udev-detect.so load-module module-udev-detect tsched=0 ..else load-module module-detect ..endif ..ifexists module-jackdbus-detect.so ..nofail load-module module-jackdbus-detect ..fail ..endif ..ifexists module-bluetooth-discover.so load-module module-bluetooth-discover ..endif ..ifexists module-esound-protocol-unix.so load-module module-esound-protocol-unix ..endif load-module module-native-protocol-unix ..ifexists module-gconf.so ..nofail load-module module-gconf ..fail ..endif load-module module-default-device-restore load-module module-rescue-streams load-module module-always-sink load-module module-intended-roles
Bug#748914: Missing function declaration shadows stack underflow
Package: linsmith Version: 0.99.21-1 Usertags: goto-cc During an analysis of all Debian packages using our research compiler tool-chain (using tools from the cbmc package) the following error was found: recalculate_all takes one argument: http://sources.debian.net/src/linsmith/0.99.21-1/src/chart.c?hl=847#L847 Yet none is passed when called from here, necessarily leading to stack underflow and thus to undefined behaviour as an arbitrary value will be used: http://sources.debian.net/src/linsmith/0.99.21-1/src/misc.c?hl=640#L640 Note that this could easily have been avoided if compiler warnings had been obeyed: [...] x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -DPACKAGE_DATA_DIR=\/usr/share\ -DPACKAGE_LOCALE_DIR=\/usr/share/locale\ -D_REENTRANT -DORBIT2=1 -pthread -I/usr/include/libgnomeui-2.0 -I/usr/include/gnome-keyring-1 -I/usr/include/libbonoboui-2.0 -I/usr/include/libxml2 -I/usr/include/libgnome-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/orbit-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gail-1.0 -I/usr/include/libart-2.0 -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/x86_64-linux-gnu/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/libpng12 -I/usr/include/libxml2 -Wall -g -O2 -Wl,-z,defs,--as-needed -MT misc.o -MD -MP -MF .deps/misc.Tpo -c -o misc.o misc.c [...] misc.c: In function 'on_comp_scale_value_changed': misc.c:640:3: warning: implicit declaration of function 'recalculate_all' [-Wimplicit-function-declaration] recalculate_all(); ^ Best, Michael pgp6PRy5qpKBb.pgp Description: PGP signature
Bug#748916: libapache2-mod-log-slow: Apache module not available in the Debian package
Package: libapache2-mod-log-slow Version: 1.0.8-2 Severity: important Hi, The version 1.0.6-3 (wheezy) has the Apache module: 10:57 wheezy:~% dpkg -L libapache2-mod-log-slow |grep so$ /usr/lib/apache2/modules/mod_log_slow.so The version 1.0.8-2 (sid, jessie) does not have the Apache module: cyb@sid:~$ dpkg -L libapache2-mod-log-slow |grep so$ cyb@sid:~$ Hence the Apache configuration is broken: # apache2ctl -t apache2: Syntax error on line 140 of /etc/apache2/apache2.conf: Syntax error on line 1 of /etc/apache2/mods-enabled/log_slow.load: Cannot load /usr/lib/apache2/modules/mod_log_slow.so into server: /usr/lib/apache2/modules/mod_log_slow.so: cannot open shared object file: No such file or directory Action '-t' failed. The Apache error log may have more information. I'll write a patch… -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libapache2-mod-log-slow depends on: ii apache2-bin [apache2-api-20120211] 2.4.9-1 libapache2-mod-log-slow recommends no packages. libapache2-mod-log-slow suggests no packages. -- no debconf information -- ,''`. : :' : Cyril Bouthors `. `' Debian.org `-
Bug#748917: network-manager: Failed to add/activate connection No session found for uid, 1000 (unknown)
Package: network-manager Version: 0.9.8.10-2 Severity: important When I click on a WiFi connection I get a Connection Failure message with the above information. This is similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742950 but I am using lightdm. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.8.3-20130328 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages network-manager depends on: ii adduser3.113+nmu3 ii dbus 1.8.2-1 ii init-system-helpers1.18 ii isc-dhcp-client4.2.4-7 ii libc6 2.18-5 ii libdbus-1-31.8.2-1 ii libdbus-glib-1-2 0.102-1 ii libgcrypt111.5.3-4 ii libglib2.0-0 2.40.0-3 ii libgnutls262.12.23-15 ii libgudev-1.0-0 204-8 ii libmm-glib01.0.0-4 ii libnl-3-2003.2.24-2 ii libnl-genl-3-200 3.2.24-2 ii libnl-route-3-200 3.2.24-2 ii libnm-glib40.9.8.10-2 ii libnm-util20.9.8.10-2 ii libpam-systemd 204-8 ii libpolkit-gobject-1-0 0.105-5 ii libsoup2.4-1 2.46.0-2 ii libsystemd-daemon0 204-8 ii libsystemd-login0 204-8 ii libuuid1 2.20.1-5.7 ii lsb-base 4.1+Debian12 ii policykit-10.105-5 ii udev 175-7.2 ii wpasupplicant 1.1-1 Versions of packages network-manager recommends: pn crda none pn dnsmasq-base none ii iptables 1.4.21-1 pn modemmanager none pn ppp none Versions of packages network-manager suggests: ii avahi-autoipd 0.6.31-4 -- Configuration Files: /etc/NetworkManager/NetworkManager.conf changed [not included] -- 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#743420: same bug too
I have same bug too, when starting xsane for network scan (server debian wjeezy, client debian sid) keeper@keeper:~$ xsane xsane: simple-watch.c:454: avahi_simple_poll_prepare: Проверочное утверждение «s-state == STATE_INIT || s-state == STATE_DISPATCHED || s-state == STATE_FAILURE» не выполнено. Аварийный останов keeper@keeper:~$ ii libcommon-sense-perl 3.72-5 amd64 ii libksane-data 4:4.12.3-2 all ii libksane-dev 4:4.12.3-2 amd64 ii libksane0 4:4.12.3-2 amd64 ii libsane:amd64 1.0.24-1.1+b1 amd64 ii libsane-common 1.0.24-1.1 all ii libsane-dev 1.0.24-1.1+b1 amd64 ii libsane-extras:amd64 1.0.22.3 amd64 ii libsane-extras-common 1.0.22.3 amd64 ii libsane-extras-dev 1.0.22.3 amd64 ii libsane-hpaio 3.14.1-1 amd64 ii libwine-sane:i386 1.6.2-8 i386 ii sane-utils 1.0.24-1.1+b1 amd64 ii xsane 0.998-5+b1 amd64 ii xsane-common 0.998-5 root@keeper:/home/keeper# cat /etc/sane.d/net.conf 192.168.0.20 avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled) Active: active (running) since Чт 2014-05-22 08:41:52 IRKT; 8h ago Main PID: 1688 (avahi-daemon) Status: Server startup complete. Host name is keeper.alocal. Local service cookie is 2186472304. CGroup: name=systemd:/system/avahi-daemon.service ├─1688 avahi-daemon: running [keeper.alocal] └─1689 avahi-daemon: chroot helper -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748918: postgrey fails to start
Package: postgrey Version: 1.34-1.1 Severity: grave Tags: patch Justification: renders package unusable Dear Maintainer, A fresh install of postgrey on two Wheezy machines fails to start. Much like was the case in debian bug #722136, starting the postgrey daemon on the command line reveals the same failure mode: $ sudo postgrey --inet 10023 2014/05/22-19:09:07 postgrey (type Net::Server::Multiplex) starting! pid(15633) Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4 Binding to TCP port 10023 on host 127.0.0.1 with IPv4 Insecure dependency in bind while running with -T switch at /usr/lib/perl/5.14/IO/Socket.pm line 202. Applying the same patch, https://github.com/yasuhirokimura/postgrey/commit/9673b54064691a5b9c295ffea340d8a1f9ee1cb8, fixes this problem for me. I wonder if the changes introduced with perl-base 5.14.2-21+deb7u1 created the problem, but I haven't found a perl-base 5.14.2-21 package to install to see if the problem goes away. -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages postgrey depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 ii libberkeleydb-perl 0.51-1 ii libnet-dns-perl0.66-2+b2 ii libnet-server-perl 2.006-1+deb7u1 ii perl 5.14.2-21+deb7u1 ii ucf3.0025+nmu3 Versions of packages postgrey recommends: ii libnet-rblclient-perl 0.5-2 ii libparse-syslog-perl 1.10-2 ii postfix2.9.6-2 postgrey suggests no packages. -- debconf information: postgrey/1.32-3_changeport: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748465: Renaming repacked tarball (was Re: Excluded-Files feature reimplemented)
Control: reassign -1 lintian Control: retitle -1 remove debian-watch-file-should-dversionmangle-not-uversionmangle Control: affects -1 devscripts Hi, Am Donnerstag, den 22.05.2014, 10:19 +0200 schrieb Andreas Tille: On Thu, May 22, 2014 at 12:45:41AM +0200, Joachim Breitner wrote: Since one can already use opts=uversionmangle=s/$/+dfsg/ in d/watch, maybe there is nothing to fix at all, except perhaps documenting it. The behaviour change can be considered a bug in the initial implementation now fixed, so this bug can be closed without further action if that’s the case. I agree, but Andreas said “I think editing each debian/watch file an mangling names is a bit clumsy.” OK, may be I should ignore I: python-biom-format source: debian-watch-file-should-dversionmangle-not-uversionmangle line 3 after the change you can see here http://anonscm.debian.org/viewvc/debian-med/trunk/packages/python-biom-format/trunk/debian/watch?view=diffr1=16994r2=16525diff_format=h We could actually close the bug ... or me reassign the problem to lintian. (Could anybody do this since I'll go offline quite soon for about one week.) I agree that this warning (it’s I only anyways) is invalid now. The justification on https://wiki.debian.org/DEHS says However, using uversionmangle to add the 'dfsg' part to the upstream version should not be considered as correct. This is based on the idea that downloading the upstream sources won't make it DFSG-free, so upstream's version is not DFSG-free but Debian's is. In other words: uversionmangle=s//+dfsg/ is not correct, dversionmangle=s/\+dfsg// is. but with the new features (and Files-Excluded in place), running uscan yields a DFSG-free tarball. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#748919: Ship nsinit
Package: src:docker.io Version: 0.11.1~dfsg1-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi! docker.io source tree contains libcontainer which provides nsinit, a nsenter-like utility that would be useful to interact with instances since we currently don't have any tools for that in Debian (util-linux is not recent enough). Could you provide it in the next package? Example of use: http://jpetazzo.github.io/2014/03/23/lxc-attach-nsinit-nsenter-docker-0-9/ - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTfcL8AAoJEJWkL+g1NSX5ku8P/RN1bBTfHXt9Rb5pcSfHRb2W Fm+N6CIYKHl+3XVElPFmmQka7/Y3rPXzLHTefUoKMoyPVR7mRsxJOxt+WRtkCs67 bbK2HIX74KNBzSmWway5dL4hhh1faLQiCRfFkeBsq4Ej8DbEakQCByNsCQOmGYFG 5dlUjS075JO4IPRjod4jjTlhyuupbUoZJlWeMcl02oHI5c7uqn0wkGFAgXXWQ6a5 CXT+VVIdrUsiceB04EC4qmLt7PHRrqEIibeJrkgm2a/pRRiTwPrA7FEMHr0RCwWs aZHDa/3uk0XBFGBUzT6bhonYtNnTCzdmrFXLEzK15p56AF2+YxaVi/HNUhvGXHKH 4Bgh9SpNDTIC4qgsVoWGlAcR9z0vZEYymKRaG2ghIjMeHM97QWRx7O4+LC1k3Tiq 4LIMdtaGkUHkYKSrDHlBSIxChVdvmi/bRCZeEJIFcpoxdvLCEllshzIYy8s7YKbM iy0QqrxpwbGwuetJFgcQTdiaEQFhfG1gLbg6qNNwgH4qYc1VsDAse52gEOmJNG0R MQHQ9CE3fI+KS2jYX2UVPEnKwFcidVnYnz3OryiyvJZiSVM0po/k3mC+ZN1f/g2f +D0FbIBczlTPjnqlsrGtCGt4CkBPYPOSjA5zXTuuoVgKcVlolgv7tqS1+7pH887X vowZVnrnT87pmWssZcsu =C9mD -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#748920: libjSSC-java: Undefined symbol: _Znwm
Package: libjSSC-java Version: 2.6.0-2 Severity: grave Tags: patch Justification: renders package unusable Dear Maintainer, When using the shared library libjSSC-java.so I get an error message about the unresolved symbol _Znwm. This symbol is related to the C++ new operator and is defined in libsupc++. When adding -lsupc++ to the compile/link lines in debian/rules, the problem disappears: --- jssc-2.6.0/debian/rules.orig2014-05-22 10:57:42.920042986 +0200 +++ jssc-2.6.0/debian/rules 2014-05-22 11:00:15.342106965 +0200 @@ -12,7 +12,7 @@ override_dh_auto_build: dh_auto_build - cc $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) -I$(JAVA_HOME)/include -fPIC -shared -o libjSSC-$(LIBRARY_VERSION).so src/cpp/_nix_based/jssc.cpp + cc $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) -I$(JAVA_HOME)/include -fPIC -shared -o libjSSC-$(LIBRARY_VERSION).so src/cpp/_nix_based/jssc.cpp -lsupc++ override_dh_installchangelogs: dh_installchangelogs -k README.txt This fix is probably somewhat of a workaround. I think cc should have resolved this symbol. Possibly, it is intended that this should be resolved by a shared library version of libsupc++ in which case it is necessary to insert a dependency on this library in libjSSC-java.so. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (1, 'experimental'), (1, 'unstable'), (1, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-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 libjSSC-java depends on: ii libc62.18-5 ii libgcc1 1:4.9.0-3 libjSSC-java recommends no packages. libjSSC-java suggests no packages. -- no debconf information --- jssc-2.6.0/debian/rules.orig 2014-05-22 10:57:42.920042986 +0200 +++ jssc-2.6.0/debian/rules 2014-05-22 11:00:15.342106965 +0200 @@ -12,7 +12,7 @@ override_dh_auto_build: dh_auto_build - cc $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) -I$(JAVA_HOME)/include -fPIC -shared -o libjSSC-$(LIBRARY_VERSION).so src/cpp/_nix_based/jssc.cpp + cc $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) -I$(JAVA_HOME)/include -fPIC -shared -o libjSSC-$(LIBRARY_VERSION).so src/cpp/_nix_based/jssc.cpp -lsupc++ override_dh_installchangelogs: dh_installchangelogs -k README.txt
Bug#747037: nvidia-kernel-common: Please use logind/systemd way of setting ACL's
Control: tag -1 help On 2014-05-05 00:07, bi...@debian.org wrote: After quickly scanning the packages in the archive, it seems that an udev rules file is using old ConsoleKit tags or executables (udev-acl or ACL_MANAGE). The ConsoleKit support was contributed by some user a few years ago - unfortunately I have no clue how this works nor can I update it to the current way. A patch (supporting both logind and non-logind usage) would be highly welcome. Thanks Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748921: debhelper: dh_installinit fails in certain multi-binary packages
Package: debhelper Version: 9.20140228 Severity: normal I have a source package named foo with 2 binary packages foo-ce and foo-pro and one init script available as debian/foo.init. When invoking dh_installinit it works only for the *first* listed binary package but fails for the second package (as in: doesn't install the according init and maintainer scripts). So: dh_installinit -pfoo-ce --name=foo -- defaults 80 works fine because foo-ce is the first listed binary package in debian/control, while: dh_installinit -pfoo-pro --name=foo -- defaults 80 is lacking the init script in the resulting package (which actually isn't easy to spot because of #462389 :-/). - | % dpkg -c ../foo-ce_0.0.1_all.deb | grep init | drwxr-xr-x root/root 0 2014-05-22 11:26 ./etc/init.d/ | -rwxr-xr-x root/root19 2014-05-22 11:04 ./etc/init.d/foo | % dpkg -c ../foo-pro_0.0.1_all.deb| grep init | % When I switch the order of the packages foo-ce and foo-pro in debian/control to foo-pro and foo-ce it works fine for the foo-pro package but fails for foo-ce. One workaround is to create a symlink debian/foo-pro.foo.init pointing to the actual init script: | % ls -la debian/foo-pro.foo.init | lrwxrwxrwx 1 mika mika 8 May 22 11:17 debian/foo-pro.foo.init - foo.init* If you want to reproduce the bug on your own: I've put a minimal working example package online at https://github.com/mika/debhelper-bug (initial commit with old style debhelper packaging, 2nd commit with minimal style debhelper packaging, but you can also just execute the dh_installinit command lines as mentioned above to reproduce the issue). regards, -mika- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014-05-22t11-22...@devnull.michael-prokop.at
Bug#748462: uscan: mk-origtargz choke on .xpi files
mk-origtargz also fails with the tomcat6 and tomcat7 watch files. In these packages we are monitoring a SVN tag which is an HTML document. The file downloaded is discarded but the version detected is used by a script to checkout the SVN repository and create the upstream tarball. Here is the watch file used: version=3 opts=uversionmangle=s/_/./g \ http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/ TOMCAT_([0-9_]*[0-9])/ debian debian/orig-tar.sh This is a common pattern for several packages maintained by the Java Team. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711833: Preparing new package upload
Hei Yoann, there is a newer upstream release of postr[0]. Before we upload a new postr package, we should try to reproduce the existing bugs, import new upstream version, try again to reproduce the exsiting bugs and try to fix any remaining bugs. Here[1] is the list with the bugs reported on postr. If you have not already clone this repository[2]. [0]: https://download.gnome.org/sources/postr/0.13/ [1]: https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=postr [2]: git://git.debian.org/git/collab-maint/postr.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748922: python-apt: TagFile doesnt close file
Package: python-apt Version: 0.9.3.5 Severity: normal Consider the following snippet: --%--- import gc import os import sys import apt_pkg print os.listdir(/proc/self/fd/) f = apt_pkg.TagFile(sys.argv[1]) print os.listdir(/proc/self/fd/) del f print os.listdir(/proc/self/fd/) gc.collect print os.listdir(/proc/self/fd/) --%--- calling apt_pkg.TagFile() opens a file descriptor but that descriptor is not closed when the object gets deleted or even garbage collection is explicitly run. Here the output: ['0', '1', '2', '3'] ['0', '1', '2', '3', '4'] ['0', '1', '2', '3', '4'] ['0', '1', '2', '3', '4'] The opened fd should be closed when the python object is destroyed. cheers, josch -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-apt depends on: ii libapt-inst1.5 1.0.1 ii libapt-pkg4.12 1.0.1 ii libc6 2.18-4 ii libgcc11:4.8.2-16 ii libstdc++6 4.8.2-16 ii python 2.7.5-5 ii python-apt-common 0.9.3.5 Versions of packages python-apt recommends: ii iso-codes3.52-1 ii lsb-release 4.1+Debian12 ii xz-utils 5.1.1alpha+20120614-2 Versions of packages python-apt suggests: pn python-apt-dbg none pn python-apt-doc none ii python-gtk2 2.24.0-3+b1 pn python-vte none -- debconf-show failed -- debsums errors found: sh: 1: /usr/sbin/dpkg-divert: not found -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643341: Discussion about cross compilation, config-scripts and pkg-config at gnupg list
Hi Colin, There is currently a discussion [1] going on at the mailing lists of the GnuPG project about cross-compilation and the pain, the current -config scripts may cause [2]. IMHO it might be a good time to drop in and add your points too. [1] http://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028473.html [2] http://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028484.html Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748923: emscripten: New upstream version (1.16.0) available
Package: emscripten Version: 1.10.0~20140205~ef1e460-1 Severity: wishlist Dear Maintainer, New upstream version (1.16.0) is available. Please consider packaging it. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Versions of packages emscripten depends on: ii clang-3.4 1:3.4.1-2 ii libclosure-compiler-java 20130227+dfsg1-6 ii llvm 1:3.3-21+nmu1 ii nodejs0.10.26~dfsg1-1 pn python:anynone emscripten recommends no packages. emscripten 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#748366: (no subject)
Hi Axel, Are you sure the problem isn't in the graphic driver? Googling around the problem gives almost always a missing 32bit driver on 64bit arch. So maybe it can just be added as runtime dependency of 2048 package http://www.archlinux.it/forum/viewtopic.php?nomobile=1p=137038 Sorry for the i13n of the link, but it gives some useful hints LIBGL_DEBUG=verbose before starting 2048 glxinfo and something like virtualgl-libs:i386 (at least on older ubuntu) cheers, Gianfranco
Bug#747485: meta-gnome3: Please Build-Depend on rygel on linux-any only
Hi, On 09/05/14 11:18, Gabriele Giacone wrote: Source: meta-gnome3 Severity: normal Tags: patch Control: block -1 711947 Dear Maintainer, rygel testsuite fails on both kfreebsd-any and hurd-any. Attached debdiff makes gnome package not to depend on rygel anymore on such archs. Any point in doing this, given that gdm and gnome-shell are linux-any now? The packages are going to be uninstallable anyway, and there's no point in having a gnome meta-package installable if it's not going to, erm, install gnome-shell. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748897: Iceweasel default user agent compromises privacy
On Thu, May 22, 2014 at 04:41:18AM -0400, Rolf Braun wrote: On Thu, May 22, 2014 at 1:00 AM, Mike Hommey m...@glandium.org wrote: On Wed, May 21, 2014 at 11:19:20PM -0400, Rolf Braun wrote: - Inclusion of the Iceweasel token, which is much rarer than standard Firefox. This one is a tough call. You're actually using a not-Firefox browser. And making Iceweasel not emit that part would require awkward changes that would affect more than Iceweasel. Agreed that it's not obviously the right thing to do, and Debian isn't the only vendor to be adding a vendor-specific token to the UA string. But there are fewer users of Debian on the desktop than e.g. Ubuntu, so the issue of being identifiable by this is more concerning. From my perspective as a user, yes, it's technically a non-Firefox browser. But from any website's perspective, it renders and processes HTML and JavaScript the same as Firefox of that version would; the user-agent isn't required to reveal anything more. I'm not sure what else it would affect, though it seems the UA string is being generated in a standard way by code from upstream, so that would have to be patched. An option i can see that could be reasonably upstreamed would be to have a pref that turns the UA to the Firefox one without anything more. - The Gecko build date in the UA reported by Firefox releases is standardized as 20100101. Inclusion of the actual build date allows individual users, especially users of backports or of unstable releases, to be identified almost uniquely,. Firefox removed this ability in the fix for bug 572661, but Debian is continuing to build Firefox with an identifiable build date. Actually, it's not, but there's a bug that only affects esr. If you look at e.g. iceweasel 23 on snapshot.debian.net, you should see Gecko/20100101. Likewise in unstable and experimental. Aurora builds from mozilla.debian.net don't use Gecko/20100101, but it looks like upstream aurora builds do, despite that not matching what is in the source tree. Must be something set on the build side. So all in all, this is mostly an ESR-only issue (also affecting chemspills like 29.0.1), that is mostly fixed in unstable, and essentially fixed in experimental (except for the Iceweasel part) Actually, since version 25 the Gecko version string is always Gecko/20100101, whatever setup is used. https://bugzilla.mozilla.org/show_bug.cgi?id=728773 So I assume from that, it's also fixed for future ESR releases (31?) in testing/stable? Indeed. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745134: live-build: please add man pages for lb commands
package live-build reopen 745134 thanks Excuse me, but this has not been fixed, and the point of the bug tracking system is to track bugs, which cannot be done properly this way. To quote the Debian Policy, §12.1 [1]: If no manual page is available, this is considered as a bug and should be reported to the Debian Bug Tracking System (the maintainer of the package is allowed to write this bug report themselves, if they so desire). Do not close the bug report until a proper man page is available. [1] https://www.debian.org/doc/debian-policy/ch-docs.html#s12.1 Also, for readers of this bug, the missing manpages are present in the previous version of live-build, so you can get a properly documented live-build by installing the version 3.0.5-1, available in Debian stable. Regards, -- ,--. : /` ) Tanguy Ortolo xmpp:tan...@ortolo.eu | `-'Debian Developer irc://irc.oftc.net/Tanguy \_ signature.asc Description: Digital signature
Bug#655219: Info received (Bug#655219: possible remedy may lie in lower ram?)
mlatu, le Thu 22 May 2014 11:56:01 +0200, a écrit : if the attached files dont work for some reason, use these links: 1284.png: https://www.mlatu.de/owncloud/public.php?service=filest=ab5e54c2c975fccff8675e3dc6dca342 It's probably a problem of detecting memory layout. Newer systems use e820 and discontiguous memory, so you end up with only a small part of it. Newer version of gnumach handles it properly. I don't remember exactly which images do have it, gnumach 2:1.3.99.dfsg.git20130610-1 (as its name suggests, released on 10th June 2013) and further have it. The 2013 release was earlier than that, so it doesn't have it, newer snapshots are needed. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655219: Info received (Bug#655219: possible remedy may lie in lower ram?)
Samuel Thibault, le Thu 22 May 2014 12:27:09 +0200, a écrit : The 2013 release was earlier than that, so it doesn't have it, newer snapshots are needed. (which are available, as usual, on http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/ ) Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748925: open/save dialog doesn't react to keyboard
Package: scite Version: 3.4.1-1 I can't type any filename in Scite's save dialog. If the input field has the focus, it doesn't close when I press escape, I have to click on the cancel button or the WM close button. If I click in the folder/file view, escape will close the dialog, but I can't type any name there. The open dialog doesn't react well either to the keyboard. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748922: correction
Hi, sorry, my initial snippet didnt actually call gc.collect. Calling it seems to close the file descriptor. Here another example though, where gc.collect() doesnt work: --%--- import gc, os, sys, apt_pkg print os.listdir(/proc/self/fd/) fd = open(sys.argv[1]) print os.listdir(/proc/self/fd/) pkgs = list(apt_pkg.TagFile(fd)) print os.listdir(/proc/self/fd/) fd.close() print os.listdir(/proc/self/fd/) del fd print os.listdir(/proc/self/fd/) gc.collect() print os.listdir(/proc/self/fd/) --%--- yields this output: ['0', '1', '2', '3'] ['0', '1', '2', '3', '4'] ['0', '1', '2', '3', '4', '5'] ['0', '1', '2', '3', '4'] ['0', '1', '2', '3', '4'] ['0', '1', '2', '3', '4'] So calling apt_pkg.TagFile with passing a fd creates yet another fd temporarily while the original fd doesnt seem to get closed? Investigating this further it seems that deleting pkgs helped and was sufficient to end up with the original four file descriptors. But this also means that there seems to be no way to work on the data returned by apt_pkg.TagFile() without having a file descriptor open? cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748926: manpages-dev: umask(2) example unclear
Package: manpages-dev Version: 3.65-1 Severity: minor Dear Maintainer, the man page for umask(2) is a bit unclear, in that it contains the following line : 0666 ~022 = 0644; i.e., rw-r--r-- that is slightly misleading (took me ~6 hours to understand where the problem was coming from) for anyone who doesn't use ~ as NOT. Suggested fix : replace that line with something like 0666 ! 022 = 0644; since 110 110 110 NAND 000 010 010 = 110 100 100; i.e., rw-r--r-- -- 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/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages manpages-dev depends on: ii manpages 3.65-1 manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii man-db [man-browser] 2.6.7.1-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#748927: hwloc-gather-topology cannot find lstopo
Package: hwloc Version: 1.9-3 Severity: normal Dear Maintainer, hwloc-gather-topology always exits with the following error message: /usr/bin/hwloc-gather-topology: 26: /usr/bin/hwloc-gather-topology: error: not found it seems the packaged script is broken as the variable $lstopo is defined to be $bindir/lstopo-no-graphics (see l.15). lstopo is installed but not lstopo-no-graphics. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages hwloc depends on: ii libc6 2.18-5 ii libcairo2 1.12.16-2 ii libhwloc5 1.9-3 ii libltdl7 2.4.2-1.7 ii libnuma1 2.0.9~rc5-1 ii libtinfo5 5.9+20140118-1 ii libx11-6 2:1.6.2-2 hwloc recommends no packages. hwloc 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#748926: manpages-dev: umask(2) example unclear
On Thu, May 22, 2014 at 12:40 PM, wxcafe wxc...@wxcafe.net wrote: Package: manpages-dev Version: 3.65-1 Severity: minor Dear Maintainer, the man page for umask(2) is a bit unclear, in that it contains the following line : 0666 ~022 = 0644; i.e., rw-r--r-- that is slightly misleading (took me ~6 hours to understand where the problem was coming from) for anyone who doesn't use ~ as NOT. Suggested fix : replace that line with something like 0666 ! 022 = 0644; since 110 110 110 NAND 000 010 010 = 110 100 100; i.e., rw-r--r-- But ~ *is* the C bitwise-NOT operator. So I don't understand this piece: for anyone who doesn't use ~ as NOT... Thus, the existing text seems fine to me. Cheers, Michael -- 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/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages manpages-dev depends on: ii manpages 3.65-1 manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii man-db [man-browser] 2.6.7.1-1 -- no debconf information -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748928: libcaca: misaligned versions between amd64 and i386 architectures
Package: libcaca Severity: normal Dear Maintainer, with the recent release of a new version of the amd64 packages generated from libcaca, there was no corresponding version of the i386 packages. On a multiarch machine, this means that if I want to upgrade the amd64 version of the libcaca0 library the i386 (older) version will get uninstalled. Even if this implies no change (i.e. a binary only update) please make sure that aligned versions of libraries are simultaneously released across different supported archs. This should imply little or no effort on your part. Thanks in advance Giacomo Mulas -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (401, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14.4-jak (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.utf8) 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#748927: hwloc-gather-topology cannot find lstopo
Hello, Raphaël Bleuse, le Thu 22 May 2014 12:49:50 +0200, a écrit : hwloc-gather-topology always exits with the following error message: /usr/bin/hwloc-gather-topology: 26: /usr/bin/hwloc-gather-topology: error: not found it seems the packaged script is broken as the variable $lstopo is defined to be $bindir/lstopo-no-graphics (see l.15). lstopo is installed but not lstopo-no-graphics. Indeed. In the meanwhile, you can install the hwloc-nox package instead. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748929: fails to build from source with upower 0.99
Package: cairo-dock-plug-ins Version: 3.3.2-3.1 User: pkg-utopia-maintain...@lists.alioth.debian.org Usertags: upower-1.0 We're preparing to transition the new upower release into unstable. The new version breaks the API/ABI and will in some cases require porting. Reverse dependencies has been build-tested and your package failed to build. Build log can be found at: http://people.debian.org/~biebl/upower-1.0/ For more information see: http://lists.freedesktop.org/archives/devkit-devel/2013-October/001519.html http://www.hadess.net/2013/10/more-power-management-changes.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748930: fails to build from source with upower 0.99
Package: gnome-applets Version: 3.4.1-4 User: pkg-utopia-maintain...@lists.alioth.debian.org Usertags: upower-1.0 We're preparing to transition the new upower release into unstable. The new version breaks the API/ABI and will in some cases require porting. Reverse dependencies has been build-tested and your package failed to build. Build log can be found at: http://people.debian.org/~biebl/upower-1.0/ For more information see: http://lists.freedesktop.org/archives/devkit-devel/2013-October/001519.html http://www.hadess.net/2013/10/more-power-management-changes.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748931: fails to build from source with upower 0.99
Package: mate-power-manager
Version: 1.8.0+dfsg1-2
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: upower-1.0
We're preparing to transition the new upower release
into unstable. The new version breaks the API/ABI
and will in some cases require porting.
Reverse dependencies has been build-tested and your
package failed to build.
Build log can be found at:
http://people.debian.org/~biebl/upower-1.0/
For more information see:
http://lists.freedesktop.org/archives/devkit-devel/2013-October/001519.html
http://www.hadess.net/2013/10/more-power-management-changes.html
I've attached a build-tested patch backporting changes from upstream
for your convenience. Please test if this works.
(Rumour has it mate-screensaver has a bug which will make it
segfault once m-p-m is updated.)
diff -uriNp mate-power-manager-1.8.0+dfsg1/debian/changelog
u1-mate-power-manager-1.8.0+dfsg1/debian/changelog
--- mate-power-manager-1.8.0+dfsg1/debian/changelog 2014-05-05
10:15:38.0 +0200
+++ u1-mate-power-manager-1.8.0+dfsg1/debian/changelog 2014-05-22
10:44:38.210035262 +0200
@@ -1,3 +1,17 @@
+mate-power-manager (1.8.0+dfsg1-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Bump build-dependency on libupower-glib-dev to = 0.99
+ * Bump dependency on upower to = 0.99
+ * Add patches from upstream for upower 0.99 support:
+0001-avoid-levels-is-0-warning-if-no-kbd-backlight-presen.patch
+0002-remove-battery-recall-logic.patch
+0003-port-mate-power-manager-to-upower-0.99-API.patch
+0005-Improve-UPower1-support.patch
+0006-Other-round-of-fixes-for-UPower-0.99-API-changes.patch
+
+ -- Andreas Henriksson andr...@fatal.se Thu, 22 May 2014 10:36:11 +0200
+
mate-power-manager (1.8.0+dfsg1-2) unstable; urgency=low
* debian/rules:
diff -uriNp mate-power-manager-1.8.0+dfsg1/debian/control
u1-mate-power-manager-1.8.0+dfsg1/debian/control
--- mate-power-manager-1.8.0+dfsg1/debian/control 2014-04-21
23:29:33.0 +0200
+++ u1-mate-power-manager-1.8.0+dfsg1/debian/control2014-05-22
10:36:09.235959226 +0200
@@ -23,7 +23,7 @@ Build-Depends: debhelper (= 9),
libxrandr-dev,
xmlto,
yelp-tools,
- libupower-glib-dev,
+ libupower-glib-dev (= 0.99),
libcanberra-gtk-dev,
libunique-dev,
libgnome-keyring-dev,
@@ -47,7 +47,7 @@ Depends: ${shlibs:Depends},
mate-notification-daemon | notification-daemon,
dbus-x11,
consolekit,
- upower,
+ upower (= 0.99),
mate-power-manager-common (= ${source:Version})
Recommends: udisks
Suggests: policykit-1
diff -uriNp
mate-power-manager-1.8.0+dfsg1/debian/patches/0001-avoid-levels-is-0-warning-if-no-kbd-backlight-presen.patch
u1-mate-power-manager-1.8.0+dfsg1/debian/patches/0001-avoid-levels-is-0-warning-if-no-kbd-backlight-presen.patch
---
mate-power-manager-1.8.0+dfsg1/debian/patches/0001-avoid-levels-is-0-warning-if-no-kbd-backlight-presen.patch
1970-01-01 01:00:00.0 +0100
+++
u1-mate-power-manager-1.8.0+dfsg1/debian/patches/0001-avoid-levels-is-0-warning-if-no-kbd-backlight-presen.patch
2014-05-22 10:42:53.427132913 +0200
@@ -0,0 +1,26 @@
+From 2b3cf01f84204dd5d8204d519e2167b41cda6bc0 Mon Sep 17 00:00:00 2001
+From: Stefan Seyfried seife+...@b1-systems.com
+Date: Wed, 9 Apr 2014 14:43:44 +0200
+Subject: [PATCH 01/15] avoid levels is 0 warning if no kbd backlight present
+
+---
+ src/gpm-kbd-backlight.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/src/gpm-kbd-backlight.c b/src/gpm-kbd-backlight.c
+index 0ac6801..a439e94 100644
+--- a/src/gpm-kbd-backlight.c
b/src/gpm-kbd-backlight.c
+@@ -113,6 +113,9 @@ gpm_kbd_backlight_set (GpmKbdBacklight *backlight,
+guint goal;
+
+g_return_val_if_fail (GPM_IS_KBD_BACKLIGHT (backlight), FALSE);
++ /* avoid warnings if no keyboard brightness is available */
++ if (backlight-priv-max_brightness 1)
++ return FALSE;
+/* if we're setting the same we are, don't bother */
+//g_return_val_if_fail (backlight-priv-brightness_percent != percentage,
FALSE);
+
+--
+2.0.0.rc2
+
diff -uriNp
mate-power-manager-1.8.0+dfsg1/debian/patches/0002-remove-battery-recall-logic.patch
u1-mate-power-manager-1.8.0+dfsg1/debian/patches/0002-remove-battery-recall-logic.patch
---
mate-power-manager-1.8.0+dfsg1/debian/patches/0002-remove-battery-recall-logic.patch
1970-01-01 01:00:00.0 +0100
+++
u1-mate-power-manager-1.8.0+dfsg1/debian/patches/0002-remove-battery-recall-logic.patch
2014-05-22 10:42:59.907312341 +0200
@@ -0,0 +1,281 @@
+From 220a4e0a64aca0579f50e6e57d4eca848b3ac57f Mon Sep 17 00:00:00 2001
+From: Stefan Seyfried seife+...@b1-systems.com
+Date: Wed, 9 Apr 2014 14:58:29 +0200
+Subject: [PATCH 02/15] remove battery recall logic
+
+the database is outdated several years now and the whole interface is
+removed from current UPower release
Bug#748932: idba FTBFS for mips, mipsel, powerpc and sparc
Package: idba
Version: 1.1.1-1
Tags: sid patch
Severity: important
Justification: FTBFS
User: debian-mips-dev-disc...@lists.alioth.debian.org
Usertags: mips-patch
Package idba FTBFS for mips and mipsel, powerpc and sparc with an error:
g++ -Wall -O3 -fopenmp -pthread -g -O2 -Wformat -Werror=format-security
-fopenmp -pthread -Wl,-z,relro -o idba_hybrid idba_hybrid.o
../lib/libassembly.a
idba_hybrid.o: In function `AtomicIntegerunsigned long
long::operator+=(unsigned long long)':
/«PKGBUILDDIR»/bin/../src/basic/atomic_integer.h:38: undefined reference to
`__sync_add_and_fetch_8'
../lib/libassembly.a(hash_graph.o): In function `AtomicIntegerunsigned long
long::operator+=(unsigned long long)':
/«PKGBUILDDIR»/lib/../src/basic/atomic_integer.h:38: undefined reference to
`__sync_add_and_fetch_8'
collect2: error: ld returned 1 exit status
Mips platform does not have 64-bit __sync_* operations.
To avoid this behaviuor it is needed to use
corresponding __atomic_* from libatomic library.
Patch use-atomic-for-mips.patch contains these changes
of src/basic/atomic_integer.h for mips.
Patch add-libatomic-to-LIBS.patch
adds libatomic in LIBS, and as-needed in LDFLAGS into debian/rules.
I believe that this fix could be used for
sparc and powerpc, but unfortunately I
could not test it so I can not guarantee that.
More info you can find at:
https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/_005f_005fatomic-Builtins.html#_005f_005fatomic-Builtins
https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/_005f_005fsync-Builtins.html#_005f_005fsync-Builtins
Could you please consider including this patch?
Best regards,
Dejandiff -uNr idba-1.1.1.orig/bin/Makefile.in idba-1.1.1/bin/Makefile.in
--- idba-1.1.1.orig/bin/Makefile.in 2013-07-23 18:41:33.0 +
+++ idba-1.1.1/bin/Makefile.in 2014-05-20 17:31:36.0 +
@@ -283,7 +283,7 @@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
LDFLAGS = @LDFLAGS@
LIBOBJS = @LIBOBJS@
-LIBS = $(top_srcdir)/lib/libassembly.a
+LIBS = $(top_srcdir)/lib/libassembly.a @LIBS@
LTLIBOBJS = @LTLIBOBJS@
MAKEINFO = @MAKEINFO@
MKDIR_P = @MKDIR_P@
diff -uNr idba-1.1.1.orig/src/basic/atomic_integer.h idba-1.1.1/src/basic/atomic_integer.h
--- idba-1.1.1.orig/src/basic/atomic_integer.h 2013-07-23 18:27:57.0 +
+++ idba-1.1.1/src/basic/atomic_integer.h 2014-05-20 15:12:28.0 +
@@ -35,19 +35,40 @@
bool operator ==(const AtomicIntegerT x) const { return value_ == x.value_; }
bool operator !=(const AtomicIntegerT x) const { return value_ != x.value_; }
-T operator += (T x) { return __sync_add_and_fetch(value_, x); }
-T operator -= (T x) { return __sync_sub_and_fetch(value_, x); }
-T operator |= (T x) { return __sync_or_and_fetch(value_, x); }
-T operator = (T x) { return __sync_and_and_fetch(value_, x); }
-T operator ^= (T x) { return __sync_xor_and_fetch(value_, x); }
-
-T operator ++() { return __sync_add_and_fetch(value_, 1); }
-T operator ++(int) { return __sync_fetch_and_add(value_, 1); }
-T operator --() { return __sync_sub_and_fetch(value_, 1); }
-T operator --(int) { return __sync_fetch_and_sub(value_, 1); }
-bool CompareAndSet(T old_value, T new_value)
-{ return __sync_bool_compare_and_swap(value_, old_value, new_value); }
+# if defined(__mips__) !defined(__mips64)
+
+T operator += (T x) { return __atomic_add_fetch(value_, x,__ATOMIC_SEQ_CST); }
+T operator -= (T x) { return __atomic_sub_fetch(value_, x, __ATOMIC_SEQ_CST); }
+T operator |= (T x) { return __atomic_or_fetch(value_, x, __ATOMIC_SEQ_CST); }
+T operator = (T x) { return __atomic_and_fetch(value_, x, __ATOMIC_SEQ_CST); }
+T operator ^= (T x) { return __atomic_xor_fetch(value_, x, __ATOMIC_SEQ_CST); }
+
+T operator ++() { return __atomic_add_fetch(value_, 1, __ATOMIC_SEQ_CST); }
+T operator ++(int) { return __atomic_fetch_add(value_, 1, __ATOMIC_SEQ_CST); }
+T operator --() { return __atomic_sub_fetch(value_, 1, __ATOMIC_SEQ_CST); }
+T operator --(int) { return __atomic_fetch_sub(value_, 1, __ATOMIC_SEQ_CST); }
+
+bool CompareAndSet(T old_value, T new_value)
+{ return __atomic_compare_exchange(value_, old_value, new_value, false, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST); }
+
+# else
+
+T operator += (T x) { return __sync_add_and_fetch(value_, x); }
+T operator -= (T x) { return __sync_sub_and_fetch(value_, x); }
+T operator |= (T x) { return __sync_or_and_fetch(value_, x); }
+T operator = (T x) { return __sync_and_and_fetch(value_, x); }
+T operator ^= (T x) { return __sync_xor_and_fetch(value_, x); }
+
+T operator ++() { return __sync_add_and_fetch(value_, 1); }
+T operator ++(int) { return __sync_fetch_and_add(value_, 1); }
+T operator --() { return __sync_sub_and_fetch(value_, 1); }
+T operator --(int) { return __sync_fetch_and_sub(value_, 1); }
+
+bool
Bug#748933: gramps: missing recommands on gir1.2-gexiv2-0.10
Package: gramps Version: 4.0.3+dfsg-3 Severity: normal Hi, Without gir1.2-gexiv2-0.10 installed on the machine, gramps presents a difficult to understand message at startup. There is upstream documentation (as told in the message) here: https://gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#GExiv2_for_Image_metadata The solution explained for Ubuntu 14.04 - Trusty Tahr also works for Debian, ie installing gir1.2-gexiv2-0.10. https://gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#Ubuntu_14.04_-_Trusty_Tahr_2 I let you decide if you want to put it as a Depends or a Recommends (as, strictly speaking, gramps can work without this package) Regards, Vincent -- System Information: Debian Release: jessie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armel mipsel Kernel: Linux 3.14-1-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 gramps depends on: ii gir1.2-gtk-3.0 3.12.2-1 ii librsvg2-2 2.40.2-1 ii python 2.7.6-1 ii python-gi3.12.1-1 ii python-gi-cairo 3.12.1-1 pn python:any none ii xdg-utils1.1.0~rc1+git20111210-7.1 Versions of packages gramps recommends: ii gir1.2-osmgpsmap-1.0 1.0.2-1 ii graphviz 2.34.0-1~build2.1 ii libosmgpsmap-1.0-01.0.2-1 ii python-pyicu 1.5-2+b3 Versions of packages gramps suggests: ii fonts-freefont-ttf20120503-4 pn gir1.2-gexiv2-0.4 none pn gir1.2-gtkspell3-3.0 none ii gir1.2-webkit-3.0 2.2.6-1 ii python-pil2.3.0-2 pn rcs 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#748934: fails to build from source with upower 0.99
Package: mate-session-manager
Version: 1.8.1-2
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: upower-1.0
We're preparing to transition the new upower release
into unstable. The new version breaks the API/ABI
and will in some cases require porting.
Reverse dependencies has been build-tested and your
package failed to build.
Build log can be found at:
http://people.debian.org/~biebl/upower-1.0/
For more information see:
http://lists.freedesktop.org/archives/devkit-devel/2013-October/001519.html
http://www.hadess.net/2013/10/more-power-management-changes.html
I've attached a patch for your convenience which disables
the upower backend (and relies on the logind fallback).
This seems to be the recommended way by upstream.
diff -uriNp mate-session-manager-1.8.1/debian/changelog
u1-mate-session-manager-1.8.1/debian/changelog
--- mate-session-manager-1.8.1/debian/changelog 2014-05-05 14:28:44.0
+0200
+++ u1-mate-session-manager-1.8.1/debian/changelog 2014-05-22
11:09:14.344348878 +0200
@@ -1,3 +1,15 @@
+mate-session-manager (1.8.1-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add --disable-upower to debian/rules
+- the upower code only works with 0.99
+- this makes mate-session-manager rely on logind
+ (which was previously a fallback option after upower)
+- kfreebsd? non suspend support for you!
+ * Drop libupower-glib-dev build-dependency and upower dependency
+
+ -- Andreas Henriksson andr...@fatal.se Thu, 22 May 2014 11:02:21 +0200
+
mate-session-manager (1.8.1-2) unstable; urgency=medium
[ Mike Gabriel ]
diff -uriNp mate-session-manager-1.8.1/debian/control
u1-mate-session-manager-1.8.1/debian/control
--- mate-session-manager-1.8.1/debian/control 2014-05-05 14:20:23.0
+0200
+++ u1-mate-session-manager-1.8.1/debian/control2014-05-22
11:03:27.510220629 +0200
@@ -11,7 +11,6 @@ Build-Depends: debhelper (= 9),
intltool,
libglib2.0-dev,
libgtk2.0-dev,
- libupower-glib-dev,
libdbus-glib-1-dev,
libstartup-notification0-dev,
libsm-dev,
@@ -35,8 +34,7 @@ Package: mate-session-manager
Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends},
- dbus-x11,
- upower
+ dbus-x11
Recommends: mate-settings-daemon,
mate-panel,
marco,
diff -uriNp mate-session-manager-1.8.1/debian/rules
u1-mate-session-manager-1.8.1/debian/rules
--- mate-session-manager-1.8.1/debian/rules 2014-04-09 00:45:27.0
+0200
+++ u1-mate-session-manager-1.8.1/debian/rules 2014-05-22 11:02:15.436157915
+0200
@@ -19,6 +19,7 @@ override_dh_auto_configure:
--localstatedir=/var/lib \
--libexecdir=/usr/lib \
--disable-introspection \
+ --disable-upower \
--with-gtk=2.0
override_dh_strip:
Bug#748935: fails to build from source with upower 0.99
Package: wmbattery Version: 2.42 User: pkg-utopia-maintain...@lists.alioth.debian.org Usertags: upower-1.0 We're preparing to transition the new upower release into unstable. The new version breaks the API/ABI and will in some cases require porting. Reverse dependencies has been build-tested and your package failed to build. Build log can be found at: http://people.debian.org/~biebl/upower-1.0/ For more information see: http://lists.freedesktop.org/archives/devkit-devel/2013-October/001519.html http://www.hadess.net/2013/10/more-power-management-changes.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748936: apt doesnt understand architecture wildcards
Package: apt Version: 1.0.1 Severity: normal Hi, Debian policy 11.1.1 [1] and the associated footnote [2] allow architecture wildcards of the form os-any and any-cpu. Apt seems to equal cpu with debian architecture which is not correct. Here is an example of correct matching: dpkg-architecture -aarmhf -iany-arm echo any-arm matches armhf Apt would instead only match the deprecated arm architecture with any-arm. This doesnt seem to be a problem in practice though because: 1) apt does not check whether a source package can be compiled on the current host architecture (it ignores the Architecture field of source packages) 2) all packages that have any-arm in their build dependency architecture restrictions also include any-armel, any-armeb and any-armhf Nevertheless, apt behaviour should reflect dpkg behaviour and naturally policy. The correct behaviour is encoded in dpkg scripts/Dpkg/Arch.pm and needs the files /usr/share/dpkg/triplettable and /usr/share/dpkg/cputable to work correctly. cheers, josch [1] https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-wildcard-spec [2] https://www.debian.org/doc/debian-policy/footnotes.html#f99 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736062: marked as done (emacsen-common: emacs-package-install --preinst displays incorrect error message)
On Wed, May 21, 2014 at 09:36:24PM +, Debian Bug Tracking System wrote: emacsen-common (2.0.8) unstable; urgency=medium . * Require add-on packages to depend on emacsen-common = 2.0.8. This should be simpler and safer, and emacsen-common is only ~140k, which shouldn't be too big a burden. Hi, Rob, I see that you finally went for the emacsen-common dependency as lesser evil, fine. While I would have preferred avoiding the dependency, I admit that we could not find something simple and rock solid to deal with the underlying problems without it. One question here, does the dependency really needs to be this tight? I mean, would emacsen-common (= 2.0.5) be enough? That is the emacsen-common version in unstable and would help a lot with use of newer add-on packages in stable. Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748937: ITP: ruby-redis-namespace -- namespace calls to Redis when multiple apps access a single redis server
Package: wnpp Severity: wishlist Owner: Praveen Arimbrathodiyil prav...@debian.org * Package name: ruby-redis-namespace Version : 1.4.1 Upstream Author : Chris Wanstrath, Terence Lee, Steve Klabnik * URL : https://rubygems.org/gems/redis-namespace * License : Expat Programming Lang: Ruby Description : namespace calls to Redis when multiple apps access a single redis server Adds a Redis::Namespace class which can be used to namespace calls to Redis. This is useful when using a single instance of Redis with multiple, different applications. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748938: fails to build from source with upower 0.99
Package: telepathy-mission-control-5
Version: 1:5.16.1-1
User: pkg-utopia-maintain...@lists.alioth.debian.org
Usertags: upower-1.0
We're preparing to transition the new upower release
into unstable. The new version breaks the API/ABI
and will in some cases require porting.
Reverse dependencies has been build-tested and your
package failed to build.
Build log can be found at:
http://people.debian.org/~biebl/upower-1.0/
For more information see:
http://lists.freedesktop.org/archives/devkit-devel/2013-October/001519.html
http://www.hadess.net/2013/10/more-power-management-changes.html
I've attached a trivial build-tested patch for your convenince
that simply disables upower, because the code already seems to
fall back on logind. Please verify this works for you.
diff -uriNp telepathy-mission-control-5-5.16.1/debian/changelog
u1-telepathy-mission-control-5-5.16.1/debian/changelog
--- telepathy-mission-control-5-5.16.1/debian/changelog 2014-01-27
13:44:17.0 +0100
+++ u1-telepathy-mission-control-5-5.16.1/debian/changelog 2014-05-22
13:40:41.555916821 +0200
@@ -1,3 +1,12 @@
+telepathy-mission-control-5 (1:5.16.1-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/rules: switch from --enable-upower to --disable-upower
+- Now rely solely on PrepareForSleep DBus signal (from logind)
+ * debian/control: drop libupower-glib-dev build-dependency
+
+ -- Andreas Henriksson andr...@fatal.se Thu, 22 May 2014 13:28:34 +0200
+
telepathy-mission-control-5 (1:5.16.1-1) unstable; urgency=medium
* debian/watch: only watch for stable versions (5.y.z, y even)
diff -uriNp telepathy-mission-control-5-5.16.1/debian/control
u1-telepathy-mission-control-5-5.16.1/debian/control
--- telepathy-mission-control-5-5.16.1/debian/control 2014-01-27
13:44:17.0 +0100
+++ u1-telepathy-mission-control-5-5.16.1/debian/control2014-05-22
13:28:33.160819778 +0200
@@ -14,7 +14,6 @@ Build-Depends: debhelper (= 9),
libdbus-glib-1-dev (= 0.82),
libglib2.0-dev (= 2.32),
libtelepathy-glib-dev (= 0.20),
- libupower-glib-dev,
libnm-glib-dev [linux-any],
pkg-config,
python (= 2.6),
diff -uriNp telepathy-mission-control-5-5.16.1/debian/rules
u1-telepathy-mission-control-5-5.16.1/debian/rules
--- telepathy-mission-control-5-5.16.1/debian/rules 2014-01-27
13:44:17.0 +0100
+++ u1-telepathy-mission-control-5-5.16.1/debian/rules 2014-05-22
13:38:49.432379690 +0200
@@ -7,7 +7,7 @@ CONFIGURE_FLAGS = --libexecdir=\$${prefi
--enable-gtk-doc \
--enable-gnome-keyring \
--with-html-dir=\$${prefix}/share/doc/libmission-control-plugins-doc \
- --enable-upower
+ --disable-upower
# We specifically do not want multiarch: only one version of MC can be
# installed anyway, the plugin directory is based on the ${libdir}, and
Bug#700571: [Python-modules-team] Bug#700571: python-psutil: Import fail
I'm sorry, but I have no longer any access to the environment in which I was able to produce the issue... :( On Tue, May 6, 2014 at 4:15 PM, Sandro Tosi sandro.t...@gmail.com wrote: Hello, can you confirm if this is still happening with the latest 2.1.1-1 version? Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- Kevin Deldycke • blog: http://kevin.deldycke.com • band: http://coolcavemen.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748456: liferea: crashes when selecting any feed
On Sat, May 17, 2014 at 02:30:00PM +0200, Johannes Schauer wrote: Package: liferea Version: 1.10.8-1 Severity: grave Justification: renders package unusable Hi, steps to reproduce: I didn't use a chroot but installed liferea in my own system and I can't reproduce the bug, everything seems to work normally. Javascript is enabled. From your backtrace, the problem is in VMEntryScope::requiredCapacity() RELEASE_ASSERT(m_stack.size() = requiredCapacity); Can you reproduce it 100% of the time? Did you try in a different system? ii liferea 1.10.8-1 ii liferea-data 1.10.8-1 ii libjavascriptcoregtk-3.0-0:amd64 2.4.2-1 ii libjavascriptcoregtk-3.0-bin 2.4.2-1 ii libwebkit2gtk-3.0-25:amd642.4.2-1 ii libwebkitgtk-3.0-0:amd64 2.4.2-1 ii libwebkitgtk-3.0-common 2.4.2-1 Berto -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748939: the current version on sid of chromium-inspector is 35 but chromium itself is 33
Package: chromium The current version on sid of chromium-inspector is 35 but chromium itself is 33. I am not sure if that is bad. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747899: hgview crashes since upgrade to mercurial 2.9.2-1
On Thu, May 15, 2014 at 15:31:07 +0200, Julien Cristau wrote: Control: tags -1 confirmed upstream fixed-upstream On Mon, May 12, 2014 at 19:01:43 +0200, Jeremy P. wrote: Package: hgview Version: 1.8.0-1 Severity: grave Justification: renders package unusable jeremyp@sky[~] cd /tmp/ jeremyp@sky[/tmp] mkdir test jeremyp@sky[/tmp] cd test/ jeremyp@sky[/tmp/test] hg init jeremyp@sky[/tmp/test] hg --version Mercurial Distributed SCM (version 2.9.2) (see http://mercurial.selenic.com for more information) Copyright (C) 2005-2014 Matt Mackall and others This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. jeremyp@sky[/tmp/test] dpkg -l mercurial Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---== ii mercurial 2.9.2-1 amd64easy-to-use, scalable distributed version control system jeremyp@sky[/tmp/test] hgview Traceback (most recent call last): File /usr/local/bin/hgview, line 38, in module main() File /usr/local/lib/python2.7/dist-packages/hgviewlib/application.py, line 225, in main sys.exit(start(repo, opts, args, parser.error)) File /usr/local/lib/python2.7/dist-packages/hgviewlib/application.py, line 173, in start app = Application(repo, opts, args) File /usr/local/lib/python2.7/dist-packages/hgviewlib/qt4/application.py, line 54, in __init__ super(HgViewQtApplication, self).__init__(*args, **kwargs) File /usr/local/lib/python2.7/dist-packages/hgviewlib/application.py, line 83, in __init__ self.choose_viewer() File /usr/local/lib/python2.7/dist-packages/hgviewlib/application.py, line 107, in choose_viewer viewer = self.HgRepoViewer(self.repo) File /usr/local/lib/python2.7/dist-packages/hgviewlib/qt4/hgrepoviewer.py, line 90, in __init__ self.setupBranchCombo() File /usr/local/lib/python2.7/dist-packages/hgviewlib/qt4/hgrepoviewer.py, line 168, in setupBranchCombo allbranches = sorted(self.repo.branchtags().items()) AttributeError: 'localrepository' object has no attribute 'branchtags' Javier, could you add Breaks on hgview ( 1.8.1) to mercurial in sid? Actually make that hgview-common, it's not specific to the qt part. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748938: [Pkg-telepathy-maintainers] Bug#748938: fails to build from source with upower 0.99
Hi, On 22/05/14 13:44, Andreas Henriksson wrote: Package: telepathy-mission-control-5 Version: 1:5.16.1-1 User: pkg-utopia-maintain...@lists.alioth.debian.org Usertags: upower-1.0 We're preparing to transition the new upower release into unstable. The new version breaks the API/ABI and will in some cases require porting. Reverse dependencies has been build-tested and your package failed to build. Build log can be found at: http://people.debian.org/~biebl/upower-1.0/ For more information see: http://lists.freedesktop.org/archives/devkit-devel/2013-October/001519.html http://www.hadess.net/2013/10/more-power-management-changes.html I've attached a trivial build-tested patch for your convenince that simply disables upower, because the code already seems to fall back on logind. Please verify this works for you. I think that would be fine: 23:01 @pochu mbiebl: telepathy-mission-control supports logind, so we could disable upower (see http://cgit.freedesktop.org/telepathy/telepathy-mission-control/commit/?h=nextid=ec348cd0fc7c456de226034a5b1ec8dc5fccdc9c and https://bugs.freedesktop.org/show_bug.cgi?id=70458) Regards, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748910: CVE-2014-0240: Possibility of local privilege escalation when using daemon, mode
On 2014-05-22 09:57, Eric Sesterhenn wrote: Package: libapache2-mod-wsgi Version: 3.3-4 Severity: critical Tags: security Justification: root security hole Dear Maintainer, as far as I can tell, CVE-2014-0240 affects the stable package of mod-wsgi. The patch provided by the mod-wsgi team applies wih fuzzing to the source shipped by debian. If a kernel = 2.6.0 and 3.1.0 is installed, this issue might allow local privilege escalation I'll upload fixed packages for squeeze and wheezy later today. Cheers, Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742942: gparted stuck at searching /dev/sdc partitions
Package: gparted Version: 0.16.1-1 Followup-For: Bug #742942 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Installing any version of gparted from 0.16.1-1 onwards and starting it. * What exactly did you do (or not do) that was effective (or ineffective)? # dpkg -i gparted_0.16.1-1_i386.deb dpkg: warning: downgrading gparted from 0.16.2-1 to 0.16.1-1 (Reading database ... 643117 files and directories currently installed.) Preparing to unpack gparted_0.16.1-1_i386.deb ... Unpacking gparted (0.16.1-1) over (0.16.2-1) ... Setting up gparted (0.16.1-1) ... Processing triggers for man-db (2.6.7.1-1) ... Processing triggers for hicolor-icon-theme (0.13-1) ... Processing triggers for mime-support (3.55) ... Warning: package mozilla listed in /etc/mailcap.order does not have mailcap entries. Processing triggers for desktop-file-utils (0.22-1) ... Processing triggers for menu (2.1.46) ... victoria:/home/amarsh04# gparted == libparted : 2.3 == (gpartedbin:15278): GLib-CRITICAL **: Source ID 7 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 6 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 27 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 32 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 31 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 37 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 36 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 48 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 47 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 53 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 52 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 58 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 61 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 60 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 64 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 63 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 67 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 66 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 70 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 69 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 81 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 80 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 88 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 87 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 95 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 94 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 102 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 101 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 105 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 104 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 112 was not found when attempting to remove it (gpartedbin:15278): GLib-CRITICAL **: Source ID 111 was not found when attempting to remove it (gpartedbin:15278): glibmm-CRITICAL **: unhandled exception (type Glib::Error) in signal handler: domain: g_convert_error code : 1 what : Invalid byte sequence in conversion input * What was the outcome of this action? * What outcome did you expect instead? normal operation, completing the disk scan. *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.15.0-rc6 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gparted depends on: ii libatkmm-1.6-1 2.22.7-2 ii libc6 2.18-7 ii
Bug#745014: src:syslog-ng: please update build-depends from libjson0-dev to libjson-c-dev
Ondřej Surý ond...@debian.org writes: the json-c upstream has dropped an compatibility layer from libjson0(-dev) to libjson-c2(-dev) in current upstream release. Please update your build-depends from libjson0-dev to libjson-c-dev. Thanks for the notice, it will be corrected with the next syslog-ng upload. -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747020: syslog-ng-core: Add /var/log/error to /etc/logrotate.d/syslog-ng
Facundo Aguirre facu...@creativadigital.com.ar writes: I think that /var/log/error should be in /etc/logrotate.d/syslog-ng like all the others files that are managed by the default configuration of syslog-ng-core. Thanks for noticing this omission, it will be fixed in the next upload! -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748940: iscsitarget: service iscsitaget stop fails when under load
Package: iscsitarget Version: 1.4.20.2-10.1 Severity: important Tags: upstream Under heavy load the iscsitarget services fails to stop on module removal. # service iscsitarget stop [ ok ] Removing iSCSI enterprise target devices: :. [ ok ] Stopping iSCSI enterprise target service: :. [] Removing iSCSI enterprise target modules: :FATAL: Module iscsi_trgt is in use. Changing etc/init/init.debian to use `rmmod --wait` instead of `modprobe -r` corrects this issue. This problem causes pacemaker to halt on failover to a secondary node when using the lsb resouce agent to control iscsitarget. -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages iscsitarget depends on: ii libc6 2.13-38+deb7u1 ii lsb-base 4.1+Debian8+deb7u1 ii procps1:3.3.3-3 Versions of packages iscsitarget recommends: pn iscsitarget-module none Versions of packages iscsitarget suggests: ii iscsitarget-dkms 1.4.20.2-10.1 -- Configuration Files: /etc/default/iscsitarget changed: ISCSITARGET_ENABLE=true ISCSITARGET_OPTIONS= /etc/iet/ietd.conf changed: # CHAP Users # # The same rules as for discovery users apply here. # # Don't set them if you don't want to use CHAP authentication. # #IncomingUser joe secret #OutgoingUser jim 12charpasswd # # Logical Unit definition # # Block devices, regular files (fileio only), LVM, and RAID # can be offered to the initiators as a block device. # # Lun numbers MUST start with zero (each target needs a Lun 0) # #Lun 0 Path=/dev/sdc,Type=fileio,ScsiId=xyz,ScsiSN=xyz # # Alias name for this target (Not Used) # #Alias Test # # Various iSCSI parameters # (not all are used right now, see also iSCSI spec for details) # # Outgoing SCSI data (initiator to target user data or command # parameters) is sent as either solicited data or unsolicited data. # Solicited data is sent in response to R2T PDUs. Unsolicited data # can be sent as part of an iSCSI command PDU sequence # (Immediate Data) or as a separate iSCSI data PDU sequence. # #MaxConnections 1 # Number of connections/session # We only support 1 #MaxSessions0 # Number of sessions/target # 0 = no explicit limit #InitialR2T Yes # Wait first for R2T # Yes = no unsolicited data #ImmediateData Yes # Data can accompany command # Yes = cmnd/data in same PDU #MaxRecvDataSegmentLength 8192 # Max data per PDU to receive #MaxXmitDataSegmentLength 8192 # Max data per PDU to transmit #MaxBurstLength 262144 # Max data per sequence (R2T) #FirstBurstLength 65536 # Max unsolicited data sequence #DefaultTime2Wait 2 # Secs to wait for ini to logout # also secs for ini to wait # before logging back in # Not implemented, but settable #DefaultTime2Retain 0 # Secs keep session after logout # We only support 0 #MaxOutstandingR2T 1 # Max outstanding R2Ts per cmnd #DataPDUInOrder Yes # Data in PDUs is ordered # We only support ordered #DataSequenceInOrderYes # PDUs in sequence are ordered # We only support ordered #ErrorRecoveryLevel 0 # We only support level 0 #HeaderDigest None,CRC32C # PDU header checksum algo list # None or CRC32C # If only one is set then the # initiator must agree to it # or the connection will fail #DataDigest None,CRC32C # PDU data checksum algo list # Same as above #MaxSessions0 # Maximum number of sessions to # this target - 0 =
Bug#744182: syslog-ng: include option should be befor the log paths in the main syslog-ng.conf file
jdossan...@docs.homelinux.org writes: The @include /etc/syslog-ng/conf.d/ option is on the bottom of the syslog-ng.conf file, but it should be befor the log paths, as example: Good catch, I'll consider updating the default config with the next syslog-ng upload. Thanks for the suggestion! (Putting the includes at the end had other, beneficial properties, so moving them further up isn't as straightforward as one might imagine. It can easily break existing configurations, which is something I'd rather avoid. But I'll explore my options anyway!) -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736062: marked as done (emacsen-common: emacs-package-install --preinst displays incorrect error message)
On Thu, May 22, 2014 at 01:36:59PM +0200, Agustin Martin wrote: One question here, does the dependency really needs to be this tight? I mean, would emacsen-common (= 2.0.5) be enough? That is the emacsen-common version in unstable and would help a lot with use of newer add-on packages stable in stable. Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739768: This bug is now fixed in ubuntu
There is some movement on this bug other places. It is now fixed in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1310919 It is also active upstream, but as I have understood not included yet: https://bugzilla.samba.org/show_bug.cgi?id=10490 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748456: liferea: crashes when selecting any feed
On 22/05/14 13:48, Alberto Garcia wrote: On Sat, May 17, 2014 at 02:30:00PM +0200, Johannes Schauer wrote: Package: liferea Version: 1.10.8-1 Severity: grave Justification: renders package unusable Hi, steps to reproduce: I didn't use a chroot but installed liferea in my own system and I can't reproduce the bug, everything seems to work normally. Javascript is enabled. From your backtrace, the problem is in VMEntryScope::requiredCapacity() RELEASE_ASSERT(m_stack.size() = requiredCapacity); Can you reproduce it 100% of the time? Did you try in a different system? Besides, why are you running liferea from a chroot? And what version of webkit and javascriptcore do you have? Next time please use reportbug. Emilio ii liferea 1.10.8-1 ii liferea-data 1.10.8-1 ii libjavascriptcoregtk-3.0-0:amd64 2.4.2-1 ii libjavascriptcoregtk-3.0-bin 2.4.2-1 ii libwebkit2gtk-3.0-25:amd642.4.2-1 ii libwebkitgtk-3.0-0:amd64 2.4.2-1 ii libwebkitgtk-3.0-common 2.4.2-1 Berto ___ Pkg-webkit-maintainers mailing list pkg-webkit-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-webkit-maintainers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748249: gnome-shell: Unable to shutdown
I've installed systemd-sysv, but the system removed sysvinit-core and now the shutdown from the desktop works as normal user. Will it be included in future updates? Thanks to all -- XMPP: a...@inventati.org OpenPGP Key-Id: 0xC2040128 signature.asc Description: OpenPGP digital signature
Bug#748941: [Pkg-mediawiki-devel] Bug#748941: mediawiki-classes: fails to install, trying to overwrite other packages files
On Thu, 22 May 2014, Holger Levsen wrote: Preparing to unpack .../mediawiki-classes_1%3a1.19.15+dfsg-2_all.deb ... Unpacking mediawiki-classes (1:1.19.15+dfsg-2) ... dpkg: error processing archive /var/cache/apt/archives/mediawiki- classes_1%3a1.19.15+dfsg-2_all.deb (--unpack): trying to overwrite '/usr/share/mediawiki/includes/libs/IEUrlExtension.php', which is also in package mediawiki 1:1.19.15+dfsg-0+deb7u1 Yes, the last stable update doesn’t mesh that well with what is in unstable. Does this work if you first recompile the wheezy package with… http://anonscm.debian.org/viewvc/pkg-mediawiki?view=revisionrevision=544 …applied, then upgrade from it to jessie/sid? I can look at this Monday at the earliest. Learning about web security right now… bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748456: liferea: crashes when selecting any feed
Hi, Quoting Emilio Pozuelo Monfort (2014-05-22 14:32:02) On 22/05/14 13:48, Alberto Garcia wrote: On Sat, May 17, 2014 at 02:30:00PM +0200, Johannes Schauer wrote: Package: liferea Version: 1.10.8-1 Severity: grave Justification: renders package unusable Hi, steps to reproduce: I didn't use a chroot but installed liferea in my own system and I can't reproduce the bug, everything seems to work normally. Javascript is enabled. From your backtrace, the problem is in VMEntryScope::requiredCapacity() RELEASE_ASSERT(m_stack.size() = requiredCapacity); Can you reproduce it 100% of the time? Yes. I tried to start liferea five times. Did you try in a different system? No. I thought using a chroot would avoid any problems because of my system configuration. Hence I found it unnecessary to try on a different system. Besides, why are you running liferea from a chroot? To make sure that my system configuration cannot be the reason for this bug to happen. And what version of webkit and javascriptcore do you have? Next time please use reportbug. I ran my initial steps to reproduce again and here are the package versions: Versions of packages liferea depends on: ii dconf-gsettings-backend [gsettings-backend] 0.20.0-2 ii gir1.2-gtk-3.0 3.12.2-1 ii gir1.2-peas-1.0 1.10.0-2 ii libatk1.0-0 2.12.0-1 ii libc62.18-7 ii libcairo21.12.16-2 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libgirepository-1.0-11.40.0-2 ii libglib2.0-0 2.40.0-3 ii libgtk-3-0 3.12.2-1 ii libindicate5 0.6.92-2 ii libjson-glib-1.0-0 1.0.0-1 ii libnotify4 0.7.6-2 ii libpango-1.0-0 1.36.3-1 ii libpeas-1.0-01.10.0-2 ii libsoup2.4-1 2.46.0-2 ii libsqlite3-0 3.8.4.3-3 ii libwebkitgtk-3.0-0 2.4.2-1 ii libxml2 2.9.1+dfsg1-3 ii libxslt1.1 1.1.28-2 ii liferea-data 1.10.8-1 ii python-gi3.12.1-1 pn python:any none Versions of packages liferea recommends: ii dbus 1.8.2-1 ii dbus-x11 1.8.2-1 ii gir1.2-gnomekeyring-1.0 3.8.0-2 ii gnome-icon-theme 3.12.0-1 ii gnome-keyring3.12.0-2 ii steadyflow 0.2.0-1 Versions of packages liferea suggests: pn network-manager none I can still reproduce the problem with current Debian sid and liferea quits once I select any feed with the WTFCrash+0x17 error. In case you do not consider this bug valid because I execute liferea inside a chroot: I get the same backtrace when executing liferea on my host system. Though there I can of course not vouch that my local configuration influences my result. Also, this error is not local to liferea. Other programs using libjavascriptcoregtk fail with the same error. If I replace apt-get install liferea with apt-get install surf in my instructions above and then do: $ sudo chroot debian-sid surf google.com Then surf will also quit with a WTFCrash+0x17 error just as liferea did. This error with surf is reproducible on my host system as well. David Smith mentioned that he could only reproduce the error if he hadnt installed a regular DE (such as icewm). I do not have a regular DE installed on my host machine either (and naturally also not inside the chroot). If liferea, surf or other applications using libjavascriptcoregtk need a DE or anything else that a minimal chroot (and my host system) doesnt have and which makes it crash, then it should be mentioned in its Depends. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748456: liferea: crashes when selecting any feed
On Thu, May 22, 2014 at 02:56:47PM +0200, Johannes Schauer wrote: David Smith mentioned that he could only reproduce the error if he hadnt installed a regular DE (such as icewm). That's useful information, thanks! Berto -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#293412: Fwd: openldap pthread linkage on hurd
Forwaring to debian-hurd... Original Message Subject: openldap pthread linkage on hurd Date: Sat, 17 May 2014 11:01:17 -0700 From: Ryan Tandy r...@nardis.ca To: Robert Millan r...@debian.org CC: 293...@bugs.debian.org [delivery to aybabtu.com failed because it refused connections, trying again...] Hi Robert, It's been quite a long time since the last update to this bug. I'm not familiar with GNU/Hurd, but AFAICT from the buildd logs, openldap seems to build and link properly now; the current testsuite failure is covered in #693971. Can you comment on that? Do you know whether the problem reported in this bug still exists? thanks, Ryan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693971: (no subject)
Hello, We were not aware of this bug report. Jelmer Vernooij, le Sun 20 Apr 2014 22:03:03 +0200, a écrit : As far as I can tell, file locking is a necessary feature. Is there any bug against the hurd about file locking that we could make this bug block on? The Hurd does have some file locking, just not record file locking yet (patch is pending review/polishing). So only coarse file-level locking is supported for now. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742942: gparted stuck at searching /dev/sdc partitions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/22/2014 8:18 AM, Arthur Marsh wrote: (gpartedbin:15278): glibmm-CRITICAL **: unhandled exception (type Glib::Error) in signal handler: domain: g_convert_error code : 1 what : Invalid byte sequence in conversion input * What was the outcome of this action? * What outcome did you expect instead? normal operation, completing the disk scan. Can you show the output of blkid? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTfftpAAoJEI5FoCIzSKrwdFMIAJNAizwNfrYGGL82vgwtegDX VVceKvLlKF1YY3w9QsKLTTvoLlemvkwgEhX53xLWVj5hvm0AL6lAY+mThs4eLJ6G 6DH7rFgT2TqZ0HALOh6ND8dNKrwigB+fWZTOaJEB8aqTrTMtUmtxKi5Kjm8Wps9Q /wlVlcTzg4R0yDNtcDI8s1Xp0cP0JiUURFVQ9NaPptAL8Dp56/BdS10Lq/iebeJJ MwADd9Zi4qDPOGYBVmlMwtR1W6rG6VJJi7De44TyhDC4tmz4iakeU3C2Dcf4Mkfj 5GWUNYpaEHOsMq9gvwYn/zYVTWNnO9ZUXsI0XN0jlyLNaOWuyp+cnbWGRBShHn4= =XzFw -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#693971: (no subject)
On Thu, May 22, 2014 at 03:15:30PM +0200, Samuel Thibault wrote: Hello, We were not aware of this bug report. Jelmer Vernooij, le Sun 20 Apr 2014 22:03:03 +0200, a écrit : As far as I can tell, file locking is a necessary feature. Is there any bug against the hurd about file locking that we could make this bug block on? The Hurd does have some file locking, just not record file locking yet (patch is pending review/polishing). So only coarse file-level locking is supported for now. Is there a bug in Debian I can follow to track this work, or can we file one? Cheers, Jelmer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
