Bug#732141: RFP: zint -- Zint barcode studio - utilities and library for barcoding
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org Package name: zint Version: 2.4.3 Upstream Author: Robin Stuart ro...@zint.org.uk URL: http://sourceforge.net/projects/zint/ License: GPL-2+, BSD-2-clause Description: Zint barcode studio - utilities and library for barcoding Zint is a barcode encoding and image generating library. It currently features support for over 50 symbologies including Australian Post 4-state codes (redirect, reply-paid, routing, standard customer), Aztec Code (ISO 24778), Aztec Runes, Channel code, Codabar, Code 11, Code 128 (ISO 15417), Code 16k, Code 2 of 5 (Data Logic, IATA, Industrial, Interleaved, Matrix), Code 32 (Italian Pharmacode), Code 39 (ISO 16388), Code 39 Extended, Code 49, Code 93, Code One, Databar (Expanded, Expanded Stacked, Limited, Stacked Omnidirectional), Data Matrix (ISO 16022), Deutsche Post (Identicode, Leitcode), Dutch Post KIX, EAN-14, European Article Number (EAN), Facing Identification Mark (FIM), Flattermarken, Grid Matrix, ITF-14, Internation Standard Book Number (ISBN), Japanese Postal Barcode, Korean Postal Barcode, LOGMARS, Maxicode (ISO 16023), MicroPDF417 (ISO 24728), Micro QR Code, MSI Plessey, NVE-18, PDF417 (ISO 15438), Pharmacode (2-track, Zentralnummer (PZN)), PLANET, Postnet, QR Code (ISO 18004), Royal Mail 4-state Barcode, Telepen, Telepen Numeric, UK Plessey, Universal Product Code (UPC-A, UPC-E), USPS Intelligent Mail as well as HIBC. . Also included are Unicode translation for symbologies which support Latin-1 and Kanji character sets, full GS1 data support including verification and automated insertion of FNC1 characters and support for encoding binary data including NULL (ASCII 0) characters. Zint encode input data in a barcode and save as a PNG, EPS or SVG file. Packaging is practically completed and available from http://anonscm.debian.org/gitweb/?p=collab-maint/zint.git Source package produces the following binary packages: * zintcommand line utility to encode data in barcode symbols * zint-qt Zint Barcode Studio, a QT frontend to zint * libzint2.4 library for encoding data in barcode symbols * libzint-dev Zint development files * zint-dbgZint -- debugging symbols -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#732142: transcode: FTBFS with freetype 2.5.1
Source: transcode Version: 3:1.1.7-6 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: sid jessie transcode fails to build against the current version of freetype: | /bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -D_REENTRANT -I../.. -I../../src -I/usr/include/freetype2 -I/usr/include -D_FORTIFY_SOURCE=2 -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -c -o load_ppml_file.lo load_ppml_file.c | load_font.c:51:30: fatal error: freetype/ftglyph.h: No such file or directory | #include freetype/ftglyph.h | ^ | compilation terminated. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#732117: mount: loop mounting fails with LOOP_SET_FD failed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/14/2013 05:52 AM, ael wrote:
# losetup -f /dev/loop0
# export f=1; mount -v -o loop=/dev/loop0
debian-testing-source-DVD-${f}old.iso /loopmnt1 mount: enabling
autoclear loopdev flag mount: going to use the loop device
/dev/loop0 mount: you didn't specify a filesystem type for
/dev/loop0 I will try type iso9660 mount: block device
/large/jigdo_area/debian-testing-source-DVD-1old.iso is
write-protected, mounting read-only mount: enabling autoclear
loopdev flag mount: going to use the loop device /dev/loop0
warning: /large/jigdo_area/debian-testing-source-DVD-1old.iso is
already associated with /dev/loop0 ioctl LOOP_SET_FD failed: Device
or resource busy mount: stolen loop=/dev/loop0
# losetup -f /dev/loop0
Can you run mount under strace?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCgAGBQJSrJNtAAoJEI5FoCIzSKrwD/oH/31WigofE6hczTVcbmErr+KY
gak1J4lLxqa50YpCjAc/MgFeyYPgd3wj2hLXkHh3fUM9WxDfpkC7AJwOyLalldT7
xVZUvRl+sbSpX4hc4ZpWYOS0KRJ4SCLVx9uEfXbZpGYknzw65CQqAdi1Dgm2g2nN
M6I6AUEXfWSkInHg4Gy+yhAAf+H3yXIhTehXv56GpmIHhfmDd9EGiKXIlYmJzzxW
WMnT+bmpdzJWw2ClGIoZoDkmRVDzai7acIQ+GHNeYxLayHM5CBV/URYK719uxDYg
Skm+r7CWKnJGUBM2qnLMnBzXRsVbiziqoi3Ib+MIPn7e33V1OlQhT7O+QwEegdI=
=Nhn0
-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#239816: libparted Atari partition table support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/14/2013 06:12 PM, Phillip Susi wrote: On 12/14/2013 02:26 AM, Thorsten Glaser wrote: The ST, maybe (except for the only-in-museums part), but the TT and Falcon run Debian GNU/Linux just finely. Linux ara5.mirbsd.org 3.11-2-m68k #1 Debian 3.11.7-1 (2013-11-09) m68k GNU/Linux (Hm, should dist-upgrade and reboot that box, too.) I'm still not following. You are talking about a 30 year old computer running at like 16 MHz with maybe 512k of ram? No, rather a Motorola 68060 running at 100 MHz with 512 MB of RAM [1]. Adrian [1] http://www.powerphenix.com/ct60/english/overview.htm - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSrJSkAAoJEHQmOzf1tfkTwqMQAL66NzlsEWG3zmXA8C+1FpH4 OzgnyCT9hQzt+sx81a1dODJmJZRS+Rlwe5aG9gUSevuaCksitzzFM24JLOeB6fQg iW6RAYlhlOgjWjj3TR96ADu6TGNAW0D0JMvDfy5PYiDQqTHMBCM9OUWHa/KiWaIM yUTx0KoxyEPs3iK9q5O4qh1Q37LAgh8xYtpbRILil8ga3rOVg3Gucv6tZjNNFUls WuvENs+65IqrIvkCLOKKJNyydRmAfBmRcJ8spBPRxl+B1ARdvQSAcOyAJOcwtnYD FhvU9HCM/IwDgx538TiwAqhnpx/z5HGgUK7MyOlFJ00BL+62v61/joczkdzUl2sD kqqTSZVP05jO/f8GZmH8eJ9zy5JwcM1fg1VT+VygLzrBLNk7+RsiB6GdN9lNemHd 3MrHZjjpcFweAvog5UFxgErhK3/FAVtv8O1eQ6Fz1bajWm0uMYFtbUo9GZsROi+p B8uzoNwNSRnG2taBZfILtNuSQnkcLfrcJpT7DMpsCJrLYQmMJY+vixS725FevQ7s 1g+g7s0Jo4d91G2RzZujNXj5i+08XQpuoFajMZpsKUald1K0kzSXKNmdwov2YW05 yFLBFyBKEnrMT5VEP/+Ed+7pJgluGSMaX8odYJQWpSYxedeyJModgxWBLBNl21oN 65W87kyDGwqu8PUULBxS =q8fX -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#731914: lintian: arch-specific behavior for timestamps far in the future
* Russ Allbery r...@debian.org, 2013-12-13, 13:45: (i386) $ lintian --no-cfg libghc-quickcheck-instances-dev_0.3.4-1_amd64.deb E: libghc-quickcheck-instances-dev: tar-errors-from-data Archive octal value 33415462123 is out of time_t range; assuming two's complement E: libghc-quickcheck-instances-dev: tar-errors-from-data Archive octal value 33415462123 is out of time_t range; assuming two's complement E: libghc-quickcheck-instances-dev: package-contains-ancient-file usr/share/doc/libghc-quickcheck-instances-dev/changelog.gz 1950-12-22 (amd64) $ lintian --no-cfg libghc-quickcheck-instances-dev_0.3.4-1_amd64.deb E: libghc-quickcheck-instances-dev: tar-errors-from-data ./usr/share/doc/libghc-quickcheck-instances-dev/changelog.gz: time stamp 2087-01-28 00:29:07 is 2307798691.20417264 s in the future Just to be sure I understand, the problem that you're reporting is not so much that the tags are different (I don't think we can avoid that; tar either produces one error or a different error, depending on architecture), but that we diagnose package-contains-ancient-file on i386 systems, which isn't correct? That's the main problem. Or that the package wasn't auto-rejected? I think it would be should emit a more specific tag than tar-errors-from-data in such cases (say timestamp-does-not-fit-32-bit-time_t). Then we could talk ftp-masters to add it to their tag list. The problem from Lintian's perspective on i386 is that by the time we see the package, tar has already reinterpreted time_t as a signed value. So I'm not quite sure what to do about this. Lintian could refrain from emitting package-contains-ancient-file when it sees Archive octal value ... is out of time_t range; assuming two's complement error from tar, and emit timestamp-does-not-fit-32-bit-time_t only. I'm wondering if tar-errors-from-data should be an autoreject tag for ftp-master. Is there ever a case where we would want to accept Debian packages that produce tar errors when unpacked? If maintainer's clock was slightly off, then tar could transiently warn about timestamps from future. I don't think we want packages rejected just because of that. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721615: duplicate of Bug #719025
Control: merge 719025 721615 Hi, this bug has already been reported as bug #719025. The reason for this bug is a missing dependency: python3-gi-cairo Installing this dependency solves the problem. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699435: phantomjs: using convenience copies of code
severity serious 699435 thanks On Thu, Jan 31, 2013 at 01:53:14PM +0100, Jérémy Lal wrote: Package: phantomjs Version: 1.6.0-5 Severity: important Hi, phantomjs is bundled with qt4, breakpad, linenoise, gif-lib, mongoose web server, minified coffeescript (that could render this bug serious). Please see Debian policy 4.13 Convenience copies of code. i'll first try to get rid of qt4. It shouldn't enter a stable release as long as it's using a copy of QT. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732143: giflib: removal of libungif breaks rdeps
Source: giflib Version: 4.1.6-11 Severity: serious Control: block 717923 with -1 The removal of libungif symlinks breaks stuff. See e.g. https://buildd.debian.org/status/fetch.php?pkg=fbiarch=mipselver=2.07-10%2Bb1stamp=1386465229 Please either revert or coordinate with reverse deps. Cheers, Julien signature.asc Description: Digital signature
Bug#644032: evince: crash : cannot read opensource pdf
Hey Yellow, can you please provide the pdf file again since that link is now broken. Or can you still reproduce this bug with newer versions ? thanks Regards althaser
Bug#623488: Iceweasel already built with gstreamer support!
To enable H.264 in Debian Firefox 24/25 (Iceweasel) build you must install apt-get install gstreamer0.10-plugins-good gstreamer0.10-ffmpeg and enable gstream support in about:config media.gstreamer.enabled according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682917 -- Best regards! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732144: gnome-games: /user/games/sol crashes after security update
Package: gnome-games Version: 1:2.30.2-2 Severity: normal Probably due to a recent security update, /usr/bin/sol crashes with the following message: ERROR:window.c:2553:aisleriot_window_init: code should not be reached Abgebrochen No Problem with Wheezy. -- System Information: Debian Release: 6.0.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-games depends on: ii gnome-games-data 1:2.30.2-2data files for the GNOME games ii gnuchess 5.07-7Plays a game of chess, either agai ii guile-1.8-libs 1.8.7+1-3 Main Guile libraries ii libatk1.0-01.30.0-1 The ATK accessibility toolkit ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libcairo2 1.10.2-7~bpo60+1 The Cairo 2D vector graphics libra ii libcanberra-gtk0 0.24-1Gtk+ helper for playing widget eve ii libcanberra0 0.24-1a simple abstract interface for pl ii libclutter-1.0-0 1.2.12-3 Open GL based interactive canvas l ii libclutter-gtk-0.10-0 0.10.4-1 Open GL based interactive canvas l ii libgcc11:4.4.5-8 GCC support library ii libgconf2-42.28.1-6 GNOME configuration database syste ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgtk2.0-02.20.1-2 The GTK+ graphical user interface ii libice62:1.0.6-2 X11 Inter-Client Exchange library ii libpango1.0-0 1.28.3-1+squeeze2 Layout and rendering of internatio ii librsvg2-2 2.26.3-1+deb6u1 SAX-based renderer library for SVG ii librsvg2-common2.26.3-1+deb6u1 SAX-based renderer library for SVG ii libsm6 2:1.1.1-1 X11 Session Management library ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii mesa-utils 7.7.1-6 Miscellaneous Mesa GL utilities ii python 2.6.6-13~bpo60+1 interactive high-level object-orie ii python-bugbuddy2.30.0-4 Python module for bug-buddy ii python-gconf 2.28.1-1 Python bindings for the GConf conf ii python-gtk22.17.0-4 Python bindings for the GTK+ widge ii python-gtkglext1 1.1.0-5 GtkGLext python bindings ii python-opengl 3.0.1~b2-1Python bindings to OpenGL ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gnome-games recommends: ii gnome-games-extra-data2.30.0-1 games for the GNOME desktop (extra ii gvfs 1.6.4-3userspace virtual filesystem - ser Versions of packages gnome-games suggests: ii gnome-hearts 0.3-2+b1 The classic hearts card game for t -- 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#732139: PNG is not the preferred form for modification
On Sat, 2013-12-14 at 17:31 +0100, Thorsten Alteholz wrote: your new package python-sfml (1.5.1) contains two PNGs: ./python-sfml-1.3/doc/source/tutorials/system-thread-ordered.png ./python-sfml-1.3/doc/source/tutorials/system-thread-mixed.png as they are created with gimp, this is not the preferred form for modification (- DFSG 2). So please add the corresponding XCF files to the package. Hi Thorsten, Thanks for looking at the package. Although these images were created using GIMP, I don't think the XCF files (if they even exist) are any more preferred than the PNG files in the package. Those images are just screenshots of the windows console with no apparent modifications made to them. So I presume that the only use of GIMP in this was converting the result to PNG format - so any XCF files won't give you any more over importing the PNG file anyway. James -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732146: Incompatibile with the latest dovecot-imapd
Package: dovecot-antispam Severity: important Dovecot was recently updated to 2.2.9, and dovecot-antispam cannot be installed anymore. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732145: tendra: does not install: SIGSEGV
Package: tendra Version: 4.1.2-19 Severity: grave Justification: renders package unusable A screenshot says more than a thousand words ☺ tglase@tglase:~ $ sudo apt-get install tendra [sudo] password for tglase: Reading package lists... Done Building dependency tree Reading state information... Done Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done Suggested packages: tendra-doc The following NEW packages will be installed: tendra 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 2107 kB of archives. After this operation, 12.4 MB of additional disk space will be used. Get:1 http://http.debian.net/debian/ sid/main tendra i386 4.1.2-19 [2107 kB] Fetched 2107 kB in 7s (301 kB/s) Selecting previously unselected package tendra. (Reading database ... 231746 files and directories currently installed.) Preparing to unpack .../tendra_4.1.2-19_i386.deb ... Unpacking tendra (4.1.2-19) ... Processing triggers for man-db (2.6.5-2) ... Setting up tendra (4.1.2-19) ... Segment violation (core dumped) dpkg: error processing package tendra (--configure): subprocess installed post-installation script returned error exit status 139 Errors were encountered while processing: tendra Please fix this, I’d hate to see TenDRA be RM’d. Thanks! -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Versions of packages tendra depends on: ii binutils 2.24-2 ii libc6 2.17-97 Versions of packages tendra recommends: ii libc6-dev [libc-dev] 2.17-97 Versions of packages tendra suggests: pn tendra-doc none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732139: PNG is not the preferred form for modification
On Sat, Dec 14, 2013 at 1:32 PM, James Cowgill wrote: On Sat, 2013-12-14 at 17:31 +0100, Thorsten Alteholz wrote: your new package python-sfml (1.5.1) contains two PNGs: ./python-sfml-1.3/doc/source/tutorials/system-thread-ordered.png ./python-sfml-1.3/doc/source/tutorials/system-thread-mixed.png as they are created with gimp, this is not the preferred form for modification (- DFSG 2). So please add the corresponding XCF files to the package. Hi Thorsten, Thanks for looking at the package. Although these images were created using GIMP, I don't think the XCF files (if they even exist) are any more preferred than the PNG files in the package. Those images are just screenshots of the windows console with no apparent modifications made to them. So I presume that the only use of GIMP in this was converting the result to PNG format - so any XCF files won't give you any more over importing the PNG file anyway. Maybe (and this may not be easy) the screenshots could be done at build time? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732143: giflib: removal of libungif breaks rdeps
Julien Cristau jcris...@debian.org wrote: Please either revert or coordinate with reverse deps. Afaik there are currently no expressed rdeps on any formerly provides: *ungif*, so i think the problem is on the packages that will FTBFS from now on. For reference, libungif got removed in 2005 so i think that provide had its days. Best regards, retitle 732143 fbi: please link with libgif reassign fbi thanks Hello, Sorry that my change interferes with tiff transition... -- Thibaut Gridel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732147: libtk-img: uses internal copies of libpng and libtiff
Source: libtk-img Version: 1:1.4.2-1 Severity: serious Tags: security The latest changelog entry says you're now using internal copies of libpng and libtiff. Considering the security history of those two libs, that is not acceptable. Please find a way to use the standalong versions. Cheers, Julien signature.asc Description: Digital signature
Bug#720216: [evince]
It's a problem with evince-previewer which is registered as the handler for PDF files. In 3.4.0-3.1 PgUp scrolls screenful by screenful to the top of the current page and there stops - no ability to scroll to previous page. In 3.10.0-1 it scrolls to the top of the current page and then immediately jumps to the top of previous page without ever showing bottom of previous page. Broken either way. Thanks Michal On 13 December 2013 20:24, althaser altha...@gmail.com wrote: Package: evince Version: 3.10.0-1+b1 I couldn't reproduce that behaviour here. Can you please confirm the issue with the newer version 3.8.3-2 ? To have two pages it needs to enable dual option not zooming out. thanks Regards althaser -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732148: genshi: Rebuild docs at build time
Package: genshi Version: 0.7-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 (From Debian FTP Masters) Dear Maintainer, Howdy maintainer, I see that you're shipping a -doc package, and it looks like you're not rebuilding docs from a quick scan of rules. Please re-build docs at build-time, don't ship pre-built output of sources. Cheers, Paul y - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSrK6nAAoJEBJutWOnSwa/6s0QAKXSdhERGkQNaQFYQzSwztp5 yzEuBfmBoHkezSwHSjz45tsHzIY+YtG6a9KyigrgMX0l712SJG6CncmWeA/gGhFh ChZqEsfT+ofHsF5eKzPwveXL2By0W6czO2/UBPxwF3RHNp98QyOCU/TxTYALRuMC ZiQDwsmKrkN4gL4YrAy3HK7lqDMzPI1HnuxUfQWZy1YImjNoO4yDuv4yidQpEUkW kbO0hrZviCh97KCTMvDp/jbt2Ul5czorsEZNYPaLEX+ywF88Xkil7vtpNW/hAGxp 7ELqhW6/nhonEPOKYwkglOmZTiTkoUKIvgT03ER0t+qn3Mab8SgZHmMSZdDFNEI7 lPth0ZmTvVtWmbU4nRxOt9qHO4HCmPV++YSVNr+Zi7vlTmot4UMr53PCydDpkC20 xmOkYwQ17Kb/gpVBmRCgJzQjN2A89bdiG6EKfBAt+9yJ4vFr3Ef/2sb+bZRsfpnt AC4ompmihWdPFbiAi39d1tLBwHNDJr3Iul2sj9jTLshZRQ1Kj1sA8z+5umPnl0qH BxaHXyhpM0/ZQk4g2o/QXfBX2ToYi7+e1VojedCZ30LZB7yAe1mxWEqzrPfUPSiA FHAm1UUG01i2LA6nrwa9ylTVHKn4q7F47Ksdo25oU96Od4ybbyNAMLBTN38SGd2Z Xq2qCfXXW+EQPqHXlf9V =ogo7 -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#732149: munin outputs malformed XHTML
Package: munin Version: 2.1.2-1 Severity: normal Dear Maintainer, munin’s XHTML output is malformed XML in several places. This causes at least chromium to not render the output. Please consider fixing the errors, or preferably consider not producing XHTML output. There is no point in producing XHTML if you are not planning to use an XML parser for further processing, and you can’t do that if the XHTML is broken. Merely using it as a style, as is the case in munin, is pointless. There are at least two problems: * In the view of a single host, the headings of each plugin start with a a line: trtdApache accessesbr br is never closed, which is not well-formed. * In the view of a single plugin for a single host, the URIs in the links to the zoomable graphs contain ampersand characters. As ampersand characters have special meaning in XML, those in the URIs need to be represented with character entity references in XML (amp;). -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (745, 'testing'), (400, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages munin depends on: ii adduser 3.113+nmu3 ii cron 3.0pl1-124 ii libdate-manip-perl 6.41-1 pn libdigest-md5-perl none ii libfile-copy-recursive-perl 0.38-1 ii libhtml-template-perl2.95-1 ii libio-socket-inet6-perl 2.71-1 ii liblog-log4perl-perl 1.41-1.1 ii librrds-perl 1.4.7-2+b1 pn libstorable-perl none ii liburi-perl 1.60-1 ii munin-common 2.1.2-1 ii perl [libtime-hires-perl]5.18.1-5 ii perl-modules 5.18.1-5 ii rrdtool 1.4.7-2+b1 ii ttf-dejavu 2.33+svn2514-3 Versions of packages munin recommends: pn munin-doc none ii munin-node 2.1.2-1 Versions of packages munin suggests: ii apache2-bin [httpd] 2.4.6-3 ii elinks [www-browser]0.12~pre6-4 pn libapache2-mod-fcgidnone ii libnet-ssleay-perl 1.55-1+b2 ii lynx-cur [www-browser] 2.8.8pre1-1 ii w3m [www-browser] 0.5.3-12 -- Configuration Files: /etc/munin/apache.conf changed [not included] /etc/munin/munin.conf changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697810: selinux-policy-default: cannot install nut.pp
tag 697810 + moreinfo thanks Hi, Sorry for the late answer. Are you still experiencing this issue? If it's the case, could you try to also load the apache.pp module? Cheers Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732147: libtk-img: uses internal copies of libpng and libtiff
Hi Julien, On Sat, Dec 14, 2013 at 10:53 PM, Julien Cristau jcris...@debian.org wrote: The latest changelog entry says you're now using internal copies of libpng and libtiff. Considering the security history of those two libs, that is not acceptable. Please find a way to use the standalong versions. I did that until I could. As for now, to use the system-wide libpng I'd have to revert to libtk-img 1.3 (and lose quite a few useful changes including support for new image formats). And I don't know a way how to use new libtiff 4.0 (libtk-img supports only 3.something and uses libtiff internals, so porting isn't feasible for me). Cheers! -- Sergei Golovan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704242: Driver for PL-2303 HX not working
On Fri, Dec 13, 2013 at 04:06:35PM +0100, Karsten Malcher wrote: Hello together, is there anything new for the PL-2303 HX? It would be fine if it could work like in the past. Have you tried a newer kernel in a while? A number of things have been hopefully fixed since June when you last looked. greg k-h -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732150: unrtf.1: Some typographical changes in the manual
Package: unrtf Version: 0.21.5-1 Severity: minor Tags: patch Dear Maintainer, Changes: Space at end of lines removed Long option name excluded from hyphenation with \% in front of it Space between sentences increased to two (*roff default). Better is to start each sentence on a new line, as the file contains formatting commands. A full stop, that begins or ends a string, protected with \ - changed to \-, if it means an option - (printed as a hyphen) changed to \[en] (en-dash), if it is used as a start of a paragraph Macros UR/UE used around a web-address \: added after / in a web address, to (only) enable hyphenation there Patch: --- unrtf.1 2013-11-30 11:31:01.0 + +++ unrtf.1.new 2013-12-13 20:36:23.0 + @@ -9,7 +9,7 @@ UnRTF \- converts document in RTF format .BI unrtf [ options ] [ file... ] .br .sp -Options: +Options: .BI [\-\-nopict] .BI [\-\-noremap] .BI [\-\-html] @@ -21,24 +21,24 @@ Options: .BI [\-\-verbose] .BI [\-\-quiet] .BI [\-\-version] -.BI [\-P\ config_search_path] +.BI [\-P\ \%config_search_path] .BI [\-t\ tags_file] .br .SH DESCRIPTION The program .B unrtf is a converter from Rich Text Format (RTF) to a growing number -of document formats. At present it supports +of document formats. At present it supports Hypertext Markup Language (HTML), plain text, text with VT100 codes, LaTeX, and RTF itself. It is possible to produce troff files with macro calls; an example configuration for troff and the mm macro package is provided. -All output formats except HTML are alpha i.e. limited and development +All output formats except HTML are alpha i.e.\ limited and development has just begun. -However with HTML, the program supports tables, fonts, -hyperlinks, and paragraph alignment. Font support includes -face and size changes, as well as -typical attributes such as italic, bold, +However with HTML, the program supports tables, fonts, +hyperlinks, and paragraph alignment. Font support includes +face and size changes, as well as +typical attributes such as italic, bold, underlining, strikethrough, smallcaps, allcaps, expand, compress and both foreground and background colors. Images are always stored to separate files in the current @@ -47,13 +47,13 @@ directory, or they can be ignored. Starting with version 0.21.0, all control of unrtf output is through runtime configuration files. This makes it easy for users to fine-tune the output, and/or define new output formats. The configuration files can -be read from the distributed ones, or from user files, searched for in the +be read from the distributed ones, or from user files, searched for in the .I config_search_path . .P Code page conversion is performed with the iconv(3) package. .SH OPTIONS .TP -\-\-nopict +\-\-nopict disables the automatic storing of embedded pictures to the current directory. .TP @@ -76,18 +76,18 @@ selects text output with VT100 escape co \-\-latex selects output of a LaTeX document. .TP -\-\-verbose +\-\-verbose prints additional information. .TP \-\-quiet suppress output of leading comments .TP -\-\-version +\-\-version prints the program version. .TP \-t tags_file -specifies the tags output configuration file to be used. The command -unrtf -t html is functionally identical to unrtf --html. The +specifies the tags output configuration file to be used. The command +unrtf \-t html is functionally identical to unrtf \-\-html. The configuration files are a simple format. To change the behaviour of unrtf, a local copy of a system configuration file can be be made and edited. The most complete configuration file and hence the best starting @@ -96,19 +96,20 @@ point is /usr/local/share/unrtf/html.con \-P config_search_path specifies the directories in which the configuration file for the specified format will be sought. The path can be provided as a single directory -or a list of colon separated directories. +or a list of colon separated directories. The default is /usr/local/share/unrtf/ where distributed output configuration files are installed. .SH FILES .TP /usr/local/share/unrtf/*.conf -- run time output configuration files. +\[en] run time output configuration files. .TP /usr/local/share/unrtf/SYMBOL.charmap -- UTF encoding of the SYMBOL font +\[en] UTF encoding of the SYMBOL font used in many RTF files. Unfortunately the iconv package does not include font encodings. The format is identical to iconv code page files. .SH WEBSITE -http://www.gnu.org/software/unrtf/unrtf.html +.UR http://\:www.gnu.org/\:software/\:unrtf/\:unrtf.html +.UE .SH NOTES Report bugs in the program to da...@physiol.usyd.edu.au -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'testing'), (500, 'stable') Architecture: i386 (i586) Kernel: Linux 3.2.46-1-rt67-1 Locale: LANG=is_IS, LC_CTYPE=is_IS
Bug#732151: postgis: FTBFS on various architectures
Source: postgis Version: 2.1.0-4 Severity: serious Justification: fails to build from source (but built successfully in the past) Control: block 712688 with -1 Hi, see the build logs at https://buildd.debian.org/status/package.php?p=postgis postgis fails to build on armel armhf mips mipsel powerpc s390x and sparc. Cheers, Julien signature.asc Description: Digital signature
Bug#657964: openvpn: Can't connect to a VPN using SOCKS proxy
This is the parent bug, efforts should be focused there. https://community.openvpn.net/openvpn/ticket/328 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732067: [Pkg-mozext-maintainers] Bug#732067: enigmail asks for passphrase automatically
On 12/14/2013 05:01 AM, Martin Vegter wrote: Yes, the button is still there. It is the Decrypt button (Decrypt or verify the message with OpenPGP), I think same as when you click the OpenPGP menu - Decrypt/Verify OK, you're talking about the button in the top-level toolbar when looking at the message, correct? I just want to be clear about what the concern is here: i think the problem is that decryption/verification happens *even though* you have Automatically decrypt/verify messages unchecked. So it sounds like a problem with that setting. Is that correct? or is this a separate concern about passphrase prompting in general? Regards, --dkg signature.asc Description: OpenPGP digital signature
Bug#502532: gramps: Addition of events and typo fix Bat Mitzva not Bas Mitzva
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tag 502532 + fixed-upstream thanks The original proposal to add Bat Mitzva to the list of events was not taken forward because it is the same event as a Bas Mitzva. However, the Bas has been changed to Bat because it is more widely used. As Bas Mitzva is what is in the GEDCOM standard, inports and exports to GEDCOM will still use this term. Thanks to Vassilii for implementing this change! It will appear in Gramps Version 3.4.7 (or 4.0.3). Regards, Ross -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSrLgdAAoJEFP+e72miRD8dOwP/2jyb1E1xn1mGU+ar/oUonch xpoV1br/jz7NgE3ibCQPReLF2k69+y4rBSMqawbRk+kYAEmv01WzQy63/DXprtyL r+Q00P1D2jcwSWxUi8lDnIf2y7YmYHr+JvO+ARF6plujHIOQPSmw9YgZtggP+F8t NT5ExaE3gcjRGqzpyEHdHADw4FOtU0cChMbWo82ecZUEWdnTgO0rTfObgca+r+xb F3hxxsUnhOOJ8InrVZCm2+do46ukIUJxVDVO1U8/Jktg8ahEohHZONR5IOAOuA5b TAFf6bkiWbPa0j2goJuAIOcu/OHjG/sbgpDyTBRmv+V3BHYc9CspejUDJpOMxDI6 DzZFyQ8DpP51t4ijnlmVm8r5z8msNJNehMjy1pkfsNUypWRSFP3l4ibVr2hbvuvm bHSBC09MxxFw8uglquKPZDaIGwXMEaI4l8Kkaeb31Ufoeiha4Y872ggT9z2KWxd8 JypmWMS5bMsnpwVyk2x69tEXnBa+lTAmoJ7q5YqE5Ni1rUFsKV2/S0wMRsqiy6De dvuUemmIY+24K3bk8nTBGwVSYprxmxbAYBuiv8xjL12+z7x1q7Ik9GyNTL5ugVcY a51xJH8s76KV67f/zl6p32ISEnQ5/5ZTYjj04nNxvmyJ6+/98govwqTRo+CUihGZ elbUI6TePZRTYiAYLrt6 =YYte -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#732152: linux-image-3.11-0.bpo.2-amd64: Actual use of macvtap hangs system
Package: src:linux Version: 3.11.8-1~bpo70+1 Severity: normal There is a regression in 3.11.8-1~bpo70+1 compared to current wheezy 3.2. Using macvtap in 3.11 bpo hard hangs the system. The module loads fine, but when I actually start a qemu-kvm session that uses macvtap in virt-manager the system completely locks up (no messages in logs either because everything stops).. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: To be filled by O.E.M. product_name: To be filled by O.E.M. product_version: To be filled by O.E.M. chassis_vendor: To Be Filled By O.E.M. chassis_version: To Be Filled By O.E.M. bios_vendor: American Megatrends Inc. bios_version: 1903 board_vendor: ASUSTeK COMPUTER INC. board_name: M5A97 R2.0 board_version: Rev 1.xx ** Network interface configuration: auto lo iface lo inet loopback ** PCI devices: 00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B) [1002:5a14] (rev 02) Subsystem: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port B) [1002:5a14] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- INTx- Capabilities: access denied 00:00.2 IOMMU [0806]: Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU) [1002:5a23] Subsystem: Advanced Micro Devices [AMD] nee ATI RD990 I/O Memory Management Unit (IOMMU) [1002:5a23] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 72 Capabilities: access denied 00:02.0 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port B) [1002:5a16] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: fea0-feaf Prefetchable memory behind bridge: c000-cfff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:04.0 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port D) [1002:5a18] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: d000-dfff Prefetchable memory behind bridge: d010-d01f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:05.0 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port E) [1002:5a19] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 Memory behind bridge: fe90-fe9f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:07.0 PCI bridge [0604]: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (PCI express gpp port G) [1002:5a1b] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
Bug#718701: [Xcb] Bug#718701: libxcb missing xcb-xkb module
Probably not much use to upstream maintainers, but I just generated
myself a local copy of the libxcb-xkb0 using the attached patch to the
source obtained from
apt-get source libxcb
You may find it a sufficient workaround until a better one is provided
by upstream.
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
diff -urN libxcb-1.9.1-3.1.ORIG/debian/control libxcb-1.9.1-3.1/debian/control
--- libxcb-1.9.1-3.1.ORIG/debian/control 2013-12-14 20:04:10.870917263 +
+++ libxcb-1.9.1-3.1/debian/control 2013-12-14 18:37:24.821152470 +
@@ -1132,6 +1132,69 @@
* Easy creation of new extensions: automatically generates interface from
machine-parsable protocol descriptions
+Package: libxcb-xkb0
+Section: libs
+Architecture: any
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Pre-Depends: ${misc:Pre-Depends}
+Multi-Arch: same
+Description: X C Binding, xkb extension
+ This package contains the library files needed to run software using
+ libxcb-xkb, the xkb extension for the X C Binding.
+ .
+ The XCB library provides an interface to the X Window System protocol,
+ designed to replace the Xlib interface. XCB provides several advantages over
+ Xlib:
+ .
+ * Size: small library and lower memory footprint
+ * Latency hiding: batch several requests and wait for the replies later
+ * Direct protocol access: one-to-one mapping between interface and protocol
+ * Thread support: access XCB from multiple threads, with no explicit locking
+ * Easy creation of new extensions: automatically generates interface from
+machine-parsable protocol descriptions
+
+Package: libxcb-xkb0-dev
+Section: libdevel
+Architecture: any
+Multi-Arch: same
+Depends: ${misc:Depends}, libxcb-xkb0 (= ${binary:Version}), libxcb1-dev
+Description: X C Binding, xkb extension, development files
+ This package contains the header and library files needed to build software
+ using libxcb-xkb, the xkb extension for the X C Binding.
+ .
+ The XCB library provides an interface to the X Window System protocol,
+ designed to replace the Xlib interface. XCB provides several advantages over
+ Xlib:
+ .
+ * Size: small library and lower memory footprint
+ * Latency hiding: batch several requests and wait for the replies later
+ * Direct protocol access: one-to-one mapping between interface and protocol
+ * Thread support: access XCB from multiple threads, with no explicit locking
+ * Easy creation of new extensions: automatically generates interface from
+machine-parsable protocol descriptions
+
+Package: libxcb-xkb0-dbg
+Priority: extra
+Section: debug
+Architecture: any
+Depends: ${misc:Depends}, libxcb-xkb0 (= ${binary:Version})
+Multi-Arch: same
+Description: X C Binding, xkb extension, debugging symbols
+ This package contains the debugging symbols associated with
+ libxcb-xkb, the xkb extension for the X C Binding. gdb will
+ automatically use these symbols when debugging libxcb-xkb.
+ .
+ The XCB library provides an interface to the X Window System protocol,
+ designed to replace the Xlib interface. XCB provides several advantages over
+ Xlib:
+ .
+ * Size: small library and lower memory footprint
+ * Latency hiding: batch several requests and wait for the replies later
+ * Direct protocol access: one-to-one mapping between interface and protocol
+ * Thread support: access XCB from multiple threads, with no explicit locking
+ * Easy creation of new extensions: automatically generates interface from
+machine-parsable protocol descriptions
+
Package: libxcb-xprint0
Section: libs
Architecture: any
diff -urN libxcb-1.9.1-3.1.ORIG/debian/libxcb-xkb0-dev.install libxcb-1.9.1-3.1/debian/libxcb-xkb0-dev.install
--- libxcb-1.9.1-3.1.ORIG/debian/libxcb-xkb0-dev.install 1970-01-01 01:00:00.0 +0100
+++ libxcb-1.9.1-3.1/debian/libxcb-xkb0-dev.install 2013-12-14 18:38:58.400731404 +
@@ -0,0 +1,4 @@
+usr/include/xcb/xkb.h
+usr/lib/*/libxcb-xkb.a
+usr/lib/*/libxcb-xkb.so
+usr/lib/*/pkgconfig/xcb-xkb.pc
diff -urN libxcb-1.9.1-3.1.ORIG/debian/libxcb-xkb0.install libxcb-1.9.1-3.1/debian/libxcb-xkb0.install
--- libxcb-1.9.1-3.1.ORIG/debian/libxcb-xkb0.install 1970-01-01 01:00:00.0 +0100
+++ libxcb-1.9.1-3.1/debian/libxcb-xkb0.install 2013-12-14 18:38:32.392848427 +
@@ -0,0 +1 @@
+usr/lib/*/libxcb-xkb.so.0*
signature.asc
Description: PGP signature
Bug#732124: initctl reload behaviour should be configurable in job file
Hi Ian, On Sat, Dec 14, 2013 at 12:49:01PM +, Ian Jackson wrote: Package: upstart Version: 1.20-1 Severity: wishlist (Where does this version number come from? Is this just a transposition error of 1.10-2, the current version in tetisting/unstable?) initctl(8) says that initctl reload sends the job's process a SIGHUP. Some programs won't expect to be randomly sent SIGHUPs. It should be possible to describe in the config file what should be done instead - probably, a command a la pre-exec et al. This would also make it possible to reload abstract jobs, and tasks. As of version 1.10, upstart does support a 'reload signal' directive to specify a signal other than SIGHUP. It seems the initctl(8) manpage has not been updated yet to match. Do you consider fixing the manpage to be a sufficient solution for this bug, or do you think that support for arbitrary reload commands is needed? For my part I don't think that there's a need for abstract 'reload's when one can do a 'restart' instead. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731884: Problem is order of partitions seen by mdadm
On Sat, 14 Dec 2013 16:38:08 + Ben Hutchings b...@decadent.org.uk wrote: Right, I don't think it is correct to look for firmware RAID signatures inside partitions. Upstream commit 357ac1067835d1cdd5f80acc28501db0ffc64957 NeilBrown signature.asc Description: PGP signature
Bug#732124: initctl reload behaviour should be configurable in job file
Steve Langasek writes (Re: Bug#732124: initctl reload behaviour should be configurable in job file): On Sat, Dec 14, 2013 at 12:49:01PM +, Ian Jackson wrote: Package: upstart Version: 1.20-1 Severity: wishlist (Where does this version number come from? Is this just a transposition error of 1.10-2, the current version in tetisting/unstable?) Yes. Oh bum. Shall I fix all of the reports I submitted today ? As of version 1.10, upstart does support a 'reload signal' directive to specify a signal other than SIGHUP. It seems the initctl(8) manpage has not been updated yet to match. Aha. Do you consider fixing the manpage to be a sufficient solution for this bug, or do you think that support for arbitrary reload commands is needed? For my part I don't think that there's a need for abstract 'reload's when one can do a 'restart' instead. I haven't done a survey but I imagine there are daemons out there which don't like being randomly HUPped. Of course they could be fixed, but asking them to handle a signal is rather unfriendly. So I think the best answer would be to provide a command-based override. But it's hardly a high priority and if you feel like closing this bug on the basis that it's a wishlist item you're not going to get round to, I won't mind. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart proposed policy in Debian
Ian Jackson writes (upstart proposed policy in Debian): Having read the docs there I have some apparently unanswered questions about how the upstart proponents think we would use upstart in Debian. I found policy 9.11.1 which I had unaccountably failed to notice before. It answer the question of how to do the transition from sysvinit to upstart, with a hideous shell rune. Perhaps the upstart package could provide a cooked command and then we could all say if init-is-upstart 2/dev/null; then exit 1; fi or something. (IIRC some comments earlier in this thread about some corner cases during upgrades; perhaps my suggestionn would help there too.) It didn't answer my other questions. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732153: mercurial: Broken state of the repository after VPN connection was dropped during push
Package: mercurial Version: 2.2.2-3 Severity: normal Dear Maintainer, I was running hg push, and in the middle I dropped the VPN connection. The hg push command hang. After I killed it, the repository was is left in an inconsistent state. Miraculously the data managed to be transferred to the server, and a hg pull and hg update sorted things out. -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (700, 'stable'), (600, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-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 mercurial depends on: ii libc6 2.13-38 ii mercurial-common 2.2.2-3 ii python2.7.3-4+deb7u1 ii ucf 3.0025+nmu3 Versions of packages mercurial recommends: ii openssh-client 1:6.0p1-4 Versions of packages mercurial suggests: ii kdiff3-qt 0.9.96-4 ii kompare 4:4.8.4+dfsg-1 pn qct none ii tk8.6 [wish] 8.6.0-1 pn vim | emacs none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732154: znc: after upgrading to znc 1.2-2 the 'znc' binary was gone
Package: znc Version: 1.2-2 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? doing an apt-get upgrade * What exactly did you do (or not do) that was effective (or ineffective)? i noticed a new znc pakage (1.2-2) was available. i already had 1.2-1 installed (since i tend to upgrade every 1/2 weeks) but the instance running was still 1.0something since i didnt restart znc for a while and its not done automatically after an upgrade * What was the outcome of this action? the outcome was that after killing znc (yes im an evil bastard) and trying to restart it there was no znc binary found on the system although apt is convinced the pakage installed correctly i worked around this by manually compiling and installing it (which works fine, but now im unsure if future apt updates are a good idea). * What outcome did you expect instead? well, guess... -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.10-3-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages znc depends on: ii libc6 2.17-97 ii libgcc1 1:4.8.2-10 ii libsasl2-2 2.1.25.dfsg1-17 ii libstdc++6 4.8.2-10 Versions of packages znc recommends: ii znc-perl1.2-2 ii znc-python 1.2-2 ii znc-tcl 1.2-2 znc 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#196857: mount: warns about *default* swapfile permissions
It's a pity to re-open a 10-years-old bug, but here we go. The bug is still present in wheezy version of mount, which is 2.20.1-5.3 and is greather than the fixed-in version 2.19.1-5. Maybe it were fixed in 2.19 but re-introduced in 2.20, I dunno. # swapon -v /dev/sda8 swapon on /dev/sda8 swapon: /dev/sda8: insecure permissions 1660, 0660 suggested. swapon: /dev/sda8: found swap signature: version 1, page-size 4, same byte order swapon: /dev/sda8: pagesize=4096, swapsize=8589934592, devsize=8589934592 # cat /etc/debian_version 7.3 # _ Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732127: Does setuid also set the group(s) ? It should.
Control: found -1 1.10-2 Control: notfound -1 1.20-1 Control: tags -1 confirmed On Sat, Dec 14, 2013 at 01:18:39PM +, Ian Jackson wrote: Package: upstart Version: 1.20-1 The documentation in init(5) doesn't mention whether specifying setgid in the job file also results in appropriate calls to setgid and setgroups. Firstly, clearly this should be documented. Agreed that this is underdocumented. The current behavior (as of upstart 1.7) is to call initgroups(), and to set the primary group to either the value of setgid if specified, or the primary group of the setuid user if not. But, further, I think setuid should cause the group ids (setresgid and also setgroups) to be set as well. Otherwise jobs will inherit the group 0 (root) which might well be unexpectedly powerful. Arguably failure to do this is a security problem, although of course the details will depend on exactly what people write in their service files. Right, and upstart avoids that. If the user specifies setgid _and_ setuid, it's arguable whether you should also call initgroups. I would say not - not being a member of groups is generally less powerful. I think it would be better to extend the config syntax with an additional 'groups' option for maximum flexibility. If you want to see this change made, it would be best if you could engage directly with the upstream mailing list (upstart-de...@lists.ubuntu.com) to sort out the exact semantics. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732093: qpdf: use dh-autoreconf instead of autotools-dev for better new-port coverage
Colin Watson cjwat...@ubuntu.com wrote: Package: qpdf Version: 5.0.1-1 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu ubuntu-patch trusty Hi, The ppc64el port requires a patch to libtool.m4. I don't think that's in Debian yet, but when it is it will require autoreconfing a bunch of packages to pick it up. qpdf could handle this quite easily by using dh-autoreconf rather than just autotools-dev; when libtool is in use (as of course it is here), dh-autoreconf is a superset of autotools-dev, and it seems to still build just fine if I do the following. * Use dh-autoreconf in order to update libtool.m4 for new ports. I'll make sure the next upload has this. Do you need it right away? I'm hoping to release qpdf 5.1.0 this weekend or, if not, within the next week, and I can include this fix when I upload 5.1.0. If you need it right away to avoid making the Ubuntu qpdf deviate from the debian qpdf, I can upload a new 5.0.1 before I do 5.1.0. -- Jay Berkenbilt q...@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#732124: initctl reload behaviour should be configurable in job file
On Sat, Dec 14, 2013 at 08:24:18PM +, Ian Jackson wrote: Steve Langasek writes (Re: Bug#732124: initctl reload behaviour should be configurable in job file): On Sat, Dec 14, 2013 at 12:49:01PM +, Ian Jackson wrote: Package: upstart Version: 1.20-1 Severity: wishlist (Where does this version number come from? Is this just a transposition error of 1.10-2, the current version in tetisting/unstable?) Yes. Oh bum. Shall I fix all of the reports I submitted today ? Yes please :) Do you consider fixing the manpage to be a sufficient solution for this bug, or do you think that support for arbitrary reload commands is needed? For my part I don't think that there's a need for abstract 'reload's when one can do a 'restart' instead. I haven't done a survey but I imagine there are daemons out there which don't like being randomly HUPped. Of course they could be fixed, but asking them to handle a signal is rather unfriendly. Agreed; but a 'reload' is something that happens only under admin direction, and the upstart job syntax gives maintainers the flexibility to set a different reload signal if appropriate - remembering that 'reload' has always been an optional init.d command in Debian for precisely the reason that many services don't support a graceful reload, I think seasoned admins are unlikely to use it and are instead probably going to use 'restart'. The common case for an unhandled SIGHUP is to kill the process anyway, at which point upstart will restart it if the job is set up with 'respawn'... so I think the default semantics are pretty good for the common case (now) and we mostly just need to step up the documentation. So I think the best answer would be to provide a command-based override. But it's hardly a high priority and if you feel like closing this bug on the basis that it's a wishlist item you're not going to get round to, I won't mind. Ok. I'll consider this bug resolved once the documentation is fixed. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#732095: webkitgtk contains a JSON do-no-evil licensed file.
Hi Paul, On 13/12/13 22:33, Paul Tagliamonte wrote: Package: webkitgtk Severity: serious User: paul...@debian.org Usertags: ftp X-Debbugs-CC: ftpmas...@ftp-master.debian.org thanks Howdy maintainers, http://sources.debian.net/src/webkitgtk/2.3.2-1/Source/WebCore/inspector/Scripts/jsmin.py I believe this file to be a derived work, and subject to Crockford's terms, and thus isn't distributable in main. For some reason this is in the lintian overrides(!?), please remove it from the overrides, and strip this file (or move this package to non-free). The override has a comment, did you see it? # Source/WebCore/inspector/Scripts/jsmin.py mentions the original # implementation's license but doesn't have this non-free license, # see https://bugs.webkit.org/show_bug.cgi?id=123665 webkitgtk source: license-problem-json-evil As mentioned in the upstream bug report, jsmin.py isn't a derived work but a reimplementation, see https://pypi.python.org/pypi/jsmin. Newer versions of jsmin.py don't mention the original code copyright and license, and are released as MIT. I can update the copy upstream to avoid any confusion. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729572: Failed to build on mips64el
On 13/12/13 16:57, Alberto Garcia wrote: On Fri, Dec 13, 2013 at 10:34:37PM +0800, YunQiang Su wrote: Hey, thanks for the patch. However, why do you need changes in both places? I didn't test only change one place and not very clear about why there are 2 places, so I add them both. I actually wonder why we need the CPPFLAGS thing at all instead of --disable-jit. Emilio? --disable-jit doesn't disable MacroAssembler and YARR, see https://bugs.webkit.org/show_bug.cgi?id=113638#c8 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732155: please package vagrant 1.4
Package: vagrant Version: 1.2.2-1 Severity: normal The vagrant version currently in testing/unstable doesn't work with virtualbox 4.3, which just hit sid: $ vagrant up Vagrant has detected that you have a version of VirtualBox installed that is not supported. Please install one of the supported versions listed below to use Vagrant: 4.0, 4.1, 4.2 Please upgrade to the latest version of vagrant to solve this problem. thanks! :) Christine -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (900, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vagrant depends on: ii bsdtar 3.1.2-7 ii curl 7.33.0-2 ii openssh-client 1:6.4p1-1 ii ruby-childprocess 0.3.9-2 ii ruby-erubis2.7.0-2 ii ruby-i18n 0.6.5-1 ii ruby-log4r 1.1.10-2 ii ruby-net-scp 1.1.1-1 ii ruby-net-ssh 1:2.6.8-1 ii ruby1.9.1 1.9.3.484-1 Versions of packages vagrant recommends: ii virtualbox 4.3.2-dfsg-1 vagrant 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#732127: Does setuid also set the group(s) ? It should.
Steve Langasek writes (Re: Bug#732127: Does setuid also set the group(s) ? It should.): Control: found -1 1.10-2 Control: notfound -1 1.20-1 Control: tags -1 confirmed On Sat, Dec 14, 2013 at 01:18:39PM +, Ian Jackson wrote: The documentation in init(5) doesn't mention whether specifying setgid in the job file also results in appropriate calls to setgid and setgroups. Firstly, clearly this should be documented. Agreed that this is underdocumented. The current behavior (as of upstart 1.7) is to call initgroups(), and to set the primary group to either the value of setgid if specified, or the primary group of the setuid user if not. I think that's a perfectly tolerable behaviour. If the user specifies setgid _and_ setuid, it's arguable whether you should also call initgroups. I would say not - not being a member of groups is generally less powerful. I think it would be better to extend the config syntax with an additional 'groups' option for maximum flexibility. That wouldn't hurt. If you want to see this change made, it would be best if you could engage directly with the upstream mailing list (upstart-de...@lists.ubuntu.com) to sort out the exact semantics. TBH I'd be happy just to see the existing behaviour documented. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732156: Precise documentation for ExecStart command syntax
Package: systemd Version: 204-5 Severity: minor Reading systemd.service(5), I'm confused about the exact syntax and quoting for the ExecStart= directive. AFAICT from reading systemd.unit(5), the values in the unit file general syntax are whatever comes after the =, and it is up to the particular directive to specify the interpretation of the RHS. ExecStart talks about multiple commands being separated by semicolons. It also talks about the first argument but it doesn't specify how arguments are split. It tells us that shell syntax is not used. But it provides this example: ExecStart=/bin/sh -c 'dmesg | tac' If that example is correct, something nontrivial must be going on. I think it should be documented. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732067: [Pkg-mozext-maintainers] Bug#732067: enigmail asks for passphrase automatically
On 2013-12-14 20:46, Daniel Kahn Gillmor wrote: On 12/14/2013 05:01 AM, Martin Vegter wrote: Yes, the button is still there. It is the Decrypt button (Decrypt or verify the message with OpenPGP), I think same as when you click the OpenPGP menu - Decrypt/Verify OK, you're talking about the button in the top-level toolbar when looking at the message, correct? I am talking about the button in the top menu, next to write, reply, forward. It might not be there by default, but can be added by right-clicking on the bar and selecting customize I just want to be clear about what the concern is here: i think the problem is that decryption/verification happens *even though* you have Automatically decrypt/verify messages unchecked. So it sounds like a problem with that setting. the problem is: 1) sometimes icedove asks for my passphrase on start and also throughout my session in random intervals 2) icedove asks for my passphrase everytime I select an encrypted message in my sent folder especially annoying behavior is when I am going through my sent folder, every time I hit an encrypted message a window pops up and asks me for my passphrase Is that correct? or is this a separate concern about passphrase prompting in general? passphrase prompting in general is of course a good think. But only when I tell to decrypt/sign a message, not automatically Regards, --dkg many thanks, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701495: Does not occur on current wheezy using pcnet drivers
Hi, I know I kind of disappeared on this bug. Sorry about that I wasn't doing well and things got kind of hectic at the same time. Anyway, I wanted to report that I have built a new VM with four NICs using the pcnet driver (three macvtaps to actual physical interfaces and one isolated network to access the host itself, since macvtap cannot access the host) and the networking works with no issues. I intend to try using the latest spice-tools and switching to virtio drivers to see if the problem occurs again. If not, then it is resolved whether in qemu-kvm or in virtio windows drivers, or both, otherwise it is likely a Windows driver issue though it could still be the type of emulated device that makes the difference. Regards, Daniel signature.asc Description: OpenPGP digital signature
Bug#729678: [gob-list] Fw: Bug#729678: gob2: Uses Iface instead of Interface
I just made 2.0.20 release including pedro's patches, so that should fix it. Best, Jiri On Fri, Nov 15, 2013 at 1:03 PM, Stephen Kitt st...@sk2.org wrote: Hi, I'm forwarding a bug report about the interface struct types gob2 generates. It should be fixed by Pedro L. Lucas's patches from last January. Please keep the Debian bug and Tony in the cc list on any replies! (Tony, sorry for the multiple emails, gob-list is subscriber-only and I couldn't remember which address I was subscribed with!) Regards, Stephen Begin forwarded message: Date: Fri, 15 Nov 2013 16:47:28 + From: Tony Houghton h...@realh.co.uk To: Debian Bug Tracking System sub...@bugs.debian.org Subject: Bug#729678: gob2: Uses Iface instead of Interface Package: gob2 Version: 2.0.19-1 Severity: normal When a gob2 class implements an interface the generated code refers to the interface's struct type as FooBarIface, but GObject's macros generate code for a type named FooBarInterface. Adding a typedef is an easy workaround, but I still think gob2 should get this right. Perhaps the convention changed in GObject, in which case I suppose gob2 could either have an option or use its own typedefs to ensure both names are valid. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-rc7-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 gob2 depends on: ii libc6 2.17-93 ii libglib2.0-0 2.36.4-1 gob2 recommends no packages. gob2 suggests no packages. -- no debconf information -- to unsubscribe: send mail to minimal...@5z.com with unsubscribe gob-list in the subject -- Jiri (George) Lebl, http://www.math.okstate.edu/~lebl/ or http://www.jirka.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732158: debian-reference: please add credits and copyright for translators
Package: debian-reference Severity: wishlist Please add credits and copyright for translators. Regarding copyright: it seems incorrect, that copyright note is limited to: Copyright © 2007-2012 Osamu Aoki and translators are left out. Regarding credits: a separate paragraph could be added to the About this document section. Thanks Holger -- Created with Sylpheed 3.2.0 under the new D E B I A N L I N U X 7 . 0 W H E E Z Y ! Registered Linux User #311290 - https://linuxcounter.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732157: Want SIGSTOP-style daemon/service readiness notification
Package: systemd Version: 204-5 Severity: wishlist It would be nice if systemd could implement the service supervisor side of the service readiness protocol that upstart calls expect stop: The service doesn't fork, and when considers itself ready it raises SIGSTOP. The supervisor can observe this via the usual mechanisms, being the service's parent, and when it occurs it sends the service CONT and starts whatever was waiting for readiness. The sd_notify(3) protocol is just about tolerable, and it is good that it's documented, but it is quite unattractive for a daemon author: Either they have to add a build- and runtime- dependency on a systemd-specific library, or they have to reimplement a fairly tedious piece of socket code. For a daemon author, raise(SIGSTOP) is lovely and simple. I guess this would be a new Type (but I'm still halfway through the docs so no expert). Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732158: debian-reference: please add credits and copyright for translators
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Le 14/12/2013 17:04, Holger Wansing a écrit : Package: debian-reference Severity: wishlist Please add credits and copyright for translators. That wouldn’t be correct in the English version, nor in any translation but the relevant one. Please continue to use the addenda feature of po4a to add the relevant notes in the relevant translation, as done via the po4a/*.1.add files from the debian-reference sources. Regards David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJSrMzBAAoJEAWMHPlE9r08V0gIAIHpL0fIZWRSFlQU17ab4+Rd Bvoa8RMHGmiayqnp/Cte26f5zIVb6LTCcqGvJm1FQFlkoRp++51ePE5eDP79Bx9V EXJu3rQbzNuXkLtUi3K3oKTsM/ClMo2o3UzsgFHrUWLm18ehrfka1FKsJ1F5AB9k lzOVJlOt8s/eUDwCoCf6yWQiTdcvqFeh1zi6OHSBmb25dY/fbm8T8lsLYFlVgn6D mKgkLH6OdLaw2Id54+2FWXAI26pOlMdR+1PBmHz9pBx68sLvewy96dnT8IiPy8Wq KE3SEyco5FAHa/8pECr0y45nl4TlNl0zyHFVGwLCvHCv+WSUF6jh0YgbUDNyX60= =eXqE -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#732159: Should this package be removed?
Package: mplayer Severity: serious Should this package be removed? If so, please reassign to ftp.debian.org - Last upload nearly two years ago - FTBFS for a long time - Incompatible with current libav - Alternatives exist (mplayer2, mpv) Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732160: openmpi-common: Valgrind suppression file incomplete
Package: openmpi-common
Version: 1.6.5-6
Severity: normal
When checking the simple test program:
#include mpi.h
int main()
{
MPI_Init(0, 0);
MPI_Finalize();
return 0;
}
with valgrind, it returns the following memory leak information :
$ mpiexec -n 1 valgrind --suppressions=/usr/share/openmpi/openmpi-valgrind.supp
./openmpi_valgrind.elf
==21325== Memcheck, a memory error detector
==21325== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==21325== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==21325== Command: ./openmpi_valgrind.elf
==21325==
==21325== Syscall param writev(vector[...]) points to uninitialised byte(s)
==21325==at 0x6332937: writev (writev.c:50)
==21325==by 0x8851312: mca_oob_tcp_msg_send_handler (in
/usr/lib/openmpi/lib/openmpi/mca_oob_tcp.so)
==21325==by 0x88524D5: mca_oob_tcp_peer_send (in
/usr/lib/openmpi/lib/openmpi/mca_oob_tcp.so)
==21325==by 0x8856335: mca_oob_tcp_send_nb (in
/usr/lib/openmpi/lib/openmpi/mca_oob_tcp.so)
==21325==by 0x8645E2E: orte_rml_oob_send (in
/usr/lib/openmpi/lib/openmpi/mca_rml_oob.so)
==21325==by 0x8646453: orte_rml_oob_send_buffer (in
/usr/lib/openmpi/lib/openmpi/mca_rml_oob.so)
==21325==by 0x8C62A5E: ??? (in
/usr/lib/openmpi/lib/openmpi/mca_grpcomm_bad.so)
==21325==by 0x50B0A6E: ompi_mpi_init (in
/usr/lib/openmpi/lib/libmpi.so.1.0.8)
==21325==by 0x50C7B57: PMPI_Init (in /usr/lib/openmpi/lib/libmpi.so.1.0.8)
==21325==by 0x408E2F: main (openmpi_valgrind.cpp:5)
==21325== Address 0x71adbb1 is 161 bytes inside a block of size 256 alloc'd
==21325==at 0x4C2B7EE: realloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21325==by 0x5137CB9: opal_dss_buffer_extend (in
/usr/lib/openmpi/lib/libmpi.so.1.0.8)
==21325==by 0x513806D: opal_dss_copy_payload (in
/usr/lib/openmpi/lib/libmpi.so.1.0.8)
==21325==by 0x5114DBD: orte_grpcomm_base_pack_modex_entries (in
/usr/lib/openmpi/lib/libmpi.so.1.0.8)
==21325==by 0x8C6293F: ??? (in
/usr/lib/openmpi/lib/openmpi/mca_grpcomm_bad.so)
==21325==by 0x50B0A6E: ompi_mpi_init (in
/usr/lib/openmpi/lib/libmpi.so.1.0.8)
==21325==by 0x50C7B57: PMPI_Init (in /usr/lib/openmpi/lib/libmpi.so.1.0.8)
==21325==by 0x408E2F: main (openmpi_valgrind.cpp:5)
==21325==
==21325==
==21325== HEAP SUMMARY:
==21325== in use at exit: 178,754 bytes in 597 blocks
==21325== total heap usage: 6,838 allocs, 6,241 frees, 13,022,326 bytes
allocated
==21325==
==21325== LEAK SUMMARY:
==21325==definitely lost: 42,952 bytes in 54 blocks
==21325==indirectly lost: 10,977 bytes in 21 blocks
==21325== possibly lost: 0 bytes in 0 blocks
==21325==still reachable: 124,825 bytes in 522 blocks
==21325== suppressed: 0 bytes in 0 blocks
==21325== Rerun with --leak-check=full to see details of leaked memory
==21325==
==21325== For counts of detected and suppressed errors, rerun with: -v
==21325== Use --track-origins=yes to see where uninitialised values come from
==21325== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
So either there are memory leaks in OpenMPI that are triggered by that test
program, or the
OpenMPI Valgrind suppression file /usr/share/openmpi/openmpi-valgrind.supp is
not complete.
Upstream, I see that openmpi-valgrind.supp is different between 1.6.5 and
trunk, so perhaps it would
be possible to get a patched openmpi-valgrind.supp in the Debian OpenMPI
package so that valgrind
stops complaining?
The newest one seems to be:
https://svn.open-mpi.org/source/xref/ompi-trunk/contrib/openmpi-valgrind.supp
but my valgrind does not seem happy with that file:
==21821== FATAL: in suppressions file ./openmpi-valgrind.supp near line 95:
==21821==bad or missing extra suppression info
==21821== exiting now.
Best regards
Torquil Sørensen
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.11-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-- 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#732161: ITP: libfile-lchown-perl -- module to modify attributes of symlinks without dereferencing them
Package: wnpp Owner: gregor herrmann gre...@debian.org Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libfile-lchown-perl Version : 0.02 Upstream Author : Paul Evans leon...@leonerd.org.uk * URL : https://metacpan.org/release/File-lchown * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to modify attributes of symlinks without dereferencing them The regular chown system call will dereference a symlink and apply ownership changes to the file at which it points. Some OSes provide system calls that do not dereference a symlink but instead apply their changes directly to the named path, even if that path is a symlink (in much the same way that lstat will return attributes of a symlink rather than the file at which it points). File::lchown provides a wrapper around those system calls. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732159: Should this package be removed?
On Sat, Dec 14, 2013 at 9:28 PM, Moritz Muehlenhoff j...@debian.org wrote: Should this package be removed? If so, please reassign to ftp.debian.org - Last upload nearly two years ago - FTBFS for a long time - Incompatible with current libav - Alternatives exist (mplayer2, mpv) I definitely agree. BTW I'd like to get an opinion from any of the Uploaders first. Cheers! -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd socket activation protocol rationale
I've just been reading sd_listen_fds(3). It's vaguely similar to upstart's socket activation protocol. It supports multiple sockets (which is obviously important). But I have a few questions about the details: Why do only some of the environment variables start SD_ ? We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START. What is the rationale behind the use of the LISTEN_PID variable and the pid check ? It seems to me that at the very least this might make it hard to wrap up a socket-activated daemon in a shell script. I think it would be good, regardless of what the TC decides on the init system question for Debian, for systemd and upstart to converge on a single reasonable protocol. I observe that upstart's UPSTART_FDS, if extended to multiple sockets, would require the daemon to do whitespace-separated parsing to extract the (perhaps noncontiguous) fds. Whereas systemd's two separate variables and use of a contiguous fd range is slightly easier to deal with. AFAICT it might be possible for both daemons to implement both protocols. upstart would have to arrange to make sure that if there were multiple fds they were consecutive. Observations and/or opinions from either upstart or systemd welcome. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732162: build-depends does not mention minimum version for libdrm-dev
Source: intel-vaapi-driver Version: 1.2.1-2 Severity: normal This is shown by configure when run on wheezy system (after updating libva*): configure:13048: checking for DRM configure:13055: $PKG_CONFIG --exists --print-errors libdrm = $LIBDRM_VERSION Requested 'libdrm = 2.4.45' but version of libdrm is 2.4.40 Please specify versioned build-depend for libdrm-dev (=2.4.45). Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd and upstart (mostly docs) bugs submitted
I've been RTFMing upstart and systemd. This has generated a number of bug reports. In case these are at of any interest here's a list. If anything particularly interesting happens in them, I'll mention it. #732127 [n| ] Does setuid also set the group(s) ? It should. #732122 [m| ] semantics of boolean event specification not defined in init(5) #732123 [m| ] usage of stanza not compatible with ordinary English #732125 [m| ] upstart-events(7) title is misleading #732126 [m| ] state machine semantics of initctl restart are unclear #732128 [m| ] Manpages missing cross-references to socket stuff #732130 [m| ] Please document event/job/process environment variables properly #732131 [m| ] Please document apparmor directives #732156 [m| ] Precise documentation for ExecStart command syntax #732157 [w| ] Want SIGSTOP-style daemon/service readiness notification I haven't yet finished with systemd's docs but I'm going to be doing something else today soon so I'll send this mail now. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: systemd and upstart (mostly docs) bugs submitted
Ian Jackson writes (systemd and upstart (mostly docs) bugs submitted): I've been RTFMing upstart and systemd. This has generated a number of bug reports. In case these are at of any interest here's a list. If anything particularly interesting happens in them, I'll mention it. I missed two: #732127 [n|] Does setuid also set the group(s) ? It should. #732122 [m|] semantics of boolean event specification not defined in init(5) #732123 [m|] usage of stanza not compatible with ordinary English #732125 [m|] upstart-events(7) title is misleading #732126 [m|] state machine semantics of initctl restart are unclear #732128 [m|] Manpages missing cross-references to socket stuff #732130 [m|] Please document event/job/process environment variables properly #732131 [m|] Please document apparmor directives #732124 [w|] initctl reload behaviour should be configurable in job file #732132 [w|] Want support for multiple-socket activation #732156 [m|] Precise documentation for ExecStart command syntax #732157 [w|] Want SIGSTOP-style daemon/service readiness notification Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732163: xchat: please support irc:// scheme in browsers, etc
Package: xchat Version: 2.8.8-7.1ubuntu3 Severity: normal Tags: patch Ubuntu has the .desktop file advertise that xchat supports irc:// which makes these urls work in iceweasel [Desktop Entry] Encoding=UTF-8 Name=XChat IRC Name[zh_TW]=網路清談 Comment[de]=IRC-Client Comment[es]=Aplicación de IRC Comment[fi]=IRC-sovellus Comment[fr]=Client IRC Comment[hu]=IRC-kliens Comment[lt]=IRC klientas Comment[no]=IRC-klient Comment[pt_BR]=Cliente de IRC Comment[sl]=Odjemalec IRC Comment[sv]=IRC-klient Comment[ro]=Client de IRC Comment[zh_TW]=X-Chat 聊天程式 Comment=Chat with other people using Internet Relay Chat Exec=sh -c xchat --existing --url %U || exec xchat Icon=xchat Terminal=false Type=Application Categories=Network; StartupNotify=true MimeType=x-scheme-handler/irc;x-scheme-handler/ircs; -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf Kernel: Linux 3.13.0-rc3-00330-gca33675 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xchat depends on: ii libc6 2.17-97 ii libdbus-glib-1-20.100.2-1 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-02.38.1-2 ii libgtk2.0-0 2.24.22-1 ii libpango-1.0-0 1.36.0-1 ii libperl5.18 5.18.1-5 ii libsexy20.1.11-2+b1 ii libssl1.0.0 1.0.1e-4 ii libx11-62:1.6.2-1 ii xchat-common2.8.8-7.1 Versions of packages xchat recommends: ii alsa-utils 1.0.27.2-1 ii libnotify4 0.7.6-1 ii libpython2.7 2.7.6-3 ii tcl8.5 8.5.14-2 pn xchat-indicator none ii xdg-utils1.1.0~rc1+git20111210-7 xchat 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#732159: Should this package be removed?
I've added debian-devel for further input, as I believe the consequences are a bit wider than expected. On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff j...@debian.org wrote: Package: mplayer Severity: serious Should this package be removed? If so, please reassign to ftp.debian.org - Last upload nearly two years ago - FTBFS for a long time - Incompatible with current libav - Alternatives exist (mplayer2, mpv) I tend to agree, however please keep in mind that this also removes mencoder, for which no drop-in alternatives exist atm: Currently, two packages depend on mencoder, toonloop and photofilmstrip: Alexandre Quessy alexan...@quessy.net toonloop (U) Debian Multimedia Maintainers pkg-multimedia-maintain...@lists.alioth.debian.org toonloop Gürkan Sengün gur...@phys.ethz.ch photofilmstrip Jens Göpfert j...@sg-dev.de photofilmstrip (U) Jonas Smedegaard d...@jones.dk toonloop (U) Philipp Huebner debala...@debian.org photofilmstrip (U) If there is general consent that those packages are OK to remove as well, then so be it. Best regards, Reinhard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732157: Fwd: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
forwarding to systemd-devel for discussion -- Forwarded message -- From: Ian Jackson ijack...@chiark.greenend.org.uk Date: Sat, Dec 14, 2013 at 1:05 PM Subject: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification To: sub...@bugs.debian.org Package: systemd Version: 204-5 Severity: wishlist It would be nice if systemd could implement the service supervisor side of the service readiness protocol that upstart calls expect stop: The service doesn't fork, and when considers itself ready it raises SIGSTOP. The supervisor can observe this via the usual mechanisms, being the service's parent, and when it occurs it sends the service CONT and starts whatever was waiting for readiness. The sd_notify(3) protocol is just about tolerable, and it is good that it's documented, but it is quite unattractive for a daemon author: Either they have to add a build- and runtime- dependency on a systemd-specific library, or they have to reimplement a fairly tedious piece of socket code. For a daemon author, raise(SIGSTOP) is lovely and simple. I guess this would be a new Type (but I'm still halfway through the docs so no expert). Ian. ___ Pkg-systemd-maintainers mailing list pkg-systemd-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732157: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
Michael Stapelberg writes (Re: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification): control: forwarded -1 https://bugzilla.redhat.com/show_bug.cgi?id=833105 control: tags -1 + upstream wontfix ... thanks for your mail. This feature request was already raised upstream and upstream decided to not implement it. Please see the provided URL for more details. I'm afraid I find upstream's response there unconvincing. Do you think you might be able to persuade them ? What would your view be as the Debian maintainer, supposing I were to supply a patch to implement the feature - would you be willing to carry the patch ? In case it's helpful I'll respond to upstream's comments there in detail: Lennart Poettering: SIGSTOP is a mechanism for stopping processes, not for notifying service readiness. We shouldn't attempt to overload OS functionality like this, as SIGSTOP might happen for it's real purpose too. This seems far-fetched, certainly during daemon startup. Overloading it for this purpose seems elegant to me. I also fail to see in which way: #include signal.h raise(SIGSTOP); was any simpler than this: #include systemd/sd-daemon.h sd_notify(READY=1); And people can just use the .pc file to add libsystemd-daemon to their build, so that's dead easy. This of course doesn't answer the question about the build- dependency (which as Enrico notes probably involves additional configure tests etc.) Speaking as the author of a daemon, it's really quite unattractive. You (Michael) half-suggest copying libsystemd-daemon's daemon.c into the package source tree, but of course this is (as you evidently recognise) not a very good idea. We should be recommending something good. Another big problem with raise(SIGSTOP) is that if done on an init system that can't handle it will result in a freeze. OTOH sd_notify() handles this gracefully and just becomes a NOP. It seems to me that this would be handled by running the daemon with an argument so that it knows what to expect. By default it will probably call daemon(3), after all, and there'll have to be a way to tell it not do that. So I don't think this is a realistic problem. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730437: network-manager: fails to start
LRN wrote: On 11.12.2013 14:44, Laurent Bigonville wrote: Well, the problem here is the missing NetworkManager-dispatcher.service service file, I've fix this in the git repository[0]. Could you please try to remove the symlink you have created and install this file instead? [0]http://anonscm.debian.org/gitweb/?p=pkg-utopia/network-manager.git;a=commitdiff;h=4f5bce36fa1480b213c770fd4cdcbb35bb954b22 $ sudo apt-get install -t experimental network-manager=0.9.8.8-2 Reading package lists... Done Building dependency tree Reading state information... Done E: Version '0.9.8.8-2' for 'network-manager' was not found So - no, i can't. Also, i am not the original poster, just decided to report here, since NM crashes for me exactly the same way the OP described it, and unlike OP i know how to use gdb. I am, however, somewhat reluctant to install stuff via anything other than dpkg/apt. Well it's a matter of removing the symlink and adding /lib/systemd/system/NetworkManager-dispatcher.service with the following content: [Unit] Description=Network Manager Script Dispatcher Service [Service] Type=dbus BusName=org.freedesktop.nm_dispatcher ExecStart=/usr/lib/NetworkManager/nm-dispatcher.action [Install] Alias=dbus-org.freedesktop.nm-dispatcher.service You might need to run systemctl enable NetworkManager afterwards. This file will be shipped in the next upload, just to confirm it's working for you Cheers Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732156: [Pkg-systemd-maintainers] Bug#732156: Precise documentation for ExecStart command syntax
Hi Ian, Ian Jackson ijack...@chiark.greenend.org.uk writes: Reading systemd.service(5), I'm confused about the exact syntax and quoting for the ExecStart= directive. AFAICT from reading systemd.unit(5), the values in the unit file general syntax are whatever comes after the =, and it is up to the particular directive to specify the interpretation of the RHS. ExecStart talks about multiple commands being separated by semicolons. It also talks about the first argument but it doesn't specify how arguments are split. It tells us that shell syntax is not used. But it provides this example: ExecStart=/bin/sh -c 'dmesg | tac' If that example is correct, something nontrivial must be going on. I think it should be documented. To clarify: the mapping of directives to parsing function happens in http://cgit.freedesktop.org/systemd/systemd/tree/src/core/load-fragment-gperf.gperf.m4?id=9091e686f43184065381aa71929e3df36a4ea2e1#n150 The relevant parsing function is config_parse_exec(): http://cgit.freedesktop.org/systemd/systemd/tree/src/core/load-fragment.c?id=9091e686f43184065381aa71929e3df36a4ea2e1#n433 Arguments are split on WHITESPACE, which is “ \t\n\r”: http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/util.h?id=9091e686f43184065381aa71929e3df36a4ea2e1#n53 I presume changing the wording of systemd.service(5) to read “Commands with their (whitespace-separated) arguments […]” would clarify. Do you agree? If so, I’ll send a patch upstream to change this. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732164: [INTL:da] Danish translation of the debconf templates nsd
Package: nsd Severity: wishlist Tags: l10n patch Please include the attached Danish nsd translations. joe@pc:~/over/debian/nsd$ msgfmt --statistics -c -v -o /dev/null da.poda.po: 3 oversatte tekster. bye Joe da.po.tar.gz Description: GNU Zip compressed data
Bug#727708: systemd socket activation protocol rationale
On Sat, 2013-12-14 at 21:45 +, Ian Jackson wrote: I've just been reading sd_listen_fds(3). It's vaguely similar to upstart's socket activation protocol. It supports multiple sockets (which is obviously important). But I have a few questions about the details: Why do only some of the environment variables start SD_ ? We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START. You misread it: there is no environment variable SD_LISTEN_FDS_START. The API defines the start value as the constant 3. There is a corresponding #define in sd-daemon.h, but it is not communicated at runtime. What is the rationale behind the use of the LISTEN_PID variable and the pid check ? It seems to me that at the very least this might make it hard to wrap up a socket-activated daemon in a shell script. To ensure that the environment values are never accidentally inherited by any child process. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732157: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
Hi Ian, Ian Jackson ijack...@chiark.greenend.org.uk writes: thanks for your mail. This feature request was already raised upstream and upstream decided to not implement it. Please see the provided URL for more details. I'm afraid I find upstream's response there unconvincing. Do you think you might be able to persuade them ? What would your view be as For this particular feature, that seems unlikely to me based on previous discussions. the Debian maintainer, supposing I were to supply a patch to implement the feature - would you be willing to carry the patch ? No. This feature request provides a new API to daemons, which would then only be available on Debian. I think it’s a horrible idea to carry such a patch. I also fail to see in which way: #include signal.h raise(SIGSTOP); was any simpler than this: #include systemd/sd-daemon.h sd_notify(READY=1); And people can just use the .pc file to add libsystemd-daemon to their build, so that's dead easy. This of course doesn't answer the question about the build- dependency (which as Enrico notes probably involves additional configure tests etc.) Speaking as the author of a daemon, it's really quite unattractive. The text you quote speaks about a pkgconfig file. Are you familiar with autotools and pkgconfig in particular? pkgconfig is an elegant mechanism to declare a build dependency (which I also use when I’m not using autotools). Adding a new build dependency to a project using autotools with pkgconfig is _really_ simple. In case a project already declared at least one pkgconfig dependency, it is literally a one-line change :-). You (Michael) half-suggest copying libsystemd-daemon's daemon.c into the package source tree, but of course this is (as you evidently recognise) not a very good idea. We should be recommending something good. Agreed. I’d recommend to just not worry too much about the dependency. Or if you do worry, drop in the file. Or copy the function. With all the implications that approach has :-). Another big problem with raise(SIGSTOP) is that if done on an init system that can't handle it will result in a freeze. OTOH sd_notify() handles this gracefully and just becomes a NOP. It seems to me that this would be handled by running the daemon with an argument so that it knows what to expect. By default it will probably call daemon(3), after all, and there'll have to be a way to tell it not do that. So I don't think this is a realistic problem. Ugh, another argument, just for such a minor feature? Sorry, I’m not at all convinced that your suggestion is more beautiful than what we have right now :-). -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594838: $ evince http://... does not work
Well all I know is I don't use this program anymore. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732159: Should this package be removed?
On 12/14/2013 11:07 PM, Reinhard Tartler wrote: On Sat, Dec 14, 2013 at 4:28 PM, Moritz Muehlenhoff j...@debian.org wrote: Package: mplayer Severity: serious Should this package be removed? If so, please reassign to ftp.debian.org - Last upload nearly two years ago - FTBFS for a long time - Incompatible with current libav - Alternatives exist (mplayer2, mpv) Well, to be honest, I think the problem is actually libav, not mplayer. Most users prefer the original ffmpeg over libav from my own experience. And there are new upstream releases of mplayer which are actually more frequent and active than mplayer2: - mplayer: current stable release 1.1.1, released May 6th, 2013 - mplayer2: current stable release 2.0, released: March 24th, 2011 Even the latest git commit for mplayer2 is older than the current stable release of mplayer. The latter seems much more active to me. So, what I'd rather like to see is that we get a proper ffmpeg back in Debian again which would also allow to update mplayer to the current upstream version. There is even an RFP for that [1]. But I guess this is not going to happen. I'm still a bit sad that the split among the ffmpeg people happened. Adrian [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#727708: systemd socket activation protocol rationale
Hi Ian, [still sending this after Uoti’s reply, because my version has some more detail] Ian Jackson ijack...@chiark.greenend.org.uk writes: Why do only some of the environment variables start SD_ ? We have LISTEN_PID and LISTEN_FDS but SD_LISTEN_FDS_START. SD_LISTEN_FDS_START is a #define from sd-daemon.h, not an environment variable. What is the rationale behind the use of the LISTEN_PID variable and the pid check ? It seems to me that at the very least this might make “In addition we set $LISTEN_PID to the PID of the daemon that shall receive the fds, because environment variables are normally inherited by sub-processes and hence could confuse processes further down the chain” ¹ it hard to wrap up a socket-activated daemon in a shell script. I am not entirely sure what use cases you have in mind, but typically a wrapper script at some point just execs the daemon itself, right? In that case, it’s not a problem. I think it would be good, regardless of what the TC decides on the init system question for Debian, for systemd and upstart to converge on a single reasonable protocol. Helmut Grohne has done some work in that direction², speaking to the relevant people at DebConf 13 in person. I am not entirely sure about the current status of these efforts, maybe Helmut can comment…? ① http://0pointer.de/blog/projects/systemd.html, feature 8 ② https://lists.debian.org/debian-devel/2013/06/msg7.html -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732165: systemd service is disabled after the switch to dh-systemd
Package: avahi-daemon Version: 0.6.31-3 Severity: serious The switch from static symlinks to dh-systemd seems to not be handled properly in 0.6.31-3. After the upgrade the service is no longer started at boot under systemd, thus marking as RC (to prevent testing migration) $ systemctl status avahi-daemon.service avahi-daemon.socket avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service; disabled) Active: inactive (dead) avahi-daemon.socket - Avahi mDNS/DNS-SD Stack Activation Socket Loaded: loaded (/lib/systemd/system/avahi-daemon.socket; disabled) Active: inactive (dead) Listen: /var/run/avahi-daemon/socket (Stream) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages avahi-daemon depends on: ii adduser 3.113+nmu3 ii bind9-host [host]1:9.9.3.dfsg.P2-4 ii dbus 1.6.18-2 ii host 1:9.9.3.dfsg.P2-4 ii init-system-helpers 1.13 ii libavahi-common3 0.6.31-3 ii libavahi-core7 0.6.31-3 ii libc62.17-97 ii libcap2 1:2.22-1.2 ii libdaemon0 0.14-2 ii libdbus-1-3 1.6.18-2 ii libexpat12.1.0-4 ii lsb-base 4.1+Debian12 Versions of packages avahi-daemon recommends: ii libnss-mdns 0.10-3.2 Versions of packages avahi-daemon suggests: ii avahi-autoipd 0.6.31-3 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732156: [Pkg-systemd-maintainers] Bug#732156: Bug#732156: Precise documentation for ExecStart command syntax
On Sat, Dec 14, 2013 at 11:18:55PM +0100, Michael Stapelberg wrote: Hi Ian, Ian Jackson ijack...@chiark.greenend.org.uk writes: Reading systemd.service(5), I'm confused about the exact syntax and quoting for the ExecStart= directive. I've now pushed a patch which expands this section and add a few examples: http://cgit.freedesktop.org/systemd/systemd/commit/?id=ec6039b. I presume changing the wording of systemd.service(5) to read “Commands with their (whitespace-separated) arguments […]” would clarify. Do you agree? If so, I’ll send a patch upstream to change this. We seem to have many question about this, so I think it is good to be very explicit here. Zbyszek -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618273:
This has been marked pending upload for over two and a half years now; has there been any other action regarding Gambit updates? At this point Gambit itself is up to 4.6.9.
Bug#714482: [libsdl2-2.0-0] Programs fail under weston
The wayland support is now in libsdl2: http://hg.libsdl.org/SDL/rev/4fc5f66d63cc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732166: [INTL:da] Danish translation of apt
Package: apt Severity: wishlist Tags: l10n patch Please include the attached Danish apt translation. joe@pc:~/over/debianp/apt$ msgfmt --statistics -c -v -o /dev/null da.po da.po: 617 oversatte tekster. bye Joe da.po.tar.gz Description: GNU Zip compressed data
Bug#727295: Update config.{guess,sub} for AArch64
On Wed, 23 Oct 2013 22:03:14 Matthias Klose wrote:
Update config.{guess,sub} for AArch64
patch at
http://launchpadlibrarian.net/153122132/exiv2_0.23-1_0.23-1ubuntu1.diff.gz
Thanks Matthias,
I prefer to fix via
dh $@ --with autotools_dev
Which should also work for any future archs.
Is that OK from your perspective?
I'll include with the next upload.
Mark
signature.asc
Description: This is a digitally signed message part.
Bug#731594: Re: [pkg-ntp-maintainers] Bug#731594: debian-installer: time synchronisation should be installed by default
On 07/12/13 20:14, Dmitrijs Ledkovs wrote: reassign 731594 openntpd retitle 731594 Please make openntpd package priority standard thanks On 7 December 2013 23:00, Thiemo Nagel thiemo.na...@gmail.com wrote: Hi Bdale, thank you for your input! Using openntpd sounds very good. Who is the person to make the decision? reassigning to openntpd package. Hi. From the openntpd perspective, I think the PROs described are fair, openntpd is extremely small on both, package size and memory footprint (~2mb), and almost no dependences from base system. On a personal note, without my openntpd maintainer hat on, I'm extremely happy with it, I run it on every single server I've root on, 4 of them members of pool.ntp.org. It does what is says it does (now w/patches applied), it's simple but powerful (It can act as servers as well commenting out a single line), and it's almost imperceptible (except in the cases you have a flapping networking connection, like a wireless network). Remember openntpd is NOT an ISC's ntp replacement, it does not provide all the functionalities the second does, but I think It does provide all the required ones with a scope of a ntpdate replacement. On the other hand, and I'm afraid this an extremely important downside for openntpd, even though the OpenNTPd project is quite active, the Portable branch, that is the openntpd software supposed to be used for running on systems other than OpenBSD, is basically stalled on time. I've tried to contact the branch responsible many many times with no success. More over, the current openntpd version present from Wheezy on are running a set of patches that have been prepared back on 2008 by the Portable Branch responsible (upstream), but never committed at upstream software. This reflects the state of staleness upstream is. I want to think I've tried to coordinate efforts with other relevant OpenNTPd consumers (other distros) for requesting some assistance to the OpenNTPd project, but I'm afraid that would be lying because I've not find enough human power to achieve that. I consider this thread is of much importance for the project, although I'm afraid I might not be able to provide a fair judge on this as I don't really know ISC's ntpd well enough to make a fair comparison. Kurt, on the other hand, used to be maintainer of openntpd and he has solid and deep knowledge on both ntp daemons. I trust he would be able to provide a very fair technical advise for this. Cheers, Dererk -- BOFH excuse #318: Your EMAIL is now being delivered by the USPS. signature.asc Description: OpenPGP digital signature
Bug#732167: [INTL:da] Danish translation of debconf
Package: debconf Severity: wishlist Tags: l10n patch Please include the attached Danish debconf translation. joe@pc:~/over/debianp/debconf$ msgfmt --statistics -c -v -o /dev/null da.po da.po: 70 oversatte tekster. bye Joe da.po.tar.gz Description: GNU Zip compressed data
Bug#728936: Bugs #728936, #730789, #731939 are duplicates: no USB input in debian-installer due to missing ohci-pci
Control: tags 728936 d-i Control: tags 730789 d-i Control: severity 728936 serious Control: severity 730789 serious Control: severity 731939 serious Justification: installation not possible with USB keyboard in OHCI port Hi all, On 12.12.2013 19:57, Ben Hutchings wrote: On Thu, Dec 12, 2013 at 06:11:12PM +0100, Andreas Cadhalpun wrote: I noticed one difference between my and Manfred's setup to Jason's: It seems USB input works now on Intel hardware (hadn't worked in the past), but not on AMD hardware (and also not on PowerPC). I seriously doubt that this is the important difference. These bugs are probably duplicates of #730789: the OHCI driver (ohci-pci, previously called ohci-hcd) is missing. I believe that breaks: - All devices in USB 1.x ports (except in systems with UHCI) - Low speed and full speed devices in USB 2.0 ports But these should still work: - High speed devices in USB 2.0 ports (handled by ehci-pci) - All devices in USB 3.0 ports (handled by xhci) Keyboards and mice are generally low speed or full speed, but a keyboard with a built-in hub might be high speed. Ben, I think we both are right, but your observation is more helpful for solving this bug. According to Wikipedia only Intel and VIA use UHCI and all the other (including AMD and PowerPC) use OHCI. I tested five different machines (all Intel, as I currently don't have access to other machines) and indeed all have UHCI. The USB keyboard I used is a Logitech DeLuxe 250. I don't know, whether that is low, full or high speed, but it works with all USB ports/drivers I tested, including uhci_hcd, ehci-pci and xhci_hcd, for example: # lspci -knn | grep -Ei usb|hci 00:1d.0 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #1 [8086:27c8] (rev 01) Kernel driver in use: uhci_hcd 00:1d.1 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #2 [8086:27c9] (rev 01) Kernel driver in use: uhci_hcd 00:1d.2 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #3 [8086:27ca] (rev 01) Kernel driver in use: uhci_hcd 00:1d.3 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB UHCI Controller #4 [8086:27cb] (rev 01) Kernel driver in use: uhci_hcd 00:1d.7 USB controller [0c03]: Intel Corporation NM10/ICH7 Family USB2 EHCI Controller [8086:27cc] (rev 01) Kernel driver in use: ehci-pci 03:00.0 USB controller [0c03]: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller [1912:0014] (rev 03) Kernel driver in use: xhci_hcd 05:01.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] (rev 46) Subsystem: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] Kernel driver in use: firewire_ohci (The OHCI here is a firewire driver (not USB) so this is not related.) I don't know, how many OHCI USB ports are currently in use, but I think that this is not a negligible number, so this bug deserves severity serious, since installation is impossible with USB keyboard in an OHCI port. Since I am not sure, which package needs fixing, I do not (yet) merge the bugs. Is it that the OHCI USB driver is missing in the kernel (in which case it would be a linux bug), or is it just not included in the installer (which would make this a bug in debian-installer)? One thing that I do not understand: What happened on Manfred's machine? He has an Intel PC, so there should be no OHCI around, but still the USB keyboard did not work in the past, although it works fine now. (see bug #715408) To clarify this, Manfred, could you please boot the current testing installer in expert mode and after choosing the language and setting the keyboard layout, switch to the console and report us the output of the following command: # lspci -knn | grep -Ei usb|hci If you still have the installer that failed, please do the same for this installer. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696866: git current (post 0.7) builds almost trivially
I needed post-0.5 to play with the spark.io spark core, which needed :leave support at least; dropping the debian dir into a git clone of upstream, running ./autogen.sh (and doing a dpkg --commit of that, which was probably wrong but I got about 15 seconds into untangling the cdbs autotools support and moved on :-) and it worked fine. So, consider this another ping towards doing a low-effort version bump... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732168: seahorse: drop gnome-doc-utils from Build-Depends
Package: seahorse Version: 3.8.2-1 Tags: patch Usertags: origin-ubuntu ubuntu-patch trusty In Ubuntu, we've applied the attached patch to achieve the following: * debian/control: - Drop Build-Depends on gnome-doc-utils, replaced by yelp-tools. Port to new documentation infrastructure. We thought you might be interested in doing the same diff -pruN -x '*~' seahorse-3.8.2.orig/debian/control seahorse-3.8.2/debian/control --- seahorse-3.8.2.orig/debian/control 2013-05-26 00:09:41.0 +0200 +++ seahorse-3.8.2/debian/control 2013-12-15 01:22:38.0 +0100 @@ -19,7 +19,6 @@ Build-Depends: cdbs (= 0.4.41), libldap2-dev, libavahi-glib-dev (= 0.6), libavahi-client-dev (= 0.6), - gnome-doc-utils, gtk-doc-tools (= 1.9), libgnome-keyring-dev (= 3.0.0), libglib2.0-dev (= 2.10.0), diff -pruN -x '*~' seahorse-3.8.2.orig/debian/control.in seahorse-3.8.2/debian/control.in --- seahorse-3.8.2.orig/debian/control.in 2013-05-26 00:07:32.0 +0200 +++ seahorse-3.8.2/debian/control.in 2013-12-15 01:22:49.0 +0100 @@ -14,7 +14,6 @@ Build-Depends: cdbs (= 0.4.41), libldap2-dev, libavahi-glib-dev (= 0.6), libavahi-client-dev (= 0.6), - gnome-doc-utils, gtk-doc-tools (= 1.9), libgnome-keyring-dev (= 3.0.0), libglib2.0-dev (= 2.10.0),
Bug#728936: Bugs #728936, #730789, #731939 are duplicates: no USB input in debian-installer due to missing ohci-pci
Control: reassign 728936 src:linux Control: reassign 731939 src:linux Control: forcemerge 730789 728936 731939 On Sun, 2013-12-15 at 01:10 +0100, Andreas Cadhalpun wrote: [...] Ben, I think we both are right, but your observation is more helpful for solving this bug. According to Wikipedia only Intel and VIA use UHCI and all the other (including AMD and PowerPC) use OHCI. I thought Intel had switched to OHCI in more recent chipsets, but I must be mistaken. [...] I don't know, how many OHCI USB ports are currently in use, but I think that this is not a negligible number, so this bug deserves severity serious, since installation is impossible with USB keyboard in an OHCI port. Right. Since I am not sure, which package needs fixing, I do not (yet) merge the bugs. Is it that the OHCI USB driver is missing in the kernel (in which case it would be a linux bug), or is it just not included in the installer (which would make this a bug in debian-installer)? [...] Module selection for the intaller is also largely defined by the linux package. Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. signature.asc Description: This is a digitally signed message part
Bug#729998: pu: package gnash/0.8.11~git20120629-1+wheezy1
On Sat, Dec 14, 2013 at 5:31 PM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
On Sat, 2013-12-14 at 15:46 +0100, Gabriele Giacone wrote:
Anything still wrong/missing here?
Someone reviewing the patch, at least.
I've preferred lazy approach: picking upstream git commit as is. IMHO
it's not worth improving it for instance by removing Ifdefs according
to specific wheezy libav{codec,util,format} versions.
I thought it was fine for 7.3.
For it to get in to 7.3 you'd have needed to have uploaded a new
package. I'm not sure how you reach the conclusion of it was fine for
7.3 with no upload having occurred (or being ACKed).
I would have uploaded it once ACKed, as recommended by developer's
reference section 5.5.1.
By it was fine for 7.3, I meant patch wasn't bad and there was
enough time to review, ack, etc..
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732169: musl-bin with /usr/bin/ldd
Package: musl Version: 0.9.14-2 Severity: normal musl's ldd doesn't work unless argv[0] == ldd aka ldd is a symlink to musl -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf Kernel: Linux 3.13.0-rc3-00330-gca33675 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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#732084: RFS: slowhttptest/1.6-1 [ITP] -- Application layer Denial of Service attacks simulation tool
Hi Dmitry, On Sat, Dec 14, 2013 at 11:31 PM, Dmitry Smirnov only...@debian.org wrote: On Sat, 14 Dec 2013 05:30:51 Neutron Soutmun wrote: I am looking for a sponsor for my package slowhttptest Nice, thank you for your work. :) It's my pleasure. I hope you'll forgive me for pedantic nitpicking but let's fix the following minor issues before we upload: * Standards 3.9.4 (expected current version 3.9.5). bumped it, no changes needed. * Needless versioned Build-Depends on debhelper (this exact version is in stable). Besides is there are any features of this particular version is in use? My intention is also to backporting it to sqeeze which running some of my production servers. But I think I could change it to (= 9~) as the squeeze-backports is only providing the 9.20120909~bpo60+1 as of now. * Short package description starts with capital letter (lowercase would be better). fixed it. uploaded to mentors.d.n, please review Best regards, Neutron Soutmun signature.asc Description: PGP signature
Bug#732170: musl: please specify multi-arch:
Package: musl
Version: 0.9.14-2
Severity: normal
musl and musl-dev should support multi-arch: same
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armhf
Kernel: Linux 3.13.0-rc3-00330-gca33675 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-- no debconf information
Source: musl
Section: libs
Priority: extra
Maintainer: Kevin Bortis p...@bortis.ch
Build-Depends: debhelper (=9), dh-exec (=0.6)
Standards-Version: 3.9.4
Homepage: http://www.musl-libc.org/
Vcs-Git: https://github.com/wermut/musl.git
Vcs-Browser: https://github.com/wermut/musl/
Package: musl
Section: libs
Architecture: armel armhf i386 amd64 mips mipsel
Depends: ${misc:Depends}
Multi-arch: same
Description: standard C library
musl is lightweight, fast, simple, free and strives
to be correct in the sense of standards-conformance
and safety.
.
This package contains the shared objects
Package: musl-dev
Section: libdevel
Architecture: armel armhf i386 amd64 mips mipsel
Multi-arch: same
Depends: ${misc:Depends}, musl (= ${binary:Version})
Provides: libc-dev
Description: standard C library development files
musl is lightweight, fast, simple, free and strives
to be correct in the sense of standards-conformance
and safety.
.
This package contains the static linked libraries
and the include files.
Package: musl-tools
Section: devel
Architecture: armel armhf i386 amd64 mips mipsel
Multi-arch: none
Depends: ${misc:Depends}, musl-dev (= ${binary:Version}),
gcc (= 4.7.2)
Description: standard C library tools
musl is lightweight, fast, simple, free and strives
to be correct in the sense of standards-conformance
and safety.
.
This package contains the gcc spec file and the
musl-gcc wraper script to make easy-to-deploy static
and minimally dynamic linked programs.
Bug#732171: musl-tools: profile $TRIPLET-gcc, ie arm-linux-musleabihf-gcc on armhf
Package: musl-tools Version: 0.9.14-2 Severity: normal this would make dpkg-buildpackage [-afoo] work out of the box -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf Kernel: Linux 3.13.0-rc3-00330-gca33675 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages musl-tools depends on: ii gcc 4:4.8.1-3 ii musl-dev 0.9.14-2 musl-tools recommends no packages. musl-tools 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#725589:
tags 725589 + patch Repackaging the tarball with no changes should be enough to fix this.
Bug#731672: uim-gtk3: uim systray not appearing in gnome shell
Unfortunately I am unable to report the exact version of gnome-shell, other than say it was working properly up to (and including I guess) the 3.6 series. I discovered this bug after a clean reinstall of debian testing. Cheers On Sunday, December 15, 2013 1:20 AM, d...@debian.org d...@debian.org wrote: Control: forwarded -1 https://github.com/uim/uim/issues/34 Control: tags -1 + moreinfo On Sun, Dec 08, 2013 at 05:02:42PM +0900, Marios Sioutis wrote: under gnome-shell 3.8.4 the uim systray is not showing in the notification bar. Specifically, uim-toolbar-gtk3-systray is not showing up. Other systray icons (e.g. dropbox, skype, redshift, steam) show up properly. confirmed. The uim systray would also show up on previous versions of gnome shell, but since other systray icons show up properly I decided to report the bug here. could you tell me exact versions for previous versions of gnome shell? -- Regards, dai GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E
Bug#728527: Openbox 3.5.2-5 patched
Hello, First I want to thank you for the hard work you are doing with packaging and working on improving the packages. I am an Openbox exclusive user and I do appreciate a lot having it, as well as the latest available versions. I would only like to say I think it was a mistake to remove this part: # Run the XDG autostart stuff. These are found in /etc/xdg/autostart and # in $HOME/.config/autostart. This requires PyXDG to be installed. # See openbox-xdg-autostart --help for more details. /usr/lib/openbox/openbox-xdg-autostart $@ from the end of the file /usr/lib/i386-linux-gnu/openbox-autostart. Instead, I think it would have been better to remove the part you have added in /etc/xdg/openbox/autostart in a previous version: if [ $DESKTOP_SESSION != 'gnome' ]; then DESKTOP_ENV=OPENBOX if which /usr/lib/i386-linux-gnu/openbox-xdg-autostart /dev/null; then /usr/lib/i386-linux-gnu/openbox-xdg-autostart $DESKTOP_ENV fi fi * The main reason for me to think it was not right to do it this way is that there is another script which belongs to the Openbox package, which acts before /usr/lib/i386-linux-gnu/openbox-autostart and before /etc/xdg/openbox/autostart. It is /usr/bin/openbox-session, which starts /usr/lib/i386-linux-gnu/openbox-autostart, as you can see on lines 21 and 22: * # Run Openbox, and have it run the autostart stuff exec /usr/bin/openbox --startup /usr/lib/i386-linux-gnu/openbox-autostart OPENBOX $@ * Another reason (maybe not the best one) why I think the two files should be restored as they used to be, is it seems to me that the files which are under /etc/xdg/openbox/ are mostly meant to be used as templates for the users to make their own configuration. I am attaching two patches in case you agree with the above statement. Best regards, Mélodie --- a-autostart 2013-12-15 03:19:04.044647590 +0100 +++ b-autostart 2013-12-15 03:18:45.642503820 +0100 @@ -6,8 +6,8 @@ # If you want to use GNOME config tools... # -#if test -x /usr/lib/i386-linux-gnu/gnome-settings-daemon /dev/null; then -# /usr/lib/i386-linux-gnu/gnome-settings-daemon +#if test -x /usr/lib/openbox/gnome-settings-daemon /dev/null; then +# /usr/lib/openbox/gnome-settings-daemon #elif which gnome-settings-daemon /dev/null 21; then # gnome-settings-daemon #fi @@ -15,10 +15,3 @@ # If you want to use XFCE config tools... # #xfce-mcs-manager - -if [ $DESKTOP_SESSION != 'gnome' ]; then -DESKTOP_ENV=OPENBOX -if which /usr/lib/i386-linux-gnu/openbox-xdg-autostart /dev/null; then - /usr/lib/i386-linux-gnu/openbox-xdg-autostart $DESKTOP_ENV -fi -fi --- a-openbox-autostart 2013-12-15 03:17:29.347437215 +0100 +++ b-openbox-autostart 2013-12-15 03:16:56.892869864 +0100 @@ -27,3 +27,8 @@ elif test -f $AUTOSTART.sh; then sh $AUTOSTART.sh fi + +# Run the XDG autostart stuff. These are found in /etc/xdg/autostart and +# in $HOME/.config/autostart. This requires PyXDG to be installed. +# See openbox-xdg-autostart --help for more details. +/usr/lib/openbox/openbox-xdg-autostart $@
Bug#732172: ITP: os-apply-config -- Creates config files out of cloud metadata
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand z...@debian.org
* Package name: os-apply-config
Version : 0.1.1
Upstream Author : OpenStack Development Mailing List
openstack-...@lists.openstack.org
* URL : https://github.com/openstack/os-apply-config
* License : Apache-2.0
Programming Lang: Python
Description : Creates config files out of cloud metadata
os-apply-config apply configuration out of the cloud metadata (JSON) that it
recieves from a metadata server.
.
It turns metadata from one or more JSON files like this:
.
{keystone:
{database:
{host: 127.0.0.1, user: keystone, password: foobar}
}
}
.
into service config files like this:
.
[sql]
connection = mysql://keystone:foobar@127.0.0.1/keystone
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732173: ITP: python-os-collect-config -- collect and cache metadata, run hooks on changes
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-os-collect-config Version : 0.1.1 Upstream Author : OpenStack Development Mailing List openstack-...@lists.openstack.org * URL : http://github.com/openstack/os-collect-config * License : Apache-2.0 Programming Lang: Python Description : collect and cache metadata, run hooks on changes os-collect-config collects collects data from defined configuration sources and runs a defined hook whenever the metadata has changed. You must define what sources to collect configuration data from in os-collect-config configuration file at /etc/os-collect-config/sources.ini. These sources will be polled and whenever any of them changes, default.command will be run. A file will be written to the cache dir, os_config_files.json, which will be a json list of the file paths to the current copy of each metadata source. This list will also be set as a colon separated list in the environment variable OS_CONFIG_FILES for the command that is run. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732084: RFS: slowhttptest/1.6-1 [ITP] -- Application layer Denial of Service attacks simulation tool
On Dec 15, 2013 9:03 AM, Neutron Soutmun neo.neut...@gmail.com wrote: Hi Dmitry, On Sat, Dec 14, 2013 at 11:31 PM, Dmitry Smirnov only...@debian.org wrote: On Sat, 14 Dec 2013 05:30:51 Neutron Soutmun wrote: I am looking for a sponsor for my package slowhttptest Nice, thank you for your work. :) It's my pleasure. I hope you'll forgive me for pedantic nitpicking but let's fix the following minor issues before we upload: * Standards 3.9.4 (expected current version 3.9.5). bumped it, no changes needed. * Needless versioned Build-Depends on debhelper (this exact version is in stable). Besides is there are any features of this particular version is in use? My intention is also to backporting it to sqeeze which running some of my production servers. But I think I could change it to (= 9~) as the squeeze-backports is only providing the 9.20120909~bpo60+1 as of now. * Short package description starts with capital letter (lowercase would be better). fixed it. uploaded to mentors.d.n, please review Hi It's missing '/gitweb' in Vcs-Browser field. Cheers, Prach
Bug#732174: pppoeconf: [INTL:ja] updated Japanese debconf translation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: pppoeconf Severity: wishlist Tags: l10n patch Version: 1.21 Hi, I updated Japanese translation of debconf messages (ja.po). Please apply this. Thanks, - -- Kenshi Muto km...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.9 http://mailcrypt.sourceforge.net/ iQIcBAEBCgAGBQJSrSXxAAoJEB0hyD3EUuD8rz8P/1Uys5b7DJmIhbkIbloRI7lj iKMMBEKr5j/fo7gigE+/sGibICfb+5G8Gj5tWgsHjxM68N3ArEg9JZ/89GTYbSIe bAgdXzbWH2LRlwLMQrcNFs8RQ7Bd10e9mcq4fG+DHDwzFrsvMbxYj4q7Gi3BujvV VmSzf+c6LOgyrbNvNdIi4AgX33GMlj/9YRT1RoY7sghZk8VdqQhR+I91/qC9nqAL dLMA/w/2zuMQMhxC71OqvVy8SRN7J3cjjmiymz+6q5ByRoeQj5r13eeruYBnFFg0 XvxL44jbl6mgokvF/sHqECRfagHYZsjLEnsfEER+O24QCtlqUVCEGWDAsbhLd2fb mODFd1bB7NKWyrH27seiIEsCYWOJvhZPXlZwbcDt1eV1U5kG9arqp+E19EIvt9o4 d7GwTJiDbmDjmWUD72hrIf/FhBod/am2zMPkjEWQC9e9ZuaXQ/hJxzi4S08lh2Wh 0ELLWulGsoAtE3zga0iokT+wTv9BTP2x1EUHezeXi+g4nmsda9rXiEDQB5OzQYyu Z9t9Is98W6HAAmhoTPlhk2UuBvOYW+HURJeTn5n66Ox59lSHdVsOqFmvZ/nrKwkN e5JK1dPkl7TFE0gdsTMJjL4E/3KW55micz8/ezpFaDZbYq0hFnT4YkqhHFm9+gLT eVfi5RFnG13RyneAHVqm =R9Hy -END PGP SIGNATURE- ja.po Description: Binary data
Bug#732157: [systemd-devel] Fwd: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
On Sat, Dec 14, 2013 at 11:19 PM, Shawn Landden sh...@churchofgit.com wrote: It would be nice if systemd could implement the service supervisor side of the service readiness protocol that upstart calls expect stop: The service doesn't fork, and when considers itself ready it raises SIGSTOP. The supervisor can observe this via the usual mechanisms, being the service's parent, and when it occurs it sends the service CONT and starts whatever was waiting for readiness. The sd_notify(3) protocol is just about tolerable, and it is good that it's documented, but it is quite unattractive for a daemon author: Either they have to add a build- and runtime- dependency on a systemd-specific library, or they have to reimplement a fairly tedious piece of socket code. For a daemon author, raise(SIGSTOP) is lovely and simple. I guess this would be a new Type (but I'm still halfway through the docs so no expert). No, it's not lovely, it's a very cheap and very bad hack. These signals are for admins and not for system management tools; just the same way ptrace is the very wrong tool to track startup behavior of services. It is just so wrong to things like that, and systemd should not do that. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732084: RFS: slowhttptest/1.6-1 [ITP] -- Application layer Denial of Service attacks simulation tool
On Sun, 15 Dec 2013 14:38:48 Prach Pongpanich wrote: It's missing '/gitweb' in Vcs-Browser field. Yeah, well spotted, it is a broken URL indeed. It should be Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/slowhttptest.git -- All the best, Dmitry Smirnov. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579790: apt: should use selections instead of --force-* options
Control: reassign -1 apt Control: retitle -1 apt: should use selections instead of --force-* options [ This is actually something I've had in my list of things to discuss with frontends, so here it goes, through a bug report. :) ] On Sat, 2010-07-17 at 06:59:38 -0500, Jonathan Nieder wrote: Moritz Beyreuther wrote: /usr/bin/dpkg --status-fd 11 --force-depends --force-remove-essential --remove courier-mta courier-base courier-authdaemon courier-authlib-userdb courier-authlib However courier-authlib is deinstalled first which breaks the deinstallation process as explained in 579790. exim is being installed to replace courier-mta as mail-transfer-agent. As you mentioned, bsd-mailx depends on an mta, so there is apparently no clean way to do this and the frontend passes a --force-* option. So now from the point of view of dpkg we are outside the realm of policy and in my opinion no matter what happens it is not going to be intuitive. There is a way around that, which is to use the --auto-deconfigure option. It should be able to produce a saner sequence of operations: 1. deconfigure everything that needs an mta 2. remove courier-mta 3. remove the packages courier-mta depended on Nope, the correct way to go about this is to setup a “dpkg transaction” through selections, which tells explicitly to dpkg what can be done, avoids the extra scary message from dpkg, gets a better result, minimizes the time packages have been forced out of the way, and avoids --force-* options. In this case apt would do, the equivalent of: # cat TRANS | dpkg --set-selections courier-mta deinstall courier-base deinstall courier-authdaemon deinstall courier-authlib-userdb deinstall courier-authlib deinstall TRANS # dpkg --auto-deconfigure --install exim*.deb # dpkg --remove --pending or something similar. In general apt should really not be forcing removals on dpkg, it should tell dpkg what packages are fine to remove, and then do a final remove, that would also reduce the number of transactions needed for an upgrade. The only --force option that a frontend should be “justified” to use at all is --force-remove-essential, only when the user has acknowledged that explicitly through a prompt or similar, and only then, not passed blindly on all invocations. In general, any time a frontend is using a --force option, there's something wrong going on. Using selections is how dselect has managed to work all this time w/o the need for any --force option at all. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732175: ogmtools: ogmcat not mentioned in the package description
Package: ogmtools Version: 1:1.5-3+b1 Severity: minor ogmcat is not mentioned in the package description. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717722: [Pkg-chromium-maint] Bug#717722: chromium: Unable to print with lpr gtk-print-backend set
Hi Mike, On Fri, Dec 13, 2013 at 05:58:08PM -0500, Michael Gilbert wrote: On Fri, Dec 13, 2013 at 4:04 AM, Salvatore Bonaccorso wrote: Control: unarchive -1 Hi Mike Thanks a lot for having included this in chromium-browser in unstable. Do you see a chance of it having it also included in one future upload for wheezy? (If Stable release managers agree obviously). I think that would be fine, but I'll leave it up to you to work it through the release team. Note that doing an spu for chromium may be more work than usual due to the frequency of security updates. Thanks a lot for the positive feedback. Sure I'm going to work that trough with he release team. If they agree to let such a change in, I will notify you again (and then can be included in one of the upcoming security updates). Regards, Salvatore signature.asc Description: Digital signature
