Bug#657116: libtar: FTBFS on hurd-i386
Hi again. Is there a new upstream version planned soon fixing this build problem, or is it better to patch the Debian package? -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738808: libbeansbinding-java: Wrong upstream Homepage URL
Please note the tailing / breaks the link. You may change the http://beansbinding.dev.java.net/ to http://beansbinding.dev.java.net and the link will work. Thanks :כתב Emmanuel Bourg, 2014-02-13 09:51 בתאריך Le 13/02/2014 08:22, Matanya Moses a écrit : libbeansbinding-java Homepage in the control file should point at https://java.net/projects/beansbinding/ instead of the wrong http://beansbinding.dev.java.net/ which is currently in use http://beansbinding.java.net works too. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689207: rust: changing back from ITP to RFP
Hi, Any news on rust packaging? Riku -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738817: winbind doesn't permitt offline logon anymore
Package: winbind Version: 2:4.1.4+dfsg-3 Severity: normal Dear Maintainer, offline logon doesn't works any more. If you configure winbind in offline logon if there is no network connection the logon fails even if the password is correct. These are the logs in auth.log when there is no network connection: Feb 13 08:47:02 psala-lx2 gdm3][3380]: pam_unix(gdm3:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=DOMINIOCSA\psala Feb 13 08:47:02 psala-lx2 gdm3][3380]: pam_winbind(gdm3:auth): getting password (0x4388) Feb 13 08:47:02 psala-lx2 gdm3][3380]: pam_winbind(gdm3:auth): pam_get_item returned a password Feb 13 08:47:02 psala-lx2 gdm3][3380]: pam_winbind(gdm3:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_SYSTEM_ERR (4), NTSTATUS: NT_STATUS_INVALID_PARAMETER, Error message was: Unexpected information received Feb 13 08:47:02 psala-lx2 gdm3][3380]: pam_winbind(gdm3:auth): internal module error (retval = PAM_SYSTEM_ERR(4), user = 'DOMINIOCSA\psala') Then I have plug the network cable and restart winbind: Feb 13 08:47:37 psala-lx2 sshd[2646]: Received signal 15; terminating. Feb 13 08:47:37 psala-lx2 sshd[3696]: Server listening on 0.0.0.0 port 22. Feb 13 08:47:37 psala-lx2 sshd[3696]: Server listening on :: port 22. Feb 13 08:47:47 psala-lx2 sudo: administrator : TTY=tty2 ; PWD=/home/administrator ; USER=root ; COMMAND=/usr/sbin/service winbind restart Feb 13 08:47:47 psala-lx2 sudo: pam_unix(sudo:session): session opened for user root by administrator(uid=0) Feb 13 08:47:50 psala-lx2 sudo: pam_unix(sudo:session): session closed for user root And the logon now is successfully: Feb 13 08:48:01 psala-lx2 gdm3][3805]: pam_unix(gdm3:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=DOMINIOCSA\psala Feb 13 08:48:01 psala-lx2 gdm3][3805]: pam_winbind(gdm3:auth): getting password (0x4388) Feb 13 08:48:01 psala-lx2 gdm3][3805]: pam_winbind(gdm3:auth): pam_get_item returned a password Feb 13 08:48:01 psala-lx2 gdm3][3805]: pam_winbind(gdm3:auth): user 'DOMINIOCSA\psala' granted access Feb 13 08:48:01 psala-lx2 gdm3][3805]: pam_unix(gdm3:session): session opened for user DOMINIOCSA\psala by (uid=0) Feb 13 08:48:01 psala-lx2 gdm3][3805]: pam_ck_connector(gdm3:session): nox11 mode, ignoring PAM_TTY :0 Feb 13 08:48:01 psala-lx2 gdm-launch-environment][2733]: pam_unix(gdm-launch- environment:session): session closed for user Debian-gdm Feb 13 08:48:01 psala-lx2 polkitd(authority=local): Unregistered Authentication Agent for unix-session:/org/freedesktop/ConsoleKit/Session1 (system bus name :1.26, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale it_IT.UTF-8) (disconnected from bus) This is my smb.conf: [global] workgroup = DOMINIOCSA server string = %h server (Samba, Ubuntu) security = DOMAIN allow trusted domains = No map to guest = Bad User obey pam restrictions = Yes pam password change = Yes passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . unix password sync = Yes syslog = 0 log file = /var/log/samba/log.%m max log size = 1000 dns proxy = No usershare allow guests = Yes panic action = /usr/share/samba/panic-action %d template shell = /bin/bash winbind enum users = Yes winbind enum groups = Yes winbind offline logon = Yes idmap config DOMINIOCSA : range = 1-25000 idmap config DOMINIOCSA : backend = rid idmap config * : range = 1-25000 idmap config * : backend = tdb If you need some more infos please ask but consider this bug: offline logon can be very usefull for mobile users! Piviul -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages winbind depends on: ii libbsd0 0.6.0-1 ii libc6 2.17-97 ii libcomerr2 1.42.9-3 ii libkrb5-26-heimdal 1.6~git20131207+dfsg-1 ii libldap-2.4-2 2.4.31-1+nmu2+b1 ii libpopt01.16-8 ii libtalloc2 2.1.0-1 ii libtdb1 1.2.12-1 ii libtevent0 0.9.19-1 ii libwbclient02:4.1.4+dfsg-3 ii multiarch-support 2.17-97 ii samba 2:4.1.4+dfsg-3 ii samba-libs 2:4.1.4+dfsg-3 winbind recommends no packages. Versions of packages winbind suggests: ii libnss-winbind 2:4.1.4+dfsg-3 ii libpam-winbind 2:4.1.4+dfsg-3 -- 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#689207: rust: changing back from ITP to RFP
On 13/02/2014 09:08, Riku Voipio wrote: Hi, Any news on rust packaging? Riku Yes, Luca is touch with ftp master regarding the bootstrap issue, we are discussing with upstream on the llvm patches and we have the agreement from Mozilla GSoC admin to propose a gsoc on the packaging of rust. Cheers, Sylvestre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738816: tortoisehg: not installable in sid, needs to migrate to mercurial 2.9
Package: tortoisehg Version: 2.10-1 Severity: serious User: trei...@debian.org Usertags: edos-outdated Affects: tortoisehg-nautilus tortoisehg is currently not installabe in sid since it depends on mercurial (= 2.7~), mercurial ( 2.9~) However, the version of mercurial in sid is 2.9-1 (since 2014-02-10). Since the dependency is hard-coded in debian/control this requires a sourceful upload. Cheers -Ralf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738818: ITP: r-other-amsmercury -- efficient calculation of accurate masses and abundances of isotopic peaks
Package: wnpp Severity: wishlist Owner: Andreas Tille ti...@debian.org * Package name: r-other-amsmercury Version : 1.3.0 Upstream Author : Marc Kirchner marc.kirch...@iwr.uni-heidelberg.de * URL : http://hci.iwr.uni-heidelberg.de/MIP/Software/nitpick.php * License : LGPL Programming Lang: R Description : efficient calculation of accurate masses and abundances of isotopic peaks This GNU R package provides fficient calculation of accurate masses and abundances of isotopic peaks. It is a precondition for R NITPICK which does peak identification for mass spectrometry data. Remark: This package is maintained by the DebiChem team as a precondition for r-other-nitpick. The packaging is available at git://anonscm.debian.org/debichem/packages/r-other-amsmercury.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738820: bopm: Wrong upstream Homepage URL
Package: bopm Severity: minor bopm Homepage in the control file should point at http://sourceforge.net/projects/bopm/ instead of the wrong http://wiki.blitzed.org/BOPM which is currently in use -- System Information: Debian Release: 6.0.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) 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#738819: emacs24: During installation: gforth.el:742:18:Error: Don't know how to compile nil
Package: emacs24 Version: 24.3+1-2+b1 Severity: normal $ LC_ALL=C apt-get install Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up emacs24 (24.3+1-2+b1) ... Install cmake-data for emacs24 install/cmake-data: Byte-compiling for emacs24 ln: failed to create symbolic link '/usr/share/emacs24/site-lisp/cmake-data /cmake-mode.el': File exists Wrote /usr/share/emacs24/site-lisp/cmake-data/cmake-mode.elc Install dictionaries-common for emacs24 install/dictionaries-common: Already byte-compiled for emacs24. Skipping ... Install emacsen-common for emacs24 emacsen-common: Handling install of emacsen flavor emacs24 Wrote /etc/emacs24/site-start.d/00debian-vars.elc Wrote /usr/share/emacs24/site-lisp/debian-startup.elc Install gforth for emacs24 install/gforth: Byte-compiling for emacsen flavour emacs24 In toplevel form: gforth.el:742:18:Error: Don't know how to compile nil gforth.el:742:18:Error: Don't know how to compile nil gforth.el:742:18:Error: Don't know how to compile nil gforth.el:742:18:Error: Don't know how to compile nil gforth.el:742:18:Error: Don't know how to compile nil ERROR: install script from gforth package failed dpkg: error processing package emacs24 (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: emacs24 E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/4 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 emacs24 depends on: ii emacs24-bin-common 24.3+1-2+b1 ii gconf-service3.2.6-1 ii libasound2 1.0.27.2-3 ii libatk1.0-0 2.10.0-2 ii libc62.17-97 ii libcairo-gobject21.12.16-2 ii libcairo21.12.16-2 ii libdbus-1-3 1.8.0-1 ii libfontconfig1 2.11.0-2 ii libfreetype6 2.5.2-1 ii libgconf-2-4 3.2.6-1 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libgif4 4.1.6-11 ii libglib2.0-0 2.36.4-1 ii libgnutls26 2.12.23-10+b1 ii libgomp1 4.8.2-14 ii libgpm2 1.20.4-6.1 ii libgtk-3-0 3.8.6-1 ii libice6 2:1.0.8-2 ii libjpeg8 8d-2 ii libm17n-01.6.4-2 ii libmagickcore5 8:6.7.7.10-7 ii libmagickwand5 8:6.7.7.10-7 ii libotf0 0.9.13-1 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-0 1.36.0-1+b1 ii libpng12-0 1.2.50-1 ii librsvg2-2 2.40.0-1 ii libselinux1 2.2.2-1 ii libsm6 2:1.2.1-2 ii libtiff5 4.0.3-7 ii libtinfo55.9+20140118-1 ii libx11-6 2:1.6.2-1 ii libxft2 2.3.1-2 ii libxml2 2.9.1+dfsg1-3 ii libxpm4 1:3.5.10-1 ii libxrender1 1:0.9.8-1 ii zlib1g 1:1.2.8.dfsg-1 emacs24 recommends no packages. Versions of packages emacs24 suggests: pn emacs24-common-non-dfsg 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#738821: nmu: usb-modeswitch_2.1.0+repack0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi dear Release Team, the new version of src:jimtcl just went out of NEW, building a new libjim0.74, replacing libjim0debian2 with a new (upstream, yay) SONAME. The only reverse-build-depend of libjim-dev is usb-modeswitch, making this a lightweight transition. Therefore, please schedule binNMUs for usb-modeswitch as follows: nmu usb-modeswitch_2.1.0+repack0-1 . ALL . -m Rebuild against new libjim dw usb-modeswitch_2.1.0+repack0-1 . ALL . -m libjim-dev (= 0.74) (I've tested that usb-modeswitch compiles and runs against the new libjim, on amd64.) Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738822: bsl: Wrong upstream Homepage URL
Package: bsl Severity: minor bsl Homepage in the control file should point at http://buzztrax.org/ instead of the wrong http://www.buzztard.org/ which is currently in use -- System Information: Debian Release: 6.0.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) 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#738823: buzztard: Wrong upstream Homepage URL
Package: buzztard Version: Wrong upstream Homepage URL Severity: minor buzztard Homepage in the control file should point at http://buzztrax.org/ instead of the wrong http://www.buzztard.org/ which is currently in use -- System Information: Debian Release: 6.0.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) 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#738824: ITP: r-other-iwrlars -- least angle regression, lasso, positive lasso and forward stagewise
Package: wnpp Severity: wishlist Owner: Andreas Tille ti...@debian.org * Package name: r-other-iwrlars Version : 0.9-5 Upstream Author : Marc Kirchner marc.kirch...@iwr.uni-heidelberg.de * URL : http://hci.iwr.uni-heidelberg.de/MIP/Software/nitpick.php * License : LGPL Programming Lang: R Description : least angle regression, lasso, positive lasso and forward stagewise This GNU R package provides efficient procedures for fitting an entire lasso sequence with the cost of a single least squares fit. Least angle regression and infinitessimal forward stagewise regression are related to the lasso described in http://www-stat.stanford.edu/~hastie/Papers/#LARS. . This is a modified version of the original lars package by Hastie and Efron, providing a LARS modification for non-negative lasso. Remark: This package is a precondition for r-other-nitpick and thus also maintained by the DebiChem team. The packaging is available at git://anonscm.debian.org/debichem/packages/r-other-iwrlars.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738825: camorama: Wrong upstream Homepage URL
Package: camorama Severity: minor camorama Homepage in the control file should point at https://git.gnome.org/browse/camorama/ instead of the wrong http://camorama.fixedgear.org/ which is currently in use -- System Information: Debian Release: 6.0.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) 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#738811: handbrake: crashes after source DVD is selected
Am Donnerstag, den 13.02.2014, 08:37 +0100 schrieb Jan Korous: I have tried 2 different DVDs which I was able to play at the same machine without a glitch. Could you please try again with the libdvdcss2 package installed? - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738765: boot.img in daily image files exceed 10mb limit
Control: reassign -1 debian-installer 20140212+deb7u1.b2
On Mi, 12 feb 14, 14:14:28, Shinn, Rob wrote:
Package: debian-installer-netboot-sparc
Version: 20140212+deb7u1.b2
When booting any of the current SPARC boot.img files on d-i.debian.org/daily-
images on my SunFire V240, via either rarpd+tftpd or using a dnsmaq-based
DCHP
setup, I get:
{1} ok boot net
Boot device: /pci@1f,70/network@2 File and args:
1000 Mbps FDX Link up
Requesting Internet Address for 0:3:ba:xx:xx:xx
Requesting Internet Address for 0:3:ba:xx:xx:xx
ERROR: /packages/obp-tftp: Last Trap: Fast Data Access MMU Miss
According to this thread;
http://comments.gmane.org/gmane.linux.debian.ports.sparc/14994
This happens because boot.img exceed a magic 10mb limit. This problem does
not occur with the boot.img file from Wheezy, which is under the magic 10mb
limit.
--
Rob Shinn rsh...@e-one.com
E-ONE IT | Sr. Unix Systems Engineer | W: 352-861-3256 | M: 352-286-7716
1701 S.W. 37th Ave., Ocala, FL 34474
--
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#728085: Pyfftw does not build
Hi Ghislain,
On Thu, Feb 13, 2014 at 08:33:08AM +, Ghislain Vaillant wrote:
I too experience this error when using pbuilder. It builds fine however if
I install the required dependencies on my machine and then run pbuilder. If
any of them are missing, for instance the -dbg packages, then pbuilder
fails.
pbuilder:
dpkg-checkbuilddeps: Unmet build dependencies: cython-dbg cython3-dbg
python-all-dbg python-numpy-dbg python3-numpy-dbg
...
E: pybuild pybuild:256: clean: plugin distutils failed with: exit code=1:
python2.7-dbg setup.py clean
dh_auto_clean: pybuild --clean -i python{version}-dbg -p 2.7 --dir .
returned exit code 13
make: *** [clean] Error 13
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit
status 2
I am not familiar enough with pbuilder to debug this. All I did was follow
the ubuntu wiki page about setting-up pbuilder. It worked like a charm with
linop, but it was a simple case without compiled extensions. For this
however, it is different somehow. If anyone has any idea what's going on,
please feel free to help.
I admit if I would have had a quick clue I would have provided it
immediately. Despite I'm using pbuilder basically all the time I never
experienced this problem ... most probably since I never added any *-dbg
package to the Build-Dependencies which is IMHO totally void. Do you
have any reason for this?
So I would recommend:
$ git diff
diff --git a/debian/control b/debian/control
index b272bae..dfc2428 100644
--- a/debian/control
+++ b/debian/control
@@ -6,18 +6,13 @@ Priority: optional
Build-Depends: cython,
cython-dbg,
cython3,
- cython3-dbg,
debhelper (= 9),
libfftw3-dev (= 3.3),
libjs-jquery,
- python-all-dbg,
python-all-dev,
python-numpy,
- python-numpy-dbg,
- python3-all-dbg,
python3-all-dev,
python3-numpy,
- python3-numpy-dbg,
quilt
Standards-Version: 3.9.5
Vcs-Browser:
http://anonscm.debian.org/gitweb/?p=debian-science/packages/pyfftw.git
in any case.
When speaking about Build-Depends: Please also remove quilt from
Build-Depends *and* from debian/rules (--with ...,quilt). This is
redundant when using debian/source/format 3.0 (quilt).
After applying the patch above the package does not yet build since it
runs into:
'build/scripts-2.7' does not exist -- can't clean it
pybuild --clean -i python{version} -p 3.3 --dir .
I: pybuild base:170: python3.3 setup.py clean
Traceback (most recent call last):
File setup.py, line 25, in module
import numpy
ImportError: No module named 'numpy'
E: pybuild pybuild:256: clean: plugin distutils failed with: exit code=1:
python3.3 setup.py clean
if on the building machine the packages python-numpy *and* python3-numpy
are missing. I have no idea how autobuild machines are dealing with
this but I'd recommend asking for advise at the
debian-pyt...@lists.debian.org mailing list how to sensibly tweak your
clean target to only clean if necessary and prevent setup.py from
doing useless things.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738801: cups: /etc/init.d/cups stop/start hang when systemd is installed
-=| Nye Liu, 12.02.2014 17:51:19 -0800 |=- Package: cups Version: 1.7.1-4 Severity: important Dear Maintainer, * What led up to the situation? running /etc/init.d/cups stop or start (for example, as root, or by logrotate) * What exactly did you do (or not do) that was effective (or ineffective)? with cups running: # /etc/init.d/cups stop with cups not running: # /etc/init.d/cups start * What was the outcome of this action? # /etc/init.d/cups stop [] Stopping cups (via systemctl): cups.service hangs indefinitely If I kill it by hand, then # /etc/init.d/cups start [] Starting cups (via systemctl): cups.service hangs indefinitely * What outcome did you expect instead? The cups daemon should start/stop as expected. Also, systemctl start/stop cups.service acts the same. Here's some additional info: In my case when aptitude is truing to configure cups-daemon, there is a hang that lasts for some 10 minutes, then things fail: Setting up cups-daemon (1.7.1-4) ... Job for cups.service failed. See 'systemctl status cups.service' and 'journalctl -xn' for details. invoke-rc.d: initscript cups, action start failed. dpkg: error processing package cups-daemon (--configure): subprocess installed post-installation script returned error exit status 1 If I try to start cups-daemon by hand, it fails immediately: $ sudo service cups-daemon start ~ Failed to issue method call: Unit cups-daemon.service failed to load: No such file or directory. See system logs and 'systemctl status cups-daemon.service' for details. $ sudo systemctl status cups-daemon.service ~ cups-daemon.service Loaded: error (Reason: No such file or directory) Active: inactive (dead) Heh, fiddling with /etc/init.d/cups I purged xprint-common and this seems to have fixed the cups problem: $ sudo dpkg -P xprint-common ~ (Reading database ... 491921 files and directories currently installed.) Removing xprint-common (2:1.4.2-11) ... Purging configuration files for xprint-common (2:1.4.2-11) ... $ sudo dpkg --configure -a ~ Setting up man-db (2.6.6-1) ... Updating database of manual pages ... Setting up cups-daemon (1.7.1-4) ... - this was hanging/failing before Setting up cups-core-drivers (1.7.1-4) ... Setting up cups (1.7.1-4) ... Updating PPD files for cups ... Updating PPD files for cups-filters ... Updating PPD files for cups-pdf ... Updating PPD files for foomatic-db ... Updating PPD files for foomatic-db-engine ... Updating PPD files for hpcups ... Updating PPD files for postscript-hp ... I hope this helps to pinpoint the problem. -- dam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738801: cups: /etc/init.d/cups stop/start hang when systemd is installed
Control: tags -1 +unreproducible +moreinfo Hi Nye, and thanks for your bugreport, Le mercredi, 12 février 2014, 17.51:19 Nye Liu a écrit : * What led up to the situation? running /etc/init.d/cups stop or start (for example, as root, or by logrotate) * What was the outcome of this action? # /etc/init.d/cups stop [] Stopping cups (via systemctl): cups.service hangs indefinitely Note that for administrators, the proper interface is service, not /etc/init.d, as the former makes sure that the environment is sanitized, but that doesn't seem to be the problem. I can't reproduce this here, with systemd as init. If I kill it by hand, then # /etc/init.d/cups start [] Starting cups (via systemctl): cups.service hangs indefinitely Can you post excerpts of /var/log/syslog and /var/log/cups/error_log from around when you start and stop cups? Thanks in advance, cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678863: Intent To Package
Hey, Sorry for the bad English. I will maintaining this package. I'm new and have low experience about building a package. greetings Dirk Finkeldey -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738826: how-can-i-help: modify control a bit to allow use in stable (wheezy)
Package: how-can-i-help Version: 4 Severity: wishlist Dear Maintainer, I tried and succeed in building a usable backport for wheezy One just need to match wheezy versions in two depends: - ruby-debian (= 0.3.8+b1) instead of 0.3.8+b2 - ruby-json (= 1.7.3-3) instead of 1.8.0-1 However I may have miss the reason why those depends were that way. Thanks, igor -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.12-0.bpo.1-686-pae (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/dash -- 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 coupling etc.
Hi there, Preface: I'm not involved with the Debian project directly other than as a user. So while I personally have strong opinions when it comes to the init system, so far I have just followed the debate because I didn't feel it would be helpful to spam this bug with useless comments. That said, I have thought about the coupling issue for quite a while now and I firmly believe that the original L and T options are BOTH explicitly harmful (in different ways). For this reason, I feel the need to express my opinion on this subject. But after I have said my piece, unless there is a need for clarification on my side, I will walk back to the sidelines and continue to watch. First of all, I do think there are legitimate concerns that lead to both the T and L options. On the one hand, the L text is clearly motivated by the worry that if a huge part of the Debian ecosystem (*cough* GNOME *cough*) suddenly depends on a specific init system (*cough* systemd *cough*) then the commitment to multiple init systems gets reduced to a farce. People might disagree about whether this is in reality going to become a problem, but I think the concern is legitimate. On the other hand, the T text seems to be motivated by the wish to not hamper progress when it comes to software, that the Debian project should not hold software back because of some ideological reasons. That said, I think both texts are problematic: L being far to extreme in its scope and T being far too toothless in the side sentence about encouragement when it comes to support for other init systems. The problem I have in this discussion is that only a few cases have been picked apart in detail, but the wider implications of these options have been mentioned in passing at best. So for this reason, I'd like to propose several different scenarios where the coupling question applies, so that the consequences of language used in the coupling question becomes clear. So let me draw up a couple of scenarios: (A) Someone writes a GUI for managing systemd that has the goal of providing access to as many features as possible, so that it really is tightly coupled to systemd in that sense. There is no way this could realistically be ported to other init systems. (Although a different software for e.g. upstart could be affected in the same way.) (B) Someone writes a GUI for accessing journald files on the hard drive. (C) Someone writes some kind of framework that depends on advanced systemd features, such as systemd-nspawn, to provide a novel technical solution. This software is new and not yet widely adopted. (Somewhere in the original discussion before all of the ballots, somebody mentioned something akin to this, I just don't feel it makes sense to invest the time to dig that up.) (D) Someone writes a daemon that currently only works with systemd, but a patch for including sysvinit and upstrart support is literally only 5 lines of code. (E) GNOME depends on logind interfaces and there is not working alternative logind (=205) implementation available. (F) GNOME depends on logind interfaces and somebody stepped up and created a logind implementation for other init systems. (G) GNOME starts to depend on systemd as pid1 irrespective of logind. (H) Some software part of the default install set (which currently does not include GNOME but might again in the future) depends on systemd as PID1, either directly (see G) or indirectly via logind with no alternative implementation (see E). I think that both L and T options have undesirable consequences. (To clarify: I consider some of these to be undesirable for Jessie, not necessarily for later releases.) Let me start with T: - Most serious case (H): If any software in the default install set depends on systemd, then this IMHO creates the de-facto situation that there really only is systemd support. Because if you can't switch the init system if you have a default set of software installed, saying that you support multiple init systems is a farce. Therefore, I definitely think that any resolution by the TC should include language that says that any software in the default install set should work with ALL supported init systems (with degraded operation being possible). So in the case of GNOME, if it continues to depend on logind (likely) and there doesn't happen to be a logind implementation that works with all the other init systems (unknown), then that should definitely disqualify GNOME from being made default desktop again. (OTOH, if there IS an alternative logind implementation at the point where this is decided, this doesn't stand in the way of GNOME becoming the default desktop again, but obviously it will also not make GNOME automatically the default desktop, that will depend on other things. ;-)) - Case (G): I don't think this is likely to happen for Jessie, but I do think this should be addressed. Since GNOME is one of the major
Bug#738801: cups: /etc/init.d/cups stop/start hang when systemd is installed
Nye; do you happen to have xprint-common unpurged? (Please paste the result of $ dpkg -l xprint-common) Le jeudi, 13 février 2014, 11.04:16 Damyan Ivanov a écrit : Heh, fiddling with /etc/init.d/cups I purged xprint-common and this seems to have fixed the cups problem: Ha. That looks interesting. There's indeed some xprint handling in cups.init. As xprint disappeared from Debian before Wheezy, I think it's probably safe to drop this handling code from the init script. If Nye can confirm he has the same conditions than you, then that'd be the fix. Damyan: Could you re-install, remove (but not purge) xprint from oldstable, edit your /etc/init.d/cups.init to drop all instances of restart_xprint and see if it works for you? Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738785: aptitude: (remote) changelogs is broken after packages.d.o move to https
Hi Julien, On 13 February 2014 00:26, Julien Cristau jcris...@debian.org wrote: [...] Seems to be an apt feature. After patching it out with diff --git a/methods/server.cc b/methods/server.cc index e12c23c..e07599c 100644 --- a/methods/server.cc +++ b/methods/server.cc @@ -294,7 +294,7 @@ ServerMethod::DealWithHeaders(FetchResult Res) NextURI = DeQuoteString(Server-Location); URI tmpURI = NextURI; // Do not allow a redirection to switch protocol - if (tmpURI.Access == http) + if (1 || tmpURI.Access == http) return TRY_AGAIN_OR_REDIRECT; } /* else pass through for error message */ Yes, that's intentional as you should really not switch between protocols. In squeeze it won't work as the redirections are handled locally by the method instead of being pushed back to the apt process. Moreover, it will probably fail in a not very helpful way if the https method is not installed. [...] I still get a message like this, though: W: Size of file /tmp/apt-changelog-TfnbZ1changelog is not what the server reported 77136 338 Yeah, that's possible. I don't think anybody tested that protocol switching worked. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738827: RFP: CasperJS - navigation scripting testing utility for PhantomJS
Package: wnpp Severity: wishlist Package name: CasperJS Version: 1.0.4 URL: http://casperjs.org/ License: MIT CasperJS is an open source navigation scripting testing utility written in Javascript for the PhantomJS WebKit headless browser and SlimerJS (Gecko). It eases the process of defining a full navigation scenario and provides useful high-level functions, methods syntactic sugar for doing common tasks such as: defining ordering browsing navigation steps filling submitting forms clicking following links capturing screenshots of a page (or part of it) testing remote DOM logging events downloading resources, including binary ones writing functional test suites, saving results as JUnit XML scraping Web contents I require it in order to be able to run the javascript testsuite of the upcoming version 2 of IPython, but I have no clue about javascript so I do not fell comfortable packaging it myself. I can help out if needed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737284: 3depict: needs versioned Build-Depends: libmgl-dev (= 2)
Control: tag -1 pending Hi, I see this has been fixed in git. Do you need a sponsor? Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738828: cinnamon: CVE-2014-1949
Package: cinnamon Severity: grave Tags: security Justification: user security hole This was assigned CVE-2014-1949: http://www.openwall.com/lists/oss-security/2014/02/12/7 Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615876: Asciidoc: about fixing duplicated files
Control: owner 615876 herla...@gmail.com found 615876 asciidoc/8.6.9-1 tags 615876 confirmed thanks Dear Axel and Christian, I'm currently working on this bug. I found the duplicated files you listed and am currently working on the installation package to fix this. In order to verify that I didn't forget anything, could you provide me the process you used to check duplicated files quickly please? Thanks a lot in advance, Joseph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738829: python-rdflib-tools: fails to upgrade from 'sid' - trying to overwrite /usr/share/man/man1/rdfpipe.1.gz
Package: python-rdflib-tools Version: 4.0.1-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'sid' to 'experimental'. It installed fine in 'sid', then the upgrade to 'experimental' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. See policy 7.6 at http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces From the attached log (scroll to the bottom...): Selecting previously unselected package python-rdflib-tools. Preparing to unpack .../python-rdflib-tools_4.0.1-1_amd64.deb ... Unpacking python-rdflib-tools (4.0.1-1) ... dpkg: error processing archive /var/cache/apt/archives/python-rdflib-tools_4.0.1-1_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/rdfpipe.1.gz', which is also in package python-rdflib 2.4.2-3 Errors were encountered while processing: /var/cache/apt/archives/python-rdflib-tools_4.0.1-1_amd64.deb cheers, Andreas python-rdflib=2.4.2-3_python-rdflib-tools=4.0.1-1.log.gz Description: GNU Zip compressed data
Bug#738830: exim4-config.template have multiple errors
Package: exim4-config Version: 4.80-7 Severity: normal Tags: patch error on file -- Package-specific info: Exim version 4.80 #3 built 02-Jan-2013 18:59:25 Copyright (c) University of Cambridge, 1995 - 2012 (c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2012 Berkeley DB: Berkeley DB 5.1.29: (October 25, 2011) Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' # # Please note that this is _not_ a dpkg-conffile and that automatic changes # to this file might happen. The code handling this will honor your local # changes, so this is usually fine, but will break local schemes that mess # around with multiple versions of the file. # # update-exim4.conf uses this file to determine variable values to generate # exim configuration macros for the configuration file. # # Most settings found in here do have corresponding questions in the # Debconf configuration, but not all of them. # # This is a Debian specific file dc_eximconfig_configtype='internet' dc_other_hostnames='marian1000.go.ro' dc_local_interfaces='' dc_readhost='' dc_relay_domains='' dc_minimaldns='true' dc_relay_nets='127.0.0.1' dc_smarthost='' CFILEMODE='644' dc_use_split_config='false' dc_hide_mailname='false' dc_mailname_in_oh='true' dc_localdelivery='mail_spool' mailname:marian1000.go.ro -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages exim4-config depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 exim4-config recommends no packages. exim4-config suggests no packages. -- Configuration Files: /etc/exim4/passwd.client [Errno 13] Permission denied: u'/etc/exim4/passwd.client' --- a/debian/exim4-config.templates +++ b/debian/exim4-config.templates @@ -1,13 +1,13 @@ Template: exim4/dc_eximconfig_configtype Type: select +__Default: not on a network; no configuration at this time # Translators beware! the following six strings form a single # Choices menu. - Every one of these strings has to fit in a standard # 80 characters console, as the fancy screen setup takes up some space # try to keep below ~71 characters. # DO NOT USE commas (,) in Choices translations otherwise # this will break the choices shown to users -__Choices: internet site; mail is sent and received directly using SMTP, mail sent by smarthost; received via SMTP or fetchmail, mail sent by smarthost; no local mail, local delivery only; not on a network, no configuration at this time -Default: local delivery only; not on a network +__Choices: internet site; mail is sent and received directly using SMTP, mail sent by smarthost; received via SMTP or fetchmail, mail sent by smarthost; no local mail; local delivery only; not on a network; no configuration at this time _Description: General type of mail configuration: Please select the mail server configuration type that best meets your needs. . @@ -29,6 +29,7 @@ Template: exim4/mailname Type: string +Default: empty _Description: System mail name: The 'mail name' is the domain name used to 'qualify' mail addresses without a domain name. @@ -44,7 +45,7 @@ Template: exim4/dc_other_hostnames Type: string -Default: +Default: empty _Description: Other destinations for which mail is accepted: Please enter a semicolon-separated list of recipient domains for which this machine should consider itself the final destination. @@ -59,7 +60,7 @@ Template: exim4/dc_relay_domains Type: string -Default: +Default:empty _Description: Domains to relay mail for: Please enter a semicolon-separated list of recipient domains for which this system will relay mail, for example as a fallback MX or @@ -71,7 +72,7 @@ Template: exim4/dc_relay_nets Type: string -Default: +Default: empty _Description: Machines to relay mail for: Please enter a semicolon-separated list of IP address ranges for which this system will unconditionally relay mail, functioning as a @@ -92,6 +93,7 @@ Template: exim4/dc_smarthost Type: string +Default: empty _Description: IP address or host name of the outgoing smarthost: Please enter the IP address or the host name of a mail server that this system should use as outgoing smarthost. If the smarthost only
Bug#738775: insserv: Insserv 1.16 tries to connect to systemd even though system is running on sysv-init
I've tried to reproduce this part of your problem report: * What was the outcome of this action? Cannot install initscripts after installing insserv 1.16 because it tries to connect to systemd which is present on the system but not used as PID 1. I have no problem installing initscripts or any other package, even if insserv spew out lots of error messages. So the problem you reported seem to be non-fatal and irrelevant for any installation problem. Can you tell me more about how the installation of initscripts fail? The svn version of insserv reduces the amount of messages, but are still printing warnings. The behaviour do not change, as far as I can tell. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738831: mpd: Mpd does not start: mpdsocket: Failed to bind to '[::]:6600': Address already in use
Package: mpd
Version: 0.18.7-1
Severity: normal
Tags: ipv6
Dear Maintainer,
Mpd does not start properly when bind_to_address option is any and
you have support for both ipv4 and ipv6.
This bug seems related to #563125, but it is not a problem of the resolver,
because if you specify the following in /etc/mpd.conf:
bind_to_address 0.0.0.0
bind_to_address ::
the daemon fails to start with the error:
mpdsocket: Failed to bind to '[::]:6600': Address already in use
Instead if you start the daemon with either one of the lines, the daemon starts
binding as expected on ipv4 only
tcp 0 0 0.0.0.0:6600 0.0.0.0:* LISTEN
or on ipv6 only:
tcp6 0 0 :::6600:::* LISTEN
So it is impossible to listen on both ipv4 and ipv6 addresses.
Here it is an strace excerpt of the fail:
socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 7
setsockopt(7, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(7, {sa_family=AF_INET, sin_port=htons(6600),
sin_addr=inet_addr(0.0.0.0)}, 16) = 0
listen(7, 5)= 0
setsockopt(7, SOL_SOCKET, SO_PASSCRED, [1], 4) = 0
socket(PF_INET6, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 8
setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(8, {sa_family=AF_INET6, sin6_port=htons(6600), inet_pton(AF_INET6, ::,
sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRINUSE (Address
already in use)
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: armel (armv5tel)
Kernel: Linux 3.12-1-kirkwood
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 mpd depends on:
ii adduser 3.113+nmu3
ii init-system-helpers 1.14
ii libadplug-2.2.1-0 2.2.1+dfsg3-0.1
ii libao41.1.0-2
ii libasound21.0.27.2-3
ii libaudiofile1 0.3.6-2
ii libavahi-client3 0.6.31-4
ii libavahi-common3 0.6.31-4
ii libavcodec54 6:9.10-2
ii libavformat54 6:9.10-2
ii libavutil52 6:9.10-2
ii libbz2-1.01.0.6-5
ii libc6 2.17-97
ii libcdio-cdda1 0.83-4.1
ii libcdio-paranoia1 0.83-4.1
ii libcdio13 0.83-4.1
ii libcurl3-gnutls 7.35.0-1
ii libfaad2 2.7-8
ii libflac8 1.3.0-2
ii libfluidsynth11.1.6-2
ii libgcc1 1:4.8.2-14
ii libglib2.0-0 2.36.4-1
ii libgme0 0.5.5-2
ii libid3tag00.15.1b-10
ii libiso9660-8 0.83-4.1
ii libjack-jackd2-0 [libjack-0.116] 1.9.9.5+20130622git7de15e7a-1
ii libmad0 0.15.1b-8
ii libmikmod23.1.16-1
ii libmms0 0.6.2-3
ii libmodplug1 1:0.8.8.4-4
ii libmp3lame0 3.99.5+repack1-3
ii libmpcdec62:0.1~r459-4
ii libmpdclient2 2.9-1
ii libmpg123-0 1.16.0-1
ii libogg0 1.3.1-1
ii libopenal11:1.14-4
ii libopus0 1.1-1
ii libpulse0 4.0-6+b1
ii libresid-builder0c2a 2.1.1-14
ii libroar2 1.0~beta11-1
ii libsamplerate00.1.8-7
ii libshout3 2.3.1-3
ii libsidplay2 2.1.1-14
ii libsidutils0 2.1.1-14
ii libsndfile1 1.0.25-9
ii libsqlite3-0 3.8.2-1
ii libstdc++64.8.2-14
ii libsystemd-daemon0204-6
ii libvorbis0a 1.3.2-1.3
ii libvorbisenc2 1.3.2-1.3
ii libvorbisidec11.0.2+svn18153-0.2
ii libwavpack1 4.70.0-1
ii libwildmidi1 0.2.3.4-2.1
ii libwrap0 7.6.q-25
ii libyajl2 2.0.4-4
ii libzzip-0-13 0.13.62-2
ii lsb-base 4.1+Debian12
mpd recommends no packages.
Versions of packages mpd suggests:
pn avahi-daemon none
pn icecast2 none
ii mpc [mpd-client] 0.25-1
pn pulseaudionone
-- Configuration Files:
/etc/mpd.conf changed:
music_directory /home/share/media/musica
playlist_directory /var/lib/mpd/playlists
db_file /var/lib/mpd/tag_cache
log_file/var/log/mpd/mpd.log
pid_file/run/mpd/pid
state_file /var/lib/mpd/state
sticker_file
Bug#738715: [debian-freedict] Bug#738715: dict-freedict-eng-rus: GoldenDict does not show requested article (at least for dict-freedict-eng-rus 2013.11.30-1)
Hello, Nikolay Shaplov schrieb am 12.02.2014, 14:31 +0400: I've installed dict-freedict-eng-rus 2013.11.30-1 from unstable and tried to use is through GoldenDict. But it does not work. It always shows wrong article (not the article I've typed in search input field). For example if I type free it would show free in the list of suggestions, but when I press enter, it will show me fragrant article in a new tab with free word in the tab's title. I cannot confirm that using the dictd server together with the dict client: krustus ~ :) % dict free 1 definition found From English-Russian FreeDict Dictionary ver. 0.2.1 [fd-eng-rus]: free /friː/ безвозмездны҄; бесплатны҄ krustus ~ :) % dict fragrant 1 definition found From English-Russian FreeDict Dictionary ver. 0.2.1 [fd-eng-rus]: fragrant /frəgrənt/ ароматически҄; ароматичны҄ I hope the Russian signs didn't get destroyed because of my tty. I cannot confirm your problem with dictd and dict. Please install dictd and use one of the suggested clients and see if the problem remains. If not, please report. Sebastian signature.asc Description: Digital signature
Bug#615876: Asciidoc: about fixing duplicated files
On Thu, 13 Feb 2014, Joseph Herlant wrote:
In order to verify that I didn't forget anything, could you provide me
the process you used to check duplicated files quickly please?
---8---
#!/bin/sh
set -eu
#set -x
l=
for f in $(dpkg -L asciidoc); do
[ -f $f ] || continue
l=${l:+$l
}$(sha256sum $f)
done
echo $l | sort | uniq --all-repeated=separate --check-chars=64
---8---
Cheers,
--
Cristian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738832: Segmentation fault in libmagic (src:file) [CVE-2014-1943]
Package: file Version: 5.11-2 Severity: grave Tags: security [ Re-sent to BTS by request of the security team, also updated ] a bug in the handling of indirect magic rules of libmagic leads to an infinite recursion when trying to determine the file type of certain files. The has been assigned CVE-2014-1943. Additionally, other well-crafted files might result in long computation times (five seconds for a single file while using 100% CPU) and overlong results (~400k line), something some applications that operate on the file result might not handle in a sane way. The issue has been made public by Bernd Melchers who initially found this bug: http://mx.gw.com/pipermail/file/2014/001327.html Impact is two-layered. The bug itself has been introduced years ago (pre oldstable). From jessie on, the default magic file as shipped in the package contains a file magic rule that is exploitable for a segmentation fault. In other words: jessie: Always affected and in full scale. squeeze/wheezy: Segmentation fault when using non-standard magic files that use indirect in a certain way. Still vulnerable for the computation time and overlong issues mentioned above. Upstream released 5.17 last night, fixing the bug for all reproducers I have in my collection. Backporting the patch is not trivial but hopefully feasible. I'll give that a try later the day. Christoph -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738715: [debian-freedict] Bug#738715: Bug#738715: dict-freedict-eng-rus: GoldenDict does not show requested article (at least for dict-freedict-eng-rus 2013.11.30-1)
Hello again, sorry, I've used the wrong dict-freedict-eng-rus database, due to problems on my unstable system. When installing eng-rus, dictd even stops working. So it seems to be indeed something serious. I'll have a look. Thanks Sebastian signature.asc Description: Digital signature
Bug#738833: release.debian.org: transition tracker for python3.4 as supported
Package: release.debian.org Severity: wishlist User: release.debian@packages.debian.org Usertags: transition Dear Release team, python3.4 is added as a supported version, please setup a tracker to transition / rebuild packages to pick up 3.4 as supported. I think something like that should do: Affected: .build-depends ~ /python3(all)?-dev|python3.3|python3/ Good: .depends ~ /python3 \( 3\.5\)/ | (!.depends ~ /python3 \( 3\.5\)/ .depends ~ /libpython3\.3/ .depends ~ /libpython3\.4/) | .depends ~ /python3.4/ Bad: .depends ~ /python3 \( 3\.4\)/ | .breaks ~ /python \(= 3\.4\)/ | (.depends ~ /libpython3\.3/ !.depends ~ /libpython3\.4/) Or use same stanzas as were used for 3.2(default) + 3.3(supported) transition. Regards, Dimitri. -- System Information: Debian Release: jessie/sid APT prefers trusty APT policy: (500, 'trusty') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf Kernel: Linux 3.13.0-8-generic (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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738831: mpd: Mpd does not start: mpdsocket: Failed to bind to '[::]:6600': Address already in use
On 2014/02/13 11:16, Niccolo Rigacci nicc...@rigacci.org wrote: Mpd does not start properly when bind_to_address option is any and you have support for both ipv4 and ipv6. This bug seems related to #563125, but it is not a problem of the resolver, because if you specify the following in /etc/mpd.conf: bind_to_address 0.0.0.0 bind_to_address :: the daemon fails to start with the error: mpdsocket: Failed to bind to '[::]:6600': Address already in use Instead if you start the daemon with either one of the lines, the daemon starts binding as expected on ipv4 only tcp 0 0 0.0.0.0:6600 0.0.0.0:* LISTEN or on ipv6 only: tcp6 0 0 :::6600:::* LISTEN So it is impossible to listen on both ipv4 and ipv6 addresses. No, and this bug report is bogus, because it is based on a misconfiguration. You configured /proc/sys/net/ipv6/bindv6only=0 and you tell MPD to bind to IPv4:6600 first. The second line will then try to bind to IPv4 *again*, as your configuration demands. Your kernel does not allow binding to the same address twice. How to solve the problem: - remove the 0.0.0.0 line as :: already implies IPv4 OR - set bindv6only=1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655154: woof: No space left on device when /tmp is full
tags 655154 + upstream
forwarded 655154 si...@budig.de
thanks
Hello,
The attached patch fixes this problem. I have forwarded it to the
upstream maintainer. Here follows the patch description:
,
| Improve handling of files received with option -U
|
| Instead of storing the downloaded contents into a temporary file
| that is copied by woof to the final destination (current directory),
| the uploaded file is directly written to the current directory, with
| precautions to avoid overwriting existing files.
|
| This is done by subclassing cgi.FieldStorage to override make_file() so
| that it does not create a temporary file when encountering an atomic
| part whose name is upfile in the MIME data.
|
| This improvement is particularly welcome when receiving large files,
| since it avoids:
| - a possible failure due to the temporary directory being too small to
| hold the file;
| - a useless copy of the whole file;
| - a possible loss of the whole download in case a failure occurs when
| woof copies the (complete) temporary file to its final destination.
`
For people who don't want to apply the patch, setting TMPDIR allows a
partial workaround: you may indicate a directory with more space than
/tmp this way, but you will still have to hold two copies of the
downloaded file at the same time (one in TMPDIR and the other in the
directory from which 'woof -U' was started), until woof deletes the
temporary file through garbage collection. Depending on the file size
and the available space, this may or may not be possible.
--
Florent
diff --git a/woof b/woof
index 2abedf0..fde8de1 100755
--- a/woof
+++ b/woof
@@ -124,6 +124,64 @@ class ForkingHTTPServer (BaseHTTPServer.HTTPServer):
self.close_request (request)
+class MyFieldStorage (cgi.FieldStorage):
+ Subclass of FieldStorage with efficient handling of uploaded files.
+
+ This class behaves the same as FieldStorage except that it handles uploaded
+ files more efficiently: instead of storing the data into a temporary file
+ that is copied by woof to the final destination (current directory),
+ the uploaded file is directly written to the current directory, with
+ precautions to avoid overwriting existing files.
+
+
+ # The function signature changed between Python 2 and Python 3; this will
+ # work in all cases.
+ def make_file(self, *args, **kwargs):
+ # The self.list is None check is here to prevent misbehaving in case we
+ # receive a multipart whose name happens to be upfile.
+ if self.list is None and self.name == upfile:
+ # make_file() was called for an uploaded file. No need to create a
+ # potentially huge temporary file only to copy it to the final
+ # destination. Just create the file in a way that avoids overwriting
+ # existing files.
+ upfilename = self.filename
+
+ if \\ in upfilename:
+upfilename = upfilename.split (\\)[-1]
+
+ upfilename = os.path.basename (self.filename)
+
+ destfile = None
+ for suffix in [, .1, .2, .3, .4, .5, .6, .7, .8,
+.9]:
+destfilename = os.path.join (upfilename + suffix)
+try:
+ destfile = os.open (destfilename,
+ os.O_WRONLY | os.O_CREAT | os.O_EXCL, 0o644)
+ break
+except OSError, e:
+ if e.errno == errno.EEXIST:
+ continue
+ raise
+
+ # Fallback to tempfile.mkstemp() in case the above did not manage to
+ # create the file.
+ if destfile is None:
+destfile, destfilepath = tempfile.mkstemp (
+ prefix = upfilename + ., dir = .)
+# 'destfilepath' is a full path, be consistent with the normal case
+destfilename = os.path.basename (destfilepath)
+
+ msg = Accepting uploaded file: '%s' % upfilename
+ if upfilename != destfilename:
+msg += , stored as '%s' % destfilename
+ sys.stderr.write (msg + ...\n)
+
+ return os.fdopen (destfile, wb)
+ else:
+ return cgi.FieldStorage.make_file (self, *args, **kwargs)
+
+
# Main class implementing an HTTP-Requesthandler, that serves just a single
# file and redirects all other requests to this file (this passes the actual
# filename to the client).
@@ -152,49 +210,26 @@ class FileServHTTPRequestHandler (BaseHTTPServer.BaseHTTPRequestHandler):
# http://mail.python.org/pipermail/python-list/2006-September/402441.html
ctype, pdict = cgi.parse_header (self.headers.getheader ('Content-Type'))
- form = cgi.FieldStorage (fp = self.rfile,
- headers = self.headers,
- environ = {'REQUEST_METHOD' : 'POST'},
- keep_blank_values = 1,
- strict_parsing = 1)
+ form = MyFieldStorage (fp = self.rfile,
+
Bug#615876: Asciidoc: about fixing duplicated files
On Thu, 13 Feb 2014, Cristian Ionescu-Idbohrn wrote:
---8---
#!/bin/sh
set -eu
#set -x
l=
for f in $(dpkg -L asciidoc); do
[ -f $f ] || continue
l=${l:+$l
}$(sha256sum $f)
done
echo $l | sort | uniq --all-repeated=separate --check-chars=64
---8---
This is simplier.
---8---
#!/bin/sh
set -eu
for f in $(dpkg -L asciidoc); do
[ -f $f ] || continue
sha256sum $f
done | sort | uniq --all-repeated=separate --check-chars=64
---8---
Cheers,
--
Cristian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738834: buildd.emdebian.org: gcc-4.7-arm-linux-gnueabi can't be installed due to unmet dependencies
Package: gcc-4.7-arm-linux-gnueabi Severity: normal I am trying to install gcc-4.7-arm-linux-gnueabi which can not be installed due to problems with binutils-arm-linux-gnueabi and libgomp1-armel-cross. If I try to install libgomp1-armel-cross, apt tells me that it is not installable due to its dependency on gcc-4.8-base-armel-cross ... which seems not to be in the repository (yet?). I am Running Debian 7.3 on my System, and I am using the emdebian wheezy repository: deb http://www.emdebian.org/debian/ wheezy main Here is my Screenlog: root@PC63:/home/andi# apt-get install gcc-4.7-arm-linux-gnueabi Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: gcc-4.7-arm-linux-gnueabi : Depends: binutils-arm-linux-gnueabi (= 2.21.1) but it is not going to be installed Depends: libgomp1-armel-cross (= 4.7.2-4) but it is not going to be installed E: Unable to correct problems, you have held broken packages. root@PC63:/home/andi# apt-get install libgomp1-armel-cross Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libgomp1-armel-cross : Depends: gcc-4.8-base-armel-cross (= 4.8.2-1) but it is not installable E: Unable to correct problems, you have held broken packages. root@PC63:/home/andi# apt-cache search gcc-4.8-base-armel-cross root@PC63:/home/andi# -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.13.1-kvmhost (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738835: Satellite/null client settings
Package: postfix If somebody selects Satellite config, is this basically intended to setup like a null client? http://www.postfix.org/STANDARD_CONFIGURATION_README.html#null_client or should null client be offered as an additional menu option? I notice some differences between Satellite and what is suggested for a null client: a) Satellite sets my_destination=$HOSTNAME, $HOSTNAME.localhost, ... whereas I expected nothing in that field, e.g. my_destination= b) for any option, postinst is creating an aliases file, a null client shouldn't really need an aliases file and it could probably leave the alias_maps and alias_database blank c) for any option, postinst is adding an alias for root to the aliases file - for a null client, that shouldn't be required either -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738836: missing license in debian/copyright
Package: unifont Severity: serious User: alteh...@debian.org Usertags: ftp X-Debbugs-CC: ftpmas...@ftp-master.debian.org thanks Dear Maintainer, please add the GFDL 1.3 ... license of unifont-6.3.20140204/doc/unifont.* to debian/copyright. Thanks! Thorsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615876: Asciidoc: about fixing duplicated files
Dear Christian,
Thanks a lot for your script.
There's an issue with your check because it also returns files that
are already symbolink links.
Check should be:
[ -f $f -a ! -h $f ] || continue
I've almost finished the patch (Only the 2 gz files are still
duplicated now). I'll upload it later on.
Regards,
Joseph
On Thu, Feb 13, 2014 at 11:41 AM, Cristian Ionescu-Idbohrn
cristian.ionescu-idbo...@axis.com wrote:
On Thu, 13 Feb 2014, Cristian Ionescu-Idbohrn wrote:
---8---
#!/bin/sh
set -eu
#set -x
l=
for f in $(dpkg -L asciidoc); do
[ -f $f ] || continue
l=${l:+$l
}$(sha256sum $f)
done
echo $l | sort | uniq --all-repeated=separate --check-chars=64
---8---
This is simplier.
---8---
#!/bin/sh
set -eu
for f in $(dpkg -L asciidoc); do
[ -f $f ] || continue
sha256sum $f
done | sort | uniq --all-repeated=separate --check-chars=64
---8---
Cheers,
--
Cristian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738834: Acknowledgement (buildd.emdebian.org: gcc-4.7-arm-linux-gnueabi can't be installed due to unmet dependencies)
Sorry, I just realized that I should have written Package: buildd.emdebian.org thx! On 02/13/2014 11:45 AM, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): unknown-pack...@qa.debian.org If you wish to submit further information on this problem, please send it to 738...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738798: openssh: FTBFS on hppa -- -fwrapv causes ICE compiling ssh-genkey.c
Control: tag -1 pending On Wed, Feb 12, 2014 at 07:42:42PM -0500, John David Anglin wrote: See build log http://buildd.debian-ports.org/status/fetch.php?pkg=openssharch=hppaver=1%3A6.5p1-3stamp=1392229519 and GCC PR rtl-optimization/60155 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60155 Maybe add --without-hardening to configure options. Ugh, OK. Committed to git. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738752: Bug#738791: transition: qhull
This compilation failure has | gcc ... -I/usr/include/qhull | PyMca/Object3D/Object3DQhull/Object3DQhull.c:7:19: fatal error: qhull.h: No such file or directory | #include qhull.h The latest upstream qhull uses /usr/include/libqhull and /usr/include/libqhullcpp for C and C++ header files, respectively. And libqhull.h instead of qhull.h. So instead of #include qhull/qhull.h ane should now use #include libqhull/libqhull.h I've added compatibility links from /usr/include/qhull/* for the contents of the above directories. This report has caused me to add another compatibility link from /usr/include/qhull/qhull.h to /usr/include/qhull/liqhull.h. So building with liqhull-dev (= 2012.1-3) might solve this problem. But in the longer term, it would be best to transition to the new path and filename. Cheers, --Barak. -- Barak A. Pearlmutter Hamilton Institute Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738837: python-lockfile: New upstream release with py3k support
Package: python-lockfile Version: 1:0.8-2 Severity: normal Dear Maintainer, A new version of python-lockfile is available and provides python3 compatibility. Please consider packaging it :) Cheers Geoff -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738838: ITP: mps-youtube -- Terminal based YouTube jukebox with playlist management
Package: wnpp Severity: wishlist Owner: Zlatan Todoric zlatan.todo...@gmail.com * Package name: mps-youtube Version : 0.1.12 Upstream Author : Darren Ross np1na...@gmail.com * URL : https://github.com/np1/mps-youtube * License : GPL Programming Lang: Python Description : Terminal based YouTube jukebox with playlist management Features: - Search and play audio/video - Create local playlists - Download audio/video - Works with Python 2.7 and 3.x - Works with Windows, Linux and Mac OS X - Requires mplayer This project is based on mps, which is a terminal based program to search, stream and download music. This implementation uses YouTube as a source of content and can play and download video as well as audio. The pafy library handles interfacing with YouTube. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music
Package: wnpp Severity: wishlist Owner: Zlatan Todoric zlatan.todo...@gmail.com * Package name: mps Version : 0.18.41 Upstream Author : Darren Ross np1na...@gmail.com * URL : https://github.com/np1/mps * License : GPL Programming Lang: Python Description : Poor Man's Spotify - Search and stream music Features: - Search and stream music - Create playlists - Download music - Works with Python 2.7 and 3.x - Works with Windows, Linux and Mac OS X - No Python dependencies - Requires mplayer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738837: python-lockfile: New upstream release with py3k support
On 13-Feb-2014, Geoff wrote: A new version of python-lockfile is available and provides python3 compatibility. Which upstream source are you referring to? The ‘lockfile’ project has had numerous homes in recent years. Please consider packaging it :) Which version are you asking to be packaged? Please re-title this bug report to specify the version. Thanks for the report. -- \“Always code as if the guy who ends up maintaining your code | `\ will be a violent psychopath who knows where you live.” —John | _o__) F. Woods | Ben Finney b...@benfinney.id.au signature.asc Description: Digital signature
Bug#738791: transition: qhull
Control: block -1 by 738751 On 2014-02-13 07:58:58, Sébastien Villemot wrote: Although I would not anticipate any difficulty, do let me know if any packages that build-depend on libqhull-dev require help getting them to build with the new version and I will do what I can to help. There is at least pymca that FTBFS with the new qhull (I marked the bug as blocking the transition). And there is meshlab (#738751). Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#737527: subversion: Replace GCJ by OpenJDK in Subversion JavaHL build
Why do you request the use of OpenJDK given that GCJ is availale? :) It's better supported, and it's a lot faster; although the speed doesn't really matter for subversion build - only for tests maybe... And I don't think Oracle hegemony is really relevant since OpenJDK is also free software and is also licensed under a copyleft license. Of course severity=wishlist but I'm sure it will be needed to switch to OpenJDK some day. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738791: transition: qhull
I've uploaded qhull (2012.1-4) which has a convenience link for /usr/include/qhull/qhull.h, this should solve the issue with meshlab (#738751) and perhaps the rest... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738801: cups: /etc/init.d/cups stop/start hang when systemd is installed
-=| Didier 'OdyX' Raboud, 13.02.2014 10:25:39 +0100 |=- Nye; do you happen to have xprint-common unpurged? (Please paste the result of $ dpkg -l xprint-common) Le jeudi, 13 février 2014, 11.04:16 Damyan Ivanov a écrit : Heh, fiddling with /etc/init.d/cups I purged xprint-common and this seems to have fixed the cups problem: Ha. That looks interesting. There's indeed some xprint handling in cups.init. As xprint disappeared from Debian before Wheezy, I think it's probably safe to drop this handling code from the init script. If Nye can confirm he has the same conditions than you, then that'd be the fix. Damyan: Could you re-install, remove (but not purge) xprint from oldstable, edit your /etc/init.d/cups.init to drop all instances of restart_xprint and see if it works for you? $ sudo dpkg -r xprint-common ~ (Reading database ... 492747 files and directories currently installed.) Removing xprint-common (2:1.6.0-4) ... $ sudo service cups restart --- hang, ctrl-C $ sudo vim /etc/init.d/cups# remove mentions of restart_xprint $ sudo service cups restart~ Warning: Unit file of cups.service changed on disk, 'systemctl --system daemon-reload' recommended. $ sudo systemctl --system daemon-reload $ sudo service cups restart~ $ IOW, removing invocations of restart_xprint from /etc/init.d/cups helped. \o/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738840: subversion: integer overflow makes 32-bit svnserve hang sometimes
Package: subversion
Version: 1.8.5-1
Severity: normal
Tags: upstream
There is a bug in Subversion 1.8 libsvn_subr that makes 32-bit svnserve
hang after some period of time doing an infinite loop inside
ensure_data_insertable() because cache-data_used becomes a very big
value after adding an unsigned representation of a negative value to it,
and ensure_data_insertable() never removes entries smaller than
cache-data_used / cache-used_entries / 8.
A patch is attached; this is definitely an upstream issue, so I'll also
send it to them (if everything will be OK with
http://subversion.tigris.org/ - now it opens with errors).This patch fixes the bug which makes 32-bit svnserve hang after some period of
time
doing an infinite loop inside ensure_data_insertable() because cache-data_used
becomes
a very big value, and ensure_data_insertable() never removes entries smaller
than
cache-data_used / cache-used_entries / 8.
--- a/subversion/libsvn_subr/cache-membuffer.c 2014-02-12 21:42:12.483208244
+
+++ b/subversion/libsvn_subr/cache-membuffer.c 2014-02-12 21:45:54.275215290
+
@@ -1374,7 +1374,9 @@ membuffer_cache_set_internal(svn_membuff
* the old spot, just re-use that space. */
if (entry ALIGN_VALUE(entry-size) = size buffer)
{
- cache-data_used += size - entry-size;
+ /* not += because (size - entry_size) is almost always a big 32-bit
+ unsigned representation of a negative value on 32-bit platforms */
+ cache-data_used = cache-data_used + size - entry-size;
entry-size = size;
#ifdef SVN_DEBUG_CACHE_MEMBUFFER
Bug#738841: subversion: non-synchronized increment of cache-hit_count in libsvn_subr
Package: subversion
Version: 1.8.5-1
Severity: minor
Tags: upstream
There is also another bug Subversion 1.8 libsvn_subr - cache-hit_count
and entry-hit_count are incremented without proper mutual exclusion
(only with read lock), so some increments get lost in multithreaded
svnserve; as it's unlikely two threads access the same entry at once,
usually cache-hit_count (not entry-hit_count) increments are lost,
which leads to cache-hit_count being less than sum(entry-hit_count).
So it may overflow during subtraction of entry-hit_count and lead to
removing of values that should not be removed from the cache in
ensure_data_insertable(). Instead of killing the performance by mutual
exclusion we may just check for possible overflow.
This doesn't affect general svnserve usability, so severity=minor.
A patch is attached; this is also an upstream issue, so I'll also try to
send it to authors.
See the comment.
--- a/subversion/libsvn_subr/cache-membuffer.c 2014-02-12 21:53:58.547230675
+
+++ a/subversion/libsvn_subr/cache-membuffer.c 2014-02-12 22:02:11.039246322
+
@@ -639,9 +639,16 @@ drop_entry(svn_membuffer_t *cache, entry
assert(idx = last_in_group);
/* update global cache usage counters
+ *
+ * cache-hit_count and entry-hit_count are incremented without proper
mutual
+ * exclusion (only with read lock), so some increments get lost in
multithreaded svnserve;
+ * as it's unlikely two threads access the same entry at once usually it
leads to
+ * cache-hit_count being less than sum(entry-hit_count). So it may overflow
+ * during subtraction and lead to emptying the cache in
ensure_data_insertable().
+ * instead of killing the performance by mutual exclusion we just check for
possible overflow.
*/
cache-used_entries--;
- cache-hit_count -= entry-hit_count;
+ cache-hit_count = cache-hit_count entry-hit_count ? 0 :
cache-hit_count-entry-hit_count;
cache-data_used -= entry-size;
/* extend the insertion window, if the entry happens to border it
@@ -802,7 +809,7 @@ let_entry_age(svn_membuffer_t *cache, en
{
apr_uint32_t hits_removed = (entry-hit_count + 1) 1;
- cache-hit_count -= hits_removed;
+ cache-hit_count = cache-hit_count hits_removed ? 0 :
cache-hit_count-hits_removed;
entry-hit_count -= hits_removed;
}
Bug#738753: please add a --exclude-keyring(s) option
Hi Holger, Holger Levsen wrote (12 Feb 2014 16:37:40 GMT) : quite many keys in my keyring can also be found in /usr/share/keyrings/ thus I believe it would be useful to teach parcimonie to not refresh those keys found in those keyrings, as I can trivially update them (eg via updating the debian- keyring package). Just to clarify the use case and requirements, hoping it may help the person who will work on this feature: are you importing these additional keyrings into your personal one (and thus, have to redo it each time the package that ships these keyrings is updated), or using a keyring FILE directive in gpg.conf? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689207: rust: changing back from ITP to RFP
Sylvestre Ledru sylves...@debian.org wrote: Yes, Luca is touch with ftp master regarding the bootstrap issue, we are discussing with upstream on the llvm patches and we have the agreement from Mozilla GSoC admin to propose a gsoc on the packaging of rust. I was planning to send a status update as soon as I got a quotable mail from ftp-masters, but this is taking some time so here's a partial summary. Rust packaging is currently technically feasible (see the many PPA or unofficial debs) but some legal/policy issues have to be ironed before hitting NEW. I'm collecting issues and drafts at https://wiki.debian.org/Teams/RustPackaging The main one is the bootstrapping phase, for which I have sent a mail on 07/02/14 to ftp-masters, asking for a position on the proposals at https://wiki.debian.org/Teams/RustPackaging/Bootstrap I'm currently waiting for a return on this. The other (secondary) issue is the libraries bundling, as described in https://wiki.debian.org/Teams/RustPackaging/Unbundling jemalloc is no more there, libuv is mostly synched (I was waiting for an imminent 0.12, but I won't hold my breathe anymore), gyp is a minor build annoyance, but LLVM is a big beast. For the latter, upstream is trying to catch up upstream on x86 for 1.0 (but not a blocker): https://github.com/mozilla/rust/wiki/Meeting-weekly-2014-02-04#wiki-llvm While this is an annoyance, it won't block NEW review (assuming all the copyrights are well in place) and (AFAICT) won't have an impact for -security till when we hit testing/stable (which I still consider premature now). Other items just listed in the above page are in a flux: * soname stability is much better now after[0], but I feel that the dynamic-vs-linking discussion is not yet written in stone. * rustpkg and dpkg integration is not yet there, as rustpkg was recently scrapped[1]. * I don't plan to touch multi-arch and cross-build until things are a bit more stable. * Co-installation of several versions is an open design point. PPA packages can already do that and I'd like to have it, but I like to have a proper runtime-vs-compiler split in place before going there. I still have to get in touch with PPA author. That's mostly it. I'll CC the ftp-masters reply here as soon as I get it. [0] https://github.com/mozilla/rust/issues/10188 [1] https://github.com/mozilla/rust/commit/25fe2cadb10db1a54cefbd1520708d4397874bc3 Cheers, Luca -- .''`. | ~[ Luca BRUNO ~ (kaeso) ]~ : :' : | Email: lucab (AT) debian.org ~ Debian Developer `. `'` | GPG Key ID: 0x3BFB9FB3 ~ Free Software supporter `-| HAM-radio callsign: IZ1WGT ~ Networking sorcerer -- 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 coupling etc.
Lucas Nussbaum writes (Bug#727708: init system coupling etc.): If you really want to have that discussion now, rather than wait for actual, concrete problems to discuss, I'd suggest that you build a few hypothetical scenarios, and discuss them. And then build a resolution that represents the aggregated opinions on those few hypothetical scenarios. I think there is one key hypothetical scenario, and it is the one alluded to in Adrian Bunk's recent message: ] One of the Debian GNOME maintainers has stated in this discussion[1]: ] ] But there are no realistic solutions for having GNOME support multiple ] init systems in jessie. ] ] Whether that's actually true is another question, but a maintainer ] speaking like this clearly shows that it is not only a theoretical ] question. I don't find Sjoerd Simons's comments very reassuring. In the context of the whole discussion I think Adrian's interpretation is much more likely to reflect the true sentiment. The question in that context is this: if GNOME upstream say that GNOME will only work with systemd, or the Debian GNOME maintainers say that Debian's GNOME packages will only work with systemd, is that acceptable ? Do you think it would be better to deal with that hypothetical case explicitly ? But I also don't really understand why there's a particular urgency for the TC to rule on that. Are there packages with tight coupling already in the archive? AIUI GNOME in sid right now can't lock the screen unless you're using systemd. Ian. -- 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 coupling etc.
Russ Allbery writes (Bug#727708: init system coupling etc.): I propose the following text as an amendment to this option. [...] Thanks for your constructive contribution. (As I'm sure you'll understand, I don't agree with it but it is right that you propose something you feel reflects your views.) It would replace this text in its entirety, including the [GR rider] section. (I don't see any need for or purpose served by cancelling technical advice to the project based on a GR outcome. I agree. Thanks, Ian. -- 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 coupling etc.
Keith Packard writes (Bug#727708: init system coupling etc.): I agree with you that this is an important issue which needs to be resolved within the Debian project. I also want to make it clear that I support the goal of having the project provide a clear policy statement about this issue in the short term. The discussions held within the context of the default init bug were fruitful, and without rancor, which makes me hopeful that the project membership can drive this issue to consensus in the near future through the usual policy editing process. As such I'd like to amend this proposed ballot with an additional option: I don't think this is likely but I can see why you would want to try that. * The TC chooses to not pass a resolution on this issue at the current time. This is different from FD as it says the TC will not continue discussions on this issue, although it could well restart them if the people involved in the policy editing process come to an impasse. It's also different from 'T' in that it will allow us to revisit this in the future without needing to overturn a previous decision. And it is different from FD in that if enough people outside the TC feel that the issue needs to be decided now, it signals that the time for them to propose a GR has come. Thank you for your consideration. And thanks for engaging with the process in a constructive way. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738831: mpd: Mpd does not start: mpdsocket: Failed to bind to '[::]:6600': Address already in use
On Thu, Feb 13, 2014 at 11:29:53AM +0100, Max Kellermann wrote: How to solve the problem: - remove the 0.0.0.0 line as :: already implies IPv4 If I set bind_to_address :: I see with netstat: tcp60 0 :::6600 :::* LISTEN Indeed I can telnet -4 across the LAN to port 6600, so I assume you are right and the bug is to be closed! Btw, someone can explain me why other daemons seem to bind on both ipv4 and ipv6? Here it is the netstat for sshd: tcp 0 0 0.0.0.0:22 0.0.0.0:*LISTEN tcp60 0 :::22 :::* LISTEN -- Niccolo Rigacci - http://www.rigacci.net/ Campi Bisenzio - Firenze - Italy Tel. Office: +39-055-9331021, Mobile: +39-327-5619352 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738753: please add a --exclude-keyring(s) option
Hi intri, On Donnerstag, 13. Februar 2014, intrigeri wrote: Just to clarify the use case and requirements, hoping it may help the person who will work on this feature: are you importing these additional keyrings into your personal one (and thus, have to redo it each time the package that ships these keyrings is updated), or using a keyring FILE directive in gpg.conf? hah. I wish I had known about the keyring file directive before... so, I have imported them and refreshed them occasionally... cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#738794: xterm: the right part of the window is not always erased
On Thu, Feb 13, 2014 at 01:04:09AM +0100, Vincent Lefevre wrote: Package: xterm Version: 301-1 Severity: minor The right part of the window is not always erased. This happened with font fixed. See attached screenshot. There's no details on how to reproduce it, e.g., a) from repainting due to exposure events b) from resizing c) from running some particular application d) another problem with the X server (seems that most recent issues reported by you in this area have been due to that) (also, of course - some notion of the previous working version of xterm) -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#738842: subversion: add debug package
Package: subversion Version: 1.8.5-1 Severity: wishlist While I was trying to catch bug #738840 I've discovered there is no subversion-dbg package in Debian. Can you add it? As I understand it just requires adding package entry to control and --dbg-package=subversion-dbg to dh_strip (at least it worked for me). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738188: VESA Newcons is awfully slow
On 12.02.2014 14:59, Robert Millan wrote: On 09/02/2014 12:56, Markus Koschany wrote: Switching between virtual terminals and X works flawlessly after I loaded the intel drivers manually. What about switching from one VT to another? (no X involved) Works perfectly. signature.asc Description: OpenPGP digital signature
Bug#738837: python-lockfile: New upstream release with py3k support
Arff, sorry for the previous incomplete report :) On 13/02/2014 12:13, Ben Finney wrote: On 13-Feb-2014, Geoff wrote: A new version of python-lockfile is available and provides python3 compatibility. Which upstream source are you referring to? The ‘lockfile’ project has had numerous homes in recent years. I simply followed link to pypi[0] from the PTS[1]. It appears python-lockfile moved from googlecode to github[2]. I was currently looking at some python packages state in debian to eventually start packaging python-CacheControl which depends on python-lockfile. I noticed python-lockfile might support py3k inspecting the setup.py but I did not try it myself though. The upstream README mention some major change in the API for 0.9. Pullrequest 3[3] reveals also the current maintainer is willing to hand over the project. This explains why python-lockfile has been quite dormant. Cheers, Geoff [0] http://pypi.python.org/pypi/lockfile [1] http://packages.qa.debian.org/p/python-lockfile.html [2] https://github.com/smontanaro/pylockfile [3] https://github.com/smontanaro/pylockfile/pull/3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738458: RFS: libebur128/1.0.1-1 [ITP] -- implementation of the EBU R128 loudness standard
Control: owner -1 ! Setting myself as owner as part of the ongoing effort to move this under the Multimedia team umbrella. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#738839: ITP: mps -- Poor Man's Spotify - Search and stream music
Hi Zlatan, On Donnerstag, 13. Februar 2014, Zlatan Todoric wrote: Description : Poor Man's Spotify - Search and stream music so how is this related to Spotify? Not at all, it's just streaming music? (And what has it to do with poverty? And with poor men especially?) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#738753: please add a --exclude-keyring(s) option
Holger Levsen wrote (13 Feb 2014 11:50:38 GMT) : hah. I wish I had known about the keyring file directive before... so, I have imported them and refreshed them occasionally... I've not looked at this problem in details (and am not likely to do so any time soon), but it seems to me that if you 1. removed these duplicate keys from your keyring; 2. used the keyring directive instead... then it would *maybe* make it easier for parcimonie to call gpg in a way that only uses your personal keyring, and disregards any additional ones (possibly by copying gpg.conf to a temporary file, removing any keyring directive from the copy, and passing --options $TEMPORARY_FILE to gpg). To me, it seems it would 0. fix an actual bug, as in the current implementation incrementally imports keys from keyrings specificied in gpg.conf into the personal one, when they're found on the configured keyserver, which seems totally wrong; 1. be a bit easier to implement than a --exclude-keyring option; 2. provide a nicer user experience, as this simply could be done by default, and no additional parcimonie option would be needed. What do you think? If you agree, then perhaps we could retitle this bug report to parcimonie should ignore additional keyrings, instead of incrementally importing their keys into the personal one or similar, and raise the priority to normal. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738842: subversion: add debug package
Control: forcemerge 508147 -1 On Thu, Feb 13, 2014 at 03:57:32PM +0400, vita...@yourcmc.ru wrote: While I was trying to catch bug #738840 I've discovered there is no subversion-dbg package in Debian. Can you add it? Already done. Just waiting for the next upload. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
Bug#738753: please add a --exclude-keyring(s) option
Hi intri, On Donnerstag, 13. Februar 2014, intrigeri wrote: What do you think? If you agree, then perhaps we could retitle this bug report to parcimonie should ignore additional keyrings, instead of incrementally importing their keys into the personal one or similar, and raise the priority to normal. sounds very reasonable to me, thanks! cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#738844: libhdf5-doc does not contain documentation, only examples
Package: libhdf5-doc Version: 1.8.12-9 Severity: normal Hello, thank you for packaging hdf5. I installed libhdf5-doc hoping to have the documentation offline to be able to work from an airplane, but I realised the package only has examples: $ dpkg -L libhdf5-doc|sort /. /usr /usr/share /usr/share/doc /usr/share/doc/libhdf5-doc /usr/share/doc/libhdf5-doc/changelog.Debian.gz /usr/share/doc/libhdf5-doc/changelog.gz /usr/share/doc/libhdf5-doc/copyright /usr/share/doc/libhdf5-doc/examples /usr/share/doc/libhdf5-doc/examples/c++ … /usr/share/doc/libhdf5-doc/examples/c++/writedata.cpp.gz /usr/share/doc/libhdf5-doc/examples/h5_attribute.c.gz … /usr/share/doc/libhdf5-doc/examples/ph5example.c.gz /usr/share/doc/libhdf5-doc/RELEASE.txt.gz At least from the package description, I expected to find something like this: http://www.hdfgroup.org/HDF5/doc/ Ciao, Enrico -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash libhdf5-doc depends on no packages. libhdf5-doc recommends no packages. Versions of packages libhdf5-doc suggests: ii chromium [www-browser] 31.0.1650.63-1 ii doc-base 0.10.5 ii evince [pdf-viewer]3.10.0-2 ii iceweasel [www-browser]24.2.0esr-1 ii libhdf5-dev1.8.12-9 ii lynx-cur [www-browser] 2.8.8pre4-1 ii netsurf-gtk [www-browser] 2.9-2+b1 ii w3m [www-browser] 0.5.3-15 -- 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#734327: rss2email TypeError: sequence item 1: expected string or Unicode, NoneType found
Hi Jeroen, Sorry for the delay. As Trevor said, the development is more active on the 3.x branch (still in experimental). I encourage you to try it independently of this problem! That being said, it looks more like a feedparser bug, though it can also be fixed in rss2email (the tag handling code is the same in 3.x). To be sure, can you attach a copy of the feed when it fails? I'm sure it will help other programs that use feedparser. Thanks! -- Etienne Millon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738845: invoke-rc.d: unknown initscript, /etc/init.d/ceph-all not found.
Source: ceph Version: 0.72.2-1 Severity: important During install of the ceph package, I notice the following emitted: invoke-rc.d: unknown initscript, /etc/init.d/ceph-all not found. Seems to me there is a bug in the init script. - Jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738754: please add a --download(-only) option
Hi, Holger Levsen wrote (12 Feb 2014 16:38:05 GMT) : when updating the keyring, gnuog is blocked for 1-2 minutes, Just to be clear: a single gpg --import $KEY_FILE takes 1-2 minutes with your current configuration and keyring, right? If so: wow. We certainly did not expect this kind of extreme use cases when designing parcimonie, thanks for enlightening me :P I'm not sure how much work (initial implementation + added code complexity + maintenance) I want to put into working around GnuPG's slowness in extreme cases. So, to assert the importance of this bug, I would first need to know how long it takes, once you've switched to the keyring directive in gpg.conf, and removed the duplicated keys from your personal keyring. thus when I run parcimonie every $random-amount of time and read mail and encounter a encrypted or signed mail, my mail client is blocked by gpg being blocked, blocking me from reading mail, which is quite annoying. Understood. So I believe a --download(-only) option would be quite useful, that way I could let parcimonie download keys and then when I'm certain I dont want to read mails, I could import those keys. Yep. Importing into a custom ~/.local/share/parcimonie/updated-keys.gpg keyring would be doable. Let's reconsider this once we have the answer to the question above. This feels like a quite horrible workaround but as I see it this is indeed a problem with gpg and not with my mailclient... Possibly whatever operation GnuPG is doing when importing a key could be optimized. I've not found any relevant parameter we could pass to --import-options, so likely this would have to happen in GnuPG itself. No idea if/how this is possible, and I've not looked at GnuPG's tasks tracker. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738846: invoke-rc.d: unknown initscript, /etc/init.d/ceph-mds-all not found.
Source: ceph-mds Version: 0.72.2-1 Severity: important During install of the ceph-mds package, I notice the following emitted: invoke-rc.d: unknown initscript, /etc/init.d/ceph-mds-all not found. Seems to me there is a bug in the init script. - Jonas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738847: graphviz: please include a binary to view dotfiles directly
Package: graphviz Version: 2.26.3-16.2 Severity: wishlist Tags: upstream Hello, It would be really nice if we had a binary to view dotfiles directly. Theoretically we should be able to do this with dotty, but in my experience dotty is really broken (e.g. does not display labels). Right now I am using a helper script called `dotview` that goes like this, but of course something that is released in the wild has to be a lot more robust: 888- #!/bin/sh set -ex image=$(mktemp --tmpdir XX.png) dot -Tpng -o$image $@ xdg-open $image 888- -- 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/4 CPU cores) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages graphviz depends on: ii libc6 2.17-97 ii libcdt4 2.26.3-16.2 ii libcgraph5 2.26.3-16.2 ii libexpat1 2.1.0-4 ii libgd3 2.1.0-3+b1 ii libgraph4 2.26.3-16.2 ii libgvc5 2.26.3-16.2 ii libgvpr12.26.3-16.2 ii libx11-62:1.6.2-1 ii libxaw7 2:1.0.12-1 ii libxmu6 2:1.1.1-1 ii libxt6 1:1.1.4-1 Versions of packages graphviz recommends: ii ttf-liberation 1.07.3-3 Versions of packages graphviz suggests: pn graphviz-doc none ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4.2 -- no debconf information -- Antonio Terceiro terce...@debian.org signature.asc Description: Digital signature
Bug#615876: Asciidoc: patch to remove duplicated files
Control: tags 615876 + patch thanks Dear Axel and Chrisitan, Please find attached the patch to correct the issue. Directories/files have been replaced by symlinks. Manpages that were in /usr/share/doc/asciidoc/doc (which had nothing to do there) were removed. I'll update the git repo tonight with this. Best regards, Joseph diff -u asciidoc-8.6.9/debian/asciidoc.links asciidoc-8.6.9/debian/asciidoc.links --- asciidoc-8.6.9/debian/asciidoc.links +++ asciidoc-8.6.9/debian/asciidoc.links @@ -1,4 +1,32 @@ -/etc/asciidoc/stylesheets/docbook-xsl.css /usr/share/doc/asciidoc/docbook-xsl.css +etc/asciidoc/filters/graphviz/asciidoc-graphviz-sample.txt usr/share/doc/asciidoc/examples/website/asciidoc-graphviz-sample.txt +etc/asciidoc/docbook-xsl/asciidoc-docbook-xsl.txt usr/share/doc/asciidoc/examples/website/asciidoc-docbook-xsl.txt +etc/asciidoc/stylesheets/asciidoc.css usr/share/doc/asciidoc/examples/website/asciidoc.css +etc/asciidoc/stylesheets/xhtml11-quirks.css usr/share/doc/asciidoc/examples/website/xhtml11-quirks.css +etc/asciidoc/stylesheets usr/share/asciidoc/stylesheets +etc/asciidoc/stylesheets/docbook-xsl.css usr/share/doc/asciidoc/docbook-xsl.css usr/share/asciidoc/images etc/asciidoc/images -usr/share/asciidoc/javascripts /etc/asciidoc/javascripts -/etc/asciidoc/stylesheets usr/share/asciidoc/stylesheets +usr/share/asciidoc/javascripts etc/asciidoc/javascripts +usr/share/asciidoc/icons usr/share/asciidoc/images/icons +usr/share/asciidoc/icons usr/share/doc/asciidoc/images/icons +usr/share/asciidoc/images usr/share/doc/asciidoc/doc/images +usr/share/asciidoc/images usr/share/doc/asciidoc/examples/website/images +usr/share/doc/asciidoc/doc/latex-bugs.txt usr/share/doc/asciidoc/examples/website/latex-bugs.txt +usr/share/asciidoc/javascripts/LaTeXMathML.js usr/share/doc/asciidoc/examples/website/LaTeXMathML.js +usr/share/asciidoc/javascripts/asciidoc.js usr/share/doc/asciidoc/examples/website/asciidoc.js +usr/share/asciidoc/javascripts/ASCIIMathML.js usr/share/doc/asciidoc/examples/website/ASCIIMathML.js +usr/share/doc/asciidoc/doc/epub-notes.txt usr/share/doc/asciidoc/examples/website/epub-notes.txt +usr/share/doc/asciidoc/doc/publishing-ebooks-with-asciidoc.txt usr/share/doc/asciidoc/examples/website/publishing-ebooks-with-asciidoc.txt +usr/share/doc/asciidoc/doc/faq.txt usr/share/doc/asciidoc/examples/website/faq.txt +usr/share/doc/asciidoc/doc/asciidocapi.txt usr/share/doc/asciidoc/examples/website/asciidocapi.txt +usr/share/doc/asciidoc/doc/asciidoc.1.txt usr/share/doc/asciidoc/examples/website/manpage.txt +usr/share/doc/asciidoc/doc/asciidoc.txt usr/share/doc/asciidoc/examples/website/userguide.txt +usr/share/doc/asciidoc/doc/testasciidoc.txt usr/share/doc/asciidoc/examples/website/testasciidoc.txt +usr/share/doc/asciidoc/doc/slidy-example.txt usr/share/doc/asciidoc/examples/website/slidy-example.txt +usr/share/doc/asciidoc/doc/customers.csv usr/share/doc/asciidoc/examples/website/customers.csv +usr/share/doc/asciidoc/doc/a2x.1.txt usr/share/doc/asciidoc/examples/website/a2x.1.txt +usr/share/doc/asciidoc/doc/source-highlight-filter.txt usr/share/doc/asciidoc/examples/website/source-highlight-filter.txt +usr/share/doc/asciidoc/doc/latex-backend.txt usr/share/doc/asciidoc/examples/website/latex-backend.txt +usr/share/doc/asciidoc/doc/music-filter.txt usr/share/doc/asciidoc/examples/website/music-filter.txt +usr/share/doc/asciidoc/doc/asciimathml.txt usr/share/doc/asciidoc/examples/website/asciimathml.txt +usr/share/doc/asciidoc/doc/latexmathml.txt usr/share/doc/asciidoc/examples/website/latexmathml.txt +usr/share/doc/asciidoc/doc/slidy.txt usr/share/doc/asciidoc/examples/website/slidy.txt diff -u asciidoc-8.6.9/debian/rules asciidoc-8.6.9/debian/rules --- asciidoc-8.6.9/debian/rules +++ asciidoc-8.6.9/debian/rules @@ -33,6 +33,7 @@ install -m0755 tests/testasciidoc.py debian/asciidoc/usr/bin/testasciidoc cp -aL examples/website/ debian/asciidoc/usr/share/doc/asciidoc/examples/ cp -aL doc/ debian/asciidoc/usr/share/doc/asciidoc/ + rm debian/asciidoc/usr/share/doc/asciidoc/doc/*.1 ./asciidoc.py -b xhtml11 -o debian/asciidoc/usr/share/doc/asciidoc/userguide.html doc/asciidoc.txt sed -i -e 's#./images/#/usr/share/asciidoc/images/#g' debian/asciidoc/usr/share/doc/asciidoc/userguide.html @@ -40,6 +41,36 @@ rm -rf debian/asciidoc/etc/asciidoc/javascripts rm -rf debian/asciidoc/etc/asciidoc/icons rm -rf debian/asciidoc/etc/asciidoc/images + rm -rf debian/asciidoc/usr/share/asciidoc/stylesheets + rm -rf debian/asciidoc/usr/share/doc/asciidoc/images/icons + rm -rf debian/asciidoc/usr/share/asciidoc/images/icons + rm -rf debian/asciidoc/usr/share/doc/asciidoc/doc/images + rm -rf debian/asciidoc/usr/share/doc/asciidoc/examples/website/images + rm debian/asciidoc/usr/share/doc/asciidoc/examples/website/latex-filter.txt + rm debian/asciidoc/usr/share/doc/asciidoc/examples/website/asciidoc-graphviz-sample.txt + rm
Bug#738848: osc: refuses to communicate with API server over IPv6
Package: osc Version: 0.143.0-1 Severity: normal Tags: ipv6 Dear Maintainer, If API server is available only through IPv6, OSC considers it to be unreachable. Failed to reach a server: [Errno 128] Network is unreachable: Meanwhile lynx can access same URL that osc fails with, from same host. Same effect is present on both, stable and testing version of osc. -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (900, 'stable'), (90, 'testing') Architecture: mipsel (mips64) Kernel: Linux 3.11-2-loongson-2f Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages osc depends on: ii ca-certificates20130119 ii python 2.7.3-4+deb7u1 ii python-m2crypto0.21.1-2 ii python-rpm 4.10.0-5+deb7u1 ii python-urlgrabber 3.9.1-4 Versions of packages osc recommends: ii cpio2.11+dfsg-0.1 pn python-keyring none ii rpm2cpio4.10.0-5+deb7u1 ii sensible-utils 0.0.7 Versions of packages osc suggests: pn gnome-keyringnone pn python-gnomekeyring 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#729138: jq: diff for NMU version 1.3-1.1
tags 729138 + patch thanks Dear maintainer, I've prepared an NMU for jq (versioned as 1.3-1.1). The diff is attached to this message. Regards. diff -Nru jq-1.3/debian/changelog jq-1.3/debian/changelog --- jq-1.3/debian/changelog 2013-10-16 21:58:13.0 +0200 +++ jq-1.3/debian/changelog 2014-02-13 13:32:34.0 +0100 @@ -1,3 +1,11 @@ +jq (1.3-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Remove build dependency on valgrind on archs where the valgrind +tests are disabled. (Closes: #729138) + + -- Christian Hofstaedtler z...@debian.org Thu, 13 Feb 2014 13:30:29 +0100 + jq (1.3-1) unstable; urgency=low * New upstream release. (Closes: #725118) diff -Nru jq-1.3/debian/control jq-1.3/debian/control --- jq-1.3/debian/control 2013-10-16 21:27:53.0 +0200 +++ jq-1.3/debian/control 2014-02-13 13:35:22.0 +0100 @@ -2,7 +2,7 @@ Section: utils Priority: optional Maintainer: Simon Elsbrock si...@iodev.org -Build-Depends: debhelper (= 8.0.0), dh-autoreconf, flex, bison, valgrind [linux-any], rake, ruby-ronn +Build-Depends: debhelper (= 8.0.0), dh-autoreconf, flex, bison, valgrind [amd64 i386], rake, ruby-ronn Standards-Version: 3.9.4 Homepage: https://github.com/stedolan/jq Vcs-Git: git://anonscm.debian.org/users/else-guest/jq.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738849: Please enable webview support for wx3.0
Package: libwxgtk3.0-0 Severity: serious The wx3.0 package *should* depend from libwebkitgtk-3.0-dev. The last boinc release needs webwview support, and I finally spotted why I didn't succeed in building it on a clean debian environment. Your build log clearly says that you are enabling webview checking for --enable-printarch... yes checking for --enable-svg... yes checking for --enable-webkit... yes checking for --enable-webview... yes checking for --enable-graphics_ctx... yes BUT after that you can see it gets disabled checking for linux/joystick.h... yes checking for python... /usr/bin/python configure: WARNING: webkitgtk not found. configure: WARNING: WebKit not available, disabling wxWebView checking for WEBKIT... checking for CAIRO... yes checking for cairo_push_group... yes boinc fails with this log, while building with a custom wx3.0 library doesn't fail. I can upload on mentors or a debdiff here if needed. thanks. G. /usr/include/wx-3.0/wx/vector.h:44:23: warning: previous declaration of 'void wxQsort(void*, size_t, size_t, wxSortCallback, const void*)' [-Wredundant-decls] WXDLLIMPEXP_BASE void wxQsort(void* pbase, size_t total_elems, ^ In file included from NoticeListCtrl.cpp:36:0: NoticeListCtrl.h:48:25: error: 'wxWebViewEvent' has not been declared void OnLinkClicked( wxWebViewEvent event ); ^ NoticeListCtrl.h:49:26: error: 'wxWebViewEvent' has not been declared void OnWebViewError( wxWebViewEvent event ); ^ NoticeListCtrl.h:59:5: error: 'wxWebView' does not name a type wxWebView* m_browser; ^ NoticeListCtrl.cpp:53:72: error: invalid use of non-static member function 'void CNoticeListCtrl::OnLinkClicked(int)' EVT_WEBVIEW_NAVIGATING(ID_LIST_NOTIFICATIONSVIEW, CNoticeListCtrl::OnLinkClicked) ^ NoticeListCtrl.cpp:53:85: error: 'EVT_WEBVIEW_NAVIGATING' was not declared in this scope EVT_WEBVIEW_NAVIGATING(ID_LIST_NOTIFICATIONSVIEW, CNoticeListCtrl::OnLinkClicked) ^ NoticeListCtrl.cpp:54:5: error: expected '}' before 'EVT_WEBVIEW_ERROR' EVT_WEBVIEW_ERROR(ID_LIST_NOTIFICATIONSVIEW, CNoticeListCtrl::OnWebViewError) Building wx [1] https://buildd.debian.org/status/fetch.php?pkg=wxwidgets3.0arch=i386ver=3.0.0-2stamp=1385783568 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583918: gnome-terminal: garbage left at bottom of max-height window
Hey, can you confirm if this bug is already fixed ? thanks regards althaser
Bug#738794: xterm: the right part of the window is not always erased
On 2014-02-13 06:55:05 -0500, Thomas Dickey wrote: On Thu, Feb 13, 2014 at 01:04:09AM +0100, Vincent Lefevre wrote: The right part of the window is not always erased. This happened with font fixed. See attached screenshot. There's no details on how to reproduce it, e.g., a) from repainting due to exposure events I don't know what you mean here, but a Ctrl-L has no effect on the right part. And if I switch the desktop and go back, the xterm window is still redrawn incorrectly. b) from resizing I don't remember whether the xterm has been resized. And I haven't tried to resize yet after the problem. c) from running some particular application It was a colored svn diff. d) another problem with the X server (seems that most recent issues reported by you in this area have been due to that) I don't know yet. I couldn't reproduce the bug. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738121: FORM try file.html not file.html? for local files
On Sat, Feb 08, 2014 at 05:33:33AM +0800, Dan Jacobson wrote: X-Debbugs-Cc: emacs-...@namazu.org Package: lynx-cur Version: 2.8.8pre4-1 File: /usr/bin/lynx $ ls er.html zaokeng.html $ cat er.html form action=zaokeng.htmlpinput type=submit/p/form clicking gets e.g., in emacs-w3m Cannot retrieve URL: file:///.../zaokeng.html? (http status: 200) Similar with lynx. w3m, Midori, chromium, firefox all know to try zaokeng.html not (or in addition to) zaokeng.html? for local files. emacs-w3m and lynx fail. actually it's not a failure: reading RFC 1866 and RFC 2616, there's no wording which would support this interpretation. Lacking any standard to cite, I'm reluctant to add a feature. There are two aspects: a) how to interpret a form for a file: uri b) whether to omit the ? which is explicitly cited in the RFCs. fwiw, Safari (6.1.1) and Chrome (32.0.1700.107) don't follow the interpretation suggested by this report. Internet Explorer 11 does - seems that this is just another case of Firefox copying IE's behavior without regard to the RFCs. -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#738850: ITP: iniparser -- a stand-alone INI file reading/writing library
Package: wnpp Severity: wishlist Owner: Klee Dienes k...@mit.edu * Package name: iniparser Version : 3.1-1 Upstream Author : Nicolas Devillard ndevi...@free.fr * URL : http://ndevilla.free.fr/iniparser * License : Expat Programming Lang: C Description : a stand-alone INI file reading/writing library The iniParser library is a simple C library offering INI file parsing services (both reading and writing). --- Note that there have been two previous ITPs posted for iniParser: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582657 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678142 There was concern in the discussion for #678142 about: 1) Lack of a well-formed build/install system (iniParser includes only a bare-bones Makefile). 2) Complexity (Does anything depend on this, any potential users that couldn't use something simpler?) I have addressed #1 by providing a CMake build environment for use by the Debian package. Regarding #2, my goal is to package the psmoveapi code for Debian, which uses the write support of iniparser (not supported by inih). I also note that Samba seems to include an internal version of iniParser. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738851: ITP: php-file-fstab -- Read and write fstab files
Package: wnpp Severity: wishlist Owner: Francois-Regis Vuillemin frv-deb...@miradou.com * Package name: php-file-fstab Version : 2.0.3 Upstream Author : Ian Eure ie...@php.net * URL : http://pear.php.net/package/File_Fstab * License : PHP Programming Lang: PHP Description : Read and write fstab files File_Fstab is an easy-to-use package which can read write UNIX fstab files. It presents a pleasant object-oriented interface to the fstab. Features: * Supports blockdev, label, and UUID specification of mount device. * Extendable to parse non-standard fstab formats by defining a new Entry class for that format. * Easily examine and set mount options for an entry. * Stable, functional interface. * Fully documented with PHPDoc. It is a dependency for horde3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738567: uses futimens, which is supported only on linux-any
Hello, David Kalnischkies, le Tue 11 Feb 2014 19:36:59 +0100, a écrit : On Mon, Feb 10, 2014 at 06:35:37PM +0100, Petr Salinger wrote: The apt 0.9.15.1 started to use futimens instead of previous utime. The futimens() is not supported on kfreebsd. Could this be added to the manpage utimensat(2)? I had looked there and assumed that by POSIX1.2008 and that it is in glibc it would be safe to use it as utime replacement… Well, but with old Linux kernels you would have the same issue. The futimes() is currently supported (at least) on linux, kfreebsd, hurd. It isn't part of any standard though, so I would worry now that we could run into problems with it as well. Indeed. But you could at least check for them in configure.ac and use what is available (autoconf will properly figure out that futimens are ENOSYS stubs in glibc on !linux, BTW). Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#604087: gnome-terminal: Typing into window is slow with transparency on and compositing disabled
Hey Mike, can you still reproduce this bug with gnome-terminal-3.4.1.1-2 ? transparency was gone with GNOME3.8. thanks regards althaser
Bug#738121: FORM try file.html not file.html? for local files
Never mind what shows up in the URL bar, $ chromium file:///.../file?xxx works just fine! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504290: [PATCH] Re: #504290: openssh-server: The sftp-server binary should have its own package
On Thu, Apr 29, 2010 at 02:08:24PM +0200, Axel Beckert wrote:
Stefan Monnier monn...@iro.umontreal.ca wrote:
the /usr/lib/sftp-server binary should be moved to a separate
package. The reason for it is that it is very useful in conjunction
with other ssh servers such as dropbear.
I'd be happy if that would happen, too, because dropbear doesn't
contain an sftp-server binary and therefore all the sftp based tools
like sshfs don't work with dropbear on the server-side unless you
install (but disable) the whole openssh-server package with all its
dependencies, too.
OpenWRT for example does have a separate sftp-server package and
therefore dropbear can be easily expanded to offer sftp support.
Following a patch against openssh 1:5.5p1-3 which splits off the
sftp-server binary into its own package. Tested with openssh-server
and dropbear on the server side and OpenSSH's sftp on the client side.
Thanks. Sorry I've left this for so long, mostly because I never wanted
to end up waiting in NEW. Just a few notes about things I would prefer
to be done differently (though no need to send a new patch):
diff -ruN openssh-5.5p1.orig/debian/control openssh-5.5p1/debian/control
--- openssh-5.5p1.orig/debian/control 2010-04-08 10:33:14.0 +0200
+++ openssh-5.5p1/debian/control2010-04-29 12:03:17.0 +0200
@@ -44,7 +44,7 @@
Priority: optional
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, debconf (= 1.2.0) |
debconf-2.0, libpam-runtime (= 0.76-14), libpam-modules (= 0.72-9), adduser
(= 3.9), dpkg (= 1.9.0), openssh-client (= ${binary:Version}), lsb-base (=
3.2-13), libssl0.9.8 (= 0.9.8g-9), openssh-blacklist, procps
-Recommends: xauth, openssh-blacklist-extra
+Recommends: xauth, openssh-blacklist-extra, openssh-sftp-server
Conflicts: ssh ( 1:3.8.1p1-9), ssh-nonfree (2), ssh-socks, ssh2, sftp,
rsh-client (0.16.1-1), ssh-krb5 ( 1:4.3p2-7)
Replaces: ssh, openssh-client ( 1:3.8.1p1-11), ssh-krb5
Suggests: ssh-askpass, rssh, molly-guard, ufw
diff -ruN openssh-5.5p1.orig/debian/NEWS openssh-5.5p1/debian/NEWS
--- openssh-5.5p1.orig/debian/NEWS 2010-04-10 02:09:11.0 +0200
+++ openssh-5.5p1/debian/NEWS 2010-04-29 11:52:53.0 +0200
@@ -1,3 +1,12 @@
+openssh (1:5.5p1-4) unstable; urgency=low
+
+ The sftp-server binary has been split out into its own package which is
+ only recommended by openssh-server. If you don't install recommended
+ packages by default, but need SFTP functionality on your SSH server,
+ please install also the new openssh-sftp-server package.
+
+ -- Axel Beckert a...@debian.org Thu, 29 Apr 2010 10:55:40 +0200
+
openssh (1:5.4p1-2) unstable; urgency=low
Smartcard support is now available using PKCS#11 tokens. If you were
I can see the rationale for openssh-sftp-server only recommending an SSH
server. But I see no sense in openssh-server only recommending
openssh-sftp-server; this bug doesn't ask for anything that would
require that, and it just brings us transitional pain. openssh-server
should simply depend on openssh-sftp-server.
+Conflicts: openssh-server (= 1:5.5p1-3)
+Replaces: openssh-server (= 1:5.5p1-3)
This should be Breaks/Replaces nowadays (I don't remember whether that
was standard practice at the time you sent your patch).
+ This package provides the SFTP server module for the SSH server. It
+ is needed if you want to access your SSH server with SFTP. The SFTP
+ server module also with other SSH daemons like dropbear.
... also works with
With these modifications, I've committed this to a local git branch,
which I'll merge after I get 6.5p1 into testing. Feel free to poke me
on IRC or whatever if I seem to have forgotten again.
Thanks,
--
Colin Watson [cjwat...@debian.org]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715436: fixed in glib2.0 2.38.1-1
this is not fixed. I have a Nikon camera, and when I plug it in, it brings up a window with the DCIM folder: gphoto2://[usb:006,008]/ yet when I try to copy the pictures from the camera to the computer I get the Operation not supported by backend. running Debian Jessie amd_64 cat /etc/os* PRETTY_NAME=Debian GNU/Linux jessie/sid NAME=Debian GNU/Linux ID=debian ANSI_COLOR=1;31 HOME_URL=http://www.debian.org/; SUPPORT_URL=http://www.debian.org/support/; BUG_REPORT_URL=http://bugs.debian.org/; -- Paul Cartwright Registered Linux User #367800 and new counter #561587 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
[ TL;DR: d-i FTBFS on sparc, what do we do now? ] Thomas Schmitt scdbac...@gmx.net (2013-12-10): Cyril Brulebois wrote: genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and './tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''. [...] Probably some FS-dependent fun? Anyone would have a clue about it? Looks like an internal error of genisoimage. '.' should be mapped to a 0x00-byte in ECMA-119, '..' to 0x01. See ECMA-119, 6.8.2.2 Identification of directories. These names are reserved for that purpose. Any other colliding ECMA-119 names should be handled by mangling. Thanks, Thomas. @Kurt: did anything change on the buildd setup side? Both lebrun and spontini got that FTBFS, while that wasn't the case before: https://buildd.debian.org/status/logs.php?pkg=debian-installerarch=sparc genisoimage comes from src:cdrkit, which wasn't exactly updated in a while: http://packages.qa.debian.org/c/cdrkit.html I've got to double check what happens on smetana, but I think I didn't get that error when trying to debug this FTBFS a few months ago. I'm not sure we want to continuously give it back until it builds (which it might on schroeder, since it didn't fail there yet)… Failing a short resolution, I'm tempted to pretend sparc isn't an issue, and maybe ask for a migration to testing + dak copy-installer. @debian-release: would that sound reasonable? @ftpmasters: I'm not sure an out-of-date build is going to be OK on the dak side. What do you think? But why is that mini.iso produced by genisoimage at all ? debian-7.2.0-sparc-netinst.iso was produced by xorriso. @Thomas: Probably due to historical reasons. Not sure I want to be touching that since I know nothing about architecture/image-specific settings. :/ Mraw, KiBi. signature.asc Description: Digital signature
Bug#732550: Backtraces
I figured out how to keep the coredumps with corekeeper and how to get the backtraces. I've attached the backtraces of three crashes from 6090b3dc; I hope they help to isolate this issue. If you need more details from the coredumps, I can retrieve those (please post the necessary gdb instructions, I'm not too familiar with gdb), but for data privacy reasons, I'm unfortunately unable to post the complete coredumps here because they contain private mails of our users. Martin (gdb) bt #0 0x08119e2c in Perl_leave_scope (my_perl=my_perl@entry=0xa1b4008, base=368) at scope.c:738 #1 0x0811ab77 in Perl_pop_scope (my_perl=my_perl@entry=0xa1b4008) at scope.c:110 #2 0x08122b49 in Perl_die_unwind (my_perl=my_perl@entry=0xa1b4008, msv=msv@entry=0xc727430) at pp_ctl.c:1759 #3 0x080c5ef6 in Perl_croak_sv (my_perl=my_perl@entry=0xa1b4008, baseex=baseex@entry=0xa1b779c) at util.c:1579 #4 0x080c5f17 in Perl_die_sv (my_perl=my_perl@entry=0xa1b4008, baseex=0xa1b779c) at util.c:1512 #5 0x080d2707 in Perl_sighandler (sig=14, sip=0x33, uap=0x0) at mg.c:3138 #6 signal handler called #7 0x08142d2c in S_regcppop (my_perl=my_perl@entry=0xa1b4008, rex=rex@entry=0xb455ea0) at regexec.c:418 #8 0x08147533 in S_regmatch (prog=0xb4711fc, reginfo=0xbfd97ec8, my_perl=0xa1b4008) at regexec.c:4757 #9 S_regtry (my_perl=my_perl@entry=0xa1b4008, reginfo=reginfo@entry=0xbfd97ec8, startpos=startpos@entry=0xbfd97dec) at regexec.c:2622 #10 0x0814edfe in S_find_byclass (my_perl=my_perl@entry=0xa1b4008, prog=prog@entry=0xb455ea0, c=c@entry=0xb4711fc, s=0xc8e218f ' ' repeats 21 times, \nab 60 €U\002, s@entry=0xc8e2118 --645945410240351\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit\n\n\nUnsere Besten:\n\nBinz, Loev, ' ' repeats 22 times, \nab 60 €U\002, strend=strend@entry=0xc916f7a /body\n/html\n \n--645945410240351--\n, reginfo=reginfo@entry=0xbfd97ec8) at regexec.c:1416 #11 0x0815510f in Perl_regexec_flags (my_perl=0xa1b4008, rx=0xb43b9d0, stringarg=0xc8e2118 --645945410240351\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit\n\n\nUnsere Besten:\n\nBinz, Loev, ' ' repeats 22 times, \nab 60 €U\002, strend=0xc916f7a /body\n/html\n \n--645945410240351--\n, strbeg=0xc8e2118 --645945410240351\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit\n\n\nUnsere Besten:\n\nBinz, Loev, ' ' repeats 22 times, \nab 60 €U\002, minend=0, sv=0xb4371b4, data=0x0, flags=3) at regexec.c:2350 #12 0x080e63e9 in Perl_pp_match (my_perl=0xa1b4008) at pp_hot.c:1386 #13 0x080e2898 in Perl_runops_standard (my_perl=0xa1b4008) at run.c:41 #14 0x0807ede0 in S_run_body (oldscope=optimized out, my_perl=optimized out) at perl.c:2345 #15 perl_run (my_perl=0xa1b4008) at perl.c:2268 #16 0x0806124f in main (argc=8, argv=0xbfd98194, env=0xbfd981b8) at perlmain.c:120 (gdb) bt #0 0x08119d02 in Perl_leave_scope (my_perl=my_perl@entry=0x9d1d008, base=406) at scope.c:777 #1 0x0811ab77 in Perl_pop_scope (my_perl=my_perl@entry=0x9d1d008) at scope.c:110 #2 0x08122b49 in Perl_die_unwind (my_perl=my_perl@entry=0x9d1d008, msv=msv@entry=0xc51728c) at pp_ctl.c:1759 #3 0x080c5ef6 in Perl_croak_sv (my_perl=my_perl@entry=0x9d1d008, baseex=baseex@entry=0x9d2079c) at util.c:1579 #4 0x080c5f17 in Perl_die_sv (my_perl=my_perl@entry=0x9d1d008, baseex=0x9d2079c) at util.c:1512 #5 0x080d2707 in Perl_sighandler (sig=14, sip=0x33, uap=0x0) at mg.c:3138 #6 signal handler called #7 0x08142d32 in S_regcppop (my_perl=my_perl@entry=0x9d1d008, rex=rex@entry=0xafc3fa8) at regexec.c:418 #8 0x08147533 in S_regmatch (prog=0xafb323c, reginfo=0xbfd6dd48, my_perl=0x9d1d008) at regexec.c:4757 #9 S_regtry (my_perl=my_perl@entry=0x9d1d008, reginfo=reginfo@entry=0xbfd6dd48, startpos=startpos@entry=0xbfd6dc6c) at regexec.c:2622 #10 0x0814edfe in S_find_byclass (my_perl=my_perl@entry=0x9d1d008, prog=prog@entry=0xafc3fa8, c=c@entry=0xafb323c, s=0xd3623ca \n, '=' repeats 72 times, \n, ' ' repeats 28 times, Smeet NewsletterU\002, s@entry=0xd362358 --b1_7249a8dfcf91bf10ce3b08d0b3585c35\nContent-Type: text/plain; charset = \UTF-8\\nContent-Transfer-Encoding: 8bit\n\n, '=' repeats 72 times, \n, ' ' repeats 12 times..., strend=strend@entry=0xd366422 -b1_7249a8dfcf91bf10ce3b08d0b3585c35--\n, reginfo=reginfo@entry=0xbfd6dd48) at regexec.c:1416 #11 0x0815510f in Perl_regexec_flags (my_perl=0x9d1d008, rx=0xafa52d4, stringarg=0xd362358 --b1_7249a8dfcf91bf10ce3b08d0b3585c35\nContent-Type: text/plain; charset = \UTF-8\\nContent-Transfer-Encoding: 8bit\n\n, '=' repeats 72 times, \n, ' ' repeats 12 times..., strend=0xd366422 -b1_7249a8dfcf91bf10ce3b08d0b3585c35--\n, strbeg=0xd362358 --b1_7249a8dfcf91bf10ce3b08d0b3585c35\nContent-Type: text/plain; charset = \UTF-8\\nContent-Transfer-Encoding: 8bit\n\n, '=' repeats 72 times, \n, ' ' repeats 12 times..., minend=0, sv=0xafa4eec, data=0x0, flags=3) at regexec.c:2350 #12 0x080e63e9 in Perl_pp_match
Bug#727708: init system coupling etc.
Ian Jackson ijack...@chiark.greenend.org.uk writes: [...] I don't find Sjoerd Simons's comments very reassuring. In the context of the whole discussion I think Adrian's interpretation is much more likely to reflect the true sentiment. I wouldn't give Adrian too much credit. Please read some other emails between him and fellow developers in this bug. Especially [0]. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4652 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708577: Moreinfo
On Tuesday, 1. October 2013 07:14:51 Krzysztof Marczak wrote: Yes, I use ATI propietary driver. Actually I use newest from testing fglrx 13.4-3. I will check fglrx 13.8 when It will be migrated to testing (I will not use from experimental because I need quite stable OpenCL library). Please test 13.12 (in jessie) and 14.1~beta (soon in sid). Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738852: [g++-4.8] unrecognized command line option ?-std=c++-11?
Package: g++-4.8 Version: 4.8.2-14 Severity: normal As stated in the mail subject -std=c++-11 flag is not recognized by g++-4.8 This seems to be in contradiction with g++ 4.8 doc: see http://gcc.gnu.org/onlinedocs/gcc-4.8.2/libstdc++/manual/manual/using.html#manual.intro.using.flags --- System information. --- Architecture: amd64 Kernel: Linux 3.12-1-amd64 Debian Release: jessie/sid 500 testing-proposed-updates ftp.fr.debian.org 500 testing security.debian.org 500 testing http.us.debian.org 500 testing ftp.fr.debian.org 500 testing euler.lcmi.local 500 stable dl.google.com 500 sid linux.dropbox.com 500 jessie neuro.debian.net 500 dataneuro.debian.net --- Package information. --- Depends (Version) | Installed ==-+-= gcc-4.8-base (= 4.8.2-14) | gcc-4.8 (= 4.8.2-14) | libstdc++-4.8-dev (= 4.8.2-14) | libc6(= 2.14) | libcloog-isl4(= 0.17) | libgmp10 | libisl10 (= 0.10) | libmpc3| libmpfr4(= 3.1.2) | zlib1g(= 1:1.1.4) | Package's Recommends field is empty. Suggests (Version) | Installed -+-== g++-4.8-multilib | 4.8.2-14 gcc-4.8-doc (= 4.8) | 4.8.2-2 libstdc++6-4.8-dbg (= 4.8.2-14) | -- Christophe TROPHIME Research Engineer LNCMI CNRS - LNCMI 25, rue des Martyrs BP 166 38042 GRENOBLE Cedex 9 FRANCE CNRS Tel : +33 (0)4 76 88 90 02 Fax : +33 (0) 4 76 88 10 01 Office U 19 M@il : christophe.troph...@lncmi.cnrs.fr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729203: CTTE and reasonable solutions
Hi Rogério, thanks for looking into resolving this situation. I haven't read every last mail in the history of this issue and recently have confined myself to just this bug. There's obviously a detailed history and a lot of animosity. I'd say first and foremost, I miss ffmpeg most as a command-line tool. The tools that link to libav (VLC etc.) seem to continue to work fine from a user's perspective. I appreciate that there might be a lot of pain for maintainers below the water line (more on that later). Reading some of the comments on this bug, I think many users are similarly missing ffmpeg as a command line tool and are not as concerned about the library side of things. So, I fully support packaging ffmpeg as a binary package for the command line client at the very least, and perhaps as a necessary first step. If the debian multimedia team are not interested in doing that, fine, they don't have to. But it would be wrong for them IMHO to prevent some other interested party from doing so. Back to maintainers linking against libav. You have said yourself that the effort involved to get e.g. handbrake to work with Debian's libav was herculean (not your exact words I know). I believe that, if ffmpeg libraries and libav libraries can co-exist in the archive, it should be a maintainer's choice which they link against. So, if it were possible for ffmpeg's libraries to be packaged without interfering with existing clients of libav's libraries, a maintainer such as yourself for handbrake[1] could choose to use ffmpeg, that would be the maintainer's right. I suspect that the animosity I've read in this thread from people towards ffmpeg in the archive as libraries is due to concerns about how practical it would be for them to co-exist. These are probably valid concerns that should be looked at. However, they can be, by exploring real packaging attempts outside the archive (or using experimental) rather than arguing about theoretics. So as a first step and addressing many of the requests here I think we should push on to get the binary packaged on it's own, for now. A good starting place would be a git repository for the packaging. Should we base this on the pre-libav ffmpeg package, or start afresh? [1] perhaps a bad example since it's yourself with the debian multimedia team... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738850: ITP: iniparser -- a stand-alone INI file reading/writing library
Hello, On 13 February 2014 14:12, Klee Dienes k...@mit.edu wrote: The iniParser library is a simple C library offering INI file parsing services (both reading and writing). 2) Complexity (Does anything depend on this, any potential users that couldn't use something simpler?) Regarding #2, my goal is to package the psmoveapi code for Debian, which uses the write support of iniparser (not supported by inih). I also note that Samba seems to include an internal version of iniParser. Well, we've just removed libmcs which did support writing ini files... Is there really nothing else in archive already to support writing them? -- Cheers, Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
