Bug#702976: epiphany-browser: domainname not checked on https
On Tue, 2013-07-02 at 08:39 +0200, Moritz Muehlenhoff wrote: severity 702976 important Wow... must really look bad security wise in Debian... Not only is it not obviously documented that webkit browsers are not security supported at all http://www.debian.org/security/ http://www.debian.org/security/faq (assuming that any users would expect that stuff from main is not supported, and would therefore even search for such exceptions). But also you do hide away these bugs,... with higher severity people would at least have a chance to notice it via apt-listbugs. Apart from that, the severity simply does not fit as it's defined... Really outrageous. Guess it becomes time that someone starts an independent and uncensored security blog about Debian... o.O Especially since there is an easy fix available, disable https in epiphany. smime.p7s Description: S/MIME cryptographic signature
Bug#714593: same here
This bug hit me too. This is a really bad bug. This also makes me quite disappointed at how fragile gnome-shell is. How can a seemingly minor application like bluetooth totally break gnome-shell? The first computer this happened on didn't even have a bluetooth device yet if I try to remove gnome-bluetooth, it wants to remove a lot of other applications I need. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712861: patches
GnomeBluetooth.patch cannot be applied without applying
60-gnome-bluetooth-3.8.patch before.
I've unified patches, this one should work alone.
--- js/ui/status/bluetooth.js
+++ js/ui/status/bluetooth.js
@@ -5,6 +5,7 @@
const GLib = imports.gi.GLib;
const Gio = imports.gi.Gio;
const GnomeBluetoothApplet = imports.gi.GnomeBluetoothApplet;
+const GnomeBluetooth = imports.gi.GnomeBluetooth;
const Gtk = imports.gi.Gtk;
const Lang = imports.lang;
const Mainloop = imports.mainloop;
@@ -36,11 +37,11 @@
this._applet.connect('notify::killswitch-state', Lang.bind(this, this._updateKillswitch));
this._killswitch.connect('toggled', Lang.bind(this, function() {
let current_state = this._applet.killswitch_state;
-if (current_state != GnomeBluetoothApplet.KillswitchState.HARD_BLOCKED
-current_state != GnomeBluetoothApplet.KillswitchState.NO_ADAPTER) {
+if (current_state != GnomeBluetooth.KillswitchState.HARD_BLOCKED
+current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER) {
this._applet.killswitch_state = this._killswitch.state ?
-GnomeBluetoothApplet.KillswitchState.UNBLOCKED:
-GnomeBluetoothApplet.KillswitchState.SOFT_BLOCKED;
+GnomeBluetooth.KillswitchState.UNBLOCKED:
+GnomeBluetooth.KillswitchState.SOFT_BLOCKED;
} else
this._killswitch.setToggleState(false);
}));
@@ -94,10 +95,10 @@
_updateKillswitch: function() {
let current_state = this._applet.killswitch_state;
-let on = current_state == GnomeBluetoothApplet.KillswitchState.UNBLOCKED;
-let has_adapter = current_state != GnomeBluetoothApplet.KillswitchState.NO_ADAPTER;
-let can_toggle = current_state != GnomeBluetoothApplet.KillswitchState.NO_ADAPTER
- current_state != GnomeBluetoothApplet.KillswitchState.HARD_BLOCKED;
+let on = current_state == GnomeBluetooth.KillswitchState.UNBLOCKED;
+let has_adapter = current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER;
+let can_toggle = current_state != GnomeBluetooth.KillswitchState.NO_ADAPTER
+ current_state != GnomeBluetooth.KillswitchState.HARD_BLOCKED;
this._killswitch.setToggleState(on);
if (can_toggle)
Bug#703967: close
Fixed in r925 and in Debian package upload svn r1004 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675577: FTBFS(es) caused by fixing this bug...
Dear maintainer(s), it would be nice if you have let know the r-b-d of your package when you introduce such intrusive change. This change broke (at least) php5 builds which expects gmp.h to be found at $i/include/gmp.h. O. -- Ondřej Surý ond...@sury.org
Bug#714729: linux-image-3.2.0-4-amd64: Kernel trace swapper: page allocation failure in combination with Intel ixgbe
Control: fixed -1 3.4.1-1~experimental.1 On Tue, 2013-07-02 at 10:42 +0200, Udo Lembke wrote: Package: src:linux Version: 3.2.46-1 Severity: important Tags: upstream Dear Maintainer, we running three nodes as ceph-cluster (0.61.3-1~bpo70+1) and sometimes (app. once or twice a day) we got an kernel trace which seems to be related to the Intel 10GB-NIC (ixgbe module). The same happens before update (from: SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux) and also occur with an actual self-compiled ixgbe-module (3.15.1). The page allocation failure are not only swapper related. Also ceph-osd and kswapd0 trigger this problem. To avoid the kernel-trace I use the sysctl-value vm.min_free_kbytes = 337920 but without luck. You could try increasing it further... We had also the issue (perhaps not related to this bug) that the whole host freezed and the NIC flood the 10-GB-Port so that the complete switch (and the compled network) are freezed. Please report only one issue in each bug report. Since that the ceph-cluster are isolated for test in an extra network. We will switch to productive mode if the kerneltraces are gone. [...] I believe the driver stopped making order-2 allocations in Linux 3.4, with this change: commit f800326dca7bc158f4c886aa92f222de37993c80 Author: Alexander Duyck alexander.h.du...@intel.com Date: Sat Mar 3 02:35:52 2012 + ixgbe: Replace standard receive path with a page based receive This should fix the allocation failures you're seeing. This might be backported to 3.2 if we have some other reason to update the ixgbe driver. Otherwise it will not be. Ben. -- Ben Hutchings Life would be so much easier if we could look at the source code. signature.asc Description: This is a digitally signed message part
Bug#714746: 0ad: consider adding newer versions in wheezy-backports
Package: 0ad Version: 0.0.13-2+b1 Severity: wishlist Dear Maintainer, 0ad is still in early development, please consider adding newer versions of the game in wheezy-backports. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages 0ad depends on: ii 0ad-data 0.0.13-1 ii 0ad-data-common0.0.13-1 ii dpkg 1.16.10 ii libboost-filesystem1.49.0 1.49.0-4 ii libboost-signals1.49.0 1.49.0-4 ii libc6 2.17-6 ii libcurl3-gnutls7.31.0-2 ii libenet2a 1.3.8+ds-2 ii libgcc11:4.8.1-2 ii libgl1-mesa-glx [libgl1] 8.0.5-6 ii libjpeg8 8d-1 ii libmozjs185-1.01.8.5-1.0.0+dfsg-4+b1 ii libnvtt2 2.0.8-1+dfsg-3 ii libopenal1 1:1.14-4 ii libpng12-0 1.2.49-4 ii libsdl1.2debian1.2.15-5 ii libstdc++6 4.8.1-2 ii libvorbisfile3 1.3.2-1.3 ii libwxbase2.8-0 2.8.12.1-13 ii libwxgtk2.8-0 2.8.12.1-13 ii libx11-6 2:1.6.0-1 ii libxcursor11:1.1.13-1+deb7u1 ii libxml22.9.1+dfsg1-2 ii zlib1g 1:1.2.8.dfsg-1 0ad recommends no packages. 0ad 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#714694: linux-image-amd64: Could not start debian
Control: tag -1 moreinfo On Tue, 2013-07-02 at 09:24 +0200, Sébastien Dailly wrote: Le 2013-07-01 23:18, Ben Hutchings a écrit : Thanks for answering so quickly, How is the root disk attached (SATA, PATA, USB)? The disk is SATA2 Have you tried using the 'rootdelay=N' parameter (N is number of seconds to wait for the root device to be ready) to the kernel command line? I've tried 'rootdelay=15' and indeed, this was enought for allowing the computer to boot. But this leads to some questions : 1) is this the correct behavior ? I'm booting debian on this PC since the 2.6.39 kernel (maybe older ?), and I've never encountered this problem… It's not correct. I was just trying to establish whether the kernel could access the disk at all. 2) should I fear before upgrading other computers ? How could I check if this regression can happen ? Thanks for the help and the support. Sorry, I don't know. Ben. -- Ben Hutchings Life would be so much easier if we could look at the source code. signature.asc Description: This is a digitally signed message part
Bug#714694: linux-image-amd64: Could not start debian
Control: tag -1 - moreinfo On Tue, 2013-07-02 at 14:24 +0100, Ben Hutchings wrote: Control: tag -1 moreinfo [...] Sorry, not actually expecting more information from you at the moment. Ben. -- Ben Hutchings Life would be so much easier if we could look at the source code. signature.asc Description: This is a digitally signed message part
Bug#711848: closed by Didier Raboud o...@debian.org (Bug#711848: fixed in cups 1.6.2-10)
Vincent, On 2013-06-27, at 6:06 PM, Vincent Lefevre vinc...@vinc17.net wrote: ... Then I assume that lpq could use cupsGetNamedDest like lp and lpr (unless the -a option is given, of course). But that would be a separate feature request. ... Well, I meant that, for instance, lpq and lpr use two different methods to get the default destination, which give here different results. Even if new features are added, the code could remain similar between different commands. I'll track this issue in the same bug and make them all use cupsGetNamedDest to get the default printer. _ Michael Sweet, Senior Printing System Engineer, PWG Chair -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669712: [freeplane] RE: freeplane: Visual corruption after scrolling mindmap
On 01/07/13 21:23, Felix Natter wrote: Omega Weapon omegap...@gmail.com writes: This looks like you're still using OpenJDK6! You should definitely try openjdk-7: http://packages.debian.org/search?keywords=openjdk-7-jresearchon=namessuite=allsection=all Now this was a WTF moment. I've already said that I'm using OpenJDK7 earlier. So, I investigated how the bug script runs, and how freeplane works out the Java command - the java-wrappers package is responsible for JAVA_CMD, and this returns the v6 runtime currently. Luckily for me I pay attention to what updates day to day (I read the changelogs every time) - that package recently upgraded to 0.1.26 - I installed the 0.1.25 version, and suddenly JAVA_CMD returns the correct v7 runtime! Bugs everywhere! Running freemind again with the software rendering with the correct v7 runtime is fine - so this is just an old irrelevant bug in OpenJDK6. I will report the bug I have discovered against java-wrappers now, and uninstall the v6 runtime since its probably no longer needed. Thanks for your help - I would not have suspected something messing around with my runtime version (this was configured at v7 by Debian alternates months ago). -- Libre software on Github: https://github.com/OmegaPhil FSF member #9442 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683061: [pkg-ntp-maintainers] Bug#683061: bug report #683061
On Tue, Jul 2, 2013 at 1:59 PM, Kurt Roeckx k...@roeckx.be wrote: Do you know NXDOMAIN returns? I think it returns just the same? I don't immediately see how getaddrinfo() alone can be used to tell whether or not an actual NXDOMAIN was received. A test with a small C program reveals that retval -11 errno 2 is returned both in the NXDOMAIN case and in the case where no nameservers could be found. So ntpd should just keep trying to resolv invalid hostnames? That may seem like a waste of resources, but * Computers are mobile these days and DNS also changes from the perspective of those computers. A laptop may connect sometimes to a LAN where the domain name ntp.somecorp.private resolves to the address of a time server. On other LANs this name does not exist. * If the retry period is on the order of seconds then the resources used aren't very significant. * If the name of the time server never resolves and this is a problem then it's the admin's fault for failing to configure ntpd properly. I suppose the question really is, when should the admin be notified that there is a problem? Good question. Is there something wrong with ntpd just logging resolution failures and leaving it at that? Anyway, you be the judge. Best wishes, -- Thomas
Bug#714694: linux-image-amd64: Could not start debian
On Tue, 2 Jul 2013, Ben Hutchings wrote: Control: tag -1 - moreinfo On Tue, 2013-07-02 at 14:24 +0100, Ben Hutchings wrote: Control: tag -1 moreinfo [...] Sorry, not actually expecting more information from you at the moment. I'm available if you need more information. Do not hesitate to ask me ! Thanks, -- Sébastien Dailly
Bug#714725: [Pkg-postgresql-public] Bug#714725: Consider setting APT::NeverAutoRemove::postgresql-* in apt.conf
Re: Peter Eisentraut 2013-07-02 51d2bd16.6020...@debian.org 3) would be needed if we decide that we also need to care about extension modules that should not be removed on dist-upgrade. (Though I tend to think these would usually be manually installed. But we might have the same metapackage-with-changing-dependency problem there as well.) It should be 3), because otherwise the postgresql-contrib-x.y package will be removed and you won't be able to dump your database if it uses any data type provided in a contrib module. The same goes for things like postgresql-x.y-ip4r. My thinking was that if you have any -contrib package installed, it will be marked as manually installed and won't be removed automatically anyway. Same for -ip4r and friends. Marking all postgresql-* packages for NeverAutoRemove might also be a bit overzealous, do we want to restrict this to postgresql-*$laststableversion*? Do we want to drop the NeverAutoRemove for $laststableversion once the cluster got upgraded? (This sounds like the solution could get way too complex, I want a simple thing.) Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#709027: [php-maint] Bug#709027: php5: libapache2-mod-php5filter is installed in preference to libapache2-mod-php5
Russ Kevin, This is not entirely a php5 fault, so I am still unsure how to fix this bug in stable: See http://lists.debian.org/caaz6_fdjfr7jvnx6b0wgttjpunbhhsmzuw48chmn2kmf-de...@mail.gmail.com Suggestions welcome. O. On Tue, Jul 2, 2013 at 4:31 AM, Russ Allbery r...@debian.org wrote: Package: libapache2-mod-php5filter Version: 5.5.0+dfsg-4 Followup-For: Bug #709027 The same thing happened to me during an upgrade from the testing version of PHP to the unstable version just now. The command-line that I ran was: aptitude -t unstable install libremctl1 remctl-client remctl-server \ ruby-remctl python-remctl php5-remctl libnet-remctl-perl since I was actually testing the remctl packages. That did the normal aptitude thing of prompting whether I wanted to remove php5-cli and libremctl-dev or upgrade them and I choose to upgrade them, which resulted in the following solution: [INSTALL, DEPENDENCIES] libapache2-mod-php5filter:i386 [INSTALL, DEPENDENCIES] php5-json:i386 [UPGRADE] libnet-remctl-perl:i386 3.4-2 - 3.5-1 [UPGRADE] libremctl-dev:i386 3.4-2 - 3.5-1 [UPGRADE] libremctl1:i386 3.4-2 - 3.5-1 [UPGRADE] libxml2:i386 2.8.0+dfsg1-7+nmu1 - 2.9.1+dfsg1-2 [UPGRADE] php5-cli:i386 5.4.4-15.1 - 5.5.0+dfsg-4 [UPGRADE] php5-common:i386 5.4.4-15.1 - 5.5.0+dfsg-4 [UPGRADE] php5-remctl:i386 3.4-2 - 3.5-1 [UPGRADE] python-remctl:i386 3.4-2 - 3.5-1 [UPGRADE] remctl-client:i386 3.4-2 - 3.5-1 [UPGRADE] remctl-server:i386 3.4-2 - 3.5-1 [UPGRADE] ruby-remctl:i386 3.4-2 - 3.5-1 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.8-2-686-pae (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libapache2-mod-php5filter depends on: ii apache2 2.4.4-6 ii apache2-bin [apache2-api-20120211] 2.4.4-6 ii libbz2-1.0 1.0.6-4 ii libc6 2.17-6 ii libcomerr2 1.42.5-1.1 ii libdb5.15.1.29-6 ii libgssapi-krb5-21.10.1+dfsg-5 ii libk5crypto31.10.1+dfsg-5 ii libkrb5-3 1.10.1+dfsg-5 ii libmagic1 1:5.14-2 ii libonig25.9.1-1 ii libpcre31:8.31-2 ii libqdbm14 1.8.78-2 ii libssl1.0.0 1.0.1e-3 ii libxml2 2.9.1+dfsg1-2 ii mime-support3.54 ii php5-common 5.5.0+dfsg-4 ii tzdata 2013c-2 ii ucf 3.0027 ii zlib1g 1:1.2.8.dfsg-1 libapache2-mod-php5filter recommends no packages. Versions of packages libapache2-mod-php5filter suggests: pn php-pear none -- Configuration Files: /etc/apache2/mods-available/php5filter.load changed [not included] -- no debconf information ___ pkg-php-maint mailing list pkg-php-ma...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint -- Ondřej Surý ond...@sury.org
Bug#712534: change of tags / fixed
tags 712534 + fixed thanks Fixed, waiting for upload. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614893: please remove this beep
I have a HP mini on a debian jessie (testing) and I found no way to disable this beep on shutdown/restart. Please solve this annoing problem, remove this beep from the shutdown sequence. Have a great day Piviul -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714747: O: wmitime -- clock dock app showing time and internet time
Package: wnpp Severity: normal Description-en: clock dock app showing time and internet time WMitime is clock dock app, which shows standard time, date. The unique feature is that it can also show Internet time with notation @TIME. See http://www.swatch.com/ for more about Internet time. I no longer have use for this application. The package is in otherwise in a good shape: standard 3.8.3, debhelper 7, pacakge format 3.0 (quilt) For a prospective new maintainer: Start maintaining the package from Git[*] git clone $lo...@git.debian.org:/git/collab-maint/wmitime.git PTS: http://packages.qa.debian.org/w/wmitime.html Jari [*] http://wiki.debian.org/Alioth/Git http://wiki.debian.org/Alioth/Git#Collab_Maint_project -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683061: [pkg-ntp-maintainers] Bug#683061: Bug#683061: bug report #683061
On Tue, Jul 02, 2013 at 03:32:13PM +0200, Thomas Hood wrote: On Tue, Jul 2, 2013 at 1:59 PM, Kurt Roeckx k...@roeckx.be wrote: Do you know NXDOMAIN returns? I think it returns just the same? I don't immediately see how getaddrinfo() alone can be used to tell whether or not an actual NXDOMAIN was received. A test with a small C program reveals that retval -11 errno 2 is returned both in the NXDOMAIN case and in the case where no nameservers could be found. And I think that a nameserver not found should never have resulted in that return value, since it's not a permanent error. So ntpd should just keep trying to resolv invalid hostnames? That may seem like a waste of resources, but * Computers are mobile these days and DNS also changes from the perspective of those computers. A laptop may connect sometimes to a LAN where the domain name ntp.somecorp.private resolves to the address of a time server. On other LANs this name does not exist. Do you expect the DHCP server on the LAN then to set that ntp server? Currently this would now result in ntpd getting restarted by dhcp and should get you a working ntp server. If it's not configured by DHCP, that means that the admin changed the default. This would now probably only work when it never got a error that it's an invalid hostname. And that's probably only the case when the network goes up the first time when on that LAN. But I see no good reason not to use DHCP for this. * If the retry period is on the order of seconds then the resources used aren't very significant. That of course depends on the number of misconfigured clients, but probably shouldn't really be an issue. This can even be a long delay in the ussual case. I suppose the question really is, when should the admin be notified that there is a problem? Good question. Is there something wrong with ntpd just logging resolution failures and leaving it at that? But do you want it to log this every second? Or do you have some trigger for when it should log this again? (For instance on interface/ip change.) Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714750: [ctn] build-depends on lesstif2-dev but does not build with lesstif2
Source: ctn Version: 3.0.6-13 Severity: normal Tags: patch Hi maintainer Ctn has a build dependency on lesstif2-dev, but does not seem to actually build with lesstif2 (Motif). None of the binary packages built from ctn depend on lesstif2 and running 'ldd * | grep libXm' in the binary package's usr/bin directory shows no matches. I was unable to find anything in the changelogs that indicated this was intentional, so either the configure options could to be fixed to build with Motif, or fixed to build without the lesstif2-dev dependency. Regards Graham -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714748: [java-wrappers] require_java_runtime no longer returns correct OpenJDK7 install
Package: java-wrappers Version: 0.1.26 Severity: normal It looks like your change in #711850 (mailto:711...@bugs.debian.org) has bricked detection of OpenJDK7 running alongside OpenJDK6. Currently I have both libre runtimes installed (no proprietary Java), with alternatives configured to use v7. After upgrading to 0.1.26, 'require_java_runtime java6' returns the v6 runtime rather than v7 via JAVA_CMD - this caused me to think there are further bugs in freeplane's Java enviroment (I note the bug you fixed is for freemind, which freeplane is a fork of ;)) - see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669712#80 I plan to uninstall OpenJDK6 as its likely no longer needed now, but am happy to keep it in place to test the fix for this bug when it comes. Thanks --- System information. --- Architecture: amd64 Kernel: Linux 3.9-1-amd64 Debian Release: jessie/sid 990 testing security.debian.org 990 testing ftp.uk.debian.org 500 unstableignorantguru.github.com 500 stable www.getgnash.org 500 quodlibet-unstable www.student.tugraz.at 1 experimentalftp.uk.debian.org --- Package information. --- Depends (Version) | Installed ==-+-=== unzip | 6.0-9 Package's Recommends field is empty. Package's Suggests field is empty. -- Libre software on Github: https://github.com/OmegaPhil FSF member #9442 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714749: O: fcrackzip -- password cracker for zip archives
Package: wnpp Severity: normal Description: password cracker for zip archives fcrackzip is a fast password cracker partly written in assembler. It is able to crack password protected zip files with brute force or dictionary based attacks, optionally testing with unzip its results. It can also crack cpmask'ed images. I no longer have use for this application. The package is in otherwise in a good shape: standard 3.9.4, debhelper 9, Pacakging format 3.0 (quilt), Copyright format 1.0 For a prospective new maintainer: Start maintaining the package from Git[*] git clone $lo...@git.debian.org:/git/collab-maint/fcrackzip.git PTS: http://packages.qa.debian.org/f/fcrackzip.html Jari [*] http://wiki.debian.org/Alioth/Git http://wiki.debian.org/Alioth/Git#Collab_Maint_project -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714751: O: wuzzah -- inobtrusively monitor your friends
Package: wnpp Severity: normal Description: inobtrusively monitor your friends The idea: you have friends on a system, and you want to know when they log on and off when you're logged on. what's more, maybe you're tired of throwing together crappy/clunky who(1)/w(1)/finger(1) commands in obfuscated shell/perl scripts that only half do the job anyway. . wuzzah is a program that selectively scans a system's utmpx records (where logins are stored, among other things), keeping an eye out for your friends logging in and out, taking customizable actions on events. wuzzah is small, fast, efficient, and written in C. I no longer have use for this application. The package is in otherwise in a good shape: standard 3.9.3, debhelper 9. Packaging format 3.0 (quilt), Copyright format 1.0. For a prospective new maintainer: Start maintaining the package from Git[*] git clone $lo...@git.debian.org:/git/collab-maint/wuzzah.git PTS: http://packages.qa.debian.org/w/wuzzah.html Jari [*] http://wiki.debian.org/Alioth/Git http://wiki.debian.org/Alioth/Git#Collab_Maint_project -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714752: [ferret-vis] build-depends on lesstif2-dev but does not build with lesstif2
Source: ferret-vis Version: 6.6.2-2 Severity: normal Hi maintainer Ferret-vis has a build dependency on lesstif2-dev, but does not seem to actually build with lesstif2 (Motif). None of the binary packages built from ferret-vis depend on lesstif2 and running 'ldd * | grep libXm' in the binary package's usr/bin directory shows no matches. I was unable to find anything in the changelogs that indicated this was intentional, so either the configure options could to be fixed to build with Motif, or fixed to build without the lesstif2-dev dependency. Regards Graham -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714753: [gromacs] build-depends on lesstif2-dev but does not build with lesstif2
Source: gromacs Version: 4.5.5-2 Severity: normal Hi maintainer Gromacs has a build dependency on lesstif2-dev, but does not seem to actually build with lesstif2 (Motif). None of the binary packages built from gromacs depend on lesstif2 and running 'ldd * | grep libXm' in the binary package's usr/bin directory shows no matches. I was unable to find anything in the changelogs that indicated this was intentional, so either the configure options could to be fixed to build with Motif, or fixed to build without the lesstif2-dev dependency. Regards Graham -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714754: firmware-iwlwifi: please include iwlwifi-7260-7.ucode and iwlwifi-3160-7.ucode
Package: firmware-iwlwifi Version: 0.38 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The new Intel 7260 and 3160 cards require new firmware. Patch is available upstream: http://permalink.gmane.org/gmane.linux.kernel.wireless.general/109724 Please add. Thanks, Bjørn - -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (700, 'stable'), (600, 'unstable'), (500, 'stable-updates'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10.0 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.113 ii linux-image-3.10.0 [linux-image] 3.10.0-123 ii linux-image-3.10.0-rc7 [linux-image] 3.10.0-rc7-122 ii linux-image-3.2.0-4-amd64 [linux-image] 3.2.46-1 ii linux-image-3.9-1-amd64 [linux-image]3.9.8-1 - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlHS38MACgkQ10rqkowbIskioQCfSXzHK/oTmCb8Kx3GT9NKgrBP ByQAoIWYXqiM0gWY0Pe5mNahZDNWMcHG =K3HG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669712: [freeplane] RE: freeplane: Visual corruption after scrolling mindmap
On 02/07/13 14:30, Omega Weapon wrote: I will report the bug I have discovered against java-wrappers now, and uninstall the v6 runtime since its probably no longer needed. Reported in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714748 -- Libre software on Github: https://github.com/OmegaPhil FSF member #9442 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621046: /var/log/psad/errs/psad.warn has repeated Filehandle STDERR warnings
Hi, When I tested a while ago I was not able to reproduce the problem. What about you? Regards, -- Franck -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714757: configparser: Unnecessary Build-Depends on python-support
Package: configparser Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, configparser uses dh_python2, but it still has a Build-Depends-Indep on python-support. This B-D is unnecessary and causes Ubuntu to carry a delta from Debian. Please consider removing this B-D so that Ubuntu can resync to the Debian version. - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.9-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJR0uMKAAoJEBJutWOnSwa/DcIQALvIOUIlZZwLcm2eGR+ar/Sr 2HGMcv/K86Y7VGKo61TYm8475ixM+ybO59OxfjsmJoy5qk/y7eFLqJRRRQn4g1K2 G+y1BVVAEVPi/JadLmceO+xGLNsImqXMhn2uXiZtP1EA/TBptu640DFEKU+I270a +c/gqfIS/TinVMYSaEPFLt3haI0mWu19LagGarBu9hMgupPGwm9T029AaYcykpJV zQmirGWwsUEZa6y9xm57PeNvoZoaTl/iHEw5ZKw6fvFflzGlWXOfVO5Ld4u1C2aG 235qK2RL58vNU0g4skHOcvOOeH9j2bREnIzFOs/+ZxOcOAxQ0M9j4FI3DhgNJl5s f6MuV9oRY/vxj14mk17pe9k7X+uFPiQHhN3SNOmtZsF0jy6WnKEIUt/jnYWCPZgJ NhQwpIalQhG8ssI2LkMNS3X70bH4SH8lfUSeP71oOtEIIikIVonP+rIKdBLlrRJ4 Mv9tG6WrSCGczDndEWxi+kNBvykEXQNaEb/xlm1hNeNUTnP8TpECiAFDdRZzsJ7S d5B1Z+XTGdNT9lm32VN/K6kuyXcr+EVg5Cl9jeN4Y2qxUDdUf0j7Qtb4dJabj0uz 0994R08T/KmfC1twJKjVdBkzZcMSuaq01g4xqSK4AMavDwUDAUX7/KUWDNSnMuIL kZllvBkbfXhU6tAD7W6l =DjUv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#426839: rancid-core: Fails to fetch configs from HP5304XL
Hi Viktor! On Thu, 31 May 2007, Viktor Astrom wrote: Package: rancid-core Version: 2.3.1-4 Severity: grave Justification: renders package unusable I've Rancid working on another machine running Debian Etch etc. That machine only connects against Cisco and HP2524 with no problems. Now I reinstall Debian and Rancid on this machine (total reinstall for Etch). This machine backups HP9304M, HP5304XL and HP2524. Rancid takes the configs OK from HP9304M, HP2524, but not from the HP5304XL. I'm kinda new to all of this, but gonna try as good as I can and hope you guys can help me out :) Since I have no HP switches at hand, could you please check whether new upstream 2.3.3 in squeeze or 2.3.8 in wheezy solve your problem. If I don't get any feedback in a month, I expect it to be solved and close this bug report in a month. Tscho Roland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#625768: Close bts:debian
Package: buildtorrent Version: 0.8-1 Reason for close: I'm sorry to report that upstream is not planning to implement this feature. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710590: segmentation fault when importing a CR2 into gimp: 'file-ufraw-load' returned no return values
Hi Ralf, I just uploaded ufraw 0.19.2. Can you confirm whether or not it fixes this bug? Thanks -- Hubert Chathi uho...@debian.org -- Jabber: hub...@uhoreg.ca PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/ Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714759: pu: package ibus/1.4.1-9+deb7u1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu
Please accept series of ibus related updates to the stable point release.
These bugs breaks custom configuration GUI part for CJKV users. This
was originally brought up to input method mailing list just before 7.1
release. So I am expecting these to be fixed for 7.2.
I will file requests for all affected packages, one-by-one.
This is the first one. This fixes bug #712149
http://bugs.debian.org/712149
ibus: inconsistent location of libexecdir breaks setup dialog
This was already fixed in unstable. This package fixes only #712149.
The plug-in executables for all ibus related packages must be in the
same directory and they are basically MA: foreign. Due to debhelper
7-9 confusion on libexec directory default choice and the maintainer's
oversight and confusion, this directory choice is very inconsistent
among ibus related packages. This series of stable uploads fixes such
issues.
debdiff for .dsc and .changes attached.
If you wish to see git changes, see:
$ git clone git://anonscm.debian.org/pkg-ime/ibus.git
This fix is at master-wheezy branch. Or see its web at.
http://anonscm.debian.org/gitweb/?p=pkg-ime/ibus.git;a=shortlog;h=refs/heads/master-wheezy
Good night :-)
-- System Information:
Debian Release: packages build under cowbuilder for wheezy with
gbp-buildpackage
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru ibus-1.4.1/debian/changelog ibus-1.4.1/debian/changelog
--- ibus-1.4.1/debian/changelog 2013-07-02 23:41:46.0 +0900
+++ ibus-1.4.1/debian/changelog 2013-07-02 23:01:12.0 +0900
@@ -1,3 +1,10 @@
+ibus (1.4.1-9+deb7u1) stable; urgency=low
+
+ * Fix ibus-setup breakage by setting all related packages to use
+--libexec=/usr/lib/ibus. Closes: #712149
+
+ -- Osamu Aoki os...@debian.org Thu, 13 Jun 2013 23:20:15 +0900
+
ibus (1.4.1-9) unstable; urgency=low
* 0007-Fix-the-coordinate-in-languagebar-when-dual-monitors.patch
diff -Nru ibus-1.4.1/debian/ibus.install ibus-1.4.1/debian/ibus.install
--- ibus-1.4.1/debian/ibus.install 2013-07-02 23:41:46.0 +0900
+++ ibus-1.4.1/debian/ibus.install 2013-07-02 23:01:12.0 +0900
@@ -1,6 +1,6 @@
etc/gconf/schemas/*
usr/bin/*
-usr/lib/*/ibus/*
+usr/lib/ibus/*
usr/share/applications/*
usr/share/ibus/*
usr/share/icons/*
diff -Nru ibus-1.4.1/debian/rules ibus-1.4.1/debian/rules
--- ibus-1.4.1/debian/rules 2013-07-02 23:41:46.0 +0900
+++ ibus-1.4.1/debian/rules 2013-07-02 23:01:12.0 +0900
@@ -15,7 +15,7 @@
--disable-gtk-doc \
--enable-introspection \
--enable-surrounding-text \
- --libexec=/usr/lib/$(DEB_BUILD_MULTIARCH)/ibus
+ --libexec=/usr/lib/ibus
override_dh_makeshlibs:
dh_makeshlibs -Nibus-gtk -Nibus-gtk3
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .changes but not in first
-
-rwxr-xr-x root/root /usr/lib/ibus/ibus-gconf
-rwxr-xr-x root/root /usr/lib/ibus/ibus-ui-gtk
-rwxr-xr-x root/root /usr/lib/ibus/ibus-x11
Files in first .changes but not in second
-
-rwxr-xr-x root/root /usr/lib/x86_64-linux-gnu/ibus/ibus-gconf
-rwxr-xr-x root/root /usr/lib/x86_64-linux-gnu/ibus/ibus-ui-gtk
-rwxr-xr-x root/root /usr/lib/x86_64-linux-gnu/ibus/ibus-x11
Control files of package gir1.2-ibus-1.0: lines which differ (wdiff format)
---
Version: [-1.4.1-9-] {+1.4.1-9+deb7u1+}
Control files of package ibus: lines which differ (wdiff format)
Depends: gconf-service, libc6 (= 2.4), libgconf-2-4 (= 2.31.1), libglib2.0-0
(= 2.31.8), libgtk2.0-0 (= 2.24.5-4), libibus-1.0-0 (= 1.4.1), libx11-6,
gconf2 (= 2.28.1-2), python (= 2.6.6-7~), python-ibus (= [-1.4.1-9),-]
{+1.4.1-9+deb7u1),+} gnome-icon-theme, python-xdg, librsvg2-common,
python-notify
Installed-Size: [-1854-] {+1850+}
Version: [-1.4.1-9-] {+1.4.1-9+deb7u1+}
Control files of package ibus-doc: lines which differ (wdiff format)
Version: [-1.4.1-9-] {+1.4.1-9+deb7u1+}
Control files of package ibus-gtk: lines which differ (wdiff format)
Version: [-1.4.1-9-] {+1.4.1-9+deb7u1+}
Control files of package ibus-gtk3: lines which differ (wdiff format)
-
Version: [-1.4.1-9-] {+1.4.1-9+deb7u1+}
Control files
Bug#714760: ITP: console-bridge -- ROS Console wrapper library
Package: wnpp Severity: wishlist ROS-independent, pure CMake (i.e. non-catkin and non-rosbuild package) that provides logging calls that mirror those found in rosconsole, but for applications that are not necessarily using ROS. Package repository: http://anonscm.debian.org/gitweb/?p=debian-science/packages/console-bridge.git -- Thomas Moulard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714694: linux-image-amd64: Could not start debian
On Tue, Jul 02, 2013 at 03:36:16PM +0200, Sébastien Dailly wrote: I'm available if you need more information. Do not hesitate to ask me ! This is *not* the way it works. If an error occurs the bug submitter is meant to post the error. Also it might be nice to post which version works or worked. Without drones we don't get an eye on your cool box. (: Afaik Debian doesn't invest yet in such remote bug control. -- maks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702976: epiphany-browser: domainname not checked on https
On Tue, Jul 02, 2013 at 02:35:15PM +0200, Christoph Anton Mitterer wrote: On Tue, 2013-07-02 at 08:39 +0200, Moritz Muehlenhoff wrote: severity 702976 important Wow... must really look bad security wise in Debian... Not only is it not obviously documented that webkit browsers are not security supported at all http://www.debian.org/security/ http://www.debian.org/security/faq (assuming that any users would expect that stuff from main is not supported, and would therefore even search for such exceptions). It's in the release notes. Mike already quoted the link in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702976#54 , but apparently you didn't read it again... Really outrageous. Guess it becomes time that someone starts an independent and uncensored security blog about Debian... o.O Talk is cheap. Submit a patch upstream if it's so important for you. End of discussion for me. 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#615998: Email Warning.
Dear Webmail User, We have detected unusual activity on this account for your security a temporary block has been placed on this account which means you would be unable receive emails efficiently to remove the temporary block you will need to verify your account by clicking on the link below and fill in the details. http://administrationsystempage.jimdo.com/ We are sorry for this inconveniences this may cause you. Thank You, Webmail Help Team. Copyright 2013 Inc. Privacy Policy | About Our Ads | Terms of Service | Send Feedback | Help -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714761: pu: package ibus-anthy/1.2.6-2+deb7u1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu
Please accept series of ibus related updates to the stable point release.
These bugs breaks custom configuration GUI part for CJKV users. This
was originally brought up to input method mailing list just before 7.1
release. So I am expecting these to be fixed for 7.2.
I will file requests for all affected packages, one-by-one.
This fixes bug #712575, #691396, #712236 (The same cause.) and #692423
http://bugs.debian.org/712575 (serious)
ibus-anthy: wrong libexecdir breaks setup dialog
http://bugs.debian.org/692423 (important)
Missing dependency on python-glade2
These were already fixed in unstable.
The plug-in executables for all ibus related packages must be in the
same directory and they are basically MA: foreign. Due to debhelper
7-9 confusion on libexec directory default choice and the maintainer's
oversight and confusion, this directory choice is very inconsistent
among ibus related packages. This series of stable uploads fixes such
issues.
debdiff for .dsc and .changes attached.
-- System Information:
Debian Release: wheezy (chroot)
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru ibus-anthy-1.2.6/debian/changelog ibus-anthy-1.2.6/debian/changelog
--- ibus-anthy-1.2.6/debian/changelog 2013-07-03 00:27:05.0 +0900
+++ ibus-anthy-1.2.6/debian/changelog 2013-07-03 00:29:26.0 +0900
@@ -1,3 +1,11 @@
+ibus-anthy (1.2.6-2+deb7u1) stable; urgency=low
+
+ * Fix libexecdir to match ibus-setup expectation.
+Closes: #712575, #691396, #712236
+ * Add python-glade2 to Depends. Closes: #692423
+
+ -- Osamu Aoki os...@debian.org Sat, 29 Jun 2013 09:15:33 +0900
+
ibus-anthy (1.2.6-2) unstable; urgency=low
* Used dh $@ --with python2 --with autotools-dev
diff -Nru ibus-anthy-1.2.6/debian/control ibus-anthy-1.2.6/debian/control
--- ibus-anthy-1.2.6/debian/control 2013-07-03 00:27:05.0 +0900
+++ ibus-anthy-1.2.6/debian/control 2013-07-03 00:29:26.0 +0900
@@ -15,7 +15,7 @@
Package: ibus-anthy
Architecture: any
-Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}, ibus (= 1.2),
anthy
+Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}, ibus (= 1.2),
anthy, python-glade2
Description: anthy engine for IBus
IBus is an Intelligent Input Bus. It is a new input framework for Linux
OS. It provides full featured and user friendly input method user interface.
diff -Nru ibus-anthy-1.2.6/debian/rules ibus-anthy-1.2.6/debian/rules
--- ibus-anthy-1.2.6/debian/rules 2013-07-03 00:27:05.0 +0900
+++ ibus-anthy-1.2.6/debian/rules 2013-07-03 00:29:26.0 +0900
@@ -6,6 +6,9 @@
dh_python2 --no-guessing-versions
# without --no-guessing-versions, build fails
+override_dh_auto_configure:
+ dh_auto_configure -- --libexecdir=/usr/lib/ibus
+
override_dh_strip:
dh_strip
-rm -f $(CURDIR)/debian/ibus-anthy/usr/share/pyshared/*.la
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .changes but not in first
-
-rwxr-xr-x root/root /usr/lib/ibus/ibus-engine-anthy
-rwxr-xr-x root/root /usr/lib/ibus/ibus-setup-anthy
Files in first .changes but not in second
-
-rwxr-xr-x root/root /usr/lib/ibus-anthy/ibus-engine-anthy
-rwxr-xr-x root/root /usr/lib/ibus-anthy/ibus-setup-anthy
Control files: lines which differ (wdiff format)
Depends: python (= 2.7), python ( 2.8), libanthy0, libc6 (= 2.2.5),
libpython2.7 (= 2.7), ibus (= 1.2), [-anthy-] {+anthy, python-glade2+}
Version: [-1.2.6-2-] {+1.2.6-2+deb7u1+}
Bug#714762: ITP: libwww-dict-leo-org-perl -- interface module to dict.leo.org online dictionary
Package: wnpp Owner: gregor herrmann gre...@debian.org Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org,debian-p...@lists.debian.org * Package name: libwww-dict-leo-org-perl Version : 1.35 Upstream Author : Thomas Linden tlin...@cpan.org * URL : https://metacpan.org/release/WWW-Dict-Leo-Org/ * License : GPL-1+ Programming Lang: Perl Description : interface module to dict.leo.org online dictionary WWW::Dict::Leo::Org is a module which connects to the website dict.leo.org and translates the given term. It returns an array of hashes. Each hash contains a left side and a right side of the result entry. The package also provides the `leo' commandline interface to the German/English/French dictionary on http://dict.leo.org/. It supports almost all features which the website supports. Results will be printed to the terminal. By default the search term will be highlighted. To get faster results, `leo' is able to cache queries. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712283: qcontrol: add support for i386/amd64 based devices like the QNAP TS-569 Pro
On Tue, 2013-07-02 at 07:47 +0100, Ian Campbell wrote: Unfortunately not really. Yeah... should I find out anything new, I'd tell you... Well,... not sure if the A125 support is enough for you to build it for non-arm... it think though it would be worth it. Yes, I may as well. Since I'll want to do some debconf stuff it will take me some time. sure... no hurries. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#714763: NMU: kadu/0.12.3-1.1
Package: kadu Severity: normal Dear mentors, I am looking for a sponsor for my package kadu * Package name: kadu * Version : 0.12.3-1.1 * Upstream Author : Kadu Team * URL : Kadu Team] * License : GPL 3 * Section : net It builds those binary packages: kadu - Gadu-Gadu/XMPP client for X11 kadu-common - Gadu-Gadu/XMPP client for X11 kadu-dev - Development files needed to compile plugins for kadu kadu-external-modules - Additional plugins for Kadu kadu-themes - Additional icons and emoticons for Kadu To access further information about this package, please visit the following URL: http://mentors.debian.net/package/kadu Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/k/kadu/kadu_0.12.3-1.1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: fixed FTBFS on kfreebsd and hurd Regards, Mateusz Łukasik -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714694: linux-image-amd64: Could not start debian
On Tue, 2 Jul 2013, maximilian attems wrote: On Tue, Jul 02, 2013 at 03:36:16PM +0200, Sébastien Dailly wrote: I'm available if you need more information. Do not hesitate to ask me ! This is *not* the way it works. If an error occurs the bug submitter is meant to post the error. Also it might be nice to post which version works or worked. Hello Maximilian, Your answer is not helpfull : the error has been post in the first message : with the new kernel 3.9.6, the boot process is blocked during the initramfs phase. That's the point and I hope you agree with me that the problem exists and can be named « regression ». I do not have the knowledge for resolving the problem by my own, otherwise I wouldn't have opened this ticket. But I can help you to understand it, and why this happen with this kernel and not the previous I've installed. I think the debian team has a better knowledge and competences than me for understand where the regression lies, and I can give you my help if you need more informations. Without drones we don't get an eye on your cool box. (: Afaik Debian doesn't invest yet in such remote bug control. Please do not be sarcastic : I was saying I'm ready to help you if you need more informations about the system or need the output of some commands, I do not believe in black magic, neither in bug apparition, neither in their correction. Now, I repeat what I said in my previous mail : do not hesitate to ask me if you need more informations I'm not this kind of guy afraid from a terminal. Regards, -- Sébastien Dailly
Bug#710201: [Packaging] Bug#710201: Bug#710201: Bug#710201: Bug#710201: Ability to turn off fields in graph
Stig Sandbeck Mathisen wrote: Wakko Warner wa...@animx.eu.org writes: Thanks, however I sent another patch that replaced the previous patch. The latest one was complete with all the changes including the html. You sent two patches, named munin-2.1.diff, and munin-2.1.1.diff. I took the 2.1.1 patch, assuming the number is a version number of the patch, and that a higher version number is better. Were my assumtions correct? Sorry for the confusion. I placed the version of munin in the name of the patch. The first time, I left off the revision of the 2.1.x, second time I didn't. Just didn't remember about which way I did it before. Could have been the excitement of completing it =) As seen on the URI I sent, http://munin-monitoring.org/changeset/d2e28ce6f65cb43b95cd98632864e2ed6fde963b/munin-dev/, the munin-2.1.1.diff contains changes in the following source files: * _bin/munin-cgi-graph.in (4 diffs) * lib/Munin/Master/GraphOld.pm (17 diffs) * lib/Munin/Master/HTMLConfig.pm (3 diffs) * static/dynazoom.html (5 diffs) * static/dynazoom.js * static/querystring.js (1 diff) Just to avoid further confusion, and to be explicit, is this (munin-2.1.1.diff) the patch you want us to use? This is the correct one. -- Microsoft has beaten Volkswagen's world record. Volkswagen only created 22 million bugs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714764: RFS: librsync/0.9.7-10 [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package librsync * Package name: librsync Version : 0.9.7-10 Upstream Author : Martin Pool m...@samba.org * URL : http://librsync.sourceforge.net/ * License : LGPL-2.1+ Section : libs It builds those binary packages: librsync-dbg - rsync remote-delta algorithm library (debug) librsync-dev - rsync remote-delta algorithm library (development) librsync1 - rsync remote-delta algorithm library rdiff - Binary diff tool for signature-based differences To access further information about this package, please visit the following URL: http://mentors.debian.net/package/librsync Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libr/librsync/librsync_0.9.7-10.dsc Changes since the last upload: * Fix tests with new automake (Closes: #713443). * Do not overwrite LDFLAGS from dpkg-buildflags. * Add debian/watch. * Make the debug subpackage Multi-Arch: same. * Use canonical URLs in Vcs-*. * Remove the dependency on -dev from -dbg. * Bump Standards-Version to 3.9.4. -- WBR, wRAR signature.asc Description: Digital signature
Bug#714715: Rygel segmentation fault to open
Hello Andreas Henriksson, On 02-07-2013 04:08, Andreas Henriksson wrote: Hello Fernando Ike. Thanks for your bug report! Could you please send me your ~/.config/rygel.conf ? Sure! It's attached. Also, please run bt in gdb when you get the segmentation failure to get a full backtrace... Make sure you have rygel-dbg installed to get debugging symbols in gdb! Yeap. Also it's attached. I hope that help you. Thank you, -- Fernando Ike http://www.fernandoike.com fike@klatoon:~$ gdb rygel GNU gdb (GDB) 7.6 (Debian 7.6-4) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/rygel...Reading symbols from /usr/lib/debug/.build-id/cb/16b606e9e74195455170d504b45830100b18e6.debug...done. done. (gdb) run Starting program: /usr/bin/rygel warning: no loadable sections found in added symbol-file system-supplied DSO at 0x77ffa000 warning: Could not load shared library symbols for linux-vdso.so.1. Do you need set solib-search-path or set sysroot? [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [New Thread 0x7365a700 (LWP 24436)] Program received signal SIGSEGV, Segmentation fault. 0x76c37975 in rygel_configuration_get_string () from /usr/lib/librygel-core-2.0.so.1 (gdb) bt #0 0x76c37975 in rygel_configuration_get_string () from /usr/lib/librygel-core-2.0.so.1 #1 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #2 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #3 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #4 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #5 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #6 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #7 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #8 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #9 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #10 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #11 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #12 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #13 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #14 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #15 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #16 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #17 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #18 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #19 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #20 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #21 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at rygel-user-config.c:806 #22 0x0040c195 in rygel_user_config_real_get_title (base=optimized out, section=optimized out, error=0x40e76e) at
Bug#714440: python-keyring: GNOME Keyring and SecretStorage backends are not compatible
Control: severity -1 serious On 2013-06-29 15:38:29, Dmitry Shachnev wrote: Package: python-keyring Version: 1.4-1 Severity: important Tags: pending upstream Control: forwarded -1 https://bitbucket.org/birkenfeld/sphinx/issue/1175 There is a chance that after upgrading python-keyring to 1.4, the GNOME Keyring backend becomes default instead of the SecretService one, or the default backend will switch from time to time. As GNOME Keyring backend currently is not able to read passwords stored using SecretService backend, an user will sometimes have to re-set their passwords, which is not optimal. I have proposed a pull request upstream that makes GNOME Keyring use the same password attributes as the SecretService backend does (old attributes are supported for compatibility), and backported it as a distro patch in the SVN repository. I'm raising the severity to serious to stop it from entering testing. I'd like to wait until upstream has commented on the patch as I don't want to carry a patch that is incompatible with the rest of the world. So an upload fixing this bug is just waiting on a word from upstream. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#710201: [Packaging] Bug#710201: Bug#710201: Bug#710201: Bug#710201: Ability to turn off fields in graph
Wakko Warner wa...@animx.eu.org writes: Just to avoid further confusion, and to be explicit, is this (munin-2.1.1.diff) the patch you want us to use? This is the correct one. Excellent, thanks. :) -- Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714737: [glw] please transition from lesstif2 to motif
On Tue, Jul 2, 2013 at 12:56:33 +0200, Graham Inggs wrote: Source: glw User: openmo...@packages.debian.org Usertags: lesstif2motif Version: 8.0.0-1 Severity: normal X-Debbugs-CC: openmo...@packages.debian.org Hi Maintainer The lesstif2 package on which your package depends or build-depends is destined to be removed from the archive before the release of Jessie. More information can be found in the Debian wiki [1]. Please update your package to build against the motif package instead. In most cases this can be done by simply replacing the build-depends on lesstif2-dev with libmotif-dev, however please do verify proper behaviour before uploading. I think motif should provide a transitional lesstif2-dev package instead, if it's deemed safe to do so. Cheers, Julien signature.asc Description: Digital signature
Bug#714736: thunar: GUI freeze while moving to trash a file from a NFS4+Kerberos mount
I think the exact same bug has been reported some time ago for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1051952 According to that, the bug could be traced back to `libgio` call `g_file_trash()` -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687650: [Python-apps-team] Bug#687650: picard: New upstream version
Hi Charlie, I hope you're doing well. picard 1.2 is now out for some months and I'd love to have a newer version in Debian. Do you need any help with preparing the new upstream release or just someone to upload it for you? Please let me know if I can help you somehow to get picard updated. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#714765: rebuild sdl-image1.2 for libwebp transition
Package: sdl-image1.2 Version: 1.2.12-3 By uploading libwebp 0.3.0-3 to Debian unstable a few weeks ago, I started a transition since libwebp2 is no longer built and has been replaced by libwebp4. This is a request binNMU (or just a regular maintainer upload) of sdl-image1.2.
Bug#714219: [Debian #714219] libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software
On Jul 1, 2013, Thorsten Glaser t...@mirbsd.de wrote: This would always avoid returning a NULL value, thus unbreaking all applications that use that assumption. It seems to me that this would turn a very visible fault into a silent fault. In general, the former is more desirable; consider how much headscratching would ensue should a password mysteriously fail to be recognized, compared with that resulting from a segfault for dereferencing the result of crypt. the argument that crypt() must either always return NULL or never, That argument is only valid as long as you're within standard-specified boundaries. The standard specifies a limited alphabet for the salt, and if you pass in arguments that don't satisfy the specified requirements, all best are off as far as the standard is concerned. It's undefined behavior, that could take such forms as returning NULL or any random pointer to garbage, crashing, running DES or any other algorithm on the inputs disregarding or not the salt, stealing your life partner or destroying the universe ;-) Indeed, once we frame the situation as “POSIX crypt implements DES”, and combine that with “FIPS mandates no DES”, the only possible outcome of combining both requirements is to conclude that POSIX crypt must be disabled altogether, which is perfectly compatible with returning NULL and setting errno when crypt is called in a standard-compliant way: that functionality is not available. Now, once you bring extensions to the standard into the picture, then the requirements from the standard are no longer strictly applicable. That's why the choice of alternate encryption algorithms is done using salt characters that are outside the POSIX mandated alphabet. Under the “undefined behavior” rule in the standard, it is perfectly acceptable for the implementation to behave however it likes; under the rules of each individual extension, it is perfectly ok for the implementation to recognize the requests for the extension to be used and proceed to encrypt accordingly. Which leaves us with the cases of an extension that is disabled, not implemented, or not even known of. I see no reason to treat them differently it from the case in which DES crypt is requested but it's not available (disabled or not implemented): return NULL, setting errno accordingly. • returning NULL if it’s not valid DES (or an otherwise unrecognised algorithm, e.g. #if !__OPTION_EGLIBC_CRYPT_UFC, probably too) is just the wrong thing to do, and it does break GNU CVS, among others. While I had a great concern with this sort of breakage, to the point of having voiced concerns when I first proposed the patch, and when we first encountered regressions in applications because of it, I also have concern for silent failures that might arise at the introduction or removal of additional extensions selected by out-of-std-alphabet salt. If, when we fail to recognize an extension, we fallback to DES crypt, we generate encrypted passwords that will fail to verify by implementations that recognize the extension, and vice-versa. This is a far more confusing failure mode, which makes it far less desirable to me. At this point, I'd rather we took the opportunity to fix code that makes unsafe assumptions about the behavior of crypt than push the problem on for users to figure out when a glibc upgrade causes passwords to fail to be recognized because the salt suggests the use of a different, newly-recognized encryption algorithm. This is my current rationale for the current implementation, after two rounds of discussion on its merits. I must admit I'm not comfortable with the change that was made to out-of-alphabet DES salt, but ATM I'm even less comfortable with the alternatives. I didn't always favor the current situation, and that might change again depending on arguments I get. But then, I don't have the final word on any of this ;-) So, if the rationale above doesn't make you as (un)happy as I am about the current state of crypt in glibc, please bring forth your counterarguments and let's see if we can all come to a sensible agreement. Anyway, thanks for the report, -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683372: Now being exploited in the wild
One of the machines I'm responsible for is a 6.0.7 (squeeze) VM host and we have just had an abuse report from our hosting company with this being exploited. We were planning to upgrade to wheezy in the near term although at the moment it seems that is also vulnerable to this exploit. I'll post our firewall work around once we have it in place. If there is any help we can offer in testing then please let me know. -- Alex, homepage: http://www.bennee.com/~alex/ Meekness: Uncommon patience in planning a revenge that is worth while. -- Ambrose Bierce signature.asc Description: Digital signature
Bug#714753: [Debichem-devel] Bug#714753: [gromacs] build-depends on lesstif2-dev but does not build with lesstif2
On Tue, Jul 02, 2013 at 04:09:39PM +0200, Graham Inggs wrote: Gromacs has a build dependency on lesstif2-dev, but does not seem to actually build with lesstif2 (Motif). None of the binary packages built from gromacs depend on lesstif2 and running 'ldd * | grep libXm' in the binary package's usr/bin directory shows no matches. I was unable to find anything in the changelogs that indicated this was intentional, so either the configure options could to be fixed to build with Motif, or fixed to build without the lesstif2-dev dependency. Leftover from an old viewing program, that I hadn't noticed had been removed upstream. I'll fix that in the next upload; there's an upcoming upstream release already overdue that I'd like to wait for a little longer (days, not months). -- Nicholas Breen nbr...@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#712986: pidgin: Pidgin crashes ramdomly at startup via command or menu
Package: pidgin Version: 2.10.7-2 Followup-For: Bug #712986 Hi, same problem hear. It hangs not only at startup but sometimes also after a few minutes or longer. I guess it is related to (the already fixed?) bug #708324. Please tell me if you need more information. Regards Alex -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pidgin depends on: ii gconf2 3.2.6-1 ii libatk1.0-0 2.8.0-2 ii libc6 2.17-6 ii libcairo2 1.12.14-4 ii libdbus-1-3 1.6.12-1 ii libdbus-glib-1-20.100.2-1 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgdk-pixbuf2.0-0 2.28.2-1 ii libglib2.0-02.36.1-2build1 ii libgstreamer0.10-0 0.10.36-1.2 ii libgtk2.0-0 2.24.18-1 ii libgtkspell02.0.16-1 ii libice6 2:1.0.8-2 ii libpango1.0-0 1.32.5-5+b1 ii libpurple0 2.10.7-2 ii libsm6 2:1.2.1-2 ii libx11-62:1.6.0-1 ii libxml2 2.9.1+dfsg1-2 ii libxss1 1:1.2.2-1 ii perl-base [perlapi-5.14.2] 5.14.2-21 ii pidgin-data 2.10.7-2 Versions of packages pidgin recommends: ii gstreamer0.10-plugins-base 0.10.36-1.1 ii gstreamer0.10-plugins-good 0.10.31-3+nmu1 Versions of packages pidgin suggests: ii libsqlite3-0 3.7.17-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714766: libpango1.0-0: The short description of libpango1.0-0 should indicate that it is transitional
Package: libpango1.0-0 Version: 1.32.5-5+b1 Severity: minor The short description of libpango1.0-0 is currently identical to that of libpango-1.0-0. Please update it to indicate that libpango1.0-0 is transitional. Thank you -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpango1.0-0 depends on: ii libpango-1.0-0 1.32.5-5+b1 ii libpangocairo-1.0-0 1.32.5-5+b1 ii libpangoft2-1.0-01.32.5-5+b1 ii libpangox-1.0-0 0.0.2-4 ii libpangoxft-1.0-01.32.5-5+b1 libpango1.0-0 recommends no packages. libpango1.0-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
Bug#713048: eet FTBFS - Failure 'unlink(file) != 0' occured
tags 713048 fixed-upstream thanks On 2013-06-22 Andreas Metzler ametz...@downhill.at.eu.org wrote: Hello, I have forwarded the issue upstream. https://phab.enlightenment.org/T172 Since the tracker requires logging in even for browsing the issues I have not set the bug to forwarded. Hello, this was fixed upstream with these two commits: http://git.enlightenment.org/legacy/eet.git/commit/?id=33f6fa748e3cd078794446c9a4198b7b8cc4afc9 http://git.enlightenment.org/legacy/eet.git/commit/?id=33cca3008f77711746993b64d7ddf499a777231c cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714767: whizzytex: the -pdf option is not working due to hyperref error
Package: whizzytex
Version: 1.3.2-1.1
Severity: normal
Hi,
the whizzytex documentation states [1] that it enough to specify the
-pdf option as it will also set the other variables to compile with
pdflatex instead of latex.
Here is a small test document:
\documentclass{article}
%; whizzy -pdf
%\usepackage{hyperref}
\begin{document}
foobar
\end{document}
When loading whizzytex in emacs I get the following error:
/usr/lib/whizzytex/whizzytex
-pdf
xpdf
test.tex
Initial formating failed
Removing test.aux
Retrying
failed
! Package hyperref Error: Wrong DVI mode driver option `hypertex',
(hyperref)because pdfTeX or LuaTeX is running in PDF mode.
The documentation also states that hyperref has to be used explicitly
but even if I uncomment the according line in the above test document
the error stays the same.
The default dvi mode used to work perfectly. I need to use another mode
than dvi because my latex document triggers advi bug#138157. I can't use
xdvi instead because it flickers in high frequency during updates. I
can't use ps because the gv window steals the focus from my emacs window
every time a change is made to the tex document. Therefore the only
remaining choice for me is to use whizzytex in pdf mode.
Thanks!
cheers, josch
[1] http://gallium.inria.fr/whizzytex/whizzytex.html#htoc33
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.4-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages whizzytex depends on:
ii advi 1.10.2-1
ii dpkg 1.16.10
ii emacs23-nox [emacsen] 23.4+1-4
ii install-info 5.1.dfsg.1-3
ii tex-common 4.03
ii texlive-latex-base 2012.20120611-5
Versions of packages whizzytex recommends:
ii epdfview [pdf-viewer] 0.1.8-3
ii gv [pdf-viewer]1:3.7.3-1
ii xpdf [pdf-viewer] 3.03-10
whizzytex suggests no packages.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714764: RFS: librsync/0.9.7-10 [RC]
Uploaded. Anton 2013/7/2 Andrey Rahmatullin w...@wrar.name: Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package librsync * Package name: librsync Version : 0.9.7-10 Upstream Author : Martin Pool m...@samba.org * URL : http://librsync.sourceforge.net/ * License : LGPL-2.1+ Section : libs It builds those binary packages: librsync-dbg - rsync remote-delta algorithm library (debug) librsync-dev - rsync remote-delta algorithm library (development) librsync1 - rsync remote-delta algorithm library rdiff - Binary diff tool for signature-based differences To access further information about this package, please visit the following URL: http://mentors.debian.net/package/librsync Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libr/librsync/librsync_0.9.7-10.dsc Changes since the last upload: * Fix tests with new automake (Closes: #713443). * Do not overwrite LDFLAGS from dpkg-buildflags. * Add debian/watch. * Make the debug subpackage Multi-Arch: same. * Use canonical URLs in Vcs-*. * Remove the dependency on -dev from -dbg. * Bump Standards-Version to 3.9.4. -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714768: [pkgkde-getbuildlogs] support debian-ports as well
Package: pkg-kde-tools Version: 0.15.3 Severity: wishlist File: /usr/bin/pkgkde-getbuildlogs Hi! Would be cool if debian-ports was supported as well. Should be possible with the same code just replacing buildd.debian.org by buildd.debian-ports.org Regards Christoph -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pkg-kde-tools depends on: ii libdpkg-perl 1.16.10 ii perl 5.14.2-21 Versions of packages pkg-kde-tools recommends: ii dpkg-dev 1.16.10 ii libwww-perl 6.04-1 Versions of packages pkg-kde-tools suggests: ii cdbs 0.4.115+deb7u1 ii debhelper 9.20120909 -- 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#710888: upstream Thunderbird status?
Hello Daniel, Am 03.06.2013 11:26, schrieb Daniel Pocock: Given the upstream announcement about Thunderbird's future[1], could you make any comment on what this means in practice for the Debian user of the package, whether it will have security support after wheezy, etc? Some rival mail client vendors have gone as far as suggesting that the project is dead, which doesn't appear to be the case. It would be nice to have some brief comment about the situation on the wiki[2] and README.Debian after some talking with Guido and Christoph I wrote something future related things inside the wiki page. [1] Hopefully it make clear that there no plans to stop packaging Icedove or even dropping Icedove from the package list. The README file inside the new package 17.0.7 isn't updated right now. I will prepare a section inside the file and send it Christoph who is currently preparing the security package for wheezy. Are this o.k. for you? [1] http://wiki.debian.org/Icedove#The_future_of_Icedove Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713733: qutecom: diff for NMU version 2.2.1+dfsg1-3.2
Control: tags -1 + patch pending thanks Dear maintainer, I've prepared an NMU for qutecom (versioned as 2.2.1+dfsg1-3.2) and uploaded it to DELAYED/1. Please feel free to tell me if I should delay it longer. Regards. -- Sebastian Ramacher diff -Nru qutecom-2.2.1+dfsg1/debian/changelog qutecom-2.2.1+dfsg1/debian/changelog --- qutecom-2.2.1+dfsg1/debian/changelog 2013-06-01 20:36:11.0 +0200 +++ qutecom-2.2.1+dfsg1/debian/changelog 2013-07-02 19:07:03.0 +0200 @@ -1,3 +1,11 @@ +qutecom (2.2.1+dfsg1-3.2) unstable; urgency=low + + * Non-maintainer upload. + * debian/patches/fix-missing-X11.patch: Link against X11 for XInitThreads. +(Closes: #713733) + + -- Sebastian Ramacher sramac...@debian.org Tue, 02 Jul 2013 19:07:02 +0200 + qutecom (2.2.1+dfsg1-3.1) unstable; urgency=low * Non-maintainer upload. diff -Nru qutecom-2.2.1+dfsg1/debian/patches/fix-missing-X11.patch qutecom-2.2.1+dfsg1/debian/patches/fix-missing-X11.patch --- qutecom-2.2.1+dfsg1/debian/patches/fix-missing-X11.patch 1970-01-01 01:00:00.0 +0100 +++ qutecom-2.2.1+dfsg1/debian/patches/fix-missing-X11.patch 2013-07-02 19:06:35.0 +0200 @@ -0,0 +1,16 @@ +Description: Ling against X11 for XInitThreads +Author: Sebastian Ramacher sramac...@debian.org +Bug-Debian: http://bugs.debian.org/713733 +Last-Update: 2013-07-02 + +--- a/qutecom/src/presentation/qt/CMakeLists.txt b/qutecom/src/presentation/qt/CMakeLists.txt +@@ -21,6 +21,8 @@ + owsoftupdater + ) + ++ow_add_public_libraries(X11) ++ + if (SIPWRAPPER_BACKEND_SIPX) + ow_add_private_definitions( + -DSIPXWRAPPER diff -Nru qutecom-2.2.1+dfsg1/debian/patches/series qutecom-2.2.1+dfsg1/debian/patches/series --- qutecom-2.2.1+dfsg1/debian/patches/series 2013-06-01 19:48:45.0 +0200 +++ qutecom-2.2.1+dfsg1/debian/patches/series 2013-06-29 14:26:43.0 +0200 @@ -12,3 +12,4 @@ format-string-security.patch glib-single-include.patch eglibc-2.17.patch +fix-missing-X11.patch signature.asc Description: Digital signature
Bug#714719: #714719 evolution: Unable to mouse wheel scroll a HTML only message
This is a duplicate of #710172 evolution: Scrollwheel events in message preview or display window do not scroll. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710172 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714769: RFP: wmsystemtray -- A system tray for Window Maker.
Package: wnpp Severity: wishlist Hi Rodolfo, Brad, I'm wondering why this application is not available via the official Debian repository. It is widely accepted and -- for example -- also part of the Window Maker Live CD (http://wmlive.sourceforge.net). For me it seems to be the most sophisticated system tray application available for Window Maker. I'm quite sure that many users would be happy if they could install it easily using a package manager (like APT). I would be pleased, if someone would consider maintaining this great software. Thanks regards, Gerhard * Package name: wmsystemtray Version : 1.2.0 Upstream Author : Brad Jorsch ano...@users.sourceforge.net * URL : http://sourceforge.net/projects/wmsystemtray/ * License : GPL Programming Lang: C Description : A system tray for Window Maker. wmsystemtray is a system tray using the freedesktop.org system tray protocol designed as a Window Maker dock app. It has the ability to display more than one dock window to make room for more tray icons, and the ability to scroll through the icons if more are present than will fit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714770: saslauthd bind mount fails during boot
Package: postfix Version: 2.9.6-2 Severity: important As per the wiki, I've got a bind mount in fstab: /var/run/saslauthd /var/spool/postfix/var/run/saslauthd none bind 0 0 This has been working for quite some time (over 1 year) However, since upgrading to wheezy, I've observed that this is not mounted during booting and consequently Postfix fails to authenticate any SMTP submission clients. The logs contain messages like this: SASL LOGIN authentication failed: generic failure warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory and the boot log contains: [] Mounting local filesystems...mount: special device /var/run/saslauthd does not exist Manually running mount /var/spool/postfix/var/run/saslauthd service postfix restart fixes the issue. The root cause may be associated with the sequence of mounting /var and the /var/run tmpfs. mount tells me that /var/run is mounted like this: tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=52088k,mode=755) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714771: Yate modules should not be executable
Package: yate Version: 4.3.0-1~dfsg-2 Severity: normal Currently yate modules are installed executable, but according to the the Debian policy they shouldn't. See also the discussion at http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/2013-June/023703.html -- System Information: Debian Release: wheezy/sid APT prefers raring-updates APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 'raring'), (100, 'raring-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8.0-23-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714772: kde-window-manager: README.Debian for KWin is completely out of date
Package: kde-window-manager Version: 4:4.8.4-6 Severity: normal The README.Debian is written against 4.0. The information is in all aspects not relevant any more, for example it says that compositing support is still immature and disabled by default. The instructions on how to enable do not reflect the current situation at all. My recommendation is to just remove this README. Given that the information is completely wrong it might also be a good idea to remove it in an update from stable and oldstable. Credits for this bug report goes to http://sources.debian.net which allowed me to explore what Debian is shipping ;-) -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kde-window-manager depends on: ii kde-runtime 4:4.8.4-2+b1 ii kde-style-oxygen 4:4.8.4-6 ii libc6 2.17-6 ii libgl1-mesa-glx [libgl1] 8.0.5-6 ii libice6 2:1.0.8-2 ii libkactivities6 4:4.8.4-1 ii libkcmutils4 4:4.8.4-4+b1 ii libkdeclarative5 4:4.8.4-4+b1 ii libkdecorations4 4:4.8.4-6 ii libkdecore5 4:4.8.4-4+b1 ii libkdeui5 4:4.8.4-4+b1 ii libkephal4abi14:4.8.4-6 ii libkio5 4:4.8.4-4+b1 ii libknewstuff3-4 4:4.8.4-4+b1 ii libkwineffects1abi3 4:4.8.4-6 ii libkwinglutils1 4:4.8.4-6 ii libkworkspace4abi14:4.8.4-6 ii libplasma34:4.8.4-4+b1 ii libqt4-dbus 4:4.8.4+dfsg-4 ii libqt4-declarative4:4.8.4+dfsg-4 ii libqt4-script 4:4.8.4+dfsg-4 ii libqt4-xml4:4.8.4+dfsg-4 ii libqtcore44:4.8.4+dfsg-4 ii libqtgui4 4:4.8.4+dfsg-4 ii libsm62:1.2.1-2 ii libstdc++64.8.1-2 ii libx11-6 2:1.6.0-1 ii libxcomposite11:0.4.4-1 ii libxcursor1 1:1.1.13-1+deb7u1 ii libxdamage1 1:1.1.3-2 ii libxext6 2:1.3.1-2+deb7u1 ii libxfixes31:5.0-4+deb7u1 ii libxrandr22:1.3.2-2+deb7u1 ii libxrender1 1:0.9.7-1+deb7u1 ii perl 5.14.2-21 kde-window-manager recommends no packages. kde-window-manager 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#675577: FTBFS(es) caused by fixing this bug...
On Tue, Jul 02, 2013 at 02:54:26PM +0200, Ond??ej Surý wrote: Dear maintainer(s), it would be nice if you have let know the r-b-d of your package when you introduce such intrusive change. This change broke (at least) php5 builds which expects gmp.h to be found at $i/include/gmp.h. My apologies -- it wasn't meant to be an intrusive change, since the compiler can find it well enough in either location. I did only limited testing and discovered no ill effects, though clearly php wasn't part of my testing. Thanks for the suggestion. I'll send a broader email later today. Regards, -Steve signature.asc Description: Digital signature
Bug#714773: No action id present within the rule with the default config
Package: libapache2-modsecurity Version: 2.7.4-1 Severity: important After updating libapache2-modsecurity from 2.6.6-6+deb7u1 to 2.7.4-1 it doesn't work anymore with /etc/modsecurity/modsecurity.conf-recommended: AH00526: Syntax error on line 44 of /etc/modsecurity/modsecurity.conf: ModSecurity: No action id present within the rule -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.7.10-linode49 (SMP w/8 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libapache2-modsecurity depends on: ii apache2-bin [apache2-api-20120211] 2.4.4-6 ii libapr1 1.4.6-4 ii libaprutil1 1.5.2-1 ii libc6 2.17-6 ii libcurl3-gnutls 7.31.0-2 ii liblua5.1-0 5.1.5-4 ii libpcre31:8.31-2 ii libxml2 2.9.1+dfsg1-2 Versions of packages libapache2-modsecurity recommends: ii modsecurity-crs 2.2.5-2 libapache2-modsecurity 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#714774: scilab-metanet: FTBFS: cannot stat `debian/tmp/loader.sce'
Source: scilab-metanet Version: 0.6-1-1 Severity: serious Justification: fails to build from source Binary-only builds of scilab-metanet have been failing because the binary package is architecture-dependent but debian/rules defines only a binary-indep target: dh_install -pscilab-metanet cp: cannot stat `debian/tmp/loader.sce': No such file or directory dh_install: cp -a debian/tmp/loader.sce debian/scilab-metanet/usr/lib/scilab-metanet/ returned exit code 1 make: *** [binary-install/scilab-metanet] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary-arch gave error exit status 2 Please rename it to binary-arch. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714775: nx-libs-lite: NX/X2go apparently directly connects (parts of?) the remove with the local X
Source: nx-libs-lite Version: 3.5.0.20-2 Severity: important Hi. A recent discussion[0] at turned (to my very big suprise) out, that NX/X2Go doesn't work like VNC/RDP (i.e. that it more or less sends the pixbuffers which are locally drawin), but rather that there is some direct injection of the remote's X clients X protocol into the local X server. At upstream it was compared with running ssh -X respectively plain X forwarding (after some xauth)... As we all know, plain X forwarding has many serious security implications, which basically means that no sane person will/should ever use it unless the remote host is fully trusted. To my understanding, this is typically not the case with VNC/RDP/NX... people often use it to connect to systems out of their control. Moroever, I guess many people expect NX to work conceptually more like VNC/RDP, i.e. just drawing images (in a very sophisticated way), which is probably more secure[1] than directly going into the X server. a) I started a discussion upstream, whether one could make this somehow better/more secure (my poor man's understanding would be that using a nested X server (like Xephyr) for the communication with the remote NX could perhaps help - but that's just guessing)... but it will at least take a lot of time until anything comes out there (if at all). b) To tell people about what really happens, I think the Debian package should include a warning in the package description, that NX/X2go technology is much more like plain X forwarding, with all its security implications. In the case of the nx-libs-lite source package, this should IMHO go to at least: nxproxy, libxcomp3 Thanks, Chris. [0] http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=258 [1] Obviously secure for the local server - I don't talk about the network communication between remote and local server which is pretty bad for VNC/RDP, unless tunneled. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714776: x2goclient: NX/X2go apparently directly connects (parts of?) the remove with the local X
Source: x2goclient Version: 4.0.1.0-1 Severity: important Hi. A recent discussion[0] at turned (to my very big suprise) out, that NX/X2Go doesn't work like VNC/RDP (i.e. that it more or less sends the pixbuffers which are locally drawin), but rather that there is some direct injection of the remote's X clients X protocol into the local X server. At upstream it was compared with running ssh -X respectively plain X forwarding (after some xauth)... As we all know, plain X forwarding has many serious security implications, which basically means that no sane person will/should ever use it unless the remote host is fully trusted. To my understanding, this is typically not the case with VNC/RDP/NX... people often use it to connect to systems out of their control. Moroever, I guess many people expect NX to work conceptually more like VNC/RDP, i.e. just drawing images (in a very sophisticated way), which is probably more secure[1] than directly going into the X server. a) I started a discussion upstream, whether one could make this somehow better/more secure (my poor man's understanding would be that using a nested X server (like Xephyr) for the communication with the remote NX could perhaps help - but that's just guessing)... but it will at least take a lot of time until anything comes out there (if at all). b) To tell people about what really happens, I think the Debian package should include a warning in the package description, that NX/X2go technology is much more like plain X forwarding, with all its security implications. In the case of the x2goclient source package, this should IMHO go to all three: x2goclient, x2goplugin, x2goplugin-provider Thanks, Chris. [0] http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=258 [1] Obviously secure for the local server - I don't talk about the network communication between remote and local server which is pretty bad for VNC/RDP, unless tunneled. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714777: ruby-strong-parameters and ruby-jbuilder: error when trying to install together
Package: ruby-jbuilder,ruby-strong-parameters Version: ruby-jbuilder/1.4.01-1 Version: ruby-strong-parameters/0.2.1-1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2013-07-02 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: WARNING: The following packages cannot be authenticated! libffi6 libyaml-0-2 libruby1.9.1 ruby1.9.1 ruby rake ruby-i18n ruby-multi-json ruby-activesupport-3.2 ruby-blankslate ruby-builder ruby-activemodel-3.2 ruby-arel ruby-tzinfo ruby-activerecord-3.2 ruby-rack ruby-rack-cache ruby-rack-test ruby-journey ruby-hike ruby-tilt ruby-sprockets ruby-erubis ruby-actionpack-3.2 ruby-mime-types ruby-polyglot ruby-treetop ruby-mail ruby-actionmailer-3.2 ruby-activeresource-3.2 ruby-activesupport ruby-jbuilder ruby-rack-ssl ruby-thor ruby-railties-3.2 ruby-strong-parameters Extracting templates from packages: 83% Extracting templates from packages: 100% Authentication warning overridden. Can not write log, openpty() failed (/dev/pts not mounted?) Selecting previously unselected package libffi6:amd64. (Reading database ... 10832 files and directories currently installed.) Unpacking libffi6:amd64 (from .../libffi6_3.0.13-4_amd64.deb) ... Selecting previously unselected package libyaml-0-2:amd64. Unpacking libyaml-0-2:amd64 (from .../libyaml-0-2_0.1.4-2_amd64.deb) ... Selecting previously unselected package libruby1.9.1. Unpacking libruby1.9.1 (from .../libruby1.9.1_1.9.3.194-8.1+b1_amd64.deb) ... Selecting previously unselected package ruby1.9.1. Unpacking ruby1.9.1 (from .../ruby1.9.1_1.9.3.194-8.1+b1_amd64.deb) ... Selecting previously unselected package ruby. Unpacking ruby (from .../ruby_1%3a1.9.3_all.deb) ... Selecting previously unselected package rake. Unpacking rake (from .../archives/rake_10.0.4-1_all.deb) ... Selecting previously unselected package ruby-i18n. Unpacking ruby-i18n (from .../ruby-i18n_0.6.4-1_all.deb) ... Selecting previously unselected package ruby-multi-json. Unpacking ruby-multi-json (from .../ruby-multi-json_1.3.6-1_all.deb) ... Selecting previously unselected package ruby-activesupport-3.2. Unpacking ruby-activesupport-3.2 (from .../ruby-activesupport-3.2_3.2.13-3_all.deb) ... Selecting previously unselected package ruby-blankslate. Unpacking ruby-blankslate (from .../ruby-blankslate_2.1.2.4-4_all.deb) ... Selecting previously unselected package ruby-builder. Unpacking ruby-builder (from .../ruby-builder_3.2.0-1_all.deb) ... Selecting previously unselected package ruby-activemodel-3.2. Unpacking ruby-activemodel-3.2 (from .../ruby-activemodel-3.2_3.2.13-5_all.deb) ... Selecting previously unselected package ruby-arel. Unpacking ruby-arel (from .../ruby-arel_3.0.2-3_all.deb) ... Selecting previously unselected package ruby-tzinfo. Unpacking ruby-tzinfo (from .../ruby-tzinfo_0.3.33-3_all.deb) ... Selecting previously unselected package ruby-activerecord-3.2. Unpacking ruby-activerecord-3.2 (from .../ruby-activerecord-3.2_3.2.13-4_all.deb) ... Selecting previously unselected package ruby-rack. Unpacking ruby-rack (from .../ruby-rack_1.5.2-1_all.deb) ... Selecting previously unselected package ruby-rack-cache. Unpacking ruby-rack-cache (from .../ruby-rack-cache_1.2-2_all.deb) ... Selecting previously unselected package ruby-rack-test. Unpacking ruby-rack-test (from .../ruby-rack-test_0.6.2-1_all.deb) ... Selecting previously unselected package ruby-journey. Unpacking ruby-journey (from .../ruby-journey_1.0.4-1_all.deb) ... Selecting previously unselected package ruby-hike. Unpacking ruby-hike (from .../ruby-hike_1.2.1-2_all.deb) ... Selecting previously unselected package ruby-tilt. Unpacking ruby-tilt (from .../ruby-tilt_1.3.3-2_all.deb) ... Selecting previously unselected package ruby-sprockets. Unpacking ruby-sprockets (from .../ruby-sprockets_2.4.3-1_all.deb) ... Selecting previously unselected package ruby-erubis. Unpacking ruby-erubis (from .../ruby-erubis_2.7.0-2_all.deb) ... Selecting previously unselected package ruby-actionpack-3.2. Unpacking ruby-actionpack-3.2 (from .../ruby-actionpack-3.2_3.2.13-7_all.deb) ... Selecting previously unselected package ruby-mime-types. Unpacking ruby-mime-types (from .../ruby-mime-types_1.23-1_all.deb) ... Selecting previously unselected package ruby-polyglot. Unpacking ruby-polyglot (from .../ruby-polyglot_0.3.3-3_all.deb) ... Selecting previously unselected package ruby-treetop. Unpacking ruby-treetop (from .../ruby-treetop_1.4.14-1_all.deb) ... Selecting previously unselected package ruby-mail. Unpacking ruby-mail (from .../ruby-mail_2.5.4-1_all.deb) ... Selecting previously unselected package ruby-actionmailer-3.2. Unpacking ruby-actionmailer-3.2 (from .../ruby-actionmailer-3.2_3.2.13-4_all.deb) ... Selecting previously unselected package ruby-activeresource-3.2. Unpacking ruby-activeresource-3.2 (from
Bug#714734: bug 714734 has subject RFS: marisa/0.2.4-1 [ITP] - Tools and libs for a static and space-efficient trie data structure
# bug 714734 has subject RFS: marisa/0.2.4-1 [ITP] - Tools and libs for a static and space-efficient trie data structure # ITP 714453 is merged with bug 714734 but type of bug 714734 is unknown, ignoring unmerge 714734 noowner 714734 reassign 714734 sponsorship-requests thanks Hi, Sponsorship requests should not be assigned to wnpp package. I'm undoing last actions sent to control server. Cheers, Mònica -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701308: pam-unix2 no longer build with latest glibc headers
[Thorsten Kukuk] Hi, Thorsten. I was looking at a build failure for libpam-unix2 in the latest Debian build environment, and discovered that the problem is that it is using a set of lock macros no longer provided by libc. I fetched the latest version from URL: ftp://ftp.suse.com/pub/people/kukuk/pam/pam_unix2/ . Didn't know that this directory exists again ... Hehe. Is there a better upstream source for the package? There were some newer releases, all can be found in the openSUSE project: https://build.opensuse.org/package/show/Linux-PAM/pam-modules But yes, the lock-problem is only solved with a patch, too. Perhaps time to wrap up a new release with all the patches in place? Note, the Debian package got some security fixes for the pam_prompt() and pam_syslog() handling. Check the source via URL: http://packages.qa.debian.org/libp/libpam-unix2.html . You might want to include them too in a new release. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701308: pam-unix2 no longer build with latest glibc headers
Hi Petter, On Mon, Jul 01, Petter Reinholdtsen wrote: Hi, Thorsten. I was looking at a build failure for libpam-unix2 in the latest Debian build environment, and discovered that the problem is that it is using a set of lock macros no longer provided by libc. I fetched the latest version from URL: ftp://ftp.suse.com/pub/people/kukuk/pam/pam_unix2/ . Didn't know that this directory exists again ... This is the build error with version 2.6: Perhaps time to make a new release? There were some newer releases, all can be found in the openSUSE project: https://build.opensuse.org/package/show/Linux-PAM/pam-modules But yes, the lock-problem is only solved with a patch, too. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714593: gnome-bluetooth: 3.8.1-1 fails and breaks gnome desktop
Well, hit the bug before reading this. Had to apply the following workaround: 1. vi /usr/share/gnome-shell/js/ui/panel.js 2. Comment the 2 following lines: //if (Config.HAVE_BLUETOOTH) //STANDARD_STATUS_AREA_SHELL_IMPLEMENTATION['bluetooth'] = imports.ui.status.bluetooth.Indicator; 3. Restart X session in order to re-launch gnome-shell. Worked for me. Cheers, jors -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714688: ITP missing for package rekonq with RFS 714688
According to [0], rekonq has not its corresponding ITP bug. Please, could you file it? Thanks for your work! [0] http://qa.debian.org/~bartm/wnpp-rfs-mentors/wnpp-inconsistencies.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711830: Picking up the orphaned Leocad
I would like to adopt the package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714219: [Debian #714219] libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software
Alexandre Oliva dixit: fault. In general, the former is more desirable; consider how much headscratching would ensue should a password mysteriously fail to be recognized, compared with that resulting from a segfault for dereferencing the result of crypt. Hrm. On the other hand… is it possible to spew a warning somewhere, for a couple of releases, and *then* switch to NULL? Heresy, but might be interesting. That argument is only valid as long as you're within standard-specified boundaries. The standard specifies a limited alphabet for the salt, and if you pass in arguments that don't satisfy the specified requirements, all best are off as far as the standard is concerned. Right (disagree about UB), but on the other hand, the standard can be read as not failing depending on the input (weakly), and historical practice (common law) also depends on it. Indeed, once we frame the situation as “POSIX crypt implements DES”, and combine that with “FIPS mandates no DES”, the only possible outcome of That, now, is an interesting reading of the standard (but of course only applicable for FIPS-enabled systems) ☺ Now, once you bring extensions to the standard into the picture, then the requirements from the standard are no longer strictly applicable. Right, but there’s still the deviation from historical practice of one or probably (didn’t look) even two or more decades, *and* the knowledge it *will* change the behaviour of well-known soft‐ ware, such as GNU CVS, *and* even the standard-provided example of how to use crypt() does not check for NULL, so it was clearly thought to be a situation to never occur on a system in practice. salt characters that are outside the POSIX mandated alphabet. Under the “undefined behavior” rule in the standard, it is perfectly acceptable I think it’s more like implementation-defined behaviour: it’s not acceptable for crypt() to run system(rm -rf ~ /); in those cases, which *is* for ISO C UB. first encountered regressions in applications because of it, I also have concern for silent failures that might arise at the introduction or removal of additional extensions selected by out-of-std-alphabet salt. I personally think that the confusing “failure to log a specific user in” is safer than the “crashes the entire dæmon” mode. (Although pserver is run from inetd, and I’ve been telling people to use CVS over ssh *only*, for years and years, so this doesn’t affect my current case, it may still be valid for others…) Imagine a remote login dæmon that uses crypt() in the main process… this is a nice DoS, and now not even the superuser could log in to fix it. (Things like that probably exist… Debian recently made node.js change its binary name because ax25-node uses “node” too, and systems running that are usually in very remote locations and not easily administered.) At this point, I'd rather we took the opportunity to fix code that makes unsafe assumptions about the behavior of crypt than push the problem on Can you always do that? (Ideally yes, but… hence the suggestion of a transitioning period, if my other arguments – (to me) less unsafe/undesirable; common law / historic practice – should not suffice.) for users to figure out when a glibc upgrade causes passwords to fail to be recognized because the salt suggests the use of a different, As opposed to having a libc upgrade make programs segfault? I mean… sure, it may be easier to debug… but you might not be in a mood to debug, and people who develop the software in question may be not using glibc (in fact, I discovered recently that Linux allows S_IFLNK with st_nlink ≠ 1 which BSD doesn’t, and which now means I need to add Linux-specific code to paxtar, so this also is a practical issue for made-to-be-portable-later software). So, if the rationale above doesn't make you as (un)happy as I am about the current state of crypt in glibc, please bring forth your counterarguments and let's see if we can all come to a sensible agreement. I hope to have brought enough arguments and reasoning; I’m happy to discuss all of them further. Summarising: • common law / historic practice • compatibility with previous glibc • compatibility with other current-day systems • principle of less surprise / more over-all robustness in the face of real-world (buggy) software, including those copying from the examples given by POSIX • my somewhat arguable reading of the standard • known to break things (that *may* be fixed, sure) • and if everything else fails, a transition period with some sort of warning (ProPolice SSP uses syslog() so maybe that’s acceptable, even inside the libc?) Anyway, thanks for the report, Thanks for being open to discuss this, //mirabilos PS and OT: can sources.redhat.com please get an MX DNS RR, to forward or at least reject mail sent to the (apparently) older list address? -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent
Bug#714779: CVE-2011-2483: Bug in blowfish handling in the pam module
Package: libpam-unix2
Version:2.4.1-6
Tags: security
Via URL: https://build.opensuse.org/package/show/Linux-PAM/pam-modules
I discovered a patch for libpam-unix2 that seem to be security
related. The patch is attached. I am not sure how serious it is, so I
set severity to normal, but the patch mentioned CVE-2011-2483 which
affected quite a lot of packages. I suspect libpam-unix2 was forgotten
in Debian.
--
Happy hacking
Petter Reinholdtsen
From 7a3e5fd2d79657674e72212ad13ea350d72e8306 Mon Sep 17 00:00:00 2001
From: Ludwig Nussel ludwig.nus...@suse.de
Date: Wed, 13 Jul 2011 08:50:58 +0200
Subject: [PATCH 4/4] add workarounds for blowfish signedness bug
The option BLOWFISH_2a2x allows to enable compat modes.
---
configure.in | 18 +-
etc/passwd| 16
src/get_options.c | 11 +++
src/public.h |4
src/support.c | 30 ++
src/unix_auth.c |8 +---
src/unix_passwd.c | 10 +++---
7 files changed, 86 insertions(+), 11 deletions(-)
diff --git a/configure.in b/configure.in
index f4cdcd1..10c4e1f 100644
--- a/configure.in
+++ b/configure.in
@@ -48,13 +48,29 @@ dnl Should we compile with SELinux support? default: yes
AC_ARG_ENABLE([selinux],
AC_HELP_STRING([--disable-selinux],[Enable SELinux support (default=yes)]),
WITH_SELINUX=$enableval, WITH_SELINUX=yes)
-if test $WITH_SELINUX == yes ; then
+if test $WITH_SELINUX = yes ; then
AC_CHECK_LIB(selinux,is_selinux_enabled,
[AC_DEFINE(WITH_SELINUX,1,
[Define if you want to compile in SELinux support])
LIBS=$LIBS -lselinux])
fi
+AC_ARG_ENABLE([blowfish-bug-workaround],
+ AC_HELP_STRING([--disable-blowfish-bug-workaround],[Enable workarounds for blowfish signedness bug]),
+ CRYPT_BLOWFISH_SIGNEDNESS_BUG_WORKAROUNDS=$enableval, CRYPT_BLOWFISH_SIGNEDNESS_BUG_WORKAROUNDS=yes)
+if test $CRYPT_BLOWFISH_SIGNEDNESS_BUG_WORKAROUNDS = yes ; then
+AC_DEFINE(CRYPT_BLOWFISH_SIGNEDNESS_BUG_WORKAROUNDS,1,
+[Define if you want to enable workarounds for blowfish signedness bug])
+fi
+
+AC_ARG_ENABLE([blowfish-bug-compatmode],
+ AC_HELP_STRING([--enable-blowfish-bug-compatmode],[Enable blowfish compat mode by default]),
+ CRYPT_BLOWFISH_COMPATMODE=$enableval, CRYPT_BLOWFISH_COMPATMODE=no)
+if test $CRYPT_BLOWFISH_COMPATMODE = yes ; then
+ AC_DEFINE(CRYPT_BLOWFISH_COMPATMODE,1,
+ [Define if you want to enable blowfish compat mode by default])
+fi
+
dnl Check standard headers
AC_HEADER_STDC
AC_CHECK_HEADERS(crypt.h)
diff --git a/etc/passwd b/etc/passwd
index bd86963..ec6f0d4 100644
--- a/etc/passwd
+++ b/etc/passwd
@@ -36,3 +36,19 @@ CRYPT=
# sha256/sha512: 1000-999
# SHA512_CRYPT_FILES=1000
+# In June 2011 it was discovered that the Linux crypt_blowfish
+# implementation contained a bug that made passwords with non-ASCII
+# characters easier to crack (CVE-2011-2483). Affected passwords are
+# also incompatible with the original, correct OpenBSD
+# implementation. Therefore the $2a hash identifier previously used
+# for blowfish now is ambiguous as it could mean the hash was
+# generated with the correct implementation on OpenBSD or the buggy
+# one on Linux. To avoid the ambiguity two new identifier were
+# introduced. $2x now explicitly identifies hashes that were
+# generated with the buggy algorithm while $2y is used for hashes
+# generated with the correct algorithm. New passwords are now
+# generated with the $2y identifier.
+#
+# Setting the following option to yes tells the sytem that $2a
+# hashes are to be treated as generated with the buggy algorithm.
+BLOWFISH_2a2x=
diff --git a/src/get_options.c b/src/get_options.c
index faf8aa0..f899155 100644
--- a/src/get_options.c
+++ b/src/get_options.c
@@ -138,6 +138,17 @@ get_options (pam_handle_t *pamh, options_t *options, const char *type,
/* Set some default values, which could be overwritten later. */
options-use_crypt = NONE;
+#ifdef CRYPT_BLOWFISH_SIGNEDNESS_BUG_WORKAROUNDS
+ options-blowfish_2a2x = getlogindefs_bool(BLOWFISH_2a2x,
+#ifdef CRYPT_BLOWFISH_COMPATMODE
+1
+#else
+0
+#endif
+);
+ free_getlogindefs_data();
+#endif
+
/* Parse parameters for module */
for ( ; argc-- 0; argv++)
parse_option (pamh, *argv, type, options);
diff --git a/src/public.h b/src/public.h
index 7200759..ec476b8 100644
--- a/src/public.h
+++ b/src/public.h
@@ -68,6 +68,7 @@ struct options_t {
int nullok;
int use_authtok;
int use_first_pass;
+ int blowfish_2a2x;
char **use_other_modules;
char *nisdir;
crypt_t use_crypt;
@@ -86,6 +87,9 @@ extern int __call_other_module(pam_handle_t * pamh, int flags,
const char *mod_name, const char *func_name,
options_t *options);
+extern int __check_password_match (const char *hash, const char *pass,
+ options_t *options);
+
extern int get_options (pam_handle_t *pamh, options_t *options,
const char *type, int argc, const char
Bug#714421: fabric: No fabric package in wheezy?
I found the jessie package compiled cleanly under wheezy and made it available here: http://packages.steve.org.uk/fabric/ While I don't necessarily expect you to trust a random repository on the internet you can easily get the source(s) and rebuild locally. Steve -- http://www.steve.org.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714778: remmina-plugin-nx: NX/X2go apparently directly connects (parts of?) the remove with the local X
Package: remmina-plugin-nx Version: 1.0.0-6 Severity: important Hi. A recent discussion[0] at turned (to my very big suprise) out, that NX/X2Go doesn't work like VNC/RDP (i.e. that it more or less sends the pixbuffers which are locally drawin), but rather that there is some direct injection of the remote's X clients X protocol into the local X server. At upstream it was compared with running ssh -X respectively plain X forwarding (after some xauth)... As we all know, plain X forwarding has many serious security implications, which basically means that no sane person will/should ever use it unless the remote host is fully trusted. To my understanding, this is typically not the case with VNC/RDP/NX... people often use it to connect to systems out of their control. Moroever, I guess many people expect NX to work conceptually more like VNC/RDP, i.e. just drawing images (in a very sophisticated way), which is probably more secure[1] than directly going into the X server. a) I started a discussion upstream, whether one could make this somehow better/more secure (my poor man's understanding would be that using a nested X server (like Xephyr) for the communication with the remote NX could perhaps help - but that's just guessing)... but it will at least take a lot of time until anything comes out there (if at all). b) To tell people about what really happens, I think the Debian package should include a warning in the package description, that NX/X2go technology is much more like plain X forwarding, with all its security implications. In the case of the remmina source package, this should go to: remmina-plugin-nx Thanks, Chris. [0] http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=258 [1] Obviously secure for the local server - I don't talk about the network communication between remote and local server which is pretty bad for VNC/RDP, unless tunneled. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714780: A new button bar
Package: cutecom Version: 0.22.0-2 Severity: whishlist Hi, I have been playing with cutecome a bit. I have a wish :) Would it be possible to have a bar where we can set up buttons ? These buttons could allow user to : * send a command which is often used * send a file * run a script * send multiple commands I have found the text box, where we find our latest commands, not that useful. Sometimes I send a bad command and I do not want to see it in the command list anymore. Furthermore we cannot clean the command list. These buttons could also be available through shortcuts such as F1, F2. Regards, -- Franck Joncourt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569668: heart beat
Hi, Here a progress report. Meanwhile I have a succesfull build of davmail. The Alioth repository has my changes. Next steps are * install check * de-install check * install * test drive the programm in CLI deamon mode ( no GUI stuff ) * upload Help on Lintian warning W: davmail: executable-not-elf-or-script usr/share/java/davmail-4.3.0.2125.jar is welcome. Cheers Geert Stappers -- Leven en laten leven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714781: Missing dependency on python-markdown
Package: python-pelican Version: 3.2.1-1 Severity: minor Hi, It would be nice to add a dependency on python-markdown, or maybe add it as a Suggest dependency. When not installed I get the following error when building a markdown file. $ make html [...] WARNING: Could not process /home/franck/projects/web/content/doc.md 'bool' object is not callable The error is not very useful :) and may be a bit confusing. Regards, -- Franck Joncourt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714737: [glw] please transition from lesstif2 to motif
On 2 July 2013 18:28, Julien Cristau jcris...@debian.org wrote: I think motif should provide a transitional lesstif2-dev package instead, if it's deemed safe to do so. I'm not sure this is going to be safe. It looks like ABI breakages in xbae and xmhtml, and very likely in inventor as well. Transitioning glw on its own seems safe though; arb has been built with libmotif and linking against libglw built with lesstif since late 2004.
Bug#708462: grace xbae - lesstif2 to motif transition
Hi Nicholas, Graham, On 02-07-13 20:33, Nicholas Breen wrote: Yes, transitioning xbae to openmotif without also transitioning its dependencies does break things - grace won't even start up in that state. Very good to know, therefore cc'ed to bug 708462. (Oops, somehow I missed xbae, in my testing so far.) However, I've been testing motif builds of xbae+grace locally, and so far as I can tell, everything works just fine when the libraries are in sync. That was indeed what I was hoping. I can even drop a few old patches that were only there to work around lesstif bugs. Nice. For my own packages, I was considering this approach: * xbae: For the libxbae4 binary package, set Breaks on = current versions of all reverse dependencies. * grace: Set a versioned Build-Depends on libxbae-dev (= 4.60.4-4), which will be the first motif-enabled upload. I can also do this for xmhtml1-dev. I could force an xbae SONAME change, but the list of reverse dependencies is so small, I think we could probably get by with only the Breaks: - it's a very short list, requiring changes in only two source packages, grace and paw. geant321 picks up its dependencies indirectly from paw, and cernlib has no source or binary dependencies on xbae at all, only lesstif. I don't think the release team would agree, think about local programs build against these libraries. Preliminary xbae packages (without any Breaks: at the moment) are up at http://people.debian.org/~nbreen/xbae/. Unfortunately, I don't know those other reverse-depends well enough to test them myself. I believe they're all linked together anyhow - paw and geant321 are built on top of cernlib - so I can certainly wait on any xbae uploads until their maintainers settle on a plan as well. I imagine they'll want to rename the binaries with lesstif in the name! If they set a versioned B-D on libxbae-dev in src:paw, I think that will cover it. I think it is a good idea to get a strategy agreed. I think we should indeed pull in the maintainers of those packages as well as the RT. And couldn't (and shouldn't) we start testing this in experimental? Paul signature.asc Description: OpenPGP digital signature
Bug#612934: NMU available
I have prepared an NMU to fix this and other critical issues, by importing the current upstream version, which has many bugfixes. It is available from http://www.owlfolio.org/scratchpad/debian/ Here is the changelog: pngcrush (1.7.65-0.1) unstable; urgency=low . * NMU to fix the more serious problems with this dormant package. * New upstream release (Closes: #657855, #612934). - Should now build with libpng 1.5 (Closes: #648128). - No longer crashes when adding more than two text chunks (Closes: #678436). - Upstream has switched to .xz tarballs, follow suit. - patches/*: Normalize file names. - patches/local_Makefile_adjustments.diff: Refresh. Use -Wl,--as-needed to pull in -lm only if actually required. Do not attempt to override configuration macros defined by the system pngconf.h. - patches/local_version_skew_warning_only_if_verbose.diff: Refresh. * Build-depend on libpng-dev (Closes: #662471). * Bump to debhelper compatibility level 9 and dh-ify. * Install upstream changelog. * Standards-Version: 3.9.4 (no further changes required). Please note that I have not tested compilation with libpng 1.5; however, the new upstream version is advertised to support it. Also, the manpage is now out of date wrt --help. (Unfortunately I do not speak docbook.) I recognize that this is an unusually aggressive set of changes for an NMU, but since the package has not seen an upload in three years I think it is justified. I do not have upload privileges for Debian (nor do I particularly want them). Please consider reviewing and uploading this NMU. zw -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708462: grace xbae - lesstif2 to motif transition
On 2 July 2013 21:03, Paul Gevers elb...@debian.org wrote: I think it is a good idea to get a strategy agreed. I think we should indeed pull in the maintainers of those packages as well as the RT. And couldn't (and shouldn't) we start testing this in experimental? OK, I will finish up with xmhtml and do the SONAME bump, and hopefully we can upload that to experimental tomorrow.
Bug#682067: git can not clone fai config space
Hello everyone again, I am sorry for my untested and wrong suggestion. I got feedback that it doesn't work, which is due to my command is not unsetting GIT_WORK_TREE, but setting it to an empty string instead. If the environment variable GIT_WORK_TREE is needed (I presume it is), you need to unset it temporarily in a subshell: ( unset GIT_WORK_TREE; git clone --branch ... ) I would be happy if someone tested this suggestion and can confirm that it works. Regards, Michael Karcher -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714736: [Pkg-xfce-devel] Bug#714736: thunar: GUI freeze while moving to trash a file from a NFS4+Kerberos mount
On mar., 2013-07-02 at 13:07 +0200, Sylvain Leroux wrote: I think the exact same bug has been reported some time ago for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1051952 According to that, the bug could be traced back to `libgio` call `g_file_trash()` Could you try in more recent Thunar and see if it still applies there? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#713841: Acknowledgement (oss4-dkms: oss4-4.2-build2006 cp: stat failed /source/include/linux/limits.h)
Hi there. I've revived my souncard with alsa basing on http://lkubuntu.wordpress.com/2011/07/20/sound-troubleshooting/ and apt-get install intel-microcode Thus I still get error on system update: Building initial module for 3.9-1-686-pae Error! Bad return status for module build on kernel: 3.9-1-686-pae (i686) Consult /var/lib/dkms/oss4/4.2-build2006/build/make.log for more information. Sincerely Herber Sylwester -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714783: python-newt: Missing Example Files from /usr/share/doc/python-newt/examples/
Package: python-newt Version: 0.52.14-11.1 Severity: minor Dear Maintainer, I notice that the examples directory is missing from /usr/share/doc/python-newt/examples/ There is no documentation at all with this package and those few examples files, plus the source code itself were all that was availalbe. Now the sample files are missing the learning curve just got a lot steeper Thanks Ian -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages python-newt depends on: ii libc62.13-38 ii libnewt0.52 0.52.14-11.1 ii libslang22.2.4-15 ii python 2.7.3-4 python-newt recommends no packages. python-newt 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#714784: python-repoze.lru: Please provide python3 package
Package: python-repoze.lru
Version: 0.6-1
Severity: normal
Dear Maintainer,
I'd like to run a python3 application that needs
python3-repoze.lru. python3-prepoze.lru package is python3 compatible.
May I commit and do a team upload to build python3 package?
Diff attached.
Regards,
Dmitrijs.
Index: debian/changelog
===
--- debian/changelog (revision 25066)
+++ debian/changelog (working copy)
@@ -1,3 +1,12 @@
+python-repoze.lru (0.6-2) UNRELEASED; urgency=low
+
+ * Team upload
+ * Add python3 package
+ * Bump debhelper to 9, standards to 3.8.4
+ * Install upstream changelog under proper name
+
+ -- Dmitrijs Ledkovs x...@debian.org Tue, 02 Jul 2013 20:38:00 +0100
+
python-repoze.lru (0.6-1) unstable; urgency=low
[ Jakub Wilk ]
Index: debian/compat
===
--- debian/compat (revision 25066)
+++ debian/compat (working copy)
@@ -1 +1 @@
-7
+9
Index: debian/control
===
--- debian/control (revision 25066)
+++ debian/control (working copy)
@@ -3,8 +3,9 @@
Priority: extra
Maintainer: Debian Python Modules Team python-modules-t...@lists.alioth.debian.org
Uploaders: TANIGUCHI Takaki tak...@debian.org
-Build-Depends: debhelper (= 7.0.50~), python-setuptools, python-all
-Standards-Version: 3.9.3
+Build-Depends: debhelper (= 9), python-setuptools, python-all, python3-setuptools, python3-all
+Standards-Version: 3.9.4
+X-Python3-Versions: = 3.2
Homepage: http://www.repoze.org/
Vcs-Svn: svn://anonscm.debian.org/python-modules/packages/python-repoze.lru/trunk/
Vcs-Browser: http://anonscm.debian.org/viewvc/python-modules/packages/python-repoze.lru/trunk/
@@ -17,3 +18,15 @@
repoze.lru is a LRU (least recently used) cache implementation. Keys and
values that are not used frequently will be evicted from the cache faster
than keys and values that are used frequently.
+ .
+ This is the Python 2 version of the package.
+
+Package: python3-repoze.lru
+Architecture: all
+Depends: ${python3:Depends}, ${misc:Depends}
+Description: tiny LRU cache implementation and decorator for Python 3
+ repoze.lru is a LRU (least recently used) cache implementation. Keys and
+ values that are not used frequently will be evicted from the cache faster
+ than keys and values that are used frequently.
+ .
+ This is the Python 3 version of the package.
Index: debian/docs
===
--- debian/docs (revision 25066)
+++ debian/docs (working copy)
@@ -1,4 +1,2 @@
-CHANGES.txt
COPYRIGHT.txt
README.txt
-README.txt
Index: debian/python-repoze.lru.install
===
--- debian/python-repoze.lru.install (revision 0)
+++ debian/python-repoze.lru.install (working copy)
@@ -0,0 +1 @@
+/usr/lib/python2*
Index: debian/python3-repoze.lru.install
===
--- debian/python3-repoze.lru.install (revision 0)
+++ debian/python3-repoze.lru.install (working copy)
@@ -0,0 +1 @@
+/usr/lib/python3*
Index: debian/rules
===
--- debian/rules (revision 25066)
+++ debian/rules (working copy)
@@ -1,4 +1,29 @@
#!/usr/bin/make -f
+PYTHON2:=$(shell pyversions -r)
+PYTHON3:=$(shell py3versions -r)
+py3sdo=set -e; $(foreach py, $(PYTHON3), $(py) $(1);)
+pyalldo=set -e; $(foreach py, $(PYTHON2) $(PYTHON3), $(py) $(1);)
+
%:
- dh $@ --with python2
+ dh $@ --with python2,python3
+
+override_dh_auto_build:
+ dh_auto_build
+ $(call py3sdo, setup.py build)
+
+override_dh_auto_install:
+ dh_auto_install
+ $(call py3sdo, setup.py install --root=$(CURDIR)/debian/tmp --install-layout=deb)
+
+override_dh_auto_clean:
+ dh_auto_clean
+ rm -rf build *.egg-info
+
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+override_dh_auto_test:
+ $(call pyalldo, setup.py test)
+endif
+
+override_dh_installchangelogs:
+ dh_installchangelogs CHANGES.txt
Bug#714785: [INTL:da] Danish translation of the debconf templates cloud-init
Package: cloud-init Severity: wishlist Tags: l10n patch Please include the attached Danish cloud-init translations. joe@pc:~/over/debian/cloud-init$ msgfmt --statistics -c -v -o /dev/null da.po da.po: 11 oversatte tekster. bye Joe da.po.tar.gz Description: GNU Zip compressed data
Bug#714786: python-newt UI causes Segmentation fault after upgrading to wheezy
Package: python-newt Version: 0.52.14-11.1 Severity: normal Dear Maintainer, I have some simple scripts which use a python-newt UI. These started generating segmentation faults after upgrading to wheezy. The problem occurs when a SnackScreen object is created then finished and another SnackScreen object is subsequently created in the same program. The following code runs fine on squeeze but generates a segmentation fault on wheezy. #!/usr/bin/env python import snack sTitle = Count i=0 while i 3: sText = str(i) s = snack.SnackScreen() bcw = snack.ButtonChoiceWindow(s, sTitle, sText, buttons = ['Continue']) s.finish() i = i+1 If the SnackScreen is created once at the top of the script and finished at the end, the problem can be worked around. But that is not pratical with legacy code that was writen for scripts in past years. Thanks Ian -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages python-newt depends on: ii libc62.13-38 ii libnewt0.52 0.52.14-11.1 ii libslang22.2.4-15 ii python 2.7.3-4 python-newt recommends no packages. python-newt 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#714787: python-paste: Please provide python3 package
Package: python-paste Version: 1.7.5.1-4.1 Severity: normal Dear Maintainer, please provide python3 package, as I think paste is python3 compatible. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#707577: broadcom-sta-dkms: wl driver leads to general protection fault on 3.8.11 kernel
I can also confirm this bug with version 5.100.82.112-11 on jessie with linux image 3.9.6-1. The driver works fine with the old kernel version 3.2.46-1 from wheezy though. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714393: sikuli-ide command does nothing except writing [info] locale: fr_FR when java alternative is pointing to sun (java-6-sun)
Hi, Matthieu Dubuget a écrit , Le 28/06/2013 21:19: Package: sikuli-ide Version: 1.0~x~rc3.tesseract3-dfsg1-5 Severity: grave Justification: renders package unusable Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? Just entering sikuli-ide in a terminal * What exactly did you do (or not do) that was effective (or ineffective)? I installed openjdk sudo aptitude install openjdk-7-jre and pointed java to this version sudo update-alternatives --config java Now, it works. * What was the outcome of this action? Output: [info] locale: fr_FR * What outcome did you expect instead? A window opening with the IDE? This is fixed in release 1.0~x~rc3.tesseract3-dfsg1-6 in testing/unstable. I'm preparing an update for wheezy. Thanks, _g. signature.asc Description: OpenPGP digital signature
