Bug#755570: voms-doc: not installable in sid (dependency on voms-dev too tight?)
Package: voms-doc Version: 2.0.11-2 Severity: serious User: trei...@debian.org Usertags: edos-outdated Hi, voms-doc is not installable in sid since it depends on voms-dev (= 2.0.11-2). However, the version of voms-dev available in sid is 2.0.11-2+b1. This is obviously a consequence of an arch=all package not being rebuild by a bin-NMU. Maybe the versioned dependency on vom-dev could be loosend a bit. Cheers -Ralf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755571: nmu: tulip_4.5.0dfsg-2+b2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu tulip_4.5.0dfsg-2+b2 . ALL . -m rebuild against binutils 2.24.51.20140709-1 tulip still depends on binutils ( 2.24.51.20140618) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) 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/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755572: gnustep-make: Broken framework versioning support
Package: gnustep-make Version: 2.6.2-2 Severity: serious Forwarded: http://savannah.gnu.org/bugs/index.php?42778 It turns out that gnustep-make does not support versioned frameworks which makes library transitions of frameworks nearly impossible. Slightly embarrassing to discover this after so many years. -- System Information: Debian Release: 7.6 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=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnustep-make depends on: ii autotools-dev 20120608.1 ii gnustep-common [gnustep-fslayout-fhs] 2.6.2-2 ii gobjc 4:4.7.2-1 gnustep-make recommends no packages. Versions of packages gnustep-make suggests: ii gnustep-base-common 1.22.1-4 ii gnustep-make-doc 2.6.2-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755573: tt-rss: New upstream release (1.13) available
Package: tt-rss Version: 1.12+dfsg-2 Severity: wishlist Dear Maintainer, A new upstream tt-rss release (1.13) is available, please consider packaging it. Thanks, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755528: moc not working: FATAL_ERROR: Can't receive value from the
severity 755528 normal thanks * Michael Hatzold m.hatz...@web.de [2014-07-21 21:40 +0200]: Package: moc Version: 1:2.5.0~beta2-1+b1 Severity: serious Justification: unusuable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? What I did today was: Open moc (mocp) trying to play a *.mp4, but my mp4_s weren't shown (as they use to be). But I could play mp3_s. I noticed moc-ffmpeg-plugin was missing and installed it - *.mp4 files were shown but there was an error, something like ..couldn't initiate sent() on server or the like. I reinstalled moc and moc-ffmpeg-plugin and rebooted. *.mp4 files still shown, but now a different error, no matter what files (mp3 or mp4) I try to play: FATAL_ERROR: Can't receive value from the server! Neither deleteing ~/.moc or rm -rf ~/.moc/cache nor --reinstall does solve the problem. Currently moc is unusuable here. It seems that libav is somewhat defect. I came up with a similar behavior. Moving all mp4's out of the directory let me play the others very well. Could you please try to play a mp4 via avplay? Does it produce sound? If not (a segfault?) we have to reassign this bug to the libbavcodec55 package. Elimar -- Do you smell something burning or is it me? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755565: quodlibet: Crashes when notification tray is opened in gnome-shell 3.12
As you have figured out correctly the problem is that GS requests QL to show a 1x1px tray icon which triggers a bug. I've fixed this yesterday [0] [1], but even with the fix applied, the icon doesn't show since it's 1x1px big. Most other applications hardcode the icons size, which is why they still work. You can install the TopIcons [2] extension as a workaround for now; it correctly notifies QL of the right size (which is also why I didn't notice this problem earlier..) [0] https://code.google.com/p/quodlibet/source/detail?r=2f6588e31143a4 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701607#15 [2] https://extensions.gnome.org/extension/495/topicons/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755574: nmu: ggcov_0.9-6+b1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu ggcov_0.9-6+b1 . ALL . -m rebuild against binutils 2.24.51.20140709-1 ggcov still depends on binutils ( 2.24.51.20140618) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) 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/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754583: ABI=4
Resurrecting an old thread. On Thu, Jun 19, 2014 at 9:09 AM, DCMTK Team b...@dcmtk.org wrote: Hi Mathieu, I did upload your latest snapshot to debian we'll see how it goes: https://ftp-master.debian.org/new/dcmtk_3.6.1~20140617-1.html thank you! SOVERSION was set to value of 4, while no official release ever did set the value to 3 (dcmtk 3.6.0 was set with a SOVERSION of 2). Was it intended ? Yes, it was intended and, actually, version 3 was used for the previous snapshot. We decided to increase the SOVERSION for each snapshot _and_ release, because DCMTK snapshots are some kind of small releases :) The problem is that we cannot guarantee ABI compatibility between snapshots and some users (even companies) use the snapshot versions for their programs/products since they are pretty stable... Actually there is still an issue. You've bump the SOVERSION without changing the VERSION. Which is illegal AFAIK: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754583 It is non-conventional to change the SOVERSION when the VERSION does not change. Please update VERSION to 3.6.2 (or anything different from 3.6.1). Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755575: nmu: anjuta-extras_3.10.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu anjuta-extras_3.10.0-1 . ALL . -m rebuild against anjuta 2:3.12.0-1 anjuta-extras still depends on anjuta ( 2:3.11) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) 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/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748614: [pkg-kolab] Bug#748614: [libkolabxml0] looses information about birthdays
Hi,
just updated to the newest libkolab* (thanks for the upload) and restarted the
system. Then I've created a new contact in kaddressbook and compared the data
stored in akonadi and the one stored in the serialized mail. The dates (here
bday) are still missing
It may still be missing the kdepim update which has to be tested after the
upload was done. But I am not sure if it is really related to the frontend.
akonadi-data (from akonadiconsole):
BEGIN:VCARD
BDAY:2014-07-24
FN:asdasd
N:asdasd
UID:{f45228a7-71dd-4c6a-b7e4-b5cd5d5eeeaa}
VERSION:3.0
END:VCARD
serialized mail (kolab.xml):
vcard
uid
uriurn:uuid:{f45228a7-71dd-4c6a-b7e4-b5cd5d5eeeaa}/uri
/uid
x-kolab-version
text3.1.0/text
/x-kolab-version
prodid
textAkonadi-KolabResource Libkolab-0.5.2 Libkolabxml-1.0.1/text
/prodid
rev
timestamp20140722T064231Z/timestamp
/rev
kind
textindividual/text
/kind
fn
textasdasd/text
/fn
n
surnameasdasd/surname
given/
additional/
prefix/
suffix/
/n
/vcard
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755563: libvirt: FTBFS on i386: test failure
On Tue, Jul 22, 2014 at 04:09:32AM +0200, Cyril Brulebois wrote: your package no longer builds on i386 due to some test failures: | FAIL: test-ffs | FAIL: test-ffsl This was reported as part of #753121 and then #754548, now fixed. I see the build used an old version of gcc-4.9. Please could you give it back? It should work now. -- Colin Watson [cjwat...@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#748967: Strange wording
The man page reads like this: USENETWORK=no Specify yes when you do not want to disable network access during build. There appears to be some inverted logic going on. Can you clarify, if yes is the right value to disable network, or if a NO is missing in the name. Best regards, Kay Hayen
Bug#755575: nmu: anjuta-extras_3.10.0-1
Control: reassign -1 anjuta-extras Control: retitle -1 anjuta-extras: uninstallable with anjuta 3.12 Control: severity -1 serious On 22/07/14 08:57, Ralf Treinen wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu anjuta-extras_3.10.0-1 . ALL . -m rebuild against anjuta 2:3.12.0-1 anjuta-extras still depends on anjuta ( 2:3.11) A binnmu is not going to help. This needs manual changes to debian/control. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710195: [Pkg-libvirt-maintainers] Bug#753121: libvirt: diff for NMU version 1.2.4-3.1
On Wed, Jul 16, 2014 at 08:23:59AM +0200, Guido Günther wrote: On Mon, Jul 14, 2014 at 04:05:07PM +0100, Colin Watson wrote: Since this is blocking the parted transition I'm working on, I've prepared an NMU for libvirt (versioned as 1.2.4-3.1) based on Peter's patch in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753121#38, and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. That's perfectly fine. I've already patched this in git but didn't get around to do an upload yet. Thanks a lot for your help and for following standard procedure for NMUs. Would you mind if I did a follow-up NMU to fix #710195? I know you've already fixed it in git, but I'm going to need to get kfreebsd-* building to unblock parted, and I think it would be a good idea to avoid tangling this with a new upstream version of libvirt if we don't have to. diff -Nru libvirt-1.2.4/debian/changelog libvirt-1.2.4/debian/changelog --- libvirt-1.2.4/debian/changelog 2014-07-14 11:34:06.0 +0100 +++ libvirt-1.2.4/debian/changelog 2014-07-22 08:07:33.0 +0100 @@ -1,3 +1,11 @@ +libvirt (1.2.4-3.2) unstable; urgency=medium + + * Non-maintainer upload. + * Drop build-dep on hal-dev (closes: #710195; backported from experimental +git branch). + + -- Colin Watson cjwat...@debian.org Tue, 22 Jul 2014 08:07:31 +0100 + libvirt (1.2.4-3.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru libvirt-1.2.4/debian/control libvirt-1.2.4/debian/control --- libvirt-1.2.4/debian/control2014-07-14 11:31:30.0 +0100 +++ libvirt-1.2.4/debian/control2014-07-22 08:05:41.0 +0100 @@ -22,7 +22,6 @@ libdevmapper-dev [linux-any], uuid-dev, libudev-dev [linux-any], - libhal-dev [!linux-any], libpciaccess-dev, kmod [linux-any], policykit-1 (= 0.105-4~), Thanks, -- Colin Watson [cjwat...@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#755576: cannot open /etc/julia/juliarc.jl on startup (bug in abspath)
Package: julia Version: 0.2.1+dfsg-3 Severity: serious When invoking julia, it prints the error message below and exits. ERROR: could not open file /tmp//tmp//etc/julia/juliarc.jl in include at boot.jl:238 julia -f starts up OK. Experimenting a little, it seems that the bug is in the abspath function, which is called from load_juliarc in client.jl. julia abspath(/foo) /tmp//foo where /tmp is the CWD. AMD64 architecture, GLIBC version 2.19-7, Linux kernel 3.11-2-amd64. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755555: ifupdown: ifup hangs on boot at LSB starting message (with 'alive' indicator)
Hello, On Mon, 21 Jul 2014 20:34:18 -0400 Daniel Dickinson debian-b...@daniel.thecshore.com wrote: ifup hangs during boot if there are any auto interfaces defined in /etc/network/interfaces (including lo, but even --exclude=lo in the initscript doesn't prevent the hanging if there are any other auto interfaces defined). What do you mean hangs? Could you provide any more details, steps to reproduce, output, anything? There is log output and mounting via rescue and issuing /etc/init.d/networking start does not exhibit the problem (however I do not currently have a jessie rescue only wheezy, which may make the difference). -- Cheers, Andrew signature.asc Description: PGP signature
Bug#646130: Bug#754582: transition: parted
On Mon, Jul 21, 2014 at 12:11:19AM +0200, Emilio Pozuelo Monfort wrote: On 20/07/14 01:29, Colin Watson wrote: May I go ahead and start the transition in unstable? I can wait for the partitionmanager NMU to land if you feel that's necessary, but I don't want to wait too long as I'm going to be travelling for a good chunk of August and would like to get this out of the way before then if possible. Go ahead. Thanks, done. Please could you binNMU everything on https://release.debian.org/transitions/html/auto-parted.html other than: * guymager (alternative dependency already in place so not needed) * libvirt (needs another upload anyway for #710195) * parted (obviously won't help; I think there's a bug in the tracker parameters that I'm failing to see, but it's not important) * partitionmanager (NMU pending, will need i386-only binNMU in a few days) Please do include hurd even though it doesn't show up in red. Thanks, -- Colin Watson [cjwat...@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#755563: libvirt: FTBFS on i386: test failure
On 22/07/14 09:02, Colin Watson wrote: On Tue, Jul 22, 2014 at 04:09:32AM +0200, Cyril Brulebois wrote: your package no longer builds on i386 due to some test failures: | FAIL: test-ffs | FAIL: test-ffsl This was reported as part of #753121 and then #754548, now fixed. I see the build used an old version of gcc-4.9. Please could you give it back? It should work now. Given back. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755577: abduco: should recommend dvtm
Package: abduco Version: 0.1-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 According to the online manual, abduco starts dvtm as default command. Therefore I believe the package should recommend (or at least suggest) that other package. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJTzhDeXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWGFYH/RC9IgDyAliRReCOJKxD+Obe lOBfhFqV2DEKibROWF+Xgk6E3ZyVK6xrWQHeebOQjNlwErbGaJbPytfkh2ZRcSq2 tw0ONFfnO5mxzcTfgaHsSlKL/AePpQdwwX1coFC6o7xqfq2W0RNRhlN3qN63do7E yRN6OkckW/6LRUeznby+d44ucUJU7Tkgik3bVh5gYTJWn4nS5ca3QyTznZRYBihF 8tVoioZTVYBUhYk8HArHx0Y0YNwE8TF5F0DPbRwp6DXzM1rXto6GY8cKfwxECWHh q+S+Gg34A1Q1CEUZnX6tz3VqlE4qxrLFU8h0bUhMk5tDpzu66s2nbuWDA6HhXlw= =cowU -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#754441: GMastermind Relicensing
Hi Riccardo, Even if you're not the original author, if you've made any modifications to the work, you own copyright on them. For example, Linus Torvalds is not the only copyright holder of Linux; the other ~5000 contributors all have copyright on it as well. This is why the kernel can't be upgraded to GPL-3, even if Linus wants to. So, having a statement from you would be helpful. (You are only relicensing *your* contributions) Also, what do you mean by the COPYING is the full GPL v2 or later? Riley On 20/07/14 20:40, Riccardo Mottola wrote: Hi Riley, thanks for inquirying. I am not the original author of GMastermind, thus I cannot relicense it, if you need that explicit statement, you need to ask Marko Riedel. I see you put it in CC, I do not know if that email address is current though. We just got permissions to incorporate GMastermind in GAP. I think the original author licensed it under GPLv2+. The README file is misleading and probably written in haste. Not only the header files explicitely say or later, but also the COPYING is the full GPL v2 or later statement. The README file says to refer to gpl.txt, this is probably inaccurate and COPYING was intended. I would say that the original intentions are pretty clear. Just in the case, I corrected the README file and also updated COPYING to the current GPL v2+ file from fsf, it had even the old FSF address. Perhaps that statement should be removed totally and just COPYING should be included. Riccardo Riley Baird wrote: Hi, I'm currently packaging GMastermind for Debian. In the process, it has been discovered that, according to a technical reading of the README, GMastermind is licensed under GPL-2 only (i.e. without or, at your option, any later version). However, according to the headers on the source files, it would appear that the intention was to license under GPL-2 or any later version. If you are fine with releasing your contributions under GPL-2+, please copy the following statement, fill in your name and send it to the email addresses below. (If not, then please send a message anyway so we know.) - I, YOUR NAME, irrevocably give permission to use, redistribute, modify and to distribute modified copies of any and all of my contributions to the program GMastermind under the terms of the GNU General Public License as published by the Free Software Foundation, either version 2 of the License, or (should anyone choose to do so) any later version. No warranty, not even the implied warranties of merchantability or fitness for a particular purpose, is given by this license grant. --- Please send this statement to the following email addresses: bm-2cvqnduybau5do2dfjtrn7zbaj246s4...@bitmessage.ch 754...@bugs.debian.org pkg-gnustep-maintain...@lists.alioth.debian.org gap-dev-disc...@nongnu.org NOTE: If you don't want to be bothered by licensing issues again, send the following statement in instead. I, YOUR NAME, release my contributions to the program GMastermind into the public domain. This applies worldwide. In some countries, this may not be legally possible; if so: I grant anyone the right to use this my contributions to the program GMastermind for any purpose, without any conditions, unless such conditions are required by law. - Thanks in advance, Riley Baird -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755578: python-vtk: ImportError: invalid mode parameter on mips64el
Package: python-vtk Version: 5.8.0-17.3 On mips64el platform syq@thor python Python 2.7.7 (default, Jun 6 2014, 13:33:55) [GCC 4.9.0] on linux2 Type help, copyright, credits or license for more information. import vtk Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/pymodules/python2.7/vtk/__init__.py, line 41, in module from vtkCommonPython import * ImportError: invalid mode parameter from vtkCommonPython import * Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named vtkCommonPython on AMD64 platform syq@wrath python Python 2.7.7 (default, Jun 3 2014, 16:16:56) [GCC 4.8.3] on linux2 Type help, copyright, credits or license for more information. import vtk syq@wrath python Python 2.7.7 (default, Jun 3 2014, 16:16:56) [GCC 4.8.3] on linux2 Type help, copyright, credits or license for more information. from vtkCommonPython import * Traceback (most recent call last): File stdin, line 1, in module ImportError: No module named vtkCommonPython -- YunQiang Su -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755579: virtuoso-vsp-startpage: Missing install directory
Package: virtuoso-vsp-startpage Version: 6.1.6+dfsg-4 Severity: normal On browser type http://localhost:8890/install/ for install on first time. Result is install directory missing from /var/libvirtuoso-opensource-6.1/vsp/* -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-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 virtuoso-vsp-startpage depends on: ii virtuoso-opensource 6.1.6+dfsg-4 virtuoso-vsp-startpage recommends no packages. virtuoso-vsp-startpage 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#755580: src:glibc: drop libgcc dependency from stage2 builds
Package: src:glibc
Version: 2.19-7
Severity: wishlist
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Even if one manages to build glibc with profiles stage1 or stage2, the
results are not installable due to unmet dependencies. The following
issues occur:
* stage1 libc6-dev Depends on libc6 which is not built in stage1
* stage2 libc6 Depends on libgcc1 which is not built by gcc stage2
This bug shall only cover the second (easier) part and I shall report a
different bug for the first issue at a later time.
When we briefly discussed this issue, there was consensus that substvars
would be the tool to address it. So the attached patch turns those
libgcc dependencies into ${libgcc:Depends} and suppresses them for
stage2. It's a bit unfortunate that dependency information keeps
scattering over control and rules.d/debhelper.mk, but I didn't find a
better way.
Helmut
diff -Nru glibc-2.19/debian/changelog glibc-2.19/debian/changelog
--- glibc-2.19/debian/changelog 2014-07-13 01:31:22.0 +0200
+++ glibc-2.19/debian/changelog 2014-07-20 22:07:19.0 +0200
@@ -1,3 +1,10 @@
+glibc (2.19-7.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Don't emit dependencies on libgcc when building stage2. (Closes: #-1)
+
+ -- Helmut Grohne hel...@subdivi.de Sun, 20 Jul 2014 22:06:57 +0200
+
glibc (2.19-7) unstable; urgency=high
* debian/patches/localedata/unsubmitted-tst-setlocale3-ENV.diff: Apply
diff -Nru glibc-2.19/debian/control.in/libc glibc-2.19/debian/control.in/libc
--- glibc-2.19/debian/control.in/libc 2014-06-27 04:28:51.0 +0200
+++ glibc-2.19/debian/control.in/libc 2014-07-20 22:09:20.0 +0200
@@ -3,7 +3,7 @@
Section: libs
Priority: required
Multi-Arch: same
-Depends: ${shlibs:Depends}, libgcc1 [!hppa !m68k], libgcc2 [m68k], libgcc4
[hppa]
+Depends: ${shlibs:Depends}, ${libgcc:Depends}
Recommends: libc6-i686 [i386], libc0.1-i686 [kfreebsd-i386], libc0.3-i686
[hurd-i386]
Suggests: glibc-doc, debconf | debconf-2.0, locales [!hurd-i386]
Provides: ${locale-compat:Depends}, libc6-sparcv9b [sparc sparc64]
diff -Nru glibc-2.19/debian/rules.d/debhelper.mk
glibc-2.19/debian/rules.d/debhelper.mk
--- glibc-2.19/debian/rules.d/debhelper.mk 2014-07-10 21:49:24.0
+0200
+++ glibc-2.19/debian/rules.d/debhelper.mk 2014-07-20 22:08:45.0
+0200
@@ -180,6 +180,9 @@
# Generate common substvars files.
echo locale:Depends=$(shell perl debian/debver2localesdep.pl
$(LOCALES_DEP_VER)) tmp.substvars
echo locale-compat:Depends=$(shell perl debian/debver2localesdep.pl
$(LOCALES_COMPAT_VER)) tmp.substvars
+ifeq ($(filter stage2,$(DEB_BUILD_PROFILES)),)
+ echo 'libgcc:Depends=libgcc1 [!hppa !m68k], libgcc2 [m68k], libgcc4
[hppa]' tmp.substvars
+endif
for pkg in $(DEB_ARCH_REGULAR_PACKAGES) $(DEB_INDEP_REGULAR_PACKAGES)
$(DEB_UDEB_PACKAGES); do \
cp tmp.substvars debian/$$pkg.substvars; \
Bug#755581: systemd: emergency mode infinite loop after systemd upgrade
Package: systemd Version: 208-6 Severity: normal Hi, after I upgraded systemd today my system became unbootable. I removed the quiet option from the kernel boot options and after waiting a while I can see the following: [ TIME ] Timed out waiting for device dev-mapper-volumegroup/x2dhome.device. [DEPEND] Dependency failed for /home [DEPEND] Dependency failed for Local File Systems. Welcome to emergency mode! After logging in, type journalctl -xb to view system logs, systemctl reboot to reboot, systemctl default to try again to boot boot into default mode. Welcome to emergency mode! After logging in, type journalctl -xb to view system logs, systemctl reboot to reboot, systemctl default to try again to boot boot into default mode. Welcome to emergency mode! After logging in, type journalctl -xb to view system logs, systemctl reboot to reboot, systemctl default to try again to boot boot into default mode. The last message seems to repeat infinitely which is not very helpful. I was able to boot with init=/bin/bash, get network up and install sysvinit-core to get around the problem and now my system boots again. This bugreport serves two purposes. Firstly I'd like to find out why my system became unbootable after upgrading systemd. I see that others ran into related problems with their system becoming unbootable with dmcrypt/luks enabled but I'm not sure whether this is the same problem here. Secondly, it is not very helpful to have the emergency mode message spawn in an (seemingly) infinite loop. I should not have to boot with init=/bin/bash. Instead, the emergency mode should start and allow me to analyze the situation. To solve the first problem, here is my fstab: --%--- # /etc/fstab: static file system information. # # Use 'vol_id --uuid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # file system mount point type options dump pass proc/proc procdefaults0 0 /dev/mapper/volumegroup-root / ext4errors=remount-ro 0 1 # /boot was on /dev/sda3 during installation #UUID=65704be4-677a-48f7-8a4e-259b4d0570c7 /boot ext2defaults 0 2 UUID=ac034ff5-d28a-4ad1-8bac-97d554395e3e /boot ext2defaults 0 2 /dev/mapper/volumegroup-home /home ext4defaults0 2 /dev/mapper/volumegroup-swap noneswapsw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 #/dev/sdb1 /mnt auto defaults,user,dmask=022,fmask=133 0 0 cgroup /sys/fs/cgroup cgroup defaults0 0 tmpfs /tmp tmpfs nodev,nosuid,size=8G 0 0 tmpfs /run tmpfs nodev,nosuid,size=8G 0 0 tmpfs /var/lib/schroot/unpack/ tmpfs nodev,nosuid,size=8G 0 0 #/dev/mmcblk0p1 /media/sdcard auto user,rw,umask=111,dmask=000 0 0 #kirkwood:/mnt/series /media/series nfs nolock 0 0 #kirkwood:/mnt/movies /media/movies nfs nolock 0 0 --%--- The system boots fine with sysvinit. Where is the problem? cheers, josch -- Package-specific info: -- systemd-delta: -- [EXTENDED] /lib/systemd/system/cups.socket - /etc/systemd/system/cups.socket.d/cupsd-listen.conf 1 overridden configuration files found. -- Contents of /var/lib/systemd/deb-systemd-helper-enabled: -- == /var/lib/systemd/deb-systemd-helper-enabled/cups.socket.dsh-also == /etc/systemd/system/sockets.target.wants/cups.socket == /var/lib/systemd/deb-systemd-helper-enabled/virtlockd.socket.dsh-also == /etc/systemd/system/sockets.target.wants/virtlockd.socket == /var/lib/systemd/deb-systemd-helper-enabled/gpsd.socket.dsh-also == /etc/systemd/system/sockets.target.wants/gpsd.socket == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/cups.socket == == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/virtlockd.socket == == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/gpsd.socket == == /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/lvm2-lvmetad.socket == == /var/lib/systemd/deb-systemd-helper-enabled/binfmt-support.service.dsh-also == /etc/systemd/system/multi-user.target.wants/binfmt-support.service == /var/lib/systemd/deb-systemd-helper-enabled/cups.path.dsh-also == /etc/systemd/system/multi-user.target.wants/cups.path == /var/lib/systemd/deb-systemd-helper-enabled/lvm2-activation-early.service.dsh-also == /etc/systemd/system/local-fs.target.wants/lvm2-activation-early.service == /var/lib/systemd/deb-systemd-helper-enabled/rsyslog.service.dsh-also == /etc/systemd/system/multi-user.target.wants/rsyslog.service
Bug#645561: #645561 - nautilus: slow in list view, when using clearlooks
No problem with nautilus 3.12.2-1 (debian testing). I remember nautilus 3.4 (in wheezy) and 3.8 (which was previously in testing) were also clean. regards, Simon On 2014-07-21 19:23, Pedro Beja wrote: Hey, this is an old bug. Could you please still reproduce this issue with newer nautilus version like 3.4.2-1+build1 or 3.8.2-3 ? thanks regards Pedro -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754582: Bug#646130: Bug#754582: transition: parted
On 22/07/14 09:16, Colin Watson wrote: Please could you binNMU everything on https://release.debian.org/transitions/html/auto-parted.html other than: * guymager (alternative dependency already in place so not needed) * libvirt (needs another upload anyway for #710195) * parted (obviously won't help; I think there's a bug in the tracker parameters that I'm failing to see, but it's not important) * partitionmanager (NMU pending, will need i386-only binNMU in a few days) Please do include hurd even though it doesn't show up in red. Done. BTW parted shows up because the old binaries match is_bad. It will go green once it is decrufted. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755582: [nut-server] Cannot Connect to Mustek UPS on USB
Package: nut-server Version: 2.7.2-1 Severity: important --- Please enter the report below this line. --- Using configuration files from previous 32-bit Sid installation which worked, nut-server cannot connect to the Mustek 600 UPS on USB using blazer driver. Package also partially installed -- unconfigured. Removed it to avoid repeated error-notifications. Note that if I start clean, both nut-server and nut-client partially installed -- unconfigured. --- System information. --- Architecture: amd64 Kernel: Linux 3.2.0-4-amd64 Debian Release: jessie/sid 500 unstableftp.us.debian.org 500 testing ftp.us.debian.org 500 sid linux.dropbox.com --- Package information. --- Depends (Version) | Installed =-+-== libc6 (= 2.15) | 2.19-7 libnspr4 (= 2:4.9-2~) | 2:4.10.6-1 OR libnspr4-0d (= 1.8.0.10) | libnss3 (= 2:3.13.4-2~) | 2:3.16.3-1 OR libnss3-1d (= 3.12.0~1.9b1) | 2:3.16.3-1 libupsclient4 (= 2.7.2) | 2.7.2-1 libusb-0.1-4(= 2:0.1.12) | 2:0.1.12-24 libwrap0 (= 7.6-4~) | 7.6.q-25 init-system-helpers(= 1.18~) | 1.19 adduser | 3.113+nmu3 lsb-base (= 3.0-6) | 4.1+Debian13 udev (= 0.124-1) | 204-14 nut-client(= 2.7.2-1) | 2.7.2-1 Package's Recommends field is empty. Suggests (Version) | Installed ===-+-=== nut-cgi | nut-snmp| nut-ipmi| nut-xml | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710195: [Pkg-libvirt-maintainers] Bug#753121: libvirt: diff for NMU version 1.2.4-3.1
On Tue, Jul 22, 2014 at 08:11:00AM +0100, Colin Watson wrote: On Wed, Jul 16, 2014 at 08:23:59AM +0200, Guido Günther wrote: On Mon, Jul 14, 2014 at 04:05:07PM +0100, Colin Watson wrote: Since this is blocking the parted transition I'm working on, I've prepared an NMU for libvirt (versioned as 1.2.4-3.1) based on Peter's patch in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753121#38, and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. That's perfectly fine. I've already patched this in git but didn't get around to do an upload yet. Thanks a lot for your help and for following standard procedure for NMUs. Would you mind if I did a follow-up NMU to fix #710195? I know you've already fixed it in git, but I'm going to need to get kfreebsd-* building to unblock parted, and I think it would be a good idea to avoid tangling this with a new upstream version of libvirt if we don't have to. Sure. Go ahead and thanks for your work on this! -- Guido diff -Nru libvirt-1.2.4/debian/changelog libvirt-1.2.4/debian/changelog --- libvirt-1.2.4/debian/changelog2014-07-14 11:34:06.0 +0100 +++ libvirt-1.2.4/debian/changelog2014-07-22 08:07:33.0 +0100 @@ -1,3 +1,11 @@ +libvirt (1.2.4-3.2) unstable; urgency=medium + + * Non-maintainer upload. + * Drop build-dep on hal-dev (closes: #710195; backported from experimental +git branch). + + -- Colin Watson cjwat...@debian.org Tue, 22 Jul 2014 08:07:31 +0100 + libvirt (1.2.4-3.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru libvirt-1.2.4/debian/control libvirt-1.2.4/debian/control --- libvirt-1.2.4/debian/control 2014-07-14 11:31:30.0 +0100 +++ libvirt-1.2.4/debian/control 2014-07-22 08:05:41.0 +0100 @@ -22,7 +22,6 @@ libdevmapper-dev [linux-any], uuid-dev, libudev-dev [linux-any], - libhal-dev [!linux-any], libpciaccess-dev, kmod [linux-any], policykit-1 (= 0.105-4~), Thanks, -- Colin Watson [cjwat...@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#755581: some further info
Hi, I managed to get some more info on this bug. It seems to indeed be a regression in systemd. I tried the following: wget http://snapshot.debian.org/archive/debian/20140628T163326Z/pool/main/s/systemd/systemd_204-14_amd64.deb wget http://snapshot.debian.org/archive/debian/20140628T163326Z/pool/main/s/systemd/libsystemd-daemon0_204-14_amd64.deb wget http://snapshot.debian.org/archive/debian/20140628T163326Z/pool/main/s/systemd/libsystemd-id128-0_204-14_amd64.deb wget http://snapshot.debian.org/archive/debian/20140628T163326Z/pool/main/s/systemd/libsystemd-journal0_204-14_amd64.deb wget http://snapshot.debian.org/archive/debian/20140628T163326Z/pool/main/s/systemd/libsystemd-login0_204-14_amd64.deb wget http://snapshot.debian.org/archive/debian/20140628T163326Z/pool/main/s/systemd/udev_204-14_amd64.deb wget http://snapshot.debian.org/archive/debian/20140628T163326Z/pool/main/s/systemd/libudev1_204-14_amd64.deb wget http://snapshot.debian.org/archive/debian/20140628T163326Z/pool/main/s/systemd/libudev1_204-14_i386.deb sudo dpkg -i systemd_204-14_amd64.deb libsystemd-daemon0_204-14_amd64.deb \ libsystemd-journal0_204-14_amd64.deb libsystemd-login0_204-14_amd64.deb \ udev_204-14_amd64.deb libudev1_204-14_amd64.deb libudev1_204-14_i386.deb Then I rebooted with init=/lib/systemd/systemd and everything worked. Then I upgraded udev and libudev1 back to 208-6 and rebooted again with init=/lib/systemd/systemd. Things still worked. Then I upgraded libsystemd-daemon0, libsystemd-journal0, libsystemd-login0 and systemd to 208-6 and I got the error I described initially. Hope this helps! 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#755668: virtuoso-server: Missing path on [Plugins] section
Package: virtuoso-server Version: 6.1.6+dfsg-4 Severity: normal On viruoso.ini , from [Plugins] section variable LoadPath is declarated but is not found on system. /etc/virtuoso-opensource-6.1/virtuoso.ini Result: plugins fail to start. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-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 virtuoso-server depends on: ii virtuoso-opensource-6.1 6.1.6+dfsg-4 virtuoso-server recommends no packages. virtuoso-server 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#754285: lxc: /etc/lxc/lxc.conf not removed on upgrade
Le Fri, 18 Jul 2014 09:55:58 +0200, Daniel Baumann daniel.baum...@progress-technologies.net a écrit : On 07/09/2014 04:06 PM, Laurent Bigonville wrote: /etc/lxc/lxc.conf it apparently not shipped in the package but not removed on upgrade. /etc/lxc/lxc.conf was present only in the 0.9.0-* uploads, not before and not afterwards. given that 0.9.0 was in experimental only, and was superseeded by 1.0 in September 2013 (= almost a year ago already) I don't think it makes sense to go through the nuissance of adding a check in preinst to remove that file. Well, looking at the .deb of version 0.9.0~alpha3-2 which has been uploaded to unstable, it definitely contains the /etc/lxc/lxc.conf file. Removing this file on upgrade is probably something like adding the following line in the lxc.maintscript file: rm_conffile /etc/lxc/lxc.conf 1.1.0~alpha1-3~ Cheers, Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749095: (no subject)
tags 749095 -patch severity 749095 wishlist thanks ldb itself doesn't use pthreads, so pthreads must be coming in from elsewhere. This is not the right patch. (I've lowered the severity of this bug, since ldb was never meant to build on the Hurd, it was only ever attempted because tdb was force-uploaded). signature.asc Description: Digital signature
Bug#748967: Strange wording
Kay Hayen dixit: The man page reads like this: USENETWORK=no Specify yes when you do not want to disable network access during build. There appears to be some inverted logic going on. Indeed… Can you clarify, if yes is the right value to disable network, or if a NO is missing in the name. Of course, “yes” is n̲o̲t̲ the right value to disable network. Read the text again: specify “yes” when you do *not* want to disable the network. Default is USENETWORK=no (network disabled). Which reminds me… sorry @ Perl guys… will try to catch some hacking time ASAP. bye, //mirabilos -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour” -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755669: udev: /dev/net/tun missing
Package: udev Version: 208-6 Severity: important udev 208-6 does not create /dev/net/tun. Downgrading to 204-14 solves this. Regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628804: Still present on debian wheezy.
On 2013-05-29 17:39, Nestor A Diaz wrote: Hi, i can confirm the problem is still on debian wheezy [...] The problem is fixed using the 'sid' version of libsnmp-session-perl Having come across this issue on a production system recently, I can confirm that applying the simple patch to the wheezy package resolves this bug. Jochen, would you be prepared to request a stable update for this? If you'd prefer, I'm happy to handle it instead, as I'd really like to reduce the number of local patches we have. :-) Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755563: libvirt: FTBFS on i386: test failure
Colin Watson cjwat...@debian.org (2014-07-22): On Tue, Jul 22, 2014 at 04:09:32AM +0200, Cyril Brulebois wrote: your package no longer builds on i386 due to some test failures: | FAIL: test-ffs | FAIL: test-ffsl This was reported as part of #753121 and then #754548, now fixed. I see the build used an old version of gcc-4.9. Please could you give it back? It should work now. Someone did, but it failed again. Adding i...@buildd.debian.org to the loop. Mraw, KiBi. signature.asc Description: Digital signature
Bug#755670: tracker.debian.org: Far too little contrast between box headers and page background
Package: tracker.debian.org The box headers in the old PTS have a nice dark red background which provides a bright contrast to the page's white background and hence lets the reader immediately recognize where a new section starts and hence find the wanted section very quickly. The new package tracker uses a very light gray on white background which has nearly no contrast. In consider that quite a regression compared to the old PTS and so far it's my primary reason why I still prefer to use the old PTS. So please add some bright or dark color (I don't much care which color) as background and maybe use white text for the box headers again. That would help a lot to easily perceive the new package tracker's pages. An IMHO less optimal but acceptable variant would be to be able to choose some (either given or arbitrary) CSS in the profile settings. TIA. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (400, 'stable'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15-trunk-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747054: FTBFS: package javax.servlet.http does not exist
Package: eclipse Version: 3.8.1-5.1 Followup-For: Bug #747054 Hi Michael and Maintainers, I reproduced the same issue and found it's related to bce8d58 - Regenerated d/eclipse-build-generatedScripts.tar.bz2. Package builds for me after I drop that commit on my jessie/sid mixed system. I do not familar with java related stuff. Just for you info and hopefully it might bring you some clue with such ftbfs. Best regards, -Andrew -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.11-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755671: tracker.debian.org: Merging two accounts results in a 403 Forbidden message
Package: tracker.debian.org Severity: normal Hi, I just tried to merge the two accounts a...@deuxchevaux.org and a...@debian.org. I'm currently logged in as a...@deuxchevaux.org and entered a...@debian.org as additional address. When I open the https://tracker.debian.org/accounts/+merge-accounts/finalize/hash URL in a browser where I'm logged in into the a...@deuxchevaux.org account, I get a 403 Forbidden error message. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752384: HEAnet sourceforge mirror is outdated
On 22/07/14 02:05, Paul Wise wrote: On Tue, Jul 22, 2014 at 2:50 AM, Daniel Lintott wrote: Okay... It took a bit of thinking of how to work it, but I've come up with a working solution that caches the file list for each project requested. There was some discussion on IRC about the problem and a caching proxy was suggested instead: sf rss = rss to html converter = caching proxy = uscan Thinking about it some more, caching the output makes more sense than caching filenames and using a HTTP caching proxy is the usual way to cache HTML/websites so it might be best to just do that. Thoughts? I would say that seems like a sensible suggestion. Using a ready-made system for the caching obviously has major benefits of being well-established and supported. Personally I've never used or setup such a service, but there are several available: nginx[1]; trafficserver[2]; haproxy[3] [1] https://packages.debian.org/wheezy/nginx [2] https://packages.debian.org/wheezy/trafficserver [3] https://packages.debian.org/wheezy-backports/haproxy I shall drop another version of the patch to the bug report that reverts the custom caching mechanism. Regards Daniel signature.asc Description: OpenPGP digital signature
Bug#728066: #728066 - redshift: New upstream version available
On Tue, Jul 22, 2014 at 12:14:18AM +0100, Jonathan McCrohan wrote: Hi Rhalina/Ritesh, On Wed, Jun 18, 2014 at 01:51:41PM +0100, althaser wrote: Could you please update redshift ? version 1.9.1 is out. Ritesh, could you please push your work to collab-maint [1]? Rhalina, if you do not have time to work on this package, please consider orphaning it. This bug has been open for almost 9 months at this stage. Yes, you are completely right. My original plan was to bring the package to a reasonable state and then do a handover, but I don't think this will work. I'm on vacation this week and will do the orphaning next week I think. Thanks for asking and caring! Bye, Rhalina -- rhalina (Franziska Lichtblau) rhal...@old-forest.org lichtb...@cip.ifi.lmu.de «I refuse to be bound by software I cannot trust and negotiate with.» -- Enrico Zini -- signature.asc Description: Digital signature
Bug#755544: notmuch-emacs: doesn't check gpg/pgp signatures by default
Jameson Graef Rollins jroll...@finestructure.net writes: On Mon, Jul 21 2014, David Bremner da...@tethera.net wrote: notmuch folks: it seems that in vagrant's message, and several others I checked, it notmuch-crypto-process-mime==nil, then no signature button is created at all. Yes, this is true. The signature button is pretty meaningless if we're not processing the signature. Maybe instead by default we could have a signature button that opens up a notmuch-crypto-process-mime customization buffer? jamie. looking at the source, there is supposed to be some button: , | (defun notmuch-show-insert-part-multipart/signed (msg part content-type nth depth button) | (button-put button 'face 'notmuch-crypto-part-header) | ;; add signature status button if sigstatus provided | (if (plist-member part :sigstatus) | (let* ((from (notmuch-show-get-header :From msg)) |(sigstatus (car (plist-get part :sigstatus | (notmuch-crypto-insert-sigstatus-button sigstatus from)) | ;; if we're not adding sigstatus, tell the user how they can get it | (button-put button 'help-echo Set notmuch-crypto-process-mime to process cryptographic MIME parts.)) ` -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755675: a README.Debian would be nice
Package: apt-transport-tor Version: 0.1.1-2 Severity: wishlist Heya, and thanks for apt-transport-tor! Currently, the package documentation seems to reside entirely in its long description. Also, it seems to be out-of-date: it mentions tor://, wherease both the README on GitHub and the latest blog post on the subject [1] mentions tor+http(s). It would be nice to ship proper documentation for this package, where people expect it to find, i.e. /usr/share/doc/apt-transport-tor/README.Debian . And/or including the upstream README from https://github.com/diocles/apt-transport-tor Can you please do that in future uploads? TIA! [1]: http://retout.co.uk/blog/2014/07/21/apt-transport-tor -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') 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) Shell: /bin/sh linked to /bin/dash Versions of packages apt-transport-tor depends on: ii libapt-pkg4.12 1.0.6 ii libc62.19-7 ii libcurl3-gnutls 7.37.0-1+b1 ii libgcc1 1:4.9.0-7 ii libstdc++6 4.9.0-7 ii tor 0.2.4.22-1 apt-transport-tor recommends no packages. apt-transport-tor 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#755576: [Pkg-julia-devel] Bug#755576: cannot open /etc/julia/juliarc.jl on startup (bug in abspath)
Control: tags -1 + confirmed Control: severity -1 grave Hi Eric, Le mardi 22 juillet 2014 à 09:11 +0200, Eric Marsden a écrit : Package: julia Version: 0.2.1+dfsg-3 Severity: serious When invoking julia, it prints the error message below and exits. ERROR: could not open file /tmp//tmp//etc/julia/juliarc.jl in include at boot.jl:238 julia -f starts up OK. Experimenting a little, it seems that the bug is in the abspath function, which is called from load_juliarc in client.jl. julia abspath(/foo) /tmp//foo where /tmp is the CWD. Thanks for reporting this. I can confirm the bug. It is triggered by the upgrade of libpcre3, from version 1:8.31-5 to 1:8.35-2. Downgrading to libpcre3 1:8.31-5 solves the issue. At this stage, I don't know if this is an ABI break in libpcre3 (#755439 looks like a possible candidate), or if it is related to the way Julia internally stores regular expressions in its LLVM bytecode image (sys.ji). -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Bug#755546: gnome-terminal: 3.12.3-1's new tabs/windows don't inherit working path from old one
On 21/07/14 23:44, santi...@debian.org wrote: After upgrading from 3.4.1.1-2 to 3.12.3-1, new terminal tabs or windows open at $HOME instead of the working directory of the terminal where they were opened from. Works for me, using zsh: I can type Ctrl+Shift+N or Ctrl+Shift+T into a Terminal window to get a new window or tab in the same working directory. This feature is also meant to work with bash. Is your shell bash, zsh or something else? Does it (perhaps indirectly) source /etc/profile.d/vte.sh during startup? S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755453: RM: nvidia-graphics-drivers-legacy-96xx -- ROM; deprecated upstream
Control: reopen -1 On Sun, Jul 20, 2014 at 5:13 PM, Vincent Cheng vch...@debian.org wrote: Oh, and please remove the version in experimental as well. Reopening bug because the above isn't done yet. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755439: pcre3: DFA matching behaviour changed, breaking glib2.0 tests
On Mon, 21 Jul 2014 at 10:17:09 +0100, Simon McVittie wrote: The remaining failures seem to be an intentional behaviour change in PCRE. The attached was enough for GLib git master when I tried it yesterday. However, I'm getting an additional test failure now, building against my planned pcre3 NMU (which it looks as though the maintainer might upload now): # random seed: R02S8c9eb61b4add98149bfeeb19d0c7c029 # Start of regex tests ok 1 /regex/properties PASS: regex 1 /regex/properties ok 2 /regex/class PASS: regex 2 /regex/class ok 3 /regex/lookahead PASS: regex 3 /regex/lookahead ok 4 /regex/lookbehind PASS: regex 4 /regex/lookbehind # ERROR:/«PKGBUILDDIR»/./glib/tests/regex.c:1693:test_subpattern: assertion failed: (res) ERROR: regex - missing test plan ERROR: regex - exited with status 134 (terminated by signal 6?) S Index: debian/changelog === --- debian/changelog (revision 42085) +++ debian/changelog (working copy) @@ -13,6 +13,17 @@ * Use the default compiler on sparc, since it's already 4.7. Closes: #751313. + [ Simon McVittie ] + * Adapt for system pcre3/1:8.35 (Closes: #755439): +- a PCRE 8.31 bug in case-insensitivity has been fixed, so do not assert + bug-for-bug compatibility with 8.31 +- named match groups' names cannot start with a digit any more, so + (?P1.) is no longer allowed; do not assert that it is +- turn off a new optimization that would reduce the result set when called + from g_match_all(_full), to preserve existing functionality + * Build-depend on pcre3/1:8.35 so that the new optimization is +known to be turned off in the built binaries + -- Emilio Pozuelo Monfort po...@debian.org Mon, 05 May 2014 11:50:10 +0200 glib2.0 (2.40.0-3) unstable; urgency=medium Index: debian/control.in === --- debian/control.in (revision 42085) +++ debian/control.in (working copy) @@ -12,7 +12,7 @@ gnome-pkg-tools (= 0.11), dpkg-dev (= 1.16.0), libelfg0-dev (= 0.8.12), - libpcre3-dev (= 1:8.31), + libpcre3-dev (= 1:8.35), desktop-file-utils, gtk-doc-tools (= 1.20), libselinux1-dev [linux-any], Index: debian/patches/0001-regex-test-do-not-assert-that-system-PCRE-still-has-.patch === --- debian/patches/0001-regex-test-do-not-assert-that-system-PCRE-still-has-.patch (revision 0) +++ debian/patches/0001-regex-test-do-not-assert-that-system-PCRE-still-has-.patch (working copy) @@ -0,0 +1,36 @@ +From 8f0620d6304f5f2c386285f645b10409aa17e86e Mon Sep 17 00:00:00 2001 +From: Simon McVittie simon.mcvit...@collabora.co.uk +Date: Sun, 20 Jul 2014 19:33:59 +0100 +Subject: [PATCH 1/3] regex test: do not assert that system PCRE still has an + 8.31 bug + +This was fixed in 8.32. + +Bug: https://bugzilla.gnome.org/show_bug.cgi?id=733325 +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755439 +Forwarded: yes +--- + glib/tests/regex.c | 6 +- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/glib/tests/regex.c b/glib/tests/regex.c +index 833e585..95b2360 100644 +--- a/glib/tests/regex.c b/glib/tests/regex.c +@@ -2446,8 +2446,12 @@ main (int argc, char *argv[]) + /* Test that othercasing in our pcre/glib integration is bug-for-bug compatible +* with pcre's internal tables. Bug #678273 */ + TEST_MATCH([DŽ], G_REGEX_CASELESS, 0, DŽ, -1, 0, 0, TRUE); +- TEST_MATCH([DŽ], G_REGEX_CASELESS, 0, Dž, -1, 0, 0, FALSE); + TEST_MATCH([DŽ], G_REGEX_CASELESS, 0, dž, -1, 0, 0, TRUE); ++#ifndef USE_SYSTEM_PCRE ++ /* This is a bug, which was fixed in 8.32. A system pcre might ++ * be that version or newer, so we cannot assert that it has this bug. */ ++ TEST_MATCH([DŽ], G_REGEX_CASELESS, 0, Dž, -1, 0, 0, FALSE); ++#endif + + /* TEST_MATCH_NEXT#(pattern, string, string_len, start_position, ...) */ + TEST_MATCH_NEXT0(a, x, -1, 0); +-- +2.0.1 + Index: debian/patches/0002-regex-test-do-not-assert-that-system-PCRE-allows-P-1.patch === --- debian/patches/0002-regex-test-do-not-assert-that-system-PCRE-allows-P-1.patch (revision 0) +++ debian/patches/0002-regex-test-do-not-assert-that-system-PCRE-allows-P-1.patch (working copy) @@ -0,0 +1,34 @@ +From 666aeffde7809927741fdf42bab611e4e73117af Mon Sep 17 00:00:00 2001 +From: Simon McVittie simon.mcvit...@collabora.co.uk +Date: Sun, 20 Jul 2014 19:34:54 +0100 +Subject: [PATCH 2/3] regex test: do not assert that system PCRE allows + (?P1) + +Perl = 5.18, and PCRE = 8.34, disallow this. + +Bug: https://bugzilla.gnome.org/show_bug.cgi?id=733325 +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755439 +Forwarded: yes +--- + glib/tests/regex.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git
Bug#755676: general: Intermittent failure to mount partition [after hibernate?] with message Transport endpoint is not connected
Package: general Severity: important Dear Maintainer, I have set up my sister's PC, which was running Windows XP, with RoboLinux, a derivative of Debian Wheezy **@robolinux:~$ cat /etc/*release PRETTY_NAME=Debian GNU/Linux 7 (wheezy) NAME=Debian GNU/Linux VERSION_ID=7 VERSION=7 (wheezy) The /dev/sda2, NTSF formatted partition, is shared between RoboLinux, Windows XP and Windows XP virtualised in VirtualBox. /etc/fstab shows : -- **@robolinux:~$ cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # file system mount point type options dump pass # / was on /dev/sda5 during installation UUID=16b91710-2e23-422e-b09a-aaf8d1ab75cb / ext4errors =remount-ro 0 1 # /home was on /dev/sda7 during installation UUID=d994a183-c3d9-4779-83a3-c058dcbc3d03 /home ext4defaults 0 2 # /var was on /dev/sda8 during installation UUID=6796e893-de2c-4878-93a4-343f2e643ea7 /varext4defaults 0 2 # swap was on /dev/sda6 during installation UUID=86f89ed8-9c45-4837-957d-d358621dc55a noneswapsw 0 0 ## Data partition as mounted after booting the system # /dev/sda2 on /media/Data type fuseblk (rw,nosuid,nodev,relatime,uid=1000,gid=1000,defaults,allow_other,blksize=4096) # /dev/sda2: LABEL=Data UUID=161C2A371C2A11F3 TYPE=ntfs as listed by blkid UUID=161C2A371C2A11F3 /media/Data ntfs-3g auto,user,rw,relatime,uid=1000,gid=1000,defaults,allow_other 0 2 /dev/sr0/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 none /proc/bus/usb usbfs devgid=117,devmode=664 0 0 **@robolinux:~$ While working in RoboLinux, intermittently, there is no access to this partition where all data is stored including the profiles for Thunderbird. So far this has only been able to recover from by a full reboot. So far I have found information about this using Google search but only in relation to other distributions and of very uncertain usefulness. If the problem has been reported previously to Debian then please add this to the bug report, else I would appreciate this being listed as a bug. Regards, Paul -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-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_US, LC_CTYPE=en_US (charmap=ISO-8859-1) 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#755533: debian-installer: Use GeoIP support in installer
Hi, On Dienstag, 22. Juli 2014, Cyril Brulebois wrote: I don't think we're going to set up networking without asking, let alone contacting some service on the internets to figure out what country the user might be in. I completly agree, d-i should not do this by default. That said, I do think it would be cool + user-friendly to be able to use (alternative) Debian installation media which does that. But this (having media behaving *this* differently) opens another can of worms... So, maybe this is better left to a Debian blend. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#704634: gufw: upstream has released gufw 13.04 please package it.
14.04.2 is available already, it's in Ubuntu Trusty now.
Bug#755415: RFA: gexiv2 -- GObject-based wrapper around the Exiv2 library
Hi, Luca Package: wnpp Severity: normal I request an adopter for gexiv2 source package. Upstream is very responsive, and the software is well maintained. I'm interested in this package, and I'm familiar with packaging and GTK development. I've used Debian more than one year, just want do some contribution, :) Sincerely Yours, Bin Li (李彬) http://www.bjgug.org/
Bug#647439: python3-whoosh
On Sun, May 18, 2014 at 02:40:51PM +0400, Dmitry Shachnev wrote: Any update on this bug? The upstream supports Python 3 for a while, and all blocking bugs seem to be fixed as well. ---end quoted text--- Thanks to Zygmunt Krynicki, this has been fixed committed to git: ssh://anonscm.debian.org/git/collab-maint/python-whoosh.git or: git://anonscm.debian.org/collab-maint/python-whoosh.git This adds a new package (python3-whoosh), so since I am not a DD, I cannot upload it. I hope a DD would sponsor this upload. -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Bug#755439: pcre3: DFA matching behaviour changed, breaking glib2.0 tests
On 22/07/14 10:56, Simon McVittie wrote: The attached was enough for GLib git master when I tried it yesterday. However, I'm getting an additional test failure now [...] # ERROR:/«PKGBUILDDIR»/./glib/tests/regex.c:1693:test_subpattern: assertion failed: (res) This is because my patch involving PCRE_NO_AUTO_POSSESS is incorrect. See the upstream GLib bug. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754372: Bug#755084: npapi-sdk: Low version number makes switching from iceweasel-dev difficult
2014-07-18 1:32 GMT+02:00 Gabriele Giacone 1o5g4...@gmail.com: An alternative came to mind, how about removing version check and adding an AC_whatever check? No idea about what changes mozilla-plugin version 8 (version 2, in openvrml case) introduced. On Thu, Jul 17, 2014 at 08:03:25PM +0200, Matthias Klumpp wrote: That patch looks good to me, I could even apply it upstream. Is npapi-sdk a Debian-specific thing, or is it something other distributions will use as well soon? I also wonder if patching all downstream projects is the right way to solve this issue, but I don't know much about NPAPI (if 0.27 is the real API version number, then patching them is the right thing to do - otherwise for real compatibility with stuff that depended on mozilla-plugin, having a higher version number there would help) See [0]. I packaged Gentoo maintainers' work [1] plus cherry-picked few further changes. [0] https://wiki.mozilla.org/NPAPI [1] https://bitbucket.org/mgorny/npapi-sdk AFAICS 0.27 never changed since initial import, nor on firefox tree [2]. If Gentoo upstream was more active, they would probably bump micro version from .2 to .2+n, n is number of changes I cherry-picked. Not sure that would be really needed. [2] https://hg.mozilla.org/mozilla-central/file/75db55f6fd2c/dom/plugins/base/npapi.h#l57 At the moment in npapi-sdk-dev, mozilla-plugin.pc is just a link to npapi-sdk.pc, broken by versioned dependencies as you pointed out. Making it ship its own mozilla-plugin.pc with a higher version, yes would fix versioned deps too. IMHO patching upstream is better, just requiring more work. Anyway, it looks like both mozilla and chromium are phasing NPAPI out. Yes - I don't think the plugins will have a future, but so far we want to support them :-) The change which introduced the = 8 dependency was NP_GetMIMEDescription geturning a const char* instead of char* apparently. I'll adjust PK to accept the lower npapi versions. Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755677: aptitude: Recognizes Debian Backports packages as official for downloading changelogs on the CLI, but not in the TUI
Package: aptitude
Version: 0.6.11-1
Control: found -1 0.6.8.2-1
Hi,
I actually ran into the following on Debian Wheezy, but then also was
able to reproduce this in Sid:
If I try to download and view the changelog of a package from an
official Debian Backports repository
(e.g.
http://metadata.ftp-master.debian.org/changelogs/main/r/redmine/wheezy-backports_changelog,
the repository's release identification is
release v=,o=Debian Backports,a=wheezy-backports,n=wheezy-backports,l=Debian
Backports,c=main)
in the NCurses TUI by pressing Shift-C, aptitude currently claims, it's
not an official package: You can only view changelogs of official
Debian packages.
And yes, there is a related fix in Sid (https://bugs.debian.org/714619),
but only in one place out of two as it seems: only for the command line
interface. And indeed, if I do the same from the command line on Sid,
it works as expected, at least in Sid: aptitude changelog
redmine=2.5.1-2\~bpo70+2 works fine.
There seems to be some kind of code duplication. The according code
locations are:
~/aptitude/aptitude → git grep -3n in_debian
src/cmdline/cmdline_changelog.cc-333- {
src/cmdline/cmdline_changelog.cc-334- // Move this to a central
location and just display an
src/cmdline/cmdline_changelog.cc-335- // apt error?
src/cmdline/cmdline_changelog.cc:336: bool in_debian=false;
src/cmdline/cmdline_changelog.cc-337-
src/cmdline/cmdline_changelog.cc-338- for(pkgCache::VerFileIterator
vf=ver.FileList();
src/cmdline/cmdline_changelog.cc:339: !vf.end() !in_debian;
++vf)
src/cmdline/cmdline_changelog.cc-340- if(!vf.File().end()
vf.File().Origin()!=NULL
src/cmdline/cmdline_changelog.cc-341-
(strcmp(vf.File().Origin(), Debian)==0 ||
src/cmdline/cmdline_changelog.cc-342-
strcmp(vf.File().Origin(), Debian Backports)==0))
src/cmdline/cmdline_changelog.cc:343: in_debian=true;
src/cmdline/cmdline_changelog.cc-344-
src/cmdline/cmdline_changelog.cc:345: if(!in_debian)
src/cmdline/cmdline_changelog.cc-346- {
src/cmdline/cmdline_changelog.cc-347- _error-Error(_(%s is
not an official Debian package, cannot display its changelog.), input.c_str());
src/cmdline/cmdline_changelog.cc-348- continue;
--
src/view_changelog.cc-385-
src/view_changelog.cc-386-void view_changelog(pkgCache::VerIterator ver)
src/view_changelog.cc-387-{
src/view_changelog.cc:388: bool in_debian=false;
src/view_changelog.cc-389-
src/view_changelog.cc-390- string pkgname = ver.ParentPkg().Name();
src/view_changelog.cc-391-
--
src/view_changelog.cc-405-
src/view_changelog.cc-406- // TODO: add a configurable association between
origins and changelog URLs.
src/view_changelog.cc-407- for(pkgCache::VerFileIterator vf=ver.FileList();
src/view_changelog.cc:408: !vf.end() !in_debian; ++vf)
src/view_changelog.cc-409-if(!vf.File().end() vf.File().Origin()!=NULL
src/view_changelog.cc-410- strcmp(vf.File().Origin(), Debian)==0)
src/view_changelog.cc:411: in_debian=true;
src/view_changelog.cc-412-
src/view_changelog.cc:413: if(!in_debian)
src/view_changelog.cc-414-{
src/view_changelog.cc-415- show_message(_(You can only view changelogs of
official Debian packages.),
src/view_changelog.cc-416- NULL, cw::get_style(Error));
src/cmdline/cmdline_changelog.cc:341 ff. is already fixed,
src/view_changelog.cc:410 ff. is not.
BTW, you can't blame Manuel or Rhonda for not fixing both places. Code
duplication is evil and leads to such issues. I'm glad that Rhonda
noticed the general issue (#714619) and even wrote a patch, and that
Manuel applied it.
I suspect Rhonda grepped for the error message (as I did in the first
place, too) and since the two error messages differ a lot, we both only
found one place initially.
-- Package-specific info:
Terminal: eterm-color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude
aptitude version information:
aptitude 0.6.11 compiled at Jun 2 2014 09:03:58
Compiler: g++ 4.8.3
Compiled against:
apt version 4.12.0
NCurses version 5.9
libsigc++ version: 2.2.11
Gtk+ support disabled.
Qt support disabled.
Current library versions:
NCurses version: ncurses 5.9.20140712
cwidget version: 0.5.17
Apt version: 4.12.0
aptitude linkage:
linux-vdso.so.1 (0x7fff057ba000)
libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12
(0x7fd6e384c000)
libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5
(0x7fd6e3616000)
libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5
(0x7fd6e33eb000)
libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0
(0x7fd6e31e6000)
libcwidget.so.3 = /usr/lib/x86_64-linux-gnu/libcwidget.so.3
(0x7fd6e2edf000)
libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
(0x7fd6e2c1d000)
Bug#755296: RFA: gtg -- organizer for the GNOME desktop environment
Hi, Luca Package: wnpp Severity: normal I request an adopter for gtg source package. Upstream is quite active in preparing the port to Gtk3, it should be quite easy to maintain. If it's still available, I would like to take care of it.:) Sincerely Yours, Bin Li (李彬) http://www.bjgug.org/
Bug#754987: /etc/init.d/udev: udevadm settle introduces delay
Hi, I'm also getting the delay (Jessie VM) after updating to udev 208-6. (static IP address, allow-hotplug, sysvinit) Temporary workaround: udev_log=err in /etc/udev/udev.conf (and regenerating initramfs) removes the delay for me. Regards Ingmar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755678: kdepim-runtime: /usr/bin/akonadi_kolabproxy_resource missing in package, breaking any setup with kolab integration
Package: kdepim-runtime Version: 4:4.13.1-1 Severity: important Dear Maintainer, After upgrading to the KDE 4.13 packages in experimental, all Akonadi resources based on Kolab silently stopped working. I noticed the problem when trying to add a new IMAP account with Kolab folders. I also noticed that I could neither create new Kolab-based resources nor delete existing ones. Akonadi gave me the following error message: Agent instance with identifier akonadi_kolabproxy_resource does not exist Comparing packages showed that akonadi_kolabproxy_resource was missing without any notes in the changelog. akonadi_kolabproxy_resource is still present in the upstream source. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kdepim-runtime depends on: ii akonadi-server1.12.1-1+b1 ii kde-runtime 4:4.13.1-1 ii kdepimlibs-kio-plugins4:4.13.1-1 ii libakonadi-calendar4 4:4.13.1-1 ii libakonadi-contact4 4:4.13.1-1 ii libakonadi-kabc4 4:4.13.1-1 ii libakonadi-kcal4 4:4.13.1-1 ii libakonadi-kde4 4:4.13.1-1 ii libakonadi-kmime4 4:4.13.1-1 ii libakonadiprotocolinternals1 1.12.1-1+b1 ii libc6 2.19-7 ii libgcc1 1:4.9.1-1 ii libkabc4 4:4.13.1-1 ii libkalarmcal2 4:4.13.1-1 ii libkcal4 4:4.13.1-1 ii libkcalcore4 4:4.13.1-1 ii libkcalutils4 4:4.13.1-1 ii libkcmutils4 4:4.13.3-1 ii libkdecore5 4:4.13.3-1 ii libkdeui5 4:4.13.3-1 ii libkgapi2-2 2.1.1-2 ii libkimap4 4:4.13.1-1 ii libkio5 4:4.13.3-1 ii libkmbox4 4:4.13.1-1 ii libkmime4 4:4.13.1-1 ii libknewstuff3-4 4:4.13.3-1 ii libknotifyconfig4 4:4.13.3-1 ii libkolab0 0.5.2-1 ii libkpimidentities44:4.13.1-1 ii libkpimtextedit4 4:4.13.1-1 ii libkpimutils4 4:4.13.1-1 ii libkresources44:4.13.1-1 ii libkrosscore4 4:4.13.3-1 ii libmailtransport4 4:4.13.1-1 ii libmicroblog4 4:4.13.1-1 ii libqjson0 0.8.1-3 ii libqt4-dbus 4:4.8.6+dfsg-2 ii libqt4-declarative4:4.8.6+dfsg-2 ii libqt4-network4:4.8.6+dfsg-2 ii libqt4-script 4:4.8.6+dfsg-2 ii libqt4-xml4:4.8.6+dfsg-2 ii libqt4-xmlpatterns4:4.8.6+dfsg-2 ii libqtcore44:4.8.6+dfsg-2 ii libqtgui4 4:4.8.6+dfsg-2 ii libsolid4 4:4.13.3-1 ii libstdc++64.9.1-1 kdepim-runtime recommends no packages. kdepim-runtime 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#755246: notmuch-mutt: search that returns whole threads
Stefano Zacchiroli z...@debian.org writes: I guess you could abuse the search term query by adding special search terms such as thread:yes or thread:no to override whatever the default setting is. A little ugly, especially if notmuch ever implements a thread: query type, but fairly easy to implement. I've thought about this as well, but initially ruled out for the reason you describe: the risk of clashes with notmuch. But it just occurred to me that nomtuch upstream is with us here in this thread! :-) David: what do you think? Is there a safe way to embed such an option into a notmuch search string, in a way that it doesn't get in the way of notmuch itself? I'm assuming here that you're going to strip whatever pseudosyntax you use before passing to notmuch, in which case the main thing is to avoid clashes with notmuch-search-terms(7) (which, e.g. already meantions thread: :]). If you can stand the verbosity, then something like NOTMUCH_MUTT_OPTIONS=threaded subject:search that returns whole threads is probably safest. If you are thinking about a hypothetical notmuch compatible syntax for options then I suggest taking the discussion to the upstream mailing list. d -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755679: emacs: compilation-directory-matcher doesn't correspond anymore to Entering directory output of make
Package: emacs Version: 46.0 Severity: normal Dear Maintainer, After an upgrade of make and emacs, the next-error function doesn't work anymore. It is not able to find the file in which the error is. ``` unset LANG; make -C ../.. -j 8 make: Entering directory '/home/bobot/Sources/frama-c' [...] File src/gui/history.ml, line 242, characters 4-10: Error: ... share/Makefile.generic:75: recipe for target 'src/gui/history.cmo' failed make: *** [src/gui/history.cmo] Error 2 make: *** Waiting for unfinished jobs make: Leaving directory '/home/bobot/Sources/frama-c' Compilation exited abnormally with code 2 at Tue Jul 22 10:30:11 ``` Normally emacs looks for Entering directory in the make output. However the output of make doesn't use anymore `dir' but 'dir' for quoting the directories. So the regexp in compilation-directory-matcher which is (\\(?:Entering\\|Leavin\\(g\\)\\) directory `\\(.+\\)'$ (2 . 1)) can't find the directories. The developers of make changed the Entering directory output in version 4.0: - bug report make (ab)uses the ASCII grave accent (0x60) as a left single quotation mark http://savannah.gnu.org/bugs/?34530 - http://git.savannah.gnu.org/cgit/make.git/commit/?id=23c2b99e9d23e726ede9442728272616e66d416f I expect emacs to be able to parse the output of this new version of make. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (700, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15-trunk-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 emacs depends on: ii emacs24 24.3+1-4+b1 emacs recommends no packages. emacs suggests no packages. make version 4.0-8 0 -- 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#755678: kdepim-runtime: /usr/bin/akonadi_kolabproxy_resource missing in package, breaking any setup with kolab integration
On Tuesday 22 July 2014 12:35:46 Jan Binder wrote: After upgrading to the KDE 4.13 packages in experimental, all Akonadi resources based on Kolab silently stopped working. This is the main reason why kdepim-runtime is still in experimental. It needs a newer set of libkolab* packages which was just now uploaded to the archive. So, it is known, will be fixed - and welcome to experimental. /Sune -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755578: Wrong vtk package
Control: reassign -1 python-vtk6 Control: severity -1 grave No way the log from OP applies to vtk5.8 (vtkCommonCore is vtk6 only). Reassigning to vtk6 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691099: iceweasel: resolves symlinks for local files and breaks relative links
Thank you so so much for that LD_PRELOAD workaround. I’m using Firefox, and the ‘symlinks-breakage’ was really annoying (also using git annex here). It seems this issue is tracked upstream in: https://bugzilla.mozilla.org/show_bug.cgi?id=803999 Best regards, T. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755533: debian-installer: Use GeoIP support in installer
On 22 July 2014 02:35, Cyril Brulebois k...@debian.org wrote: Patrick Häcker pa...@web.de (2014-07-21): Package: debian-installer Severity: wishlist Tags: d-i l10n Dear Maintainer, it would be nice, if Debian installer would support GeoIP to use default values where appropriate. See http://henrich-on-debian.blogspot.de/2014/07/geoip-support-for-installer-is-really.html for an example. This would probably change the required order of the installer steps. But as a start, it would probably be enough to check if a DHCP enabled network interface is available and use GeoIP only then. Otherwise the normal steps should be executed. Kind regards Patrick I don't think we're going to set up networking without asking, let alone contacting some service on the internets to figure out what country the user might be in. I'm happy to hear what other d-i developers have to say about this though. So in Ubuntu, ubiquity d-i do have geoip support added via tzsetup package. (https://launchpad.net/bugs/229884). They do so by contacting geoip service hosted by Canonical http://geoip.ubuntu.com/lookup , which is run on anonymous basis with no logs collected. (There is also connectivity check (to catch captive portals) geoname predictor services used by ubiquity on similar anonymous terms - http://start.ubuntu.com/connectivity-check and http://geoname-lookup.ubuntu.com/?query=Moskva ) geoip.ubuntu.com/lookup is not open-sourced, but it's just a tiny python script that uses python-geoip package data from geoip-database package. But it looks like there are also further database updates taken from https://www.maxmind.com/en/home . I'll work on open-sourcing that trivial python script. The logic currently is opt-out - e.g. if timezone is not already preseeded, an attempt will be made to query the server for timezone. One can also pre-seed empty server address, and thus disable the lookup. I don't know which servers and/or data fedora installer uses. For debian to do something like this, we'd ideally be hosting our own service somewhere. I don't know if we wish for this to be opt-in or opt-out, or something in-between e.g. If network is already configured, and no timezone has been preseeded, do the auto-check. Or if we should be simply asking the question if one wishes to attempt auto-detection at that point vs choose manually. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755462: same problem on i386
Hi! I get a same build error on i386. -- Preparing to unpack .../nvidia-legacy-304xx-kernel-dkms_304.123-1_i386.deb ... -- Deleting module version: 304.123 completely from the DKMS tree. -- Done. Unpacking nvidia-legacy-304xx-kernel-dkms (304.123-1) over (304.123-1) ... Beállítás: nvidia-legacy-304xx-kernel-dkms (304.123-1) ... Loading new nvidia-legacy-304xx-304.123 DKMS files... Building only for 3.14-1-686-pae Building initial module for 3.14-1-686-pae Error! Bad return status for module build on kernel: 3.14-1-686-pae (i686) Consult /var/lib/dkms/nvidia-legacy-304xx/304.123/build/make.log for more information. -- Thanks Gabor DKMS make.log for nvidia-legacy-304xx-304.123 for kernel 3.14-1-686-pae (i686) 2014. júl. 22., kedd, 12.43.29 CEST make: Entering directory '/var/lib/dkms/nvidia-legacy-304xx/304.123/build' make KBUILD_VERBOSE=1 -C /lib/modules/3.14-1-686-pae/build M=/var/lib/dkms/nvidia-legacy-304xx/304.123/build modules make[1]: Entering directory '/usr/src/linux-headers-3.14-1-686-pae' Makefile:10: *** mixed implicit and normal rules: deprecated syntax make -C /usr/src/linux-headers-3.14-1-686-pae \ KBUILD_SRC=/usr/src/linux-headers-3.14-1-common \ KBUILD_EXTMOD=/var/lib/dkms/nvidia-legacy-304xx/304.123/build -f /usr/src/linux-headers-3.14-1-common/Makefile \ modules test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo 2; \ echo 2 ERROR: Kernel configuration is invalid.; \ echo 2 include/generated/autoconf.h or include/config/auto.conf are missing.;\ echo 2 Run 'make oldconfig make prepare' on kernel src to fix it.; \ echo 2 ; \ /bin/false) mkdir -p /var/lib/dkms/nvidia-legacy-304xx/304.123/build/.tmp_versions ; rm -f /var/lib/dkms/nvidia-legacy-304xx/304.123/build/.tmp_versions/* make -f /usr/src/linux-headers-3.14-1-common/scripts/Makefile.build obj=/var/lib/dkms/nvidia-legacy-304xx/304.123/build /bin/sh /var/lib/dkms/nvidia-legacy-304xx/304.123/build/conftest.sh gcc-4.8 gcc-4.8 x86 /lib/modules/3.14-1-686-pae/build /lib/modules/3.14-1-686-pae/build compile_tests remap_page_range remap_pfn_range vmap agp_backend_acquire set_pages_uc set_memory_uc set_memory_array_uc change_page_attr i2c_adapter pci_get_class pm_message_t irq_handler_t pci_choose_state vm_insert_page acpi_device_ops acpi_op_remove acpi_device_id acquire_console_sem console_lock kmem_cache_create on_each_cpu smp_call_function vmm_support acpi_evaluate_integer ioremap_cache ioremap_wc proc_dir_entry INIT_WORK acpi_walk_namespace agp_memory scatterlist pci_domain_nr pci_dma_mapping_error file_operations sg_init_table pci_get_domain_bus_and_slot get_num_physpages efi_enabled proc_create_data pde_data proc_remove pm_vt_switch_required echo \#define NV_COMPILER \` gcc-4.8 -v 21 | tail -n 1`\ /var/lib/dkms/nvidia-legacy-304xx/304.123/build/nv_compiler.h gcc-4.8 -Wp,-MD,/var/lib/dkms/nvidia-legacy-304xx/304.123/build/.nv.o.d -nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.8/include -I/usr/src/linux-headers-3.14-1-common/arch/x86/include -Iarch/x86/include/generated -I/usr/src/linux-headers-3.14-1-common/include -Iinclude -I/usr/src/linux-headers-3.14-1-common/arch/x86/include/uapi -Iarch/x86/include/generated/uapi -I/usr/src/linux-headers-3.14-1-common/include/uapi -Iinclude/generated/uapi -include /usr/src/linux-headers-3.14-1-common/include/linux/kconfig.h -I/var/lib/dkms/nvidia-legacy-304xx/304.123/build -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m32 -msoft-float -mregparm=3 -freg-struct-return -mno-mmx -mno-sse -fno-pic -mpreferred-stack-boundary=2 -march=i686 -mtune=generic -maccumulate-outgoing-args -Wa,-mtune=generic32 -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -DCC_HAVE_ASM_GOTO -I/var/lib/dkms/nvidia-legacy-304xx/304.123/build -Wall -MD -Wsign-compare -Wno-cast-qual -Wno-error -D__KERNEL__ -DMODULE -DNVRM -DNV_VERSION_STRING=\304.123\ -Wno-unused-function -Wuninitialized -UDEBUG -U_DEBUG -DNDEBUG -DMODULE -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(nv) -DKBUILD_MODNAME=KBUILD_STR(nvidia) -c -o /var/lib/dkms/nvidia-legacy-304xx/304.123/build/.tmp_nv.o /var/lib/dkms/nvidia-legacy-304xx/304.123/build/nv.c In file included from /usr/src/linux-headers-3.14-1-common/arch/x86/include/asm/bitops.h:506:0, from
Bug#746361: Update on upstream bug
c0ffee 2014-07-20 07:13:53 UTC (In reply to Tejun Heo from comment #1) libata is not getting the parameter at all. Your initrd probably doesn't automatically parse the kernel command line to extract module params. Please consult with your distro on how to specify module params for modules loaded from initrd. If you can build your kernel with libata built-in, this'd be easy to verify. I'm closing the bug as INVALID for now. Thanks. libata.force=2:disable didn't affect slow boot times in my case, but libata.force=rstonce shortened delay from +60 seconds to +8 seconds. I think it proves that initrd parses kernel command line to extract module params, and at least libata.force=rstonce affects system.
Bug#755212: transition: protobuf-c
Robert Edmonds edmo...@debian.org writes:
The various riemann-c-client headers in /usr/include/riemann include
proto/riemann.pb-c.h, and there's syslog-ng-mod-riemann (from
syslog-ng-incubator) that uses the library, thus, the generated header
too, transitively.
Ah, right. From a brief look at the source code for that module it
looks like it doesn't require a (bin-)NMU at all, if I'm understanding
the libriemann-client API correctly.
Yep, I agree. syslog-ng-incubator should not need a bin-NMU, as it uses
everything through the libriemann-client API, and never touches the
protobuf structures directly.
I would recommend that the upstream developers ship a .proto file
instead.
I'd rather not ship a .proto file, if at all possible. I'll see if I can
hide it completely.
This would eliminate the problem, too.
It looks like you typedef the structures generated by protoc-c and wrap
them in your own API, e.g. from riemann/query.h:
#include riemann/proto/riemann.pb-c.h
typedef Query riemann_query_t;
riemann_query_t *riemann_query_new (const char *string);
void riemann_query_free (riemann_query_t *query);
int riemann_query_set_string (riemann_query_t *query, const char *string);
(Query is from typedef struct _Query Query in riemann.pb-c.h.)
If your API callers always use the *_new(), *_free(), etc. functions and
never try to dereference or calculate sizeof() on the wrapped struct's
it might be possible to remove the #include of the .pb-c.h file and
change your typedef to, e.g.:
typedef struct _Query riemann_query_t;
And then have riemann_query_t be an opaque type. Though this depends
on protoc-c continuing to generate structure tags with leading
underscores, which may not always be the case. (I've wanted to get rid
of the leading underscores for a while now.)
(Similiarly for the other riemann_*_t types that wrap protoc-c generated
structures.)
It might also be possible to wrap the structure types generated by
protoc-c in your own opaque structure type and expose that wrapper type
via your API. Something like:
typedef struct riemann_query riemann_query_t;
riemann_query_t *riemann_query_new (const char *string);
void riemann_query_free (riemann_query_t *query);
int riemann_query_set_string (riemann_query_t *query, const char *string);
(In riemann/query.h.)
#include proto/riemann.pb-c.h
struct riemann_query {
Query query;
};
/* rest of the implementation... */
(In lib/riemann/query.c.)
That's a bit uglier since you have to update accesses to go via the
wrapper but would provide the maximum amount of insulation between the
libriemann-client API and the underlying structures generated by the
protoc-c code generator.
I gave this some more thought, and there's a problem: while generating
riemann events and similar can be done with opaque types, if I do a
query, then I want to access the results, and to do that with opaque
types would mean I need a lot of getter functions (and an API + ABI
bump). So I'll stick to how it is done today, for the foreseeable
future.
But I'll keep your suggestions in mind in case I end up writing another
library that uses protobuf, I'll hide the protobuf stuff deeper then! :)
--
|8]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755578:
severity 755578 minor thanks Anton -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#250850: myodbc: register to ODBC default to yes?
Hi, I come back to this old bug. Ping? Can we make progress on this? On Mon, Nov 28, 2011 at 12:05:26PM +0100, Lionel Elie Mamane wrote: Steve Langasek wrote: I don't know what ODBC is, I just install and it asks: Do you want MyODBC to be registered as an ODBC driver? With default to No. I think the default should be yes, so it will just work for most users. Unless you have a reason, of course. The reason for this is that handing over control of the driver entries to the package will result in any local changes to the entry in /etc/odbcinst.ini being overwritten. I believe this is a policy violation, so am not willing to enable this by default. The other ODBC drivers packaged in Debian that I tried (PostgreSQL, SQLite) register to ODBC by default or unconditionally. So either this is a policy violation and all other ODBC driver packages are RC-buggy (file bugs then!), or change the default to yes for MyODBC, so that Debian users get an easy and uniform experience. I've started a thread on debian-devel looking for input on this. And? What was the outcome of that? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753184: marked as done (foremost: FTBFS: dpkg-source: error: expected ^--- in line 3 of diff `foremost-1.5.7/debian/patches/fix-lintian-hardening-warnings.patch')
Hi! On Mon, 2014-07-07 at 13:15:12 -0300, Raúl Benencia wrote: On Mon, Jul 07, 2014 at 03:54:08PM +, Debian Bug Tracking System wrote: This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. Guillem, the package has been uploaded to unstable by my usual sponsor. I asked him to upload it a couple of day before you offer yourself to do it. Nevertheless, I'll like to handle the upload to stable with you. Sure. If you know how to proceed, then let's do that now that the version has been in unstable for a while, if you don't know I can then assist with that. I will reopen the bug until the problem is fixed in stable. In theory that should not be needed (but it's fine now), as long as the version information in the BTS is correct, which should mark the stable version as effected (usually can be easily seen in the top right graph). Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755578: Wrong vtk package
Control: reassign -1 python-vtk 5.8.0-17.3 On Tue, Jul 22, 2014 at 1:13 PM, Anton Gladky gl...@debian.org wrote: 2014-07-22 12:52 GMT+02:00 Mathieu Malaterre ma...@debian.org: Control: reassign -1 python-vtk6 Control: severity -1 grave No way the log from OP applies to vtk5.8 (vtkCommonCore is vtk6 only). Reassigning to vtk6 It is about vtkCommonPython which is in python-vtk [1]. Sorry for the noise. Corrected. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755578: Wrong vtk package
2014-07-22 12:52 GMT+02:00 Mathieu Malaterre ma...@debian.org: Control: reassign -1 python-vtk6 Control: severity -1 grave No way the log from OP applies to vtk5.8 (vtkCommonCore is vtk6 only). Reassigning to vtk6 It is about vtkCommonPython which is in python-vtk [1]. [1] https://packages.debian.org/sid/amd64/python-vtk/filelist -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755576: [Pkg-julia-devel] Bug#755576: Bug#755576: cannot open /etc/julia/juliarc.jl on startup (bug in abspath)
Good point. pcre 8.31 is a hard requirement as of now. We should probably file the issue upstream, so that we can use a newer version of pcre. -viral On 22-Jul-2014, at 3:14 pm, Sébastien Villemot sebast...@debian.org wrote: Control: tags -1 + confirmed Control: severity -1 grave Hi Eric, Le mardi 22 juillet 2014 à 09:11 +0200, Eric Marsden a écrit : Package: julia Version: 0.2.1+dfsg-3 Severity: serious When invoking julia, it prints the error message below and exits. ERROR: could not open file /tmp//tmp//etc/julia/juliarc.jl in include at boot.jl:238 julia -f starts up OK. Experimenting a little, it seems that the bug is in the abspath function, which is called from load_juliarc in client.jl. julia abspath(/foo) /tmp//foo where /tmp is the CWD. Thanks for reporting this. I can confirm the bug. It is triggered by the upgrade of libpcre3, from version 1:8.31-5 to 1:8.35-2. Downgrading to libpcre3 1:8.31-5 solves the issue. At this stage, I don't know if this is an ABI break in libpcre3 (#755439 looks like a possible candidate), or if it is related to the way Julia internally stores regular expressions in its LLVM bytecode image (sys.ji). -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594 ___ Pkg-julia-devel mailing list pkg-julia-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-julia-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736258: acpid fails to upgrade on amd64
Yesterday I've got the same problem in my desktop computer at work while apt-get upgrade (I also work with debian testing), but I have some kind of workaround: at first I tried to kill acpid, with no sucess at all, so I've started my system in singleuser mode (no acpid running) and was able to upgrade that package and then the rest of the system
Bug#755581: systemd: emergency mode infinite loop after systemd upgrade
Am 22.07.2014 09:45, schrieb Johannes Schauer: Secondly, it is not very helpful to have the emergency mode message spawn in an (seemingly) infinite loop. I should not have to boot with init=/bin/bash. Instead, the emergency mode should start and allow me to analyze the situation. Samuel filed #755581 which seems to be the same issue about the failing/looping emergency mode. I'd say we track this issue there. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#645561: #645561 - nautilus: slow in list view, when using clearlooks
version: 3.4.2-1+build1 I'm closing this bug now since it seems to be fixed. If you can still reproduce it feel free to reopen and provide more info. thanks Simon, regards Pedro
Bug#755680: RFP: asterisk-chan-dongle -- asterisk's huawei 3g dongle channel driver
Package: wnpp Severity: wishlist * Package name: asterisk-chan-dongle Version : 1.1.r14 * Upstream Author : Dmitry Vagin dmitry2...@yandex.ru, Artem Makhutov ar...@makhutov.org, bg bg_...@mail.ru * URL : https://code.google.com/p/asterisk-chan-dongle/ * License : GPL 2 Programming Lang: C Description : asterisk's huawei 3g dongle channel driver Asterisk chan_dongle channel driver for Huawei UMTS cards Supported features: * Place voice calls and terminate voice calls * Send SMS and receive SMS * Send and receive USSD commands / messages -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755669: udev: /dev/net/tun missing
Am 22.07.2014 10:28, schrieb Stefan Pietsch: Package: udev Version: 208-6 Severity: important udev 208-6 does not create /dev/net/tun. Downgrading to 204-14 solves this. Are you still using sysvinit as init system? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#701607:
The original bug is probably fixed by one of the two commits: https://code.google.com/p/quodlibet/source/detail?r=d3ea2148aebdb66 https://code.google.com/p/quodlibet/source/detail?r=912779f6cdfacb89 @Ben: You can work around the crasher bug by installing the following GS extension which moves tray icons to the top: https://extensions.gnome.org/extension/495/topicons/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755581: systemd: emergency mode infinite loop after systemd upgrade
Am 22.07.2014 09:45, schrieb Johannes Schauer: Package: systemd Version: 208-6 Severity: normal Hi, after I upgraded systemd today my system became unbootable. I removed the quiet option from the kernel boot options and after waiting a while I can see the following: [ TIME ] Timed out waiting for device dev-mapper-volumegroup/x2dhome.device. [DEPEND] Dependency failed for /home [DEPEND] Dependency failed for Local File Systems. Can you enable the debug-shell.service (systemctl enable debug-shell.service). This allows you to login very early during boot on tty9 and inspect the system. Booting with systemd.log_level=debug (on the kernel command line) and the journalctl -alb output would be good first step to diagnose it. Are the devices missing when systemd drops you into the emergency mode? Can you send us the output of the udevadm info output for those devices? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#755681: oasis3: drop useless build dependency on hdf5
Source: oasis3
Version: 3.3.beta.dfsg.1-8
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
While preparing the hdf5-8 transition I noticed that the source package
for oasis3 seems having a useless build dependency on HDF5. I've built
the package woth this build dependency removed and checked with debdiff
that the resulting packages were correct (see below).
$ debdiff ../oasis3_3.3.beta.dfsg.1-8.dsc ../oasis3_3.3.beta.dfsg.1-8.1.dsc
dpkg-source: avertissement: extraction d'un paquet source non signé
(/home/pini/hdf5-transition/oasis3_3.3.beta.dfsg.1-8.dsc)
dpkg-source: avertissement: extraction d'un paquet source non signé
(/home/pini/hdf5-transition/oasis3_3.3.beta.dfsg.1-8.1.dsc)
diff -Nru oasis3-3.3.beta.dfsg.1/debian/changelog
oasis3-3.3.beta.dfsg.1/debian/changelog
- --- oasis3-3.3.beta.dfsg.1/debian/changelog 2012-02-04 18:04:42.0
+0100
+++ oasis3-3.3.beta.dfsg.1/debian/changelog 2014-07-22 11:59:32.0
+0200
@@ -1,3 +1,10 @@
+oasis3 (3.3.beta.dfsg.1-8.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Drop useless hdf5 build dependancy.
+
+ -- Gilles Filippini p...@debian.org Tue, 22 Jul 2014 11:59:18 +0200
+
oasis3 (3.3.beta.dfsg.1-8) unstable; urgency=low
* oasis3 and liboasis3-dev are not Multi=Arch: same.
diff -Nru oasis3-3.3.beta.dfsg.1/debian/control
oasis3-3.3.beta.dfsg.1/debian/control
- --- oasis3-3.3.beta.dfsg.1/debian/control 2012-02-04 18:01:20.0
+0100
+++ oasis3-3.3.beta.dfsg.1/debian/control 2014-07-22 11:59:51.0
+0200
@@ -2,7 +2,7 @@
Section: science
Priority: optional
Maintainer: Alastair McKinstry mckins...@debian.org
- -Build-Depends: mpi-default-dev, debhelper (= 8.1.3~), gfortran,
libhdf5-serial-dev | libhdf5-dev, libnetcdf-dev (= 4.1.2),
libcurl4-gnutls-dev, texlive-latex-base, texlive-latex-extra
+Build-Depends: mpi-default-dev, debhelper (= 8.1.3~), gfortran, libnetcdf-dev
(= 4.1.2), libcurl4-gnutls-dev, texlive-latex-base, texlive-latex-extra
Standards-Version: 3.9.2
Homepage: http://www.prism.enes.org/PAEs/coupling_IO/software_OASIS3.php
$ debdiff ../oasis3_3.3.beta.dfsg.1-8_amd64.changes
../oasis3_3.3.beta.dfsg.1-8.1_amd64.changes
File lists identical (after any substitutions)
Control files of package liboasis3-0d: lines which differ (wdiff format)
-
Version: [-3.3.beta.dfsg.1-8-] {+3.3.beta.dfsg.1-8.1+}
Control files of package liboasis3-dev: lines which differ (wdiff format)
- -
Depends: mpi-default-dev, liboasis3-0d (= [-3.3.beta.dfsg.1-8)-]
{+3.3.beta.dfsg.1-8.1)+}
Version: [-3.3.beta.dfsg.1-8-] {+3.3.beta.dfsg.1-8.1+}
Control files of package oasis3: lines which differ (wdiff format)
- --
Version: [-3.3.beta.dfsg.1-8-] {+3.3.beta.dfsg.1-8.1+}
Control files of package oasis3-examples: lines which differ (wdiff format)
- ---
Depends: oasis3 (= [-3.3.beta.dfsg.1-8),-] {+3.3.beta.dfsg.1-8.1),+} libc6 (=
2.14), libgcc1 (= 1:4.4.0), libgfortran3 (= 4.6), libnetcdff5, libopenmpi1.6
Version: [-3.3.beta.dfsg.1-8-] {+3.3.beta.dfsg.1-8.1+}
Thanks in advance,
_g.
- -- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.14-1-486
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCAAGBQJTzkuVAAoJEO/obGx//s+Dcs8IAIiygM+m6IQe+MA542S8qnXa
KCVm6ZDTJlYLvL2eBqzS4xMJ0Ptn+ehcxkXXzwFbB10RRZZFhZrP6IW0EKqgJ1vP
kDfnVcLP8qHNzCbQODEuY8JTeJwZuSTM0nuVbTPcitdU9031fYHDyLWDz6DcYMdW
wupwxN+cejS6ioI6NkVW6xUGUJVMAqBH6dnc51X9SPapIqGmAUb/e0MCQMGSKV3o
R/Ef61VcbeKyzZpCwD9qca+M3Y0tSPSpkP8bhBFCvUYj3sQIlh8Zon7Agitsja8n
U2iAQziozv4yq29pb4ryDWYn1sRB6I2HdyG2DasuSRV10hFWO7DIGk4SVK/8HY4=
=rjZu
-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#755581: systemd: emergency mode infinite loop after systemd upgrade
Hi, Quoting Michael Biebl (2014-07-22 13:23:13) Am 22.07.2014 09:45, schrieb Johannes Schauer: Secondly, it is not very helpful to have the emergency mode message spawn in an (seemingly) infinite loop. I should not have to boot with init=/bin/bash. Instead, the emergency mode should start and allow me to analyze the situation. Samuel filed #755581 which seems to be the same issue about the failing/looping emergency mode. I'd say we track this issue there. #755581 is the number of this bugreport. Maybe you mis-pasted? I searched again in the bug list but cannot find another bug about looping emergency mode :( In case you meant #755672, then I cannot find the same effect in his bugreport as I reported. From his screenshot it seems that the message about emergency mode starting only appears once and not multiple times. Nevertheless that might still be the same issue because it takes some time until the emergency mode message comes again is about 2 minutes. 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#639129: #639129 - nautilus: chooses wrong default folder after mounting via sftp
bookmarks aren't working here, I have to try with a fresh new account. I won't close it for now. thanks regards Pedro On 22 July 2014 01:03, brian m. carlson sand...@crustytoothpaste.net wrote: On Mon, Jul 21, 2014 at 06:13:16PM +0100, Pedro Beja wrote: Hey Brian, this is an old bug. Could you please still reproduce this issue with newer nautilus version like 3.4.2-1+build1 or 3.8.2-3 ? Using whatever's in sid, clicking on the bookmark now works correctly. Clicking on the network link leads me to the wrong place, though. Nevertheless, you can probably close this, since there is a sane way to do what I want. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Bug#755246: notmuch-mutt: search that returns whole threads
On Tue, Jul 22, 2014 at 07:17:32AM -0300, David Bremner wrote: I'm assuming here that you're going to strip whatever pseudosyntax you use before passing to notmuch, in which case the main thing is to avoid clashes with notmuch-search-terms(7) (which, e.g. already meantions thread: :]). Yes, that's the idea. The main design concerns is hence to avoid stuff that people might legitimately want to put in a regular notmuch query. In fact, I was hoping in some sort of meta-syntax, to piggyback on. For instance, if field:value is something that is always threated specially by notmuch, we can use something like notmuch:threads (vs, say, notmuch:nothreads) and strip it before it hits notmuch. If you've no objection to this, I can implement something like it. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#755462: same problem on i386
Le Tue, 22 Jul 2014 13:04:39 +0200, Gabor Kilvadi gabor.kilv...@gmail.com a écrit : Hi! I get a same build error on i386. Bonjour Same error Make.log: [...] test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo 2; \ echo 2 ERROR: Kernel configuration is invalid.; \ echo 2 include/generated/autoconf.h or include/config/auto.conf are missing.;\ echo 2 Run 'make oldconfig make prepare' on kernel src to fix it.; \ echo 2 ; [...] In file included from /var/lib/dkms/nvidia-legacy-304xx/304.123/build/nv.c:13:0: /var/lib/dkms/nvidia-legacy-304xx/304.123/build/nv-linux.h: At top level: /var/lib/dkms/nvidia-legacy-304xx/304.123/build/nv-linux.h:1313:2: error: #error console lock api unrecognized!. #error console lock api unrecognized!. ^ /usr/src/linux-headers-3.14-1-common/scripts/Makefile.build:308: recipe for target '/var/lib/dkms/nvidia-legacy-304xx/304.123/build/nv.o' failed make[4]: *** [/var/lib/dkms/nvidia-legacy-304xx/304.123/build/nv.o] Error 1 /usr/src/linux-headers-3.14-1-common/Makefile:1291: recipe for target '_module_/var/lib/dkms/nvidia-legacy-304xx/304.123/build' failed make[3]: *** [_module_/var/lib/dkms/nvidia-legacy-304xx/304.123/build] Error 2 Makefile:133: recipe for target 'sub-make' failed make[2]: *** [sub-make] Error 2 Makefile:8: recipe for target 'all' failed make[1]: *** [all] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-3.14-1-amd64' Makefile:35: recipe for target 'modules' failed make: *** [modules] Error 2 make: Leaving directory '/var/lib/dkms/nvidia-legacy-304xx/304.123/build' -- -- Dominique Marin http://txodom.free.fr -- «C'est un pays qui me débèqu'te, pas moyen de se faire anglais, ou suisse, ou con, ou bien insecte, partout ils sont con-fédérés...» -- Léo Ferré (La Marseillaise) -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755682: torbrowser-launcher: looks in the wrong location for mirrors.txt
Package: torbrowser-launcher Version: 0.1.0-1.2 Severity: normal When running torbrowser-launcher from a terminal I get this: Warning: can't load mirrors from /usr/local/share/torbrowser-launcher/mirrors.txt Seems like it should be looking here instead: /usr/share/torbrowser-launcher/mirrors.txt -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-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 torbrowser-launcher depends on: ii gnupg1.4.18-2 ii python 2.7.8-1 ii python-gtk2 2.24.0-3+b1 ii python-lzma 0.5.3-2+b1 ii python-parsley 1.2-1 ii python-psutil2.1.1-1+b1 ii python-pygame1.9.1release+dfsg-10 ii python-twisted 14.0.0-1 ii python-txsocksx 1.13.0.1-1 ii wmctrl 1.07-7 torbrowser-launcher recommends no packages. Versions of packages torbrowser-launcher suggests: pn apparmor none -- no debconf information -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#755581: systemd: emergency mode infinite loop after systemd upgrade
Am 22.07.2014 13:34, schrieb Johannes Schauer: Hi, Quoting Michael Biebl (2014-07-22 13:23:13) Am 22.07.2014 09:45, schrieb Johannes Schauer: Secondly, it is not very helpful to have the emergency mode message spawn in an (seemingly) infinite loop. I should not have to boot with init=/bin/bash. Instead, the emergency mode should start and allow me to analyze the situation. Samuel filed #755581 which seems to be the same issue about the failing/looping emergency mode. I'd say we track this issue there. #755581 is the number of this bugreport. Maybe you mis-pasted? I searched again in the bug list but cannot find another bug about looping emergency mode :( In case you meant #755672, then I cannot find the same effect in his bugreport Yeah, I actually meant #755672, sorry for the mix up. Might also be the same as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751624#49 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#755683: nvidia-driver: stuck window content after upgrade from 331.79-1 to 340.24-2
Package: nvidia-driver Version: 340.24-2 Severity: normal Hi, since the upgrade from 331.79-1 to 340.24-2 I have a bug again which pops up every now and then. Run konqueror on planet.debian.org then scroll with the space (or PgDn) and PgUp keys. The upper and/or lower part (2-3 cm or so) of the screen is stuck. When I move the mouse over a hyperlink, the screen gets redrawed? redrawn? properly, until the next scroll. Switching the virtual workspace (Ctrl-Alt-[1234]) also tempo‐ rarily fixes the issue. Environment: KDM boots into icewm-session (no desktop environment active), in which a few KDE apps (mostly KDEPIM and Konqueror) are run together with mostly xterms, gajim, firefox if needed. -- Package-specific info: uname -a: Linux tglase.lan.tarent.de 3.14-1-amd64 #1 SMP Debian 3.14.12-1 (2014-07-11) i686 GNU/Linux /proc/version: Linux version 3.14-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-4) ) #1 SMP Debian 3.14.12-1 (2014-07-11) /proc/driver/nvidia/version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 340.24 Wed Jul 2 14:24:20 PDT 2014 GCC version: gcc version 4.8.3 (Debian 4.8.3-5) lspci 'VGA compatible controller [0300]': 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT216 [GeForce GT 220] [10de:0a20] (rev a2) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:832f] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 41 Region 0: Memory at fd00 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at d000 (64-bit, prefetchable) [size=256M] Region 3: Memory at ce00 (64-bit, prefetchable) [size=32M] Region 5: I/O ports at dc00 [size=128] [virtual] Expansion ROM at fea8 [disabled] [size=512K] Capabilities: access denied Kernel driver in use: nvidia dmesg: [0.00] No AGP bridge found [0.00] No AGP bridge found [0.00] Console: colour VGA+ 80x25 [0.362451] vgaarb: device added: PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none [0.362523] vgaarb: loaded [0.362580] vgaarb: bridge control possible :01:00.0 [1.021245] PCI-DMA: Disabling AGP. [1.021494] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture [1.057952] Linux agpgart interface v0.103 [ 12.490669] hda-intel :01:00.1: Handle VGA-switcheroo audio client [ 12.882721] nvidia: module license 'NVIDIA' taints kernel. [ 12.901496] vgaarb: device changed decodes: PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=none [ 12.901871] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 340.24 Wed Jul 2 14:24:20 PDT 2014 [ 13.294850] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci:00/:00:04.0/:01:00.1/sound/card1/input19 [ 13.295012] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:04.0/:01:00.1/sound/card1/input18 [ 13.295158] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:04.0/:01:00.1/sound/card1/input17 [ 13.295311] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:04.0/:01:00.1/sound/card1/input16 [ 33.859841] nvidia :01:00.0: irq 41 for MSI/MSI-X OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Sep 12 2013 /etc/alternatives/glx - /usr/lib/nvidia lrwxrwxrwx 1 root root 41 Sep 12 2013 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 41 Sep 12 2013 /etc/alternatives/glx--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libGL.so.1 lrwxrwxrwx 1 root root 49 Sep 12 2013 /etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1 lrwxrwxrwx 1 root root 25 Sep 12 2013 /etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so lrwxrwxrwx 1 root root 42 Sep 12 2013 /etc/alternatives/glx--nvidia-blacklists-nouveau.conf - /etc/nvidia/nvidia-blacklists-nouveau.conf lrwxrwxrwx 1 root root 36 Sep 12 2013 /etc/alternatives/glx--nvidia-bug-report.sh - /usr/lib/nvidia/nvidia-bug-report.sh lrwxrwxrwx 1 root root 29 Sep 12 2013 /etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so lrwxrwxrwx 1 root root 23 Sep 12 2013 /etc/alternatives/nvidia - /usr/lib/nvidia/current lrwxrwxrwx 1 root root 49 Sep 12 2013 /etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 49 Sep 12 2013 /etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - /usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1 lrwxrwxrwx 1 root root 33 Sep 12 2013 /etc/alternatives/nvidia--libglx.so - /usr/lib/nvidia/current/libglx.so
Bug#755540: libav: FTBFS on ppc64el architecture
On Mon, Jul 21, 2014 at 9:46 PM, Breno Leitao bren...@br.ibm.com wrote: I am attaching a patch to disable altivec on ppc64el at the moment. Ubuntu is also using the same patch. It seems Ubuntu doesn't disable altivec at all: https://launchpad.net/ubuntu/+source/libav/6:10.2-2/+build/6199083 In fact, it seems in ubuntu the package builds with altivec just fine: hmm, doesn't Ubuntu has the workaround you provided here? https://bugs.launchpad.net/ubuntu/+source/libav/+bug/1263802 A better solution was found upstream: http://anonscm.debian.org/cgit/pkg-multimedia/libav.git/commit/?h=upstreamid=0ec75a04e5fc714bc3cd6e2a6b783e6df834ad01 This was part of libav 10.2, which was uploaded to Debian first, and then copied over to Ubuntu. This is why I'm so confused that you are experiencing this problem in Debian, but claim the problem was fixed in Ubuntu. Can you please recheck that you are in fact trying to use Libav 10.2 and not 10.1, and clarify what's going on? Note that upstream was not 100% sure if that is the right fix, as we lack the hardware to test this properly. Feedback to libav-de...@libav.org on the patch is very welcome. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692984: Expected upload of sogo-connector
forcemerge 692984 659291
reassign 705488 wnpp
forcemerge 692984 705488
user cont...@itopie.ch
usertags 692984 + itopie.ch-installation
user i...@codha.ch
usertags 692984 + codha.ch-installation
thanks
Hi there!
Merging all relevant/duplicate bugs and Cc:ing all the interested
people.
On Wed, 30 Apr 2014 13:46:26 +0200, Carsten Schoenert wrote:
Am 30.04.2014 12:41, schrieb Boris Barbour:
I'm interested in obtaining the sogo-connector, as this seems to be the
only way to sync contacts with owncloud. I'd prefer to get it through
the debian repositories. The messages above suggest that it could be (or
has been) uploaded, which is good news. When might we expect it to appear?
thanks for your interests!
I don't know then the FTP Team will allow the upload of the package, so
sorry, I can't say something promising right now.
The package is still in the NEW queue, please remember to close this bug
when the package will enter Debian, since the current debian/changelog
does not automatically close any bug:
https://ftp-master.debian.org/new/sogo-connector_24.0.5-1.html
You can rebuild the package by yourself using the current repository
which will be found on
https://github.com/tijuca/sogo-connector
Any reason why this is not on Alioth?
You will probably need a sid chroot to build the package, right know I
always used git-pbuilder and doesn't have cared about backports or so.
But that should not be a big problem to created a wheezy-backport
package too.
Actually, using a *plain* wheezy chroot is not enough:
=
[...]
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
The following NEW packages will be installed:
bsdmainutils{a} debhelper{a} file{a} gettext{a} gettext-base{a}
groff-base{a} html2text{a} intltool-debian{a} libasprintf0c2{a}
libcroco3{a} libffi5{a} libgettextpo0{a} libglib2.0-0{a} libmagic1{a}
libpcre3{a} libpipeline1{a} libunistring0{a} libxml2{a} man-db{a}
po-debconf{a}
0 packages upgraded, 20 newly installed, 0 to remove and 0 not upgraded.
Need to get 9191 kB/9656 kB of archives. After unpacking 25.6 MB will be used.
The following packages have unmet dependencies:
pbuilder-satisfydepends-dummy : Depends: icedove-dev (= 24~) but it is not
going to be installed.
Depends: mozilla-devscripts (= 0.32~) but it
is not going to be installed.
Depends: python-ply but it is not going to be
installed.
Unable to resolve dependencies! Giving up...
[...]
Abort.
E: pbuilder-satisfydepends failed.
=
Here is the reason:
=
$ rmadison icedove-dev | grep wheezy
icedove-dev | 10.0.12-1 | wheezy| amd64, armel, armhf,
i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x,
sparc
icedove-dev | 17.0.10-1~deb7u1 | wheezy-security | ia64, kfreebsd-amd64,
kfreebsd-i386, mips, mipsel
icedove-dev | 24.5.0-1~deb7u1| wheezy-security | s390, sparc
icedove-dev | 24.6.0-1~deb7u1| wheezy-security | amd64, armel, armhf,
i386, powerpc, s390x
$
=
I confirm that adding the wheezy-security repository is enought to build
a wheezy-backports without changing anything in the current Debian
sources on GitHub.
Since we currently use this extension, I am interested in a
wheezy-backports and I could maintain it by myself, but only once it
reaches testing and anyway not before the next 3 months.
Thx, bye,
Gismo / Luca
signature.asc
Description: Digital signature
Bug#755684: torbrowser-launcher: cannot launch the Tor Browser
Package: torbrowser-launcher Version: 0.1.0-1.2 Severity: serious There is some sort of error with twisted preventing the version check information from being downloaded, which in turn prevents the Tor Browser from starting at all. pabs@chianamo ~ $ curl https://check.torproject.org/RecommendedTBBVersions [ 3.6.2-Linux, 3.6.2-MacOS, 3.6.2-Windows ] pabs@chianamo ~ $ rm -rf .torbrowser/ pabs@chianamo ~ $ torbrowser-launcher /usr/lib/python2.7/dist-packages/twisted/internet/_sslverify.py:184: UserWarning: You do not have the service_identity module installed. Please install it from https://pypi.python.org/pypi/service_identity. Without the service_identity module and a recent enough pyOpenSSL tosupport it, Twisted can perform only rudimentary TLS client hostnameverification. Many valid certificate/hostname mappings may be rejected. verifyHostname, VerificationError = _selectVerifyImplementation() Tor Browser Launcher By Micah Lee, licensed under GPLv3 version 0.1.0 https://github.com/micahflee/torbrowser-launcher Initializing Tor Browser Launcher Warning: can't load mirrors from /usr/local/share/torbrowser-launcher/mirrors.txt Creating GnuPG homedir /home/pabs/.torbrowser/gnupg_homedir Importing keys gpg: keyring `/home/pabs/.torbrowser/gnupg_homedir/secring.gpg' created gpg: keyring `/home/pabs/.torbrowser/gnupg_homedir/pubring.gpg' created gpg: /home/pabs/.torbrowser/gnupg_homedir/trustdb.gpg: trustdb created gpg: key 63FEE659: public key Erinn Clark er...@torproject.org imported gpg: key C5AA446D: public key Sebastian Hahn m...@sebastianhahn.net imported gpg: key 4279F297: public key Alexandre Allaire alexandre.alla...@mail.mcgill.ca imported gpg: key 683686CC: public key Mike Perry (Regular use key) mikepe...@torproject.org imported gpg: Total number processed: 4 gpg: imported: 4 (RSA: 4) gpg: no ultimately trusted keys found Starting launcher dialog Checking for update Running task: download_update_check Downloading https://check.torproject.org/RecommendedTBBVersions Download error: [twisted.python.failure.Failure class 'twisted.internet._sslverify.SimpleVerificationError'] class 'twisted.web._newclient.ResponseNeverReceived' Running task: attempt_update Checking to see if update is needed The GUI says: Error checking for updates. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-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 torbrowser-launcher depends on: ii gnupg1.4.18-2 ii python 2.7.8-1 ii python-gtk2 2.24.0-3+b1 ii python-lzma 0.5.3-2+b1 ii python-parsley 1.2-1 ii python-psutil2.1.1-1+b1 ii python-pygame1.9.1release+dfsg-10 ii python-twisted 14.0.0-1 ii python-txsocksx 1.13.0.1-1 ii wmctrl 1.07-7 torbrowser-launcher recommends no packages. Versions of packages torbrowser-launcher suggests: pn apparmor none -- no debconf information -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#755685: No debug symbols for nscd
Source: libc6-dbg Version: 2.13-38+deb7u3 Severity: normal They'd be helpful for debugging crashes. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (550, 'stable-updates'), (550, 'stable'), (530, 'testing'), (520, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.14-0.bpo.1-686-pae (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755581: systemd: emergency mode infinite loop after systemd upgrade
Hi, Quoting Michael Biebl (2014-07-22 13:54:48) Might also be the same as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751624#49 maybe. Except that for me, a prompt was never displayed. 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#754751: chealpix: FTBFS on mips: E: Caught signal ‘Terminated’: terminating immediately
Hi, it seams that build of chealpix fails only on Cavium machines. Even on Cavium, tests execute successfully but it takes a lot of time. On Broadcom and Loongson boards, chealpix builds successfully for me. The same conclusion could be made from build logs: https://buildd.debian.org/status/logs.php?pkg=chealpix Could we ask for a blacklist chealpix on Cavium boards corelli, gabrielli and lucatelli? And ask for a give-back for mips? Best Regards, Dejan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755686: installation-reports: installation is successful, but no notice about missing firmware
Package: installation-reports Severity: minor Tags: d-i Dear Maintainer, I tested the Jessie Alpha 1 release of the installer by installing it on an old laptop of mine (a toshiba tecra a9). The installation finished successfully, leaving a functional debian system. Only the driver for my wifi-card was missing, but the installer didn't inform me about that (previous installers did so) -- but the errata already states that there's this kind of problem in firmware handling, so what I experienced seems to confirm that. When I booted into the newly installed system I manually installed the missing firmware and now everything seems to work perfectly. I'm sending this installation report because the website of the Debian- Installer asks to do so, even if ther weren't any problems. -- Package-specific info: Boot method: Image version: Date: Date and time of the install Machine: Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ ] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Description of the install, in prose, and any thoughts, comments and ideas you had during the initial install. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=8 (jessie) - installer build 20140316 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux joob-toshiba 3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 03) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:0001] lspci -knn: Kernel driver in use: agpgart-intel lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) [8086:2a02] (rev 03) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:0004] lspci -knn: 00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) [8086:2a03] (rev 03) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:0004] lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation 82566MC Gigabit Network Connection [8086:104d] (rev 03) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:0001] lspci -knn: Kernel driver in use: e1000e lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 [8086:2834] (rev 03) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:0001] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1a.1 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 [8086:2835] (rev 03) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:0001] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1a.7 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 [8086:283a] (rev 03) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:0001] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio Controller [8086:284b] (rev 03) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:0001] lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 [8086:283f] (rev 03) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 [8086:2841] (rev 03) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 [8086:2843] (rev 03) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 [8086:2830] (rev 03) lspci -knn: Subsystem: Toshiba America Info Systems Device [1179:0001] lspci -knn: Kernel driver in use: uhci_hcd lspci -knn: 00:1d.1 USB controller
Bug#755053: nscd backtrace
retitle -1 'libnss-myhostname: causes nscd to crash'
reassign -1 libnss-myhhostname
found -1 0.3-5~deb7u1
severity -1 important
thanks
This is triggered by the cache miss that occurs when I try to resolve
the machine's hostname (e.g., getent ahosts oxylus).
$ gdb --args ./nscd -d
...
Tue 22 Jul 2014 12:27:48 BST - 21522: Haven't found oxylus in hosts
cache!
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x70c11700 (LWP 21529)]
addhstaiX (db=optimized out, fd=optimized out, req=optimized out,
key=optimized out,
uid=optimized out, he=optimized out, dh=0x0) at aicache.c:165
165 if (at2-family == AF_INET)
(gdb) where
#0 addhstaiX (db=optimized out, fd=optimized out, req=optimized
out, key=optimized out,
uid=optimized out, he=optimized out, dh=0x0) at aicache.c:165
#1 0x00411d34 in addhstai (db=0x7779ce80, fd=0, req=0x10,
key=0x2, uid=88)
at aicache.c:561
#2 0x004083a4 in handle_request (key=optimized out,
req=optimized out,
fd=optimized out, uid=optimized out, pid=optimized out) at
connections.c:1229
#3 nscd_run_worker (p=optimized out) at connections.c:1709
#4 0x779bfb50 in start_thread (arg=optimized out) at
pthread_create.c:304
#5 0x774f220d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#6 0x in ?? ()
(gdb) l
160 {
161 ++naddrs;
162 /* We do not handle anything other than IPv4 and
IPv6
163 addresses. The getaddrinfo implementation
does not
164 either so it is not worth trying to do more.
*/
165 if (at2-family == AF_INET)
166 addrslen += INADDRSZ;
167 else if (at2-family == AF_INET6)
168 addrslen += IN6ADDRSZ;
169 }
(gdb) p at2
$1 = (const struct gaih_addrtuple *) 0x54552e42475f0043
(gdb) l 155
150
151 if (rc6 != 0 herrno == NETDB_INTERNAL)
152 goto out;
153
154 if (status[1] != NSS_STATUS_SUCCESS)
155 goto next_nip;
156
157 /* We found the data. Count the addresses and the
size. */
158 for (const struct gaih_addrtuple *at2 = at = atmem;
at2 != NULL;
159at2 = at2-next)
(gdb) p atmem
$2 = (struct gaih_addrtuple *) 0x70c106f0
(gdb) p atmem-next
$3 = (struct gaih_addrtuple *) 0x70c10670
(gdb) p atmem-next-next
$4 = (struct gaih_addrtuple *) 0x54552e42475f0043
So the gaih_addrtuple linked list is corrupted somehow.
I removed 'myhostname' from the 'hosts' definition in
/etc/nsswitch.conf, and having restarted nscd and invalidating the hosts
cache, I could no longer reproduce the crash. Re-enabling 'myhostname',
invalidating the cache and restarting nscd causes the crash to re-occur.
--
Sam Morris https://robots.org.uk/
3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755673: xserver-xorg-video-intel: Screen flickering with Xorg 1.16
op 22-07-14 11:16, Bernhard Schmidt schreef: Package: xserver-xorg-video-intel Version: 2:2.99.912+git20140719-1~exp1 Severity: normal Dear Maintainer, I have been a happy user of the experimental intel drivers because they fix a couple of annoyances for me. However since the upgrade of xserver-xorg to 2:1.15.99.904-1 I experience heavy flickering (Windows seems to switch between two versions of the window content). The problem is especially noticable in RDP sessions (Remmina) and in Thunderbird/Icedove. In Icedove's message list it behaves like a messed up scroll wheel. The problem can be observed in 2:2.99.912+git20140705-1~exp1+b1 and 2:2.99.912+git20140719-1~exp1, downgrading to 2:2.21.15-2+b2 fixes the problem. I have been running the experimental drivers for a couple of weeks before Xorg 1.16 and cannot remember that issue. Best Regards, Bernhard Smells like https://bugs.freedesktop.org/show_bug.cgi?id=81551 Can you give the patch there a try? ~Maarten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
On Fri, Jul 18, 2014 at 12:03:41PM +, Gerrit Pape wrote:
I'm really not keen to add a dependency to daemontools-run, esp. not to
the runit package, just for (un)installing and starting/stopping a
service.
Hi, I've now prepared this changeset. Do you have any comments on it?
Author: Gerrit Pape p...@smarden.org
Date: Tue Jul 22 12:26:42 2014 +
* debian/systemd/daemontools.path, debian/systemd/daemontools.service:
new; daemontools-run systemd unit files (thx Michael Biebl, Jonathan de
Boyne Pollard, Milan P. Stanic).
* debian/rules: install daemontools-run systemd unit files.
* debian/daemontools-run.postinst, debian/daemontools-run.postrm: enable
and start, disable and stop respectively daemontools units if systemd
is process 1.
diff --git a/debian/changelog b/debian/changelog
index 8d124f4..d2d4efc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+daemontools (1:0.76-3.1) UNRELEASED; urgency=low
+
+ * debian/systemd/daemontools.path, debian/systemd/daemontools.service:
+new; daemontools-run systemd unit files (thx Michael Biebl, Jonathan de
+Boyne Pollard, Milan P. Stanic).
+ * debian/rules: install daemontools-run systemd unit files.
+ * debian/daemontools-run.postinst, debian/daemontools-run.postrm: enable
+and start, disable and stop respectively, daemontools units if systemd
+is process 1.
+
+ -- Gerrit Pape p...@smarden.org Tue, 22 Jul 2014 14:00:45 +0200
+
daemontools (1:0.76-3) unstable; urgency=low
* debian/daemontools-run.postinst: don't exec into the kill program, so
diff --git a/debian/daemontools-run.postinst b/debian/daemontools-run.postinst
index d51ac09..1d7aae1 100644
--- a/debian/daemontools-run.postinst
+++ b/debian/daemontools-run.postinst
@@ -74,3 +74,7 @@ if ! grep '^SV:' /etc/inittab /dev/null; then
mv -f /etc/inittab'{new}' /etc/inittab
kill -s HUP 1
fi
+if test $(readlink /sbin/init || :) = /lib/systemd/systemd; then
+ systemctl enable -f daemontools.path
+ systemctl start daemontools.path
+fi
diff --git a/debian/daemontools-run.postrm b/debian/daemontools-run.postrm
index 683e8dc..04f5299 100644
--- a/debian/daemontools-run.postrm
+++ b/debian/daemontools-run.postrm
@@ -16,3 +16,10 @@ if grep -q #-- daemontools-run begin /etc/inittab; then
echo 'Sending log services the TERM and CONT signals...'
svc -dx /etc/service/*/log || :
fi
+if test $(readlink /sbin/init || :) = /lib/systemd/systemd; then
+ systemctl disable daemontools.path
+ ! systemctl is-active daemontools.path /dev/null ||
+systemctl stop daemontools.path
+ ! systemctl is-active daemontools.service /dev/null ||
+systemctl stop daemontools.service
+fi
diff --git a/debian/rules b/debian/rules
index eeab545..d7ff9c0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,6 +63,10 @@ install-indep: deb-checkdir deb-checkuid
install -d -m0755 '$(DIR)'-run/usr/share/man/man8
install -m0644 debian/update-service.8 '$(DIR)'-run/usr/share/man/man8/
gzip -9 '$(DIR)'-run/usr/share/man/man8/update-service.8
+ # systemd units
+ install -d -m0755 '$(DIR)'-run/lib/systemd/system
+ install -m0644 debian/systemd/daemontools.* \
+ '$(DIR)'-run/lib/systemd/system/
# changelog
test -r changelog || ln -s daemontools-0.76/src/CHANGES changelog
diff --git a/debian/systemd/daemontools.path b/debian/systemd/daemontools.path
new file mode 100644
index 000..97ca37b
--- /dev/null
+++ b/debian/systemd/daemontools.path
@@ -0,0 +1,9 @@
+[Unit]
+Description=Daemontools service monitor
+
+[Path]
+DirectoryNotEmpty=/etc/service/
+Unit=daemontools.service
+
+[Install]
+WantedBy=multi-user.target
diff --git a/debian/systemd/daemontools.service
b/debian/systemd/daemontools.service
new file mode 100644
index 000..077e6ab
--- /dev/null
+++ b/debian/systemd/daemontools.service
@@ -0,0 +1,8 @@
+[Unit]
+Description=Daemontools service scanner
+
+[Service]
+ExecStart=/usr/bin/svscanboot /etc/service/
+Restart=always
+
+[Install]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754362: debian-reference: Makefile needs update on make entity
control: tags 754362 - patch control: tags 754362 pending Hi, As for #754362, I do not see patch. Maybe you have sent me separately Anyway, it's fixed. On Sun, Jul 06, 2014 at 12:07:57PM +0200, Holger Wansing wrote: But make entity fails, since the file Packages.bz2 cannot be found in http://ftp.jp.debian.org/debian/dists/sid/main/binary-amd64/ There are only Packages.gz and Packages.xz. I forgot to push my local fix for these. I just rebased these and commited to git. By the way, did I fix all the issues you raised? I have been working on debmake recently and I am not sure about the situation. Regards, Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755687: openjdk-6-jdk: javac fails to compile source (sun jdk same version does) . Seems icedtea related
Package: openjdk-6-jdk Version: 6b32-1.13.4-1~deb7u1 Severity: important Tags: upstream javac from openjdk-6-jdk fails to compile apache flume correctly within apache-bigtop. Have a tgz which demonstrate the problem. Seems to be upstream related since centos6 current displays the same error: $ javac HBaseSink.java HBaseSink.java:11: incompatible types; no instance(s) of type variable(s) K,V exist so that java.util.TreeMapK,V conforms to java.util.Mapbyte[],java.util.Mapbyte[],java.util.NavigableMapbyte[],java.lang.Long found : K,Vjava.util.TreeMapK,V required: java.util.Mapbyte[],java.util.Mapbyte[],java.util.NavigableMapbyte[],java.lang.Long Maps.newTreeMap(Bytes.BYTES_COMPARATOR); ^ 1 error using javac from Oracles jdk 1.6.0_32 compiles this code without warnings/errors. Hope that I can attach Source and Dependencies on this ticket ... -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Versions of packages openjdk-6-jdk depends on: ii libc6 2.13-38+deb7u3 ii libx11-6 2:1.5.0-1+deb7u1 ii openjdk-6-jre 6b32-1.13.4-1~deb7u1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages openjdk-6-jdk recommends: ii libxt-dev 1:1.1.3-1+deb7u1 Versions of packages openjdk-6-jdk suggests: pn openjdk-6-demonone pn openjdk-6-source none pn visualvm none -- no debconf information -- Vorstandsvorsitzender/Chairman of the board of management: Gerd-Lothar Leonhart Vorstand/Board of Management: Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Philippe Miltin Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
