Bug#757899: mirror listing update for mirrors.ocf.berkeley.edu
Package: mirrors Severity: minor Submission-Type: update Site: mirrors.ocf.berkeley.edu Type: leaf Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc Archive-ftp: /debian/ Archive-http: /debian/ Archive-rsync: debian/ CDImage-ftp: /debian-cd/ CDImage-http: /debian-cd/ CDImage-rsync: debian-cd/ IPv6: no Archive-upstream: mirrors.kernel.org CDImage-upstream: mirrors.kernel.org Updates: four Maintainer: Chris Kuehl cku...@ocf.berkeley.edu Country: US United States Location: Berkeley, California Sponsor: Open Computing Facility http://ocf.berkeley.edu/ Comment: Adding debian-cd to existing mirror -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754931: one more fixed nvidia-support typo, add patch tag
On Mon, Aug 11, 2014 at 9:07 AM, Anders Jonsson anders.jons...@norsjovallen.se wrote: tags 754931 +patch thanks I noticed that this bug was not marked with patch, apparently the control server did not receive an e-mail earlier. Also sending an updated po file. The only change from Martin's is that it changes one more Noveau to the correct Nouveau. Thanks for the patch! I'll group this with some other i18n patches and upload this before the freeze. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757875: [INTL:tr] Turkish debconf template translation for nvidia-support
On Mon, Aug 11, 2014 at 2:20 PM, Mert Dirik mertdi...@gmail.com wrote: Package: nvidia-support Severity: wishlist Tags: l10n patch Please find the attached Turkish translation of nvidia-support debconf messages. This file should be put as debian/po/tr.po in your build tree. Thanks for the patch! I'll group this with some other i18n patches and upload this before the freeze. Regards, Vincent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751144: has_expired returns integer
On 12 August 2014 16:11, Brian May br...@microcomaustralia.com.au wrote: pyopenssl has_expired() seems to return an Integer instead of a Boolean, which is confusing trying to understand why celery's tests fail. Sorry, I meant to say this problem appears to be fixed in the latest upstream version. -- Brian May br...@microcomaustralia.com.au
Bug#751144: has_expired returns integer
Hello, Any progress on getting the latest version of pyopenssl in Debian? I see this package is has python-modules-t...@lists.alioth.debian.org as an uploader. If no response, I will fix this bug and #751893 myself. pyopenssl has_expired() seems to return an Integer instead of a Boolean, which is confusing trying to understand why celery's tests fail. Thanks -- Brian May br...@microcomaustralia.com.au
Bug#754441: VCS Created
I've just created a repo on pkg-gnustep. You can find it here: git+ssh://your_alioth_usern...@scm.alioth.debian.org//git/pkg-gnustep/pkg-gmastermind.app.git I've also added corresponding Vcs-Git: and Vcs-Browser: fields in d/control. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742037: gstreamer0.10-ffmpeg: 686 days old; stuck in Sid since forever
Package: gstreamer0.10-ffmpeg Version: 0.10.13-5 Followup-For: Bug #742037 Jessie will ship with Iceweasel (= 30) which has Gstreamer 1.0 support. Thus, would a solution be to concentrate FFMPEG porting efforts on 1.0, rather than on 0.10 Gstreamer? Can we produce 1.0 modules with new AV? -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (1001, 'testing'), (1001, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.16-trunk-686-pae (SMP w/1 CPU core) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gstreamer0.10-ffmpeg depends on: ii libavcodec53 6:0.8.12-1 ii libavformat536:0.8.12-1 ii libavutil51 6:0.8.12-1 ii libc62.19-7 ii libglib2.0-0 2.40.0-3 ii libgstreamer-plugins-base0.10-0 0.10.36-1.1 ii libgstreamer0.10-0 0.10.36-1.3 ii liborc-0.4-0 1:0.4.21-1 ii libpostproc526:0.git20120821-4 ii libswscale2 6:10.3-1 gstreamer0.10-ffmpeg recommends no packages. gstreamer0.10-ffmpeg 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 Archive: https://lists.debian.org/debian-bugs-dist
Bug#505608: runit: stopped runsv processes not responding to TERM signals
On Mon, Aug 11, 2014 at 06:52:33PM +, Gerrit Pape wrote: In your case the log service is still running, and so runsv is still waiting for it. The best solution is to make your log service detect that stdin is closed and exit as there's no more data to log. Hm. The log service of cereal makes heavy use of shell redirection: #!/bin/sh -e # The cereal scripts were written by # Jameson Graef Rollins jroll...@finestructure.net # and # Daniel Kahn Gillmor d...@fifthhorseman.net. # # They are Copyright 2007, and are all released under the GPL, version 3 # or later. exec 21 SHAREDIR=/usr/share/cereal export SHAREDIR . $SHAREDIR/common LOGUSER=$(cat ../env/LOGUSER) LOGGROUP=$(cat ../env/LOGGROUP) check_user $LOGUSER check_group $LOGGROUP exec chpst -u $LOGUSER:$LOGGROUP svlogd -tt ./main ../socket I guess that this was written with the old documented behavior in mind. Reassigning this bug to cereal. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757897: Fwd: [Python-modules-team] Bug#757897: FTBFS: self.assertFalse(Certificate(CERT1).has_expired()) fails
-- Forwarded message -- From: Brian May br...@microcomaustralia.com.au Date: 12 August 2014 15:59 Subject: Re: [Python-modules-team] Bug#757897: FTBFS: self.assertFalse(Certificate(CERT1).has_expired()) fails To: Debian Bug Tracking System sub...@bugs.debian.org On 12 August 2014 15:05, Brian May br...@microcomaustralia.com.au wrote: == FAIL: test_has_expired (celery.tests.security.test_certificate.test_Certificate) -- Traceback (most recent call last): File /«PKGBUILDDIR»/celery/tests/security/test_certificate.py, line 26, in test_has_expired self.assertFalse(Certificate(CERT1).has_expired()) AssertionError: 1L is not false On a hunch, I tried installing the latest python-openssl (see https://bugs.debian.org/751144), now I get: == FAIL: test_has_expired (celery.tests.security.test_certificate.test_Certificate) -- Traceback (most recent call last): File /home/brian/tree/debian/unstable/celery/celery/celery/tests/security/test_certificate.py, line 28, in test_has_expired self.assertFalse(Certificate(CERT1).has_expired()) AssertionError: True is not false -- The certificate expired Jul 24 12:11:14 2014, so I think the test is faulty. This seems to be further confused by the fact that python-openssl in Debian returns 1L instead of True. -- Brian May br...@microcomaustralia.com.au -- Brian May br...@microcomaustralia.com.au
Bug#716119: Reproduced
Hi Martin, On Mon, Aug 11, 2014 at 06:43:13PM +0200, Martin Steghöfer wrote: Can be reproduced with simpler data than the one provided by mayhem, e.g.: mast:~$ mincdump http://abcdeeef/ Segmentation fault (core dumped) mast:~$ mincdump file:/ Segmentation fault (core dumped) mast:~$ mincdump file:o/ Segmentation fault (core dumped) mast:~$ mincdump file:o/a Segmentation fault (core dumped) mast:~$ mincdump file:/// Segmentation fault (core dumped) mast:~$ mincdump file:// Segmentation fault (core dumped) I've looked into it and it seems that netcdf is to blame for the problem. I'm gonna file a bug there. thanks for your work on this. Any hint / patch would be really welcome. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757900: libappindicator3-1: Recommends non-existing indicator-application
Package: libappindicator3-1 Version: 0.4.92-3 Severity: normal Dear maintainer, Jessie does not ship indicator-application that libappindicator3-1 Recommends. You therefore might want to look into revising this package's dependencies. Cheers! Martin-Éric -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (1001, 'testing'), (1001, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.16-trunk-686-pae (SMP w/1 CPU core) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libappindicator3-1 depends on: ii libatk1.0-0 2.12.0-1 ii libc62.19-7 ii libcairo-gobject21.12.16-2 ii libcairo21.12.16-2 ii libdbusmenu-glib40.6.2-1 ii libdbusmenu-gtk3-4 0.6.2-1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgtk-3-0 3.12.2-1+b1 ii libindicator3-7 0.5.0-2 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 Versions of packages libappindicator3-1 recommends: pn indicator-application none libappindicator3-1 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 Archive: https://lists.debian.org/debian-bugs-dist
Bug#756810: linux-image-3.16-rc6-armmp: HDMI on wandboard/cubox-i no longer works
On 2014-08-11, Vagrant Cascadian wrote: I think this is caused by dropping CONFIG_DRM_IMX_IPUV3_CORE=m, which was moved out of staging into drivers/gpu/ipu-v3/Kconfig. And the configuration option was also renamed to CONFIG_IMX_IPUV3_CORE... I've tested that the following patch on a Cubox-i works: diff --git a/config/armhf/config.armmp b/config/armhf/config.armmp index 2e9343e..8c2ce84 100644 --- a/config/armhf/config.armmp +++ b/config/armhf/config.armmp @@ -191,6 +191,11 @@ CONFIG_DRM_I2C_NXP_TDA998X=m CONFIG_DRM_TILCDC=m ## +## file: drivers/gpu/ipu-v3/Kconfig +## +CONFIG_IMX_IPUV3_CORE=m + +## ## file: drivers/hwspinlock/Kconfig ## CONFIG_HWSPINLOCK_OMAP=m live well, vagrant pgpPvg5aIxh64.pgp Description: PGP signature
Bug#505608: runit: stopped runsv processes not responding to TERM signals
On Tue, Aug 12, 2014 at 08:30:05AM +0200, Marc Haber wrote: Reassigning this bug to cereal. There is already a corresponding bug against cereal (#485599), so this bug can accordingly be closed. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757901: tclthread: aolserver application crashes with libthread error
Package: tclthread Version: 1:2.6.5-4 Severity: important Dear Maintainer, an aolserver4 application wont start: Warning: modload: could not find Ns_ModuleInit in /usr/lib/tcltk/thread2.6.7/libthread2.6.7.so Fatal: modload: failed to load module '/usr/lib/tcltk/thread2.6.7/libthread2.6.7.so' Only with tclthread_2.6.5-4_i386.deb from squeeze the application could start again -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (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/bash Versions of packages tclthread depends on: ii libc6 2.13-38+deb7u3 ii tcl 8.5.0-2.1 ii tcl8.4 [tclsh] 8.4.19-5 ii tcl8.5 [tclsh] 8.5.11-2 tclthread recommends no packages. tclthread 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#716119: Reproduced
El 12/08/14 a les 08:41, Andreas Tille ha escrit: thanks for your work on this. Any hint / patch would be really welcome. Kind regards Andreas. I submitted a bug report with a proposed patch to the netcdf package yesterday: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757884 In my opinion netcdf is to blame - although, from the netcdf point of view, you could argue that the URIs have to be checked (in mincdump) for valid form before passing them on. However, their documentation doesn't say anything about it. They also *try* to check the validity during parsing, but fail in some cases. So I think the parsing in netcdf is the place to fix this (see my patch submitted there). Cheers, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757891: init-system-helpers: Please do not depend on perl
Hi Samuel, Samuel Thibault sthiba...@debian.org writes: perl is separate from perl-base so that in tight environement, Debian can be installed with only perl-base. A base system installed by d-i, notably, is supposed to only install perl-base, not perl. It happens however that d-i installs rsyslog, which depends on init-system-helpers, which depends on perl. Is the whole perl really needed? If some modules are needed, they could be moved to perl-base, to save having to install the whole perl on all Debian base systems. init-system-helpers uses File::Path, File::Basename, File::Find and Text::ParseWords — none of them is in perl-base. Please report back once you’ve made perl-base contain all of them. -- 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#753065: FTBFS with clang instead of gcc
Thanks. I'll review this and discuss with upstream. // Ola On Sun, Jun 29, 2014 at 12:04 AM, Alexander sanek23...@gmail.com wrote: Package: vzquota Severity: minor Tags: patch User: pkg-llvm-t...@lists.alioth.debian.org Usertags: clang-ftbfs Hello, Using the rebuild infrastructure, your package fails to build with clang (instead of gcc). We detected this kinf of error: http://clang.debian.net/status.php?version=3.4.2key=SOMETIMES_UNINITIALIZED Full build log is available here: http://clang.debian.net/logs/2014-06-16/vzquota_3.1-1_unstable_clang.log Thanks, Alexander -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comAnnebergsslingan 37\ | o...@debian.org 654 65 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Bug#757894: lava-server: [INTL:es] Spanish translation of debconf messages
Quoting Matias A. Bellone (matiasbellone+deb...@gmail.com): Source: lava-server Severity: wishlist Tags: l10n patch Dear Maintainer, You will find attached a compressed file that contains the translation to Spanish of lava-server's debconf messages. Content-Type contained an invalid encoding utf-8T value. Thus, the PO file is invalid and noot used. The attached file fixes this. es.po Description: application/gettext signature.asc Description: Digital signature
Bug#742037: gstreamer0.10-ffmpeg: 686 days old; stuck in Sid since forever
2014-08-12 10:10 GMT+03:00 Sebastian Dröge sl...@coaxion.net: On Di, 2014-08-12 at 09:26 +0300, Martin-Éric Racine wrote: Package: gstreamer0.10-ffmpeg Version: 0.10.13-5 Followup-For: Bug #742037 Jessie will ship with Iceweasel (= 30) which has Gstreamer 1.0 support. Thus, would a solution be to concentrate FFMPEG porting efforts on 1.0, rather than on 0.10 Gstreamer? Can we produce 1.0 modules with new AV? Yes, see the gstreamer1.0-libav package. Is there anything preventing us from building gstreamer1.0-ffmpeg packages then? Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-dist
Bug#757902: [xbomb] Program aborts with SIGSEGV
Package: xbomb Version: 2.2a-3 Severity: grave Program doesn't start but aborts with SIGSEGV: xbomb XBomb Version 2.2a (c) Andrew M. Bishop 1994-2009. [a...@gedanken.demon.co.uk] Speicherzugriffsfehler Reinhard --- System information. --- Architecture: amd64 Kernel: Linux 3.16-trunk-amd64 Debian Release: jessie/sid 500 unstabledebian 500 testing debian 500 stable deb.opera.com 101 experimentaldebian --- Package information. --- Depends (Version) | Installed ===-+-=== libc6 (= 2.4) | libx11-6| libxaw7 | libxt6 | Package's Recommends field is empty. Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748386: [Pkg-running-devel] Bug#748386: subsurface: diff for NMU version 4.0.3-2.1
Quoting Tobias Frost (t...@debian.org): tags 748386 + pending thanks Dear maintainer, I've prepared an NMU for subsurface (versioned as 4.0.3-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Thanks for your work (as pkg-running team member, I leave priority to Sylvestre Ledru, who is probably busy elsewhere...which explains why nothing happened with that issue). I included the NMU changes to our git repository and tagged the release, so please push the NMU the DELAYED/0..or let's just wait for 5 days...:-) signature.asc Description: Digital signature
Bug#485599: looking for reasons why runsv and run linger after cereal session is destroyed
On Fri, Jan 09, 2009 at 12:27:34PM -0500, Daniel Kahn Gillmor wrote: I was trying to look into this further, and i suspect the problem has something to do with the file i/o shennanigans we're doing to work around screen's inability to log to an existing file descriptor. What i find is that when i attach a strace to the lingering run process, it immediately terminates with the following output (sorry about the line wrap): 0 dkg@pip:~$ sudo strace -p 24909 Process 24909 attached - interrupt to quit open(../socket, O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) write(2, ./run: 23: ..., 11) = 11 write(2, cannot open ../socket: No such fi..., 35) = 35 write(2, \n..., 1)= 1 exit_group(2) = ? Process 24909 detached 0 dkg@pip:~$ The socket has been deleted by the session destruction, of course -- i think we're seeing some sort of race condition between runsv bringing the service back up and cereal-admin removing the entire directory. Sorry this isn't more conclusive yet, but i wanted to document what i'd found. I _think_ that this might be a documentation issue in runsv(8). It now says: x Exit. If the service is running, send it a TERM signal, and then a CONT signal. Do not restart the service. If the service is down, and no log service exists, runsv exits. If the service is down and a log service exists, runsv closes the standard input of the log service, and waits for it to terminate. If the log service is down, runsv exits. This command is ignored if it is given to service/log/supervise/control. And to me it looks like the shell script that is the log service does not handle the clsoed stdin. But I am not an expert in shell scripts that make so intensive use of redirection. #505608 against runit might givi more insight. In older versions of runit, this part of the documentation was significantly different and did not mention that runit waits for the log service to terminate voluntarily. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742037: gstreamer0.10-ffmpeg: 686 days old; stuck in Sid since forever
On Di, 2014-08-12 at 09:26 +0300, Martin-Éric Racine wrote: Package: gstreamer0.10-ffmpeg Version: 0.10.13-5 Followup-For: Bug #742037 Jessie will ship with Iceweasel (= 30) which has Gstreamer 1.0 support. Thus, would a solution be to concentrate FFMPEG porting efforts on 1.0, rather than on 0.10 Gstreamer? Can we produce 1.0 modules with new AV? Yes, see the gstreamer1.0-libav package. signature.asc Description: This is a digitally signed message part
Bug#742037: gstreamer0.10-ffmpeg: 686 days old; stuck in Sid since forever
On Di, 2014-08-12 at 10:13 +0300, Martin-Éric Racine wrote: 2014-08-12 10:10 GMT+03:00 Sebastian Dröge sl...@coaxion.net: On Di, 2014-08-12 at 09:26 +0300, Martin-Éric Racine wrote: Package: gstreamer0.10-ffmpeg Version: 0.10.13-5 Followup-For: Bug #742037 Jessie will ship with Iceweasel (= 30) which has Gstreamer 1.0 support. Thus, would a solution be to concentrate FFMPEG porting efforts on 1.0, rather than on 0.10 Gstreamer? Can we produce 1.0 modules with new AV? Yes, see the gstreamer1.0-libav package. Is there anything preventing us from building gstreamer1.0-ffmpeg packages then? You mean building gst-libav against ffmpeg instead of libav? No, unless ffmpeg has a different API than libav v10 there should be no problem. signature.asc Description: This is a digitally signed message part
Bug#757777: [udev] Fails to Load Also snd-seq
On Monday 11 August 2014 17:17:30 Marco d'Itri wrote: On Aug 11, David Baron d_ba...@012.net.il wrote: But if sysvinit is still operational, I can place a fallback boot item with init= for that and try that first. If OK, no problem to upgrade the rest and be done. Please just upgrade. Upgraded successfully, rebooted without a hitch with systemd 208-7. snd-seq was indeed modprobed successfully without any workaround. Can close, but with note about this interdependence of systemd and udev which might not have been all-around the best idea. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755212: closed by Emilio Pozuelo Monfort po...@debian.org (Re: Bug#755212: transition: protobuf-c)
On 12/08/14 03:11, Robert Edmonds wrote: Hi, I think the transition is not quite over; there is still #756422, which blocks #755212. We need a sourceful upload of collectd in order to rebuild (or possibly remove) the .pb-c.[ch] files in the collectd-dev package, which is an Architecture: all package. I would be happy to NMU collectd, BTW... Great, then do it :) https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu has the guidelines: if you only fix the RC bug, you could upload directly without going through the delayed queue. Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757805: linux: linux-3.14.13/drivers/gpu/drm/i915/intel_panel.c:696 i9xx_enable_backlight+0xd4/0x100 [i915]()
On Mon, Aug 11, 2014 at 17:46:55 +0300, Martin-Éric Racine wrote: 2014-08-11 16:56 GMT+03:00 maximilian attems m...@stro.at: On Mon, Aug 11, 2014 at 04:30:01PM +0300, Martin-Éric Racine wrote: Package: src:linux Version: 3.14.13-2 Severity: normal File: linux While debugging something else, I found the following in syslog: can you reproduce with latest 3.16 (should be in exp). Yes, I can. See attached kernel oops dump. Please report this upstream following the instructions at https://01.org/linuxgraphics/documentation/how-report-bugs Thanks, Julien signature.asc Description: Digital signature
Bug#757763: the proposed fix solves the issue
Hi, Adding the journalmatch statement in an [Init] section indeed did work. Some hosts were properly banned during the night as per jail configuration. One remaining issue concerns the mail notyfying about the ban. My jail.d/jail.local is configured with: action = %(action_mwl)s so I get a mail when some IP is banned. With the systemd configuration, the journal is properly used to detect the errors and trigger the ban, but the mail contains a final empty section with : Lines containing IP:130.0.174.58 in /var/log/mail.warn So the mail reporting code is not aware of systemd and journal. best regards, Luc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757903: syslog-ng-core: invoke-rc.d: initscript syslog-ng, action stop failed.
Package: syslog-ng-core Version: 3.5.6-1 Severity: grave Justification: renders package unusable Today the upgrade from 3.5.5-2 to 3.5.6-1 failed with: | Processing triggers for syslog-ng-core (3.5.6-1) ... | Job for syslog-ng.service canceled. | invoke-rc.d: initscript syslog-ng, action stop failed. | dpkg: error processing package syslog-ng-core (--configure): | subprocess installed post-installation script returned error exit status 1 Uncommenting invoke-rc.d syslog-ng stop || exit $? in line 6 of the postinst script and running apt install -f fixes the issue and lets the installation complete. I've also seen this issue while installing syslog-ng-core for the first time on another system. Both systems are running systemd if that matters. Let me know if you want more info. My other system waits to be upgraded. Cheers -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (650, 'unstable'), (601, 'testing'), (600, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-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 syslog-ng-core depends on: ii init-system-helpers 1.20 ii libc62.19-7 ii libcap2 1:2.24-4 ii libevtlog0 0.2.12-6 ii libglib2.0-0 2.40.0-4 ii libivykis0 0.36.2-1 ii libnet1 1.1.6+dfsg-3 ii libpcre3 1:8.35-3 ii libssl1.0.0 1.0.1i-2 ii libsystemd-daemon0 208-7 ii libwrap0 7.6.q-25 ii util-linux 2.20.1-5.8 Versions of packages syslog-ng-core recommends: ii logrotate 3.8.7-1 Versions of packages syslog-ng-core suggests: pn syslog-ng-mod-amqp none pn syslog-ng-mod-geoipnone iu syslog-ng-mod-json 3.5.6-1 iu syslog-ng-mod-mongodb 3.5.6-1 pn syslog-ng-mod-redisnone pn syslog-ng-mod-smtp none iu syslog-ng-mod-sql 3.5.6-1 pn syslog-ng-mod-stompnone -- no debconf information -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#742037: gstreamer0.10-ffmpeg: 686 days old; stuck in Sid since forever
2014-08-12 10:29 GMT+03:00 Sebastian Dröge sl...@coaxion.net: On Di, 2014-08-12 at 10:13 +0300, Martin-Éric Racine wrote: 2014-08-12 10:10 GMT+03:00 Sebastian Dröge sl...@coaxion.net: On Di, 2014-08-12 at 09:26 +0300, Martin-Éric Racine wrote: Package: gstreamer0.10-ffmpeg Version: 0.10.13-5 Followup-For: Bug #742037 Jessie will ship with Iceweasel (= 30) which has Gstreamer 1.0 support. Thus, would a solution be to concentrate FFMPEG porting efforts on 1.0, rather than on 0.10 Gstreamer? Can we produce 1.0 modules with new AV? Yes, see the gstreamer1.0-libav package. Is there anything preventing us from building gstreamer1.0-ffmpeg packages then? You mean building gst-libav against ffmpeg instead of libav? No, unless ffmpeg has a different API than libav v10 there should be no problem. Not quite what I meant. We currently have a Gstreamer0.10-ffmpeg that is stuck in Sid because it won't build against recent libav. Do we have something to produce a Gstreamer1.0-ffmpeg against current libav? There's hardly any software that explictly needs Gstreamer 0.10 left in Jessie, so we could pretty much let the whole Gstreamer 0.10 stack go, if that's the case. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-dist
Bug#757891: init-system-helpers: Please do not depend on perl
Michael Stapelberg [2014-08-12 9:02 +0200]: Samuel Thibault sthiba...@debian.org writes: perl is separate from perl-base so that in tight environement, Debian can be installed with only perl-base. A base system installed by d-i, notably, is supposed to only install perl-base, not perl. It happens however that d-i installs rsyslog, which depends on init-system-helpers, which depends on perl. Is the whole perl really needed? If some modules are needed, they could be moved to perl-base, to save having to install the whole perl on all Debian base systems. init-system-helpers uses File::Path, File::Basename, File::Find and Text::ParseWords — none of them is in perl-base. I'm in a similar situation with postgresql-common. It only uses perl-base, and I replaced things like the above with plain perl code (very simple for Basename, a bit more involved for ParseWords), or with calling programs (for Find). Would that be acceptable for you? I can look into this. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.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#755872: maint-guide.fr
Hi Andrei, Osamu, Please find attached the update of the maint-guide French documentation translation, proofread by the debian-l10n-french mailing list contributors. Kind regards. -- Jean-Paul fr.po.xz Description: application/xz
Bug#755839: libidn: run dh-autoreconf to update config.{sub, guess} and {libtool, aclocal}.m4
You wrote: I just submitted a comment on mentors.d.n. Thank you! I am aware of them, but wanted to do as minimal changes to the packaging as possible to fix bugs at this point. The packaging should really be rewritten using dh instead, but that's a larger task and I don't want to do it now just before the freeze. Apart from that, I noticed that the package also involves Java. Frankly, I am a bit wary of touching this area, since I never touched other packages with Java before, and so I am completely unaware of the policies in this respect -- I am not very comfortable sponsoring that. There are no changes in this area, so you are not making it any worse :-) Hopefully I'll regain upload rights within a week or two (I got one @debian.org signature, just need another one) and can take care of this. Are there not other team members or co-maintainer Aníbal active, that can take a look and upload the package? Anibal, if you have time to look at the package that would be great. I'll get to it eventually otherwise. /Simon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742037: gstreamer0.10-ffmpeg: 686 days old; stuck in Sid since forever
On Di, 2014-08-12 at 10:46 +0300, Martin-Éric Racine wrote: 2014-08-12 10:29 GMT+03:00 Sebastian Dröge sl...@coaxion.net: On Di, 2014-08-12 at 10:13 +0300, Martin-Éric Racine wrote: 2014-08-12 10:10 GMT+03:00 Sebastian Dröge sl...@coaxion.net: On Di, 2014-08-12 at 09:26 +0300, Martin-Éric Racine wrote: Package: gstreamer0.10-ffmpeg Version: 0.10.13-5 Followup-For: Bug #742037 Jessie will ship with Iceweasel (= 30) which has Gstreamer 1.0 support. Thus, would a solution be to concentrate FFMPEG porting efforts on 1.0, rather than on 0.10 Gstreamer? Can we produce 1.0 modules with new AV? Yes, see the gstreamer1.0-libav package. Is there anything preventing us from building gstreamer1.0-ffmpeg packages then? You mean building gst-libav against ffmpeg instead of libav? No, unless ffmpeg has a different API than libav v10 there should be no problem. Not quite what I meant. We currently have a Gstreamer0.10-ffmpeg that is stuck in Sid because it won't build against recent libav. Do we have something to produce a Gstreamer1.0-ffmpeg against current libav? There's hardly any software that explictly needs Gstreamer 0.10 left in Jessie, so we could pretty much let the whole Gstreamer 0.10 stack go, if that's the case. gstreamer1.0-libav is exactly what you mean then. It's just renamed from -ffmpeg to -libav as upstream also switched to libav as default. signature.asc Description: This is a digitally signed message part
Bug#752681: laptop-mode-tools: The new runtime-pm management is enabled in more situations than usb-autosuspend
On 08/11/2014 09:34 PM, Zoltan Hidvegi wrote: Blacklisting will work. Try it. It works for me. Yes, blacklisting does work, but the problem is that the default behavior of the system has changed in a very undesirable way, and it's very hard for a non-expert to figure out how to fix it. On every optical mouse I've came across (several different manufacturers) the autosuspend works by turning off the mouse LED. After that the mouse stays suspended until a button is pressed, which wakes up the mouse and turns the LED back on but it goes to sleep again after the prescribed autosuspend delay. This is a new an unexpected behavior, and although I consider myself an experienced expert user, it took a long time to find the source of the problem as I also run into the no longer used usb-autosuspend module that is still there giving you a false hope that you can fix it there. A possible solution would be to allow a blacklist based on the product name (found in the product file in /sys/bus/usb/devices/*/product) and look for something like *Optical*Mouse* in the product name to blacklist. It would be nice if optical mice would behave as before, since that's what most people would prefer and expect. Where do you want to draw the line ? Why not the same for USB keyboard ? Or any other device. The reason we leave it to the defaults is so that the user has the flexibility to choose on his own. Will everyone be aware of doing it. Probably not. But is whitelisting it, is the solution ? Giving user the choice is the best solution in my opinion. Certainly we can improve this situation by writing a GUI, or a separate wrapper. But where would you want it ? And not all users want the GUI. Give me your thoughts, which are generic and distro agnostic. There are also issues in the /usr/share/laptop-mode-tools/modules/runtime-pm script, it assumes that the $runtime_device variable does not contain spaces. Unfortunately, on my system there is a file called /sys/bus/platform/devices/Fixed MDIO bus.0 Note the spaces in the name. The shell by default does word splitting on variables. All uses of $runtime_device should be quoted (and not only that but also any function that takes such a device as an argument should handle names with spaces), list the blacklisted, whichlisted, listed_by_id, listed_by_type etc. functions, they all use unquoted variables at the moment. Unfortunately to support names with spaces, the script probably needs some more invasive changes. The current module gives me error messages like: sirius /home/hzoli # service laptop-mode reload /usr/sbin/laptop_mode: 108: [: /sys/bus/platform/devices/Fixed: unexpected operator /usr/sbin/laptop_mode: 115: [: /sys/bus/platform/devices/Fixed: unexpected operator /usr/sbin/laptop_mode: 118: [: /sys/bus/platform/devices/Fixed: unexpected operator [ ok ] Laptop mode disabled, not active. /usr/sbin/laptop_mode: 108: [: /sys/bus/platform/devices/Fixed: unexpected operator /usr/sbin/laptop_mode: 115: [: /sys/bus/platform/devices/Fixed: unexpected operator /usr/sbin/laptop_mode: 118: [: /sys/bus/platform/devices/Fixed: unexpected operator [ ok ] Laptop mode enabled, not active. These come from line 108 of /usr/share/laptop-mode-tools/modules/runtime-pm not /usr/sbin/laptop_mode -Zoltan Hmmm!! I'll look into this some time. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Bug#748386: [Pkg-running-devel] Bug#748386: subsurface: diff for NMU version 4.0.3-2.1
On Tue, 2014-08-12 at 09:19 +0200, Christian PERRIER wrote: Quoting Tobias Frost (t...@debian.org): tags 748386 + pending thanks Dear maintainer, I've prepared an NMU for subsurface (versioned as 4.0.3-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Thanks for your work (as pkg-running team member, I leave priority to Sylvestre Ledru, who is probably busy elsewhere...which explains why nothing happened with that issue). I included the NMU changes to our git repository and tagged the release, so please push the NMU the DELAYED/0..or let's just wait for 5 days...:-) Ok, just pushed to DELAYED/0. Thanks for the feeback :) -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757887: systemd: kdm don't start
On Tue, Aug 12, 2014 at 01:08:39AM +0200, Michael Biebl wrote: Am 12.08.2014 00:31, schrieb Jaroslav Mikulík: Package: systemd Version: 208-6 Severity: normal Dear Maintainer, * What led up to the situation? After recent upgrade to systemd, kdm on my machine don't start (4 core CPU). Strange that on older machine (1 core CPU) is kdm started OK. * What exactly did you do (or not do) that was effective (or ineffective)? In kdm.log I found this error: klauncher(1841) kdemain: No DBUS session-bus found. Check if you have started the DBUS server. kdeinit4: Communication error with launcher. Exiting! kdmgreet(1780)/kdecore (K*TimeZone*): KSystemTimeZones: ktimezoned initialize() D-Bus call failed: Not connected to D-Bus server When KDM is started on manualy after boot, then it started OK. Please remove the workaround from /etc/rc.local. Then boot adding the following to the kernel command line: systemd.log_level=debug After that, attach the journalctl -alb to this bug report. I had the same problem with kdm (or at least very similar, don't remember the exact error message). I made a native systemd unit file which fixes the problem for me. Jaroslav, if you want to try it, it's at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754314 (unfortunately w/o any feedback from KDE maintainers since 5 weeks) 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#756103: systemd should be more forgiving of fstab errors
On Lu, 11 aug 14, 23:53:54, Michael Biebl wrote: Am 11.08.2014 23:35, schrieb Andrei POPESCU: I have been thinking about this incident since then and watching all the system doesn't boot due to fstab errors reports (I'm subscribed to both -user and -pkg-systemd-maintainers). I'm not sure it's a good idea to just fail the boot completely whenever there are errors like mine in fstab, but instead it would be much friendlier if systemd would try to bring up as much of the system as possible and start the emergency console only if e.g. / and /usr are missing. I already commented on that. I think it's wrong to just continue booting and starting potentially critical services. How is systemd supposed to know which file systems are vital? It can't, of course (nor should it), unless receiving enough information from the admin, but see below. You might have database on separate partitions and you might risk losing data if the services are started but the partitions aren't available. I understand these concerns, however: 1. it seems very brittle to me that a wrong fstab entry is capable of blocking the entire boot. This will be mitigated once emergency mode is fixed, but still won't be much comfort for headless systems. 2. sysv-rc would not stop either, so this would not be a regression Another possibility would be if admins could designate specific filesystems as critical for booting with a fstab parameter like 'bootwait', where systemd stops if that particular filesystem couldn't be mounted. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Bug#757781: hunspell-da: Parse errors in dictionary
Control: reassign -1 hunspell-da On Lu, 11 aug 14, 12:05:10, Morten Bo Johansen wrote: Source: hunspell-da Severity: important Trying to produce e.g. a list of misspelled words with hunspell and the Danish dicitionary (hunspell-da) spews out a lot of lines like this: ~/ % hunspell -l file.txt error: line 6787: 0 is wrong flag id error: line 10034: 0 is wrong flag id error: line 10034: 0 is wrong flag id error: line 11351: 0 is wrong flag id error: line 11351: 0 is wrong flag id error: line 11849: 0 is wrong flag id [...] in line 6787 of the dictionary (da_DK.dic) I see the line A/Sas/70,9,976 in line 10034 bel/, in line 28718 E-post/,941,947 These are all parse errors to hunspell. Thanks, Morten -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.14-2-686-pae (SMP w/2 CPU cores) Locale: LANG=da_DK.utf8, LC_CTYPE=da_DK.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Bug#754314: systemd support for kdm
Hi, On Thu, Jul 17, 2014 at 05:17:23PM +0200, Moritz Muehlenhoff wrote: On Mon, Jul 14, 2014 at 06:34:40PM +0200, Moritz Mühlenhoff wrote: On Wed, Jul 09, 2014 at 10:16:07PM +0200, Moritz Muehlenhoff wrote: Source: kde-workspace Severity: wishlist Tags: patch activation of the service - After installation of the updated package the service isn't enabled by default. You'll need to run systemctl enable kdm.service for that. I'm not sure how the default display manager is handled if several systemd units are installed, so it's probably for the best right now. Michael Stapelberg explained to me that the unit file needs an additional WantedBy=multi-user.target which would resolve this. This doesn't seem to be sufficient, I still need to enable the service manually ATM. This issue was discussed during the systemd/GNOME sprint this spring. I.e. how the display-manager.service symlink is supposed to be managed when multiple display managers are installed. lightdm and gdm3 are already updated to support this scheme, so I'm bringing their maintainers into the loop here. Please coordinate with them when adding systemd support to kdm. Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757820: jack2d: FTBFS with clang instead of gcc
Control: reassign -1 src:jack2d
On Lu, 11 aug 14, 10:43:33, Arthur Marble wrote:
Package: jack2d
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs
Hello,
Using the rebuild infrastructure, your package fails to build with clang
(instead of gcc).
Detected this kind of error:
http://clang.debian.net/status.php?version=3.5.0rc1key=UNDEF_REF
Full build log is available here:
http://clang.debian.net/logs/2014-08-05/jackd2_1.9.10+20140719git3eb0ae6a~dfsg-1_unstable_clang.log
Thanks,
Arthur
-- System Information:
Debian Release: jessie/sid (unstable)
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-2-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Compiler: Debian clang version 3.5.0-+rc1-2 (tags/RELEASE_35/rc1) (based on
LLVM 3.5.0)
diff -Naur
jackd2.orig/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/changelog
jackd2/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/changelog
--- jackd2.orig/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/changelog
2014-08-11 10:34:38.112057125 -0500
+++ jackd2/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/changelog
2014-08-11 10:37:12.588059815 -0500
@@ -1,3 +1,10 @@
+jackd2 (1.9.10+20140719git3eb0ae6a~dfsg-2) unstable; urgency=medium
+
+ * Fix FTBFS with clang
+- Fixed undefined reference error
+
+ -- Arthur Marble art...@info9.net Mon, 11 Aug 2014 10:37:12 -0500
+
jackd2 (1.9.10+20140719git3eb0ae6a~dfsg-1) unstable; urgency=medium
* Imported Upstream version 1.9.10+20140719git3eb0ae6a~dfsg
diff -Naur
jackd2.orig/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/clang-ftbfs.diff
jackd2/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/clang-ftbfs.diff
---
jackd2.orig/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/clang-ftbfs.diff
1969-12-31 18:00:00.0 -0600
+++
jackd2/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/clang-ftbfs.diff
2014-08-11 10:36:10.908058741 -0500
@@ -0,0 +1,11 @@
+--- a/common/memops.c
b/common/memops.c
+@@ -198,7 +198,7 @@ static inline __m128i float_24_sse(__m12
+ */
+ static unsigned int seed = 2;
+
+-inline unsigned int fast_rand() {
++static inline unsigned int fast_rand() {
+ seed = (seed * 96314165) + 907633515;
+ return seed;
+ }
diff -Naur
jackd2.orig/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/series
jackd2/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/series
--- jackd2.orig/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/series
2014-08-11 10:34:38.112057125 -0500
+++ jackd2/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/series
2014-08-11 10:34:57.068057455 -0500
@@ -1 +1,2 @@
waf.patch
+clang-ftbfs.diff
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
signature.asc
Description: Digital signature
Bug#757827: python3-rsa: should depend on python3-pyasn1
Control: reassign -1 python3-rsa 3.1.4-1 On Lu, 11 aug 14, 18:26:22, Leo Antunes wrote: Source: python3-rsa Version: 3.1.4-1 Severity: important Dear Maintainers, The current version of python3-rsa in sid does not depend on python3-pyasn1 and is therefore unusable unless you install it manually. Cheers -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Bug#757848: file descriptors leaked when executing script
Control: reassign -1 wide-dhcpv6-client 20080615-12
On Lu, 11 aug 14, 21:24:58, Michael Stapelberg wrote:
Source: wide-dhcpv6-client
Version: 20080615-12
Severity: normal
I am running wide-dhcpv6-client on my Ubiquiti EdgeRouter ERLITE-3
(which takes the package from Debian, and the version is 20080615-12,
i.e. current testing).
I am using this “script”:
#!/bin/sh
/etc/init.d/radvd restart
exit 0
I noticed that after stopping wide-dhcpv6-client, I could not start it
again. It would always complain about not being able to bind:
bind(6, {sa_family=AF_INET6, sin6_port=htons(5546), inet_pton(AF_INET6,
::1, sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRINUSE
(Address already in use)
write(2, Aug/11/2014 19:01:13: dhcp6_ctl_init: bind(control sock): Address
already in use\n, 81) = 81
It seemed strange to me that ::1:5546 was already in use, but netstat
-anp identified radvd as having that port open. Since radvd’s code does
not ever open that port, I checked its file descriptors, and it turns
out that radvd indeed inherited the file descriptors from
wide-dhcpv6-client, including the listening port and the configuration
file file descriptor.
In order to prevent this bug, wide-dhcpv6-client should use the CLOEXEC
option on all its file descriptors.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: armel
i386
Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
signature.asc
Description: Digital signature
Bug#742037: gstreamer0.10-ffmpeg: 686 days old; stuck in Sid since forever
2014-08-12 10:52 GMT+03:00 Sebastian Dröge sl...@coaxion.net: On Di, 2014-08-12 at 10:46 +0300, Martin-Éric Racine wrote: 2014-08-12 10:29 GMT+03:00 Sebastian Dröge sl...@coaxion.net: On Di, 2014-08-12 at 10:13 +0300, Martin-Éric Racine wrote: 2014-08-12 10:10 GMT+03:00 Sebastian Dröge sl...@coaxion.net: On Di, 2014-08-12 at 09:26 +0300, Martin-Éric Racine wrote: Package: gstreamer0.10-ffmpeg Version: 0.10.13-5 Followup-For: Bug #742037 Jessie will ship with Iceweasel (= 30) which has Gstreamer 1.0 support. Thus, would a solution be to concentrate FFMPEG porting efforts on 1.0, rather than on 0.10 Gstreamer? Can we produce 1.0 modules with new AV? Yes, see the gstreamer1.0-libav package. Is there anything preventing us from building gstreamer1.0-ffmpeg packages then? You mean building gst-libav against ffmpeg instead of libav? No, unless ffmpeg has a different API than libav v10 there should be no problem. Not quite what I meant. We currently have a Gstreamer0.10-ffmpeg that is stuck in Sid because it won't build against recent libav. Do we have something to produce a Gstreamer1.0-ffmpeg against current libav? There's hardly any software that explictly needs Gstreamer 0.10 left in Jessie, so we could pretty much let the whole Gstreamer 0.10 stack go, if that's the case. gstreamer1.0-libav is exactly what you mean then. It's just renamed from -ffmpeg to -libav as upstream also switched to libav as default. OK. Good to know. Is it a drop-in replacement for the older -ffmpeg? i.e. will Iceweasel be able to play H.264 media content with it? Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-dist
Bug#757890: cups 1.7.4-4 fails to install failed socket: Cannot assign requested address
Control: tags -1 +moreinfo Le lundi, 11 août 2014, 19.34:57 ant a écrit : when trying to install cups, aptitude reports errors and fails to install: Sockets. Aug 11 19:13:50 ant systemd[1]: cups.socket failed to listen on sockets: Cannot assign requested address Do you have IPv6 enabled? Can you enable it and try to complete the installation; what do you get? (This is probably #747073) Cheers, OdyX -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757234: xul-ext-https-everywhere: update Debian rules from master and my patches
Paul Wise: I've been submitting changes to the rules for debian.org/debian.net as DSA add more SSL-enabled domains[1]. I'm not sure if upstream will make a release containing them in time for the jessie release so I thought I would submit a diff against 3.5.3 so we can at least have recent Debian rules. My most recent patch hasn't yet been accepted but I guess it will since previous ones were accepted. The attached patch includes the patch that hasn't yet been accepted upstream, hopefully that is OK. Thanks for the patch. Upstream is going to release 4.0.0 real soon, so I'll make sure Debian rules are right when updating the package. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#757501: [INTL:tr] Turkish debconf template translation for vidalia
Control: tag -1 + pending Mert Dirik wrote (08 Aug 2014 19:50:16 GMT) : Please find the attached Turkish translation of vidalia debconf messages. This file should be put as debian/po/tr.po in your build tree. Thanks, applied in Git! Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757891: init-system-helpers: Please do not depend on perl
Hi Martin, Martin Pitt mp...@debian.org writes: I'm in a similar situation with postgresql-common. It only uses perl-base, and I replaced things like the above with plain perl code (very simple for Basename, a bit more involved for ParseWords), or with calling programs (for Find). Would that be acceptable for you? I can look into this. Thanks for your offer, but I’m not interested in crippling my code or duplicating functionality. That’s what these Perl modules are there for, and they are not non-standard at all. -- 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#757891: init-system-helpers: Please do not depend on perl
Control: clone -1 -2 Control: reassign -2 perl-base Control: retitle -2 perl-base: Please include File::Path, File::Basename, File::Find, Text::ParseWords Michael Stapelberg, le Tue 12 Aug 2014 09:02:59 +0200, a écrit : It happens that d-i installs rsyslog, which depends on init-system-helpers, which depends on perl. Is the whole perl really needed? If some modules are needed, they could be moved to perl-base, to save having to install the whole perl on all Debian base systems. init-system-helpers uses File::Path, File::Basename, File::Find and Text::ParseWords — none of them is in perl-base. Please report back once you’ve made perl-base contain all of them. Well, it's not me to be convinced, but the perl-base maintainers. Please discuss it with them. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742037: gstreamer0.10-ffmpeg: 686 days old; stuck in Sid since forever
On Di, 2014-08-12 at 11:50 +0300, Martin-Éric Racine wrote: 2014-08-12 10:52 GMT+03:00 Sebastian Dröge sl...@coaxion.net: On Di, 2014-08-12 at 10:46 +0300, Martin-Éric Racine wrote: 2014-08-12 10:29 GMT+03:00 Sebastian Dröge sl...@coaxion.net: On Di, 2014-08-12 at 10:13 +0300, Martin-Éric Racine wrote: 2014-08-12 10:10 GMT+03:00 Sebastian Dröge sl...@coaxion.net: On Di, 2014-08-12 at 09:26 +0300, Martin-Éric Racine wrote: Package: gstreamer0.10-ffmpeg Version: 0.10.13-5 Followup-For: Bug #742037 Jessie will ship with Iceweasel (= 30) which has Gstreamer 1.0 support. Thus, would a solution be to concentrate FFMPEG porting efforts on 1.0, rather than on 0.10 Gstreamer? Can we produce 1.0 modules with new AV? Yes, see the gstreamer1.0-libav package. Is there anything preventing us from building gstreamer1.0-ffmpeg packages then? You mean building gst-libav against ffmpeg instead of libav? No, unless ffmpeg has a different API than libav v10 there should be no problem. Not quite what I meant. We currently have a Gstreamer0.10-ffmpeg that is stuck in Sid because it won't build against recent libav. Do we have something to produce a Gstreamer1.0-ffmpeg against current libav? There's hardly any software that explictly needs Gstreamer 0.10 left in Jessie, so we could pretty much let the whole Gstreamer 0.10 stack go, if that's the case. gstreamer1.0-libav is exactly what you mean then. It's just renamed from -ffmpeg to -libav as upstream also switched to libav as default. OK. Good to know. Is it a drop-in replacement for the older -ffmpeg? i.e. will Iceweasel be able to play H.264 media content with it? Yes signature.asc Description: This is a digitally signed message part
Bug#757904: linuxinfo: [l10n:cs] Initial Czech translation of linuxinfo
Package: linuxinfo Version: 1.9.1 Severity: wishlist Tags: l10n patch Dear Maintainer, In attachment there is initial Czech translation (cs.po) of package linuxinfo, please include it. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash # Czech translation of linuxinfo. # Copyright (C) 2014 Michal Simunek michal.simu...@gmail.com # This file is distributed under the same license as the linuxinfo package. # Michal Simunek michal.simu...@gmail.com, 2014. # msgid msgstr Project-Id-Version: linuxinfo 1.9.1\n Report-Msgid-Bugs-To: Helge Kreutzmann deb...@helgefjell.de\n POT-Creation-Date: 2013-12-06 21:10+0100\n PO-Revision-Date: 2014-08-12 09:15+0200\n Last-Translator: Michal Simunek michal.simu...@gmail.com\n Language-Team: Czech debian-l10n-cz...@lists.debian.org\n Language: cs\n MIME-Version: 1.0\n Content-Type: text/plain; charset=utf-8\n Content-Transfer-Encoding: 8bit\n Plural-Forms: nplurals=3; plural=n==1 ? 0 : n=2 n=4 ? 1 : 2;\n #: linuxinfo.c:50 msgid Unknown msgstr Neznámé #: linuxinfo.c:50 msgid One msgstr Jeden #: linuxinfo.c:50 msgid Two msgstr Dva #: linuxinfo.c:50 msgid Three msgstr Tři #: linuxinfo.c:50 msgid Four msgstr Čtyři #: linuxinfo.c:50 msgid Five msgstr Pět #: linuxinfo.c:50 msgid Six msgstr Šest #: linuxinfo.c:50 msgid Seven msgstr Sedm #: linuxinfo.c:50 msgid Eight msgstr Osm #: linuxinfo.c:50 msgid Nine msgstr Devět #: linuxinfo.c:50 msgid Ten msgstr Deset #: linuxinfo.c:50 msgid Eleven msgstr Jedenáct #: linuxinfo.c:50 msgid Twelve msgstr Dvanáct #: linuxinfo.c:74 #, c-format msgid -h print this help\n msgstr -h zobrazí tuto nápovědu\n #: linuxinfo.c:75 #, c-format msgid -v print linuxinfo version\n msgstr -v zobrazí verzi linuxinfo\n #: linuxinfo.c:82 #, c-format msgid Unsupported option or file %s not found.\n msgstr Nepodporovaná volba nebo nebyl nalezen soubor %s.\n #: linuxinfo.c:91 #, c-format msgid Could not open %s.\n msgstr Nelze otevřít %s.\n #: linuxinfo.c:115 #, c-format msgid processor msgid_plural processors msgstr[0] procesor msgstr[1] procesory msgstr[2] procesorů #: linuxinfo.c:116 #, c-format msgid , %s total bogomips, %sM RAM\n msgstr , %s total bogomips, %sM RAM\n #: linuxinfo.c:123 #, c-format msgid System library %s\n msgstr Systémová knihovna %s\n #: linuxinfo_common.c:137 #, c-format msgid Could not stat /proc/meminfo, result can be inaccurate\n msgstr Nelze vyhodnotit /proc/meminfo, výsledek může být nepřesný\n
Bug#757906: Dependency solution problems currently with gnuplog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: apt Version: 1.0.6 Severity: normal I have the both packages, gnuplot-nox and gnuplot-x11, installed with version 4.6.5-6. The new version of that packages are 4.6.5-10 but conflicting each other. Now comes the problem. With any apt-get dist-upgrade, apt is installing the packages aglfn, gnuplot-data und gnuplot-tex (as they are in the dependencies of the packages version 4.6.5-10 but not as dependencies of version 4.6.5-6. The funny think is that I get informed with the same command that installs that packages, that they are going to get deinstalled with a autoremove as they are not needed. That game comes up now with every upgrade cycle (daily). I see two or tree solutions for this problem: - - Just take only the installable packages in consideration when resolving dependencies. That would not update gnuplot-nox and/or gnuplot-x11 but would not install and deinstall the dependencies of newer package every time. - - Pick one out of the conflicting packages to keep and upgrade and deinstall the other. That would be not the best solution but at least allows to update them. The user can choose afterwards to install the other package. (Maybe taking the one that has the least dependencies.) - - Inform the user clearly _why_ they are not updated. At the moment it only shows that they have been kept back but not for what reason. With this packages it is just annoying and maybe is not good for SSDs as they would wear out. But for other packages that problem can get really problematic so I think it should be solved. This problem will comes into sever state when gnuplot (in this case) with that version will be stable in future. It will end with systems not fully upgraded to newer stable releases. - -- Package-specific info: - -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends false; APT::Install-Suggests 0; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image-3\.13\.11$; APT::NeverAutoRemove:: ^linux-image-3\.15\.6$; APT::NeverAutoRemove:: ^linux-headers-3\.13\.11$; APT::NeverAutoRemove:: ^linux-headers-3\.15\.6$; APT::NeverAutoRemove:: ^linux-image-extra-3\.13\.11$; APT::NeverAutoRemove:: ^linux-image-extra-3\.15\.6$; APT::NeverAutoRemove:: ^linux-signed-image-3\.13\.11$; APT::NeverAutoRemove:: ^linux-signed-image-3\.15\.6$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.13\.11$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.15\.6$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.13\.11$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.15\.6$; APT::NeverAutoRemove:: ^gnumach-image-3\.13\.11$; APT::NeverAutoRemove:: ^gnumach-image-3\.15\.6$; APT::NeverAutoRemove:: ^.*-modules-3\.13\.11$; APT::NeverAutoRemove:: ^.*-modules-3\.15\.6$; APT::NeverAutoRemove:: ^.*-kernel-3\.13\.11$; APT::NeverAutoRemove:: ^.*-kernel-3\.15\.6$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.13\.11$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.15\.6$; APT::NeverAutoRemove:: ^linux-tools-3\.13\.11$; APT::NeverAutoRemove:: ^linux-tools-3\.15\.6$; APT::VersionedKernelPackages ; APT::VersionedKernelPackages:: linux-image; APT::VersionedKernelPackages:: linux-headers; APT::VersionedKernelPackages:: linux-image-extra; APT::VersionedKernelPackages:: linux-signed-image; APT::VersionedKernelPackages:: kfreebsd-image; APT::VersionedKernelPackages:: kfreebsd-headers; APT::VersionedKernelPackages:: gnumach-image; APT::VersionedKernelPackages:: .*-modules; APT::VersionedKernelPackages:: .*-kernel; APT::VersionedKernelPackages:: linux-backports-modules-.*; APT::VersionedKernelPackages:: linux-tools; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Periodic ; APT::Periodic::Update-Package-Lists 1; APT::Periodic::Download-Upgradeable-Packages 0; APT::Periodic::AutocleanInterval 1; APT::Periodic::MaxAge 30; APT::Periodic::MinAge 2; APT::Periodic::MaxSize 500; APT::Update ; APT::Update::Pre-Invoke ; APT::Update::Pre-Invoke:: if [ -x /usr/bin/daptup ]; then /usr/bin/daptup --pre; fi; APT::Update::Post-Invoke ; APT::Update::Post-Invoke:: if [ -x /usr/bin/daptup ]; then /usr/bin/daptup --post; fi; APT::Update::Post-Invoke-Success ; APT::Update::Post-Invoke-Success:: test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i; APT::Get ; APT::Get::Show-Upgraded true; APT::Get::Show-Versions true; APT::Get::Purge true; APT::Cache ; APT::Cache::AllVersions false; APT::Acquire ; APT::Acquire::Description de;
Bug#757907: pgadmin: pgadmin doesn't support Sid/Jessie postgresql default version 9.4
Package: pgadmin3 Version: 1.18.1-3 Severity: important File: pgadmin Dear Maintainer, When installing postgresql package in Sid, version 9.4 is installed. But current pgadmin version (1.18.1-3) doesn't support this version, it supports 8.3 through 9.3 version. There is a new upstream version (currently 1.20 beta1 http://www.postgresql.org/ftp/pgadmin3/release/v1.20.0-beta1/src/) available. Regards, Sébastien KALT -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (980, 'unstable'), (970, 'testing'), (960, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16-0.slh.2-aptosid-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pgadmin3 depends on: ii libc6 2.19-7 ii libgcc1 1:4.9.1-5 ii libkrb5-3 1.12.1+dfsg-7 ii libpq5 9.4~beta2-1 ii libssl1.0.0 1.0.1i-2 ii libstdc++6 4.9.1-5 ii libwxbase3.0-0 3.0.1-3 ii libwxgtk3.0-0 3.0.1-3 ii libxml2 2.9.1+dfsg1-4 ii libxslt1.1 1.1.28-2 ii pgadmin3-data 1.18.1-3 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages pgadmin3 recommends: ii pgagent3.4.0-3 ii postgresql-client 9.4+160 ii postgresql-client-9.1 [postgresql-client] 9.1.13-0wheezy1 ii postgresql-client-9.3 [postgresql-client] 9.3.4-2 ii postgresql-client-9.4 [postgresql-client] 9.4~beta2-1 Versions of packages pgadmin3 suggests: ii postgresql-contrib 9.4+160 -- 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#735974: libfarstream-0.1-0: please transition to Farstream 2.0 (Gstreamer 1.0 -based)
Package: libfarstream-0.1-0 Version: 0.1.2-3 Followup-For: Bug #735974 As pointed out by the initial reporter, Farstream 1 is unmaintained. All development has moved to a branch based upon Gstreamer 1.0. Could you please follow suit and package 2.0? Thanks! -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (1001, 'testing'), (1001, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.16-trunk-686-pae (SMP w/1 CPU core) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libfarstream-0.1-0 depends on: pn gstreamer0.10-nice none pn gstreamer0.10-plugins-badnone pn gstreamer0.10-plugins-base none pn gstreamer0.10-plugins-good none ii libc62.19-7 ii libglib2.0-0 2.40.0-3 ii libgstreamer-plugins-base0.10-0 0.10.36-1.1 ii libgstreamer0.10-0 0.10.36-1.3 ii libgupnp-1.0-4 0.20.12-1 ii libgupnp-igd-1.0-4 0.2.3-1 ii libnice100.1.7-1 ii libxml2 2.9.1+dfsg1-4 ii multiarch-support2.19-7 libfarstream-0.1-0 recommends no packages. libfarstream-0.1-0 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 Archive: https://lists.debian.org/debian-bugs-dist
Bug#756810: linux-image-3.16-rc6-armmp: HDMI on wandboard/cubox-i no longer works
On Mon, Aug 11, 2014 at 11:43:15PM -0700, Vagrant Cascadian wrote: On 2014-08-11, Vagrant Cascadian wrote: I think this is caused by dropping CONFIG_DRM_IMX_IPUV3_CORE=m, which was moved out of staging into drivers/gpu/ipu-v3/Kconfig. And the configuration option was also renamed to CONFIG_IMX_IPUV3_CORE... I've tested that the following patch on a Cubox-i works: diff --git a/config/armhf/config.armmp b/config/armhf/config.armmp thank you, applied! (will be in next 3.16 upload, very likely for sid) happy hacking. (: -- maks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752945: oasis: FTBFS - 2 test failures
Control: severity 752945 important Le 2014-08-09 11:39, Mehdi Dogguy a écrit : If I don't have a way to reproduce this bug, I guess I'll downgrade the severity to important. I tried to run some more tests in different contexts but wasn't able to reproduce the described failures. Thus, I'm downgrading this issue to important. Kind regards, -- Mehdi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757908: gthumb: please migrate Recommends: gstreamer0.10-gnomevfs to Gst 1.0 components
Package: gthumb Version: 3:3.3.1-2 Severity: normal Gthumb recommends gstreamer0.10-gnomevfs, which is an obsolete Gst 0.10 component. Since Gthum has recently become a full-fledged GNOME 3 application, chances are it already uses GIO to access the VFS, so there's probably no new Recommends to take its place. Unless I'm mistaken, that Recommends can simply be dropped. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (1001, 'testing'), (1001, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.16-trunk-686-pae (SMP w/1 CPU core) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gthumb depends on: ii gsettings-desktop-schemas 3.12.2-1 ii gthumb-data 3:3.3.1-2 ii libatk1.0-0 2.12.0-1 ii libc6 2.19-7 ii libcairo-gobject2 1.12.16-2 ii libcairo2 1.12.16-2 ii libexiv2-12 0.23-1 ii libgcc1 1:4.9.1-4 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-02.40.0-3 ii libgstreamer-plugins-base1.0-0 1.4.0-1 ii libgstreamer1.0-0 1.4.0-1 ii libgtk-3-0 3.12.2-1+b1 ii libjavascriptcoregtk-3.0-0 2.4.4-2 ii libjpeg88d1-1 ii libjson-glib-1.0-0 1.0.2-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpng12-0 1.2.50-2 ii librsvg2-2 2.40.2-1 ii libsecret-1-0 0.18-1 ii libsoup2.4-12.46.0-2 ii libstdc++6 4.9.1-4 ii libtiff54.0.3-9 ii libwebkit2gtk-3.0-252.4.4-2 ii libwebp50.4.0-4.1 ii multiarch-support 2.19-7 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages gthumb recommends: ii bison 2:3.0.2.dfsg-2 ii flex2.5.39-8 pn gstreamer0.10-gnomevfs none ii gvfs-bin1.20.2-1 gthumb 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 Archive: https://lists.debian.org/debian-bugs-dist
Bug#756867: transition: gdal
On 02/08/14 20:41, Bas Couwenberg wrote: Updating GDAL from 1.10.1 to 1.11.0 involves a SONAME bump from libgdal.so.1.17.1 to libgdal.so.1.18.0. Because the binary package name doesn't change, I don't know how to format a Ben file to track this. Err. What? Are you bumping the SONAME without renaming the package? Why? Why isn't the package named after the SONAME as it should be? What am I missing? Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757909: pulseaudio-module-gconf: migration to a dconf PA backend
Package: pulseaudio-module-gconf Version: 5.0-6 Severity: normal pulseaudio-module-gconf seems to be one of the few components left in Jessie that uses gconf. Pretty much everything else has migrated to use the dconf/gsettings backend. Could this be migrated as well? Thanks! -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (1001, 'testing'), (1001, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.16-trunk-686-pae (SMP w/1 CPU core) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pulseaudio-module-gconf depends on: ii gconf-service 3.2.6-2 ii libc6 2.19-7 ii libcap21:2.24-3 ii libgconf-2-4 3.2.6-2 ii libglib2.0-0 2.40.0-3 ii libpulse0 5.0-6 ii pulseaudio 5.0-6 pulseaudio-module-gconf recommends no packages. pulseaudio-module-gconf 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 Archive: https://lists.debian.org/debian-bugs-dist
Bug#748386: [Pkg-running-devel] Bug#748386: subsurface: diff for NMU version 4.0.3-2.1
On Tue, 12 Aug 2014 09:19:49 +0200 Christian PERRIER bubu...@debian.org wrote: Quoting Tobias Frost (t...@debian.org): tags 748386 + pending thanks Dear maintainer, I've prepared an NMU for subsurface (versioned as 4.0.3-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Thanks for your work (as pkg-running team member, I leave priority to Sylvestre Ledru, who is probably busy elsewhere...which explains why nothing happened with that issue). Well, I am surprised... I didn't receive any email from the BTS and it is the first time that I see about this bug. Anyway, thanks for the upload. Just upload it now. (and please commit the change in the vcs if you can) Thanks again, S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757820: jack2d: FTBFS with clang instead of gcc
Control: reassign -1 src:jackd2
On Lu, 11 aug 14, 10:43:33, Arthur Marble wrote:
Package: jack2d
Severity: minor
Tags: patch
User: pkg-llvm-t...@lists.alioth.debian.org
Usertags: clang-ftbfs
Hello,
Using the rebuild infrastructure, your package fails to build with clang
(instead of gcc).
Detected this kind of error:
http://clang.debian.net/status.php?version=3.5.0rc1key=UNDEF_REF
Full build log is available here:
http://clang.debian.net/logs/2014-08-05/jackd2_1.9.10+20140719git3eb0ae6a~dfsg-1_unstable_clang.log
Thanks,
Arthur
-- System Information:
Debian Release: jessie/sid (unstable)
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-2-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Compiler: Debian clang version 3.5.0-+rc1-2 (tags/RELEASE_35/rc1) (based on
LLVM 3.5.0)
diff -Naur
jackd2.orig/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/changelog
jackd2/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/changelog
--- jackd2.orig/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/changelog
2014-08-11 10:34:38.112057125 -0500
+++ jackd2/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/changelog
2014-08-11 10:37:12.588059815 -0500
@@ -1,3 +1,10 @@
+jackd2 (1.9.10+20140719git3eb0ae6a~dfsg-2) unstable; urgency=medium
+
+ * Fix FTBFS with clang
+- Fixed undefined reference error
+
+ -- Arthur Marble art...@info9.net Mon, 11 Aug 2014 10:37:12 -0500
+
jackd2 (1.9.10+20140719git3eb0ae6a~dfsg-1) unstable; urgency=medium
* Imported Upstream version 1.9.10+20140719git3eb0ae6a~dfsg
diff -Naur
jackd2.orig/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/clang-ftbfs.diff
jackd2/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/clang-ftbfs.diff
---
jackd2.orig/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/clang-ftbfs.diff
1969-12-31 18:00:00.0 -0600
+++
jackd2/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/clang-ftbfs.diff
2014-08-11 10:36:10.908058741 -0500
@@ -0,0 +1,11 @@
+--- a/common/memops.c
b/common/memops.c
+@@ -198,7 +198,7 @@ static inline __m128i float_24_sse(__m12
+ */
+ static unsigned int seed = 2;
+
+-inline unsigned int fast_rand() {
++static inline unsigned int fast_rand() {
+ seed = (seed * 96314165) + 907633515;
+ return seed;
+ }
diff -Naur
jackd2.orig/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/series
jackd2/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/series
--- jackd2.orig/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/series
2014-08-11 10:34:38.112057125 -0500
+++ jackd2/jackd2-1.9.10+20140719git3eb0ae6a~dfsg/debian/patches/series
2014-08-11 10:34:57.068057455 -0500
@@ -1 +1,2 @@
waf.patch
+clang-ftbfs.diff
--
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
signature.asc
Description: Digital signature
Bug#735974: libfarstream-0.1-0: please transition to Farstream 2.0 (Gstreamer 1.0 -based)
On 12/08/14 10:17, Martin-Éric Racine wrote: As pointed out by the initial reporter, Farstream 1 is unmaintained. All development has moved to a branch based upon Gstreamer 1.0. ... Could you please follow suit and package 2.0? I assume you mean Farstream 0.2 (the parallel-installable, GStreamer-1.0-based version of Farstream that continues to be maintained upstream) which has been in Debian since late 2012, in the farstream-0.2 source package. Please use that in any new code that needs this functionality, and convert old code to use it. At this point src:farstream is only here to support ktp-call-ui and Pidgin. We are not going to re-upload src:farstream-0.2 as src:farstream; that would just break those packages, for no real benefit. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757876: freeciv-client-gtk: can't start a local game
In a terminal, I type freeciv-gtk2, but there is no message then and the client can't start a local server. When I type freeciv-server, everything works fine : Ceci est le serveur pour Freevciv version 2.4.2 Vous pouvez en apprendre davantage sur Freeciv sur http://www.freeciv.org/ 2: Chargement des différentes règles du jeu. 2: AI*1 a été ajouté en tant que joueur contrôlé par une IA de niveau Facile (classic). 2: AI*2 a été ajouté en tant que joueur contrôlé par une IA de niveau Facile (classic). 2: AI*3 a été ajouté en tant que joueur contrôlé par une IA de niveau Facile (classic). 2: AI*4 a été ajouté en tant que joueur contrôlé par une IA de niveau Facile (classic). 2: AI*5 a été ajouté en tant que joueur contrôlé par une IA de niveau Facile (classic). 2: Accepte dorénavant la connexion de nouveaux clients. Pour obtenir une aide sommair I tried to launch freeciv-server separately, and with the client I choosed Connect to a network game, but I choose the local server. This way I can play a local game. Regards * Jacob Nevins jacobn+deb...@chiark.greenend.org.uk le [11-08-2014 22:45:26 +0100]: Xavier Cartron writes: When I click on Start a new game (démarrer une nouvelle partie in french), I see at the bottom of the client window these messages : Starting local server Impossible to connect to the server And then, nothing happens, and I can't play any game. Unfortunately, I don't see any error message when launching freeciv with a terminal. When you say launching freeciv with a terminal, what exactly do you type, and what do you see? What happens if you type 'freeciv-server' in a terminal (if different to the above)? -- Thuban PubKey : http://yeuxdelibad.net/Divers/thuban.pub -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757876: freeciv-client-gtk: can't start a local game
Xavier Cartron writes: In a terminal, I type freeciv-gtk2, but there is no message then and the client can't start a local server. When I type freeciv-server, everything works fine : [...] I tried to launch freeciv-server separately, and with the client I choosed Connect to a network game, but I choose the local server. This way I can play a local game. Hm. Can you do freeciv-gtk2 -l foo.log? The server log is redirected to this file, and might tell us what's upsetting it when it's started by the client. (The log file might be rather verbose.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756867: transition: gdal
On 08/12/2014 11:26 AM, Emilio Pozuelo Monfort wrote: On 02/08/14 20:41, Bas Couwenberg wrote: Updating GDAL from 1.10.1 to 1.11.0 involves a SONAME bump from libgdal.so.1.17.1 to libgdal.so.1.18.0. Because the binary package name doesn't change, I don't know how to format a Ben file to track this. Err. What? Are you bumping the SONAME without renaming the package? Why? Why isn't the package named after the SONAME as it should be? What am I missing? Sorry about creating such confusion by badly wording the issue. The SONAME doesn't change, it remains at libgdal.so.1, only the library version changes. The package is named libgdal1h to differentiate it from its predecessor libgdal1 after the reintroduction of internal symbols hiding for better compatibility against mixing external geotiff and gdal. Because the libgdal exposes both C and C++ symbols, its reverse dependencies need a rebuild to make sure they continue to work in case they don't only use the stable C API but also the unstable C++ API. Does it make sense to you now? Emilio Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757910: linuxinfo: [l10n:cs] Initial Czech translation of man page for linuxinfo package
Package: linuxinfo Version: 2.1.0 Severity: wishlist Tags: l10n patch Dear Maintainer, In attachment there is initial Czech translation of man page (cs.po) for linuxinfo package, please include it. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash # Czech translation of man page strings for linuxinfo # Copyright (C) 2014 Michal Simunek michal.simu...@gmail.com # This file is distributed under the same license as the linuxinfo package. # Michal Simunek michal.simu...@gmail.com, 2014. # msgid msgstr Project-Id-Version: linuxinfo 2.1.0\n Report-Msgid-Bugs-To: Helge Kreutzmann deb...@helgefjell.de\n POT-Creation-Date: 2014-08-09 20:40+0300\n PO-Revision-Date: 2014-08-12 10:15+0200\n Last-Translator: Michal Simunek michal.simu...@gmail.com\n Language-Team: Czech debian-l10n-cz...@lists.debian.org\n Language: cs\n MIME-Version: 1.0\n Content-Type: text/plain; charset=utf-8\n Content-Transfer-Encoding: 8bit\n #. type: TH #: linuxinfo.1:4 #, no-wrap msgid LinuxInfo msgstr LinuxInfo #. type: TH #: linuxinfo.1:4 #, no-wrap msgid 9 August 2014 msgstr 9. srpen 2014 #. type: TH #: linuxinfo.1:4 #, no-wrap msgid Linux msgstr Linux #. type: TH #: linuxinfo.1:4 #, no-wrap msgid Software msgstr Software #. type: SH #: linuxinfo.1:5 #, no-wrap msgid NAME msgstr NÁZEV #. type: Plain text #: linuxinfo.1:7 msgid linuxinfo - displays system information about system. msgstr linuxinfo - zobrazuje údaje o systému. #. type: SH #: linuxinfo.1:7 #, no-wrap msgid SYNOPSIS msgstr PŘEHLED #. type: Plain text #: linuxinfo.1:10 msgid Blinuxinfo [I-h | I-v | Ifilename] msgstr Blinuxinfo [I-h | I-v | Ifilename] #. type: SH #: linuxinfo.1:10 #, no-wrap msgid DESCRIPTION msgstr POPIS #. type: Plain text #: linuxinfo.1:14 msgid Displays the system information about the system, including kernel version, number and type of processors in system, version of system library (libc or glibc). msgstr Zobrazuje údaje o tomto systému, včetně verze jádra, počtu a typu procesorů v systému, verze systémové knihovny (libc nebo glibc). #. type: SH #: linuxinfo.1:14 #, no-wrap msgid OPTIONS msgstr VOLBY #. type: TP #: linuxinfo.1:15 #, no-wrap msgid B-v msgstr B-v #. type: Plain text #: linuxinfo.1:18 msgid Print version information. msgstr Zobrazí údaj o verzi. #. type: TP #: linuxinfo.1:18 #, no-wrap msgid B-h msgstr B-h #. type: Plain text #: linuxinfo.1:21 msgid Print brief help. msgstr Zobrazí stručnou nápovědu. #. type: TP #: linuxinfo.1:21 #, no-wrap msgid Bfilename msgstr Bfilename #. type: Plain text #: linuxinfo.1:25 msgid Use an alternative source for system information (by default B/proc/cpuinfo). msgstr Pro údaje o systému použije alternativní zdroj (výchozí nastavení je B/proc/cpuinfo). #. type: SH #: linuxinfo.1:25 #, no-wrap msgid AUTHORS msgstr AUTOŘI #. type: Plain text #: linuxinfo.1:28 msgid Alex Buell Eltalex.bu...@munted.euegt, Helge Kreutzmann Eltdeb...@helgefjell.deegt msgstr Alex Buell Eltalex.bu...@munted.euegt, Helge Kreutzmann Eltdeb...@helgefjell.deegt #. type: SH #: linuxinfo.1:28 #, no-wrap msgid BUGS msgstr CHYBY #. type: Plain text #: linuxinfo.1:30 msgid What bugs? ;o) Do tell me! msgstr Jaké chyby? ;o) To mi vysvětlete! #. type: Plain text #: linuxinfo.1:32 msgid Ok, some CPUs are not yet detected. Please inform me (Helge) if yours is amongst those. msgstr Dobře, některé procesory se ještě nedaří rozpoznat. Pokud mezi ně patří ten váš, informujte mě prosím (Helge).
Bug#735974: libfarstream-0.1-0: please transition to Farstream 2.0 (Gstreamer 1.0 -based)
2014-08-12 12:33 GMT+03:00 Simon McVittie s...@debian.org: On 12/08/14 10:17, Martin-Éric Racine wrote: As pointed out by the initial reporter, Farstream 1 is unmaintained. All development has moved to a branch based upon Gstreamer 1.0. ... Could you please follow suit and package 2.0? I assume you mean Farstream 0.2 (the parallel-installable, GStreamer-1.0-based version of Farstream that continues to be maintained upstream) which has been in Debian since late 2012, in the farstream-0.2 source package. Please use that in any new code that needs this functionality, and convert old code to use it. Erm... Yes. That one. :) At this point src:farstream is only here to support ktp-call-ui and Pidgin. We are not going to re-upload src:farstream-0.2 as src:farstream; that would just break those packages, for no real benefit. Noted. Has there been any sign of a Pidgin release that could build using 0.2? Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-dist
Bug#757911: vinagre shows user prompt to the console for RDP connections
Package: vinagre Version: 3.12.2-1 Severity: grave Justification: renders package unusable Hi, The current version of vinagre is using the console to display errors to the users and to request input(password, key verification,...) This is a quite aninoying regression from the version in stable. Upstream has commited 2 patches that address this, we should include them in our own package. I'm opening this bug to be sure this is not forgotten Cheers, Laurent Bigonville -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vinagre depends on: ii dconf-gsettings-backend [gsettings-backend] 0.20.0-2 ii libavahi-common3 0.6.31-4 ii libavahi-gobject00.6.31-4 ii libavahi-ui-gtk3-0 0.6.31-4 ii libc62.19-7 ii libcairo21.12.16-2 ii libdbus-glib-1-2 0.102-1 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libglib2.0-0 2.40.0-4 ii libgtk-3-0 3.12.2-2 ii libgtk-vnc-2.0-0 0.5.3-1 ii libsecret-1-00.18-1 ii libspice-client-glib-2.0-8 0.25-1 ii libspice-client-gtk-3.0-40.25-1 ii libtelepathy-glib0 0.24.0-1 ii libvte-2.90-91:0.36.3-1 ii libxml2 2.9.1+dfsg1-4 Versions of packages vinagre recommends: ii freerdp-x11 1.1.0~git20140809.1.b07a5c1+dfsg-2 ii gnome-icon-theme 3.12.0-1 vinagre 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#709616: floods the network with pause packets
Hello, Since I've upgraded to Linux 3.14, this bug occurs more often. The record of uptime so far is 7 days and 18 hours. Tail of uprecords -b -m 0 output: 46 19 days, 23:50:56 | Linux 3.13-1-amd64 Tue Apr 22 09:37:55 2014 477 days, 04:20:44 | Linux 3.14-1-amd64 Mon May 19 15:08:40 2014 487 days, 07:20:52 | Linux 3.14-1-amd64 Tue Jun 24 09:58:19 2014 496 days, 15:31:00 | Linux 3.14-1-amd64 Fri Jul 18 18:24:48 2014 507 days, 18:00:42 | Linux 3.14-2-amd64 Mon Aug 4 17:40:44 2014 - 510 days, 00:06:01 | Linux 3.14-2-amd64 Tue Aug 12 11:51:28 2014 All reboots were due to the bug. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750255: lio-utils: FTBFS: chmod: cannot access '/«BUILDDIR»/lio-utils-3.1+git2.fd0b34fd/debian/lio-utils/usr/share/pyshared/*.py': No such file or directory
Hi Ritesh, Sorry for the late reply, I am on vacation right now. I am aiming at first week of September for the final release. Will keep you posted :-) The merge effort will not be carried out for this one, though, and it still is to be decided how we will version it etc. Best Regards, -- Jerome On 08/11/2014 10:43 AM, Ritesh Raj Sarraf wrote: On 08/09/2014 01:05 PM, Ritesh Raj Sarraf wrote: On 08/09/2014 03:31 AM, Aurelien Jarno wrote: On Wed, Jun 04, 2014 at 12:16:06PM +0530, Ritesh Raj Sarraf wrote: For the sake of users who may land on this bug report. lio-utils is deprecated upstream. Users are advised to switch to targetcli. lio-utils may soon be removed from the Debian repositories. Even if lio-utils is deprecated, targetcli depends on it. Ignoring this bug just mean we currenyl don't have scsi target support in Jessie, which is be a pitty. No. It is on my list and will be fixed very soon.. Personal stuff has delayed it but soon I'll be resuming work on it. Jerome, When do you plan the 3.0 release ? I see you and Andy talking on merges and newer designs. Please let me know the timelines when you plan a release. Debian will freeze in 2 months and I'd like to push the newer stack as soon as possible. -- Ritesh Raj Sarraf |http://people.debian.org/~rrs Debian - The Universal Operating System -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757912: accountsservice: passes (encrypted) passwords as commandline arguments
Package: accountsservice Version: 0.6.37-3 Severity: normal Tags: security Hi, accountsservice passes (encrypted) passwords as command line arguments to usermod: +--- | argv[0] = /usr/sbin/usermod; | argv[1] = -p; | argv[2] = strings[0]; +---[ src/user.c ] Command line arguments, and thus the (encrypted) password, are by default readable by every local user. Please use some other means to set passwords that do not involve passing them as command line arguments, for example by using chpasswd which allows passing user name and password via stdin. Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750643: antlr: missing licence for PyANTLR
Hello Debian, the PyAntlr extension of Antlr consists of two software parts: (1) A generator source code located in antlr/actions/python ; and a (2) runt-time library located in lib/python I herewith declare, that o part (1) has been released into the wild under the conditions of license http://opensource.org/licenses/BSD-3-Clause ; and further, that o part (2) has been released into the wild under the conditions of license GPL version 3 or later (http://www.gnu.org/licenses/gpl-3.0.txt) // Wolfgang Häfelinger On Sun, Jul 13, 2014 at 6:07 PM, Thorsten Glaser t...@mirbsd.de wrote: wolfgang haefelinger dixit: Discussed this with the original author of Antlr. The lights are on red for a new 2.7 release and I'm currently not willing to create a fork. Sure. Let’s just add editorial notes from Terence and you to clean up the licence situation. We will put that into debian/copyright, and you (Terence, probably) can put it up on the website, and that should be everything anyone could ever need. which is why the “LICENSE.txt” of Antlr itself does not work for you. (Side fact: it’s misnamed because PD means absence of the need for a licence.) What file name does Debian then propose? This is not about Debian (they do not ship those files anyway, but collect all licencing information in a central file) but about PD versus licences. But this does not matter – we’re not re-releasing, so we just put the updated info “somewhere”, and everything is good. Besides, with the proposed language I sent to Terence, there would be a licence, so this point is moot anyway. 1) antlr/actions/python/ 2) lib/python/ My statement is then: o All source code packed with (1) is released in terms of the BSD software license. That is one of these? * http://opensource.org/licenses/BSD-3-Clause * http://opensource.org/licenses/BSD-2-Clause p All source code packed with (2) is released in terms of the GPL software license. This also, unfortunately, has got several options… * GPL, any version * GPL version 2 only * GPL version 2 or later * GPL version 3 only * GPL version 3 or later * GPL version (1 or) 2 or 3 only So, can you help me reformulate them so that they look proper and can be used in an official statement? Yes, of course. Just solve the above choices ;-) Second, how shall I transmit this statement to Debian? There is a half-backed website [1] - maintained by me - where I could put those license details. Just per eMail to this bugreport is enough. It would be good if you can PGP sign it, but that’s not been required until now. If you update a website, sure, put it up there. Otherwise, I’d suggest (once finished) you also send it to Terence, so it can be shown at the official Antlr site. Thanks for your patience! bye, //mirabilos -- igli exceptions: a truly awful implementation of quite a nice idea. igli just about the worst way you could do something like that, afaic. igli it's like anti-design. mirabilos that too… may I quote you on that? igli sure, tho i doubt anyone will listen ;) -- Wolfgang Häfelinger häfelinger IT - Applied Software Architecture http://www.haefelinger.it +49 1520 32 52 981 (+31 648 27 61 59)
Bug#757914: iceweasel: please Suggests: gstreamer1.0-libav
Package: iceweasel Version: 31.0-3 Severity: normal The X.264 media container codec is now provided by gstreamer1.0-libav, which would be desirable to see in Suggests or even better Recommends. -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (1001, 'testing'), (1001, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.16-trunk-686-pae (SMP w/1 CPU core) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages iceweasel depends on: ii debianutils 4.4 ii fontconfig2.11.0-5 ii libasound21.0.28-1 ii libatk1.0-0 2.12.0-1 ii libc6 2.19-7 ii libcairo2 1.12.16-2 ii libdbus-1-3 1.8.6-1 ii libdbus-glib-1-2 0.102-1 ii libevent-2.0-52.0.21-stable-1 ii libffi6 3.1-2 ii libfontconfig12.11.0-5 ii libfreetype6 2.5.2-1 ii libgcc1 1:4.9.1-4 ii libgdk-pixbuf2.0-02.30.7-1 ii libglib2.0-0 2.40.0-3 ii libgtk2.0-0 2.24.24-1 ii libhunspell-1.3-0 1.3.3-2 ii libnspr4 2:4.10.6-1 ii libnss3 2:3.16.3-1 ii libpango-1.0-01.36.3-1 ii libsqlite3-0 3.8.5-2 ii libstartup-notification0 0.12-3 ii libstdc++64.9.1-4 ii libvpx1 1.3.0-2 ii libx11-6 2:1.6.2-2 ii libxext6 2:1.3.2-1 ii libxrender1 1:0.9.8-1 ii libxt61:1.1.4-1 ii procps1:3.3.9-7 ii zlib1g1:1.2.8.dfsg-1 iceweasel recommends no packages. Versions of packages iceweasel suggests: pn fonts-mathjax none pn fonts-oflb-asana-math none ii fonts-stix [otf-stix] 1.1.1-1 ii libcanberra0 0.30-2 ii libgnomeui-0 2.24.5-3 ii libgssapi-krb5-2 1.12.1+dfsg-7 pn mozplugger 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 Archive: https://lists.debian.org/debian-bugs-dist
Bug#735974: libfarstream-0.1-0: please transition to Farstream 2.0 (Gstreamer 1.0 -based)
On 12/08/14 10:54, Martin-Éric Racine wrote: 2014-08-12 12:33 GMT+03:00 Simon McVittie s...@debian.org: At this point src:farstream is only here to support ktp-call-ui and Pidgin. We are not going to re-upload src:farstream-0.2 as src:farstream; that would just break those packages, for no real benefit. Noted. Has there been any sign of a Pidgin release that could build using 0.2? There has not. Support for Gst 1.0 was merged for Pidgin 3; place bets now on whether that will happen in time for Debian 9. The last activity on the upstream bug was a request for a backport to 2.x, 20 months ago. (For Debian 8 seems unlikely to me.) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731122 tracks the request in Debian; https://developer.pidgin.im/ticket/15299 is the upstream bug. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757876: freeciv-client-gtk: can't start a local game
Control: severity -1 normal Control: tags -1 unreproducible moreinfo On 11.08.2014 23:27, Xavier Cartron wrote: Package: freeciv-client-gtk Version: 2.4.2-1~bpo70+1 Severity: grave Justification: renders package unusable Hello, the wheezy-backport works for me and has been so for the past months. Probably there is some configuration issue on your side that prevents the connection of your freeciv client to the local server. Please backup your configuration in $HOME (.freeciv directory and hidden .freeciv* files), move them away and restart the game. If this does not help, please attach your log file to this bug report as Jacob has outlined before: freeciv-gtk2 -l freeciv_bug_757876.log Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#757913: systemd: On systemd dbus.target is invoked but not exist.
reassign 757913 dbus thanks Am 12.08.2014 12:10, schrieb Corcodel Marian: Package: systemd Version: 208-6 Severity: normal Hi On /lib/systemd/system/dbus.target.wants exist link dbus.socket which is useless, when dbus.target not exist and not defined on systemd. Please remove this directory. First, this directory is shipped in dbus, not systemd, so you've filed this bug against the wrong package: # dpkg -S /lib/systemd/system/dbus.target.wants/ dbus: /lib/systemd/system/dbus.target.wants Second, the dbus.target is indeed deprecated but not useless, as there have been units (in the past) which referenced it. According to codesearch [1] there is apparently only one left [2] in the Debian archive. Since it's a simple ordering (After=) it seems safe to drop. I'll leave that up for Simon to decide. This should probably also go upstream. [1] http://codesearch.debian.net/search?q=dbus.target [2] http://sources.debian.net/src/spice-vdagent/0.15.0-1.1/data/spice-vdagentd.service/?hl=3#L3 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#757334: Missing build-dep in previous patch
Hi, In my previous patch I forgot to add some build dependencies. Here a new patch that replace the previous one. Sorry for the inconvenience. Erwan. diff -Naur a/debian/control b/debian/control --- a/debian/control2014-08-06 13:51:51.774223809 +0200 +++ b/debian/control2014-08-06 13:52:43.894221039 +0200 @@ -5,7 +5,7 @@ Uploaders: Yves-Alexis Perez cor...@debian.org, Lionel Le Folgoc mrpo...@gmail.com Build-Depends: debhelper (= 9), intltool (= 0.31), pkg-config, - libglib2.0-dev, libgtk2.0-dev, libxfce4util-dev (= 4.10.0), dpkg-dev (= 1.16.1) + libglib2.0-dev, libgtk2.0-dev, libxfce4util-dev (= 4.10.0), dpkg-dev (= 1.16.1), dh-autoreconf, xfce4-dev-tools, gtk-doc-tools Standards-Version: 3.9.3 Homepage: http://www.xfce.org/ Vcs-Svn: svn://svn.debian.org/pkg-xfce/desktop/trunk/garcon diff -Naur a/debian/rules b/debian/rules --- a/debian/rules 2014-08-06 13:51:51.778223809 +0200 +++ b/debian/rules 2014-08-06 13:53:14.550219410 +0200 @@ -4,7 +4,11 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+all %: - dh $@ --parallel + dh $@ --parallel --with autoreconf + +override_dh_auto_configure: + xdt-autogen + dh_auto_configure override_dh_install: dh_install --fail-missing -X .la
Bug#757915: libesmtp: FTBFS because of outdated config.guess, config.sub on ppc64el
Package: src:libesmtp Version: 1.0.6-3 Severity: normal Tags: patch User: debian-powe...@lists.debian.org Usertags: ppc64el Dear Maintainer, the package libesmtp fails to build from source on ppc64el because autoconf/config.guess and autoconf/config.sub are outdated. This patch from Ubuntu adds the use of dh_autoreconf to deal with that. Thanks for reading, Fred -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (450, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash diff -baupr ../../libesmtp-1.0.6/debian/changelog ../libesmtp-1.0.6/debian/changelog --- ../../libesmtp-1.0.6/debian/changelog 2014-07-01 15:56:44.0 + +++ ../libesmtp-1.0.6/debian/changelog 2014-08-08 15:07:39.0 + @@ -1,3 +1,10 @@ +libesmtp (1.0.6-3ppc64el1) UNRELEASED; urgency=medium + + * Fix FTBFS with patch from Ubuntu : Rebuild using dh-autoreconf for usable +shared libs on ppc64el (resolving FTBFS for reverse-build-dependencies on said arch). + + -- Frédéric Bonnard fre...@linux.vnet.ibm.com Fri, 08 Aug 2014 12:06:29 -0300 + libesmtp (1.0.6-3) unstable; urgency=low * Fix FTBFS due to debhelper compat 9 changes to lib directories. diff -baupr ../../libesmtp-1.0.6/debian/control ../libesmtp-1.0.6/debian/control --- ../../libesmtp-1.0.6/debian/control 2014-05-29 03:41:16.0 + +++ ../libesmtp-1.0.6/debian/control 2014-08-08 15:06:29.0 + @@ -5,7 +5,7 @@ Maintainer: Jeremy T. Bouse jbouse@debi Build-Depends: debhelper ( 9.0.0), libltdl3-dev, libssl-dev, - autotools-dev + dh-autoreconf Standards-Version: 3.9.5 Homepage: http://www.stafford.uklinux.net/libesmtp/ Vcs-Git: git://github.com/jbouse-debian/libesmtp.git diff -baupr ../../libesmtp-1.0.6/debian/rules ../libesmtp-1.0.6/debian/rules --- ../../libesmtp-1.0.6/debian/rules 2014-05-29 03:41:16.0 + +++ ../libesmtp-1.0.6/debian/rules 2014-08-08 15:06:29.0 + @@ -3,7 +3,7 @@ export DH_VERBOSE=1 %: - dh $@ --with autotools-dev + dh $@ --with autoreconf override_dh_auto_configure: dh_auto_configure -- --with-auth-plugin-dir=/usr/lib/esmtp --enable-etrn
Bug#683746: Review of debian/copyright for rspamd
Hi Andreas, I'm going to upload new package soon. On Mon, Aug 11, 2014 at 9:56 PM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: Hi Vsevolod, On 11.08.2014 16:18, Vsevolod Stakhov wrote: I've applied the suggested patch to both 0.6 and master branches. Thank you for the contribution! You're welcome. I hope this helps to get rspamd into Debian. It's probably a good idea to upload a new package with debian/copyright fixed. 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#757584: Confirmed fixed, and update prepared
On 08/12/2014 03:37 AM, Sebastiaan Couwenberg wrote: If in the mean time pktools 2.5.3 is released, we can consider uploading that instead of 2.5.2 + git changes and patches. I asked Pieter kempeneers, the pktools upstream, when he expected to release 2.5.3. I received a reply today informing me that pktools 2.5.3 has been released: http://download.savannah.gnu.org/releases/pktools/ Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750785: Slowness with context and xetex
On 11.08.14 Behdad Esfahbod (beh...@behdad.org) wrote: Hi, Before the return, add something like this: printf(DEBUG props %d features %d default_shaper %d shaper_list %d plan func %p proposal func %p\n, hb_segment_properties_equal (shape_plan-props, proposal-props), hb_shape_plan_user_features_match (shape_plan, proposal), shape_plan-default_shaper_list, proposal-shaper_list == NULL, shape_plan-shaper_func, proposal-shaper_func); I left the code provided by Norbert active and redirected all output to stderr. The log is attached (xetex run was terminated). Please be aware, that the uncompressed file has a size of 280 MB. Hilmar -- sigmentation fault out.log.xz Description: Binary data signature.asc Description: Digital signature
Bug#757916: emacs24-nox: abort byte-compiling notmuch-show.el on mipsel
Source: emacs24-nox Version: 24.3+1-4+b1 Severity: important The following causes notmuch 0.18.1-2 to FTBFS on mipsel: bremner@eder ~/notmuch-0.18.1 % emacs --quick --directory emacs -batch -f batch-byte-compile emacs/notmuch-show.el emacs: malloc.c:2372: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *) ((av)-bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd old_size == 0) || ((unsigned long) (old_size) = (unsigned long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 *(sizeof(size_t))) - 1)) ~((2 *(sizeof(size_t))) - 1))) ((old_top)-size 0x1) ((unsigned long) old_end pagemask) == 0)' failed. Fatal error 6: Aborted Previously we used emacs23 to build, so that's why it's just showing up now. I'll attach the elisp file in question, but you can also grab it from the notmuch source package. One additional weirdness is that after printing Fatal error 6: Aborted, emacs does not terminate. Eventually the buildd killed the job. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ;; notmuch-show.el --- displaying notmuch forests. ;; ;; Copyright © Carl Worth ;; Copyright © David Edmondson ;; ;; This file is part of Notmuch. ;; ;; Notmuch is free software: you can redistribute it and/or modify it ;; under the terms of the GNU General Public License as published by ;; the Free Software Foundation, either version 3 of the License, or ;; (at your option) any later version. ;; ;; Notmuch is distributed in the hope that it will be useful, but ;; WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ;; General Public License for more details. ;; ;; You should have received a copy of the GNU General Public License ;; along with Notmuch. If not, see http://www.gnu.org/licenses/. ;; ;; Authors: Carl Worth cwo...@cworth.org ;; David Edmondson d...@dme.org (eval-when-compile (require 'cl)) (require 'mm-view) (require 'message) (require 'mm-decode) (require 'mailcap) (require 'icalendar) (require 'goto-addr) (require 'notmuch-lib) (require 'notmuch-tag) (require 'notmuch-query) (require 'notmuch-wash) (require 'notmuch-mua) (require 'notmuch-crypto) (require 'notmuch-print) (declare-function notmuch-call-notmuch-process notmuch (rest args)) (declare-function notmuch-search-next-thread notmuch nil) (declare-function notmuch-search-previous-thread notmuch nil) (declare-function notmuch-search-show-thread notmuch nil) (declare-function notmuch-foreach-mime-part notmuch (function mm-handle)) (declare-function notmuch-count-attachments notmuch (mm-handle)) (declare-function notmuch-save-attachments notmuch (mm-handle optional queryp)) (declare-function notmuch-tree notmuch-tree (optional query query-context target buffer-name open-target)) (defcustom notmuch-message-headers '(Subject To Cc Date) Headers that should be shown in a message, in this order. For an open message, all of these headers will be made visible according to `notmuch-message-headers-visible' or can be toggled with `notmuch-show-toggle-visibility-headers'. For a closed message, only the first header in the list will be visible. :type '(repeat string) :group 'notmuch-show) (defcustom notmuch-message-headers-visible t Should the headers be visible by default? If this value is non-nil, then all of the headers defined in `notmuch-message-headers' will be visible by default in the display of each message. Otherwise, these headers will be hidden and `notmuch-show-toggle-visibility-headers' can be used to make them visible for any given message. :type 'boolean :group 'notmuch-show) (defcustom notmuch-show-relative-dates t Display relative dates in the message summary line. :type 'boolean :group 'notmuch-show) (defvar notmuch-show-markup-headers-hook '(notmuch-show-colour-headers) A list of functions called to decorate the headers listed in `notmuch-message-headers'.) (defcustom notmuch-show-hook '(notmuch-show-turn-on-visual-line-mode) Functions called after populating a `notmuch-show' buffer. :type 'hook :options '(notmuch-show-turn-on-visual-line-mode) :group 'notmuch-show :group 'notmuch-hooks) (defcustom notmuch-show-insert-text/plain-hook '(notmuch-wash-wrap-long-lines notmuch-wash-tidy-citations notmuch-wash-elide-blank-lines notmuch-wash-excerpt-citations) Functions used to improve the display of text/plain parts. :type 'hook :options '(notmuch-wash-convert-inline-patch-to-part notmuch-wash-wrap-long-lines notmuch-wash-tidy-citations notmuch-wash-elide-blank-lines notmuch-wash-excerpt-citations) :group 'notmuch-show :group 'notmuch-hooks) ;; Mostly useful for debugging. (defcustom
Bug#757785: libwebp FTBFS on arm64, internal compiler errors
Jeff Breidenbach wrote: I'm quite happy to have NMU, with no delay necessary. It especially makes sense since I'm not set up to test on ARM. Also, upstream has some ideas. I'll see if they are amenable to direct contact. -frename-registers made it build. Debdiff attatched and uploaded as NMU I've realised just after I uploaded that I screwed up the comment in debian/rules (what actually happened is I corrected the comment but forgot to save the file). It should say # gcc 4.9 ICEs when building libwebp for arm64, # using -frename-registers works arround this. # http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757738 I don't think it's worth doing a second upload just to fix a comment but you might want to fix the comment but you might want to include the corrected comment in your packaging tree so it goes in the next upload. PS. How the heck did webp become bootstrap critical? Same way a lot of other stuff did. As far as debian is concerned a source package is either completely built or not built at all. So almost certainly someone added webp support to a package in the strong set of packages that must be built to have a healthy archive where all source packages that produce binaries have their build-dependencies satisfiable making libwebp part of that set. I'm not sure which of your rdepends it was that's in the strong set (unfortunately i'm not finding a list of the strong set online, I guess most people who need to know about it calculate it on the fly since it changes over time anyway) but looking through your rdepends it seems some pretty important stuff has picked up dependencies on libwebp, There is work underway to add build-profiles to ease bootstrapping by allowing source packages to be built with reduced functionality but even then afaict there is no intention to accept profile-built packages in the official archive, just ot use them as an intermediate step to break loops in bootstrapping. diff -Nru libwebp-0.4.1/debian/changelog libwebp-0.4.1/debian/changelog --- libwebp-0.4.1/debian/changelog 2014-07-30 23:39:36.0 + +++ libwebp-0.4.1/debian/changelog 2014-08-12 11:16:49.0 + @@ -1,3 +1,10 @@ +libwebp (0.4.1-1.1) unstable; urgency=medium + + * NMU with maintainer's permission + * use -frename-registers as workaround for ICE on arm64 (Closes: #757785) + + -- Peter Michael Green plugw...@debian.org Tue, 12 Aug 2014 11:15:58 + + libwebp (0.4.1-1) unstable; urgency=medium * New upstream release diff -Nru libwebp-0.4.1/debian/rules libwebp-0.4.1/debian/rules --- libwebp-0.4.1/debian/rules 2014-01-08 18:14:20.0 + +++ libwebp-0.4.1/debian/rules 2014-08-11 21:43:18.0 + @@ -6,6 +6,13 @@ # dh-make output file, you may use that output file without restriction. # This special exception was added by Craig Small in version 0.37 of dh-make. +# gcc 4.9 ICEs when building libwebp for arm64, use 4.8 for now +# http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757738 +DEB_HOST_ARCH ?= $(shell dpkg-architecture -q DEB_HOST_ARCH) +ifeq ($(DEB_HOST_ARCH),arm64) + export DEB_CFLAGS_MAINT_APPEND=-frename-registers +endif + # Uncomment this to turn on verbose mode. export DH_VERBOSE=1
Bug#757761: openvswitch-switch: Please include ovsk-controller
On 11/08/14 14:28, Ben Pfaff wrote: On Mon, Aug 11, 2014 at 08:17:19PM +0200, Dariusz Dwornikowski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11.08.2014 17:38, Ben Pfaff wrote: On Mon, Aug 11, 2014 at 09:53:09AM +0200, Dariusz Dwornikowski wrote: Source: openvswitch Severity: wishlist Dear Maintainer, Tomasz Buchert and I are working on introducing mininet, an SDN emulator (http://mininet.org/) to Debian. Mininet heavily depends on ovsk to provide OpenFlow switch but also an OpenFlow controller. Ovsk starting from version 2.1 ships ovsk-controller as test-controller and resides in tests/ directory of the main source. Why can't mininet use a real controller instead of the useless test program from OVS? Mininet is just an emulator, using test controller from OVS makes it easy to start with and use by people who start with OpenFlow and SDNs. Using an OVS controller is one of the major options in mininet, and in fact the default behavior. You can always use external controller with - --remote option in mininet. If we ship mininet package without having OVS controller to use, we will be shipping partially unusable software. I don't understand why the OVS controller is useful. OVS has a larger set of features, and performs better, with no controller, than it does with the test-controller. Why do mininet users want to use ovs-controller instead of no controller at all? Hi Ben, mininet users want to see mininet work - I doubt that they care, at least at the beginning, how it works internally. Mininet is basically an OpenFlow testing framework and therefore *always* runs with an OpenFlow controller and hence *always* needs one. Therefore, replacing it with OVS without OF controller is not feasible and probably discouraged by the architecture of mininet. Also, the test-controller was called a reference controller implementation [1] at one point. Do you provide such a reference implementation right now? If not, can you tell us how we can run a simple MAC-learning OpenFlow-controller to manage multiple switches? Or OVS is not a right tool to do that? Cheers, Tomasz [1] http://openvswitch.org/cgi-bin/ovsman.cgi?page=utilities%2Fovs-controller.8 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757917: transition: libav11
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to upload libav11 to unstable, which requires the recompilation of any package that links against it. A prerelease for Libav11 that passes upstream's extensive test suite is currently in debian/experimental, and I'll make sure that the final release will be done and uploaded before jessie freeze. Unlike previous transitions, this should be less painful compared to Libav10 or Libav9, because Libav11 maintains full source-code compatibility, cf. to the release announcement: https://libav.org/news.html: The API remains backward compatible, so no source changes should be required in the code that works with Libav 10. We note however, that a number of obsolete APIs remain deprecated and will be removed in the future. All users are strongly encouraged to update their code. A work in progress migration guide can be found at our wiki. If you are still having difficulty after reading the migration guide, please do not hesitate to file a report in our Bugzilla. We have a special category for porting issues. Proposed ben file: Affected: .build-depends ~ /lib(avcodec|avformat|avutil|device|filter|avresample)-dev/ Bad: .depends ~ /lib(avcodec55|avformat55|avutil53|device54|filter4|avresample1)/ Good: .depends ~ /lib(avcodec56|avformat56|avutil54|device55|filter5|avresample2)/ Moritz, do you still have the infrastructure and/or scripts that you used for the libav10 test rebuild so that we can verify that everything still builds with libav11? I can give it a shot but unlikely before this weekend. If not, maybe someone else would be willing to fill in? -- 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#757918: tbb 4.0 alpha fails
package: torbrowser-launcher Hi, so the launcher (version 0.1.2 still) today tried to upgrade to tbb 4.0-alpha, which IMO it shouldnt do, but anyway, it also failed: Starting launcher dialog LATEST VERSION 4.0-alpha-1 Checked for update within 24 hours, skipping TBB is out of date, attempting to upgrade to 4.0-alpha-1 Running task: download_sha256 Downloading https://www.torproject.org/dist/torbrowser/4.0- alpha-1/sha256sums.txt Updating over Tor Finished receiving body: Response body fully received Running task: download_sha256_sig Downloading https://www.torproject.org/dist/torbrowser/4.0- alpha-1/sha256sums.txt-mikeperry.asc Updating over Tor Finished receiving body: Response body fully received Running task: download_tarball Downloading https://www.torproject.org/dist/torbrowser/4.0-alpha-1/tor- browser-linux64-4.0-alpha-1_en-US.tar.xz Updating over Tor Finished receiving body: Response body fully received Running task: verify Verifying signature gpg: Signature made Thu Aug 7 22:30:53 2014 CEST using RSA key ID 0E3A92E4 gpg: Good signature from Mike Perry (Regular use key) mikepe...@torproject.org gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: C963 C21D 6356 4E2B 10BB 335B 2984 6B3C 6836 86CC Subkey fingerprint: D734 B622 C7B5 D164 D665 0CB8 717F 1F13 0E3A 92E4 Running task: extract Extracting tor-browser-linux64-4.0-alpha-1_en-US.tar.xz Running task: run Running /home/foo/.torbrowser/tbb/x86_64/tor-browser_en-US/start-tor-browser Unhandled Error Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/twisted/web/_newclient.py, line 911, in dispatcher return func(*args, **kwargs) File /usr/lib/python2.7/dist-packages/twisted/web/_newclient.py, line 1462, in _finishResponse_WAITING self._giveUp(Failure(reason)) File /usr/lib/python2.7/dist-packages/twisted/web/_newclient.py, line 1511, in _giveUp self._disconnectParser(reason) File /usr/lib/python2.7/dist-packages/twisted/web/_newclient.py, line 1499, in _disconnectParser parser.connectionLost(reason) --- exception caught here --- File /usr/lib/python2.7/dist-packages/twisted/web/_newclient.py, line 532, in connectionLost self.response._bodyDataFinished() File /usr/lib/python2.7/dist-packages/twisted/web/_newclient.py, line 911, in dispatcher return func(*args, **kwargs) File /usr/lib/python2.7/dist-packages/twisted/web/_newclient.py, line 1154, in _bodyDataFinished_CONNECTED self._bodyProtocol.connectionLost(reason) File /usr/bin/torbrowser-launcher, line 833, in connectionLost self.all_done(reason) File /usr/bin/torbrowser-launcher, line 844, in response_finished self.run_task() File /usr/bin/torbrowser-launcher, line 787, in run_task self.verify() File /usr/bin/torbrowser-launcher, line 996, in verify self.run_task() File /usr/bin/torbrowser-launcher, line 791, in run_task self.extract() File /usr/bin/torbrowser-launcher, line 1040, in extract self.run_task() File /usr/bin/torbrowser-launcher, line 795, in run_task self.run() File /usr/bin/torbrowser-launcher, line 1043, in run subprocess.Popen([self.common.paths['tbb']['start']]) File /usr/lib/python2.7/subprocess.py, line 679, in __init__ errread, errwrite) File /usr/lib/python2.7/subprocess.py, line 1259, in _execute_child raise child_exception exceptions.OSError: [Errno 13] Permission denied I assume this is due to me using apparmor, from the journal Aug 12 13:32:31 matrix kernel: audit: type=1400 audit(1407843151.609:1377): apparmor=DENIED operation=open profile=/usr/bin/torbrowser-launcher name=/usr/bin/python2.7 pid=20218 comm=file requested_mask=r denied_mask=r fsuid=1002 ouid=0 And here I'm lost... at least for the moment :) cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#756534: network-manager: IPv6 hop limit set to 0
I can confirm I'm getting the same issue. (Running Jessie/Sid, with network-manager Version: 0.9.4.0-10) It appears that network manager will directly change the sysctl values like thus: # sysctl -A |grep -i hop_limit net.ipv6.conf.all.hop_limit = 64 net.ipv6.conf.default.hop_limit = 64 net.ipv6.conf.eth0.hop_limit = 0 net.ipv6.conf.lo.hop_limit = 64 net.ipv6.conf.wlan0.hop_limit = 0 Once reset using a script or sysctl -w directly, once the interface is brought back up (unplugged-replugged or wifi reconnect) it will reset the value from 64 (or whatever) back to 0 I've had a look through the RedHat/Gnome NetworkManager git tree, but cannot see any fix for this as yet. I have been unable to confirm if its an issue with their source or if its a debian patch that has introduced this. Regards, Yinette. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646020: CVE-2011-3624
Package: ruby1.8 Dear maintainer, Recently you fixed one or more security problems and as a result you closed this bug. These problems were not serious enough for a Debian Security Advisory, so they are now on my radar for fixing in the following suites through point releases: squeeze (6.0.8) - use target oldstable Please prepare a minimal-changes upload targetting each of these suites, and submit a debdiff to the Release Team [0] for consideration. They will offer additional guidance or instruct you to upload your package. I will happily assist you at any stage if the patch is straightforward and you need help. Please keep me in CC at all times so I can track [1] the progress of this request. For details of this process and the rationale, please see the original announcement [2] and my blog post [3]. 0: debian-rele...@lists.debian.org 1: http://prsc.debian.net/tracker/646020/ 2: 201101232332.11736.th...@debian.org 3: http://deb.li/prsc Thanks, with his security hat on: -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757920: debian-installer: vesamenu.c32 is not a COM32R image
Package: debian-installer Version: Severity: normal Tags: d-i Dear Maintainer, * What led up to the situation? I want to install Debian/testing on a new computer. * What exactly did you do (or not do) that was effective (or ineffective)? I upgraded the PXE installer for testing using di-netboot-assistant, then I tried to install with it. * What was the outcome of this action? I expected the installer to run. * What outcome did you expect instead? The installer failed with the error vesamenu.c32 is not a COM32R image (written from memory). When I compare the vesamenu.c32 files in the testing and daily installers with the same files from stable and some Ubuntu version there are some differences: * The working files have a size about 150kB and are COM executable * The problematic files have a size of 26kB and are ELF 32-bit LSB shared object This is an example of a good file: http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20140316/images/netboot/debian-installer/amd64/boot-screens/vesamenu.c32 This is a bad file: http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20140802/images/netboot/debian-installer/amd64/boot-screens/vesamenu.c32 Regards, Kim Hansen -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757722: babeltrace: please enable build on sparc
- Original Message -
From: Sebastian Andrzej Siewior sebast...@breakpoint.cc
To: Jérémie Galarneau jeremie.galarn...@efficios.com
Cc: 757...@bugs.debian.org, Mathieu Desnoyers
mathieu.desnoy...@efficios.com
Sent: Monday, August 11, 2014 3:15:48 PM
Subject: Re: Bug#757722: babeltrace: please enable build on sparc
On 2014-08-11 14:31:08 [-0400], Jérémie Galarneau wrote:
It seems you don't have the following patch applied:
commit 6a0b6cd5133db9e3c72914d4e5dd7fc792360934
Author: Mathieu Desnoyers mathieu.desnoy...@efficios.com
Date: Wed Jul 16 10:58:48 2014 -0400
Fix: don't perform unaligned integer read/writes
Signed-off-by: Mathieu Desnoyers mathieu.desnoy...@efficios.com
I may be misunderstanding here, but we don't read floats directly in a
trace. We basically use the ctf_integer_read functions, as you can see
in _ctf_float_copy() in formats/ctf/types/floats.c
That patch should ensure the accesses are always aligned (see the use
of memcpy).
Have you spotted a place where an unaligned float access is performed?
No, this is all good. I *assumed* that you also do double handling that
way and therefore suggested use an alignment of 8. If you don't then it
is all good.
And the second bug I stumbled on is in test_ctf_writer:
|…
|ok 75 - Flush trace stream with one event
|ok 76 - Add a new event class to a stream class after writing an event
|ok 77 - Append 100 000 events to a stream
|
|Program received signal SIGSEGV, Segmentation fault.
|0xf7f6f778 in ctf_integer_write (ppos=0x70022328, definition=optimized
|out) at integer.c:325
|325
|bt_bitfield_write_be(mmap_align_addr(pos-base_mma)
|+
|(gdb) bt
|#0 0xf7f6f778 in ctf_integer_write (ppos=0x70022328,
|definition=optimized out) at integer.c:325
|#1 0xf7f88014 in bt_ctf_field_integer_serialize (field=0x700cd928,
|pos=0x70022328) at event-fields.c:1065
|#2 0xf7f88c88 in bt_ctf_field_serialize (field=0x700cd928,
|pos=0x70022328) at event-fields.c:660
|#3 0xf7f88f10 in bt_ctf_field_structure_serialize (field=0x700cd8c8,
|pos=0x70022328) at event-fields.c:1143
|#4 0xf7f88c88 in bt_ctf_field_serialize (field=0x700cd8c8,
|pos=0x70022328) at event-fields.c:660
|#5 0xf7f857bc in bt_ctf_stream_flush (stream=0x70022310) at
|stream.c:458
|#6 0x7000577c in packet_resize_test (stream_class=optimized out,
|stream=0x70022310, clock=0x70022108) at test_ctf_writer.c:698
|#7 0x70002750 in main (argc=optimized out, argv=0xd6f4) at
|test_ctf_writer.c:818
|
|= 0xf7f6f778 +600: ldub [ %l3 + %l1 ], %g4
|
|l1 0x10002 65538
|l3 0xf7bb4000 -138723328
and _bt_bitfield_write_le() had __ptr = 0xf7bb4000 and this_unit = 65538
|(gdb) print *((struct ctf_stream_pos *)ppos)-base_mma
|$3 = {page_aligned_addr = 0xf7bb4000, page_aligned_length = 131072, addr
|= 0xf7bb4000, length = 131072}
So it looks like it tried to load a byte from 0xf7bb4000 + 0x10002 and
this segfaulted. The mapping should be 131072 bytes in size it should
fit. This is confirmed by proc, too
|f7bb-f7bd -w-s 0001 fe:02 262357
|/tmp/ctfwriter_5uYQD4/test_stream_0
|Size:128 kB
So everything looks legal…
Thanks for looking into this! Any idea what could cause this to fail?
Not really. What I learnt is that you extend file's size with fallocate()
and then mmap() it for writing. The area that you write is covered by the
mmap() and file so it should be fine.
I try later to extract a minimal testcase out of it or replace it with
write() and see how that goes.
You might want to double-check the parameters passed to mmap() when mapping
this region. mmap(2) describes:
SIGSEGV
Attempted write into a region mapped as read-only.
Thoughts ?
Thanks,
Mathieu
Jérémie
Sebastian
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757919: simgear: FTBFS on big-endian archs
Package: simgear
Version: 3.2.0~git20140719+4a9125-1
Severity: serious
Control: tags -1 patch
https://buildd.debian.org/status/package.php?p=simgearsuite=experimental
Untested fix attached.
Description: Actually enable the big-endian fallback
Author: Rebecca Palmer rebecca_pal...@zoho.com
WORDS_BIGENDIAN isn't actually defined anywhere, causing md5.c to
default to little-endian, and fail tests if this is wrong:
https://buildd.debian.org/status/logs.php?pkg=simgearver=3.2.0~git20140719%2B4a9125-1suite=experimental
Forwarded: can't be as it stands (probably breaks Windows/MSVC)
--- simgear-3.2.0~git20140719+4a9125.orig/simgear/package/md5.c
+++ simgear-3.2.0~git20140719+4a9125/simgear/package/md5.c
@@ -158,7 +158,7 @@ SG_MD5Transform(u_int32_t state[4], cons
{
u_int32_t a, b, c, d, in[MD5_BLOCK_LENGTH / 4];
-#ifndef WORDS_BIGENDIAN
+#if __BYTE_ORDER__==__ORDER_LITTLE_ENDIAN__
memcpy(in, block, sizeof(in));
#else
for (a = 0; a MD5_BLOCK_LENGTH / 4; a++) {
@@ -247,4 +247,4 @@ SG_MD5Transform(u_int32_t state[4], cons
state[1] += b;
state[2] += c;
state[3] += d;
-}
\ No newline at end of file
+}
Bug#757903: syslog-ng-core: invoke-rc.d: initscript syslog-ng, action stop failed.
Sebastian Ramacher sramac...@debian.org writes: Package: syslog-ng-core Version: 3.5.6-1 Severity: grave Justification: renders package unusable Today the upgrade from 3.5.5-2 to 3.5.6-1 failed with: | Processing triggers for syslog-ng-core (3.5.6-1) ... | Job for syslog-ng.service canceled. | invoke-rc.d: initscript syslog-ng, action stop failed. | dpkg: error processing package syslog-ng-core (--configure): | subprocess installed post-installation script returned error exit status 1 Uncommenting invoke-rc.d syslog-ng stop || exit $? in line 6 of the postinst script and running apt install -f fixes the issue and lets the installation complete. I've also seen this issue while installing syslog-ng-core for the first time on another system. Both systems are running systemd if that matters. Let me know if you want more info. My other system waits to be upgraded. What does systemctl status syslog-ng.service print? -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757920: debian-installer: vesamenu.c32 is not a COM32R image
Hi Kim, and thanks for your detailed bug report. Kim R. T. Hansen k...@rthansen.dk (2014-08-12): Package: debian-installer Version: Severity: normal Tags: d-i Dear Maintainer, * What led up to the situation? I want to install Debian/testing on a new computer. * What exactly did you do (or not do) that was effective (or ineffective)? I upgraded the PXE installer for testing using di-netboot-assistant, then I tried to install with it. * What was the outcome of this action? I expected the installer to run. * What outcome did you expect instead? The installer failed with the error vesamenu.c32 is not a COM32R image (written from memory). When I compare the vesamenu.c32 files in the testing and daily installers with the same files from stable and some Ubuntu version there are some differences: * The working files have a size about 150kB and are COM executable * The problematic files have a size of 26kB and are ELF 32-bit LSB shared object This is an example of a good file: http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20140316/images/netboot/debian-installer/amd64/boot-screens/vesamenu.c32 This is a bad file: http://ftp.fr.debian.org/debian/dists/testing/main/installer-amd64/20140802/images/netboot/debian-installer/amd64/boot-screens/vesamenu.c32 The fact you're using di-netboot-assistant is interesting, maybe it would have needed an update for the syslinux 6 transition? The code can be viewed online here: http://anonscm.debian.org/cgit/d-i/netboot-assistant.git/tree/di-netboot-assistant#n236 It seems there's some *.c32-specific handling, and there's even a mention of a (probably previous) transition for menu related files. I think we would have had more reports if PXE was broken in the general case so I suspect this might be a regression only in the d-i netboot assistant case. I'm adding Ron since he looked quite closely at d-i + syslinux lately, so he might have some expertise to share here. ;) Mraw, KiBi. signature.asc Description: Digital signature
Bug#757835: nfs-kernel-server: after update 1.2.8-6-1.2.8-8 rpc.mountd starts crashing
Package: nfs-kernel-server Version: 1:1.2.8-6 Followup-For: Bug #757835 Dear Maintainer, I got segfaults too, below are the last working versions, anything newer segfaults, whether I upgrade libtirpc1 or nfs-kernel-server. For those who need quick fix/workaround: deb http://snapshot.debian.org/archive/debian/20140808/ unstable main contrib non-free ... and downgrade to libtirpc1 0.2.4-1 and nfs-kernel-server 1:1.2.8-6. Have a nice day! -- Package-specific info: -- rpcinfo -- program vers proto port service 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 1000241 udp 8 status 1000241 tcp 56008 status 132 tcp 2049 nfs 133 tcp 2049 nfs 134 tcp 2049 nfs 1002272 tcp 2049 1002273 tcp 2049 132 udp 2049 nfs 133 udp 2049 nfs 134 udp 2049 nfs 1002272 udp 2049 1002273 udp 2049 1000211 udp 34725 nlockmgr 1000213 udp 34725 nlockmgr 1000214 udp 34725 nlockmgr 1000211 tcp 34779 nlockmgr 1000213 tcp 34779 nlockmgr 1000214 tcp 34779 nlockmgr 151 udp 47250 mountd 151 tcp 48360 mountd 152 udp 54973 mountd 152 tcp 60512 mountd 153 udp 39291 mountd 153 tcp 34776 mountd -- /etc/default/nfs-kernel-server -- RPCNFSDCOUNT=8 RPCNFSDPRIORITY=0 RPCMOUNTDOPTS=--manage-gids NEED_SVCGSSD= RPCSVCGSSDOPTS= -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (750, 'stable'), (600, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.4-trunk-686-pae (SMP w/4 CPU cores) Locale: LANG=cs_CZ.utf8, LC_CTYPE=cs_CZ.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages nfs-kernel-server depends on: ii libblkid1 2.20.1-5.3 ii libc6 2.19-7 ii libcap2 1:2.22-1.2 ii libgssglue1 0.4-2 ii libsqlite3-0 3.8.5-2 ii libtirpc1 0.2.4-1 ii libwrap0 7.6.q-25 ii lsb-base 4.1+Debian13 ii nfs-common1:1.2.8-6 ii ucf 3.0030 nfs-kernel-server recommends no packages. nfs-kernel-server suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756534: Info received (network-manager: IPv6 hop limit set to 0)
Actually, doing a little further poking around... It looks like network-manager will set the hop limit based on what is given by the router in the v6 router advertisement. In my case, the local gateway will specify the hop-limit as 0 in its advertisement, and network-manager will take it as gospel. I reckon if the value received in a router advertisement is 0, it should default to something like 64. Best Regards, Yinette -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757921: perl 5.20 vendorarch path changes from usr/lib/perl5 to usr/lib/triplet/perl5
Package: lintian
Version: 2.5.25
Severity: normal
Tags: patch
User: debian-p...@lists.debian.org
Usertags: perl-5.20-transition
Perl 5.20 sets the library path to /usr/lib/triplet/perl5/5.20.
Lintian has a couple of related checks which use usr/lib/perl5 and will
stop triggering errors/warnings when packages are built with perl 5.20.
$ git grep -c usr/lib/perl5
checks/binaries.desc:1
checks/binaries.pm:1
checks/files.desc:1
checks/files.pm:3
debian/changelog:2
po4a/po/checks/checks.pot:2
po4a/po/checks/da.po:2
t/tests/binaries-missing-depends-on-xapi/debian/Makefile:2
t/tests/files-foo-in-bar/debian/debian/install:1
t/tests/files-foo-in-bar/tags:1
t/tests/legacy-filenames/debian/debian/rules:17
t/tests/legacy-filenames/tags:22
t/tests/legacy-libbaz/debian/debian/rules:6
t/tests/legacy-libbaz/tags:4
The first of the patches addresses this by accounting for the
possibility that there is a tripled directory between 'usr/lib' and
'perl5'. The second patch adapts the tests.
Thanks for considering,
dam
-- 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.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages lintian depends on:
ii binutils 2.24.51.20140807-1
ii bzip2 1.0.6-7
ii diffstat 1.58-1
ii file 1:5.19-1
ii gettext0.19.2-1
ii hardening-includes 2.5
ii intltool-debian0.35.0+20060710.1
ii libapt-pkg-perl0.1.29+b1
ii libarchive-zip-perl1.37-2
ii libclass-accessor-perl 0.34-1
ii libclone-perl 0.37-1
ii libdigest-sha-perl 5.92-1
ii libdpkg-perl 1.17.11
ii libemail-valid-perl1.194-1
ii libfile-basedir-perl 0.03-1
ii libipc-run-perl0.92-1
ii liblist-moreutils-perl 0.33-2
ii libparse-debianchangelog-perl 1.2.0-1
ii libtext-levenshtein-perl 0.09-1
ii libtimedate-perl 2.3000-2
ii liburi-perl1.64-1
ii man-db 2.6.7.1-1
ii patchutils 0.3.3-1
ii perl [libdigest-sha-perl] 5.18.2-7
ii t1utils1.37-2
Versions of packages lintian recommends:
ii libautodie-perl 2.25-1
ii libperlio-gzip-perl 0.18-3
ii perl-modules [libautodie-perl] 5.18.2-7
Versions of packages lintian suggests:
ii binutils-multiarch 2.24.51.20140807-1
ii dpkg-dev 1.17.11
ii libhtml-parser-perl3.71-1+b1
ii libtext-template-perl 1.46-1
ii libyaml-perl 0.98-1
ii xz-utils 5.1.1alpha+20120614-2
-- no debconf information
From 25d3df70f04be1c57c340cb96e9e0131bcf9c066 Mon Sep 17 00:00:00 2001
From: Damyan Ivanov Damyan Ivanov d...@debian.org
Date: Tue, 12 Aug 2014 10:21:14 +
Subject: [PATCH 1/2] adapt to library patch changes with perl 5.20
replace usr/lib/perl5 with usr/lib/(?:[^/]+/)?/perl5
the new vendorarch patch is /usr/lib/triplet/perl5/5.20
---
checks/binaries.desc | 2 +-
checks/binaries.pm| 2 +-
checks/files.desc | 2 +-
checks/files.pm | 6 +++---
po4a/po/checks/checks.pot | 4 ++--
po4a/po/checks/da.po | 4 ++--
6 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/checks/binaries.desc b/checks/binaries.desc
index a5f3c77..280aee4 100644
--- a/checks/binaries.desc
+++ b/checks/binaries.desc
@@ -216,7 +216,7 @@ Tag: missing-dependency-on-perlapi
Severity: serious
Certainty: certain
Ref: perl-policy 4.4.2
-Info: This package includes a *.so file in tt/usr/lib/perl5/tt,
+Info: This package includes a *.so file in tt/usr/lib/.../perl5/tt,
normally indicating that it includes a binary Perl module. Binary Perl
modules must depend on perlapi-$Config{version} (from the Config module).
If the package is using debhelper, this problem is usually due to a
diff --git a/checks/binaries.pm b/checks/binaries.pm
index c57e431..42860fe 100644
--- a/checks/binaries.pm
+++ b/checks/binaries.pm
@@ -391,7 +391,7 @@ sub run {
next if $type eq 'udeb';
# Perl library?
-if ($file =~ m,^usr/lib/perl5/.*\.so$,) {
+if ($file =~ m,^usr/lib/(?:[^/]+/)?perl5/.*\.so$,) {
$has_perl_lib = 1;
}
diff --git a/checks/files.desc b/checks/files.desc
index 9036101..313729e 100644
--- a/checks/files.desc
+++ b/checks/files.desc
@@ -715,7 +715,7 @@ Tag: package-installs-nonbinary-perl-in-usr-lib-perl5
Severity: normal
Certainty: certain
Info: Architecture-independent Perl code should be placed in
- tt/usr/share/perl5/tt, not tt/usr/lib/perl5/tt
+ tt/usr/share/perl5/tt, not
Bug#754392: weston: segfault on exit when cms-colord.so is loaded
Package: weston Followup-For: Bug #754392 Hi, I ran weston using valgrind and the logs can be found at: https://people.debian.org/~bigon/weston_vg.log (warning ~40M) I'm seeing the following thing (in addition to the mesa leaks): ==13455== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s) ==13455==at 0x5B160CD: ??? (syscall-template.S:81) ==13455==by 0x4E3BFE8: wl_connection_flush.part.4 (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.1.0) ==13455==by 0x4E3A1FF: wl_display_flush_clients (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.1.0) ==13455==by 0x4E3A257: wl_display_run (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.1.0) ==13455==by 0x411610: main (compositor.c:4316) ==13455== Address 0x64c1dd3 is 4,131 bytes inside a block of size 16,424 alloc'd ==13455==at 0x4C284C0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==13455==by 0x4E3C111: wl_connection_create (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.1.0) ==13455==by 0x4E3A822: wl_client_create (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.1.0) ==13455==by 0x40811E: weston_client_launch (compositor.c:306) ==13455==by 0x41CCF2: launch_input_method (text-backend.c:898) ==13455==by 0x41CE20: handle_seat_created (text-backend.c:935) ==13455==by 0x411774: wl_signal_emit (wayland-server.h:260) ==13455==by 0x416837: weston_seat_init (input.c:2221) ==13455==by 0x680B3BF: x11_input_create (compositor-x11.c:315) ==13455==by 0x680E2A5: x11_compositor_create (compositor-x11.c:1539) ==13455==by 0x680E84F: backend_init (compositor-x11.c:1646) ==13455==by 0x4112BB: main (compositor.c:4240) ==13455== When the plugin is NOT loaded (https://people.debian.org/~bigon/weston_vg2.log) less mesa leaks and in this case I actually see invalid writes. 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#757650: [Pkg-sysvinit-devel] Bug#757650: override: sysvinit:admin/optional sysvinit-core:admin/extra
On Mon, 11 Aug 2014, Cyril Brulebois wrote: Michael Biebl bi...@debian.org (2014-08-11): That is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754987 https://lists.debian.org/debian-user/2014/07/msg01509.html I know a workaround, but haven't figured out the underlying cause yet. FWIW I spent some time on #debian-systemd and idly noticed some mentions of a boot-time timeout; when Ben mentioned net.agent I finally connected the dots and we stopped spending more time on it. FWIW, make sure CONFIG_FW_LOADER_USER_HELPER is *NOT* set in the kernel config. I didn't check the reports above, so it is possible that this has already been checked. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748386: [Pkg-running-devel] Bug#748386: subsurface: diff for NMU version 4.0.3-2.1
On 12. August 2014 09:19:49 MESZ, Christian PERRIER bubu...@debian.org wrote: Quoting Tobias Frost (t...@debian.org): tags 748386 + pending thanks Dear maintainer, I've prepared an NMU for subsurface (versioned as 4.0.3-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Thanks for your work (as pkg-running team member, I leave priority to Sylvestre Ledru, who is probably busy elsewhere...which explains why nothing happened with that issue). I included the NMU changes to our git repository and tagged the release, so please push the NMU the DELAYED/0..or let's just wait for 5 days...:-) Ok, Just uploaded. -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751049: proofgeneral: FTBFS - pdfetex (file cm-super-t1.enc): cannot open encoding file for reading
Control: tags -1 +unreproducible Hi, As he said, it can be built fine now. (Probably changes in TeX caused this build failure but now it was gone...) So, tagged as unreproducible. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
