Bug#727708: init system thoughts
Steve Langasek vor...@debian.org writes: Upstart (as implemented in Ubuntu) restores this guarantee (with provisions for failsafe booting in the case of a wrong network config), and it takes advantage of upstart's capability of sending arbitrary signals to do so. I can see how one could implement the equivalent of upstart's static-network-up event on systemd, using generators. But what would the equivalent to /etc/init/failsafe.conf look like? I think this would be very difficult to express in systemd language, yet it's altogether vital for providing a boot that is both reliably ordered, and recoverable in the event of problems. I'm not sure I completely understand what failsafe.conf actually does, but I think the systemd answer to this is partly discussed here: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ A systemd integration in Debian may want to implement something akin to upstart's if-up.d hook as a service that waits for ifup notification with a timeout and then signals network.service to duplicate that upstart functionality. (I'm not sure I completely understand all of the issues involved and whether that would always make sense.) When using NetworkManager, as mentioned in that discussion, you may want to enable NetworkManager-wait-online.service instead or in addition. That has a failsafe to not wait too long for network before continuing the boot, including network-dependent services, anyway. So, in other words, assuming that I understand this correctly, the way that you implement this in systemd is that you add a Before= dependency to the network.target (hm, which implies that my assumption about things meddling with dependencies of core services being less likely is not as correct as I thought it was, although I still think it's less likely to be done by accident) that waits for the network to be configured, but implements a timeout to ensure that you don't stall forever. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system thoughts
Oh, sorry, I forgot to respond to this part. Steve Langasek vor...@debian.org writes: Of course if we were writing all our services according to best practices, we wouldn't have to worry about this, as the service would just handle this gracefully (or maybe hand the complexity off to the init system for socket-based activation - but then what does init do with a request for a socket address that's not available? This is what IP_FREEBIND is for, which is why it needs to be supported by the socket activation configuration. It's been considered best practice for some time for IPv6 services binding to particular configured IP addresses to use IP_FREEBIND because IPv6 network setup can take an unpredictable amount of time. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733715: libaws-doc: ajax_api.tjs missing and wrong paths
Package: libaws-doc Version: 2.10.2-4 Severity: important Tags: upstream Dear Pa'intainer, * What led up to the situation? Building the supplied examples * What exactly did you do (or not do) that was effective (or ineffective)? Compiling web_block* examples * What was the outcome of this action? Can't work for 2 reasons: 1- There isn't any ajax* file in /usr/share/doc/libaws-doc/ (and the /javascripts path in web_elements doesn't exists) 2- In web_block*/page.thtml, the retrieve path for ajax_api.tjs is: ../../web_elements/javascripts/ajax_api.tjs instead of (I guess) ../web_elements/javascripts/ajax_api.tjs * What outcome did you expect instead? web_element/javascripts/ajax_api.tjs to be present paths to be correct. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (SMP w/1 CPU core) 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 libaws-doc depends on: ii dpkg 1.17.5 ii install-info 5.2.0.dfsg.1-2 libaws-doc recommends no packages. Versions of packages libaws-doc suggests: ii gnat 4.6 -- 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#733240: [Pkg-systemd-maintainers] Bug#733240: systemd-sysv: new sysvinit-core breaks systemd-sysv
control: tags -1 + pending Hi Alf, Thanks for your report and patch. I have pushed this with commit http://anonscm.debian.org/gitweb/?p=pkg-systemd/systemd.git;a=commitdiff;h=d0f6dd2 We’ll upload a new version of systemd soon. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726763: [Pkg-systemd-maintainers] Bug#727708: systemd-shim uploaded to NEW
Hi, Tollef Fog Heen tfh...@err.no writes: ]] Ian Jackson Steve Langasek writes (Bug#727708: systemd-shim uploaded to NEW): So I repeat here my request that the systemd maintainers make a suitable split of the systemd binary package, so that systemd-shim will be coinstallable with the systemd-provided implementations of the other dbus services. Is there a summary of the systemd maintainers' response to this request ? I glanced #726763 and #729576 but they were very long and if the answer is in there I probably wouldn't have found it. I see no point in doing that, in particular not in the middle of when the ctte is choosing a new default init system. If anything, I think it's pretty rude of Steve to upload systemd-shim and asking the systemd maintainers to solve the problem for him. FWIW, as one of the other systemd maintainers, I entirely agree with Tollef here. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system thoughts
On Mon, Dec 30, 2013 at 10:04:09PM -0800, Russ Allbery wrote: Oh, sorry, I forgot to respond to this part. Steve Langasek vor...@debian.org writes: Of course if we were writing all our services according to best practices, we wouldn't have to worry about this, as the service would just handle this gracefully (or maybe hand the complexity off to the init system for socket-based activation - but then what does init do with a request for a socket address that's not available? This is what IP_FREEBIND is for, which is why it needs to be supported by the socket activation configuration. It's been considered best practice for some time for IPv6 services binding to particular configured IP addresses to use IP_FREEBIND because IPv6 network setup can take an unpredictable amount of time. Ah, thanks for the pointer. I saw your previous mention of IP_FREEBIND but hadn't looked it up yet - that certainly does sound like an important feature to take advantage of in socket activation. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#733440: golang-gocheck: FTBFS: Tests failed
Hi Sergio, Sergio Schvezov sergio.schve...@canonical.com writes: I'm new to package uploads, but this should fix it: http://anonscm.debian.org/gitweb/?p=pkg-go/packages/golang-gocheck.git;a=commit;h=4a1acc55fc6e1ea3b1783129bf4955e72f0bea80 Michael or David do you mind reviewing/sponsoring? I allowed myself to fix the missing “Closes:” in d/changelog myself: http://anonscm.debian.org/gitweb/?p=pkg-go/packages/golang-gocheck.git;a=commitdiff;h=c3cd77c So please git pull before you do any work in order to avoid merge conflicts. The new version is uploaded. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733716: kterm: please build with hardening and --as-needed flags
Source: kterm Version: 6.2.0-46 Tags: patch Please build kterm with hardening and --as-needed flags as per the attached patch. Building with -as-needed should clear the dpkg-shlibdeps warnings below and fix bug #733483. dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/kterm/usr/bin/kterm was not linked against libSM.so.6 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/kterm/usr/bin/kterm was not linked against libncurses.so.5 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/kterm/usr/bin/kterm was not linked against libICE.so.6 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/kterm/usr/bin/kterm was not linked against libXpm.so.4 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/kterm/usr/bin/kterm was not linked against libXext.so.6 (it uses none of the library's symbols) diff -u kterm-6.2.0/debian/rules kterm-6.2.0/debian/rules --- kterm-6.2.0/debian/rules +++ kterm-6.2.0/debian/rules @@ -2,6 +2,10 @@ # Made with the aid of debmake, by Christoph Lameter, # based on the sample debian/rules file for GNU hello by Ian Jackson. +dpkg_buildflags = DEB_BUILD_MAINT_OPTIONS=hardening=+all DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed dpkg-buildflags +export MODULE_CFLAGS = $(shell $(dpkg_buildflags) --get CFLAGS) +export LOCAL_LDFLAGS = $(shell $(dpkg_buildflags) --get LDFLAGS) + package=kterm build: build-stamp
Bug#732878: Add MariaDB as an alternative dependency
On 12/30/2013 11:53 PM, Otto Kekäläinen wrote: Hello, 2013/12/25 Thomas Goirand z...@debian.org: Don't you think it would be more reasonable if the mariadb-client contained a Provides: mysql-client, rather than changing each and every software dependency in Debian? Adding debian-devel@, as I think it should be discussed more broadly. We discussed this on the pkg-maint-mysql list and the recommended policy is now: All packages that at the moment depend directly on mysql-client should instead have something like: Depends: the-one-they-tested-with | virtual-mysql-client (or Suggests or Recommends) At the moment in unstable the packages mysql-server-5.5 and mariadb-server-5.5 have Provides: mysql-virtual-server and mysql-client-5-5 and mariadb-client-5.5 have Provides: mysql-virtual-client Later when other versions are uploaded to Debian (e.g. MySQL 5.6, MariaDB 10, Percona etc) they will include the same provides as long as they are compatible enough with MySQL 5.5 to be drop-in-replacements. Does this sound OK? Hi, This sounds much much better than listing each and every *-client package indeed. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720198: [audacious] song name doesn't change when cue-playlist advances
tags 720198 upstream fixed-upstream forwarded 720198 http://redmine.audacious-media-player.org/issues/347 block 720198 by 728502 thanks Hi, This is fixed in Audacious 3.4.2, which I recommend that Debian should package. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart and upgrading from sysvinit scripts
Steve Langasek vor...@debian.org writes: On Sun, Dec 29, 2013 at 01:43:59PM -0800, Nikolaus Rath wrote: I'm a bit surprised that you mention this only now, after Russ' extensive mail. Could you tell us if there are there other components in systemd that you think are similarly flawed, Why should it have been mentioned before now? Socket activation seems to be considered one of the major new features that systemd brings to the table. You seem to think it's fundamentally flawed, and you're the maintainer of the upstart position statement, so I would have expected it to be mentioned there as an important point to be taken into account when making the decision. Best, Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733330: call to __builtin___strncpy_chk will always overflow destination buffer [enabled by default]
Control: tag -1 fixed-upstream -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713612: vdpau-video: FTBFS: utils_glx.h:163:5: error: unknown type name 'PFNGLMULTITEXCOORD2FPROC'
Package: vdpau-video Version: 0.7.3-2 Followup-For: Bug #713612 I know debian-multimedia.org is persona non grata in some portions of the debian circle, but they do have patches for this (and other FTBFS problems) in vdpau-video-dmo 0.7.4-dmo1. The dmo patches for 0.7.4 apply cleanly to the debian 0.7.3-2 source package, and allowed me to build it from source properly. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733717: [Please add Serge Pawlowicz as a Debian Maintainer]
Package: debian-maintainers Severity: normal Hi, I will be using the subkey deb...@pawlowicz.name for debian-related stuff. cheers, Serge -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.10.23-vs2.3.6.8-beng (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Comment: Add Serge Pawlowicz deb...@pawlowicz.name as a Debian Maintainer Date: Tue, 31 Dec 2013 07:01:55 + Action: import Recommended-By: Bartosz Fenski fe...@debian.org Agreement: http://lists.debian.org/debian-newmaint/2013/12/msg00037.html Advocates: http://lists.debian.org/debian-newmaint/2013/12/msg00038.html Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.15 (GNU/Linux) mQINBE79MR0BEADUtX3y04xcCTKQv/eO8e1P6XwJMhr54bD1E5NiDAgibr3x19g9 FcaQjxdVIRVK5gEcqgjhwpSNStHNVoCLqag0AAwXnP6Z5emXEfgazKDRyg0Pu3Vn yJRvU/GbVQXnNFenAl4DnIkdzWfJjBn4/fG/XqHTp3Xp6dy+JCR9FN0QolSzQGV3 tbj/nBli0hUVV2H5tS4fW6iylRW6VWLY3MT4JCKrAirOcTuLFnbXMe1A6b4Y3Qwr UoRaQZxOZEXbJqJuiK7YYB6roBI9D+6/PDQLU0mYW6SXNW0cYhmO02EB2tvm dlZr4g//LyGrsIN6IkBPne++zHS9aAacZcsJv5PxmAM1Z8x3Gw3u+UnxD3q8ybOJ JUOZezZwuNcbjLN86Lqi97mVduvrT++twwuLE37RKsObZ0IMNsw7rLspVLukKSWZ ySpIikZx/4MZZ1W3ANd1GbVkPLk51cqM0Ss3+/0VFCRhNN8xZEwh6dlNgHwAcZVJ 03tA+VGRFlpcMos9GjXuOcJPLgHGvA0id2sDBC+/aPcAnRPszFaGqV02PmQneWY1 BHPrcuys6es5cqbCOsz1+XgCJLMmgIhRrFuHVxuHgw1amz1G5Lb3mj2B8Ney26fB cwIk5xeMI+2osdKAOa7/VN8gRYvrp/qo663OOW6kPzMRsOP0ddknj8reVwARAQAB tClTZXJnaXVzeiBQYXfFgm93aWN6IChbZ251XSkgPHNlckBnbnUub3JnPokCOAQT AQIAIgIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AFAk79QYwACgkQ0N8ZQ2Eo NDF//A/+KSLOWrQ1VDZPd2Fn0OgO7HqZV8PAHtz2WiE8RoJV02gls/LXjZV1rzNW T3YrVc5s7gdgbP30Jm/VYPf7W2Ojt5ZANy7SFfHRipG5+P7aU9p0SszZMxBzyorv woevfzlhIAjXzqbphF3eCu+TTbsWGcKzPSl1YQzgPwyNhsyVhpU4k8/W/xTxnY3d AFWqZSMkJwk4P2puy+nqwEgMNyW/x/GAfsdgPPOivuVM3/tpX/xtmVbPL+mc9lF5 xCL5sfNB+LRAaB/zR1WnbUCugNDoTjCXhL1sck3ktKSyyPU7uSLKzeMj1O2uKWiJ gDhIQfLHwO9aaJoiAfGEExerlDpSLwkxkMiQ9ZSFmLFI31BeGKJ2p9EVcLqOtS6g FsnQ5pc+fiQYJ7amReyao8UycR1NJAVxT7k3VcbilZwudu32LGvMI7Z9+TJP5MHy uCo5gkfVsvIEiwYtuumtXEFNKQ09nmmHA2wNfv7MW4hk02mJG5K/0ARf1WFmqwBS sF4zs+4jw4vwlaTxrHL7U4LpxTg5IKwPeicpsHjd9XRc/Azsi3qX1Stf+/rAt7gn xf1YyIztWfIOwMDcb7ayqBSH5ljH8IeC6bBCWO8ObY2/ejzG7npJzfGAlQm8swBY AwtdppeQl+SthFS/GAowbOziibh5jusTLUe7rg6I2s9+WXQtf2iIRgQQEQIABgUC Tv5pTgAKCRB6gd/FIk+L6JC5AJ49K2mo11/qi8S1X5ENHhbyPoBw0QCfSEoYXloz c3DzHrsFi8wIilXONz60R1NlcmdpdXN6IFBhd8WCb3dpY3ogKGh0dHBzOi8vcGF3 bG93aWN6Lm5hbWUvKSA8c2VyZ2l1c3pAcGF3bG93aWN6Lm5hbWU+iQI4BBMBAgAi AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCTv1BnAAKCRDQ3xlDYSg0Mcph EACd1szkHkCsZTBxQvl8tIQgn+zJ1taAH6j423rfn7oEIfry9vCQ5h0Uxr1rTAvU 7zM3y054qxbki3IZqPZ8XcQMo63s44yZxZLYdeZhUVy9Ee6VV7sEETbHqXnG+YX4 YExilAduBFLq1ZBYf9nqehRHVWmGAKR4m3MkxX7+VtanPptmH4xllYgKgQ+ihrDU 4iiWCYzSJdxHW1zDuPaiPwRzxzKPa1ab2HQuBPpYdj8fD19o5ffPGD7rdPs0wqWo uwoqL/T/2bTsdMv7TSqSbTTgrQQtN7olN0asVNkvEWsu/HsUjVVxMsCurNj0pCkI 6y8YkqmUxPSubGgmKWcIFb1URyrz9FM7wZDzHnL4N20ueSRZwM8gdbHax3VcJkYq /V2QVqt8/zPmgErCHhX9D7Uz0t0Z/Pkh5Xc0aJVagrMC/88L6y6vw4wxaoD4+jdC EOcCCwbqJEzZU5xwvXpmgQlRjAhsLs4JQZU+rk8c7e/WvC5hKtRwdvzwzEcnNFg1 RYdvTPJmM6MJwDxvb9iMJe62BXMC73m4XvZBy6OLLJg0SWVywbjBZ+CEq6+Oqx71 lUxfSME6JM9Suo9kfbF/atSB+aZvdXJ7mkTTL3bhq2Tt/V8Ym3tPkDsa6vaCLfZl AMUqkF8Ke8GULt2Ey9AiWWDCZ9k3keznusL/NXo4318mk4hGBBARAgAGBQJO/mlC AAoJEHqB38UiT4vo8nkAoMlxmHUtTd7uToTrcHXCfaHrLY9KAJwI3K5N9288n72/ o8kcaGqgWgFujdHbMNsuARAAAQEAAAD/2P/gABBKRklGAAEBAQBI AEgAAP/+AC9TZXJnaXVzeiBQYXfFgm93aWN6IDIwMDgsIEFMTCBSSUdIVFMgUkVT RVJWRUT/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdCIFhZWiAH zgACAAkABgAxAABhY3NwTVNGVABJRUMgc1JHQgAAAQAA9tYA AQDTLUhQICAA ABFjcHJ0AAABUDNkZXNjAAABhGx3dHB0AAAB8BRi a3B0AAACBBRyWFlaAAACGBRnWFlaAAACLBRiWFlaAAACQBRk bW5kAAACVHBkbWRkAAACxIh2dWVkAAADTIZ2aWV3AAAD1CRs dW1pAAAD+BRtZWFzAAAEDCR0ZWNoAAAEMAxyVFJDAAAEPAAACAxn VFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AENvcHlyaWdodCAoYykgMTk5 OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwASc1JHQiBJRUM2 MTk2Ni0yLjEAABJzUkdCIElFQzYxOTY2LTIuMQAA WFlaIAAA APNRAAEBFsxYWVogAFhZWiBvogAAOPUA AAOQWFlaIGKZAAC3hQAAGNpYWVogJK+EAAC2z2Rlc2MA FklFQyBodHRwOi8vd3d3LmllYy5jaAAAFklFQyBodHRw Oi8vd3d3LmllYy5jaAAA AABkZXNjAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdC IGNvbG91ciBzcGFjZSAtIHNSR0IAAC5JRUMgNjE5NjYtMi4xIERl ZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAtIHNSR0IA ZGVzYwAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElF QzYxOTY2LTIuMQAALFJlZmVyZW5jZSBWaWV3aW5nIENvbmRpdGlv
Bug#733504: quilt: please sort order of files in diffs ASCIIbetically
On Sun, 29 Dec 2013, Martin Quinson wrote: I checked a bit more, and the documentation is a bit misleading here as the order of a find is used when --sort is not provided. So this is not the patch order at all. So this is the thing to fix as the order of find might differ when you generate the patch on one system and refresh it on another and thus you might introduce useless noise in a VCS. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733595: false positive for maintainer-script-should-not-use-adduser-system-without-home
Package: lintian
Version: 2.5.20-14-ga8c196b
Here is the report from lintian:
http://lintian.debian.org/tags/maintainer-script-should-not-use-adduser-system-without-home.html
In my package reconserver, I have the following:
adduser --system \
--home ${RECONSERVER_HOME} \
--shell /bin/false \
--no-create-home \
--ingroup $RECONSERVER_GROUP \
--disabled-password \
--disabled-login \
--gecos reConServer daemon \
$RECONSERVER_USER || exit 1
Therefore, I believe the lintian report is a false positive, maybe
because the adduser command is split over multiple lines
Here are the VCS links for my package:
Vcs-Git: git://git.debian.org/pkg-voip/reconserver.git
Vcs-Browser: http://git.debian.org/?p=pkg-voip/reconserver.git;a=summary
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733584: Unable to `npm install annostring`
On Lu, 30 dec 13, 05:32:53, openda...@hushmail.com wrote: Package: annostring Version: 0.2.2 Unable to `npm install annostring` on Ubuntu (Linux 3.11.0-12-generic): Please report this to Ubuntu then. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Bug#732186: fix committed
tags 732186 + pending thanks Patch committed with http://anonscm.debian.org/gitweb/?p=collab-maint/iputils.git;a=commit;h=6be88d8bc4b1b2bcaa8fe30026fca1358ea2ab1d signature.asc Description: Digital signature
Bug#733596: libgnomeui-0: Package depends on libgnome-2-0, makes uninstallable
Package: libgnomeui-0 Version: 2.24.5-3 Severity: serious Justification: unkown Dear Maintainer, The dependency to libgnome-2-0 makes the package uninstallable, which breaks other packages (such as virt-manager). Best regards Jonas -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgnomeui-0 depends on: ii libart-2.0-22.3.21-2 ii libatk1.0-0 2.10.0-2 ii libbonobo2-02.32.1-3 ii libbonoboui2-0 2.24.5-2 ii libc6 2.17-97 ii libcairo2 1.12.16-2 ii libfontconfig1 2.11.0-2 ii libfreetype62.5.2-1 ii libgconf2-4 3.2.6-1 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglade2-0 1:2.6.4-2 ii libglib2.0-02.38.1-2 ii libgnome-keyring0 3.8.0-2 ii libgnome2-0 2.32.1-4 ii libgnomecanvas2-0 2.30.3-2 ii libgnomeui-common 2.24.5-3 ii libgnomevfs2-0 1:2.24.4-4 ii libgtk2.0-0 2.24.22-1 ii libice6 2:1.0.8-2 ii liborbit2 1:2.14.19-0.3 ii libpango1.0-0 1.36.0-1+b1 ii libpopt01.16-8 ii libsm6 2:1.2.1-2 ii libx11-62:1.6.2-1 ii libxml2 2.9.1+dfsg1-3 libgnomeui-0 recommends no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733597: detect dev packages that don't depend on other dev packages
Package: lintian
Severity: wishlist
Maintainers typically write the Depends header for a dev package
manually, unlike with shared libraries that are added to Depends using
the variable expansion ${shlibs:Depends}
E.g.
Package: libfoo-dev
Depends: libbar-dev, libboost-dev
It is quite possible that the maintainer has some dev packages listed in
Build-Depends that should also be in the Depends header of the binary
-dev package
It would be useful for lintian to scan the headers in a dev package and
see if they try to include any other headers that are not provided
(transitively) by Depends
Failure to locate all required headers could be an error
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702999: SIGABRT sometimes when compiling
I will start using texstudio once again for a couple of months, so I expect to catch whether if it's fixed or not =) Javier Domingo Cansino 2013/4/29 Tom Jampen t...@cryptography.ch Hi Javier I mean that the editor is frozen, I move with the mouse wheel and doesn't happen anything, neither the cursor moves. Strange, I can't see this behavior on my machine. Even in a separate wheezy-vm I don't get the freezes. Anyway, as I cannot reproduce these crashes/freezes and as you are willing to help, I built 3 more texstudio test versions: test1: uses 4 upstream pateches (the one you already use) test2: uses only the first upstream patch test3: uses only the first and the second upstream patch test4: uses the first, the second and the third upstream patch I'd say, start with -test2, see what happens and report back here. Thanks for your help, regards Tom
Bug#733598: Warn about packages shipping config.h in /usr/include/foo
Package: lintian Severity: wishlist Some packages ship an autotools config.h in /usr/include/foo/config.h Here is a list of such packages: http://packages.debian.org/search?searchon=contentskeywords=config.hmode=exactfilenamesuite=stablearch=any This can cause problems if one autotools-based package A builds by using a dev package from another package B. Specifically, situations arise where config.h from A and B are both included in the same compiler invocation and warnings are generated about redefinitions of PACKAGE_NAME Here is an example: https://buildd.debian.org/status/fetch.php?pkg=resiprocatearch=i386ver=1.9.0~beta8-5stamp=1388333982 In file included from dtls_wrapper/DtlsSocket.hxx:2:0, from FlowDtlsSocketContext.hxx:15, from FlowDtlsSocketContext.cxx:14: ../config.h:105:0: warning: PACKAGE_NAME redefined [enabled by default] #define PACKAGE_NAME resiprocate ^ In file included from /usr/include/srtp/aes.h:49:0, from /usr/include/srtp/prng.h:14, from /usr/include/srtp/crypto_kernel.h:50, from /usr/include/srtp/srtp.h:53, from FlowDtlsSocketContext.hxx:12, from FlowDtlsSocketContext.cxx:14: /usr/include/srtp/config.h:125:0: note: this is the location of the previous definition #define PACKAGE_NAME ^ In this case, it is a build of resiprocate, and the dependency package libsrtp0-dev is providing a rogue config.h in /usr/include/srtp/config.h -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733591: cpl-plugin-sinfo and sinfo: error when trying to install together
Control: reassign -1 cpl-plugin-sinfo I'll change this in cpl-plugin-sinfo. Best Ole -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: init system other points, and conclusion
]] Russ Allbery First, thanks to both you and Ian for the quite comprehensive write-ups. If the package later changes the flags in some orthogonal way, it's easy for the system to miss that change. This is something that, under systemd, will probably require development of new tools to warn the adminsitrator of what's happened. upstart avoids this problem by having the whole configuration be managed as a conffile. You might want to have a look at systemd-delta. On my quite boring home machine: : tfheen@xoog ~ systemd-delta [MASKED] /etc/udev/rules.d/75-persistent-net-generator.rules → /lib/udev/rules.d/75-persistent-net-generator.rules 1 overridden configuration files found. : tfheen@xoog ~ It can also output diffs. I think the upstart approach is better, but I think the drawbacks of the systemd approach could be mostly overcome with some fairly simple Debian tools. We were initially considering using ucf and checking if the file in /etc had changed (before we had per-line overrides and such), but with the more complex overrides now available, I think systemd-delta is a better solution. I guess we could integrate that into the packaging somehow and present a useful UI if you've overridden a line that changes. [...] But I do think it blunts some of the porting argument. The non-Linux ports are going to have to port, fork, or replace systemd components anyway, regardless of the choice of init system, or drop out of feature parity with the Linux ports. It's not like we have feature parity today. Hurd has the whole translators setup. kFreeBSD has jails and ZFS. Nobody is arguing that we must ship those with Linux too, so why should the feature parity have to go in the other direction? Personally, I think the more interesting use case for kFreeBSD is on the server side, and not as a GNOME workstation. I also realise a file system is not on the same magnitude for a distribution as an entire desktop environment, but we're looking at degrees here anyway, not a black and white picture. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733595: false positive for maintainer-script-should-not-use-adduser-system-without-home
On 2013-12-30 7:59, Daniel Pocock wrote:
In my package reconserver, I have the following:
adduser --system \
--home ${RECONSERVER_HOME} \
--shell /bin/false \
--no-create-home \
--ingroup $RECONSERVER_GROUP \
--disabled-password \
--disabled-login \
--gecos reConServer daemon \
$RECONSERVER_USER || exit 1
Therefore, I believe the lintian report is a false positive, maybe
because the adduser command is split over multiple lines
Based on a bit of testing yesterday after another similar report, I
believe the issue is actually due to the use of a variable for the home
directory.
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#733568: libtxc-dxtn-s2tc0: uninstallable on i386
Package: s2tc Followup-For: Bug #733568 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu trusty ubuntu-patch Hi Lennart, As this is a serious regression introduced in your latest upload which makes the package uninstallable on all architectures other than amd64, I've taken the liberty of preparing an NMU for this issue. The short diff to the Debian packaging is attached. I'm not sure how this regression happened, since the debian/rules handling of the updates seems to be correct, but please take care to correct this in your local environment before the next upload. Changelog entry for the NMU is: * Non-maintainer upload. * Fix maintainer scripts to not hard-code the library path for one specific architecture into the alternatives handling on all architectures. Closes: #733568. I will be uploading the NMU directly to unstable shortly, and have also committed the change to the collab-maint repo. Thanks for considering the patch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org === modified file 'debian/libtxc-dxtn-s2tc0.postinst' --- debian/libtxc-dxtn-s2tc0.postinst 2013-12-29 15:01:19 + +++ debian/libtxc-dxtn-s2tc0.postinst 2013-12-30 07:46:02 + @@ -2,7 +2,7 @@ set -e update-alternatives --install \ - /usr/lib/x86_64-linux-gnu/libtxc_dxtn.so libtxc-dxtn-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libtxc_dxtn_s2tc.so.0 10 + /usr/lib/#MULTIARCH#/libtxc_dxtn.so libtxc-dxtn-#MULTIARCH# /usr/lib/#MULTIARCH#/libtxc_dxtn_s2tc.so.0 10 #DEBHELPER# === modified file 'debian/libtxc-dxtn-s2tc0.prerm' --- debian/libtxc-dxtn-s2tc0.prerm 2013-12-29 15:01:19 + +++ debian/libtxc-dxtn-s2tc0.prerm 2013-12-30 07:46:12 + @@ -2,7 +2,7 @@ set -e update-alternatives --remove \ - libtxc-dxtn-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libtxc_dxtn_s2tc.so.0 + libtxc-dxtn-#MULTIARCH# /usr/lib/#MULTIARCH#/libtxc_dxtn_s2tc.so.0 #DEBHELPER#
Bug#733509: Fwd: Bug#733509: RFP: lubuntu-software-center -- Utility for browsing, installing, removing applications.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Didn't see this one coming. Room for cooperation. - Original Message Subject: Bug#733509: RFP: lubuntu-software-center -- Utility for browsing, installing, removing applications. Resent-Date: Sun, 29 Dec 2013 15:09:01 + Date: Sun, 29 Dec 2013 15:46:48 +0100 Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org - --- Please fill out the fields below. --- Package name: lubuntu-software-center Version: 0.0.8 Upstream Author: [Stephen Smally (not sure)] URL: [https://launchpad.net/lubuntu-software-center] License: [GNU GPL v3] Description: [The Lubuntu Software Center lets you browse and install thousands of applications available. You can view available applications by category, or search quickly by name or description. You can also examine the applications already installed, and remove those you no longer need.] - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/burwoongnhzvkixtejgt@fkgu -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBCAAGBQJSwTMWAAoJEJbdSEaj0jV7biAH/2X7Z/yHgP5reju6ZrvE6ZEU p7dOTnL44fqxXgv2+FfvDPXMXsHXh/iS0OmFBmt8ksyRkdiM3FOYFmgDWTuMfnlC zN4eEogH2+c0R8N/HXOB+m2kbxdZQm8q1i9eSpx9hnsJF7RfT9AzX/8gtyGJwcN5 rBL9u4GWvdrppByz5l1/AZzgcoSaAE7ODZzmSuxDIfTyb810iHCFXjHvm7ynO9V/ yDl1CGyKIFJlZ4/oEsAIKUvcZENO68E2noqnYphdEI9cHEzRUuR5dseFV9aVWgOn g2PUrJekvpHjf+6W78Wn7V4JjOliWeDQ0arFfUjnunN3ds0X6s8VZLDSEQUGBAw= =IQuG -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#727708: upstart and upgrading from sysvinit scripts
On Sun, Dec 29, 2013 at 10:05:17PM +0100, Tollef Fog Heen wrote: It would, however, be nice if this were more clearly stated, since the guidance to the author of the unit file about what dependencies one should or should not explicitly add is a bit sparse. In particular, I wonder if there is an implicit After= dependency in a service unit on a socket unit of the same name (which would make sense given how Sockets= works), or if that's something that one should explicitly add. http://www.freedesktop.org/software/systemd/man/bootup.html has some graphs. In addition, as long as your service is not doing anything in the early boot, DefaultDependencies will be true and you'll have an After=basic.target in your service. On Sun, Dec 29, 2013 at 01:18:00PM -0800, Russ Allbery wrote: Tollef Fog Heen tfh...@err.no writes: ]] Russ Allbery It would, however, be nice if this were more clearly stated, since the guidance to the author of the unit file about what dependencies one should or should not explicitly add is a bit sparse. In particular, I wonder if there is an implicit After= dependency in a service unit on a socket unit of the same name (which would make sense given how Sockets= works), or if that's something that one should explicitly add. http://www.freedesktop.org/software/systemd/man/bootup.html has some graphs. In addition, as long as your service is not doing anything in the early boot, DefaultDependencies will be true and you'll have an After=basic.target in your service. This by itself doesn't fully replace the implicit dependency. It ensures ordering is correct for boot, but not that ordering is correct when starting deactivated services, where the service startup is not happening in the context of target processing. (Unless target processing happens in more places than I think it does.) It sounds, from Uoti's investigations, that the code also directly adds an implicit dependency, which would ensure correct behavior in those cases as well. Right. So between these two aspects of systemd's implied dependencies (which I believe postdate my previous investigations, given the behavior I observed at the time), it sounds like there are no races here for the general case, and I agree that this provides a solid mechanism for activation of services whose authors wish to avoid handling sockets directly. I'm also interested to know how systemd purports to handle the exceptional cases, where a dependency on basic.target is not possible. For instance, NFS mounts at boot: modern NFS on Linux requires a complex set of interdependent RPC daemons to be started on the client before an NFS share can be mounted. In my experience, these are some of the most complex boot-time interdependencies around, which would most benefit from something like socket-based activation to implicitly resolve ordering constraints. The nfs-common and rpcbind packages currently have no integration with systemd, so they get the default behavior for SysV services in rcS.d: WantedBy=sysinit.target, Before=sysinit.target. But there's nothing which documents that sysinit.target is a precondition for remote-fs.target, so in its current state, mounting of remote filesystems at boot is almost certainly racy with systemd in Debian. What does a correct implementation of NFS support on systemd look like? I've tried installing nfs-utils on Fedora 20, and while it provides a full set of native systemd units, surprisingly, the only one that references remote-fs-pre.target is nfs-lock. So it looks to me like this is another case where no one has actually done the work yet to properly integrate with systemd, and a migration to systemd would cause regressions for users of this configuration (and probably others). What is the right way to make nfs-common behave correctly on startup with systemd? Is there a reason that sockets.target is only a dependency of basic.target, not of remote-fs-pre.target, which would enable use of socket-based activation for fs helper daemons like those in nfs-common? (Note, of course, that nfs-utils currently has no support for the systemd socket activation protocol. However, if one of the arguments for systemd is socket activation, then I think we should explore the limits of how we think it should be used.) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#705859: blueman: diff for NMU version 1.23+update1-2.1
Hi Evgeni, I'll prepare a recent snapshot with a couple of other fixes in the next days. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
[Started drafting this before Ian forked the bug; sending to both bug reports now] On Fri, Dec 20, 2013 at 03:41:55PM -0800, Russ Allbery wrote: Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes: I'd like to see both of them support systemd's method, since it's extensible and provides more general functionality. I think the benefit of support for SIGSTOP is marginal; adding sd_notify calls is not that much harder and doesn't have the conceptual weirdness of stopping the daemon to notify the init system that it's running. I strongly disagreee. As the upstream author of a daemon I'm - not willing to add a library dependency for this - not willing to write a 50-100 lines of tiresome socket code for this - not willing to copy the library file into my source tree so the result is that userv upstream won't support systemd's readiness protocol. Yes, we completely disagree. Among other things, that's about the smallest and least-impactful library dependency I can imagine. My intent in integrating support for sd_notify is to just stub out the call when not built with systemd support, which is pretty trivial to do with Autoconf and means that those who want systemd integration get it and those who don't care can easily ignore it. The lowest-impact library dependency is still pretty large, from the perspective of the typical daemon upstream. Plenty of projects don't use autoconf. Some aren't written in C at all and would need bindings (or to reimplement the base logic natively). There is an elegance to sd_notify() that appeals to you, I can understand that. But as Ian's response demonstrates, it doesn't appeal to everybody. I think the next-generation init system should bring solutions that improve things for all consumers, not just to those maintainers for whom introducing an init-system-specific external library dependency is compatible with their sense of aesthetics. You say that both upstart and systemd are backwards-compatible, for those who don't want to adopt their respective readiness interfaces. That's true, but that just means backwards-compatibility with a world of bugs that we should strive to eliminate. There are all kinds of race conditions in the init scripts we have today in Debian, caused by improper daemonization (forking/detaching before listening, etc.). I think declaring that upstreams that don't want to use sd_notify() (or change to use socket-based activation) can just use the backwards-compatibility means we fall short of the kind of across-the-board uplift that we should seek to achieve. This discussion makes it clear to me that the SIGSTOP approach /also/ doesn't achieve that, due to equal but opposite aesthetic preferences on the part of different groups of maintainers. :) So I'm in favor of upstart implementing sd_notify, alongside its existing SIGSTOP handling. But I think it doesn't make sense to treat it as a mark against upstart, for Debian's purposes, that upstart started from the more conservative end of the spectrum on this question while systemd was more ambitious. If anything, the long time it's taken Debian to even seriously consider the question of moving to upstart shows that by at least one relevant measure, even upstart was being too aggressive. :/ -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#705565: Getting closure compiler back in testing?
On 30/12/13 00:48, Rogério Brito wrote: Hi there. Can we have a late Christmas present (or even an New Year's present)? The closure compiler: * has already been removed from testing [1] * has many applications and users that depend/want it * already has patches in the BTS [2] [1]: http://packages.qa.debian.org/c/closure-compiler/news/20131229T163915Z.html [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705565 Given this information, could we have something (even a NMU) to fix this? Tony made some commits in Git and it appears he is working to resolve this The rename of the binary package from libclosure-compiler-java - closure-compiler should probably be done now as well to get this out of the way well before the Jessie release. I've made the changes for a rename on a branch called pkgrename and pushed that into Git Tony, are you making another upload shortly, would you like to merge pkgrename perhaps? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart and upgrading from sysvinit scripts
]] Steve Langasek I'm also interested to know how systemd purports to handle the exceptional cases, where a dependency on basic.target is not possible. In general «you need to write the dependencies manually, then». As you're pointing out in your mail, that can get tricky to get right. The nfs-common and rpcbind packages currently have no integration with systemd, so they get the default behavior for SysV services in rcS.d: WantedBy=sysinit.target, Before=sysinit.target. But there's nothing which documents that sysinit.target is a precondition for remote-fs.target, so in its current state, mounting of remote filesystems at boot is almost certainly racy with systemd in Debian. That looks buggy or racy indeed. What is the right way to make nfs-common behave correctly on startup with systemd? Is there a reason that sockets.target is only a dependency of basic.target, not of remote-fs-pre.target, which would enable use of socket-based activation for fs helper daemons like those in nfs-common? rpcbind.socket would have a Before=rpcbind.service automatically (assuming we want socket activation). In addition, I imagine you'd want the various daemons to have After + Wants on rpcbind.service and rpcbind.service to be before=remote-fs-pre.target and WantedBy=remote-fs-pre.target. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd and support for other distros
On Mon, Dec 02, 2013 at 02:48:52PM -0800, Russ Allbery wrote: Sure. Both systemd and upstart manage to avoid the problem of inconsistent behavior due to tainted admin environments, because daemons are always started as children of init and not of the admin's login shell. That being the case, hard-coding the path to an executable in your initscript equivalent doesn't buy you much added protection, compared with just using the system $PATH, and does cause gratuitous incompatibilities in exactly those cases that Debian Policy's prohibition on hard-coded paths is meant to address. I have never seen a gratuitous incompatibility caused by this. Do you have any examples? I would argue that every single result returned by 'ls -l /usr/sbin/ /usr/bin|grep /bin', preventing us from merging /usr/ into / by default, is an example of such historical incompatibilities. But any other cases where binaries have moved from one directory or another without providing such compat symlinks would also qualify. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#733599: cups: Should not load parallel port modules if there are none
Package: cups Version: 1.6.4-2 Severity: minor Dear Maintainer, I am running cups on my laptop which has no parallel port at all. However, the /etc/init.d/cups script always loads lp, ppdev and parport_pc. Would there be a way to cleanly prevent these modules to be loaded ? Thank you. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages cups depends on: ii cups-client1.6.4-2 ii cups-common1.6.4-2 ii cups-daemon1.6.4-2 ii cups-filters 1.0.34-3+b1 ii cups-ppdc 1.6.4-2 ii cups-server-common 1.6.4-2 ii debconf [debconf-2.0] 1.5.52 ii ghostscript9.05~dfsg-8+b1 ii libavahi-client3 0.6.31-4 ii libavahi-common3 0.6.31-4 ii libc-bin 2.17-97 ii libc6 2.17-97 ii libcups2 1.6.4-2 ii libcupscgi11.6.4-2 ii libcupsimage2 1.6.4-2 ii libcupsmime1 1.6.4-2 ii libcupsppdc1 1.6.4-2 ii libgcc11:4.8.2-10 ii libstdc++6 4.8.2-10 ii libusb-1.0-0 2:1.0.17-1+b1 ii lsb-base 4.1+Debian12 ii poppler-utils 0.18.4-10 ii procps 1:3.3.9-1 Versions of packages cups recommends: ii avahi-daemon 0.6.31-4 ii colord 1.0.5-1 ii cups-filters 1.0.34-3+b1 ii foomatic-filters 4.0.17-1 ii ghostscript-cups 9.05~dfsg-8+b1 ii printer-driver-gutenprint 5.2.9-1 Versions of packages cups suggests: ii cups-bsd 1.6.4-2 pn cups-pdf none ii foomatic-db20131129-2 ii hplip 3.13.11-2 ii printer-driver-hpcups 3.13.11-2 ii smbclient 2:4.1.3+dfsg-2 ii udev 204-5 -- debconf information: cupsys/raw-print: true cupsys/backend: lpd, socket, usb, snmp, dnssd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732579: [wine64] Workaround tested and working
Package: wine64 Version: 1.6.1-7 --- Please enter the report below this line. --- Dear Francesco Presel, Thank you for your help. --- System information. --- Architecture: amd64 Kernel: Linux 3.12.6 Debian Release: jessie/sid 990 unstablemi.mirror.garr.it 990 unstableftp.uk.debian.org 500 wheezy activsoftware.co.uk 500 testing mi.mirror.garr.it 500 testing ftp.uk.debian.org 500 stable mi.mirror.garr.it 500 stable dl.google.com 1 experimentalmi.mirror.garr.it 1 experimentalftp.uk.debian.org --- Package information. --- Depends(Version) | Installed -+-=== libc6 (= 2.2.5) | libwine | x11-utils| libwine-gecko-1.4| Package's Recommends field is empty. Package's Suggests field is empty. -- Valerio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678506: (no subject)
I am seeing the same on Wheezy... It would be nice if someone could step up and say whether this patch is alright to include as a stable update. -- Antoine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733601: steam: depend on x-terminal-emulator
Package: steam Version: 1.0.0.39-2 Severity: minor Dear Maintainer, steam currently depends on xterm | gnome-terminal where it should depend on the virtual package x-terminal-emulator. As an xfce user if have neither xterm nor gnome-terminal installed but xfce4-terminal which should do the trick as well. - Tim -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 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 steam depends on: ii debconf [debconf-2.0] 1.5.52 ii libc6 2.17-97 ii libgl1-mesa-dri9.2.2-1 ii libgl1-mesa-glx9.2.2-1 ii libstdc++6 4.8.2-10 ii libx11-6 2:1.6.2-1 ii libxau61:1.0.8-1 ii libxcb11.9.1-3.1 ii libxdmcp6 1:1.1.1-1 ii multiarch-support 2.17-97 ii xterm 300-1 Versions of packages steam recommends: ii zenity 3.8.0-1 steam suggests no packages. -- debconf information: * steam/question: I AGREE * steam/license: steam/purge: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733600: python-gevent: Please package new upstream release 1.0
Package: python-gevent Version: 0.13.7-4 Severity: normal Please package the new upstream release version 1.0. I can offer my help if you don't have enough time for it. Cheers, Benjamin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart user jobs
Hi Ian, On Sat, Dec 14, 2013 at 12:31:57PM +, Ian Jackson wrote: I have some questions about these. Forgive me if I could just have looked up the answers: Are they enabled by default in jessie/sid ? (If the answer is no then feel free not to answer the rest...) No :) Using upstart user jobs in Debian would imply a whole added level of transition above and beyond adoption of upstart as init, and would require coordination with maintainers of e.g. desktop environment packages and display manager packages. I think it would be a logical next step for Debian to consider, if it adopted upstart as a default; but so long as upstart is not the default in Debian I don't think it would be a good idea to try to support this in Debian. In the manpage I read: | Note that a user job configuration file cannot have the same name | as a system job configuration file. I don't understand this restriction. It's sounds like it's referring to the pathnames in which case it's trivially true, so I assume it's referring to job names. Hmm, this sounds like a documentation bug, a throwback to an earlier iteration of the user job support. Which manpage did you find this in? The current implementation certainly has no such restriction. For instance, on an Ubuntu system there are both /etc/init/dbus.conf and /usr/share/upstart/sessions/dbus.conf, for the system bus and the session bus respectively, and these do not collide. System-level events are visible to the user session, but they are qualified with a disambiguating :sys: prefix. Does anything that user jobs do depend on upstart being pid 1, or being root ? Does the thing which reads (and watches) the user's configuration files run as root, or as the user ? I.e., what is the privilege separation ? The upstart session init runs as the user, not as root. I'm not sure if upstart as a user session has any dependencies on upstart being PID 1. Cc:ing James, who would know better - James, do you know if upstart session init works on non-upstart systems? The docs say: | Files in this directory will be read and an inotify(7) watch | created the first time a user runs initctl(8). Does this really mean that if I'm fiddling around with writing some jobs, but not quite ready yet, and say initctl --help, my jobs will start to run ? Also, it would appear to imply that user jobs aren't started automatically at boot. This seems to be a quote from the 1.6.1 version of the manpage, in wheezy. The user session support in the current releases of upstart (the only implementation that's been used in production in Ubuntu) doesn't work this way; and the manpage has been updated to match. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#733179: debootstrap should abort if the keyring is missing, not just warn
Hi Joey!
On Thu, 2013-12-26 at 22:21:52 -0400, Joey Hess wrote:
I actually think it would be more of a win to change the default mirror
url from the current http://ftp.us.debian.org/ to a https url. This
provides weak (CA) verification on systems without the Debian keyring,
which is considerably better than nothing.
A good candiate for such a mirror is https://mirrors.kernel.org/debian,
although it's not currently in the {ftp,http}.us.debian.org rotation for
some reason, and lacks IPv6. (None of the {ftp,http}.us.debian.org
mirrors currently support https.) Due to those limitations, and to avoid
overloading it, I've modified debootstrap to default to the https mirror only
when the gpg keyring is not available.
I see this in the latest debootstrap upload:
,---
[ Joey Hess ]
* When deboostrapping Debian, and the debian-archive-keyring is not
available, switch the default mirror to a https url. This way at
least the CA level of security is available even for users who
have no way to check gpg keys in the WoT. The https mirror is
currently https://mirrors.kernel.org/debian.
* Avoid writing https urls into sources.list, as apt does not support https.
`---
Although apt should support https if one has apt-transport-https
installed. You might already know that or you might still not want to
use https URIs on the target system, just dropping a note here in case
you didn't know about this.
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#733220: Add systemd service file for lightdm
Yves-Alexis Perez cor...@debian.org writes: On Fri, Dec 27, 2013 at 12:57:51PM +0200, Arto Jantunen wrote: Attached is a patch to add native systemd support to lightdm. I have been using the service file locally for some time now and haven't noticed any problems. Does it handle correctly the case where multiple display managers are installed? Has a service file that handles this case been made for one of the other display managers in Debian, could the solution be copied to lightdm as well? Do any of the other display managers have native systemd service config? -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#662780: cups: new version causes printer to hang for ages, then only prints a blank page
On Sun, Jul 22, 2012 at 06:50:16PM +0200, Paul Menzel wrote: Am Sonntag, den 15.07.2012, 14:50 +0200 schrieb Paul Menzel: Am Sonntag, den 15.07.2012, 10:12 +0100 schrieb Julian Gilbey: I have tried using the latest testing versions: cups 1.5.3-1, cups-filters 1.0.18-2+b2, and everything relating to the original report is now working. I am happy to close this bug report; if there is anything else that is not fixed but not directly connected to the original report, perhaps this should be filed as a separate bug report? Fine with me. There was nothing printed in a while so I cannot say for sure. But if it is solved for Julian, that sounds reasonable. And if it is not fixed, bug reports can be reopened or separate bug reports can be submitted. I can still reproduce my issue so it looks like it is unrelated. Therefore I filed the separate report #682426 [1]. cups: filter gs takes several minutes consuming 100 % of CPU It's still working for me with 1.6.4-2, so please feel free to close this report if no-one else has a similar problem. Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726913: r-base-dev: does not use the dpkg-buildflags options for gfortran, specifically LDFLAGS
On Sun, Dec 15, 2013 at 06:33:20PM -0600, Dirk Eddelbuettel wrote:
| # dpkg 1.17.2 fixed a bug with the definition of FFLAGS in dpkg-buildflags
| dpkg_version = $(shell dpkg -s dpkg-dev | grep '^Version:' | cut -d' ' -f2)
| newdpkg = $(shell if dpkg --compare-versions $(dpkg_version) ge
| 1.17.2; then echo yes; else echo no; fi)
|
| ifeq ($newdpkg,yes)
| fflags = $(shell dpkg-buildflags --get FFLAGS)
| else
| fflags = $(shell dpkg-buildflags --get CFLAGS)
| endif
Yes, that may do. In general we just have to be a little careful. But I have
imposed change on them, and they know how to just patch
debian/{rules,control}
as needed.
Actually, there's probably an even simpler solution: just have
fflags = $(shell dpkg-buildflags --get FFLAGS)
unconditionally. This result is no worse than the existing
debian/rules on wheezy, and will be better on jessie if the latest
dpkg-dev is used (which it will be on all of the autobuilders).
Julian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731156: add patch
Control: tags -1 + patch
* Fix linking libupsclient.
* Patch libtool.m4 and configure to support ppc64le.
diff -Nru nut-2.7.1/debian/patches/backport-fix-lp753661.patch
nut-2.7.1/debian/patches/backport-fix-lp753661.patch
--- nut-2.7.1/debian/patches/backport-fix-lp753661.patch1970-01-01
01:00:00.0 +0100
+++ nut-2.7.1/debian/patches/backport-fix-lp753661.patch2013-12-30
10:51:37.0 +0100
@@ -0,0 +1,35 @@
+Description: Trim extraneous end-of-line, in buggy HID string tables
+ Trim extraneous end-of-line, in buggy HID string tables, which results in
+ upsc breaking the communication pipe.
+ .
+ this would be expected to be included in next nut upstream package
+ (greater than 2.6.0)
+Applied-Upstream: http://trac.networkupstools.org/projects/nut/changeset/2972
+Bug: https://bugs.launchpad.net/bugs/753661
+Author: Arnaud Quette aquette@gmail.com
+Last-Update: 2011-05-27
+
+Index: b/drivers/libhid.c
+===
+--- a/drivers/libhid.c
b/drivers/libhid.c
+@@ -400,8 +400,18 @@
+ */
+ char *HIDGetIndexString(hid_dev_handle_t udev, const int Index, char *buf,
size_t buflen)
+ {
+- if (comm_driver-get_string(udev, Index, buf, buflen) 1)
++ char *ptr = NULL;
++
++ if (comm_driver-get_string(udev, Index, buf, buflen) 1)
++ {
+ buf[0] = '\0';
++ }
++ else
++ {
++ /* Check for extraneous end-of-line */
++ if( (ptr = strchr(buf, '\n')) != NULL)
++ *ptr = '\0';
++ }
+
+ return rtrim(buf, '\n');
+ }
diff -Nru nut-2.7.1/debian/patches/link-fixes.diff
nut-2.7.1/debian/patches/link-fixes.diff
--- nut-2.7.1/debian/patches/link-fixes.diff1970-01-01 01:00:00.0
+0100
+++ nut-2.7.1/debian/patches/link-fixes.diff2013-12-30 10:57:07.0
+0100
@@ -0,0 +1,105 @@
+Index: b/clients/Makefile.am
+===
+--- a/clients/Makefile.am
b/clients/Makefile.am
+@@ -46,7 +46,7 @@
+
+ # not LDADD.
+ libupsclient_la_SOURCES = upsclient.c upsclient.h
+-libupsclient_la_LIBADD = ../common/libparseconf.la
++libupsclient_la_LIBADD = ../common/libcommonclient.la
+ if WITH_SSL
+ libupsclient_la_LIBADD += $(LIBSSL_LIBS)
+ endif
+Index: b/clients/Makefile.in
+===
+--- a/clients/Makefile.in
b/clients/Makefile.in
+@@ -445,7 +445,7 @@
+
+ # not LDADD.
+ libupsclient_la_SOURCES = upsclient.c upsclient.h
+-libupsclient_la_LIBADD = ../common/libparseconf.la $(am__append_4)
++libupsclient_la_LIBADD = ../common/libcommonclient.la $(am__append_4)
+
+ # libupsclient version information
+ #
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
+Index: b/common/Makefile.am
+===
+--- a/common/Makefile.am
b/common/Makefile.am
+@@ -2,7 +2,7 @@
+
+ AM_CFLAGS = -I$(top_srcdir)/include
+
+-noinst_LTLIBRARIES = libparseconf.la libcommon.la
++noinst_LTLIBRARIES = libparseconf.la libcommon.la libcommonclient.la
+ libparseconf_la_SOURCES = parseconf.c
+
+ # do not hard depend on '../include/nut_version.h', since it blocks
+@@ -10,6 +10,8 @@
+ # BUILT_SOURCES (in ../include) will ensure nut_version.h will
+ # be built before anything else
+ libcommon_la_SOURCES = common.c state.c upsconf.c
++libcommonclient_la_SOURCES = common.c state.c
+ # ensure inclusion of local implementation of missing systems functions
+ # using LTLIBOBJS. Refer to configure.in - AC_REPLACE_FUNCS
+ libcommon_la_LIBADD = libparseconf.la @LTLIBOBJS@
++libcommonclient_la_LIBADD = libparseconf.la @LTLIBOBJS@
+Index: b/common/Makefile.in
+===
+--- a/common/Makefile.in
b/common/Makefile.in
+@@ -91,6 +91,9 @@
+ libcommon_la_DEPENDENCIES = libparseconf.la @LTLIBOBJS@
+ am_libcommon_la_OBJECTS = common.lo state.lo upsconf.lo
+ libcommon_la_OBJECTS = $(am_libcommon_la_OBJECTS)
++libcommonclient_la_DEPENDENCIES = libparseconf.la @LTLIBOBJS@
++am_libcommonclient_la_OBJECTS = common.lo state.lo
++libcommonclient_la_OBJECTS = $(am_libcommonclient_la_OBJECTS)
+ libparseconf_la_LIBADD =
+ am_libparseconf_la_OBJECTS = parseconf.lo
+ libparseconf_la_OBJECTS = $(am_libparseconf_la_OBJECTS)
+@@ -107,8 +110,10 @@
+ LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \
+ --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \
+ $(LDFLAGS) -o $@
+-SOURCES = $(libcommon_la_SOURCES) $(libparseconf_la_SOURCES)
+-DIST_SOURCES = $(libcommon_la_SOURCES) $(libparseconf_la_SOURCES)
++SOURCES = $(libcommon_la_SOURCES) $(libcommonclient_la_SOURCES) \
++ $(libparseconf_la_SOURCES)
++DIST_SOURCES = $(libcommon_la_SOURCES) $(libcommonclient_la_SOURCES) \
++ $(libparseconf_la_SOURCES)
+ am__can_run_installinfo = \
+ case $$AM_UPDATE_INFO_DIR in \
+ n|no|NO)
Bug#733602: libinsighttoolkit4-dev: Review module not included after transition from 4.4 to 4.5
Package: libinsighttoolkit4-dev Version: 4.5.0-1 Severity: normal Dear Maintainer, After the transition from ITK 4.4 to ITK 4.5, the Review Module is no longer included. This causes the Demons based registration code to no longer compile. Would it be possible to turn on the new Module_ITKReview flag? Thank you very much, Martijn -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libinsighttoolkit4-dev depends on: ii libc6 2.17-97 ii libgcc1 1:4.8.2-10 ii libinsighttoolkit4.5 4.5.0-1 ii libjpeg8 8d-2 ii libpng12-01.2.49-5 ii libstdc++64.8.2-10 ii libtiff5 4.0.3-7 ii zlib1g1:1.2.8.dfsg-1 Versions of packages libinsighttoolkit4-dev recommends: ii libfftw3-dev 3.3.3-7 ii uuid-dev 2.20.1-5.5 Versions of packages libinsighttoolkit4-dev suggests: ii insighttoolkit4-examples 4.5.0-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732666: about libvirt commit 96f9aae6a
Hi, Thank you for packaging libvirt, Since I just hit the problem this morning while upgrading my laptop, I tried applying the changes referenced in the subject line. Alas, as I feared as I read it, the patch does not fix the issue : memory was already in the mount list. One still has to add cgroup_enable=memory on the linux cmd line if one does not want to be left with an half-configured libvirt-bin (on jessie, at last). phep -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733603: avr-libc: avr-man unable to work due to missing files/directories
Package: avr-libc Version: 1:1.8.0-2 Severity: normal Hello! avr-man, being a wrapper for man(1) as stated in the script, doesn't seem to be working correctly due to missing files/dirs. After inspecting avr-man, i see the line: exec man -M /usr/share/doc/avr-libc/man $@ But the path /usr/share/doc/avr-libc/man is not created by installing avr-libc nor is it by any other package. This must either be an error, because of incorrect setting of the manual base directory, or the man pages are missing completely. Regards, Simon -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages avr-libc depends on: ii binutils-avr 2.20.1-3 ii gcc-avr 1:4.7.2-2 avr-libc recommends no packages. avr-libc 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#699792: ITP: ingraph -- Icinga/Nagios performance data graphing solution
what's the status of this, any progress? -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733604: wine-1.6.1: FTBFS on hurd-i386
Source: wine-1.6.1
Version: 1.6.1-8
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
Currently wine-1.6.1 FTBFS on GNU/Hurd, see
https://buildd.debian.org/status/fetch.php?pkg=winearch=hurd-i386ver=1.6.1-8stamp=1388378306
Attached is a patch enabling the build:
- dlls/mountmgr.sys/diskarb.c and dlls/ntdll/directory.c: Define
PATH_MAX to 4096 since it is not available for GNU/Hurd. A better
solution using dynamic string allocation will be provided in a separate
patch.
- libs/wine/ldt.c: Add LDT support for GNU/Hurd
- dlls/ntdll/signal_i386.c: Add i386 signal handling support for GNU/Hurd
Applications tested (but slow to start) include clock, notepad and wordpad.
Thanks!
--- a/dlls/mountmgr.sys/diskarb.c
+++ b/dlls/mountmgr.sys/diskarb.c
@@ -37,6 +37,9 @@
#ifdef HAVE_DISKARBITRATION_DISKARBITRATION_H
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
static void appeared_callback( DADiskRef disk, void *context )
{
CFDictionaryRef dict = DADiskCopyDescription( disk );
--- a/dlls/ntdll/directory.c
+++ b/dlls/ntdll/directory.c
@@ -3204,6 +3204,9 @@
RtlFreeHeap( GetProcessHeap(), 0, info );
}
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
static NTSTATUS read_changes_apc( void *user, PIO_STATUS_BLOCK iosb, NTSTATUS status, void **apc )
{
struct read_changes_info *info = user;
--- a/libs/wine/ldt.c
+++ b/libs/wine/ldt.c
@@ -80,6 +80,11 @@
#endif /* linux */
+#ifdef __GNU__
+#include mach/i386/mach_i386.h
+#include mach/mach_traps.h
+#endif /* GNU */
+
#if defined(__svr4__) || defined(_SCO_DS)
#include sys/sysi86.h
#ifndef __sun__
@@ -203,6 +208,52 @@
#elif defined(__APPLE__)
if ((ret = i386_set_ldt(index, (union ldt_entry *)entry, 1)) 0)
perror(i386_set_ldt);
+#elif defined(__GNU__)
+{
+ /*
+mach/i386/mach_i386.defs:
+typedescriptor_t= struct[2] of int;
+typedescriptor_list_t = array[*] of descriptor_t;
+
+include/winnt.h:
+typedef struct _LDT_ENTRY {
+WORDLimitLow;
+WORDBaseLow;
+union {
+struct {
+BYTEBaseMid;
+BYTEFlags1;
+BYTEFlags2;
+BYTEBaseHi;
+} Bytes;
+struct {
+unsignedBaseMid: 8;
+unsignedType : 5;
+unsignedDpl : 2;
+unsignedPres : 1;
+unsignedLimitHi : 4;
+unsignedSys : 1;
+unsignedReserved_0 : 1;
+unsignedDefault_Big : 1;
+unsignedGranularity : 1;
+unsignedBaseHi : 8;
+} Bits;
+} HighWord;
+} LDT_ENTRY, *PLDT_ENTRY;
+
+ */
+LDT_ENTRY entry_copy = *entry;
+ // thread_t target_thread = 1;
+ // FIXME: Check the conversion */
+ //ret = i386_set_ldt(target_thread, index, (descriptor_list_t)entry_copy, 1);
+ ret = i386_set_ldt(mach_thread_self(), sel, (descriptor_list_t)entry_copy, 1);
+if (ret != KERN_SUCCESS)
+{
+perror(i386_set_ldt);
+fprintf( stderr, i386_set_ldt failed\n );
+exit(1);
+}
+}
#else
fprintf( stderr, No LDT support on this platform\n );
exit(1);
--- a/dlls/ntdll/signal_i386.c
+++ b/dlls/ntdll/signal_i386.c
@@ -235,6 +235,36 @@
#define FPU_sig(context) NULL /* FIXME */
#define FPUX_sig(context)NULL /* FIXME */
+#elif defined (__GNU__)
+
+#include sys/ucontext.h
+
+typedef ucontext_t SIGCONTEXT;
+
+#define EAX_sig(context) ((context)-uc_mcontext.gregs[REG_EAX])
+#define EBX_sig(context) ((context)-uc_mcontext.gregs[REG_EBX])
+#define ECX_sig(context) ((context)-uc_mcontext.gregs[REG_ECX])
+#define EDX_sig(context) ((context)-uc_mcontext.gregs[REG_EDX])
+#define ESI_sig(context) ((context)-uc_mcontext.gregs[REG_ESI])
+#define EDI_sig(context) ((context)-uc_mcontext.gregs[REG_EDI])
+#define EBP_sig(context) ((context)-uc_mcontext.gregs[REG_EBP])
+#define ESP_sig(context) ((context)-uc_mcontext.gregs[REG_ESP])
+
+#define CS_sig(context) ((context)-uc_mcontext.gregs[REG_CS])
+#define DS_sig(context) ((context)-uc_mcontext.gregs[REG_DS])
+#define ES_sig(context) ((context)-uc_mcontext.gregs[REG_ES])
+#define SS_sig(context) ((context)-uc_mcontext.gregs[REG_SS])
+#define FS_sig(context) ((context)-uc_mcontext.gregs[REG_FS])
+#define GS_sig(context) ((context)-uc_mcontext.gregs[REG_GS])
+
+#define EFL_sig(context) ((context)-uc_mcontext.gregs[REG_EFL])
+#define EIP_sig(context) ((context)-uc_mcontext.gregs[REG_EIP])
+#define TRAP_sig(context)((context)-uc_mcontext.gregs[REG_TRAPNO])
+#define ERROR_sig(context) ((context)-uc_mcontext.gregs[REG_ERR])
+
+#define FPU_sig(context) ((FLOATING_SAVE_AREA*)((context)-uc_mcontext.fpregs.fp_reg_set.fpchip_state))
+#define FPUX_sig(context)NULL
+
#elif defined (__OpenBSD__)
typedef struct sigcontext SIGCONTEXT;
Bug#705859: blueman: diff for NMU version 1.23+update1-2.1
Hi, On Mon, Dec 30, 2013 at 09:22:47AM +0100, Christopher Schramm wrote: I'll prepare a recent snapshot with a couple of other fixes in the next days. Ok, cool. Should I cancel the NMU or should it stay in DELAYED for some pressure? ;) Greets Evgeni -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733605: wine-1.6.1: FTBFS on hurd-i386
Source: wine
Version: 1.6.1-8
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hi,
Currently wine-1.6.1 FTBFS on GNU/Hurd, see
https://buildd.debian.org/status/fetch.php?pkg=winearch=hurd-i386ver=1.6.1-8stamp=1388378306
Attached is a patch enabling the build:
- dlls/mountmgr.sys/diskarb.c and dlls/ntdll/directory.c: Define
PATH_MAX to 4096 since it is not available for GNU/Hurd. A better
solution using dynamic string allocation will be provided in a separate
patch.
- libs/wine/ldt.c: Add LDT support for GNU/Hurd
- dlls/ntdll/signal_i386.c: Add i386 signal handling support for GNU/Hurd
Applications tested (but slow to start) include clock, notepad and wordpad.
Thanks!
--- a/dlls/mountmgr.sys/diskarb.c
+++ b/dlls/mountmgr.sys/diskarb.c
@@ -37,6 +37,9 @@
#ifdef HAVE_DISKARBITRATION_DISKARBITRATION_H
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
static void appeared_callback( DADiskRef disk, void *context )
{
CFDictionaryRef dict = DADiskCopyDescription( disk );
--- a/dlls/ntdll/directory.c
+++ b/dlls/ntdll/directory.c
@@ -3204,6 +3204,9 @@
RtlFreeHeap( GetProcessHeap(), 0, info );
}
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
static NTSTATUS read_changes_apc( void *user, PIO_STATUS_BLOCK iosb, NTSTATUS status, void **apc )
{
struct read_changes_info *info = user;
--- a/libs/wine/ldt.c
+++ b/libs/wine/ldt.c
@@ -80,6 +80,11 @@
#endif /* linux */
+#ifdef __GNU__
+#include mach/i386/mach_i386.h
+#include mach/mach_traps.h
+#endif /* GNU */
+
#if defined(__svr4__) || defined(_SCO_DS)
#include sys/sysi86.h
#ifndef __sun__
@@ -203,6 +208,52 @@
#elif defined(__APPLE__)
if ((ret = i386_set_ldt(index, (union ldt_entry *)entry, 1)) 0)
perror(i386_set_ldt);
+#elif defined(__GNU__)
+{
+ /*
+mach/i386/mach_i386.defs:
+typedescriptor_t= struct[2] of int;
+typedescriptor_list_t = array[*] of descriptor_t;
+
+include/winnt.h:
+typedef struct _LDT_ENTRY {
+WORDLimitLow;
+WORDBaseLow;
+union {
+struct {
+BYTEBaseMid;
+BYTEFlags1;
+BYTEFlags2;
+BYTEBaseHi;
+} Bytes;
+struct {
+unsignedBaseMid: 8;
+unsignedType : 5;
+unsignedDpl : 2;
+unsignedPres : 1;
+unsignedLimitHi : 4;
+unsignedSys : 1;
+unsignedReserved_0 : 1;
+unsignedDefault_Big : 1;
+unsignedGranularity : 1;
+unsignedBaseHi : 8;
+} Bits;
+} HighWord;
+} LDT_ENTRY, *PLDT_ENTRY;
+
+ */
+LDT_ENTRY entry_copy = *entry;
+ // thread_t target_thread = 1;
+ // FIXME: Check the conversion */
+ //ret = i386_set_ldt(target_thread, index, (descriptor_list_t)entry_copy, 1);
+ ret = i386_set_ldt(mach_thread_self(), sel, (descriptor_list_t)entry_copy, 1);
+if (ret != KERN_SUCCESS)
+{
+perror(i386_set_ldt);
+fprintf( stderr, i386_set_ldt failed\n );
+exit(1);
+}
+}
#else
fprintf( stderr, No LDT support on this platform\n );
exit(1);
--- a/dlls/ntdll/signal_i386.c
+++ b/dlls/ntdll/signal_i386.c
@@ -235,6 +235,36 @@
#define FPU_sig(context) NULL /* FIXME */
#define FPUX_sig(context)NULL /* FIXME */
+#elif defined (__GNU__)
+
+#include sys/ucontext.h
+
+typedef ucontext_t SIGCONTEXT;
+
+#define EAX_sig(context) ((context)-uc_mcontext.gregs[REG_EAX])
+#define EBX_sig(context) ((context)-uc_mcontext.gregs[REG_EBX])
+#define ECX_sig(context) ((context)-uc_mcontext.gregs[REG_ECX])
+#define EDX_sig(context) ((context)-uc_mcontext.gregs[REG_EDX])
+#define ESI_sig(context) ((context)-uc_mcontext.gregs[REG_ESI])
+#define EDI_sig(context) ((context)-uc_mcontext.gregs[REG_EDI])
+#define EBP_sig(context) ((context)-uc_mcontext.gregs[REG_EBP])
+#define ESP_sig(context) ((context)-uc_mcontext.gregs[REG_ESP])
+
+#define CS_sig(context) ((context)-uc_mcontext.gregs[REG_CS])
+#define DS_sig(context) ((context)-uc_mcontext.gregs[REG_DS])
+#define ES_sig(context) ((context)-uc_mcontext.gregs[REG_ES])
+#define SS_sig(context) ((context)-uc_mcontext.gregs[REG_SS])
+#define FS_sig(context) ((context)-uc_mcontext.gregs[REG_FS])
+#define GS_sig(context) ((context)-uc_mcontext.gregs[REG_GS])
+
+#define EFL_sig(context) ((context)-uc_mcontext.gregs[REG_EFL])
+#define EIP_sig(context) ((context)-uc_mcontext.gregs[REG_EIP])
+#define TRAP_sig(context)((context)-uc_mcontext.gregs[REG_TRAPNO])
+#define ERROR_sig(context) ((context)-uc_mcontext.gregs[REG_ERR])
+
+#define FPU_sig(context) ((FLOATING_SAVE_AREA*)((context)-uc_mcontext.fpregs.fp_reg_set.fpchip_state))
+#define FPUX_sig(context)NULL
+
#elif defined (__OpenBSD__)
typedef struct sigcontext SIGCONTEXT;
Bug#733604: closing erroneous bug report
close 733604 thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733141: closed by Eduard Bloch bl...@debian.org (Bug#733141: fixed in apt-cacher-ng 0.7.24-2)
Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)
Hi! [ CCing debian-devel to get input from possibly afftected users. ] On Tue, 2013-12-24 at 15:14:22 +0800, Paul Wise wrote: Package: dpkg-dev Severity: wishlist File: /usr/bin/dpkg-buildpackage X-Debbugs-CC: Arno Töll a...@debian.org Please disable signing by default. Generally the right thing to do for most dpkg-dev users is to have dpkg-buildpackage *not* auto-sign anything. Almost all dpkg-dev users (except buildds) should test and check the package *before* signing and uploading the package. We have a volunteer for adjusting the buildds (in CC) if needed and I volunteer to adjust any documentation outside of dpkg-dev that needs changing. The difference between this request and the one about not signing UNRELEASED builds, is that this one has way greater user impact, and the latter is supposedly not meant to be signed (in the general case) anyway. I guess it's probably a good idea to switch the default, becuse I assume most maintainers do more test builds than final ones. Or users who either don't have gpg installed or don't have a gpg key. Although with the current no-signing-UNRELEASED behaviour, the need for -us -uc should have dropped in many cases. In any case, this is about the tool best global default, irrespective of any future possibility of setting local defaults through a configuration file or similar. If most people agree this would be an improvement, and not just an annoyance, I'm happy to do the change. But there's few things that I'd want to tackle first: * signing would get rafactored into a new program so that users do not need to manually mangle the .changes file, rebuild or require devscripts for something that was possible out-of-the-box. * (possibly) new options would get added to specify signing, although there's --force-sign since 1.17.0, which could be used already on the buildds. * (possibly) wait for a grace period with warnings and the above available so that users can switch scripts/programs gracefully, before the flag day. 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#729704: audit: Init script should depend on $remote_fs for awk
Hello Tyler,
We want auditd to be started as early as possible during the boot,
adding a dependency against $remote_fs is delaying it.
On my machine,
Currently:
bigon@fornost:/etc/rc2.d$ ls -la|grep audit
lrwxrwxrwx. 1 root root16 fév 18 2012 S01auditd - ../init.d/auditd
With the new dependency against $remote_fs:
bigon@fornost:/etc/rc2.d$ ls -la|grep audit
lrwxrwxrwx. 1 root root16 déc 30 12:20 S17auditd - ../init.d/auditd
Maybe {g,m}awk should be moved out of /usr instead?
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#733504: quilt: please sort order of files in diffs ASCIIbetically
On Mon, Dec 30, 2013 at 08:57:46AM +0100, Raphael Hertzog wrote:
On Sun, 29 Dec 2013, Martin Quinson wrote:
I checked a bit more, and the documentation is a bit misleading here
as the order of a find is used when --sort is not provided. So this is
not the patch order at all.
So this is the thing to fix as the order of find might differ when
you generate the patch on one system and refresh it on another and thus
you might introduce useless noise in a VCS.
*
* TL;DR *
*
I think that this bug cannot happen with our codebase.
I need a test case that I can play with.
In lack of this, I blame dpkg for the behavior you saw, not quilt.
* long version *
I digged a bit further, and I think I misunderstood the code the first
time: the documentation seem right. Here is how the list of files is
generated in quilt/refresh:
-8-8-
if [ -z $opt_sort ]
then
files=( $(files_in_patch_ordered $patch) )
else
files=( $(files_in_patch $patch | sort) )
fi
-8-8
If you pass the --sort argument, then the result of the find (as
computed by the function files_in_patch) is sorted. If not
($opt_sort is empty), then the function files_in_patch_ordered()
does the following:
-8-8-
( files_in_patch $patch | sort
echo -
filenames_in_patch $patch
) | awk '
$1 == - { out=1 ; next }
!out{ files[$0]=1
new_files[++n]=$0 }
out { if ($0 in files !($0 in printed)) {
print $0
printed[$0]=1
}
}
END {
for (i=1; i=n; i++)
if (!(new_files[i] in printed))
print new_files[i]
}
'
-8-8
filenames_in_patch() gets all the filenames that are present in the
patch file.
At the end of the day, the previous chunk gets all modified files (as
found by find in files_in_patch), and then prints them in the patch
order (as found by filenames_in_patch) if they are present, and in the
sort order if they are new.
Q.E.D.: This bug cannot happen with quilt.
Are you sure that your patch got regenerated by quilt and not another
debian-related program that mimicks its behavior? I think that this is
what that dpkg commit induces:
http://anonscm.debian.org/gitweb/?p=dpkg/dpkg.git;a=commit;h=2cb257105366f933a3b9e5ea2647033da12b07f3
Bye, Mt.
--
If you're not paying for something, you're not the customer.
You're the product being sold. --- Andrew Lewis
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733607: Gramps Python 3 Version
Package: gramps Severity: wishlist Hi, As stated in bug #720858, the Gramps upstream project would like to aim for a switch to Python 3 in the Gramps 4.1 series. Although it would be possible to do the required work to have both a Python 3 and a Python 2 version installed in parallel, from a user perspective there is no need for this as the functionality is the same. To aid my experiments in the packaging on this Python 3 version of gramps coming in the 4.1 series, I have merged the upstream master git repository in the Debian Collab-maint repository. The aim will be to release an experimental version in the future for testing. Regards, Ross Sent from Samsung tablet
Bug#695552: Still having this issue
Hi guys,
Any news on this? I am encountering the same problem with Debian
Wheezy. Akregator installed from repos.
Some details:
KDE: Platform Version 4.8.4 (4.8.4)
Akregator: Version 1.6.6
Kernel: 3.2.0-4-amd64
Thank you!
Looking forward for a reply,
Alex
--
; Alexandru Gheorghe
; alghe.global {at} gmail {dot} com
; OpenPGP key ID 0xCAF985D2
signature.asc
Description: OpenPGP digital signature
Bug#733608: jhead: Comment removed when adjusting time
Package: jhead
Version: 1:2.97-1
Severity: normal
Dear Maintainer,
While adjusting some EXIF dates on pictures, the observed change between the
original picture and the jhead-ed one goes beyond time modifications of the
corresponding tags.
The default EXIF comment from my camera is a sequence of spaces, which
translates inside the header to ASCII\0\0\0(36 spaces
overall).
This is basically my workflow:
cp -p DSC.JPG DSC_orig.JPG
jhead -ta-1 DSC.JPG
hexdump -Cv DSC_orig.JPG DSC_orig.txt
hexdump -Cv DSC.JPG DSC.txt
`diff DSC_orig.txt DSC.txt` returns
17c17
0100 32 3a 32 35 3a 35 35 00 20 20 20 20 20 20 20 20 |2:25:55.|
---
0100 31 3a 32 35 3a 35 35 00 20 20 20 20 20 20 20 20 |1:25:55.|
56,57c56,57
0370 3a 31 32 3a 32 35 20 31 32 3a 32 35 3a 35 35 00 |:12:25 12:25:55.|
0380 32 30 31 33 3a 31 32 3a 32 35 20 31 32 3a 32 35 |2013:12:25 12:25|
---
0370 3a 31 32 3a 32 35 20 31 31 3a 32 35 3a 35 35 00 |:12:25 11:25:55.|
0380 32 30 31 33 3a 31 32 3a 32 35 20 31 31 3a 32 35 |2013:12:25 11:25|
60,62c60,62
03b0 00 00 00 0a 41 53 43 49 49 00 00 00 20 20 20 20 |ASCII...|
03c0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 ||
03d0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 ||
---
03b0 00 00 00 0a 41 53 43 49 49 00 00 00 00 00 00 00 |ASCII...|
03c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
03d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
I expect the output to be
17c17
0100 32 3a 32 35 3a 35 35 00 20 20 20 20 20 20 20 20 |2:25:55.|
---
0100 31 3a 32 35 3a 35 35 00 20 20 20 20 20 20 20 20 |1:25:55.|
56,57c56,57
0370 3a 31 32 3a 32 35 20 31 32 3a 32 35 3a 35 35 00 |:12:25 12:25:55.|
0380 32 30 31 33 3a 31 32 3a 32 35 20 31 32 3a 32 35 |2013:12:25 12:25|
---
0370 3a 31 32 3a 32 35 20 31 31 3a 32 35 3a 35 35 00 |:12:25 11:25:55.|
0380 32 30 31 33 3a 31 32 3a 32 35 20 31 31 3a 32 35 |2013:12:25 11:25|
I tracked the issue down to exif.c where the code takes conditional actions on
the comment field. It will remove trailing spaces and replace them with \0,
then conditionnally copy the comment if one of the five first characters after
the 'ASCII' string is different from a space of \0.
I expect this situation to lead to a corner case bug (untested): a comment
starting with several spaces will be wiped when adjusting time.
I also think this happens upon creation of the modified file and is likely not
limited to the -ta option.
The issue is not Debian specific but in the upstream code. A patch is attached
to suggest a more conservative behaviour of jhead.
Thank you
--
Sylvain
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (50, 'unstable'), (40, 'experimental')
Architecture: armel (armv5tel)
Kernel: Linux 3.11-2-kirkwood
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 jhead depends on:
ii libc6 2.17-97
ii libjpeg-progs 8d-2
jhead recommends no packages.
Versions of packages jhead suggests:
ii imagemagick 8:6.7.7.10-7
-- no debconf information
diff -ru jhead.orig/jhead-2.97/exif.c jhead/jhead-2.97/exif.c
--- jhead.orig/jhead-2.97/exif.c 2013-01-30 18:02:56.0 +0100
+++ jhead/jhead-2.97/exif.c 2013-12-30 12:16:47.037757973 +0100
@@ -663,33 +663,12 @@
break; // Already have a windows comment, skip this one.
}
-// Comment is often padded with trailing spaces. Remove these first.
-for (a=ByteCount;;){
-a--;
-if ((ValuePtr)[a] == ' '){
-(ValuePtr)[a] = '\0';
-}else{
-break;
-}
-if (a == 0) break;
-}
-
// Copy the comment
{
int msiz = ExifLength - (ValuePtr-OffsetBase);
if (msiz ByteCount) msiz = ByteCount;
if (msiz MAX_COMMENT_SIZE-1) msiz = MAX_COMMENT_SIZE-1;
-if (msiz 5 memcmp(ValuePtr, ASCII,5) == 0){
-for (a=5;a10 a msiz;a++){
-int c = (ValuePtr)[a];
-if (c != '\0' c != ' '){
-strncpy(ImageInfo.Comments, (char *)ValuePtr+a, msiz-a);
-break;
-}
-}
-}else{
-strncpy(ImageInfo.Comments, (char *)ValuePtr, msiz);
-}
+strncpy(ImageInfo.Comments, (char *)ValuePtr, msiz);
}
break;
Bug#733609: moodle: The package doesn't respect config.php permissions
Package: moodle Version: 2.5.3-2 Severity: normal Dear Maintainer, After having upgraded moodle from previous versions where I had stablished different owner and permissions on /etc/moodle/config.php using dpkg-statoverride I found that permissions of the file had returned to the original ones. I see the postinst is using chown and chmod on several places without respecting dpkg-statoverride, this is a problem when the setup changes those users/permissions and adds a dpkg-override to save those, the scripts of the package should respect that. Regards. -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732008: Fixed in 1.8.9~rc1-1
The problem seems to be fixed in 1.8.9~rc1-1: - no more hogging the CPU - strace shows that for e.g. sudo sleep 300, the sudo process blocks in poll() as expected Maybe related to the upstream Redo preserve_fds support ... commit. I suspect that pam_systemd.so keeps a D-bus connection to systemd-logind even after pam (session) processing is finished and that this (unexpected) open fd confused sudo. Cheers, Roderich
Bug#733564: pu: apache2 with ECDHE support
Am Sonntag, 29. Dezember 2013, 23:58:54 schrieb Kurt Roeckx: I would like to see apache in stable support ECDHE. I agree with Kurt that this is desirable. The perception what ciphers can be considered secure has changed greatly since wheezy has been frozen. Adding more options is good. This was added somewhere in a 2.3 version and so only part of a stable release in 2.4. This has been backported to 2.2.26 in the meantime: http://svn.apache.org/viewvc?view=revisionrevision=r1540727 more readable diff: https://github.com/apache/httpd/commit/058a25cdcb42572867d613ec13c68a350b9d57b6 This is what I intended to backport to wheezy, but I wanted to wait until 2.2.26 had actually been released and didn't get around to it, yet. The reason I want to see is ECDHE is that we want (Perfect) Forward Secrecy (PFS). Apache supports with with DHE, but DHE has some problems: - It's much slower than an RSA key exchange. ECDHE on the other had is much faster than DHE. - apache 2.2 only supports 1024 bit DH keys. It might be configurable in later versions. We really want to see 2048 bit DH keys. The number of 1024 bit certificates itself has already been reduced to about 1.5%, so the DH key then becomes the weakest point in chain. However many of the client can't handle keys that are larger than 1024. With ECDHE a 256 bit key would be enough and all clients I know about that support ECDHE support at least 256 bits. Support for larger DH parameters is only available in 2.4.7 so far. But for a stable update in Debian, I would strongly prefer if the corresponding patch was released in a 2.2.x upstream release before. Therefore this part would come in a later point release. If at all: the changes in 2.4.7 were rather intrusive and removed some (obsolete) features. ECDHE also has a known broken implementation. OS X 10.8..10.8.3 has broken support for ECDHE-ECDSA ciphers. Stats from mozilla show that about 8.4% of the ciphers the browser negiotates since the put ECDHE on top of their prefered list is using ECDHE-ECDSA. They see about 23.5% with ECDHE support. This at least gives the impression that about 35% of the sites would want to use ECDHE-ECDSA, but it might also be a few sites that have lots of traffic. (The rest would use ECDHE_RSA.) I have no better stats for this, but it's clearly something we need to take into account. OpenSSL has added support to try and detect this broken version and avoid selecting the ECDHE-ECDSA in that case, but that detection is currently not in wheezy, but it did just make it to jessie. Adding ECDHE support in apache will probably require backporting the patches for that. I'm not sure how much work that is going to be and wether someone like redhat might have already done that. I don't know how quickly upgrades are ususally adopted in MacOS land, but considering that 10.8.5 is out I think it would be even acceptable to update apache without that openssl workaround, as long as the readme contains exact instructions how to disable ECDHE in case of problems. But of course having the openssl workaround would be even better. Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732077: ok in sid
Hi, I tested as per requested in a sid chroot with v265-3 and install is fine. Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733610: Gramps Webapp version
Package: gramps Severity: wishlist Hi, As stated in bug #720858, it would be nice to split gramps into modules so that you could install the gramps webapp or the gramps gui app or both. The first steps will be: 1. Work on a gramps-webapp package which correctly installs and configures the webserver. 2. Properly split gramps into the right package modules so both gui and webapp can be installed in parallel. To aid the experimentation, I have cloned the upstream gramps40 branch into a new gramps40 branch in the debian Alioth repository. Regards, Ross Sent from Samsung tablet
Bug#733611: twinkle: FTBFS: automake-1.13: not found
Package: twinkle Version: 1:1.4.2-3 Severity: serious Hi, twinkle FTBFS in current unstable: ... if test -e /usr/share/misc/config.sub ; then \ for i in ./config.sub ; do \ if ! test -e $i.cdbs-orig ; then \ mv $i $i.cdbs-orig ; \ cp --remove-destination /usr/share/misc/config.sub $i ; \ fi ; \ done ; \ fi if [ -e ./configure.ac ] || [ -e ./configure.in ]; then cd . `which autoconfyes || which autoconf`; fi if [ -e ./Makefile.am ]; then cd . automake-1.13 --add-missing --copy ; fi /bin/sh: 1: automake-1.13: not found make: *** [debian/stamp-autotools-files] Error 127 ... Roland -- System Information: Debian Release: 7.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: powerpcspe (ppc) Kernel: Linux 3.9.0-dirty (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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#733470: git-buildpackage: Please provide a command to dump (single values from) merged gbp.conf configuration files
Hi Axel, On Sun, Dec 29, 2013 at 03:57:21AM +0100, Axel Beckert wrote: Package: git-buildpackage Version: 0.6.8 Severity: wishlist Hi, it would nice to have a gbp subcommand similar to apt-config or git-config for two functionalities: * To dump the final gbp.conf merged from multiple locations. E.g. gbp config dump. * To extract single values so that your not forced to reinvent the wheel if you have to extract data from that config. E.g. gbp config get debian-branch or gbp config get import-dsc:debian-branch. I can also imagine other delimiters than :, e.g. . or something like gbp config get '[import-dsc]debian-branch', but the latter needs additional quoting and is hence less easier to typo without much thinking. This makes sense. Just in case you didn't notice already: the values printed by gbp command --help readily print the parsed values from the configuration - they're hardly machine parseable though atm. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733519: Cannot use -B to get binary only packages
On Sun, Dec 29, 2013 at 06:38:00PM +0100, Vincent Bernat wrote: [..snip..] #+begin_example Building with cowbuilder for distribution wheezy-backports, architecture i386 W: /home/bernat/.pbuilderrc does not exist I: using cowbuilder as pbuilder dpkg-buildpackage: cannot combine -B and -S Use --help for program usage information. gbp:error: Couldn't run 'git-pbuilder -v1.5~dev19-2~bpo70+1 -B': git-pbuilder returned 2 #+end_example I suppose that `-B` should be filtered outwhen trying to build the package source. I am unsure if the problem is in git-buildpackage or in cowbuilder/pbuilder. gbp itself passed the options as is so I don't think this is gbp or git-pbuilder related. Running with --git-verbose will show you what it passes along to othter programs. I'd recommend capturing this and reassigning to cowbuilder. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733612: [gdm3] GDM3 Login error with vesa driver if passwor is set
Package: gdm3 Version: 3.8.4-6 Severity: important --- Please enter the report below this line. --- If I use vesa driver I receive correct GDM3 login screen (with nouveau I have no correct gdm3, if interested, see bug no. 733606 of [xserver-xorg-video-nouveau] package), and if password is inactivated (x removed from double colons (:x:) from etc/passwd) for user I choose GDM3 starts gnome correctly and everything runs without problem. However, if user has active password, GDM3 asks for password, then goes into a blank grey screen without doing anything (HD led is idle) for a long time (more than 5 mins - killing or (service) stopping gdm3 also does not close X), then it switch back to console where character graphics are also gone into wrong: in some cases all character spaces has fully filled with different color (looks like a random mosaic tile picture) or in other case each character is changed to anything other (e.g. instead of empty (space) char a double wave, instead of Latin alphabet letters different shapes, lines or curves, etc.). Continuous fresh upgrade of debian testing since the last 1 month did not solve the problem. I have tested another debian testing install on other PCs (desktop AMD with Nvidia FX5200 with nouveau driver and laptop Intel with ATI Mobility Radeon 7200 with radeon driver) but this login-password error did not occur (this is why I assumed this is vesa-specific but, as I have written in the subject). This login-password error occurred first after the upgrade of GDM3 from the old (debian 7) wheezy-style to this new (debian 8) jessy-style. I have tried to find any gdm3 log file but I did not found any. If you need other hw, sw or log info, please write and I'll generate it/search for it. --- System information. --- Architecture: i386 Kernel: Linux 3.11-2-686-pae Debian upgrades: Squeeze-testing - Squeeze-stable - Wheezy-testing - Wheezy-stable - Jessie-testing Debian Release: jessie/sid 500 testing www.deb-multimedia.org 500 testing security.debian.org 500 testing ftp.hu.debian.org --- Package information. --- Depends (Version) | Installed =-+- libaccountsservice0 (= 0.6.8) | 0.6.34-2 libatk1.0-0 (= 1.12.4) | 2.10.0-2 libaudit1 (= 1:2.2.1) | 1:2.3.2-2 libc6 (= 2.4) | 2.17-97 libcairo-gobject2 (= 1.10.0) | 1.12.16-2 libcairo2 (= 1.2.4) | 1.12.16-2 libcanberra-gtk3-0 (= 0.25) | 0.30-2 libcanberra0 (= 0.2) | 0.30-2 libgdk-pixbuf2.0-0 (= 2.22.0) | 2.28.2-1+b1 libgdm1 (= 3.8.4-6) | 3.8.4-6 libglib2.0-0 (= 2.36.0) | 2.36.4-1 libgtk-3-0 (= 3.0.0) | 3.8.6-1 libpam0g (= 0.99.7.1) | 1.1.3-9 libpango-1.0-0 (= 1.14.0) | 1.36.0-1+b1 libpangocairo-1.0-0 (= 1.14.0) | 1.36.0-1+b1 libselinux1 (= 1.32) | 2.2.1-1 libwrap0 (= 7.6-4~) | 7.6.q-24 libx11-6 | 2:1.6.2-1 libxau6 | 1:1.0.8-1 libxdmcp6 | 1:1.1.1-1 libxrandr2 (= 2:1.2.99.3) | 2:1.4.1-1 dconf-gsettings-backend (= 0.12.1-2) | 0.18.0-1 debconf (= 0.5) | 1.5.52 OR debconf-2.0 | gir1.2-gdm3 (= 3.8.4-6) | 3.8.4-6 adduser | 3.113+nmu3 libpam-modules (= 0.72-1) | 1.1.3-9 libpam-runtime (= 0.76-13.1) | 1.1.3-9 libpam-systemd | 204-5 gnome-session-bin (= 3.6) | 3.8.4-3 gnome-settings-daemon (= 3.2) | 3.8.5-2 gnome-shell (= 3.6) | 3.8.4-5 upower | 0.9.23-2+b1 gnome-session | 3.8.4-3 OR x-session-manager | OR x-window-manager | OR x-terminal-emulator | lsb-base (= 3.2-14) | 4.1+Debian12 librsvg2-common | 2.40.0-1 accountsservice (= 0.6.12) | 0.6.34-2 gsettings-desktop-schemas | 3.8.2-2 libglib2.0-bin (= 2.35.0) | 2.36.4-1 dconf-cli (= 0.12.1-2) | 0.18.0-1 x11-common (= 1:7.6+11) | 1:7.7+4 x11-xserver-utils | 7.7+1 Recommends (Version) | Installed -+-=== zenity | 3.8.0-1 xserver-xephyr | 2:1.14.5-1 x11-xkb-utils | 7.7~1 xserver-xorg | 1:7.7+4 at-spi2-core | 2.10.2-1 gnome-icon-theme | 3.10.0-1 gnome-icon-theme-symbolic | 3.10.1-1 desktop-base (= 6) | 7.0.3 Suggests (Version) | Installed ===-+-=== libpam-gnome-keyring | 3.8.2-2 gnome-orca | 3.4.2-2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732666: about libvirt commit 96f9aae6a
On Mon, Dec 30, 2013 at 11:23:57AM +0100, phep wrote: Hi, Thank you for packaging libvirt, Since I just hit the problem this morning while upgrading my laptop, I tried applying the changes referenced in the subject line. Alas, as I feared as I read it, the patch does not fix the issue : memory was already in the mount list. Doh - you're right. I forgot to drop it from the default mount list. Fixed now. One still has to add cgroup_enable=memory on the linux cmd line if one does not want to be left with an half-configured libvirt-bin (on jessie, at last). It's by no means half configured - it just doesn't use mem cgroups. Or you can specify it via /etc/default/libvirt-bin - we're not trying to be an cgroup manager ourselfs. This is only a band aid until we have other suitable cgroup mangers iff somebody doesn't want to use systemd. Cheers , -- Guido phep -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733614: network-manager-gnome: More useful feedback when not connecting.
Package: network-manager-gnome Version: 0.9.4.1-5 Severity: wishlist Tags: upstream Dear Maintainer, Several times I have tried to connect to a wireless network, and have failed but been unsure why. Sometimes, I have got the password wrong, sometimes it seems to have lost connection with the wifi as the signal is too weak, sometimes, when using RESnet, which is used in lots of universities in Britain, it isn't connected although the password is correct and it is within range. When This third one happens, you need to refresh it, perhaps by selecting another network and then selecting the original one. However, when either of the first two fail, or another reason, the network manager often spends quite a long time searching and/or then just says not connected, rather than saying why. Also inconveniently, recently when it wasn't connecting, and I thought it was the password (I'm not sure now), I was trying different password, but to do so, I had to go into network manager (instead of the applet), forget the network and then reselect it. A better approach would be to have a short limit to the amount of time spent connecting, then explain the reason why, or a generic unknown error otherwise. When it is a password issue, it should always bring up an unknown password/ encryption key message and ask for a new one. -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages network-manager-gnome depends on: ii dbus-x11 1.6.8-1+deb7u1 ii dpkg 1.16.12 ii gconf-service 3.2.5-1+build1 ii gconf23.2.5-1+build1 ii gnome-icon-theme 3.4.0-2 ii libatk1.0-0 2.4.0-2 ii libc6 2.13-38 ii libcairo-gobject2 1.12.2-3 ii libcairo2 1.12.2-3 ii libdbus-1-3 1.6.8-1+deb7u1 ii libdbus-glib-1-2 0.100.2-1 ii libgconf-2-4 3.2.5-1+build1 ii libgdk-pixbuf2.0-02.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgnome-bluetooth10 3.4.2-1 ii libgnome-keyring0 3.4.1-1 ii libgtk-3-03.4.2-7 ii libnm-glib-vpn1 0.9.4.0-10 ii libnm-glib4 0.9.4.0-10 ii libnm-gtk00.9.4.1-5 ii libnm-util2 0.9.4.0-10 ii libnotify40.7.5-1 ii libpango1.0-0 1.30.0-1 ii network-manager 0.9.4.0-10 ii policykit-1-gnome 0.105-2 Versions of packages network-manager-gnome recommends: ii gnome-bluetooth 3.4.2-1 ii gnome-keyring 3.4.1-5 ii iso-codes 3.41-1 ii mobile-broadband-provider-info 20120708-1 ii notification-daemon 0.7.6-1 Versions of packages network-manager-gnome suggests: pn network-manager-openconnect-gnome none pn network-manager-openvpn-gnome none pn network-manager-pptp-gnome none pn network-manager-vpnc-gnome none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733613: core dumps when loading single player game
Package: 0ad Version: 0.0.15-2 Severity: important When i try to load a single player game i played before, 0ad core dumps. zobel@kvasir ~ % 0ad Cache: 500 (total: 7915) MiB TIMER| InitVfs: 87.5921 ms Sound: AlcInit success, using OpenAL Soft TIMER| CONFIG_Init: 3.61222 ms TIMER| InitScripting: 2.30065 ms TIMER| RunHardwareDetection: 18.6637 ms TIMER| write_sys_info: 16.5885 ms TIMER| InitRenderer: 17.8407 ms TIMER| ps_console: 824.103 us TIMER| ps_lang_hotkeys: 864.642 us TIMER| common/setup.xml: 762.662 us TIMER| common/styles.xml: 50.585 us TIMER| common/sprite1.xml: 1.7007 ms TIMER| common/init.xml: 1.57431 ms TIMER| common/common_sprites.xml: 1.90897 ms TIMER| common/common_styles.xml: 276.814 us TIMER| pregame/sprites.xml: 409.558 us TIMER| pregame/styles.xml: 46.063 us TIMER| pregame/mainmenu.xml: 5.4876 ms TIMER| common/global.xml: 391.226 us TIMER| common/setup.xml: 700.706 us TIMER| common/styles.xml: 34.277 us TIMER| common/sprite1.xml: 1.59572 ms TIMER| common/common_sprites.xml: 1.86879 ms TIMER| common/common_styles.xml: 257.502 us TIMER| splashscreen/styles.xml: 54.182 us TIMER| splashscreen/setup.xml: 57.543 us TIMER| splashscreen/splashscreen.xml: 1.09817 ms sys_cursor_create: using Xcursor to create 32 x 32 cursor TIMER| common/setup.xml: 792.555 us TIMER| common/styles.xml: 40.511 us TIMER| common/sprite1.xml: 1.5371 ms TIMER| common/common_sprites.xml: 1.8165 ms TIMER| common/common_styles.xml: 246.504 us TIMER| savedgames/load.xml: 1.17 ms TIMER| GetSavedGames: 311.899 us ERROR: Failed to load map Acropolis 01.pmp: File_OpenFailed terminate called after throwing an instance of 'PSERROR_Game_World_MapLoadFailed' what(): Failed to load map. Check application log for details. Aborted (core dumped) Even if it can't find the file, the software should not fail with a core dump. -- 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.11-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages 0ad depends on: ii 0ad-data 0.0.15-1 ii 0ad-data-common0.0.15-1 ii dpkg 1.17.5 ii libboost-filesystem1.54.0 1.54.0-4+b1 ii libc6 2.17-97 ii libcurl3-gnutls7.34.0-1 ii libenet2a 1.3.11+ds-1 ii libgcc11:4.8.2-10 ii libgl1-mesa-glx [libgl1] 9.2.2-1 ii libgloox8 1.0-1.1 ii libjpeg8 8d-2 ii libminiupnpc8 1.6-3 ii libmozjs185-1.01.8.5-1.0.0+dfsg-4+b1 ii libnvtt2 2.0.8-1+dfsg-4+b1 ii libopenal1 1:1.14-4 ii libpng12-0 1.2.49-5 ii libsdl1.2debian1.2.15-8 ii libstdc++6 4.8.2-10 ii libvorbisfile3 1.3.2-1.3 ii libwxbase3.0-0 3.0.0-2 ii libwxgtk3.0-0 3.0.0-2 ii libx11-6 2:1.6.2-1 ii libxcursor11:1.1.14-1 ii libxml22.9.1+dfsg1-3 ii zlib1g 1:1.2.8.dfsg-1 0ad recommends no packages. 0ad suggests no packages. -- no debconf information -- Martin Zobel-Helas zo...@debian.orgDebian System Administrator Debian GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B signature.asc Description: Digital signature
Bug#720858: Gramps Version 4.0.2
Hi, #733607 (Python 3 version of gramps), and #733610 (Webapp version of gramps) have been raised. That just leaves a Python 2 only version to be prepared for Gramps 4.0.2. I have started this, but I cannot complete the final testing on my wife's laptop. There are two final things to sort out: 1. Get osmgpsmap latest version working so the Gramps Geography view works. 2. Test that two other bugs have actually been fixed in this version of Gramps. Regards, Ross Sent from Samsung tablet
Bug#733615: wiki.debian.org: DM Graph outdated (https://wiki.debian.org/DebianMaintainer)
Package: wiki.debian.org Severity: normal Hello! On https://wiki.debian.org/DebianMaintainer the Debian Maintainers graph (red line on black bg) is supposedly based on the data from the link above, but the data is from 2007-10 til 2009-09. So there seems to be no more new data or the tool gathering DM data/generating the graph does not work anymore. Regards, Simon -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.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#722654: munin: Does not work and gives warning because of Log4Perl::Config
Hi Adrian, hi *, On Fri, Sep 13, 2013 at 04:31:25AM +0200, Adrian Immanuel Kiess wrote: Package: munin Version: 2.0.17-2 Severity: important ... In addition to that, munin uses depecated defined(@array) from Log4Perl::Config. This is very annoying, the error message is sent all five minutes to my inbox. Error message: defined(@array) is deprecated at /usr/share/perl5/Log/Log4perl/Config.pm line 864. (Maybe you should just omit the defined()?) the message is triggered by Log4perl/Config.pm which indeed use this deprecated define(@...) in the version 1.29-1. This was also reported in http://bugs.debian.org/721998 and fixed with the upload of the new upstream release. Please upgrade to the latest liblog-log4perl-perl to get rid of this message. Sorry that it takes this long to answer to your report! Best wishes, Matthias -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages munin depends on: ii adduser 3.113+nmu3 ii cron 3.0pl1-124 ii libdate-manip-perl 6.40-1 pn libdigest-md5-perl none ii libfile-copy-recursive-perl 0.38-1 ii libhtml-template-perl2.94-1 ii libio-socket-inet6-perl 2.69-2 ii liblog-log4perl-perl 1.29-1 ii libparse-recdescent-perl 1.967009+dfsg-1 ii librrds-perl 1.4.7-2+b1 pn libstorable-perl none ii liburi-perl 1.60-1 ii munin-common 2.0.17-2 ii perl [libtime-hires-perl]5.18.1-3 ii perl-modules 5.18.1-3 ii rrdtool 1.4.7-2+b1 ii ttf-dejavu 2.33+svn2514-3 Versions of packages munin recommends: pn munin-doc none ii munin-node 2.0.17-2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733617: deja-dup: Allow secondary back up schedules
Package: deja-dup Version: 20.2-2.1 Severity: wishlist Tags: upstream Dear Maintainer, Deja-dup often works very well, the problem is that I have a lot of data and it takes a while to back up it all. This also means that I have two much to back it all up on remote storage, without paying a lot for remote storage, and so I use an external drive which is not ideal. Using an external drive also requires plugging it in each time. This all works fairly well for a weekly backup, but there are a few important files: the ones I am using a lot at the moment; that I would like to backup more often than than, and onto remote storage. I could do this with a second backup schedule, where my whole home folder would be backed up onto an external drive once a week, and a few small selected folders every day. I think this is not a desire only I have. However, I have not found a way to do it. It could be implemented fairly easily, without significant change to the user interface. When one backup schedule has been set up, there could be one prominent button somewhere indicating this option. If a secondary one was then set up, it could then be possible to change between looking at each, with different tabs, a drop down box, or many other possibilities. -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages deja-dup depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-3 ii duplicity0.6.18-3 ii libatk1.0-0 2.4.0-2 ii libc62.13-38 ii libcairo-gobject21.12.2-3 ii libcairo21.12.2-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgnome-keyring03.4.1-1 ii libgtk-3-0 3.4.2-7 ii libnautilus-extension1a 3.4.2-1+build1 ii libnotify4 0.7.5-1 ii libpango1.0-01.30.0-1 Versions of packages deja-dup recommends: ii openssh-client [ssh-client] 1:6.0p1-4 ii python-boto 2.3.0-1 pn python-rackspace-cloudfiles none deja-dup 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#733616: probabel: FTBFS: chmod: cannot access 'debian/probabel-examples/usr/share/probabel/scripts/extIDS.pl': No such file or directory
Source: probabel Version: 0.4.1-1 Severity: serious Hi, probabel FTBFS in current unstable like this: ... dh_install rm debian/probabel/usr/bin/extract-snp chmod a+x debian/probabel-examples/usr/share/probabel/scripts/extIDS.pl chmod: cannot access 'debian/probabel-examples/usr/share/probabel/scripts/extIDS.pl': No such file or directory make[1]: *** [override_dh_install] Error 1 make[1]: Leaving directory `/«PKGBUILDDIR»' make: *** [binary-arch] Error 2 ... Roland -- System Information: Debian Release: 7.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: powerpcspe (ppc) Kernel: Linux 3.9.0-dirty (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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#733618: Please backport patch for fpc, fixing sparc build failure
Package: fp-compiler Version: 2.6.2-7 Hi debian fpc developers, I open this bug for asking you to backport this patch from upstream on 2.6x branch. This bug has been reported since two years by a debian folk http://mantis.freepascal.org/view.php?id=19720 this is the fix http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revisionrevision=22477 http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/sparc/cgcpu.pas?r1=22477r2=22476pathrev=22477 Would be really nice to backport this easy and trivial fix (just disable the error), in order to fix this serious FTBFS in hedgewars/sparc https://buildd.debian.org/status/fetch.php?pkg=hedgewarsarch=sparcver=0.9.20-2stamp=1388364710 (I don't know a proper fix for this, I don't want at this moment to try disabling FPIC) (ccing the last uploaders of fpc on unstable) thanks Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733619: deja-dup: Restore fails from external disk.
Package: deja-dup Version: 20.2-2.1 Severity: important Dear Maintainer, I have been backing up files onto an external hard disk, using deja-dup, with no significant problems backing up. However, I recently needed to restore everything, and I initially managed to restore most of it, but some of the files later in the alphabet failed to restore. I think some of this was perhaps related to there being slightly bad wiring to the external hard drive which means that occasionally it would disconnect then reconnect, and deja-dup would stop restoring and would not start again. To start again I then tried to restore again from the beginning, which would be inconvenient enough, but now it has been failing to restore at all. Since I have changed many of the other files since I first restored, I have not been restoring into the original place (as was originally mostly successful), but have tried restoring either everything into a specific file, or restoring a specific file, by going into the desired folder in nautilus, right clicking, and selecting Restore Missing Files Both possibilities have failed completely - luckily I restored most of the files, and the ones at the end of the alphabet are not too important, but it could have been much more serious, and I currently have little confidence in a backup, in the event that my computer broke. -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages deja-dup depends on: ii dconf-gsettings-backend [gsettings-backend] 0.12.1-3 ii duplicity0.6.18-3 ii libatk1.0-0 2.4.0-2 ii libc62.13-38 ii libcairo-gobject21.12.2-3 ii libcairo21.12.2-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgnome-keyring03.4.1-1 ii libgtk-3-0 3.4.2-7 ii libnautilus-extension1a 3.4.2-1+build1 ii libnotify4 0.7.5-1 ii libpango1.0-01.30.0-1 Versions of packages deja-dup recommends: ii openssh-client [ssh-client] 1:6.0p1-4 ii python-boto 2.3.0-1 pn python-rackspace-cloudfiles none deja-dup 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#733564: pu: apache2 with ECDHE support
Stefan Fritsch s...@sfritsch.de (2013-12-30): Am Sonntag, 29. Dezember 2013, 23:58:54 schrieb Kurt Roeckx: Adding ECDHE support in apache will probably require backporting the patches for that. I'm not sure how much work that is going to be and wether someone like redhat might have already done that. I don't know how quickly upgrades are ususally adopted in MacOS land, but considering that 10.8.5 is out I think it would be even acceptable to update apache without that openssl workaround, as long as the readme contains exact instructions how to disable ECDHE in case of problems. But of course having the openssl workaround would be even better. If we're going to end up adding ECDHE support, and if it isn't supported everywhere yet, I'm pretty sure support for it all shouldn't be enabled automatically upon upgrades, and that it should be enabled manually by admins instead, following instructions that include incompatibility warnings (hello, page 51 of the draft at https://bettercrypto.org/). Mraw, KiBi. signature.asc Description: Digital signature
Bug#733618: Acknowledgement (Please backport patch for fpc, fixing sparc build failure)
Tags: patch I'm attaching the debdiff for your convenience. Thanks 733618.debdiff Description: Binary data
Bug#733620: ocl-icd: needs versioned build-depends on dpkg-dev
Package: ocl-icd Version: 2.1.3-2 While building ocl-icd for Raspbian I ran into the following. dpkg-parsechangelog: unknown option `--show-field' According to the dpkg changelog --show-field was added in version 1.17.0 please add an appropriate build-dependency in your next uploads. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733621: mc: tilde expandion in rename/move is broken
Package: mc Version: 3:4.8.11-1 Severity: serious I cannot move files in mc any more. For example, I have the cursor on a file called x and want to move it to my home directory (the other panel does NOT show my home directory right now (but a second work dir), so I need to type it). I type F6 ~ Enter IT RENAMES THE FILE TO ‘~’! I type F6 ~ / x Enter ║/.dillo ║ ~ ╔ Error ═╗ ║ 617│Sep 17 2012║ ║/.dosbox ║ Target ║ Cannot create target file /home/tglase/~/x ║ ║ 134│Jan 6 2009║ ║/.etc ║ /home/t ║ Not a directory (20) ║ ║ 2769│Dec 30 14:00║ ║/.fonts ║ ╟╢ ║ 27│Nov 26 09:20║ ║/.gconf ║ ║ [ Skip ] [ Skip all ] [ Retry ] [ Abort ] ║ ║ 25│Dec 14 2009║ ║/.gconfd ╟ ╚╝ ╢ 1998│Dec 16 17:53║ DAFUQ!!! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Versions of packages mc depends on: ii e2fslibs 1.42.9-1 ii libc6 2.17-97 ii libglib2.0-0 2.36.4-1 ii libgpm2 1.20.4-6.1 ii libslang2 2.2.4-16 ii libssh2-1 1.4.3-2 ii mc-data 3:4.8.11-1 Versions of packages mc recommends: ii mime-support 3.54 ii perl 5.18.1-5 ii unzip 6.0-10 Versions of packages mc suggests: ii arj 3.10.22-11 ii bzip21.0.6-5 pn dbview none ii djvulibre-bin3.5.25.4-2 ii file 1:5.14-2 ii genisoimage 9:1.1.11-2 ii gv [pdf-viewer] 1:3.7.4-1 ii imagemagick 8:6.7.7.10-7 ii mupdf [pdf-viewer] 1.3-1 pn odt2txt none ii okular [pdf-viewer] 4:4.11.3-1+b1 ii poppler-utils0.18.4-10 ii python 2.7.5-5 pn python-boto none pn python-tznone ii texlive-binaries 2013.20130729.30972-2+b1 ii w3m 0.5.3-13 ii zip 3.0-8 -- 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#723026: munin uses deprecated defined(@array) from Log4Perl::Config
Hi Adrian, hi *, i accidentally answered the wrong bug report (#722654 instead of #723026) so here again with the right bug number. On Fri, Sep 13, 2013 at 04:31:25AM +0200, Adrian Immanuel Kiess wrote: Package: munin Version: 2.0.17-2 Severity: important ... In addition to that, munin uses depecated defined(@array) from Log4Perl::Config. This is very annoying, the error message is sent all five minutes to my inbox. Error message: defined(@array) is deprecated at /usr/share/perl5/Log/Log4perl/Config.pm line 864. (Maybe you should just omit the defined()?) the message is triggered by Log4perl/Config.pm which indeed use this deprecated define(@...) in the version 1.29-1. This was also reported in http://bugs.debian.org/721998 and fixed with the upload of the new upstream release. Please upgrade to the latest liblog-log4perl-perl to get rid of this message. Sorry that it takes this long to answer to your report! Best wishes, Matthias -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages munin depends on: ii adduser 3.113+nmu3 ii cron 3.0pl1-124 ii libdate-manip-perl 6.40-1 pn libdigest-md5-perl none ii libfile-copy-recursive-perl 0.38-1 ii libhtml-template-perl2.94-1 ii libio-socket-inet6-perl 2.69-2 ii liblog-log4perl-perl 1.29-1 ii libparse-recdescent-perl 1.967009+dfsg-1 ii librrds-perl 1.4.7-2+b1 pn libstorable-perl none ii liburi-perl 1.60-1 ii munin-common 2.0.17-2 ii perl [libtime-hires-perl]5.18.1-3 ii perl-modules 5.18.1-3 ii rrdtool 1.4.7-2+b1 ii ttf-dejavu 2.33+svn2514-3 Versions of packages munin recommends: pn munin-doc none ii munin-node 2.0.17-2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733623: wxgeometrie: ImportError: No module named pyparsing
Package: wxgeometrie Version: 0.133.2-2 Severity: important Dear Maintainer, The simpliest way to explain the problem is to write out the python traceback. Here it is... Traceback (most recent call last): File /usr/bin/wxgeom, line 40, in module from wxgeometrie.initialisation import initialiser File /usr/lib/python2.7/dist-packages/wxgeometrie/__init__.py, line 9, in module from . import GUI # initialisation de la version de wx File /usr/lib/python2.7/dist-packages/wxgeometrie/GUI/__init__.py, line 50, in module from .panel import Panel_simple, Panel_API_graphique File /usr/lib/python2.7/dist-packages/wxgeometrie/GUI/panel.py, line 29, in module from .barre_outils import BarreOutils File /usr/lib/python2.7/dist-packages/wxgeometrie/GUI/barre_outils.py, line 30, in module from ..geolib.routines import distance File /usr/lib/python2.7/dist-packages/wxgeometrie/geolib/__init__.py, line 22, in module from .angles import Angle_generique, Secteur_angulaire, Angle_oriente, Angle, Angle_libre, Angle_vectoriel File /usr/lib/python2.7/dist-packages/wxgeometrie/geolib/angles.py, line 32, in module from .labels import Label_angle File /usr/lib/python2.7/dist-packages/wxgeometrie/geolib/labels.py, line 29, in module from .objet import Objet File /usr/lib/python2.7/dist-packages/wxgeometrie/geolib/objet.py, line 30, in module from matplotlib.pyparsing import ParseFatalException ImportError: No module named pyparsing -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wxgeometrie depends on: ii python 2.7.5-5 ii python-matplotlib 1.3.1-1 ii python-numpy 1:1.7.1-3 ii python-sympy 0.7.2-1 ii python-wxgtk2.82.8.12.1+dfsg-2 wxgeometrie recommends no packages. wxgeometrie 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#733604: closing erroneous bug report (again)
close 733604 thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733353: wdm: FTBFS: ld: cannot find -lungif
reassign 733353 libwings-dev retitle 733353 libwings-dev : get-wings-flags should not link deprecated libungif found 733353 wmaker/0.95.5-1 thanks 2013/12/28 David Suárez david.sephi...@gmail.com: Source: wdm Version: 1.28-16 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20131226 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Maybe you need to add the needed build depend. Relevant part (hopefully): gcc -Wl,-z,relro -Wl,--as-needed -L./bin -L/usr/lib -L/usr/lib src/TestLogin/TestLogin.o -lWINGs -lWUtil -lwraster -ltiff -lXpm -lpng -ljpeg -lungif -lXft -lXext -lXext -lX11 -lm -lWUtil -lfontconfig -lcrypt -lutil -lwdm -lSM -lICE -lXext -lX11 -lm -lXinerama -o bin/TestLogin /usr/bin/ld: cannot find -lungif collect2: error: ld returned 1 exit status Hi, David and Rodolfo, wdm does not explicitly link against ungif. Seems that recent 'get-wings-flags' from libwings-dev package (used by wdm) forces that link, WLIBS=-lWINGs -lWUtil -lwraster -ltiff -lXpm -lpng -ljpeg -lungif -lXft -lXext -lXext -lX11 -lm Please use -lgif instead of -lungif (See http://bugs.debian.org/732272 for the details). Also some stuff there may already be added by normal X11 configure checks and in any case -lXext is repeated. Reassigning accordingly Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732666: about libvirt commit 96f9aae6a
Hi, Le 30/12/2013 13:19, Guido Günther a écrit : On Mon, Dec 30, 2013 at 11:23:57AM +0100, phep wrote: Hi, Thank you for packaging libvirt, Since I just hit the problem this morning while upgrading my laptop, I tried applying the changes referenced in the subject line. Alas, as I feared as I read it, the patch does not fix the issue : memory was already in the mount list. Doh - you're right. I forgot to drop it from the default mount list. Fixed now. Thank you for your prompt reply. One still has to add cgroup_enable=memory on the linux cmd line if one does not want to be left with an half-configured libvirt-bin (on jessie, at last). It's by no means half configured - it just doesn't use mem cgroups. Actually it is. If one has mount_cgroups=yes in /etc/default/libvirt-bin (and nothing on the kernel cmdline), updating libvirt-bin results in the following : Paramétrage de libvirt-bin (1.2.0-1) ... [ ok ] Stopping libvirt management daemon: libvirtd not running. [] Starting libvirt management daemon: libvirtdmount: special device cgroup_memory does not exist [warn] Can not mount cgroups layout ... (warning). invoke-rc.d: initscript libvirt-bin, action start failed. dpkg: error processing package libvirt-bin (--configure): le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1 Des erreurs ont été rencontrées pendant l'exécution : libvirt-bin E: Sub-process /usr/bin/dpkg returned an error code (1) Échec de l'installation d'un paquet. Tentative de réparation : Paramétrage de libvirt-bin (1.2.0-1) ... [ ok ] Stopping libvirt management daemon: libvirtd not running. [] Starting libvirt management daemon: libvirtdmount: special device cgroup_memory does not exist [warn] Can not mount cgroups layout ... (warning). invoke-rc.d: initscript libvirt-bin, action start failed. dpkg: error processing package libvirt-bin (--configure): le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1 Des erreurs ont été rencontrées pendant l'exécution : libvirt-bin Appuyez sur Entrée pour continuer. This persists even after one apply your patches. I'm not well versed in the cgroup machinery, but I don't think that the modifications to the init.d script and /etc/default/libvirt-bin you committed change anything for people who do _not_ have cgroup_enable=memory in the kernel cmdline. As far as I can understand the only difference you introduced with those two patches was to create the mount point and call mount for the memory subsystem if cgroup_enable=memory is on the cmdline, but it does not seem to change anything for those who don't have ! I'll try to investigate this more deeply tonight. Cheers, phep -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733624: gnome-settings-daemon: battery power estimation consider only one battery when two are present
Package: gnome-settings-daemon Version: 3.10.1-1 Severity: normal Tags: upstream Dear Maintainer, * What led up to the situation? Having two batteries in same laptop with gnome-settings-daemon 3.10.1 from experimental * What exactly did you do (or not do) that was effective (or ineffective)? When the first battery reach the critical percentage power defined by Gnome, the critical action happens (shutdown/hibernate) even if the second battery is still full. * What was the outcome of this action? The laptop hibernate/shutdown too often. * What outcome did you expect instead? The laptop should use the second battery before applying the critical power action. The solution is to package Gnome 3.10.2, because this commit : https://git.gnome.org/browse/gnome-settings- daemon/commit/?h=gnome-3-10id=6680d0f0812935fa982c2645930e6f0f4c1d93ed fix the bug. Thanks, Adrien -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-settings-daemon depends on: ii dconf-gsettings-backend [gsettings-backend] 0.18.0-1 ii gsettings-desktop-schemas3.10.0-1 ii libc62.17-97 ii libcairo21.12.16-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libcolord1 1.0.5-1 ii libcups2 1.6.4-2 ii libfontconfig1 2.11.0-2 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libgeocode-glib0 3.10.0-1 ii libglib2.0-0 2.38.2-1 ii libgnome-desktop-3-8 3.10.1-2 ii libgtk-3-0 3.10.2-1 ii libgudev-1.0-0 204-5 ii libgweather-3-6 3.10.0-1 ii libibus-1.0-51.5.4-1 ii liblcms2-2 2.2+git20110628-2.3+b1 ii libnotify4 0.7.6-1 ii libnspr4 2:4.10.2-1 ii libnss3 2:3.15.3.1-1 ii libpackagekit-glib2-16 0.8.14-2 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-0 1.36.0-1+b1 ii libpolkit-gobject-1-00.105-4 ii libpulse-mainloop-glib0 4.0-6+b1 ii libpulse04.0-6+b1 ii librsvg2-2 2.40.0-1 ii libupower-glib1 0.9.23-2+b1 ii libwacom20.8-1 ii libx11-6 2:1.6.2-1 ii libxext6 2:1.3.2-1 ii libxfixes3 1:5.0.1-1 ii libxi6 2:1.7.2-1 ii libxkbfile1 1:1.0.8-1 ii libxtst6 2:1.2.2-1 ii nautilus-data3.10.0-1 ii systemd 204-5 Versions of packages gnome-settings-daemon recommends: ii pulseaudio 4.0-6+b1 Versions of packages gnome-settings-daemon suggests: pn gnome-screensavernone ii metacity [x-window-manager] 1:2.34.13-1 ii mutter [x-window-manager]3.10.1-2 ii x11-xserver-utils7.7+1 ii xfwm4 [x-window-manager] 4.10.1-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#733625: new upsteam (2013-12-08)
Package: dokuwiki It would be nice if you could upload the current upstream release to debian. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733567: cookiecutter: please update to 0.7.0
❦ 30 décembre 2013 00:29 CET, Pierre Chifflier pol...@debian.org : Could you update cookiecutter to the latest upstream version (0.7.0) ? It fixes several bugs and add new features. Unfortunately, the source tarball does not include either documentation nor tests. I have requested upstream to include them and to release a new tarball: https://github.com/audreyr/cookiecutter/pull/140 -- Test input for validity and plausibility. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Bug#733626: will always overflow destination buffer
Package: insighttoolkit Version: 3.20.1+git20120521-4 Severity: important Seems there is a buffer overflow: /usr/bin/cmake -E cmake_progress_report /«BUILDDIR»/insighttoolkit-3.20.1+git20120521/obj-i486-linux-gnu/CMakeFiles In file included from /usr/include/stdio.h:937:0, from /«BUILDDIR»/insighttoolkit-3.20.1+git20120521/Utilities/kwsys/SystemInformation.cxx:87: In function 'int sprintf(char*, const char*, ...)', inlined from 'bool itksys::SystemInformationImplementation::RetrieveClassicalCPUIdentity()' at /«BUILDDIR»/insighttoolkit-3.20.1+git20120521/Utilities/kwsys/SystemInformation.cxx:2040:114: /usr/include/i386-linux-gnu/bits/stdio2.h:34:43: warning: call to int __builtin___sprintf_chk(char*, int, unsigned int, const char*, ...) will always overflow destination buffer [enabled by default] __bos (__s), __fmt, __va_arg_pack ()); ^ In function 'int sprintf(char*, const char*, ...)', inlined from 'bool itksys::SystemInformationImplementation::RetrieveClassicalCPUIdentity()' at /«BUILDDIR»/insighttoolkit-3.20.1+git20120521/Utilities/kwsys/SystemInformation.cxx:2041:119: /usr/include/i386-linux-gnu/bits/stdio2.h:34:43: warning: call to int __builtin___sprintf_chk(char*, int, unsigned int, const char*, ...) will always overflow destination buffer [enabled by default] __bos (__s), __fmt, __va_arg_pack ()); ^ In function 'int sprintf(char*, const char*, ...)', inlined from 'bool itksys::SystemInformationImplementation::RetrieveClassicalCPUIdentity()' at /«BUILDDIR»/insighttoolkit-3.20.1+git20120521/Utilities/kwsys/SystemInformation.cxx:2042:123: /usr/include/i386-linux-gnu/bits/stdio2.h:34:43: warning: call to int __builtin___sprintf_chk(char*, int, unsigned int, const char*, ...) will always overflow destination buffer [enabled by default] __bos (__s), __fmt, __va_arg_pack ()); ^ ref: https://buildd.debian.org/status/fetch.php?pkg=insighttoolkitarch=i386ver=3.20.1%2Bgit20120521-4stamp=1388401586 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733627: ca-certificates: hooks don't get all the CAs
Package: ca-certificates Version: 20130119 Severity: normal Dear Maintainer, After adding ca-certificates-java I found that a locally installed ca (/usr/local/share/ca-certificates/whatever.crt) was not being added to the java keystore, I looked at the passed added certs (even then running update-ca-certificates -f) on the stdin of the hook and saw that this cert was not listed. Running with --verbose I can see the local CA under the: Updating certificates in /etc/ssl/certs... message, but it is not counted as added or written to the tmp file that then gets catted to the stdin of the hooks, thus it is not listed as beeing replaced by the java hook. The only way I got it added to the java certs was by removing all the symlinks to the CA out of /etc/ssl/certs/ It was then that the count for added stuff jumped from 158 to 159 and I was shown by the hook a message saying: Replacing debian:whatever.pem Regards. -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'oldstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ca-certificates depends on: ii debconf [debconf-2.0] 1.5.49 ii openssl1.0.1e-2 ca-certificates recommends no packages. ca-certificates suggests no packages. -- debconf information: ca-certificates/title: * ca-certificates/enable_crts: cacert.org/cacert.org.crt, debconf.org/ca.crt, mozilla/A-Trust-nQual-03.crt, mozilla/ACEDICOM_Root.crt, mozilla/AC_Raíz_Certicámara_S.A..crt, mozilla/Actalis_Authentication_Root_CA.crt, mozilla/AddTrust_External_Root.crt, mozilla/AddTrust_Low-Value_Services_Root.crt, mozilla/AddTrust_Public_Services_Root.crt, mozilla/AddTrust_Qualified_Certificates_Root.crt, mozilla/AffirmTrust_Commercial.crt, mozilla/AffirmTrust_Networking.crt, mozilla/AffirmTrust_Premium.crt, mozilla/AffirmTrust_Premium_ECC.crt, mozilla/America_Online_Root_Certification_Authority_1.crt, mozilla/America_Online_Root_Certification_Authority_2.crt, mozilla/ApplicationCA_-_Japanese_Government.crt, mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt, mozilla/Baltimore_CyberTrust_Root.crt, mozilla/Buypass_Class_2_CA_1.crt, mozilla/Buypass_Class_2_Root_CA.crt, mozilla/Buypass_Class_3_CA_1.crt, mozilla/Buypass_Class_3_Root_CA.crt, mozilla/CA_Disig.crt, mozilla/CNNIC_ROOT.cr t, mozilla/COMODO_Certification_Authority.crt, mozilla/COMODO_ECC_Certification_Authority.crt, mozilla/Camerfirma_Chambers_of_Commerce_Root.crt, mozilla/Camerfirma_Global_Chambersign_Root.crt, mozilla/Certigna.crt, mozilla/Certinomis_-_Autorité_Racine.crt, mozilla/Certplus_Class_2_Primary_CA.crt, mozilla/Certum_Root_CA.crt, mozilla/Certum_Trusted_Network_CA.crt, mozilla/Chambers_of_Commerce_Root_-_2008.crt, mozilla/ComSign_CA.crt, mozilla/ComSign_Secured_CA.crt, mozilla/Comodo_AAA_Services_root.crt, mozilla/Comodo_Secure_Services_root.crt, mozilla/Comodo_Trusted_Services_root.crt, mozilla/Cybertrust_Global_Root.crt, mozilla/DST_ACES_CA_X6.crt, mozilla/DST_Root_CA_X3.crt, mozilla/Deutsche_Telekom_Root_CA_2.crt, mozilla/DigiCert_Assured_ID_Root_CA.crt, mozilla/DigiCert_Global_Root_CA.crt, mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, mozilla/Digital_Signature_Trust_Co._Global_CA_1.crt, mozilla/Digital_Signature_Trust_Co._Global_CA_3.crt, mozilla/E-Guven_Kok_Elektronik_Sertifika_Hiz met_Saglayicisi.crt, mozilla/EBG_Elektronik_Sertifika_Hizmet_Sağlayıcısı.crt, mozilla/EC-ACC.crt, mozilla/EE_Certification_Centre_Root_CA.crt, mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt, mozilla/Entrust.net_Secure_Server_CA.crt, mozilla/Entrust_Root_Certification_Authority.crt, mozilla/Equifax_Secure_CA.crt, mozilla/Equifax_Secure_Global_eBusiness_CA.crt, mozilla/Equifax_Secure_eBusiness_CA_1.crt, mozilla/Equifax_Secure_eBusiness_CA_2.crt, mozilla/Firmaprofesional_Root_CA.crt, mozilla/GTE_CyberTrust_Global_Root.crt, mozilla/GeoTrust_Global_CA.crt, mozilla/GeoTrust_Global_CA_2.crt, mozilla/GeoTrust_Primary_Certification_Authority.crt, mozilla/GeoTrust_Primary_Certification_Authority_-_G2.crt, mozilla/GeoTrust_Primary_Certification_Authority_-_G3.crt, mozilla/GeoTrust_Universal_CA.crt, mozilla/GeoTrust_Universal_CA_2.crt, mozilla/GlobalSign_Root_CA.crt, mozilla/GlobalSign_Root_CA_-_R2.crt, mozilla/GlobalSign_Root_CA_-_R3.crt, mozilla/Global_Chambersign_Root_-_2008.crt, mozilla/Go_Daddy_Class_2_CA.crt, mozilla/Go_Daddy_Root_Certificate_Authority_-_G2.crt, mozilla/Hellenic_Academic_and_Research_Institutions_RootCA_2011.crt, mozilla/Hongkong_Post_Root_CA_1.crt, mozilla/IGC_A.crt, mozilla/Izenpe.com.crt, mozilla/Juur-SK.crt, mozilla/Microsec_e-Szigno_Root_CA.crt, mozilla/Microsec_e-Szigno_Root_CA_2009.crt,
Bug#733628: Underlinked library
Package: insighttoolkit4 Severity: grave Tags: patch By policy shared lib should not be underlinked. Please fix NrrdIO: dpkg-shlibdeps: warning: symbol sqrt used by debian/libinsighttoolkit4.5/usr/lib/libITKNrrdIO-4.5.so.1 found in none of the libraries There is a missing -lm ref: https://buildd.debian.org/status/fetch.php?pkg=insighttoolkit4arch=i386ver=4.5.0-1stamp=1388355262 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733630: task-gnome-desktop: This task should include the task-print-server.
Package: task-gnome-desktop Version: 3.18 Severity: normal Since gnome-control-center has a button for printer setup this task should be included by default. Otherwise the functionality is missing.I am not sure if this should be filed against the gnome-control-center itself, if so please redirect the bug. In general this would apply for bluetooth as well, but since printers are so much more common I am only commenting on this. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 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 task-gnome-desktop depends on: ii gnome-core1:3.8+4 ii task-desktop 3.18 ii tasksel 3.18 Versions of packages task-gnome-desktop recommends: ii gimp2.8.6-1 ii gnome 1:3.8+4 pn hunspell-en-us none pn hyphen-en-usnone ii iceweasel 17.0.10esr-1~deb7u1 pn libreoffice none pn libreoffice-evolution none pn libreoffice-gcj none ii libreoffice-gnome 1:4.1.3-1+b1 pn libreoffice-help-en-us none pn mythes-en-usnone ii network-manager-gnome 0.9.8.4-1 pn synapticnone task-gnome-desktop suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd jessie - jessie+1 upgrade problems
* Josselin Mouette: Le mardi 17 décembre 2013 à 12:26 -0800, Russ Allbery a écrit : Is there actually any implementation other than glib2.0 and libdbus that would be affected by a switch to kdbus? This is an interesting question. Josselin, is GNOME (for example) likely to acquire a hard dependency on kdbus through some mechanism? I don't understand the plumbing of this stuff well enough to know where the dependencies could surface. That doesn’t seem very likely to me. In terms of library API, kdbus doesn’t change anything, so there is no need for applications to depend on it. Isn't it fairly likely that some libraries or applications will use kdbus directly because their developers dislike the existing libraries? It happens all the time with other kernel functionality (inotify and its cousins, netlink, etc.). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733564: pu: apache2 with ECDHE support
On Mon, Dec 30, 2013 at 01:41:31PM +0100, Cyril Brulebois wrote: Stefan Fritsch s...@sfritsch.de (2013-12-30): Am Sonntag, 29. Dezember 2013, 23:58:54 schrieb Kurt Roeckx: Adding ECDHE support in apache will probably require backporting the patches for that. I'm not sure how much work that is going to be and wether someone like redhat might have already done that. I don't know how quickly upgrades are ususally adopted in MacOS land, but considering that 10.8.5 is out I think it would be even acceptable to update apache without that openssl workaround, as long as the readme contains exact instructions how to disable ECDHE in case of problems. But of course having the openssl workaround would be even better. If we're going to end up adding ECDHE support, and if it isn't supported everywhere yet, I'm pretty sure support for it all shouldn't be enabled automatically upon upgrades, and that it should be enabled manually by admins instead, following instructions that include incompatibility warnings (hello, page 51 of the draft at https://bettercrypto.org/). If you want an overview of what browser support, you can see see that on ssllabs. The only way I know of getting that info for other browser is going to a random website and then selecting the browser. About the only thing not supporting ECDHE is java 6 and internet explorer on windows XP. Internet explorer is also the only one that doesn't have ECDHE (or even DHE) at the top the prefered ciphers. That means that all other browser that are tracked there have support for ECDHE and have it as most prefered cipher. MacOS had a problem with the ECDSA version of it, which seems surprisingly popular, but it was fixed. But I was under the impression that apple didn't encourage users to upgrade when it was fixed. I'm not sure if that changed in the mean time. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733629: Convenient lib: double-conversion
Package: insighttoolkit4 Please use the system installed double-conversion lib: http://packages.debian.org/fr/source/sid/double-conversion instead of the convenient lib. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733631: ksh: octal support in arithmetic evaluation breaks ksh compatibility
Package: ksh Version: 93u+20120801-1 Severity: normal ksh93 and mksh behave differently: xvii% ksh93 -c 'echo $((010))' 8 xvii% mksh -c 'echo $((010))' 10 breaking the needed compatibility with each other since they are both /bin/ksh alternatives, and valid #!/bin/ksh scripts should behave consistently with both shells. According to Thorsten Glaser (the mksh maintainer), the bug is in ksh93[*]: |ksh93 can break scripts with #!/bin/ksh because interpreting |leading-digit-zero numbers as octal is a *very* recent change, |and is *known* to break existing scripts. Not the other way round. [*] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732509#25 Note: ksh can still have some POSIX compatibility mode when run as sh, like other shells like mksh (actually the lksh version), bash and zsh. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ksh depends on: ii libc6 2.17-97 ksh recommends no packages. ksh 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#733632: mpv: FTBFS on mips/mipsel/powerpc/sparc: undefined reference to `__sync_add_and_fetch_8'
Package: mpv
Version: 0.3.0-1
Severity: serious
Tags: upstream patch
Justification: fails to build from source (but built successfully in the past)
mpv fails to build from source on mips/mipsel/powerpc/sparc with the
following error message:
| [243/243] linking - build/mpv
| common/msg.c.10.o: In function `mp_msg_update_msglevels':
| /«PKGBUILDDIR»/build/../common/msg.c:243: undefined reference to
`__sync_add_and_fetch_8'
| collect2: error: ld returned 1 exit status
| Waf: Leaving directory `/«PKGBUILDDIR»/build'
| Build failed
The problem is that the new version of mpv tries to uses 64-bit GCC
legacy atomic builtins [1], which are not all available on all
architectures.
The solution to this problem is to use the new GCC atomics, similar
to the C11 ones [2]. For that you need GCC 4.8, which is unfortunately
not the default on all architectures, and to link with libatomic. The
later library provides a fallback implementation if a given atomic bultin
is not available natively, which is usually the case for 64-bit atomics
on 32-bit platforms.
The patch below implements that and should fix the problem, though I
have only tested it on mips so far.
[1] http://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html
[2] http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
--- mpv-0.3.0/debian/control
+++ mpv-0.3.0/debian/control
@@ -45,7 +45,8 @@
pkg-config,
python,
python-docutils,
- yasm
+ yasm,
+ gcc-4.8
Standards-Version: 3.9.5
Homepage: http://mpv.io/
Vcs-Git: git://anonscm.debian.org/pkg-multimedia/mpv.git
--- mpv-0.3.0/debian/patches/04_gcc-atomic.diff
+++ mpv-0.3.0/debian/patches/04_gcc-atomic.diff
@@ -0,0 +1,21 @@
+--- mpv-0.3.0/compat/atomics.h
mpv-0.3.0/compat/atomics.h
+@@ -20,4 +20,4 @@
+ // time. We only support a full memory barrier.
+
+ #define mp_memory_barrier() __sync_synchronize()
+-#define mp_atomic_add_and_fetch(a, b) __sync_add_and_fetch(a, b)
++#define mp_atomic_add_and_fetch(a, b) __atomic_fetch_add(a, b,
__ATOMIC_SEQ_CST)
+--- mpv-0.3.0/wscript
mpv-0.3.0/wscript
+@@ -104,6 +104,10 @@ main_dependencies = [
+ 'deps': [ 'pthreads' ],
+ 'func': check_cc(lib='rt')
+ }, {
++'name': 'libatomic',
++'desc': 'linking with -latomic',
++'func': check_cc(lib='atomic')
++}, {
+ 'name': '--iconv',
+ 'desc': 'iconv',
+ 'func': check_iconv,
--- mpv-0.3.0/debian/patches/series
+++ mpv-0.3.0/debian/patches/series
@@ -1,3 +1,4 @@
01_desktop-path.patch
02_fix-config-path.patch
03_waf.patch
+04_gcc-atomic.diff
--- mpv-0.3.0/debian/rules
+++ mpv-0.3.0/debian/rules
@@ -1,5 +1,7 @@
#!/usr/bin/make -f
+export CC=gcc-4.8
+
%:
dh $@
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: mips (mips64)
Kernel: Linux 3.2.0-4-5kc-malta
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733633: arpwatch uses 100% CPU and does not log any addresses
Package: arpwatch
Version: 2.1a15-1.2
Severity: important
Dear Maintainer,
after the start arpwatch uses 100% CPU and does not log any
addresses to /var/lib/arpwatch/arp.dat:
-rw-r- 1 arpwatch root 0 2013-12-30 14:53 /var/lib/arpwatch/arp.dat
A trace of arpwatch is attached (strace /usr/sbin/arpwatch -d).
This behavior is reproducible on every start, only the number
of calls to poll at the end of the trace differs (from one to
several).
Regards
Uwe
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (750, 'testing'), (650, 'unstable'), (1, 'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 3.9-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 arpwatch depends on:
ii adduser 3.113+nmu3
ii libc6 2.17-97
ii libpcap0.8 1.5.2-1
arpwatch recommends no packages.
arpwatch suggests no packages.
-- debconf-show failed
execve(/usr/sbin/arpwatch, [/usr/sbin/arpwatch, -d], [/* 18 vars */]) = 0
brk(0) = 0x9336000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf76f9000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=199715, ...}) = 0
mmap2(NULL, 199715, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf76c8000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/i386-linux-gnu/i686/cmov/libresolv.so.2, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 '\0\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=79720, ...}) = 0
mmap2(NULL, 92232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf76b1000
mmap2(0xf76c4000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12) = 0xf76c4000
mmap2(0xf76c6000, 6216, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf76c6000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/usr/lib/i386-linux-gnu/libpcap.so.0.8, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=243892, ...}) = 0
mmap2(NULL, 244608, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7675000
mmap2(0xf76af000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3a) = 0xf76af000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/i386-linux-gnu/i686/cmov/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 \232\1\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1763108, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7674000
mmap2(NULL, 1768220, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf74c4000
mmap2(0xf766e000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1aa) = 0xf766e000
mmap2(0xf7671000, 11036, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7671000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf74c3000
set_thread_area({entry_number:-1 - 12, base_addr:0xf74c36c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xf766e000, 8192, PROT_READ) = 0
mprotect(0xf76af000, 4096, PROT_READ) = 0
mprotect(0xf76c4000, 4096, PROT_READ) = 0
mprotect(0x804f000, 4096, PROT_READ)= 0
mprotect(0xf771b000, 4096, PROT_READ) = 0
munmap(0xf76c8000, 199715) = 0
socket(PF_NETLINK, SOCK_RAW, 0) = 3
bind(3, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
getsockname(3, {sa_family=AF_NETLINK, pid=10704, groups=}, [12]) = 0
time(NULL) = 1388413817
sendto(3, \24\0\0\0\22\0\1\3y\203\301R\0\0\0\0\0\0\0\0, 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{\f\4\0\0\20\0\2\0y\203\301R\320)\0\0\0\0\4\3\1\0\0\0I\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 2080
brk(0) = 0x9336000
brk(0x9357000) = 0x9357000
recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{\24\0\0\0\3\0\2\0y\203\301R\320)\0\0\0\0\0\0\1\0\0\0I\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
sendto(3, \24\0\0\0\26\0\1\3z\203\301R\0\0\0\0\0\0\0\0, 20, 0,
{sa_family=AF_NETLINK, pid=0,
