Bug#743169: osgDB_freetype.so no longer built
This appears to be fixed upstream, but I haven't tried building that: https://github.com/openscenegraph/osg/commit/3063b45aba74a0cfc693d46866084cde0d8959e2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743679: octave: plot(1:4) triggers segfault crash
Package: octave Version: 3.8.1-1+b1 Severity: important This bug was introduced after upgrading to Octave 3.8.1-1+b1, and the bug was not there in 3.8.0 (I am not sure about this version number. I can only remember that it was already 3.8, introducing the experimental gui). Just fresh install octave: $ sudo apt-get update $ sudo apt-get upgrade $ sudo apt-get install octave Then open octave [using --norc/--no-gui/--jit-compiler does not affect the segfault]: neo@testing ~> which octave /usr/bin/octave neo@testing ~> octave GNU Octave, version 3.8.1 Copyright (C) 2014 John W. Eaton and others. This is free software; see the source code for copying conditions. There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. For details, type 'warranty'. Octave was configured for "x86_64-pc-linux-gnu". Additional information about Octave is available at http://www.octave.org. Please contribute if you find this software useful. For more information, visit http://www.octave.org/get-involved.html Read http://www.octave.org/bugs.html to learn how to submit bug reports. For information about changes from previous versions, type 'news'. octave:1> plot(1:4) panic: Segmentation fault -- stopping myself... attempting to save variables to 'octave-workspace'... save to 'octave-workspace' complete neo@testing ~> octave -q > load octave-workspace > whos > # there is no variables here So the octave-workspace does not provide any information. A figure window opens, and then closed again after the segfault. If we try opening figure by itself calling `figure', there was no segfault, until one of the following operations was performed: 1. Pushing `A' button at the down-left corner, or Edit->Autoscale 2. Pushing `G' button at the down-left cornet, or Edit->Grid Any other interaction with this figure does not crash octave. P.S. I am not sure if this is the same problem, but I think it is better to include it here. After installing octave-psychtoolbox-3, calling DrawSomeTextDemo or DotRotDemo provided by psychtoolbox, also crashes with segfault, though this does not use figure. That package extensively uses OpenGL. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages octave depends on: ii default-jre-headless 2:1.7-51 ii libamd2.3.1 1:4.2.1-3 ii libarpack2 3.1.5-2 ii libatlas3-base [liblapack.so.3] 3.10.1-4 ii libblas3 [libblas.so.3] 1.2.20110419-7 ii libc62.18-4 ii libcamd2.3.1 1:4.2.1-3 ii libccolamd2.8.0 1:4.2.1-3 ii libcholmod2.1.2 1:4.2.1-3 ii libcolamd2.8.0 1:4.2.1-3 ii libcxsparse3.1.2 1:4.2.1-3 ii libfftw3-double3 3.3.3-7 ii libfftw3-single3 3.3.3-7 ii libfltk-gl1.31.3.2-4 ii libfltk1.3 1.3.2-4 ii libfontconfig1 2.11.0-2 ii libfreetype6 2.5.2-1 ii libgcc1 1:4.8.2-16 ii libgl1-mesa-glx [libgl1] 10.1.0-4 ii libglpk364.53-2 ii libglu1-mesa [libglu1] 9.0.0-2 ii libgomp1 4.8.2-16 ii libgraphicsmagick++3 1.3.18-1 ii libgraphicsmagick3 1.3.18-1 ii liblapack3 [liblapack.so.3] 3.5.0-2 ii liboctave2 3.8.1-1+b1 ii libqhull62012.1-4 ii libqrupdate1 1.1.2-1 ii libqscintilla2-112.8.1-1 ii libqt4-network 4:4.8.5+git242-g0315971+dfsg-2 ii libqtcore4 4:4.8.5+git242-g0315971+dfsg-2 ii libqtgui44:4.8.5+git242-g0315971+dfsg-2 ii libstdc++6 4.8.2-16 ii libumfpack5.6.2 1:4.2.1-3 ii libx11-6 2:1.6.2-1 ii octave-common3.8.1-1 ii texinfo 5.2.0.dfsg.1-2 Versions of packages octave recommends: ii gnuplot-x11 4.6.5-1 ii libatlas3-base 3.10.1-4 ii pstoedit3.62-1 Versions of packages octave suggests: pn octave-doc pn octave-htmldoc ii octave-info 3.8.1-1 -- no debconf information
Bug#741730: wxsqlite3: Please update to use wxwidgets3.0
Hi James, On Sat, Apr 5, 2014 at 1:58 AM, James Cowgill wrote: > Control: block 639782 by -1 I'm not sure you need wxSQLite3 for CodeLite. Did you check? > I'm intending to adopt CodeLite. Since the new version I want to upload > uses wxWidgets 3, it depends on this bug being fixed. So it would be > nice if this could be updated sometime soon :) I'll upload it to experimental soon. But if you need only wxWidgets3, then you are ready to go. It's already in the archive[1]. Regards, Laszlo/GCS [1] http://packages.qa.debian.org/w/wxwidgets3.0.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743565: cacti: CVE-2014-2708 CVE-2014-2709
Control: found -1 0.8.7g-1+squeeze3 Control: found 742768 0.8.7g-1+squeeze3 On 04/03/14 21:30, Salvatore Bonaccorso wrote: > If you fix the vulnerabilities please also make sure to include the > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. Hi security team, Do you consider these vulnerabilities severe enough to require fixing through security updates, or is the update via (old-)stable-updates good enough? The last fix CVE-2014-2327 is still being made, but I can (and am preparing) upload fixes for the other four current CVE issues. Do you want me to get the current fixes already in, or wait one more week to get all five fixes into Debian in one go. (For the record, I will upload the four fixes to sid real soon anyways). Paul signature.asc Description: OpenPGP digital signature
Bug#743680: distributed-net: [INTL:ja] New Japanese debconf translation
Package: distributed-net Version: 2.9111.520-2 Severity: wishlist Tags: patch l10n Dear distributed-net package maintainer, Here's Japanese po-debconf template translation (ja.po) file that reviewed by several Japanese Debian developers and users. Could you apply it, please? note: attachments are: one for the one bubulle attached (*) and another for patched w/ I pointed (**) * https://lists.debian.org/debian-i18n/2014/04/msg2.html ** https://lists.debian.org/debian-i18n/2014/04/msg3.html -- victory http://userscripts.org/scripts/show/102724 0.0.1.4 http://userscripts.org/scripts/show/163846 0.0.1 http://userscripts.org/scripts/show/163848 0.0.1 -- victory no need to CC me :-) http://userscripts.org/scripts/show/102724 0.0.1.4 http://userscripts.org/scripts/show/163846 0.0.1 http://userscripts.org/scripts/show/163848 0.0.1 distributed-net_2.9111.520-2_ja.po.gz Description: Binary data distributed-net_2.9111.520-2-2_ja.po.gz Description: Binary data
Bug#740928: Similar problem
Hi, I just updated my SID tonight after a couple of weeks, and I have a similar problem... - gdm3 doesn't display anything at all - xdm lets me log in, but then shows the 'oh no' error - startx shows the 'oh no' error. `dmesg | grep fault` returns [ 985.748377] gnome-shell[7625]: segfault at c ip 7f6924755b10 sp 7fff286a85f8 error 4 in libxcb-glx.so.0.0.0[7f6924748000+15000] I have also found the following odd behaviour: X& starts X, but the mouse does not appear. Then I run DISPLAY=:0.0 xterm& which starts a terminal, but still, I don't have focus, not a mouse pointer. I kill with ^C the terminal, and now, X has a pointer. I can now start apps like xterm, or xmonad and use them. gnome-shell, though, doesn't work: (gnome-shell:6404): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL' failed (gnome-shell:6404): Clutter-CRITICAL **: Unable to initialize Clutter: The OpenGL version could not be determined Window manager error: Unable to initialize Clutter. FWIW, I'm using the latest Catalyst driver from amd's website. Cheers, P! signature.asc Description: This is a digitally signed message part
Bug#743681: distributed-net: [INTL:ru] Russian debconf templates translation
Package: distributed-net Version: 2.9111.520-2 Severity: wishlist Tags: l10n patch Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** Russian debconf templates translation is attached. -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf armel Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ru.po.gz Description: GNU Zip compressed data
Bug#743682: kdm: Laptop with lid closed: System goes to suspend when shutting down (using systemd)
Package: kdm Version: 4:4.11.7-1+b1 Severity: important Dear Maintainer, Steps to reproduce: * On a laptop, after pressing the power button, close the lid and exclusively use the external mouse, keyboard and screen. * Make sure the power plug is plugged in all the time. * Log in to KDE, work for a while, then shut the machine down. Actual behaviour: * The machine logs out, and then goes to suspend. After resuming from suspend, the shutdown continues. Expected behaviour: * The machine should shut down. Note that I am using systemd. I can "fix" this by telling systemd not to go to suspend when the lid is closed: I just have to add 'HibernateMode=disabled' to /etc/systemd/sleep.conf. However, I'd definitely like the machine to suspend when the lid is closed and AC power is off, so that's not a good solution. I don't think it's that uncommon to use a laptop with the lid closed, so this setup should work without any special configuration. Maybe this bug ought to be assigned to systemd instead, I don't know. Certainly, systemd does not suspend my machine when I close the lid while I am logged in to KDE, presumably because PowerDevil does the work then and tells systemd not to get in its way. Kind regards Ralf -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-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 Versions of packages kdm depends on: ii adduser 3.113+nmu3 ii consolekit0.4.6-4 ii debconf [debconf-2.0] 1.5.52 ii kde-runtime 4:4.11.5-1 ii kde-wallpapers-default4:4.11.5-1 ii kde-workspace-kgreet-plugins 4:4.11.7-1+b1 ii libc6 2.18-4 ii libck-connector0 0.4.6-4 ii libdbus-1-3 1.8.0-3 ii libkdecore5 4:4.11.5-1 ii libkdeui5 4:4.11.5-1 ii libkio5 4:4.11.5-1 ii libknewstuff3-4 4:4.11.5-1 ii libkworkspace4abi24:4.11.7-1+b1 ii libpam0g 1.1.8-2 ii libqimageblitz4 1:0.0.6-4 ii libqt4-svg4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-xml4:4.8.5+git242-g0315971+dfsg-2 ii libqtcore44:4.8.5+git242-g0315971+dfsg-2 ii libqtgui4 4:4.8.5+git242-g0315971+dfsg-2 ii libstdc++64.8.2-16 ii libx11-6 2:1.6.2-1 ii libxau6 1:1.0.8-1 ii libxdmcp6 1:1.1.1-1 ii libxtst6 2:1.2.2-1 ii lsb-base 4.1+Debian12 Versions of packages kdm recommends: ii kde-window-manager [x-window-manager] 4:4.11.7-1+b1 ii kde-workspace 4:4.11.7-1 ii konsole [x-terminal-emulator] 4:4.11.3-1 ii logrotate 3.8.7-1 ii xserver-xephyr [xserver] 2:1.15.0-2 ii xserver-xorg [xserver] 1:7.7+6 ii xterm [x-terminal-emulator]303-1 Versions of packages kdm suggests: ii kde-wallpapers 4:4.11.5-1 ii kdepasswd 4:4.11.5-2 -- Configuration Files: /etc/kde4/kdm/kdmrc changed: [General] ConfigVersion=2.4 ConsoleTTYs=tty1,tty2,tty3,tty4,tty5,tty6 GreeterUID=kdm PidFile=/var/run/kdm.pid ReserveServers=:1,:2,:3 ServerVTs=-7 StaticServers=:0 [Shutdown] BootManager=None HaltCmd=/sbin/shutdown -h -P now RebootCmd=/sbin/shutdown -r now [X-*-Core] AllowNullPasswd=false AllowRootLogin=false AllowShutdown=Root AutoReLogin=false ClientLogFile=.xsession-errors-%d Reset=/etc/kde4/kdm/Xreset Session=/etc/kde4/kdm/Xsession Setup=/etc/kde4/kdm/Xsetup Startup=/etc/kde4/kdm/Xstartup [X-*-Greeter] AntiAliasing=false ColorScheme= FaceSource=AdminOnly FailFont=Sans Serif,10,-1,5,75,0,0,0,0,0 GUIStyle= GreetFont=Serif,20,-1,5,50,0,0,0,0,0 GreetString=Welcome to %s at %n GreeterPos=50,50 HiddenUsers= Language=en_US LogoArea=Logo LogoPixmap=/usr/share/kde4/apps/kdm/pics/kdelogo.png MaxShowUID=2 MinShowUID=1000 Preloader=/usr/bin/preloadkde SelectedUsers= ShowUsers=NotHidden SortUsers=true StdFont=Sans Serif,10,-1,5,50,0,0,0,0,0 Theme=/usr/share/kde4/apps/kdm/themes/joy UseBackground=true UseTheme=true UserCompletion=false UserList=true [X-:*-Core] AllowNullPasswd=true AllowShutdown=All NoPassEnable=false NoPassUsers= ServerArgsLocal=-br -nolisten tcp ServerCmd=/usr/bin/X [X-:*-Greeter] AllowClose=true DefaultUser=kde FocusPasswd=true LoginMode=DefaultLocal PreselectUser=None [X-:0-Core] AutoLoginEnable=false AutoLoginLocked=false AutoLoginUser= ClientLogFile=.xsession-errors [Xdmcp] Enable=false Willing=/etc/kde4/kdm/Xwilling -- debconf information: * shared/default-x-display-manager: lightdm kdm/daemon_name: /usr/bin/kdm kdm/stop_running_server_with_children: false
Bug#743683: libspatialite5: arch-dependent file in "Multi-Arch: same" package
Package: libspatialite5
Version: 4.1.1-8
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch
libspatialite5 is marked as "Multi-Arch: same", but the following file
is architecture-dependent:
/usr/share/doc/libspatialite5/examples/Makefile.gz
An example diff between i386 and amd64 (after ungzipping) is attached.
--
Jakub Wilk
diff -ur
libspatialite5_4.1.1-8_i386/usr/share/doc/libspatialite5/examples/Makefile
libspatialite5_4.1.1-8_amd64/usr/share/doc/libspatialite5/examples/Makefile
--- libspatialite5_4.1.1-8_i386/usr/share/doc/libspatialite5/examples/Makefile
2014-04-04 13:31:08.0 +0200
+++ libspatialite5_4.1.1-8_amd64/usr/share/doc/libspatialite5/examples/Makefile
2014-04-04 13:03:06.0 +0200
@@ -76,8 +76,8 @@
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
-build_triplet = i486-pc-linux-gnu
-host_triplet = i486-pc-linux-gnu
+build_triplet = x86_64-pc-linux-gnu
+host_triplet = x86_64-pc-linux-gnu
noinst_PROGRAMS = demo1$(EXEEXT) demo2$(EXEEXT) demo3$(EXEEXT) \
demo4$(EXEEXT) demo5$(EXEEXT)
subdir = examples
@@ -180,14 +180,14 @@
ETAGS = etags
CTAGS = ctags
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
-ACLOCAL = ${SHELL} /build/spatialite-UKvjvG/spatialite-4.1.1/missing
aclocal-1.14
+ACLOCAL = ${SHELL} /tmp/buildd/spatialite-4.1.1/missing aclocal-1.14
AMTAR = $${TAR-tar}
AM_DEFAULT_VERBOSITY = 1
AR = ar
AS = as
-AUTOCONF = ${SHELL} /build/spatialite-UKvjvG/spatialite-4.1.1/missing autoconf
-AUTOHEADER = ${SHELL} /build/spatialite-UKvjvG/spatialite-4.1.1/missing
autoheader
-AUTOMAKE = ${SHELL} /build/spatialite-UKvjvG/spatialite-4.1.1/missing
automake-1.14
+AUTOCONF = ${SHELL} /tmp/buildd/spatialite-4.1.1/missing autoconf
+AUTOHEADER = ${SHELL} /tmp/buildd/spatialite-4.1.1/missing autoheader
+AUTOMAKE = ${SHELL} /tmp/buildd/spatialite-4.1.1/missing automake-1.14
AWK = mawk
CC = gcc
CCDEPMODE = depmode=none
@@ -219,7 +219,7 @@
INSTALL_PROGRAM = ${INSTALL}
INSTALL_SCRIPT = ${INSTALL}
INSTALL_STRIP_PROGRAM = $(install_sh) -c -s
-LD = /usr/bin/ld
+LD = /usr/bin/ld -m elf_x86_64
LDFLAGS = -Wl,-z,relro
LIBOBJS =
LIBS = -lfreexl -lproj -lz -lsqlite3 -L/usr/lib -lgeos_c
@@ -230,7 +230,7 @@
LN_S = ln -s
LTLIBOBJS =
MAINT = #
-MAKEINFO = ${SHELL} /build/spatialite-UKvjvG/spatialite-4.1.1/missing makeinfo
+MAKEINFO = ${SHELL} /tmp/buildd/spatialite-4.1.1/missing makeinfo
MANIFEST_TOOL = :
MKDIR_P = /bin/mkdir -p
NM = /usr/bin/nm -B
@@ -256,10 +256,10 @@
SHELL = /bin/bash
STRIP = strip
VERSION = 4.1.1
-abs_builddir = /build/spatialite-UKvjvG/spatialite-4.1.1/examples
-abs_srcdir = /build/spatialite-UKvjvG/spatialite-4.1.1/examples
-abs_top_builddir = /build/spatialite-UKvjvG/spatialite-4.1.1
-abs_top_srcdir = /build/spatialite-UKvjvG/spatialite-4.1.1
+abs_builddir = /tmp/buildd/spatialite-4.1.1/examples
+abs_srcdir = /tmp/buildd/spatialite-4.1.1/examples
+abs_top_builddir = /tmp/buildd/spatialite-4.1.1
+abs_top_srcdir = /tmp/buildd/spatialite-4.1.1
ac_ct_AR = ar
ac_ct_CC = gcc
ac_ct_CXX = g++
@@ -270,9 +270,9 @@
am__tar = $${TAR-tar} chof - "$$tardir"
am__untar = $${TAR-tar} xf -
bindir = ${exec_prefix}/bin
-build = i486-pc-linux-gnu
-build_alias = i486-linux-gnu
-build_cpu = i486
+build = x86_64-pc-linux-gnu
+build_alias = x86_64-linux-gnu
+build_cpu = x86_64
build_os = linux-gnu
build_vendor = pc
builddir = .
@@ -281,17 +281,17 @@
docdir = ${datarootdir}/doc/${PACKAGE_TARNAME}
dvidir = ${docdir}
exec_prefix = ${prefix}
-host = i486-pc-linux-gnu
+host = x86_64-pc-linux-gnu
host_alias =
-host_cpu = i486
+host_cpu = x86_64
host_os = linux-gnu
host_vendor = pc
htmldir = ${docdir}
includedir = ${prefix}/include
infodir = ${prefix}/share/info
-install_sh = ${SHELL} /build/spatialite-UKvjvG/spatialite-4.1.1/install-sh
-libdir = ${prefix}/lib/i386-linux-gnu
-libexecdir = ${prefix}/lib/i386-linux-gnu
+install_sh = ${SHELL} /tmp/buildd/spatialite-4.1.1/install-sh
+libdir = ${prefix}/lib/x86_64-linux-gnu
+libexecdir = ${prefix}/lib/x86_64-linux-gnu
localedir = ${datarootdir}/locale
localstatedir = /var
mandir = ${prefix}/share/man
Bug#743684: mediawiki 1:1.19.15+dfsg-0+deb7u1 incompatible with mediawiki-classes 1:1.19.14+dfsg-1
Package: mediawiki Version: 1:1.19.14+dfsg-1 Severity: important Hello, mediawiki 1:1.19.15+dfsg-0+deb7u1 is incompatible with mediawiki-classes 1:1.19.14+dfsg-1 in testing. During installation of mediawiki 1:1.19.15+dfsg-0+deb7u1 in testing, I have the error: " dpkg: error processing archive /var/cache/apt/archives/mediawiki_1%3a1.19.15+dfsg-0+deb7u1_all.deb (--unpack): tentative de remplacement de « /usr/share/mediawiki/includes/libs/IEUrlExtension.php », qui appartient aussi au paquet mediawiki-classes 1:1.19.14+dfsg-1 " Thank you. Regards, Pierre Crescenzo -- System Information: Debian Release: jessie/sid Architecture: i386 (i686) Kernel: Linux 3.13-1-686-pae (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mediawiki depends on: ii apache2 2.4.9-1 ii apache2-bin [httpd] 2.4.9-1 ii cdebconf [debconf-2.0] 0.189 ii debconf [debconf-2.0] 1.5.52 ii libjs-jquery1.7.2+dfsg-3 ii libjs-jquery-cookie 9-1 ii libjs-jquery-form 9-1 ii libjs-jquery-tipsy 9-1 ii mediawiki-classes 1:1.19.14+dfsg-1 ii mime-support3.54 ii php55.5.10+dfsg-1 ii php5-mysql 5.5.10+dfsg-1 ii php5-pgsql 5.5.10+dfsg-1 ii php5-sqlite 5.5.10+dfsg-1 Versions of packages mediawiki recommends: ii mediawiki-extensions-base 3.6 ii mysql-server 5.5.35+dfsg-2 ii php-wikidiff2 0.0.1+svn109581-1+b1 ii php5-cli 5.5.10+dfsg-1 ii python 2.7.5-5 Versions of packages mediawiki suggests: ii clamav 0.98.1+dfsg-4 ii imagemagick8:6.7.7.10+dfsg-1 ii mediawiki-extensions-math 2:1.0+git20120528-8 pn memcached ii php5-gd5.5.10+dfsg-1 -- debconf information: * mediawiki/webserver: apache2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742275: Info received (Patch queued upstream)
Hei hei, upstream applied my change manually to 2.x branch, but the change itself should be okay. See https://github.com/zfsnap/zfsnap/pull/43 for details. Greets Alex -- »With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie) *** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601 D1D5 8FBA 7744 CC87 10D0 *** pgpi20eZIE6S1.pgp Description: PGP signature
Bug#743685: FTBFS: test failures
Source: urwid
Version: 1.2.1-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Dear Maintainer,
urwid 1.2.1-1 currently FTBFS on i386 and mipsel according to the buildd [1]
logs. Note that the test suite is now run against all python2 and python3
versions supported in sid (rather than just python2, as was the case with
previous versions of urwid); the test failure on i386 is a new one, and only
happens with python3.
i386 [2]:
==
FAIL: test_linefeed (urwid.tests.test_vterm.TermTest)
--
Traceback (most recent call last):
File "/«PKGBUILDDIR»/build/lib.linux-i686-3.4/urwid/tests/test_vterm.py",
line 128, in test_linefeed
self.expect('hello\nworld')
File "/«PKGBUILDDIR»/build/lib.linux-i686-3.4/urwid/tests/test_vterm.py",
line 120, in expect
self.assertEqual(got, what, desc)
AssertionError: b'hello' != b'hello\nworld' : Expected:
b'hello\nworld'
Got:
b'hello'
--
Ran 280 tests in 0.758s
FAILED (failures=1)
mipsel [3]:
==
FAIL: test_run (urwid.tests.test_event_loops.TwistedEventLoopTest)
--
Traceback (most recent call last):
File "/«PKGBUILDDIR»/urwid/tests/test_event_loops.py", line 128, in test_run
self.assertIn("da", out)
AssertionError: 'da' not found in ['waiting', 'hello', 'clean exit']
--
Ran 289 tests in 6.329s
FAILED (failures=1)
[1] https://buildd.debian.org/status/package.php?p=urwid
[2]
https://buildd.debian.org/status/fetch.php?pkg=urwid&arch=i386&ver=1.2.1-1&stamp=1396632579
[3]
https://buildd.debian.org/status/fetch.php?pkg=urwid&arch=mipsel&ver=1.2.1-1&stamp=1396648217
Regards,
Vincent
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (700, 'testing'), (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-5-vclaptop-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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#741730: wxsqlite3: Please update to use wxwidgets3.0
On Sat, 2014-04-05 at 09:33 +0200, László Böszörményi (GCS) wrote: > Hi James, > > On Sat, Apr 5, 2014 at 1:58 AM, James Cowgill wrote: > > Control: block 639782 by -1 > I'm not sure you need wxSQLite3 for CodeLite. Did you check? It does in a few places (I grepped the header file): https://github.com/eranif/codelite/blob/e8cd1e9b0c04d64e851fe86acb4ebb6af6bfffc0/CodeLite/refactoring_storage.h https://github.com/eranif/codelite/blob/e8cd1e9b0c04d64e851fe86acb4ebb6af6bfffc0/CodeLite/cpptoken.h https://github.com/eranif/codelite/blob/e8cd1e9b0c04d64e851fe86acb4ebb6af6bfffc0/CodeLite/tags_storage_sqlite3.h > > > I'm intending to adopt CodeLite. Since the new version I want to upload > > uses wxWidgets 3, it depends on this bug being fixed. So it would be > > nice if this could be updated sometime soon :) > I'll upload it to experimental soon. But if you need only wxWidgets3, > then you are ready to go. It's already in the archive[1]. > > Regards, > Laszlo/GCS > [1] http://packages.qa.debian.org/w/wxwidgets3.0.html Thanks, James -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743594: AssertionError: rewind_cache created a broken cache
I have the same issue. Tried to execute 'apt-get clean' but the exception didn't go away. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743686: ulatencyd: Ulatencyd start without consolekit support
Package: ulatencyd
Version: 0.5.0-7
Severity: normal
Hi
Ulatencyd wo consolekit support is unable to determine wich tasks is active and
put wright parameter (cpu.shares = 1500) from configuration.
Personal i choose to start ulatencyd on systemd after console-kit-
daemon.service and before systemd-logind.service on order to work task active
style.
-- System Information:
Debian Release: 7.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages ulatencyd depends on:
ii dbus 1.6.8-1+deb7u1
ii dpkg 1.16.12
ii libc6 2.13-38+deb7u1
ii libdbus-1-31.6.8-1+deb7u1
ii libdbus-glib-1-2 0.100.2-1
ii libglib2.0-0 2.33.12+really2.32.4-5
ii liblua5.1-05.1.5-4
ii libpolkit-gobject-1-0 0.105-3
ii libxau61:1.0.7-1
ii libxcb11.8.1-2+deb7u1
ii lua-posix 5.1.19-2
ii lua5.1 [lua] 5.1.5-4
ulatencyd recommends no packages.
ulatencyd suggests no packages.
-- Configuration Files:
/etc/init.d/ulatencyd [Errno 2] No such file or directory:
u'/etc/init.d/ulatencyd'
/etc/ulatencyd/scheduler/20-desktop.lua changed:
--[[
Copyright 2010,2011 ulatencyd developers
This file is part of ulatencyd.
License: GNU General Public License 3 or later
]]--
SCHEDULER_MAPPING_DESKTOP = {
info = {
description = "a good default desktop configuration"
}
}
-- cpu & memory configuration
SCHEDULER_MAPPING_DESKTOP["cpu"] =
{
{
name = "rt_tasks",
cgroups_name = "rt_tasks",
param = { ["cpu.shares"]="3048", ["?cpu.rt_runtime_us"] = "949500" },
check = function(proc)
local rv = proc.received_rt or check_label({"sched.rt"}, proc) or
proc.vm_size == 0
return rv
end,
},
{
name = "system_essential",
cgroups_name = "sys_essential",
param = { ["cpu.shares"]="3048" },
label = { "system.essential" }
},
{
name = "user",
cgroups_name = "usr_${euid}",
check = function(proc)
return ( proc.euid > 999 )
end,
param = { ["cpu.shares"]="3048", ["?cpu.rt_runtime_us"] = "100" },
children = {
{
name = "poison",
param = { ["cpu.shares"]="10" },
label = { "user.poison" },
cgroups_name = "psn_${pid}",
},
{
name = "poison_group",
param = { ["cpu.shares"]="300" },
cgroups_name = "pgr_${pgrp}",
check = function(proc)
local rv = ulatency.find_flag(ulatency.list_flags(), {name =
"user.poison.group",
value =
proc.pgrp})
return rv ~= nil
end,
},
{
name = "bg_high",
param = { ["cpu.shares"]="1000", ["?cpu.rt_runtime_us"] = "1"},
label = { "user.bg_high" },
},
{
name = "media",
param = { ["cpu.shares"]="2600", ["?cpu.rt_runtime_us"] = "1"},
label = { "user.media" },
cgroups_name = "med_${pid}",
},
{
name = "ui",
param = { ["cpu.shares"]="2000", ["?cpu.rt_runtime_us"] = "1"},
label = { "user.ui" },
cgroups_name = "ui_${pid}",
},
{
name = "active",
param = { ["cpu.shares"]="1500", ["?cpu.rt_runtime_us"] = "1"},
cgroups_name = "usr_${euid}_active",
check = function(proc)
return proc.is_active
end
},
{
name = "idle",
param = { ["cpu.shares"]="200"},
label = { "user.idle" },
cgroups_name = "idl_${pid}",
},
{
name = "group",
param = { ["cpu.shares"]="600", ["?cpu.rt_runtime_us"] = "1"},
cgroups_name = "grp_${pgrp}",
check = function(proc)
return true
end,
},
},
},
{
name = "system",
cgroups_name = "sys_idle",
label = { "daemon.idle" },
param = { ["cpu.shares"]="1"},
},
{
name = "system",
cgroups_name = "sys_bg",
label = { "daemon.bg" },
param = { ["cpu.shares"]="600"},
},
{
name = "system",
cgroups_name = "sys_daemon",
check = function(proc)
-- don't put kernel threads into a cgroup
return (proc.ppid ~= 0 or proc.pid == 1)
end,
param = { ["cpu.shares"]="800",
["?cpu.rt_runtime_us"] = "1"},
}
}
SCHEDULER_MAPPING_DESKTOP["memory"] =
{
{
name = "system_essential",
cgroups_name = "sys_essential",
param = { ["?memory.swappiness"] = "0" },
label = { "system.essential" }
},
{
name = "user",
cgroups_name = "usr_${euid}",
check = function(proc)
return ( proc.euid > 999 )
Bug#743687: dpkg: dpkg-deb creates tar files with -T and without --no-unquote
Package: dpkg Version: 1.17.6 Severity: minor Dear dpkg maintainers, dpkg-deb creates the tarfiles inside a .deb using tar -T without using --no-unquote. This can cause issues when a filename contains one or more "\"-characters, as tar will strip one level of blackslahes (due to --unqoute being the default). Thus a file named \\ will be renamed to \ in the process (and e.g. "\a" becomes "a"[1]). If this causes two files to have the same name, tar will consider of them a hardlink of other (discarding its content, as it is assumed to be the same as the other one). I have filed this as "minor", since (to my knowledge) the only packages containing files affected by this are found solely in the Lintian test suite[2]. ~Niels [1] I believe it will also do some translation. E.g. turn something like "\060" into a literal "0". [2] E.g. t/tests/files-tar-traps - can be run from the source via: $ mkdir debian/test-out $ t/runtests t debian/test-out files-tar-traps Also, consider opening t/tests/files-tar-traps/pre_build and have it enable the last line or add other "funny" named files as needed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743688: ruby: broken symlinks for testrb, rdoc and gem in the 2.0.0.1 ruby package
Package: ruby Version: 1:2.0.0.1 Severity: normal Dear Maintainer, Adequate reported broken symlinks for testrb, rdoc and gem in the ruby package and sure enough they are broken. adequate found packaging bugs - ruby: broken-symlink /usr/share/man/man1/testrb.1.gz -> testrb2.0.1.gz ruby: broken-symlink /usr/share/man/man1/rdoc.1.gz -> rdoc2.0.1.gz ruby: broken-symlink /usr/share/man/man1/gem.1.gz -> gem2.0.1.gz Trying to use the manpages gives me this on the console :- $ man gem man: warning: /usr/share/man/man1/gem.1.gz is a dangling symlink No manual entry for gem See 'man 7 undocumented' for help when manual pages are not available. $ man rdoc man: warning: /usr/share/man/man1/rdoc.1.gz is a dangling symlink No manual entry for rdoc See 'man 7 undocumented' for help when manual pages are not available. $ man testrb man: warning: /usr/share/man/man1/testrb.1.gz is a dangling symlink No manual entry for testrb See 'man 7 undocumented' for help when manual pages are not available. I just looked at one of the examples in the man directory for completeness :- $ ll -h testr* -rw-r--r-- 1 root root 677 Feb 2 06:14 testrb1.9.1.1.gz lrwxrwxrwx 1 root root 14 Mar 30 20:35 testrb.1.gz -> testrb2.0.1.gz As can be seen there is no testrb2.0.1.gz Looking forward to the fixed package. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (600, 'testing'), (500, 'testing-updates'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ruby depends on: ii ruby2.0 2.0.0.484+really457-1 ruby recommends no packages. Versions of packages ruby suggests: pn ri pn ruby-dev -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743543: Resolution
I indeed use fglrx-driver. I have switched back to the free ati driver witch works. Thanks, RAPHAEL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#708961: gcc-snapshot: unrecognizable insn in decLibrary.c, ICE in extract_insn
what's the current status? please follow-up upstream as well. Am 19.05.2013 21:02, schrieb Roland Stigge: Package: gcc-snapshot Version: 20130509-1 Severity: wishlist User: debian-powerpc...@breakpoint.cc Usertags: powerpcspe Hi, when building the latest gcc-snapshot on powerpcspe (i.e., gnuspe / e500v2), this results in: ... /home/ernie/gcc-snapshot-20130509/build/./gcc/xgcc -B/home/ernie/gcc-snapshot-20130509/build/./gcc/ -B/usr/lib/gcc-snapshot/powerpc-linux-gnuspe/bin/ -B/usr/lib/gcc-snapshot/powerpc-linux-gnuspe/lib/ -isystem /usr/lib/gcc-snapshot/powerpc-linux-gnuspe/include -isystem /usr/lib/gcc-snapshot/powerpc-linux-gnuspe/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/. -I../../../src/libgcc/../gcc -I../../../src/libgcc/../include -I../../../src/libgcc/../libdecnumber/dpd -I../../../src/libgcc/../libdecnumber -DHAVE_CC_TLS -o decDouble.o -MT decDouble.o -MD -MP -MF decDouble.dep -c ../../../src/libgcc/../libdecnumber/decDouble.c ../../../src/libgcc/../libdecnumber/decLibrary.c: In function 'isinfd64': ../../../src/libgcc/../libdecnumber/decLibrary.c:60:1: error: unrecognizable insn: } ^ (insn 2 4 3 2 (set (reg/v:DD 125 [ arg ]) (reg:DD 3 3 [ arg ])) ../../../src/libgcc/../libdecnumber/decLibrary.c:53 -1 (nil)) ../../../src/libgcc/../libdecnumber/decLibrary.c:60:1: internal compiler error: in extract_insn, at recog.c:2154 0x1086917f _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../src/gcc/rtl-error.c:109 0x108691d3 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../src/gcc/rtl-error.c:117 0x10801bd7 extract_insn(rtx_def*) ../../src/gcc/recog.c:2154 0x10573667 instantiate_virtual_regs_in_insn ../../src/gcc/function.c:1561 0x105752c3 instantiate_virtual_regs ../../src/gcc/function.c:1926 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. Preprocessed source stored into /tmp/ccLwS90V.out file, please attach this to your bugreport. make[5]: *** [decLibrary.o] Error 1 make[5]: *** Waiting for unfinished jobs make[5]: Leaving directory `/home/ernie/gcc-snapshot-20130509/build/powerpc-linux-gnuspe/libgcc' make[4]: *** [all-stage1-target-libgcc] Error 2 make[4]: Leaving directory `/home/ernie/gcc-snapshot-20130509/build' ... Attaching the cited debug file ccLwS90V.out. Thanks in advance, Roland -- System Information: Debian Release: 7.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: powerpcspe (ppc) Kernel: Linux 3.9.0-dirty (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731028: needrestart: change list mode to a list of commands for restarting
On Thu, 2014-04-03 at 21:11 +0200, Thomas Liske wrote: > in which way would needrestart be more useful for you? Are you doing > some screen scraping on the output of needrestart? I switched back to checkrestart from debian-goodies because needrestart doesn't print the list of commands needed to restart daemons. My usual workflow is to run checkrestart after an upgrade and then copy-paste the list of restart commands that it suggests. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#743689: grisbi: New upstream version 1.0.0 is available
Package: grisbi Severity: normal Hello, The latest verison of grisbi is now 1.0.0 web site: http://www.grisbi.org/ source download: http://sourceforge.net/projects/grisbi/files/grisbi%20stable/1.0.x/ Do you need co-maintainers? I see the Debian packaging is available on collab-maint. And I am a DD. Bye -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699730: gnome-control-center: brightness resets on reboot or logout
Package: gnome-control-center Followup-For: Bug #699730 Dear Maintainer, I originally reported this bug, but it has gone away in gnome 3.8 in jessie. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-control-center depends on: ii accountsservice0.6.34-2 ii apg2.2.3.dfsg.1-2 ii colord 1.0.6-1 ii desktop-file-utils 0.22-1 ii gnome-control-center-data 1:3.8.3-4 ii gnome-desktop3-data3.8.4-2 ii gnome-icon-theme 3.12.0-1 ii gnome-icon-theme-symbolic 3.12.0-1 ii gnome-menus3.8.0-2 ii gnome-settings-daemon 3.8.5-2 ii gsettings-desktop-schemas 3.8.2-2 ii libaccountsservice00.6.34-2 ii libatk1.0-02.10.0-2 ii libc6 2.18-4 ii libcairo2 1.12.16-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra0 0.30-2 ii libcheese-gtk233.10.1-1sid1 ii libcheese7 3.10.1-1sid1 ii libclutter-gtk-1.0-0 1.4.4-3 ii libcolord-gtk1 0.1.25-1.1 ii libcolord1 1.0.6-1 ii libcups2 1.7.1-10 ii libdbus-glib-1-2 0.102-1 ii libfontconfig1 2.11.0-2 ii libgdk-pixbuf2.0-0 2.30.6-1 ii libgl1-mesa-glx [libgl1] 10.1.0-4 ii libglib2.0-0 2.38.2-5 ii libgnome-bluetooth11 3.8.1-2 ii libgnome-desktop-3-7 3.8.4-2 ii libgoa-1.0-0 3.8.3-2 ii libgtk-3-0 3.10.7-1 ii libgtop2-7 2.28.5-2 ii libibus-1.0-5 1.5.5-1 ii libkrb5-3 1.12.1+dfsg-1 ii libnm-glib-vpn10.9.8.0-5 ii libnm-glib40.9.8.0-5 ii libnm-gtk0 0.9.8.8-1 ii libnm-util20.9.8.0-5 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-01.36.3-1 ii libpolkit-gobject-1-0 0.105-4 ii libpulse-mainloop-glib04.0-6+b1 ii libpulse0 4.0-6+b1 ii libpwquality1 1.2.3-1 ii libsmbclient 2:4.1.6+dfsg-1 ii libsocialweb-client2 0.25.20-6 ii libupower-glib10.9.23-2+b1 ii libwacom2 0.8-1 ii libx11-6 2:1.6.2-1 ii libxi6 2:1.7.2-1 ii libxml22.9.1+dfsg1-3 Versions of packages gnome-control-center recommends: ii cups-pk-helper 0.2.5-2 ii gkbd-capplet 3.6.0-1 ii gnome-online-accounts 3.8.3-2 ii gnome-user-guide 3.8.2-1 ii gnome-user-share 3.8.3-1 ii iso-codes 3.51-1 ii mesa-utils 8.1.0-2+b1 ii mousetweaks3.12.0-1 ii network-manager-gnome 0.9.8.8-1 ii ntp1:4.2.6.p5+dfsg-3 ii policykit-1-gnome 0.105-2 ii rygel 0.20.3-1 ii rygel-tracker 0.20.3-1 ii system-config-printer 1.4.3-4 Versions of packages gnome-control-center suggests: ii gnome-screensaver3.6.1-1 ii gstreamer1.0-pulseaudio 1.2.3-1 ii libcanberra-gtk-module 0.30-2 ii libcanberra-gtk3-module 0.30-2 ii x11-xserver-utils7.7+2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725899: perl-base: Needs versioned Conflicts on libscalar-list-utils-perl
clone 725899 -1
retitle -1 perl-base: perl-base and dual life modules don't fit together
submitter -1 !
thanks
On Fri, Apr 04, 2014 at 12:03:40AM +0100, Dominic Hargreaves wrote:
> I think in principle we're happy to update Scalar-List-Utils in
> perl-base; I had a look at doing this and just now need to fix up the
> porting tests.
>
> Niko, would you be happy with such an upload once it's tested?
Happy is not quite the right word. Clearly this isn't how things should
go in a perfect world. But sure, it seems to be the only viable short
term solution. Feel free to go ahead, and thanks for working on this.
Do we need to do something about Module::Corelist? Hopefully not, but
it's sort of lying after this. If we have to, i guess we could fork it
into Module::Corelist::Debian or something...
For the record, I had a look at whether it would be possible to remove
Scalar::Util and List::Util from perl-base in the long term. They were
added in #158499 to keep perl-base self contained. I see such needs
are currently
/usr/lib/perl/5.18.2/Hash/Util.pm:use Scalar::Util qw(reftype);
/usr/lib/perl/5.18.2/File/Spec/Unix.pm: @dirlist = grep { !
Scalar::Util::tainted($_) } @dirlist;
/usr/lib/perl/5.18.2/Socket.pm:return Scalar::Util::dualvar( $errno,
$errstr );
/usr/share/perl/5.18.2/overload.pm:$package =
Scalar::Util::blessed($package);
This doesn't look promising, and the rest of the archive may well
have grown undeclared dependencies on them too. It'd be quite bit
of work to go through those, even with codesearch.debian.net.
Such energy would probably better spent on the /usr/bin/perl-base
idea discussed in #721364, as that would give us a general fix.
I'm cloning a separate bug about the general issue.
--
Niko Tyni nt...@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#681884: Same problem with schroot 1.6.8-1
Erik de Castro Lopo wrote: > Can anyone figure out from what we know so far if this is an schroot > but or a systemd bug? > > If someone can give me a gentle nudge in the right direction I'm willing > to invest some time on this because I really do need this bug fixed. Now I can't even re-produce this bug. I'm still using schroot 1.6.8-1 with systemd 204-8 but upgrading something else (no clue what) seems to have fixed. I have schroot working properly again. I'm very happy. If no one else can re-produce this then the bug should be closed. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742990: what is this bug about, anyway??
Hi Bastian, your bug report is very vague: [12:25] < h01ger> | "seems to include", "could be a licence violation", "if this is a false positive..." - and no list of actual files without sources given. if you arent sure that a bug is RC, than dont file it. If I were the maintainer, I would probably close the bug stating "come back if you have more substancial claims to make", like this its pretty annoying. Even if you are probably right, you should be more helpful when filing RC bugs. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#743691: RFS: wcslib-contrib/4.20 [ITP] -- Draw and label curvilinear coordinate grids with pgplot
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: debian-as...@lists.debian.org, debian-scie...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "wcslib-contrib" * Package name: wcslib-contrib Version : 4.20-1 Upstream Author : Mark Calabretta * URL : http://www.atnf.csiro.au/people/mcalabre/WCS/ * License : LGPL-3 Section : contrib/science It builds those binary packages: libpgsbox-dev - Header files and static library for libpgsbox libpgsbox4 - Draw and label curvilinear coordinate grids with pgplot wcslib-tools-wcsgrid - Command line tool utilizing libpgsbox To access further information about this package, please visit the following URL: http://mentors.debian.net/package/wcslib-contrib Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/contrib/w/wcslib-contrib/wcslib-contrib_4.20-1.dsc This package builds the parts of wcslib that need pgplot5 to compile and therefore cannot be put into main: libpgsbox and the wcsgrid tool. It is based on the same debianization. Although there is version 4.21 available for wcslib, this package is still created with version 4.20 since 4.21 does not pass all unit tests. Upstream is working on this :-) The package is put under debian-astro maintenance, and may be needed for future packages (I already got one request). Best regards Ole -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735763: svnkit is marked for autoremoval from testing
On 03.04.2014 15:34, Miguel Landaeta wrote: > On Wed, Apr 02, 2014 at 07:00:35PM +0200, Markus Koschany wrote: >> >> I have tested all reverse dependencies of svnkit and they seem to work. >> Only netbeans could not be tested because it's affected by another RC bug. > > Hi Markus, > > Since Matthew tagged his packages with LowThresholdNmu and > trilead-ssh2 doesn't get an update since 4 years ago or so > I think we can upload it. > > I'll review it and upload it to DELAYED/5 if everything is OK. Hi Miguel, that would be great. Please go ahead and let me know if there is something that should be changed. > If Matthew gives his consent, we can move trilead-ssh2 to debian-java > as you said. I'm in favour of it but of course it's up to Matthew to decide. Cheers, Markus signature.asc Description: OpenPGP digital signature
Bug#743692: pitivi fails to start, complains about missing clutter-gst dependencies
Package: pitivi Version: 0.93-2 Severity: important pitivi fails to start, complains about missing clutter-gst dependencies: ERROR:root:Could not find any typelib for ClutterGst Failed to initialize modules: cannot import name ClutterGst ERROR:root:Could not find any typelib for ClutterGst ERROR - The following hard dependencies are unmet: == - ClutterGst not found on the system Missing soft dependency: - pycanberra not found on the system -> abilita le notifiche sonore quando il rendering è completo ERROR:root:Could not find any typelib for GnomeDesktop Missing soft dependency: - GnomeDesktop not found on the system -> file thumbnails provided by GNOME's thumbnailers ERROR:root:Could not find any typelib for Notify Missing soft dependency: - Notify not found on the system -> abilita le notifiche visuali quando il rendering è completo Steps to reproduce: Install PiTiVi on non-gnome platform and run pitivi. Solution: This bug can be fixed by adding gir1.2-clutter-gst-2.0 as dependency. Thanks. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pitivi depends on: ii gir1.2-clutter-1.0 1.18.0-2 ii gir1.2-gdkpixbuf-2.02.30.6-1 ii gir1.2-ges-1.0 1.2.0-2 ii gir1.2-glib-2.0 1.38.0-2 ii gir1.2-gst-plugins-base-1.0 1.2.3-1 ii gir1.2-gstreamer-1.01.2.3-1 ii gir1.2-gtk-3.0 3.10.7-1 ii gir1.2-gtkclutter-1.0 1.4.4-3+b1 ii gir1.2-pango-1.01.36.3-1 ii gnome-icon-theme3.12.0-1 ii gstreamer1.0-gnonlin1.2.0-1 ii gstreamer1.0-plugins-bad [gstreamer1.0-videosink] 1.2.3-1+b1 ii gstreamer1.0-plugins-base 1.2.3-1 ii gstreamer1.0-plugins-good [gstreamer1.0-videosink] 1.2.3-1 pn gstreamer1.0-pulseaudio | gstreamer1.0-audiosink ii gstreamer1.0-x [gstreamer1.0-videosink] 1.2.3-1 ii libc6 2.18-4 ii libcairo2 1.12.16-2 ii python 2.7.5-5 ii python-cairo1.8.8-1+b2 ii python-dbus 1.2.0-2+b2 ii python-gi 3.10.2-2+b1 ii python-gst-1.0 1.2.0-1 ii python-matplotlib 1.3.1-1+b1 ii python-numpy1:1.8.1-1 ii python-xdg 0.25-4 pitivi recommends no packages. Versions of packages pitivi suggests: ii frei0r-plugins 1.1.22git20091109-1.4 ii gstreamer1.0-libav 1.2.3-1 ii gstreamer1.0-plugins-bad 1.2.3-1+b1 ii gstreamer1.0-plugins-ugly 1.2.3-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743693: modemmanager: problem with dependecies on jessie
Package: modemmanager
Version: 0.5.2.0-2.1
Severity: normal
Dear Maintainer,
The last version of modemmanager, fails to upgrade on testing with the output
below:
$ aptitude full-upgrade
The following packages will be upgraded:
modemmanager{b}
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/477 kB of archives. After unpacking 1147 kB will be used.
The following packages have unmet dependencies:
modemmanager : Breaks: network-manager (< 0.9.8.2-1) but 0.9.8.0-5 is
installed.
The following actions will resolve these dependencies:
Remove the following packages:
1) modemmanager
Leave the following dependencies unresolved:
2) network-manager recommends modemmanager
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing-proposed-updates'),
(500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages modemmanager depends on:
ii libc6 2.18-4
ii libdbus-1-3 1.8.0-3
ii libdbus-glib-1-2 0.102-1
ii libglib2.0-0 2.38.2-5
ii libgudev-1.0-0204-8
Versions of packages modemmanager recommends:
ii usb-modeswitch 2.1.0+repack0-1+b1
modemmanager suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739409: [ocl-icd-libopencl1] Broken symbols file
Hi Vincent, On 05.04.2014 02:35, Vincent Danjean wrote: On 04/04/2014 21:21, Andreas Cadhalpun wrote: Control: severity -1 serious Justification: breaks other packages You are kidding? The only effect of this bug is that, if you enable the non-free Debian repo, then a non-free package can sometimes be installed by default where another free one (from main) would work. If installing another ICD Loader really does not work, then this is another bug that has nothing to do with depends. ICD Loaders are meant to be exchangeable. You're right: the more serious problem is that nvidia-libopencl1 doesn't work with a program build with ocl-icd-opencl-dev. I just tested amd-libopencl1 and it works. I was hopping that the first alternative would be a good enough hint for package managers. It seems not. I will apply your patch. Thanks. This creates the following dependencies (from python-pyopencl): Depends: libopencl-1.1-1, libopencl-1.2-1, ocl-icd-libopencl1 (>= 1.0) | libopencl1, opencl-icd Now if you try to install this package, apt satisfies the libopencl-1.1-1 dependency randomly, for me by installing nvidia-libopencl1. (A similar problem is the opencl-icd dependency, but that is added by pyopencl itself.) nvidia-libopencl1 does not provide libopencl-1.2-1 and conflict with libopencl1. So I find this fact very suspicious. Do you have any evidence of it? What are the precise versions of all involved packages (in particular nvidia-libopencl1). But I agree that amd-libopencl1 can be installed if the package manager try to satisfy "libopencl-1.2-1" before "ocl-icd-libopencl1 (>= 1.0) | libopencl1" (that said, it needs you to have enable the non-free Debian repo *and* it should indeed work) Sorry for mixing things up here. If I install python-pyopencl apt by installs amd-libopencl1. nvidia-libopencl1 was installed in my build process to satisfy the dependencies of libavutil152. Note that opencl-icd is a different problem. It tells that your program needs a ICD (ie OpenCL implementation). However, to my knowledge (and same for other involved maintainers), there is no way to express in dpkg/apt a depends on a ICD that will work for your current hardware. So, this force you to install an ICD but you will need to select a correct one for your machine. This is indeed a problem as apt doesn't ask, but just installs a random one. So I guess one has to install the correct ICD first. Attached is a patch that fixes this problem in ocl-icd. Additionally, I'm not sure if you are aware of [1]: "Packages MUST NOT use virtual package names (except privately, amongst a cooperating group of packages) unless they have been agreed upon and appear in this list." I think it would be a good idea to add the libopencl* virtual packages to that list, because they can be added automatically via the symbols file, which is not exactly using 'privately, amongst a cooperating group of packages'. However, that the case. They are used privately amongst OpenCL related packages. There have been discussions explaining the reasons. No maintainer of external packages should add them manually. No package unrelated with OpenCL should use them at all. If you think so. But before you attempt this, I think you should coordinate with the other packages currently providing these libraries and standardize the symbol names. This is not possible unless you are able to modify the binaries provided by AMD, NVidia (and even Intel that, in its libopencl1.so library doe no even use the correct SONAME...) In any case, this is out the scope of the power of Debian Developer (AMD and NVidia are in non-free, not in main, Intel ones is not even in non-free due to an error in there licencing file. They promise me to correct this on a forum but I did not see any fact until now...) But the Debian Developer can ensure that nvidia-libopencl1 does not provide libopencl1 as long as it doesn't work well together with the rest. ocl-icd-libopencl1 uses @OPENCL_*, while e.g. nvidia-libopencl1 uses @BASE, so if a program is compiled with ocl-icd-opencl-dev and used with nvidia-libopencl1 (which apt installs by default with the current broken symbols file), it will produce errors like: undefined reference to `clReleaseMemObject@OPENCL_1.0' Are you sure? When I test it a few months (years) ago, there was only a warning. Look at line 310 and following at http://anonscm.debian.org/gitweb/?p=collab-maint/ocl-icd.git;a=blob;f=debian/README.Debian;hb=HEAD Perhaps the linker behavior changed since this time. Yes, I'm sure that I see this error. When FFmpeg is compiled with ocl-icd-opencl-dev and then e.g. amarok is compiled while nvidia-libopencl1 is installed instead of ocl-icd-libopencl1, it results in: [ 71%] Building CXX object src/core-impl/collections/ipodcollection/CMakeFiles/amarok_collection-ipodcollection.dir/IpodCollectionFactory.o cd src/core-impl/collections/ipodcollection && /usr/bin/c++ -DKDE4_CMAKE_TOPLEVEL_
Bug#743554: Forwarded to upstream
Control: tag -1 upstream Control: forwarded -1 https://github.com/astropy/astropy/issues/2171 These problems are already forwarded to upstream. While the test_composite_static_matrix_transform failure could be fixed by increasing the tolerance, the checksum test failures would need to be silenced or disabled. However, I am afraid that the checksum test failure exposes a real problem that was not in the 0.3.0 version, so instead of just silencing it I will wait for a new version from upstream. See the upstream bug report for details. Best Ole -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743694: Downgrade most of privacy-breach* tags from severity: error to pedantic
Package: lintian Version: 2.5.22.1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I hereby ask for downgrading most of the privacy-breach* checks from severity: error to pedantic. Because the severity of these lintian checks is relevant to the decision, if a package gets accepted into Debian I've added the FTP masters team this report to get their point of view. Why do I disagree to the severity chosen for these tags: - - The severity chosen for these tags/checks is not justified by any of our policies, neither the Debian policy, not the best packaging practises nor any legal reason! There is IMO one exception: the violation of Google AdSense terms is serious and shouldn't be changed. - - There is no technical nor social justification for this severity. Making it simple: either you have an internet connection or you don't. In the latter case there is no problem. If you have an internet connection you either use a technical solution/ anonymizer to disable any "tracking" services or you don't. In both cases you don't have a problem, either you decided you accept the existance of zero-byte gifs, cross-links, tracking services and stuffs or you already use a technical solution to "disable" this. So making our package compliant to this new privacy- policy doesn't add any value to our users. - - I simply morally disagree with removing donation requests from authors although this might be legally correct (and yes I know, you request to put this in the upstream metadata instead). IMHO it is simply not your choice to make, how the author makes a donation request. - - Because I cannot see any agreement on the position lintian authors took here and because I don't see any technical nor social justification for this choice, I find it unacceptable that the burden to make packages "privacy"- compliant to some users is put on the shoulders of myself and fellow DDs. I cannot argue with the position of the Debian project and IMHO neither can you, so I would suggest a conservative choice for severity of these tags as long as we don't have a common position of the project. Regards, Daniel - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (850, 'unstable'), (700, 'testing'), (560, 'stable'), (500, 'oldstable'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages lintian depends on: ii binutils 2.24-5 ii bzip2 1.0.6-5 ii diffstat 1.58-1 ii file 1:5.17-1 ii gettext0.18.3.2-1 ii hardening-includes 2.5 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.29+b1 ii libarchive-zip-perl1.37-2 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.36-1 ii libdpkg-perl 1.17.6 ii libemail-valid-perl1.192-1 ii libfile-basedir-perl 0.03-1 ii libipc-run-perl0.92-1 ii liblist-moreutils-perl 0.33-2 ii libparse-debianchangelog-perl 1.2.0-1 ii libtext-levenshtein-perl 0.06~01-2 ii libtimedate-perl 2.3000-1 ii liburi-perl1.60-1 ii man-db 2.6.6-1 ii patchutils 0.3.2-3 ii perl [libdigest-sha-perl] 5.18.2-2+b1 ii t1utils1.37-2 Versions of packages lintian recommends: pn libperlio-gzip-perl ii perl-modules [libautodie-perl] 5.18.2-2 Versions of packages lintian suggests: pn binutils-multiarch ii dpkg-dev 1.17.6 ii libhtml-parser-perl3.71-1+b1 ii libtext-template-perl 1.46-1 ii libyaml-perl 0.84-1 ii xz-utils 5.1.1alpha+20120614-2 - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlM/4okACgkQm0bx+wiPa4y7jwCgh/PCcIHyBliuYzPTmLcOfAUw /zsAoM+BIgeF3rkscqbxjNd6KqYG9hkZ =sT++ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743695: gevent-socketio tries to download python packages during the build
Package: gevent-socketio
Version: 0.3.6-1
Severity: serious
Tags: sid jessie
gevent-socketio tries to download python packages during the build, and fails to
build when it doesn't succeed.
complete build log at
https://launchpad.net/ubuntu/+source/gevent-socketio/0.3.6-1
dh_auto_clean
Download error on https://pypi.python.org/simple/versiontools/: [Errno -2] Name
or service not known -- Some packages may not be found!
Couldn't find index page for 'versiontools' (maybe misspelled?)
Download error on https://pypi.python.org/simple/: [Errno -2] Name or service
not known -- Some packages may not be found!
No local packages or download links found for versiontools>=1.7
Traceback (most recent call last):
File "setup.py", line 50, in
""",
File "/usr/lib/python2.7/distutils/core.py", line 111, in setup
_setup_distribution = dist = klass(attrs)
File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 239, in
__init__
self.fetch_build_eggs(attrs.pop('setup_requires'))
File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 264, in
fetch_build_eggs
replace_conflicting=True
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 620, in resolve
dist = best[req.key] = env.best_match(req, ws, installer)
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 858, in
best_match
return self.obtain(req, installer) # try and download/install
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 870, in obtain
return installer(requirement)
File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 314, in
fetch_build_egg
return cmd.easy_install(req)
File "/usr/lib/python2.7/dist-packages/setuptools/command/easy_install.py",
line 610, in easy_install
raise DistutilsError(msg)
distutils.errors.DistutilsError: Could not find suitable distribution for
Requirement.parse('versiontools>=1.7')
dh_auto_clean: python setup.py clean -a returned exit code 1
make[1]: *** [override_dh_auto_clean] Error 1
make[1]: Leaving directory `/build/buildd/gevent-socketio-0.3.6'
make: *** [clean] Error 2
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743497: Forwarded to upstream
Control: tag -1 upstream Control: forwarded -1 PIPE-4905 The bug was forwarded to upstream and is registered under the mentioned Id. Since the bug database is not public, an URL is not given. The report to upstream includes all other failing platforms as well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743696: gbatnav: fails to build with clang instead of gcc
Package: gbatnav
Version: 1.0.4cvs20051004-5
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs
Dear Maintainer,
Your package fails to build with clang instead of gcc. [-Wreturn-type]
The attached patch fixes it.
Buildlogs and patch are here:
https://github.com/nonas/debian-clang/tree/master/buildlogs/gbatnav
Regards,
Nicolas
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Description: fix FTBFS with clang instead of gcc
Author: Nicolas Sévelin-Radiguet
Last-Update: 2014-04-05
--- a/gbnserver/play.c
+++ b/gbnserver/play.c
@@ -506,7 +506,7 @@
j=quejugador(fd);
if(j<0 || j>=MAXPLAYER)
- return;
+ return FALSE;
for (i = 0; i < ntokens; i++) {
if (strcmp( p->token, tokens[i].label )==0 ){
Bug#733641: (no subject)
Dear maintainer,
Attached patches make samidare to work with current sid ruby packages.
I test with these packages.
ii ruby1:2.0.0.1
ii ruby-htree 0.8+dfsg-2
Best Regards,
Kouichi ONO
--- mconv.rb.org 2008-07-24 21:55:19.0 +0900
+++ mconv.rb 2014-04-02 21:39:30.176448762 +0900
@@ -25,7 +25,7 @@
# IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
# OF SUCH DAMAGE.
-require 'iconv'
+#require 'iconv'
module Mconv
def Mconv.internal_mime_charset
@@ -50,30 +50,8 @@
end
def Mconv.conv(str, to, from)
-ic = Iconv.new(to, from)
-result = ''
-rest = str
-if rest.respond_to? :force_encoding
- rest = rest.dup.force_encoding("ascii-8bit")
-end
-
-begin
- s = ic.iconv(rest)
- result << s
-rescue Iconv::Failure
- result << $!.success
-
- rest = $!.failed
-
- # following processing should be customizable by block?
- result << '?'
- rest = rest[1..-1]
-
- retry
-end
-
-result << ic.close
+result = str.encode(to, from, :invalid => :replace, :undef => :replace)
result
end
--- debian/control.org 2014-02-13 01:23:47.0 +0900
+++ debian/control 2014-03-28 23:34:40.183473806 +0900
@@ -3,13 +3,13 @@
Priority: optional
Maintainer: NIIBE Yutaka
Build-Depends: debhelper (>= 5)
-Build-Depends-Indep: ruby (>= 1.8)
+Build-Depends-Indep: ruby
Standards-Version: 3.8.0
Homepage: http://www.a-k-r.org/samidare/
Package: samidare
Architecture: all
-Depends: libhtree-ruby1.8, libyaml-ruby1.8, libzlib-ruby1.8, ruby (>= 1.8), ruby1.8
+Depends: ruby-htree, ruby
Description: web page updates checker
Samidare makes it easy to keep up with your favorite weblogs or webpages in
general.
--- debian/rules.org 2014-02-13 01:23:47.0 +0900
+++ debian/rules 2014-02-13 01:27:40.378750628 +0900
@@ -6,7 +6,7 @@
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
-RUBY := ruby1.8
+RUBY := ruby
CFLAGS = -Wall -g
Bug#743697: qa.debian.org: [jenkins.d.n] please run rebootstrap
Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org
Usertags: jenkins.d.n
Hi Holger,
It would be nice if jenkins could run rebootstrap, a QA effort aiming to
test the very early stage for bootstrapping new and old architectures.
This is part of a larger goal called "bootstrappable Debian".
I set up a git branch "rebootstrap" at
git.debian.org:/git/users/helmutg/jenkins.debian.net.git that tries to
provide a initial configuration for jenkins to run rebootstrap (also
attached). Help with finishing this draft is welcome.
To get an idea of what is needed I'll write down a bit of the goals and
use cases:
* Until now only the gcc/eglibc dance is implemented and it takes at
most 3h. If successful, this will take longer in future.
* There are no inter-job dependencies. They can all run in parallel.
* The most valuable build artefact is the build log. Optionally the
resulting packages can be saved (by passing RESULT=/some/directory).
* Rebuilds should happen at least once per gcc/eglibc package upload,
being able to externally trigger sets of jobs would be nice. Most
often I can tell which job configurations are affected by a commit to
rebootstrap.git.
* The build logs contain lines matching /^progress-mark:\d+:.*/ to give
a rough clue on where they fail. Larger numbers are better.
* As future extension running gcc-4.9 and multilib bootstraps would be
nice. That also means that generating job configurations from a
feature space (architecture, gcc version, multilib enabled) would be
nice.
* It is essential to run many architectures in parallel to determine
whether a particular build error is architecture-specific or generic.
* The main goal of this effort is to actually fix things. Examples:
#742358 #742539 #743342 #743676 #742640
If you have any questions concerning this effort. The natural points of
contact are me (mail) and #debian-bootstrap (or maybe #debian-qa) on
oftc.
Helmut
- defaults:
name: rebootstrap
description: 'Verfy bootstrappability of Debian architectures'
scm:
- git:
url: 'git://anonscm.debian.org/users/helmutg/rebootstrap.git'
branches:
- master
builders:
- shell: '/srv/jenkins/bin/chroot-run.sh sid ./bootstrap.sh
HOST_ARCH={architecture} {params}'
publishers:
- email:
recipients: helm...@debian.org
- project:
name: rebootstrap
jobs:
- 'rebootstrap_arm64':
architecture: 'arm64'
- 'rebootstrap_m68k':
architecture: 'm68k'
Bug#741240: vlc segfaults while playing MKV files
reassign 741240 libavcodec54 thanks Hello, This appears to be a race condition in libavcodec threaded decoding. It should be fixed in newer upstream libavcodec versions already. In the mean time, you might have to disable threaded decoding in the VLC preferences. -- Rémi Denis-Courmont http://www.remlab.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743698: recommend/suggest va-driver/vdpau-driver and libgl1-mesa-dri libaacs0
Package: mpv Version: 0.3.7-1 Severity: normal #703544 i965-va-driver: Nothing depends / recommends this I thinks mpv would be a prime candidate. Theres also: $ aptitude search va-driver -F %p | grep -E -v 'i386|dbg' i965-va-driver nvidia-va-driver s3g-va-driver va-driver vdpau-va-driver xvba-va-driver I can confirm that i965-va-driver and vdpau-va-driver work well with the mpv package, but it might make more sense to "suggest" vdpau-va-driver since it's probably better to use mpv's native vaapi support. Similarly, there's $ aptitude search vdpau-driver -F %p | grep -E -v 'i386|dbg' mesa-vdpau-drivers nvidia-vdpau-driver vdpau-driver --vo=opengl (the one recommended by upstream) requires libgl1-mesa-dri (or equivalent) to function. libaacs0 is required for playing blurays Kevin -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'testing'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14.0.00 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mpv depends on: ii libasound2 1.0.27.2-3 ii libass4 0.10.1-3 ii libavcodec546:9.11-3+b1 ii libavfilter36:9.11-3+b1 ii libavformat54 6:9.11-3+b1 ii libavresample1 6:9.11-3+b1 ii libavutil52 6:9.11-3+b1 ii libbluray1 1:0.5.0-2 ii libbs2b03.1.0+dfsg-2 ii libc6 2.18-4 ii libcdio-cdda1 0.83-4.1 ii libcdio-paranoia1 0.83-4.1 ii libcdio13 0.83-4.1 ii libdvdnav4 4.2.1-3 ii libdvdread4 4.2.1-2 ii libegl1-mesa [libegl1-x11] 10.1.0-5 ii libenca01.15-2 ii libgl1-mesa-glx [libgl1]10.1.0-5 ii libguess1 1.1-4 ii libjack-jackd2-0 [libjack-0.116]1.9.9.5+20140404git3d7c67dc~dfsg-1 ii libjpeg88d-2 ii liblcms2-2 2.5-1 ii liblircclient0 0.9.0~pre1-1 ii liblua5.1-0 5.1.5-5 ii libmpg123-0 1.18.0-1 ii libncurses5 5.9+20140118-1 ii libpostproc52 6:0.git20120821-4 ii libpulse0 5.0-1 ii libquvi70.4.1-2 ii libsdl2-2.0-0 2.0.2+dfsg1-3 ii libswscale2 6:9.11-3+b1 ii libtinfo5 5.9+20140118-1 ii libuuid12.20.1-5.7 ii libva-glx1 1.3.0-1 ii libva-x11-1 1.3.0-1 ii libva1 1.3.0-1 ii libvdpau1 0.7-1 ii libwayland-client0 1.4.0-1 ii libwayland-cursor0 1.4.0-1 ii libwayland-egl1-mesa [libwayland-egl1] 10.1.0-5 ii libx11-62:1.6.2-1 ii libxext62:1.3.2-1 ii libxinerama12:1.1.3-1 ii libxkbcommon0 0.4.0-1 ii libxss1 1:1.2.2-1 ii libxv1 2:1.0.10-1 ii libxxf86vm1 1:1.1.3-1 ii zlib1g 1:1.2.8.dfsg-1 mpv recommends no packages. mpv suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743671: Building extensions breaks resulting packages
Control: reassign -1 gem2deb Hello, thanks for your bug report. On Sat, Apr 05, 2014 at 01:14:04AM +0200, Marc Dequènes (Duck) wrote: > Package: libruby2.1 > Version: 2.1.1-2 > Severity: grave > Control: block 743664 with -1 > > Coin, > > Building extensions leaves mkmf.log files in weird places since 2.1, see > #743664. > > I though the problem was in mkmf.rb which had changed a bit since 2.0 but > after investigation it appears to be a change in > rubygems/ext/ext_conf_builder.rb: > 39c37,41 > < run cmd, results > --- > >begin > > run cmd, results > >ensure > > FileUtils.mv 'mkmf.log', dest_path if File.exist? 'mkmf.log' > >end > > Commenting FileUtils.mv fixed this issue. I honestly don't understand the > reason for moving the log file at all. That was probably added to help people debug built extensions, and kind of makes sense for the usual upstream use case where people install stuff from rubygems and have their binary extensions compiled at installation time. For this reason I think the best option is to make gem2deb cope with this. I am working on a fix for this. -- Antonio Terceiro signature.asc Description: Digital signature
Bug#743699: gamin: fails to build with clang instead of gcc
Source: gamin
Version: 0.1.10-4.1
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs
Dear Maintainer,
Your package fails to build with clang instead of gcc. [-Wreturn-type]
The attached patch fixes it.
Buildlogs and patch are here:
https://github.com/nonas/debian-clang/tree/master/buildlogs/gamin
Regards,
Nicolas
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Description: fix FTBFS with clang instead of gcc
Author: Nicolas Sévelin-Radiguet
Last-Update: 2014-04-05
--- a/server/gam_eq.c
+++ b/server/gam_eq.c
@@ -124,7 +124,7 @@
{
gboolean done_work = FALSE;
if (!eq)
- return;
+ return FALSE;
#ifdef GAM_EQ_VERBOSE
GAM_DEBUG(DEBUG_INFO, "gam_eq: Flushing event queue for %s\n", gam_connection_get_pidname (conn));
Bug#743700: RFS: spatialite/4.1.1-9
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "spatialite". Package name: spatialite Version : 4.1.1-9 Upstream Author : Alessandro Furieri URL : https://www.gaia-gis.it/fossil/libspatialite/ License : MPL-1.1 or GPL-2.0+ or LGPL-2.1+ Section : science It builds those binary packages: libspatialite-dev - Geospatial extension for SQLite - development files libspatialite5 - Geospatial extension for SQLite - libraries libspatialite5-dbg - Geospatial extension for SQLite - debugging symbols To access further information about this package, please visit the following URL: http://mentors.debian.net/package/spatialite Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/spatialite/spatialite_4.1.1-9.dsc More information about SpatiaLite can be obtained from https://www.gaia-gis.it/fossil/libspatialite/. Changes since the last upload: * Only install example C files, Makefile is architecture specific. (closes: #743683) Regards, Sebastiaan Couwenberg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743688: ruby: broken symlinks for testrb, rdoc and gem in the 2.0.0.1 ruby package
Control: reassign -1 ruby2.0 Control: forcemerge -1 737503 Hello, On Sat, Apr 05, 2014 at 02:51:58PM +0530, shirish शिरीष wrote: > Package: ruby > Version: 1:2.0.0.1 > Severity: normal > > Dear Maintainer, > Adequate reported broken symlinks for testrb, rdoc and gem in the ruby > package and sure enough they are broken. > > adequate found packaging bugs > - > > ruby: broken-symlink /usr/share/man/man1/testrb.1.gz -> testrb2.0.1.gz > ruby: broken-symlink /usr/share/man/man1/rdoc.1.gz -> rdoc2.0.1.gz > ruby: broken-symlink /usr/share/man/man1/gem.1.gz -> gem2.0.1.gz Thanks for your bug report. This is, however, a known issue. -- Antonio Terceiro signature.asc Description: Digital signature
Bug#743677: Fwd: Bug#743677: didjvu: RuntimeError: std::bad_alloc
Hi Jakub,
maybe you've seen that already.
Greetings,
Daniel
Original Message
Subject: Bug#743677: didjvu: RuntimeError: std::bad_alloc
Resent-Date: Sat, 05 Apr 2014 06:24:02 +
Resent-From: jsb...@mimuw.edu.pl (Janusz S. Bień)
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: jsb...@mimuw.edu.pl, Daniel Stender
Date: Sat, 05 Apr 2014 08:14:29 +0200
From: jsb...@mimuw.edu.pl (Janusz S. Bień)
Reply-To: jsb...@mimuw.edu.pl (Janusz S. Bień), 743...@bugs.debian.org
To: Debian Bug Tracking System
Package: didjvu
Version: 0.2.7-1
Severity: normal
When trying to convert to DjVu the scans from
http://www.polona.pl/item/304920/0/
(you need to log to download them, but a Google account will do)
I get
--8<---cut here---start->8---
jsbien@cauda:~/Kazania$ /usr/bin/time --version
GNU time 1.7
jsbien@cauda:~/Kazania$ /usr/bin/time didjvu bundle --fg-subsample 1
--bg-subsample 1 -o Kazania_1-1.djvu *.jpg
0015.jpg:
- reading image
- converting to DjVu
BG44=/tmp/didjvu.9mRyH8.iw44 --> "/tmp/didjvu.9mRyH8.iw44" (192953 bytes)
BG44=/tmp/didjvu.8JrMo7.iw44 --> "/tmp/didjvu.8JrMo7.iw44" (273246 bytes)
- 0.413 bits/pixel; 2.337:1, 57.21% saved, 3179253 bytes in, 1360504
bytes out
0016.jpg:
- reading image
- converting to DjVu
BG44=/tmp/didjvu.Lmlaxd.iw44 --> "/tmp/didjvu.Lmlaxd.iw44" (114707 bytes)
BG44=/tmp/didjvu.A3RioQ.iw44 --> "/tmp/didjvu.A3RioQ.iw44" (643929 bytes)
- 0.305 bits/pixel; 3.708:1, 73.03% saved, 3554038 bytes in, 958587
bytes out
0017.jpg:
- reading image
- converting to DjVu
BG44=/tmp/didjvu.StdNIt.iw44 --> "/tmp/didjvu.StdNIt.iw44" (39129 bytes)
BG44=/tmp/didjvu.ulu9av.iw44 --> "/tmp/didjvu.ulu9av.iw44" (140061 bytes)
- 0.194 bits/pixel; 4.008:1, 75.05% saved, 782287 bytes in, 195165 bytes out
0018.jpg:
- reading image
- converting to DjVu
BG44=/tmp/didjvu.DOXSuu.iw44 --> "/tmp/didjvu.DOXSuu.iw44" (41671 bytes)
BG44=/tmp/didjvu.w_KvYJ.iw44 --> "/tmp/didjvu.w_KvYJ.iw44" (103356 bytes)
- 0.205 bits/pixel; 3.918:1, 74.48% saved, 604421 bytes in, 154254 bytes out
0019.jpg:
- reading image
- converting to DjVu
Traceback (most recent call last):
File "/usr/bin/didjvu", line 9, in
didjvu.main()
File "/usr/share/didjvu/lib/didjvu.py", line 202, in __init__
parser.parse_args(actions=self)
File "/usr/share/didjvu/lib/cli.py", line 217, in parse_args
return action(o)
File "/usr/share/didjvu/lib/didjvu.py", line 343, in bundle
self.bundle_simple(o)
File "/usr/share/didjvu/lib/didjvu.py", line 372, in bundle_simple
parallel_for(o, self._bundle_simple_page, o.input, o.masks,
component_filenames)
File "/usr/share/didjvu/lib/didjvu.py", line 58, in parallel_for
f(o, *args)
File "/usr/share/didjvu/lib/didjvu.py", line 359, in _bundle_simple_page
self.encode_one(o, input, mask, component, None)
File "/usr/share/didjvu/lib/didjvu.py", line 286, in encode_one
djvu_doc = image_to_djvu(width, height, image, mask, options=o)
File "/usr/share/didjvu/lib/didjvu.py", line 157, in image_to_djvu
bg_djvu = make_layer(image, mask, subsample_bg, options.bg_options)
File "/usr/share/didjvu/lib/didjvu.py", line 138, in make_layer
image, mask = subsampler(image, mask, options)
File "/usr/share/didjvu/lib/didjvu.py", line 134, in subsample_bg
image = image.resize(dim, 1)
RuntimeError: std::bad_alloc
Command exited with non-zero status 1
306.00user 11.22system 4:44.51elapsed 111%CPU (0avgtext+0avgdata
2479212maxresident)k
36648inputs+1419240outputs (69major+4278373minor)pagefaults 0swaps
jsbien@cauda:~/Kazania$ free
total used free sharedbuffers cached
Mem: 411007212245162885556 155912 28816 299428
-/+ buffers/cache: 8962723213800
Swap: 8450184 118008438384
--8<---cut here---end--->8---
The same problems occurs with the following invocation:
--8<---cut here---start->8---
jsbien@cauda:~/Kazania$ /usr/bin/time didjvu encode --fg-subsample 1
--bg-subsample 1 --output-template Kazania_1-1_{base-ext}.djvu *.jpg
--8<---cut here---end--->8---
However it does not occur when the scan are processed one by one, e.g.
--8<---cut here---start->8---
jsbien@cauda:~/Kazania$ /usr/bin/time didjvu encode --fg-subsample 1
--bg-subsample 1 --output-template Kazania_1-1_{base-ext}.djvu 0019.jpg
0019.jpg:
- reading image
- converting to DjVu
BG44=/tmp/didjvu.FAdJjC.iw44 --> "/tmp/didjvu.FAdJjC.iw44" (418952 bytes)
BG44=/tmp/didjvu.iFWFeB.iw44 --> "/tmp/didjvu.iFWFeB.iw44" (566114 bytes)
- 0.535 bits/pixel; 2.547:1, 60.74% saved, 4294019 bytes in, 1685892
bytes out
100.72user 3.92system 1:28.58elapsed 118%CPU (0avgtext+0avgdata
1424168maxresident)k
15112inputs+455368outputs (61major+1461927minor)pagefaults 0swaps
--8<---cut here---end--->8---
Bug#743701: libva1=1.3.0-1 with i965 makes all video "solid black" with mpv --hwdec=vaapi
Package: i965-va-driver Version: 1.2.2-2 Severity: normal With the 1.3.0-1 version currently in unstable and i965-va-driver=1.2.2-2 on ivy bridge chip, $ mpv vc1.mkv --no-config --no-resume-playback --hwdec=vaapi --vo=opengl results in a solid black screen while the sound works. The vc1.mkv clip can be found at [1]. I found this happens with every hardware decodable clip I tried including h264 clips. The vc1 clip however neatly demonstrates that the problem is specifically with hardware decoding as seeking with left and right keys leads to (unrelated) decoding errors and a fallback to software decoding, at which point the video reappears! [1] https://dl.dropboxusercontent.com/u/60598588/vc1.mkv (29 M) The problem goes away on downgrading to libva1=1.2.1-2. Kevin -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'testing'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14.0.00 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages i965-va-driver depends on: ii libc6 2.18-4 ii libdrm-intel1 2.4.52-1 ii libdrm22.4.52-1 ii libva1 1.2.1-2 ii multiarch-support 2.18-4 i965-va-driver recommends no packages. i965-va-driver suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742818: fix test failures when built with GCC 4.9
On Sun, Mar 30, 2014 at 02:21:05PM +0300, Niko Tyni wrote: > forwarded 742818 https://rt.perl.org/Ticket/Display.html?id=121505 > thanks > > * Fix undefined behaviour in sv.c, resulting in test failures when > > built with GCC 4.9. Patch by Marek Polacek. > Marek also supplied fixes for other similar cases of undefined behaviour, > and those were present in the 5.18.2-2ubuntu1 patch. > > I'll wait a while for upstream to comment, but I expect this will be in > our next upload. While there isn't much discussion in the ticket, there were some around http://www.nntp.perl.org/group/perl.perl5.porters/2014/03/msg214103.html There's a concern that this problem is more widespread. Upstream is considering enabling the gcc '-fwrapv' option to get the desired behaviour in such cases. -- Niko Tyni nt...@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#743702: ftools-fv: fails to build with clang instead of gcc
Source: ftools-fv Version: 5.3+dfsg-4 Severity: minor Tags: patch User: pkg-llvm-t...@lists.alioth.debian.org Usertags: clang-ftbfs Dear Maintainer, Your package fails to build with clang instead of gcc. [-Wreturn-type] The attached patch fixes it. Buildlogs and patch are here: https://github.com/nonas/debian-clang/tree/master/buildlogs/ftools-fv Regards, Nicolas -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Description: fix FTBFS with clang instead of gcc Author: Nicolas Sévelin-Radiguet Last-Update: 2014-04-05 --- a/tcltk/pow/PowUtils.c +++ b/tcltk/pow/PowUtils.c @@ -664,7 +664,7 @@ sprintf (errormsg, "Couldn't construct WCS information: %s", WCSpih_Message[status]); Tcl_SetResult(interp, errormsg ,TCL_VOLATILE); Tcl_SetVar(interp,"powWCSTranslation", WCSpih_Message[status] ,TCL_GLOBAL_ONLY); -return; +return -1; } listObj = Tcl_NewObj(); @@ -791,7 +791,7 @@ sprintf (errormsg, "Couldn't construct WCS information: %s", WCSpih_Message[status]); Tcl_SetResult(interp, errormsg ,TCL_VOLATILE); Tcl_SetVar(interp,"powWCSTranslation", WCSpih_Message[status] ,TCL_GLOBAL_ONLY); -return; +return -1; } listObj = Tcl_NewObj();
Bug#743703: r-base: FTBFS on armhf
package: r-base version: 3.0.3.20140403-1 severity: serious Hi, The latest upload of r-base FTBFS on armhf: https://buildd.debian.org/status/package.php?p=r-base It seems the previous version built fine. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743704: python-setuptools fails to install
Package: python-setuptools Version: 3.3-1 Severity: important python-setuptools fails to install with the following messages: > Preparing to unpack .../python-setuptools_3.4.1-1_all.deb ... > Unpacking python-setuptools (3.4.1-1) over (3.3-1) ... > dpkg: error processing archive /var/cache/apt/archives/python- setuptools_3.4.1-1_all.deb (--unpack): > trying to overwrite '/usr/lib/python2.7/dist-packages/build', which is also in package python-pyaudio 0.2.7-2+b1 > dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) > E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-setuptools depends on: iu python-pkg-resources 3.4.1-1 pn python:any python-setuptools recommends no packages. python-setuptools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743705: Flash video doesn't work full-screen
Package: libmutter0b Version: 3.8.4-3 Severity: wishlist Tags: patch Hi! Could you apply the patch from https://bug700288.bugzilla- attachments.gnome.org/attachment.cgi?id=267229 (see the bugzilla thread at https://bugzilla.gnome.org/show_bug.cgi?id=700288) please? This will allow to show flash videos fullscreen in gnome 3. -- Thanks, Alexei -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.8 (SMP w/6 CPU cores) Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libmutter0b depends on: ii gsettings-desktop-schemas 3.8.2-2 ii libatk1.0-0 2.10.0-2 ii libc6 2.18-4 ii libcairo-gobject2 1.12.16-2 ii libcairo2 1.12.16-2 ii libcanberra-gtk3-0 0.30-2 ii libcanberra00.30-2 ii libclutter-1.0-01.18.0-2 ii libcogl-pango20 1.18.0-2 ii libcogl-path20 1.18.0-2 ii libcogl20 1.18.0-2 ii libdrm2 2.4.52-1 ii libegl1-mesa [libegl1-x11] 10.1.0-4 ii libgbm1 10.1.0-4 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libgirepository-1.0-1 1.38.0-2 ii libglib2.0-02.38.2-5 ii libgtk-3-0 3.10.7-1 ii libice6 2:1.0.8-2 ii libjson-glib-1.0-0 0.16.2-1 ii libpango-1.0-0 1.36.0-1+b1 ii libpangocairo-1.0-0 1.36.0-1+b1 ii libsm6 2:1.2.1-2 ii libstartup-notification00.12-3 ii libwayland-client0 1.4.0-1 ii libwayland-cursor0 1.4.0-1 ii libwayland-egl1-mesa [libwayland-egl1] 10.1.0-4 ii libwayland-server0 1.4.0-1 ii libx11-62:1.6.2-1 ii libxcomposite1 1:0.4.4-1 ii libxcursor1 1:1.1.14-1 ii libxdamage1 1:1.1.4-1 ii libxext62:1.3.2-1 ii libxfixes3 1:5.0.1-1 ii libxi6 2:1.7.2-1 ii libxinerama12:1.1.3-1 ii libxkbcommon0 0.4.0-1 ii libxrandr2 2:1.4.2-1 ii libxrender1 1:0.9.8-1 ii mutter-common 3.8.4-3 libmutter0b recommends no packages. libmutter0b suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742135: fixed in enigmail 2:1.6+git0.20140323-1
On 27-03-14 04:20, Daniel Kahn Gillmor wrote: > Source: enigmail > Source-Version: 2:1.6+git0.20140323-1 > Distribution: experimental Was it really intentional to upload to experimental? Enigmail is now listed for removal from testing because this bug is not fixed in sid. Paul signature.asc Description: OpenPGP digital signature
Bug#743706: Package broken due to initramfs-tools (< 0.110~) is 0.109.1
Package: linux-image-3.13-0.bpo.1-amd64 Version: 3.13.7-1~bpo70+1 Severity: important Hello, the package cannot be installed, because the dependency to initramfs-tools is incorrect. Regards Karsten -- System Information: Debian Release: 7.3 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743707: jscommunicator fails to build from source
Package: jscommunicator
Version: 1.1.1-1
Severity: serious
Tags: sid jessie
seen in current unstable:
make[1]: Entering directory `/scratch/packages/tmp/jscommunicator-1.1.1'
./make-release
/usr/bin/closure-compiler: line 1: $'PK\003\004': command not found
/usr/bin/closure-compiler: line 2: $'\b3\236!D': command not found
/usr/bin/closure-compiler: line 3:.�!Dcom/PK: No such file or directory
/usr/bin/closure-compiler: line 4:.�!D
com/google/PK: No such file or directory
/usr/bin/closure-compiler: line 5:.�!Dcom/google/debugging/PK: No such file or
directory
/usr/bin/closure-compiler: line 6:0�!Dcom/google/debugging/sourcemap/PK: No such
file or directory
/usr/bin/closure-compiler: line 7:.�!D%com/google/debugging/sourcemap/proto/PK:
No such file or directory
/usr/bin/closure-compiler: line 8:0�!Dcom/google/javascript/PK: No such file or
directory
/usr/bin/closure-compiler: line 9:2�!Dcom/google/javascript/jscomp/PK: No such
file or directory
/usr/bin/closure-compiler: line 10:2�!D!com/google/javascript/jscomp/ant/PK: No
such file or directory
/usr/bin/closure-compiler: line 16:2�!Dcom/google/javascript/jscomp/deps/PK
2�!D#com/google/javascript/jscomp/graph/PK
2�!D
com/google/javascript/jscomp/js/PK
2�!D%com/google/javascript/jscomp/parsing/PK
2�!D#com/google/javascript/jscomp/regex/PK
2�!Dcom/google/javascript/jscomp/type/PK: No such file
or directory
/usr/bin/closure-compiler: line 17:2�!Dcom/google/javascript/rhino/PK: No such
file or directory
/usr/bin/closure-compiler: line 18:2�!D#com/google/javascript/rhino/jstype/PK:
No such file or directory
/usr/bin/closure-compiler: line 19: $'\b2\236!D': command not found
/usr/bin/closure-compiler: line 20: rhino_ast/PK: No such file or directory
/usr/bin/closure-compiler: line 21:2�!Drhino_ast/java/PK: No such file or
directory
/usr/bin/closure-compiler: line 22:2�!Drhino_ast/java/com/PK: No such file or
directory
/usr/bin/closure-compiler: line 23:2�!Drhino_ast/java/com/google/PK: No such
file or directory
/usr/bin/closure-compiler: line 24:2�!D%rhino_ast/java/com/google/javascript/PK:
No such file or directory
/usr/bin/closure-compiler: line
25:2�!D+rhino_ast/java/com/google/javascript/rhino/PK: No such file or directory
/usr/bin/closure-compiler: line 26: syntax error near unexpected token `)'
/usr/bin/closure-compiler: line
26:0�!Dz�BWH�+com/google/debugging/sourcemap/Base64.class�TKS�V��_2B�<¥N#@�/�I$@#��2M��*��L;�I�t�$3�)�v�ҙ��N_��҄E�W��s�@h
B0.F���$_��rC��"��S~�E�3��8+ঈ[ȉ��9n�
�gS�bvd��wt`��6+��-
��B}��ZKܙ�eE_Q,���F.���v�j�U]�W�R�Z%~�Y��궲
O)5ud�m��N���@��۠Έe�h+���N3��a��aez(�g���nՒ�5�pwp�cf��t&;{�V��\~~��x�nqiy5�T���Mm끾
m�;_X5�G��%�_m�ni�>�lЙ���]H5ot=��/3��_� X�p��JXú�O���J[j�z�SvvT�f�r�}
�W��*'|�h��48
��Z�,�r�,͡]�9���a�u[��I�RхgC�u�]��]5}���p^:��J��"���4d��S�vƭ���^8!gh�9�0��*5��moѿ��%^��Q98�=���z��>�!�C�>�_B�t�~p�r$��Q�0�Z�}�\A�p/�OW�Xu�%�ः�s}���8��1�)ځ*,I�H9Pݍ$�0H���:t�
�-Yy���7�'
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory `/scratch/packages/tmp/jscommunicator-1.1.1'
make: *** [binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743708: libvirt-bin: AppArmor profile template installed in the wrong place
Package: libvirt-bin Version: 1.2.1-1 Severity: normal Hi, libvirt complain that its AppArmor template does not exist: libvirtd[9079]: internal error: template '/etc/apparmor.d/libvirt/TEMPLATE' does not exist ... and indeed, the template is installed in /etc/apparmor.d/libvirtd/TEMPLATE instead. (Once I fix this by hand, AppArmor denies the audit_write capability to libvirtd, that apparently needs it. I'll report this separately if needed. And once I allow libvirtd to use this capability, I get "internal error: cannot load AppArmor profile 'libvirt-6da57234-587c-4119-3c3a-f064574cb3dc'", but I assume this is expected until #725144 is resolved.) Cheers, -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libvirt-bin depends on: ii adduser 3.113+nmu3 ii gettext-base 0.18.3.2-1 ii init-system-helpers 1.18 ii libapparmor1 2.8.0-5+b1 ii libaudit11:2.3.4-1 ii libavahi-client3 0.6.31-4 ii libavahi-common3 0.6.31-4 ii libblkid12.20.1-5.7 ii libc62.18-4 ii libcap-ng0 0.7.3-1+b1 ii libdbus-1-3 1.8.0-3 ii libdevmapper1.02.1 2:1.02.83-2 ii libfuse2 2.9.3-8 ii libgcrypt11 1.5.3-4 ii libgnutls26 2.12.23-13 ii libnetcf11:0.2.3-4 ii libnl-3-200 3.2.24-1 ii libnl-route-3-2003.2.24-1 ii libnuma1 2.0.9~rc5-1 ii libparted0debian12.3-18 ii libpcap0.8 1.5.3-2 ii libpciaccess00.13.2-1 ii librados20.72.2-2 ii librbd1 0.72.2-2 ii libreadline6 6.3-5 ii libsasl2-2 2.1.26.dfsg1-9 ii libselinux1 2.2.2-1 ii libssh2-11.4.3-2 ii libudev1 204-8 ii libvirt0 1.2.1-1 ii libxen-4.3 4.3.0-3+b1 ii libxenstore3.0 4.3.0-3+b1 ii libxml2 2.9.1+dfsg1-3 ii libyajl2 2.0.4-4 ii logrotate3.8.7-1 Versions of packages libvirt-bin recommends: ii bridge-utils1.5-7 ii dmidecode 2.12-2 ii dnsmasq-base2.68-1 pn ebtables ii iproute 1:3.12.0-2 ii iptables1.4.21-1 ii libxml2-utils 2.9.1+dfsg1-3 ii netcat-openbsd 1.105-7 ii parted 2.3-18 ii pm-utils1.4.1-13 ii qemu1.7.0+dfsg-5 ii qemu-kvm1.7.0+dfsg-5 Versions of packages libvirt-bin suggests: ii apparmor 2.8.0-5+b1 pn auditd ii policykit-1 0.105-4 pn radvd ii systemd 204-8 ii systemtap2.3-1 -- 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#731959: Fwd: debian / esajpip
[...] If you follow the whole thread, get_proc_stats is not available anymore in recent procps releases. Therefore the only solution is to follow: http://www.freelists.org/post/procps/private-symbol-get-proc-stats,1 Would it be possible that it gets included in upstream directly instead of within a debian patch. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738978: transition: x264
Control: tag -1 confirmed On Fri, Feb 14, 2014 at 13:27:53 +, Reinhard Tartler wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > I've prepared a new upstream release of libx264, and we need to rebuild > all applications that link against it. AFAIUI, this transition should be > rather smooth because it affects only a few packages. > Feel free to upload to unstable. Cheers, Julien signature.asc Description: Digital signature
Bug#734588: transition sdlgfx 2.0.23 to 2.0.25
Control: tag -1 confirmed On Wed, Jan 8, 2014 at 10:40:06 +, Gianfranco Costamagna wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > (opening a bug, sorry for double posting) > Hi debian release Managers! > > Together with Manuel (the sdlgfx uploader, who reads in cc), we decided to > ask for a transition > > the package can be found here [1] and brings a really similar API, but the > packages that build-deps from it will likely need a binNMU to build against > the new ABI/API. > Feel free to upload to unstable. Cheers, Julien signature.asc Description: Digital signature
Bug#743709: ITP: ruby-opengraph-parser -- library for parsing Open Graph Protocol information from a website
package: wnpp severity: wishlist Upstream url: https://rubygems.org/gems/opengraph_parser Upstream authors: Huy Ha, Duc Trinh License: Expat -- പ്രവീണ് അരിമ്പ്രത്തൊടിയില് You have to keep reminding your government that you don't get your rights from them; you give them permission to rule, only so long as they follow the rules: laws and constitution.
Bug#743379: ITP: gravit -- visually stunning gravity simulator
On 02/04/14 18:06, Thibaut Paumard wrote: > Le 02/04/2014 17:22, Tomasz Buchert a écrit : > > On 02/04/14 15:21, Andreas Tille wrote: > >> Hi Tomasz, > >> > >> I guess you might like to maintain this package in Debian Astro team. > > Hi Andreas, > > I totally agree, it is a great idea. Do I have to do something > > special about it? > > What about stellarium? I'm doing completely fine alone, but, > > well, what do you think? > > > > Yes please :-) > > We don't have a policy yet, I think you can just apply the > debian-science policy with s/debian-science/debian-astro/. > > The essential steps are to put debian-astro-maintainers@lists.alioth.d.o > in the Maintainer field, yourself as Uploader, and putting the package > in a git repository on alioth under /git/debian-astro. > > Of course you also need to subscribe to > debian-astro-maintainers@lists.alioth.d.o, debian-astro@lists.d.o and > request to be added to the alioth project. > > https://alioth.debian.org/projects/debian-astro > https://lists.alioth.debian.org/mailman/listinfo/debian-astro-maintainers > http://debian-science.alioth.debian.org/debian-science-policy.html > > Regards, Thibaut. > > Hi Thibaut, I did as you wrote and pushed changes to d/control of gravit [1] and stellarium [2]. I asked to join astro team and subscribed to the mailing lists. I cannot move git repositories to /git/debian-astro before being accepted as a member of astro team, though. Funnily, I still see no sponsors for gravit. :) Tomasz [1] http://anonscm.debian.org/gitweb/?p=collab-maint/gravit.git;a=commit;h=6baab5a7e3f0067b6d4a6a8ba10eb658f89aa3b8 [2] http://anonscm.debian.org/gitweb/?p=collab-maint/stellarium.git;a=commit;h=ff723308ecabd224f4260cd8adf3386cbc804d53 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743675: retitle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 retitle 743675 ITP: python-django-remote-forms -- Platform independent form serializer for Django thanks Fix typos in bug reports to match correct package name "python-django-remote-forms". Below the correct summary of package: * Package name: python-djando-remote-forms Version : 0.0.1 (alpha pre release) Upstream Author : WiserTogether Tech Team * URL : https://github.com/WiserTogether/django-remote-forms.git * License : MIT Programming Lang: Python Description : Platform independent form serializer for Django This package allows you to serialize django forms, including fields and widgets into Python dictionary for easy conversion into JSON and expose over API Ciao, Marco -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTP/snAAoJEI1bR4z3/k2qr4AP/jurbbbtgRV8jUVgYUM5H77E ll2/nPMln2MCi2uZhwLOalX/pcFThKxVb1h+Uv6qhhKUl4q4J7ibmpUyH744RmKG tNjUEperxHr7JB8LWsSCN/3UGvJbk3RAhMRz3HYf0KIWoTu7cFWrHNHcitvtLTb5 DhDejUJsoRc/TJwpRdatdf5GGlH38dNoZgM9oY5z/Pr8qfjpITv1BJEeUhQK7sSE fjnUtSvl+rz4cejxzb0oOjp2TkTSQSHwCBzXyPcb04ypKTz5Aa5psk75gt5mnRB2 N5JfxkwfPTvwOa0HOXAxtspNMOuZLnjJbb4HZ5Nyvo7SBS7N9XklIwDJbBmj5VaP AogLCQpkZ8KxG5ad75JOxpvnKduCeSaIq7jzTz/93RydtZHi4HuC58DyOcUNXR8n odmIMbeUa4dEmYbyaMIJFGDbpbNd78X63LlNmLAwMkvHwTniXvwCKIvhBHBT4odS njWuXTY4PwC7hY7puMtF+fN8lYDDFWH34G5fnJCe53D0r5INZwpI0TqVxkV/Dwnj Uj0r5DE+b8lJsZ6Fiiw61FmpUrYvWbi5wG/m+vOWvy0ZYV4LLDiPgwXTpf4g4Hkt pe7wlv2SM/UtN7tNPQSso6/rT8G5DPtIdNvRZymCCIdahPR9LVVWk0W5a+Cy54dp bL8qf9r+5gQ48OZb1Rdb =OwHb -END PGP SIGNATURE- -- GPG key: 4096R/0xF7FE4DAA 2013-08-02 Marco Bardelli -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734238:
Just for reference, I was given by geissert@d.o the input files to reproduce the segfault. segfaul1.dpatch work around issue as demonstrated in: https://openjpeg.googlecode.com/svn/data/input/nonregression/edf_c2_20.jp2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743710: ITP: mlpack -- Fast and scalable C++ machine learning library
Package: wnpp Owner: Barak A. Pearlmutter Severity: wishlist Package name: mlpack Version : 1.0.8 Upstream Author : Ryan Curtin URL or Web page : http://www.mlpack.org/ License : LGPL-3+ Description : Fast and scalable C++ machine learning library MLPACK (Machine Learning PACK) is an intuitive, fast, and scalable C++ machine learning library, meant to be a machine learning analog to LAPACK. It aims to implement a wide array of machine learning methods and function as a "swiss army knife" for machine learning researchers. Upstream has been notified of this ITP, and is encouraging. For a preliminary packaging, see git://anonscm.debian.org/debian-science/packages/mlpack.git Most of the lintian issues are due to doxygen generating bogus man pages. Excepting those, I'd hope to either address or report the issues to upstream for most of the others before uploading. --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#734238:
Control: tag -1 patch confirmed
Here is the backported patch (attached). I have no clue on how to use
dpatch to convert it. 20.jp2 does not segfault anymore, and p0_06.j2k
does decode normally.
--- libopenjpeg/tcd.c 2014-04-05 14:49:32.0 +0200
+++ ../../openjpeg-1.3+dfsg/libopenjpeg/tcd.c 2014-04-05 14:40:25.0 +0200
@@ -1415,6 +1415,17 @@
if (tcd->tcp->mct) {
int n = (tile->comps[0].x1 - tile->comps[0].x0) * (tile->comps[0].y1 - tile->comps[0].y0);
+
+#if 1
+ /* testcase 1336.pdf.asan.47.376 */
+ if ((tile->comps[0].x1 - tile->comps[0].x0) * (tile->comps[0].y1 - tile->comps[0].y0) < n ||
+( tile->comps[1].x1 - tile->comps[1].x0) * (tile->comps[1].y1 - tile->comps[1].y0) < n ||
+( tile->comps[2].x1 - tile->comps[2].x0) * (tile->comps[2].y1 - tile->comps[2].y0) < n) {
+opj_event_msg(tcd->cinfo, EVT_ERROR, "Tiles don't all have the same dimension. Skip the MCT step.\n");
+return false;
+ }
+#endif
+
if (tcd->tcp->tccps[0].qmfbid == 1) {
mct_decode(
tile->comps[0].data,
Bug#734238:
On Sat, Apr 5, 2014 at 3:05 PM, Mathieu Malaterre wrote: > Control: tag -1 patch confirmed > > Here is the backported patch (attached). I have no clue on how to use > dpatch to convert it. 20.jp2 does not segfault anymore, and p0_06.j2k > does decode normally. Of course segfault1.dpatch needs to be completely remove first. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743703: r-base: FTBFS on armhf
On 5 April 2014 at 13:55, Ivo De Decker wrote: | package: r-base | version: 3.0.3.20140403-1 | severity: serious | | Hi, | | The latest upload of r-base FTBFS on armhf: | | https://buildd.debian.org/status/package.php?p=r-base | | It seems the previous version built fine. gcc -std=gnu99-I../../src/extra -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -fopenmp -fpic -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -g -c deparse.c -o deparse.o gcc -std=gnu99-I../../src/extra -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -fopenmp -fpic -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -g -c devices.c -o devices.o gcc -std=gnu99-I../../src/extra -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -fopenmp -fpic -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -g -c dotcode.c -o dotcode.o dotcode.c: In function 'do_dotcall': dotcode.c:1231:1: internal compiler error: Segmentation fault } ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. The bug is not reproducible, so it is likely a hardware or OS problem. make[4]: *** [dotcode.o] Error 1 make[4]: Leaving directory `/«PKGBUILDDIR»/src/main' make[3]: *** [R] Error 2 make[3]: Leaving directory `/«PKGBUILDDIR»/src/main' make[2]: *** [R] Error 1 make[2]: Leaving directory `/«PKGBUILDDIR»/src' make[1]: *** [R] Error 1 make[1]: Leaving directory `/«PKGBUILDDIR»' make: *** [make-arch-stamp] Error 2 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2 That's a gcc error. I changed how to set CFLAGS etc by calling dpkg-buildflags so I am pretty much playing by the book. What do you suggest I do? Take out -O2 or -g on armhf? Dirk | Cheers, | | Ivo -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704805: Bug#726913: r-base-dev: does not use the dpkg-buildflags options for gfortran, specifically LDFLAGS
On 5 April 2014 at 02:48, Vincent Danjean wrote: | On 04/04/2014 16:27, Dirk Eddelbuettel wrote: | > | It would also mean that the critical r-base transition to testing can | > | only happen when all of the depending add-on packages have been | > | upgraded or removed from testing, making the transition far, far | > | smoother. Yes, it may only happen once every five years, but the pain | > | was significant last time, and this is a very simple way to avoid that | > | next time round. | > | > This is where we differ. I did not see the last (or previous) transition as | > painful. At all. [1] | | It has been for me. Me and some colleagues did partial upgrades of R as | we need a r-package that need a newer r-core. And, suddenly, lots of other | r packages stopped working. | The workaround have been to force the upgrade of all r-* installed | packages. But it means that all theses packages are now marked as | manually installed (whereas most of them was dependencies). Well I personally upgraded my large set of r-cran-* packages within days. I pestered other maintainers to do it for theirs. This report, months after the fact, does not help all that much as it lacks information about _which_ packages failed and _how_. | Currently, R is unusable with partial upgrade between stable and | testing. However, this is something that we must support (and that have | a severity above normal) Not ideal but I don't think that partially upgrades between stable and testing are a goal of the project or distribution. The goal is to get testing where we can cut a new stable. If current testing works... | > [1] I have one persistent pain point, but that is unrelated to the transition | > and your proposal. Well maybe it is related: there are group-maintained | > r-cran-* packages that are simply poorly maintained. Look at the Debian QA | > pages, some slip behind a few upstream releases. In that context I do not | > want a poorly maintained package to block the transitiont of R itself. | | When this happens on other cited examples, the maintainer request the | removal from testing of the offending (not updated) packages. In any case, | they do not work with the new R. Better remove them (from testing) quickly | instead of having to detect them manually latter and mark them as RC. We can do that now too. A new tag 'r-api-version' of whatever is not needed for removals. I still feel that the suggested approach may be too heavy-handed. Dirk | Regards, | Vincent | -- | Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org | GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA | Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html | APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743711: softhsm: Please add a p11-kit config file for softhsm
Package: softhsm Version: 1.3.5-1 Severity: wishlist Dear Maintainer, Please consider adding a /etc/pkcs11/modules/softhsm.module file to the package, so that aribtrary systems on the machine can detect and use softhsm without additional configuration. Documentation about this file is here: http://p11-glue.freedesktop.org/doc/p11-kit/pkcs11-conf.html -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages softhsm depends on: ii libbotan-1.10-0 1.10.5-1 ii libc62.17-96 ii libgcc1 1:4.8.2-4 ii libsofthsm 1.3.5-1 ii libsqlite3-0 3.8.1-1 ii libstdc++6 4.8.2-4 ii softhsm-common 1.3.5-1 softhsm recommends no packages. softhsm suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738978: transition: x264
On 05.04.2014 08:46, Julien Cristau wrote: Control: tag -1 confirmed On Fri, Feb 14, 2014 at 13:27:53 +, Reinhard Tartler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I've prepared a new upstream release of libx264, and we need to rebuild all applications that link against it. AFAIUI, this transition should be rather smooth because it affects only a few packages. Feel free to upload to unstable. Uploaded, thanks. Reinhard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743708: [Pkg-libvirt-maintainers] Bug#743708: libvirt-bin: AppArmor profile template installed in the wrong place
Hi, On Sat, Apr 05, 2014 at 02:40:31PM +0200, intrig...@debian.org wrote: > Package: libvirt-bin > Version: 1.2.1-1 > Severity: normal > > Hi, > > libvirt complain that its AppArmor template does not exist: > > libvirtd[9079]: internal error: template '/etc/apparmor.d/libvirt/TEMPLATE' > does not exist > > ... and indeed, the template is installed in > /etc/apparmor.d/libvirtd/TEMPLATE instead. > > (Once I fix this by hand, AppArmor denies the audit_write capability > to libvirtd, that apparently needs it. I'll report this separately if > needed. And once I allow libvirtd to use this capability, I get > "internal error: cannot load AppArmor profile > 'libvirt-6da57234-587c-4119-3c3a-f064574cb3dc'", but I assume this is > expected until #725144 is resolved.) Thanks for checking out apparmor support but please don't file individual bugs until we have apparmor support "officialy" enabled. Adding your findings to 725144 is very much appreciated though. Cheers, -- Guido > > Cheers, > > -- System Information: > Debian Release: jessie/sid > APT prefers unstable > APT policy: (990, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages libvirt-bin depends on: > ii adduser 3.113+nmu3 > ii gettext-base 0.18.3.2-1 > ii init-system-helpers 1.18 > ii libapparmor1 2.8.0-5+b1 > ii libaudit11:2.3.4-1 > ii libavahi-client3 0.6.31-4 > ii libavahi-common3 0.6.31-4 > ii libblkid12.20.1-5.7 > ii libc62.18-4 > ii libcap-ng0 0.7.3-1+b1 > ii libdbus-1-3 1.8.0-3 > ii libdevmapper1.02.1 2:1.02.83-2 > ii libfuse2 2.9.3-8 > ii libgcrypt11 1.5.3-4 > ii libgnutls26 2.12.23-13 > ii libnetcf11:0.2.3-4 > ii libnl-3-200 3.2.24-1 > ii libnl-route-3-2003.2.24-1 > ii libnuma1 2.0.9~rc5-1 > ii libparted0debian12.3-18 > ii libpcap0.8 1.5.3-2 > ii libpciaccess00.13.2-1 > ii librados20.72.2-2 > ii librbd1 0.72.2-2 > ii libreadline6 6.3-5 > ii libsasl2-2 2.1.26.dfsg1-9 > ii libselinux1 2.2.2-1 > ii libssh2-11.4.3-2 > ii libudev1 204-8 > ii libvirt0 1.2.1-1 > ii libxen-4.3 4.3.0-3+b1 > ii libxenstore3.0 4.3.0-3+b1 > ii libxml2 2.9.1+dfsg1-3 > ii libyajl2 2.0.4-4 > ii logrotate3.8.7-1 > > Versions of packages libvirt-bin recommends: > ii bridge-utils1.5-7 > ii dmidecode 2.12-2 > ii dnsmasq-base2.68-1 > pn ebtables > ii iproute 1:3.12.0-2 > ii iptables1.4.21-1 > ii libxml2-utils 2.9.1+dfsg1-3 > ii netcat-openbsd 1.105-7 > ii parted 2.3-18 > ii pm-utils1.4.1-13 > ii qemu1.7.0+dfsg-5 > ii qemu-kvm1.7.0+dfsg-5 > > Versions of packages libvirt-bin suggests: > ii apparmor 2.8.0-5+b1 > pn auditd > ii policykit-1 0.105-4 > pn radvd > ii systemd 204-8 > ii systemtap2.3-1 > > -- > intrigeri > | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc > | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc > > ___ > Pkg-libvirt-maintainers mailing list > pkg-libvirt-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-libvirt-maintainers > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743703: r-base: FTBFS on armhf
Hi Dirk, On Sat, Apr 05, 2014 at 08:11:03AM -0500, Dirk Eddelbuettel wrote: > That's a gcc error. > > I changed how to set CFLAGS etc by calling dpkg-buildflags so I am pretty > much playing by the book. What do you suggest I do? Take out -O2 or -g on > armhf? It's probably a good idea to submit a bug report against gcc, and to notify the arm* porters, to make sure the gcc issue is investigated. In the mean time, however, the missing build on armhf will block migration to testing, so if you can fix the build by changing the CFLAGS, that's probably best for now. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735763: svnkit is marked for autoremoval from testing
Hi Markus, On Sat, Apr 05, 2014 at 12:47:52PM +0200, Markus Koschany wrote: > On 03.04.2014 15:34, Miguel Landaeta wrote: > > > > I'll review it and upload it to DELAYED/5 if everything is OK. I just uploaded trilead-ssh2 to DELAYED/5. > that would be great. Please go ahead and let me know if there is something > that should be changed. I modified your NMU to also install Maven artifacts for this library. I'm going to eventually need that. > > If Matthew gives his consent, we can move trilead-ssh2 to debian-java > > as you said. > > I'm in favour of it but of course it's up to Matthew to decide. Let's wait for him. In the meantime I'm going to review your changes to svnkit. Thanks for taking the time to fixing these packages. Cheers, -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://db.debian.org/fetchkey.cgi?fingerprint=4CB7FE1E280ECC90F29A597E6E608B637D8967E9 "Faith means not wanting to know what is true." -- Nietzsche signature.asc Description: Digital signature
Bug#740375: transition: poppler 0.24
Control: tag -1 confirmed On Fri, Feb 28, 2014 at 19:44:28 +0100, Pino Toscano wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi, > > I would like to ask a slot for a Poppler 0.24.x transition. Feel free to upload to unstable. Cheers, Julien signature.asc Description: Digital signature
Bug#100808:
Get Easy & Quick Loans at 2.5 % From H-Loan Company plc,Reply to this E-mail:hloand...@rogers.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743675: retitle
Control: retitle -1 ITP: python-django-remote-forms -- Platform independent form serializer for Django thanks -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Below the (really) correct summary of package: * Package name: python-django-remote-forms Version : 0.0.1 (alpha pre release) Upstream Author : WiserTogether Tech Team * URL : https://github.com/WiserTogether/django-remote-forms.git * License : MIT Programming Lang: Python Description : Platform independent form serializer for Django This package allows you to serialize django forms, including fields and widgets into Python dictionary for easy conversion into JSON and expose over API Ciao, Marco -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTQA5BAAoJEI1bR4z3/k2qumcP/1jYNG5a/qss9qL84GB8vQUp TUR81ciUAqMtQ2n6+9W+QpCRL4XeikFX/n173GqZNKw07YX+6M/6wLNHm4kKuwyF pfTee7oMaIGf7nlLtZs74D1IpfXyBj+zN8Y9TiYGnWim3apwusJPTqcoDlr8swBd SqnvQcjzUSLFVu4F/CiHqc/HmrROj7Y7jjA5uP1EeQT2ikFH3/cB4VitRpZDOJIP EBC7nZo8mX1Zyhmi9abFc62iBrkxDV9SNkDAoOVVW4AODKHeJkbdBf73D7GU7+8A rInU5eal4ewmluxuL6ZDeImkemlWseHPy2KXkm594L+K4KL3Khn2+3CL2fih46dr mANcVpEDpWoZaFGyoiuMczoTfmYXJX7j6kUPQwM7MWs7QiAG16JhSN7GQM2qX4et UDfVxJUeib8U9pjNB7cnfHvoeWv2bYNEF1GeX9dMAVIs3RXpqcljQs9i4+/85sZP QHCxlCCbsAFdKAIBA5Wequ52J8+NAz1uFve6YGIDaxAdrzfGfqD/N2r0VvB09npP mh7YEAOIB0LumwYPW7+2WO33+g09RFCDmJZNgk4IIRvliiScLGNbHiSpqMwxwLPK ihblxiv1Rz/AOCxuXDFLQ887AwzoqtDbnFXOjJvZJAgNpmmjZw0hZ3YHV1IEahqs wO/BF5hmvwqThs6T5OrB =aeVp -END PGP SIGNATURE- -- GPG key: 4096R/0xF7FE4DAA 2013-08-02 Marco Bardelli -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#735563: Bug #735563: udev: 70-persistent-net.rules not updated when adding or changing NIC
On Fri 04 Apr 2014 at 06:28:48 +0200, Michael Biebl wrote: > On 4. April 2014 05:43:10 MESZ, Stephen Powell wrote: > > > >You may ship it, but it doesn't actually work. It may be useful during > >installation, but if you erase the file after installation, it does not > >get re-created, and if you add a new NIC after installation, the new > >data for the new card does not get appended. Are you saying that, in > >the > >Debian version of systemd, this is supposed to work? If that is your > >claim, > >then in Debian, this is a bug after all. > > If it doesn't work it's a bug The following was done on an install from d-i's Jessie Alpha 1 release. Only the base system was installed, so no DE. 1. Observed that 70-persistent-net.rules was created by 'Detect network hardware' and was present on first boot of the new system. 2. Adding a USB wireless adapter resulted in an entry being appended to 70-persistent-net.rules. 3. Deleted the file. 'udevadm trigger --action=add' re-created it with all interfaces present. 4. Deleted the file again and rebooted. 5. 70-persistent-net.rules did not exist but the udevadm command creates it. 6. Rebooted with 'net.ifnames=1' after deleting 70-persistent-net.rules. 7. Data is not added when the USB adapter is inserted, the udevadmn command has ceased to work and 70-persistent-net.rules is not present. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743360: fuse: install fails
On 4-Apr-14, at 9:50 PM, Jeff King wrote: On Wed, Apr 02, 2014 at 07:22:00PM -0400, John David Anglin wrote: mx3210:/var/cache/apt/archives/fuse/DEBIAN# sh ./postinst configure + dpkg-statoverride --list /bin/fusermount + chmod 4755 /bin/fusermount + [ -x /sbin/MAKEDEV ] + [ ! -e /dev/fuse ] + echo MAKEDEV not installed, skipping device node creation. MAKEDEV not installed, skipping device node creation. + udevadm control --reload-rules + udevadm info -q path -n /dev/fuse device node not found I had the same problem. Running "modprobe fuse" before the upgrade fixes it. Shouldn't the script do that? Also, "MAKEDEV" is installed, so the "not installed" message is misleading. Thanks for the tip. Dave -- John David Anglin dave.ang...@bell.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739409: [ocl-icd-libopencl1] Broken symbols file
Hi, On 05/04/2014 13:04, Andreas Cadhalpun wrote: > You're right: the more serious problem is that nvidia-libopencl1 doesn't work > with a program build with ocl-icd-opencl-dev. > I just tested amd-libopencl1 and it works. nvidia-libopencl1 only support OpenCL 1.1. If you use OpenCL 1.2 features, you need an libopencl1 that support it. From my point of view, this comes from a very bad design/specification in the norm. The norm comes from the Khronos group that has public forums but that did not seem to listen to this community. If you have free time, advocating here to better specify the binary interface would be very welcome. I do not have enough free time to do it myself (I can provide arguments and examples if someone want to do it) > Sorry for mixing things up here. If I install python-pyopencl apt > by installs amd-libopencl1. nvidia-libopencl1 was installed in my > build process to satisfy the dependencies of libavutil152. nvidia-libopencl1 is an old OpenCL ICD Loader implementation, only supporting OpenCL ICD implementing the 1.1 OpenCL version. Unless you really want to test/develop with all the NVidia OpenCL stack (and so be blocked at OpenCL 1.1), you should not use it. ocl-icd-libopencl1 and amd-libopencl1 are two replacements that must work. In particular, both of them are able to load and run the OpenCL ICD from NVidia (nvidia-opencl-icd). So, I would suggest to either depends on the virtual package (libopencl1) or on the free implementation (ocl-icd-libopencl1). But, here again, there is an issue in the norm: ocl-icd-libopencl1 and amd-libopencl1 can both use the NVidia ICD (nvidia-opencl-icd with a NVidia OpenCL implementation of OpenCL 1.1). However, there is no way for them to know that the NVidia ICD only support OpenCL 1.1. It means that, if you use OpenCL 1.2 functions in your program and your program select the NVidia ICD at run time, you will have errors (probably segfault as random values will be interpreted as function pointers). Here again, the good fix would be to push a better interface in the norm. It has not be done when OpenCL 2.0 arrives a few months ago :-( >>> But before you attempt this, I think you should coordinate with the >>> other packages currently providing these libraries and standardize >>> the symbol names. >> >> This is not possible unless you are able to modify the binaries >> provided by AMD, NVidia (and even Intel that, in its libopencl1.so >> library doe no even use the correct SONAME...) >>In any case, this is out the scope of the power of Debian Developer >> (AMD and NVidia are in non-free, not in main, Intel ones is not >> even in non-free due to an error in there licencing file. They promise >> me to correct this on a forum but I did not see any fact until now...) > > But the Debian Developer can ensure that nvidia-libopencl1 does not > provide libopencl1 as long as it doesn't work well together with the rest. libopencl1 means that this package provide a share library with the libopencl1. Please, look (again) at http://anonscm.debian.org/gitweb/?p=collab-maint/ocl-icd.git;a=blob;f=debian/README.Debian;hb=HEAD in particular line 245 and following. It explains the role of all introduced virtual packages (I just see that I did not updated the name of all of them after the last discussion, ie for example libopencl-1.2-1 is still cited as libopencl1.2, but the reason is still correctly explained) Note that nvidia-libopencl1 does not provide libopencl-1.2-1 as it does not have support for 1.2 OpenCL functions. >>> ocl-icd-libopencl1 uses @OPENCL_*, while e.g. nvidia-libopencl1 uses >>> @BASE, so if a program is compiled with ocl-icd-opencl-dev and used >>> with nvidia-libopencl1 (which apt installs by default with the current >>> broken symbols file), it will produce errors like: >>> undefined reference to `clReleaseMemObject@OPENCL_1.0' >> >> Are you sure? When I test it a few months (years) ago, there was >> only a warning. Look at line 310 and following at >> http://anonscm.debian.org/gitweb/?p=collab-maint/ocl-icd.git;a=blob;f=debian/README.Debian;hb=HEAD >> Perhaps the linker behavior changed since this time. > > Yes, I'm sure that I see this error. > When FFmpeg is compiled with ocl-icd-opencl-dev and then e.g. amarok is > compiled while nvidia-libopencl1 is installed instead of ocl-icd-libopencl1, > it results in: > [ 71%] Building CXX object > src/core-impl/collections/ipodcollection/CMakeFiles/amarok_collection-ipodcollection.dir/IpodCollectionFactory.o > cd src/core-impl/collections/ipodcollection && /usr/bin/c++ > -DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=11 -DKDE_DEPRECATED_WARNINGS > -DMAKE_AMAROK_COLLECTION_IPODCOLLECTION_LIB -DQT_CORE_LIB -DQT_DBUS_LIB > -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_STL > -DQT_STRICT_ITERATORS -DQT_SVG_LIB -DQT_USE_FAST_CONCATENATION > -DQT_USE_FAST_OPERATOR_PLUS -DQT_XML_LIB -D_BSD_SOURCE -D_REENTRANT > -D_XOPEN_SOURCE=500 -g -O2 -fstack-protector --param=ssp-buffer-s
Bug#743708: [Pkg-libvirt-maintainers] Bug#743708: libvirt-bin: AppArmor profile template installed in the wrong place
Guido Günther wrote (05 Apr 2014 13:41:13 GMT) : > Thanks for checking out apparmor support but please don't file > individual bugs until we have apparmor support "officialy" enabled. > Adding your findings to 725144 is very much appreciated though. OK, I'll do that next time. Thanks for the guidance :) 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#743701: libva1=1.3.0-1 with i965 makes all video "solid black" with mpv --hwdec=vaapi
Control: tags -1 = moreinfo On 2014-04-05 04:33:22, Kevin Mitchell wrote: > Package: i965-va-driver > Version: 1.2.2-2 > Severity: normal > > With the 1.3.0-1 version currently in unstable and i965-va-driver=1.2.2-2 on > ivy bridge chip, > > $ mpv vc1.mkv --no-config --no-resume-playback --hwdec=vaapi --vo=opengl > > results in a solid black screen while the sound works. The vc1.mkv > clip can be found at [1]. I found this happens with every hardware > decodable clip I tried including h264 clips. The vc1 clip however > neatly demonstrates that the problem is specifically with hardware > decoding as seeking with left and right keys leads to (unrelated) decoding > errors > and a fallback to software decoding, at which point the video > reappears! I've just uploaded intel-vaapi-driver 1.3.0-1. It should appear on a mirror near you in the next couple of hours. Could you please check if the problem persists with the new version? Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#743532: lintian: when to say: old-fsf-address-in-copyright-file
Hi, On Thu, Apr 03, 2014 at 06:45:25PM +0200, Jakub Wilk wrote: > * Osamu Aoki , 2014-04-04, 01:16: > >License: GPL-2.0+ with incorrect FSF address, and with autoconf exception > > FWIW, this line does not conform to the copyright format specification. What is the offending part? "GPL-2.0+" or "with ..."? "GPL-2+" and the SPDX style "GPL-2.0+" are equivalent as specified as "For SPDX compatibility, versions with trailing dot-zeroes are considered to be equivalent to versions without (e.g., "2.0.0" is considered equal to "2.0" and "2").". As for "with ..." part, I am following "An exception or clarification to a license is signalled in plain text, by appending with keywords exception to the short name." I wish to fix problem here. Please let me know the solution. (As I re-read spec, I realize my MIT license marking needs to be fixed to use Expat if it is not X style.) > >For me copying "license" text including some associated disclaimer exactly > >from the original source seems to be the right thing to do. > > Indeed. But the main point of old-fsf-address-in-copyright-file is to let > you know about _upstream_ problem. Then please use "I: instead of "W:". Warning seems excessive when the maintainer is aware and tracking its status by marking it in here. > >FYI: This debian/copyright is autogenerated here using debmake packaging > >helper script. > > If the copyright file was automatically generated, then there's even greater > change that you didn't notice the problem yourself. To be clear, only a template of debian/copyright is autogenerated to save time for maintainer checking the same license text in different files word-by-word. Maintainer needs to give final touch which I made it clear in its documentation. Most of these trouble comes from autotools. That is why almost no one bothered to list such problematic files in this debian/copyright and they evade annoying warnings by treating such files as a part of *. I was surprised to see so many autotools derived files had this problem. By documenting all files properly with the help of program and marking their problems obvious, next automatic license check run of the source tree may find it has been fixed upstream too. Then he can update debian/copyright. (Right now debmake only creates the template file only. It can not verify existing debian/copyright against updated source tree yet.) Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743713: x264: FTBFS on sparc: cc1: error: unrecognized command line option '-fno-aggressive-loop-optimizations'
Source: x264 Version: 2:0.142.2389+git956c8d8-3 Severity: important See the build log at https://buildd.debian.org/status/fetch.php?pkg=x264&arch=sparc&ver=2%3A0.142.2389%2Bgit956c8d8-3&stamp=1396707861 Looks like that option is not recognized by gcc 4.6. Cheers, Julien signature.asc Description: Digital signature
Bug#681884: [buildd-tools-devel] Bug#681884: Same problem with schroot 1.6.8-1
On Sat, Apr 05, 2014 at 09:25:33PM +1100, Erik de Castro Lopo wrote: > Erik de Castro Lopo wrote: > > > Can anyone figure out from what we know so far if this is an schroot > > but or a systemd bug? > > > > If someone can give me a gentle nudge in the right direction I'm willing > > to invest some time on this because I really do need this bug fixed. > > Now I can't even re-produce this bug. > > I'm still using schroot 1.6.8-1 with systemd 204-8 but upgrading something > else (no clue what) seems to have fixed. > > I have schroot working properly again. I'm very happy. If no one else can > re-produce this then the bug should be closed. There's definitely a bug here, in fact two bugs: - systemd shouldn't be breaking things by altering defaults that have worked for over a decade, thereby breaking every user of mount --bind. This is utterly wrong. mount --bind is in widespread use and, like it or not, there are thousands of programs and scripts that, unwittingly or not, depend upon the existing kernel default. - schroot should be able to cope with the default being changed; there's a patch to do this; it just needs updating to work on non-Linux systems and I'll apply it. The bits of the existing patch just need wrapping in "if(Linux)" conditionals. I'll fix this in schroot of course, as I have for many minor portability issues over the years. I do have some rather bad things to say about systemd's attitudes here, but I'll refrain from it here. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743483: apache2-mpm-itk: AssignUserID is ignored in favor of file ownership.
Steinar, could you please comment on that? I have no experience with itk whatsoever. Therefore, I do not how if this is a problem in itk or a configuration issue. Moreover, please reasign this bug to the itk source package, if this is a still persisting problem. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#731074: [pkg-lighttpd] Bug#731074: Bug#731074: lighttpd: indeterminate test on kfreebsd buildds
Hi, On 02.04.2014 02:13, Michael Gilbert wrote: > Didn't get a message that I was accepted ;) Will do. That's a "feature" of FusionForge. While you're at it, please do also include the security NMUs you did in Stable. Thanks! -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#743703: r-base: FTBFS on armhf
On 5 April 2014 at 15:39, Ivo De Decker wrote: | Hi Dirk, | | On Sat, Apr 05, 2014 at 08:11:03AM -0500, Dirk Eddelbuettel wrote: | > That's a gcc error. | > | > I changed how to set CFLAGS etc by calling dpkg-buildflags so I am pretty | > much playing by the book. What do you suggest I do? Take out -O2 or -g on | > armhf? | | It's probably a good idea to submit a bug report against gcc, and to notify | the arm* porters, to make sure the gcc issue is investigated. Can you take care of that, please? | In the mean time, however, the missing build on armhf will block migration to | testing, so if you can fix the build by changing the CFLAGS, that's probably | best for now. I had hope that using dpkg-buildflags would circumvent the need for these dance, but apparently not. I start by arch:= $(shell dpkg-architecture -qDEB_BUILD_GNU_CPU) buildarch := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) ## edd 26 Jul 2013 also use DEB_HOST_ARCH_OS to catch kFreeBSD buildos := $(shell dpkg-architecture -qDEB_HOST_ARCH_OS) [...] optimflags = $(shell dpkg-buildflags --get CFLAGS) and I still have all these special cases from way back when ## lam...@debian.org 06 Dec 2001 hppa needs -ffunction-sections ifeq ($(arch),hppa) optimflags = -O2 -ffunction-sections endif ## edd 20 Jun 2002 no optimisation or debugging on baby systems ## edd 02 Jun 2003 use this on arm only ## edd 12 May 2010 no longer use it on arm either -- thx Modestas ## edd 04 Aug 2010 on mips and mipsel, don't use -g ##ifneq "$(findstring $(arch), m68k arm)" "" #ifneq "$(findstring $(arch), arm)" "" ifneq "$(findstring $(arch), mips mipsel)" "" optimflags = -g0 #optimflags = -O0 -g0 endif ## edd 04 Apr 2009 Alpha dies on deriv.c, trying will less optimisation ## edd 16 Apr 2009 commented-out as Kurt Roeckx applied a gcc patch #ifeq ($(arch),alpha) #optimflags = -O2 -g0 #endif ## edd 09 Apr 2006 per patch from Andreas Jochens in #361604 ifeq ($(arch),powerpc64) optimflags += -mminimal-toc endif ## edd 26 Jul 2013 kFreeBSD wants -O2 per #714506 ifeq ($(buildos),kfreebsd) optimflags = -O2 -pipe endif Currently none for arm / armhf. Do you suggest setting armhf only? And to what? No debug? No optim? Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742149: mapnik: FTBFS on mipsen (virtual memory exhausted)
> On 03/19/2014 09:28 PM, Aurelien Jarno wrote: > > On Wed, Mar 19, 2014 at 09:18:20PM +0100, Sebastiaan Couwenberg wrote: > I'm not sure what the best course of action is. But Jérémy suggested > backporting a change from upstream, I'll give that a go tomorrow: > > https://github.com/mapnik/mapnik/pull/2134 I've backported that patch and it seems it saves some memory. Also i discovered hundreds of megabytes of memory usage can be saved by disabling debugging symbols (-g0). (Not uploading the fix yet because i'd like scons to not build twice, once at build, once again at install target.) Jérémy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743714: O: guile-gnome-platform -- Guile bindings for GLib
Package: wnpp Severity: normal The current maintainer of guile-gnome-platform, Andreas Rottmann , has orphaned this package. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see http://www.debian.org/devel/wnpp/index.html#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: guile-gnome-platform Binary: guile-gnome2-glib, guile-gnome2-gconf, guile-gnome2-gtk, guile-gnome2-gnome, guile-gnome2-gnome-ui, guile-gnome2-canvas, guile-gnome2-vfs, guile-gnome2-dev Version: 2.16.1-6.1 Maintainer: Andreas Rottmann Build-Depends: cdbs (>= 0.4.49), debhelper (>> 5), automake1.10, libtool, xvfb, xauth, xfonts-base, stx2any, guile-1.8-dev, guile-library (>= 0.1.6), g-wrap (>= 1.9.13-2), guile-g-wrap (>= 1.9.13-2), libgwrap-runtime-dev (>= 1.9.11), guile-cairo-dev (>= 1.4.0), libglib2.0-dev (>= 2.12.13), libgtk2.0-dev (>= 2.10.13), libgconf2-dev (>= 2.18.0), libglade2-dev (>= 1:2.6.2), libgnomevfs2-dev (>= 2.18.1), libgnome2-dev (>= 2.18.0), libgnomeui-dev (>= 2.18.1) Architecture: any Standards-Version: 3.9.2 Format: 3.0 (quilt) Files: 241f4764ada1f0914da25196848dbca5 2000 guile-gnome-platform_2.16.1-6.1.dsc fde233c17863b7dfbe6937e4b5c00669 3494333 guile-gnome-platform_2.16.1.orig.tar.gz 92878eff923f5e46ef9ddb1c0f529fee 8093 guile-gnome-platform_2.16.1-6.1.debian.tar.gz Checksums-Sha1: 0debc84b33c9b7eba11839fa3a9cc656586faf53 2000 guile-gnome-platform_2.16.1-6.1.dsc 3cf7cc8de6f261e6cf48d34e691706fe4b7f1061 3494333 guile-gnome-platform_2.16.1.orig.tar.gz 645c0275f5354b1f3faa7fc363fbb3eac913dee4 8093 guile-gnome-platform_2.16.1-6.1.debian.tar.gz Checksums-Sha256: b03637e0313d175faa191ec9e56e306f95ef312983d2714f27ff563d49a605f0 2000 guile-gnome-platform_2.16.1-6.1.dsc 4c0856d3a8310af5959fb123f3a011fc6bc1ec1cf0f125629f8a4a741871c57b 3494333 guile-gnome-platform_2.16.1.orig.tar.gz 396e0742107693083b59f610d94ecbfb27e633ae21f53228dd5ca66e3a5a2aad 8093 guile-gnome-platform_2.16.1-6.1.debian.tar.gz Homepage: http://www.gnu.org/software/guile-gnome/ Package-List: guile-gnome2-canvas deb lisp extra guile-gnome2-dev deb libdevel extra guile-gnome2-gconf deb lisp extra guile-gnome2-glib deb lisp extra guile-gnome2-gnome deb lisp extra guile-gnome2-gnome-ui deb lisp extra guile-gnome2-gtk deb lisp extra guile-gnome2-vfs deb lisp extra Directory: pool/main/g/guile-gnome-platform Priority: source Section: lisp Package: guile-gnome-platform Binary: guile-gnome2-glib, guile-gnome2-gconf, guile-gnome2-gtk, guile-gnome2-gnome, guile-gnome2-gnome-ui, guile-gnome2-canvas, guile-gnome2-vfs, guile-gnome2-dev Version: 2.16.2-1.1 Maintainer: Andreas Rottmann Build-Depends: cdbs (>= 0.4.49), debhelper (>> 7), automake, libtool, xvfb, xauth, xfonts-base, stx2any, guile-1.8-dev, guile-library (>= 0.1.6), g-wrap (>= 1.9.14-1), guile-g-wrap (>= 1.9.14-1), libgwrap-runtime-dev (>= 1.9.11), guile-cairo-dev (>= 1.4.0), libglib2.0-dev (>= 2.12.13), libgtk2.0-dev (>= 2.10.13), libgconf2-dev (>= 2.18.0), libglade2-dev (>= 1:2.6.2), libgnomevfs2-dev (>= 2.18.1), libgnome2-dev (>= 2.18.0), libgnomeui-dev (>= 2.18.1) Architecture: any Standards-Version: 3.9.3 Format: 3.0 (quilt) Files: c603d9ec2985572f9b193067e67460b9 2619 guile-gnome-platform_2.16.2-1.1.dsc eb4a084d13785efaa1639145907a87b4 2538191 guile-gnome-platform_2.16.2.orig.tar.gz 02b6b95c8d775568ff04435e07f0f4e8 8716 guile-gnome-platform_2.16.2-1.1.debian.tar.xz Checksums-Sha1: 43b39ca1ecb10b8783e1a4939ffa20d3aca541eb 2619 guile-gnome-platform_2.16.2-1.1.dsc a53d9a2a82ae83b07d6b47bfbfb7f7005cdfc4b3 2538191 guile-gnome-platform_2.16.2.orig.tar.gz cc7911c382c1d4d4adc1b34b1bc89ee04ba5a4e2 8716 guile-gnome-platform_2.16.2-1.1.debian.tar.xz Checksums-Sha256: 1c99d3d17b4de259934290e7c9264ed17b1322b00e49af0b60b3e1a769432162 2619 guile-gnome-platform_2.16.2-1.1.dsc 50e6cd95c4a32f44498816c607c071b7d7368c49a34daebf598d9129df344fb0 2538191 guile-gnome-platform_2.16.2.orig.tar.gz afc6a4895a5f82ef614c02df840c1fe3cc27ff99d0dc2965a8a21cedf5c3c7e6 8716 guile-gnome-platform_2.16.2-1.1.debian.tar.xz Homepage: http://www.gnu.org/software/guile-gnome/ Package-List: guile-gnome2-canvas deb lisp extra guile-gnome2-dev deb libdevel extra guile-gnome2-gconf deb lisp extra guile-gnome2-glib deb lisp extra guile-gnome2-gnome deb lisp extra guile-gnome2-gnome-ui deb lisp extra guile-gnome2-gtk deb lisp extra guile-gnome2-vfs deb lisp extra Directory: pool/main/g/guile-gnome-platform Priority: source Section: lisp Package: guile-gnome2-glib Source: guile-gnome-platform Version: 2.16.2-1.1 Installed-Size: 344 Maintainer: Andreas Rottmann Architecture: armel Depends: guile-g-wrap (>= 1.9.9), guile-1.8-libs, libc6 (>= 2.4), libffi6 (>= 3.0.4), libglib2.0-0 (>= 2.35.9), libgmp10, libgwrap-runtime2 (>= 1.9.14), libltdl7 (>= 2.4.2) Description-en: Guile bindings for
Bug#743584: trafficserver 4.1.2-1.1 FTBFS on kfreebsd-*
On 05.04.2014 04:06, Aníbal Monsalve Salazar wrote: > Please let trafficserver 4.1.2-1.2 migrate to testing. It's the result > of the efforts of Petr, Dejan, myself and some other people who looked > into the bugs fixed by the NMUs. Sure thing. The MIPS patch is supposed to be included in ATS 5.0, but the kfreebsd patch is probably a Debian specific issue. That being said, I can also commit it upstream if you'd like. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#743703: r-base: FTBFS on armhf
Hi Dirk, On Sat, Apr 05, 2014 at 09:50:47AM -0500, Dirk Eddelbuettel wrote: > | It's probably a good idea to submit a bug report against gcc, and to notify > | the arm* porters, to make sure the gcc issue is investigated. > > Can you take care of that, please? It seems there are other packages failing with similar errors, so there might be buildd issues. I'm trying on the armhf porterboxes now. Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743338: [pkg-lighttpd] Bug#743338: lighttpd: "Broken" migration to /var/www/html
Hi, On 01.04.2014 23:24, Nelson A. de Oliveira wrote: > I see two problems here: it broke my server without any message (there > isn't a message in NEWS, for example) and the placeholder page gives a > wrong path too: Good idea. I'll add a NEWS file warning users about this and fix the documentation bug. > I am also thinking if it should automatically change/update my > /etc/lighttpd/lighttpd.conf file to include the new path (like happened) > or if it should only use /var/www/html on new installs. As you should be aware as a DD, I am not allowed to touch conffiles. It will be updated accordingly if you did not modify the default configuration but apart there is not much I can do. I am not sure how the upgrade broke anything for you though. Apparently you had modified the lighttpd.conf so that it wasn't upgraded. Thus, it further continues to use whatever doc root you configured, and our default doc root contains nothing but the sample index.html file you're supposed to replace if you really want to use the default. Would you mind telling me more about your setup? Please note, that the default document root is not really meant to be used by end users anyway. It's rather supposed to be the host of "last resort" when no other (virtual) host matches. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#743687: dpkg: dpkg-deb creates tar files with -T and without --no-unquote
Hi! On Sat, 2014-04-05 at 11:12:55 +0200, Niels Thykier wrote: > Package: dpkg > Version: 1.17.6 > Severity: minor > dpkg-deb creates the tarfiles inside a .deb using tar -T without using > --no-unquote. This can cause issues when a filename contains one or > more "\"-characters, as tar will strip one level of blackslahes (due > to --unqoute being the default). > > Thus a file named \\ will be renamed to \ in the process (and > e.g. "\a" becomes "a"[1]). If this causes two files to have the same > name, tar will consider of them a hardlink of other (discarding its > content, as it is assumed to be the same as the other one). > > I have filed this as "minor", since (to my knowledge) the only > packages containing files affected by this are found solely in the > Lintian test suite[2]. Nice catch, thanks, fixed in my local tree and will be included in my next push targetting 1.17.7, which should hopefully happen *this* weekend, if the final testing and re-reviews look good. Regards, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743703: r-base: FTBFS on armhf
On 5 April 2014 at 17:01, Ivo De Decker wrote: | Hi Dirk, | | On Sat, Apr 05, 2014 at 09:50:47AM -0500, Dirk Eddelbuettel wrote: | > | It's probably a good idea to submit a bug report against gcc, and to notify | > | the arm* porters, to make sure the gcc issue is investigated. | > | > Can you take care of that, please? | | It seems there are other packages failing with similar errors, so there might | be buildd issues. I'm trying on the armhf porterboxes now. That rhymes with my glance at my debian/rules. Before calling dpkg-buildflags, the base default was '-O3 -pipe' everywhere, including arm / armhf so if anything we should be less taxing now. Keep me posted! Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664630: PC/SC-software and card reader REINER-SCT Cyberjack RFID komfort
Control: retitle -1 moneyplex application does not work with the pcscd 1.8 Control: reassign -1 pcscd On Wed, Mar 28, 2012 at 01:07:45PM +0200, Frank Neuber wrote: > Hi, > and sorry for my late answer. I had some Dolomiti Superski in the last > days ;-) > > I installed a fresh Wheezy in a Virtual Box with the SP02 driver from > the debian repository. > I can see the ATR like you ... > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664630#50 > > So the cardreader is working. > > The problem is that the current moneyplex application does not work with > the pcscd 1.8. But there is a beta version of moneyplex available. You > can ask the moneyplex suppport to be a beta tester like me :-) This beta > version is available in 64 and 32 bit (the old version was only 32 bit) > and is working well with pcscd 1.8. I'm doing some cleanup on the open bugs of the pcsc-cyberjack package. Based on the information above, it seems to me that this problem is rather in pcscd, so I'm reassigning this bug appropriately. However, given that it was filed in 2012, and no futher updates have been made, I wonder if this is still a problem and some recent update of pcsc-lite fixed it. I'm no longer using smartcards for online-banking, so I cannot test anymore. Sorry 'bout that. Reinhard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743715: RFS: django-remote-forms/0.0.1~pre+g16ec596-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "django-remote-forms" * Package name: django-remote-forms Version : 0.0.1~pre+g16ec596-1 Upstream Author : WiserTogether Tech Team * URL : https://github.com/WiserTogether/django-remote-forms.git * License : MIT Section : python It builds those binary packages: python-django-remote-forms - Platform independent form serializer for Django To access further information about this package, please visit the following URL: http://mentors.debian.net/package/django-remote-forms Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/d/django-remote-forms/django-remote-forms_0.0.1~pre+g16ec596-1.dsc The uploaded package is UNRELEASED. Changes since the last upload: * moved in unstable distribution Regards, Marco Bardelli -- GPG key: 4096R/0xF7FE4DAA 2013-08-02 Marco Bardelli -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743716: xboard: analysis mode is broken when xboard is upgraded from 4.6.2-1 to 4.7.3-1
Package: xboard Version: 4.7.3-1 Severity: normal Dear Maintainer, In the old version 4.6.2-1, when I do rajulocal@hogwarts:~/chess$ xboard -fcp crafty KamarajuKusumanchi_vs_paconov_2014_04_02.pgn the game will start playing automatically. It can be stopped and moved to the beginning of the game by clicking on the "<<" button at the top right. Now if I press ctrl-A, the analyis mode will start and the analyzed moves will appear in a separate window. The analysis mode can also by started by Mode -> Analysis Mode. Once the Analysis Mode starts, I can step through the program by pressing ">" button at the top right. In the new version 4.7.3-1, this behaviour is broken. After loading the game, clicking on the "<<" button, if I press ctrl-A, nothing happens. The Analysis Mode under Mode menu is greyed out and not clickable. In both the cases above, I have crafty 23.4-6 installed. rajulocal@hogwarts:~/chess$ dpkg -l crafty ii crafty 23.4-6 amd64state-of-the-art chess engine, compatible with xboard rajulocal@hogwarts:~/chess$ uname -a Linux hogwarts 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux My machine is a mixture of stable (Wheezy) and testing (Jessie). rajulocal@hogwarts:~/chess$ cat KamarajuKusumanchi_vs_paconov_2014_04_02.pgn [Event "Live Chess"] [Site "Chess.com"] [Date "2014.04.02"] [White "KamarajuKusumanchi"] [Black "paconov"] [Result "0-1"] [WhiteElo "977"] [BlackElo "1086"] [TimeControl "10|0"] [Termination "paconov won by resignation"] 1.e4 b6 2.d4 Bb7 3.Nc3 e6 4.Nf3 Nc6 5.d5 exd5 6.exd5 Qe7+ 7.Be3 Nb4 8.a3 Na6 9.Bxa6 Bxa6 10.Qd4 O-O-O 11.O-O-O c5 12.Qa4 Kb7 13.Rhe1 Nf6 14.Bg5 Qd6 15.Ne4 Nxe4 16.Bxd8 Qf4+ 17.Kb1 Nc3+ 0-1 Please let me know if you need any further information. -- Kamaraju S. Kusumanchi http://malayamaarutham.blogspot.com/ -- System Information: Debian Release: 7.4 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xboard depends on: ii libc6 2.18-4 ii libcairo2 1.12.2-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-5 ii libice6 2:1.0.8-2 ii librsvg2-2 2.36.1-2 ii libsm6 2:1.2.1-2 ii libx11-62:1.6.2-1 ii libxaw7 2:1.0.10-2 ii libxmu6 2:1.1.1-1 ii libxpm4 1:3.5.10-1 ii libxt6 1:1.1.3-1+deb7u1 Versions of packages xboard recommends: ii fairymax 4.8q-2 ii xfonts-100dpi 1:1.0.3 ii xfonts-75dpi 1:1.0.3 Versions of packages xboard suggests: ii gnome-terminal [x-terminal-emulator] 3.4.1.1-2 ii xterm [x-terminal-emulator] 303-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743338: [pkg-lighttpd] Bug#743338: Bug#743338: lighttpd: "Broken" migration to /var/www/html
On Sat, Apr 5, 2014 at 5:06 PM, Arno Töll wrote: > As you should be aware as a DD, I am not allowed to touch conffiles. It I don't think he's asking us to. > will be updated accordingly if you did not modify the default > configuration but apart there is not much I can do. I am not sure how > the upgrade broke anything for you though. Apparently you had modified > the lighttpd.conf so that it wasn't upgraded. Thus, it further continues > to use whatever doc root you configured, and our default doc root > contains nothing but the sample index.html file you're supposed to > replace if you really want to use the default. Would you mind telling me > more about your setup? My guess is that he had documents in /var/www and had not modified lighttpd.conf. Hence after the update his files in /var/www were no longer being served. > > Please note, that the default document root is not really meant to be > used by end users anyway. It's rather supposed to be the host of "last > resort" when no other (virtual) host matches. Users *are* using /var/www, especially if they've only got a single (v)host. Olaf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743483: apache2-mpm-itk: AssignUserID is ignored in favor of file ownership.
On Sat, Apr 05, 2014 at 04:45:26PM +0200, Arno Töll wrote: > could you please comment on that? I have no experience with itk > whatsoever. Therefore, I do not how if this is a problem in itk or a > configuration issue. This is almost certainly a configuration issue. It sounds like he is hitting suexec or suphp. FWIW, mpm-itk setuid()s as soon as it has read the request and parsed the configuration to figure out what AssignUserID directive to obey, which is long before it could possibly know the owner of the file (or even if the file exists). /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743717: subunit: FTBFS on all arch
package: subunit version: 0.0.18-2 severity: serious Hi, The latest upload of subunit FTBFS on all arches. The upload was probably built in an unclean or outdated environment. https://buildd.debian.org/status/package.php?p=subunit&suite=sid Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743718: gcc-4.8: FTCBFS for powerpcspe during patch application
Package: gcc-4.8
Version: 4.8.2-19
Severity: normal
Tags: patch
Hi doko,
I got a FTCBFS for powerpcspe:
Applying patch powerpc_remove_many.diff
patching file src/gcc/config/rs6000/rs6000.h
Hunk #1 succeeded at 101 (offset 3 lines).
Hunk #2 FAILED at 176.
1 out of 2 hunks FAILED -- rejects in file src/gcc/config/rs6000/rs6000.h
Patch powerpc_remove_many.diff does not apply (enforce with -f)
make: *** [stamps/02-patch-stamp] Error 1
dpkg-buildpackage: error: debian/rules control gave error exit status 2
This is a regression introduced between 4.8.2-18 and 4.8.2-19.
The patch context changed. The attached debdiff fixes the patch context.
Helmut
diff -u gcc-4.8-4.8.2/debian/changelog gcc-4.8-4.8.2/debian/changelog
--- gcc-4.8-4.8.2/debian/changelog
+++ gcc-4.8-4.8.2/debian/changelog
@@ -1,3 +1,11 @@
+gcc-4.8 (4.8.2-19.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Adapt context of powerpc_remove_many.diff to fix FTCBFS for powerpcspe.
+Closes: #-1.
+
+ -- Helmut Grohne Sat, 05 Apr 2014 17:30:17 +0200
+
gcc-4.8 (4.8.2-19) unstable; urgency=medium
* Update to SVN 20140404 (r209122) from the gcc-4_8-branch.
diff -u gcc-4.8-4.8.2/debian/patches/powerpc_remove_many.diff
gcc-4.8-4.8.2/debian/patches/powerpc_remove_many.diff
--- gcc-4.8-4.8.2/debian/patches/powerpc_remove_many.diff
+++ gcc-4.8-4.8.2/debian/patches/powerpc_remove_many.diff
@@ -20,9 +20,9 @@
handling -mcpu=xxx switches. There is a parallel list in driver-rs6000.c
to
provide the default assembler options if the user uses -mcpu=native, so if
@@ -170,7 +176,8 @@
- %{mcpu=e500mc64: -me500mc64} \
%{maltivec: -maltivec} \
%{mvsx: -mvsx %{!maltivec: -maltivec} %{!mcpu*: %(asm_cpu_power7)}} \
+ %{mpower8-vector|mcrypto|mdirect-move|mhtm: %{!mcpu*: %(asm_cpu_power8)}} \
--many"
+" \
+ASM_CPU_SPU_MANY_NOT_SPE
Bug#740043: RFS: powerline/0~20140216-1 [ITP]
Hi Jerome, On 2014-02-25 06:36, Jerome Charaoui wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "powerline" > > * Package name: powerline >Version : 0~20140216-1 >Upstream Author : Kim Silkebækken > * URL : https://github.com/Lokaltog/powerline > * License : Expat >Section : python > > It builds those binary packages: > > fonts-powerline - ultimate statusline/prompt utility (font) > powerline - ultimate statusline/prompt utility > python-powerline - ultimate statusline/prompt utility (library) > python-powerline-doc - ultimate statusline/prompt utility (documentation) > > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/powerline > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/p/powerline/powerline_0~20140216-1.dsc I'm not a DD so I can't sponsor your package. I was hoping to contribute with a review, but I couldn't find any flaw in your packaging. A nice-to-have though would be Vcs-* URLs in debian/control to simplify contributing to your packaging, if you're using a VCS. You can also use Debian's infrastructure, see: https://wiki.debian.org/Alioth/PackagingProject Regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
