Bug#741324: rpm regulary creates directory /~
I've pushed the changes in my NMU to the git repository, so assume that there is no need to send a diff here. Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your sig. signature.asc Description: This is a digitally signed message part
Bug#742245: how-can-i-help should have --gift interface esp. for newbies.
Hey, On 22/03/14 02:00, shirish शिरीष wrote: in-line :- cut I saw the man-page. For newbies, they might or might not discover the man-page. Yes, that is a good point. And even if they do, they will only see some cryptic 'types of opportunities' that might not be meaningful to them. Which brings us to the next question... How about we add '--bug_type' or '--show:bug_type' option that would limit output to selected types? It won't need much more work, but it will be more usable for everyone. That's exactly what I need. Also document it in how-can-i-help --help which would probably be run by bunch of newbie number of times so the easier it is, the more likely that people would start with something as they would be more focussed on fixing a certain type of bug/s. While explaining the syntax and usage of the new option (both in man and in '--help') is straightforward, I wonder if we should specifically mention that the gift bugs are meant for newcomers. Something like: 'Hint: If you want to start contributing to Debian you should probably look at 'gift' bugs first. You can do it by running how-can-i-help (...)'. Should we make such a line appear in '--help' output? Won't pointing at 'gift' bugs reduce changes of spotting other, more fitting opportunities? What do you think? Regards, T. signature.asc Description: OpenPGP digital signature
Bug#742379: apt-cacher: Rewrite init script proposal
Package: apt-cacher
Version: 1.7.6
Severity: minor
Tags: patch
Dear Maintainer,
I'm preparing a server project which uses apt-cacher package.
But init script is not as nice as the others and seems uses old-style
event display.
I've joined an init script which complies with Wheezy start-stop-daemon
usage.
I'll use it in my own project but you could be interested !
Regards
F!nTcH
PS: Init script doesn't seems to be updated, even on 1.7.8 (unstable)
X-Mailer: reportbug 6.4.4
-- System Information:
Debian Release: 7.4
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages apt-cacher depends on:
ii debconf [debconf-2.0] 1.5.49
ii dpkg 1.16.12
ii ed 1.6-2
ii libfilesys-df-perl 0.92-4+b1
ii libfreezethaw-perl 0.5001-1
ii libio-interface-perl 1.06-1+b1
ii libnetaddr-ip-perl 4.062+dfsg-1
ii libsys-syscall-perl0.23-1
ii libwww-curl-perl 4.15-1+b2
ii libwww-perl6.04-1
ii lsb-base 4.1+Debian8+deb7u1
ii perl 5.14.2-21+deb7u1
ii ucf3.0025+nmu3
ii update-inetd 4.43
Versions of packages apt-cacher recommends:
ii libberkeleydb-perl 0.51-1
Versions of packages apt-cacher suggests:
pn libio-socket-inet6-perl none
-- Configuration Files:
/etc/init.d/apt-cacher changed:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DESC=Apt-Cacher
NAME=apt-cacher
DAEMON=/usr/sbin/$NAME
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
test -x $DAEMON || exit 0
if [ -r /etc/default/$NAME ]
then
. /etc/default/$NAME
fi
. /lib/lsb/init-functions
d_start() {
if test $AUTOSTART = 1 ; then
start-stop-daemon --start --quiet \
--exec $DAEMON -- -R 3 -d -p $PIDFILE $EXTRAOPT \
return $?
else
log_warning_msg Not started (AUTOSTART not enabled in
/etc/default/$NAME);
return 0
fi
}
d_stop() {
start-stop-daemon --stop --quiet --retry=TERM/10/KILL/5 --pidfile
$PIDFILE \
--name $NAME
# Also stop any running libcurl backend
/usr/share/apt-cacher/libcurl.pl EXIT
}
case $1 in
start)
log_daemon_msg Starting $DESC $NAME
d_start
log_end_msg $?
;;
stop)
log_daemon_msg Stopping $DESC $NAME
d_stop
log_end_msg $?
;;
restart)
$0 stop
sleep 1
$0 start
;;
force-reload|reload)
log_daemon_msg Reloading configuration files for $DESC $NAME
start-stop-daemon --status --pidfile $PIDFILE
if [ $? != 0 ] ; then
log_warning_msg Not running!
else
kill -HUP `cat $PIDFILE`
log_end_msg 0
fi
;;
status)
status_of_proc -p $PIDFILE $DAEMON $NAME exit 0 || exit $?
;;
*)
log_action_msg Usage: $SCRIPTNAME
{start|stop|restart|reload|force-reload|status}
exit 1
;;
esac
exit 0
-- debconf information:
* apt-cacher/mode: daemon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739054: [Pkg-fglrx-devel] Bug#739054: Not fixed
On Fri, Mar 21, 2014 at 10:52 AM, Giuseppe Iuculano wrote: I've the same crash with 1:14.3~beta1.0-1 Is this happening when you're using chromium? I've seen chromium cause this a couple times now with the latest driver on my machine. Best wishes, MIke -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741187: seahorse-nautilus: diff for NMU version 3.8.0-1.1
Dear maintainer,
I've prepared an NMU for seahorse-nautilus (versioned as 3.8.0-1.1) and
uploaded it.
Regards.
diff -Nru seahorse-nautilus-3.8.0/debian/changelog
seahorse-nautilus-3.8.0/debian/changelog
--- seahorse-nautilus-3.8.0/debian/changelog2013-05-29 13:02:00.0
+0100
+++ seahorse-nautilus-3.8.0/debian/changelog2014-03-22 23:20:14.0
+
@@ -1,3 +1,10 @@
+seahorse-nautilus (3.8.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add correct flag for reaping the progress child (Closes: #741187)
+
+ -- Ben Hutchings b...@decadent.org.uk Sat, 22 Mar 2014 23:19:39 +
+
seahorse-nautilus (3.8.0-1) unstable; urgency=low
* New upstream release.
diff -Nru
seahorse-nautilus-3.8.0/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch
seahorse-nautilus-3.8.0/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch
---
seahorse-nautilus-3.8.0/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch
1970-01-01 01:00:00.0 +0100
+++
seahorse-nautilus-3.8.0/debian/patches/add-correct-flag-for-reaping-the-progress-child.patch
2014-03-22 23:20:50.0 +
@@ -0,0 +1,26 @@
+From: Stef Walter st...@redhat.com
+Date: Fri, 16 Aug 2013 17:24:11 +
+Subject: Add correct flag for reaping the progress child
+Origin:
https://git.gnome.org/browse/seahorse-nautilus/commit/?id=c41f07cf5785b2d755b85f20bf0546c6ce2ebb02
+
+This fixes the WARNING about ECHILD that comes from some versions
+of glib. The WARNING was removed in later versions of glib, but this
+is also a good fix.
+
+https://bugzilla.gnome.org/show_bug.cgi?id=697895
+---
+diff --git a/tool/seahorse-tool-progress.c b/tool/seahorse-tool-progress.c
+index 613e82f..c039118 100644
+--- a/tool/seahorse-tool-progress.c
b/tool/seahorse-tool-progress.c
+@@ -217,7 +217,7 @@ seahorse_tool_progress_start (const gchar *title)
+ argv[2] = (gchar *)title;
+ argv[3] = NULL;
+
+-ret = g_spawn_async_with_pipes (NULL, argv, NULL,
G_SPAWN_STDOUT_TO_DEV_NULL | G_SPAWN_SEARCH_PATH,
++ret = g_spawn_async_with_pipes (NULL, argv, NULL,
G_SPAWN_STDOUT_TO_DEV_NULL | G_SPAWN_SEARCH_PATH | G_SPAWN_DO_NOT_REAP_CHILD,
+ NULL, NULL, progress_pid, progress_fd,
NULL, NULL, err);
+
+ if (!ret) {
+--
+cgit v0.9.2
diff -Nru seahorse-nautilus-3.8.0/debian/patches/series
seahorse-nautilus-3.8.0/debian/patches/series
--- seahorse-nautilus-3.8.0/debian/patches/series 1970-01-01
01:00:00.0 +0100
+++ seahorse-nautilus-3.8.0/debian/patches/series 2014-03-22
23:19:23.0 +
@@ -0,0 +1 @@
+add-correct-flag-for-reaping-the-progress-child.patch
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740917: hibernate breaks after stable update
Control: severity -1 important Control: tag -1 moreinfo The latest stable update included an update to the kernel. You can't hibernate - or rather, you cannot successfully resume - if the running kernel is different from the installed kernel. (But there ought to be a clear error message if hibeneration is aborted for this reason.) Daniel, have you rebooted since the update? Ben. -- Ben Hutchings I'm not a reverse psychological virus. Please don't copy me into your sig. signature.asc Description: This is a digitally signed message part
Bug#742380: please respect http_proxy settings
package: how-can-i-help Hi, how-can-i-help tries to directly downloading files via http, without respecting http_proxy. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#742381: Remove warning message in monit init script in Debian Wheezy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package: monit
Version: 1:5.4-2
When using /etc/monit/monit_delay file in Debian Wheezy no warning
should be displayed. Using the suggested start delay in the config file
results in a different behaviour of monit than using the monit_delay file.
When using start delay in config file monit can not
start/stop/restart/... services during this start delay (see
https://lists.gnu.org/archive/html/monit-general/2010-03/msg2.html).
But some systems need to use monit right after it has been restarted to
handle the services.
Assume the following workflow when delay is done via config file:
1. Modify monit configuration
2. Restart monit via 'service monit restart'
3. Restart a monitored service via 'monit restart xyz' = The error
'Cannot connect to the monit daemon Did you start it with http support?'
appears.
To prevent this error you have to use the monit_delay file to start
monitoring services after a given delay AND the ability to manipulate
services via monit CLI right after it has been restarted. But in this
case the current init script will throw an notification message which
should be removed because the suggested replacement will result in a
different and sometimes unwanted behaviour of monit.
- --- /etc/init.d/monit.orig 2014-03-22 23:45:09.37042 +0100
+++ /etc/init.d/monit 2014-03-22 23:45:30.598810357 +0100
@@ -92,9 +92,6 @@
monit_delayed_monitoring () {
if [ -f $DELAY ]
then
- -printf Warning: Please, set start delay for $NAME in config file\n
- -printf and delete $DELAY file.\n
- -
if [ ! -x $DELAY ]
then
printf Warning: A delayed start file exists ($DELAY)\n
Regards
Volker
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTLhfLAAoJEAHVpGGDJluMbB8QALNrTPei2czgrrpnd60+LTUA
4OK7axPi4zGvJ1sK2Uwi9rlKtK8oX3TEHFtUlCUkY3jkTCgGMbFrN4BjN4bF5jcQ
q7Y0HzRdkx4cBKpF2stP5ZDWPigQK/V/lnNDLJnGCrukOWe9xEqZ400ZTDM4bPtm
1zIp2nwnt6WtoTKYC6LpstWeImLckCk7F2aJPYG2NkjNQW6zjD6nppUY+kXJtiRT
O/jOZeQLbpN18Qk8ZvbFfMVICW4VObeSiUr2+9OD5gMXd36+GKglPKqCmw0ipeBI
blpcjH0K1OUK/ZYmUNlQ9K7v/rawqjZ+q+fziXEvwbWr1tlwKVzYLrzfQ+6QKLC1
hxCS4HQUz63QpLcxkQjO8ljn0U6VGM+SQjLvFy30x3D+eg/ZguVqRjwgJ7GtdqY4
mes2+wNNnjfCTSBlnjVIoUzeaks3vk+f/nwjYWKO/Fmnm/ro+L2zk4WiqUiz1SW4
gvo0N0DaI4F6LBVPfMXgPhOyyknlaxSCmxplbXJ5BnfRIfddMitCtwcnKqK8SH8Q
Tl1FVdxmM91f1pvljFisy8wziwvdBm/TWUUz2gYykCGgd++gHPXZQ3lnjmxHTUEy
X70V8j6Y0QRRYCTycx3yiqs8KzlE/ituuR2zgh80JYJtm1vCDABSxHUAeMYs0YQn
L0DHeqv2GoWvmCVoYvCy
=CBHO
-END PGP SIGNATURE-
Bug#741873: qemu-kvm: crashes booting gnumach (Hurd) with multiboot options
On Thu, Mar 20, 2014 at 3:26 AM, Gabriele Giacone 1o5g4...@gmail.com wrote: On Wed, Mar 19, 2014 at 5:52 AM, Michael Tokarev m...@tls.msk.ru wrote: However, if we're to made a new stable release, I'd like to include quite some more changes too, which are useful for other users. Not that right now I have time for that :( I'm sure, as you already reminded, you would have to explain importance of each one. At the moment, I could propose #719633 debdiff if you agree about backporting it. Bisected. It works fine on wheezy. http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4de6467cbc8f3ddff7f2dcb63f427b0e92de0e9d I'll file a SPU with both #719633 and #741873 patches. Michael, if you have other changes, integrate. -- G..e -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742382: security-tracker: tablular view doesn't consider oldstable/stable (security) repositories
package: security-tracker severity: nomal The information in the new tabular view doesn't consider the security archives. For example, see lighttpd: https://security-tracker.debian.org/tracker/source-package/lighttpd squeeze and wheezy are currently marked as vulnerable in the tabular view for those two issues, but they have already been fixed in a DSA. The individual pages more clearly demonstrate the affected suites: https://security-tracker.debian.org/tracker/CVE-2014-2323 https://security-tracker.debian.org/tracker/CVE-2014-2324 I really enjoy the new view, so thanks for considering this. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
Grace is one of the most useful packages in the entire archive. I am not aware of anything other package that provides the same degree of functionality. Removing it is not a good idea. Drew On Sat, 2014-03-22 at 16:10 +, Neil Williams wrote: I've attached a patch that changes grace to use its embedded t1lib copy. This is not at all ideal since probably most of the t1lib security patches aren't included, but grace is the last package remaining to drop support for t1lib, so it needs a change. Swapping a buggy package for an old embedded buggy package is not a solution. It's not just far from ideal, it is not even worth considering. I'm seeking the removal of pygrace and expeyes so that grace can be removed. CC'ing the relevant maintainers (and filing important bugs for each package). I expect the removal to start in two weeks unless I hear back about a viable solution. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
On Sat, Mar 22, 2014 at 8:01 PM, Drew Parsons wrote: Grace is one of the most useful packages in the entire archive. I am not aware of anything other package that provides the same degree of functionality. Removing it is not a good idea. That can be fixed by anyone willing to spend the time to update it to use freetype. Removing the package will likely provide an incentive for someone sufficiently skilled and interested to do that, and it will eventually be back. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668953: Public interest
Hello, Thanks for filing a request to create a new mailing list. I'm unsure whether we should host this mailing list within Debian due to being spefically for packaging and co-maintainers communication. A lot of other package teams consolidate these efforts through alioth projects which makes it even easier to collaborate together. Have you guys tried that? Feel free to disagree and prove a point for the need of this mailing list, though. However, since it's been almost two years of this request, chances are the real need for the mailing list might be unfounded. Let me know what you think, dm. -- http://damog.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739443: Video crash
Hi, version 1:14.3~beta1.0-1 fixed the issue for me. Regards, WG -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741410: New FGo Release
I have now uploaded a package for the new release to the Debian Mentors site [1]. This should correctly incorporate all of the patches in the BTS (thanks), and some other small changes. This release also changes the maintainer from myself, to the team, as this better matches the other FlightGear related packages. 1: https://mentors.debian.net/package/fgo signature.asc Description: OpenPGP digital signature
Bug#728127: end game ends the whole session
Hi Stefano, Sorry about the long, long delay in getting back to this. Stefano Zacchiroli z...@debian.org writes: On Mon, Oct 28, 2013 at 08:08:41PM -0700, Russ Allbery wrote: I think I may be missing something here, but what semantics do you believe ending the current game in the middle of a match should have? Off-hand, that doesn't seem like a sensible action to me, since wouldn't it then leave the match status in an undefined state? Or, put another way, why would you use end game rather than resign? The semantics is indeed a bit confused, at least in my mind; I don't exclude that a proper solution for this bug would be improved documentation of what end game is supposed to do --- I didn't find any in the doc. So, first of all, whereas resigning implies that you lose, end game does not. Using end game it's the AI that will play in your stead until the end of the current game. So you can also win. I believe the intended use case is that you use to quickly terminate a game, if you are at present not interested in playing, say, the bear off phase. But if you're ahead in that specific game, you do expect (statistically) to win that game. If that happens in, say, the first game of a match to be played at 11-points, you do expect to be able to play yourself the subsequent games. It is this that seems to be impossible, and it smells like a software bug (something like: triggering the boolean match ended instead of the boolean game ended once done). Ah, I see, yes. I should have actually tried this before I responded to your original message, since after having actually done this in a game, the problem is obvious. I'll report this upstream and see what they say. I suspect you're right that it's a bug in the game status tracking. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742383: game-data-packager: Misspelled dependency on virtual package lzh-archiver
Package: game-data-packager Version: 30 Severity: normal game-data-packager suggests the non-existent package name “lhz-archiver”. It should suggest “lzh-archiver” instead. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742245: how-can-i-help should have --gift interface esp. for newbies.
Reply in-line :- On 3/23/14, Tomasz Nitecki t...@tnnn.pl wrote: Hey, On 22/03/14 02:00, shirish शिरीष wrote: in-line :- cut I saw the man-page. For newbies, they might or might not discover the man-page. Yes, that is a good point. And even if they do, they will only see some cryptic 'types of opportunities' that might not be meaningful to them. Which brings us to the next question... Hi Tomasz, That is exactly how I felt. While I'm not using it or going to do any commits but I do use it and want to use it whenever and wherever we promote debian within students and general populace at large. Having said the above, it can be observed that most of the bugs which are there at the moment fall under the following categories :- a. Orphaned - which would arguably have a steeper learning curve, although they would have the old/oldish packaging which should help them to base their work upon. b. RFA - Request for Adoption - This is typically handing-off the package to a new maintainer or a team. This calls for a certain commitment which the new contributor either might not know or understand the implications of doing so. Some of those packages may be team-maintained or not and it'll take time for the contributor to understand that. c. ITA - If somebody else is working on adoption, then just leave them/it alone. A new contributor could help to make it a team-maintained so the life of package in the archive would be more stable and perhaps longer. This has time commitments to it as well. d. RFH - Most of the packages in RFH are important and seem to be (at least to me) more in Priority:Essential state or huge . For e.g. grub2, libisoburn, libreoffice . While some might certainly enjoy it as a challenge, quite a few may find it overwhelming as well. e. Packages removed from testing but no reason given (that I feel is another bug, perhaps already reported) Packages removed from Debian 'testing' (the maintainer might need help): - apt-dpkg-ref - http://packages.qa.debian.org/apt-dpkg-ref - arora - http://packages.qa.debian.org/arora - libboost-system1.53.0 - http://packages.qa.debian.org/boost1.53 - cinnamon-common - http://packages.qa.debian.org/cinnamon - cppcheck - http://packages.qa.debian.org/cppcheck - funny-manpages - http://packages.qa.debian.org/funny-manpages - galternatives - http://packages.qa.debian.org/galternatives - hardinfo - http://packages.qa.debian.org/hardinfo - indicator-application - http://packages.qa.debian.org/indicator-application - remake - http://packages.qa.debian.org/remake - unrar-free - http://packages.qa.debian.org/unrar-free - xserver-xorg-video-qxl - http://packages.qa.debian.org/xserver-xorg-video-qxl Looking at the qa pages though, it is easy to know what the issues are. For instance for apt-dpkg-ref :- http://packages.qa.debian.org/a/apt-dpkg-ref.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737250 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738415 And lastly bugs about sponsorship (RFS) which probably only an existing DD is able to do anything about it. How about we add '--bug_type' or '--show:bug_type' option that would limit output to selected types? It won't need much more work, but it will be more usable for everyone. That's exactly what I need. Also document it in how-can-i-help --help which would probably be run by bunch of newbie number of times so the easier it is, the more likely that people would start with something as they would be more focussed on fixing a certain type of bug/s. While explaining the syntax and usage of the new option (both in man and in '--help') is straightforward, I wonder if we should specifically mention that the gift bugs are meant for newcomers. Something like: 'Hint: If you want to start contributing to Debian you should probably look at 'gift' bugs first. You can do it by running how-can-i-help (...)'. Should we make such a line appear in '--help' output? Won't pointing at 'gift' bugs reduce changes of spotting other, more fitting opportunities? What do you think? First of all, I'm not saying we do not show them. We could have all kinds of options, something like :- $how-can-i-help -rfh or --RFH $how-can-i-help -O $how-can-i-help -rfa or --RFA and like those apart from $how-can-help --gift . The second thing is, as seen above most of the other bugs (except perhaps some of the RFH) would have ensuing time commitments for a new contributor. As far as they are able to understand that from the manpage they could exclusively call that as shared above. Regards, T. Just my 2 paisa. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Bug#742381: Remove warning message in monit init script in Debian Wheezy
Hello, On Sun, Mar 23, 2014 at 12:07:57AM +0100, Volker Theile wrote: When using /etc/monit/monit_delay file in Debian Wheezy no warning should be displayed. It's displayed, because monit_delay was deprecated and will be removed in wheezy+. Using the suggested start delay in the config file results in a different behaviour of monit than using the monit_delay file. Yes, that's slightly different things. When using start delay in config file monit can not start/stop/restart/... services during this start delay (see [1]https://lists.gnu.org/archive/html/monit-general/2010-03/msg2.html). Do you think that monit CLI would work with /etc/monit/monit_delay?! But some systems need to use monit right after it has been restarted to handle the services. Lets examine the reasons for this below... Assume the following workflow when delay is done via config file: 1. Modify monit configuration 2. Restart monit via 'service monit restart' Why you are doing this? Why you can't just do monit reload, instead of restart? To prevent this error you have to use the monit_delay file to start monitoring services I'm sorry, but my point of view: to prevent this error you should read the monit's manpage. That's all. Feel free to reopen this bugreport (with wishlist severity), but please prepare a better argumentation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638760: Removal of grace, pygrace and expeyes
On Sat, 2014-03-22 at 20:07 -0400, Michael Gilbert wrote: On Sat, Mar 22, 2014 at 8:01 PM, Drew Parsons wrote: Grace is one of the most useful packages in the entire archive. I am not aware of anything other package that provides the same degree of functionality. Removing it is not a good idea. That can be fixed by anyone willing to spend the time to update it to use freetype. Removing the package will likely provide an incentive for someone sufficiently skilled and interested to do that, and it will eventually be back. At the core of it, lib/canvas/t1fonts.c would need to be replaced, and Canvas in include/grace/canvasP.h and various client code points would need to be updated to match. Sounds like a worthy candidate for the Google Summer of Code. Drew [... or even better, pay someone to port the entire thing wholesale to Qt] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742384: obnam: several consecutive runs back up unmodified files
Package: obnam Version: 1.7.2-1 Severity: normal No files where modified in the client after running these commands. but second runs backup up 179 files instead of 0 (or so it reports) This is not expected output. I expect it to return 0 new files backup on second run. Please, change output so is not confusing. If it is indeed a bug... please, ask me for debug log or how to help you debug the issue # #this is first run # obnam backup --repository /backup/backup/ sftp://r...@myserver.com: 00h00m00s 1 files 0 B scanned: connecting to to repositoryEnter passphrase for key '/root/.ssh/id_rsa': Backed up 511 files (of 511 found), uploaded 1.0 MiB in 6m43s at 2.7 KiB/s average speed # obnam backup --repository /backup/backup/ sftp://r...@myserver.com: 00h00m00s 1 files 0 B scanned: connecting to to repositoryEnter passphrase for key '/root/.ssh/id_rsa': Backed up 179 files (of 511 found), uploaded 0.0 B in 2m48s at 0.0 B/s average speed # obnam backup --repository /backup/backup/ sftp://r...@myserver.com: 00h00m00s 1 files 0 B scanned: connecting to to repositoryEnter passphrase for key '/root/.ssh/id_rsa': Backed up 179 files (of 511 found), uploaded 0.0 B in 2m54s at 0.0 B/s average speed # obnam generations 2 2014-03-23 00:57:22 .. 2014-03-23 01:04:05 (511 files, 1179227 bytes) 5 2014-03-23 01:04:13 .. 2014-03-23 01:07:01 (511 files, 1179227 bytes) 8 2014-03-23 01:21:09 .. 2014-03-23 01:24:03 (511 files, 1179227 bytes) # obnam diff 2 5 # obnam diff 2 8 # -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages obnam depends on: ii libc6 2.18-4 ii python2.7.5-5 ii python-cliapp 1.20130808-1 ii python-fuse 2:0.2.1-9 ii python-larch 1.20131130-1 ii python-paramiko 1.10.1-1 ii python-tracing0.8-1 ii python-ttystatus 0.23-1 obnam recommends no packages. obnam suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741931: missing license in debian/copyright
tag 741931 pending thanks Fix commited to the repo by maxy. -- Hiroshima '45, Chernobyl '86, Windows '95. Grafitti en Niceto Vega 5940, Buenos Aires. De una foto de Mario Gallo. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#742321: linux-image-3.11-2-amd64: switch to VT on laptop with external screen doesn't update external screen
Control: tag -1 = unreproducible On 2014-03-22 13:06:50 +, Ben Hutchings wrote: Please test Linux 3.13, currently in testing and unstable. I can't reproduce the problem, even with the same Linux 3.11. When the problem occurred, I had used my machine without the external screen a few days before, without rebooting. So, I've tried to do similar things (with Linux 3.11), but I still couldn't reproduce it. BTW, Linux 3.13 (in unstable) still doesn't recognize the touchpad (bug 622231), that's why I'm still using 3.11. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741361: [Pkg-kde-extras] Bug#741361: Please migrate to xine-lib-1.2
tag 741361 moreinfo thanks On Tuesday 11 March 2014 18:14:17 Moritz Muehlenhoff wrote: Source: kaffeine Severity: important Hi, xine-lib is scheduled for removal in jessie. Please build-depend on libxine2-dev instead of libxine-dev (a test compile worked fine for me) The severity will be bumped to RC status in a few weeks/months. Hi Moritz! If libxine is going to be *removed*, can't you simply make libxine- dev provide libxine2 stuff? In that way you will only need binNMUs for this packages. You normally add the soname to dev packages if you intend to provide more than one version at the time. I'll wait for your reply before doing any change :) Kinds regards, Lisandro. -- I must confess, I was born at a very early age. -- Groucho Marx Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#742093: vflib3: missing libxext-dev build-dependency
control: tag -1 patch Hi, I've uploaded an nmu fixing this. Please see patch attached. Best wishes, Mike diff -u vflib3-3.6.14.dfsg/debian/changelog vflib3-3.6.14.dfsg/debian/changelog --- vflib3-3.6.14.dfsg/debian/changelog +++ vflib3-3.6.14.dfsg/debian/changelog @@ -1,3 +1,10 @@ +vflib3 (3.6.14.dfsg-3+nmu2) unstable; urgency=medium + + * Non-maintainer upload. + * Add libxext-dev build dependency (closes: #742093). + + -- Michael Gilbert mgilb...@debian.org Fri, 21 Mar 2014 04:59:28 + + vflib3 (3.6.14.dfsg-3+nmu1) unstable; urgency=medium * Non-maintainer upload. diff -u vflib3-3.6.14.dfsg/debian/control vflib3-3.6.14.dfsg/debian/control --- vflib3-3.6.14.dfsg/debian/control +++ vflib3-3.6.14.dfsg/debian/control @@ -2,7 +2,7 @@ Section: devel Priority: optional Maintainer: OHURA Makoto oh...@debian.org -Build-Depends: autotools-dev, chrpath, debhelper ( 5.0.0), dpatch, gettext, libfreetype6-dev, libkpathsea-dev, libx11-dev, autoconf2.13, xutils-dev +Build-Depends: autotools-dev, chrpath, debhelper ( 5.0.0), dpatch, gettext, libfreetype6-dev, libkpathsea-dev, libx11-dev, autoconf2.13, xutils-dev, libxext-dev Standards-Version: 3.7.2 Package: vflib3-dev
Bug#741361: [Pkg-kde-extras] Bug#741361: Please migrate to xine-lib-1.2
tag 741361 moreinfo thanks On Tuesday 11 March 2014 18:14:17 Moritz Muehlenhoff wrote: Source: kaffeine Severity: important Hi, xine-lib is scheduled for removal in jessie. Please build-depend on libxine2-dev instead of libxine-dev (a test compile worked fine for me) The severity will be bumped to RC status in a few weeks/months. Hi Moritz! If libxine is going to be *removed*, can't you simply make libxine- dev provide libxine2 stuff? In that way you will only need binNMUs for this packages. You normally add the soname to dev packages if you intend to provide more than one version at the time. I'll wait for your reply before doing any change :) Kinds regards, Lisandro. -- I must confess, I was born at a very early age. -- Groucho Marx Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#741290: kde4libs: FTBFS on armel: symbols issues
tag 741290 pending thanks I have just noted that maxy got this change ready. I have also just pinged him, if he does not replies in some days I'll simply push it. Kinds regards, Lisandro. -- Background: talking about Nokia's aquisition of Trolltech. mukidohime That's why there's the FreeQt agreement, a poison pill against just that sort of thing. ... MoDaX mukidohime: agreements can be broken mukidohime MoDaX: Yes, with a massive lawsuit following soon after. mukidohime If Nokia pulled something like that, aseigo would entirely pull some sort of dragonball Z-esque maneuver, and it would probably be visible from the ISS. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#742386: wheezy-pu: package qemu/1.1.2+dfsg-6a+deb7u1
Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu
Hello,
this upload would fix two bugs with severity important regarding booting
GNU/Hurd machines.
#719633
qemu-system-x86_64 crashes on hwaccel machines without specifying
--enable-kvm option and on non-hwaccel machines.
Patch backported from 1.7.0+dfsg-4, current sid version.
#741873
qemu crashes by booting GNU/Hurd with QEMU multiboot options [MBOOT].
That does not let adding hurd-i386 to jenkins.d.n CI, wheezy machine.
Patch backported from upstream 1.2 stable branch.
[MBOOT] http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#QEMU_Multiboot
Attached debdiff.
Thanks for considering.
diff -Nru qemu-1.1.2+dfsg/debian/changelog qemu-1.1.2+dfsg/debian/changelog
--- qemu-1.1.2+dfsg/debian/changelog2013-03-18 07:10:11.0 +0100
+++ qemu-1.1.2+dfsg/debian/changelog2014-03-23 01:38:39.0 +0100
@@ -1,3 +1,11 @@
+qemu (1.1.2+dfsg-6a+deb7u1) stable; urgency=medium
+
+ * Fix crash booting GNU/Hurd on both hwaccel systems without --enable-kvm
+option and on non-hwaccel ones (Closes: #719633).
+ * Fix crash booting GNU/Hurd with QEMU multiboot options (Closes: #741873).
+
+ -- Gabriele Giacone 1o5g4...@gmail.com Mon, 17 Mar 2014 00:36:36 +0100
+
qemu (1.1.2+dfsg-6a) unstable; urgency=low
* reupload to remove two unrelated files slipped in debian/
diff -Nru qemu-1.1.2+dfsg/debian/patches/hurd01.patch
qemu-1.1.2+dfsg/debian/patches/hurd01.patch
--- qemu-1.1.2+dfsg/debian/patches/hurd01.patch 1970-01-01 01:00:00.0
+0100
+++ qemu-1.1.2+dfsg/debian/patches/hurd01.patch 2014-03-23 01:39:02.0
+0100
@@ -0,0 +1,33 @@
+Description: x86: only allow real mode to access 32bit without LMA
+ When we're running in non-64bit mode with qemu-system-x86_64 we can
+ still end up with virtual addresses that are above the 32bit boundary
+ if a segment offset is set up.
+ .
+ GNU Hurd does exactly that. It sets the segment offset to 0x8000 and
+ puts its EIP value to 0x8xxx to access low memory.
+ .
+ This doesn't hit us when we enable paging, as there we just mask away the
+ unused bits. But with real mode, we assume that vaddr == paddr which is
+ wrong in this case. Real hardware wraps the virtual address around at the
+ 32bit boundary. So let's do the same.
+ .
+ This fixes booting GNU Hurd in qemu-system-x86_64 for me.
+Author: Alexander Graf ag...@suse.de
+Origin: upstream,
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=33dfdb56f2f3c8686d218395b871ec12fd5bf30b
+Bug-Debian: https://bugs.debian.org/719633
+
+--- a/target-i386/helper.c
b/target-i386/helper.c
+@@ -512,6 +512,12 @@ int cpu_x86_handle_mmu_fault(CPUX86State
+
+ if (!(env-cr[0] CR0_PG_MASK)) {
+ pte = addr;
++#ifdef TARGET_X86_64
++if (!(env-hflags HF_LMA_MASK)) {
++/* Without long mode we can only address 32bits in real mode */
++pte = (uint32_t)pte;
++}
++#endif
+ virt_addr = addr TARGET_PAGE_MASK;
+ prot = PAGE_READ | PAGE_WRITE | PAGE_EXEC;
+ page_size = 4096;
diff -Nru qemu-1.1.2+dfsg/debian/patches/hurd02.patch
qemu-1.1.2+dfsg/debian/patches/hurd02.patch
--- qemu-1.1.2+dfsg/debian/patches/hurd02.patch 1970-01-01 01:00:00.0
+0100
+++ qemu-1.1.2+dfsg/debian/patches/hurd02.patch 2014-03-23 01:41:09.0
+0100
@@ -0,0 +1,27 @@
+Description: fix entry pointer for ELF kernels loaded with -kernel option
+Author: Henning Schild henn...@hennsch.de
+Origin: upstream,
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4de6467cbc8f3ddff7f2dcb63f427b0e92de0e9d
+Bug-Debian: https://bugs.debian.org/741873
+
+diff --git a/hw/elf_ops.h b/hw/elf_ops.h
+index fa65ce2..731a983 100644
+--- a/hw/elf_ops.h
b/hw/elf_ops.h
+@@ -269,6 +269,17 @@ static int glue(load_elf, SZ)(const char *name, int fd,
+ addr = ph-p_paddr;
+ }
+
++/* the entry pointer in the ELF header is a virtual
++ * address, if the text segments paddr and vaddr differ
++ * we need to adjust the entry */
++if (pentry !translate_fn
++ph-p_vaddr != ph-p_paddr
++ehdr.e_entry = ph-p_vaddr
++ehdr.e_entry ph-p_vaddr + ph-p_filesz
++ph-p_flags PF_X) {
++*pentry = ehdr.e_entry - ph-p_vaddr + ph-p_paddr;
++}
++
+ snprintf(label, sizeof(label), phdr #%d: %s, i, name);
+ rom_add_blob_fixed(label, data, mem_size, addr);
+
diff -Nru qemu-1.1.2+dfsg/debian/patches/series
qemu-1.1.2+dfsg/debian/patches/series
--- qemu-1.1.2+dfsg/debian/patches/series 2013-03-18 06:05:54.0
+0100
+++ qemu-1.1.2+dfsg/debian/patches/series 2014-03-23 01:32:19.0
+0100
@@ -21,3 +21,5 @@
vmdk-fix-data-corruption-bug-in-WRITE-and-READ-handling.patch
Bug#741190: qt4-x11: Improve atomic support on parisc
On Wednesday 12 March 2014 19:10:25 John David Anglin wrote: [snip] I'm fully willing to make the contribution available under any GNU License Terms. Or BSD-license? Would that help? (Maybe not because of the copyright licensing?) I have no objection to this approach and could try to send a signed email on the weekend. It's something I've never done before. OK, then let's try with an unsigned mail to this address (741190@...) stating that you put the patch under a BSD license. If we then get the requirement to get it signed we will see what to do. I don't understand the copyright situation for these files. It is my understanding that Helge contributed the code that is being removed in my patch. The AVR32 header that is copied has a Digia copyright. Indeed, every file that I looked at has a Digia copyright. AVR32? OK, did you write this patch or did you just copied another header from Qt source and applied it to parisc? In case you have done the latest, did you modify anything? Please try to be as verbose as possible, it will certainly be the best for all of us :-D WRT copyright: if you substantially modify a file you also get a copyright right, except the changes are trivial or come from well defined data. Kinds regards, Lisandro. -- Super cow powers | bbq /dev/stomach Traveler1, seen on #debian-ar, irc.oftc.net Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#718434: fixed in ca-certificates 20140223
On Sat, 2014-03-22 at 13:42 +, Ivan Shmakov wrote: First of all, accepting some “random” certificates may give the users some false sense of security. This is true, and also a reason why I'm really convinced of the argument encrypt/sign,... even if it's not trusted... Especially the argument that the only problem one has are MitM attacks sounds kinda stupid since everyone that can intercept your traffic (which an attacker would need to be able anyway - even if all was clear-text)... can also easily do MitM attacks... But what you talk about: false sense of security... that goes much farther... The whole current X.509 based strict-hierarchical trust model with gazillions of CAs gives a false sense of security. Especially when it's controlled by companies like MS, Apple, Mozilla for whom only money counts and who are themselves under the control (just as the CAs as well) of governments. And especially when you have CAs in the list, for which you know for sure, that they will happily assist their governments in forgery ... CNNIC, Turktrust,... just to name the most obvious... Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#735488: Qt4 in arm64: wrap up of the current situation
First of all, sorry for the long delay, I'm trying to catch up with my backlog :-/ On Wednesday 19 March 2014 15:59:01 Mark Salter wrote: On Tue, 2014-03-18 at 14:13 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: Mark: as per [0] Thiago (upstream for qtcore) says: +#ifndef Q_DATA_MEMORY_BARRIER +# define Q_DATA_MEMORY_BARRIER asm volatile(dmb sy\n:::memory) +#endif +#ifndef Q_COMPILER_MEMORY_BARRIER +# define Q_COMPILER_MEMORY_BARRIER asm volatile(:::memory) This shouldn't be necessary anymore if we're using the compilr intrinsics with the right __ATOMIC_xxx macros. The compiler will inser the proper barriers. Would it be possible to fix it? I agree that the explicit barriers are not needed. I could spin another patch with them removed, but that still leaves -fpermissive. Please do spin the patch and I'll push it. [snip] I'm not very fluent with c++ and have no idea what needs to be done with this. I think that's stuff for porters then (wookey?) -- You know it's love when you memorize her IP number to skip DNS overhead. Anonymous Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#741968: closed by Lars Wirzenius l...@liw.fi (Bug#741968: fixed in obnam 1.7.2-1)
Hi Lars, I don't think the problem is fully fixed. I'm still getting weird errors depending how I read the backed up files from the fuse-mounted repository. As an example, I've attached an annoted terminal session showing how if I try to read an epub (with Calibre's ebook-viewer) from a fuse-mounted repo, I get corruption. But if I first copy it out using cp then it's OK. Bizarre stuf... Cheers Nemo backupfuse/Books is an obnam mount of the latest generation /Books is the folder that was backed up ebook-viewer is the Calibre ebook-viewer (v1.23), written in python $ md5 backupfuse/Books/handbook.epub --A) CHECKSUM OK 06d524ff85facfc2993e67ef6494d05f backupfuse/Books/handbook.epub $ ebook-viewer backupfuse/Books/handbook.epub --B1) TRY TO VIEW THE EPUB InputFormatPlugin: EPUB Input running on backupfuse/Books/handbook.epub EPUB appears to be invalid ZIP file, trying a more forgiving ZIP parser --B2) EPUB IS CORRUPTED $ ebook-viewer /Books/handbook.epub --C1) LET'S GO CHECK THE ORIGINAL InputFormatPlugin: EPUB Input running on /Books/handbook.epub Found HTML cover OEBPS/Text/cover.html--C2) ORIGINAL READS OK $ md5 /Books/handbook.epub 06d524ff85facfc2993e67ef6494d05f /Books/handbook.epub --C3) BUT ORIGINAL HAS SAME MD5 WE SAW IN STEP A! $ md5 backupfuse/Books/handbook.epub --D) CHECK MD5 OF BACKED FILE AGAIN b8d645db3af61ae2e8de03f496a1788d backupfuse/Books/handbook.epub --D2) CHECKSUM HAS CHANGED!! $ sudo -s # echo 3 /proc/sys/vm/drop_caches --E) DROP LINUX CACHES # exit $ md5 backupfuse/Books/handbook.epub --F1) CHECK MD5 AGAIN 06d524ff85facfc2993e67ef6494d05f backupfuse/Books/handbook.epub --F2) IT'S CORRECT AGAIN $ $ cp backupfuse/Books/handbook.epub /tmp/ --G1) SO NOW COPY IT OUT USING CP $ md5 /tmp/handbook.epub 06d524ff85facfc2993e67ef6494d05f /tmp/handbook.epub --G2) GOOD CHECKSUM $ ebook-viewer /tmp/handbook.epub InputFormatPlugin: EPUB Input running on /tmp/handbook.epub Found HTML cover OEBPS/Text/cover.html --G3) NOW IT READS OK $ ebook-viewer backupfuse/Books/handbook.epub --H1) TRY READING THE BACKUP COPY InputFormatPlugin: EPUB Input running on backupfuse/Books/handbook.epub Found HTML cover OEBPS/Text/cover.html --H2) BACKUP COPY READS OK PROBABLY FROM CACHE $ sudo -s # echo 3 /proc/sys/vm/drop_caches --I) DROPPING CACHE # exit $ ebook-viewer backupfuse/Books/handbook.epub --J1) TRY READING BACKUP COPY AGAIN InputFormatPlugin: EPUB Input running on backupfuse/Books/handbook.epub EPUB appears to be invalid ZIP file, trying a more forgiving ZIP parser --J2) CORRUPTED AGAIN
Bug#742387: group docker == local root
Package: docker.io Version: 0.9.0+dfsg1-1 Tags: security Severity: important joey@darkstar:~docker.io run -v /:/mnt -t -i mydebian bash2014/03/22 22:56:23 Invalid bind mount: source can't be '/' joey@darkstar:~ docker.io run -v ../../../:/mnt -t -i debian bash root@b7647a89f0d7:/# wc -l /mnt/etc/shadow 42 /mnt/etc/shadow IMHO, this is a straight-up security hole. Non-root users should not be allowed to expose outside system paths into the container. The check for / implies I'm right; the absurdly bad impleentation of the check is ... worrying. Note README.Debian does not indicate that the docker group gives the user root, either inside or outside the container. As noted in the upstream documentation (https://docs.docker.io), Docker will allow non-root users in the docker group to access docker.sock and thus communicate with the daemon. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-3-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 docker.io depends on: ii adduser 3.113+nmu3 ii init-system-helpers 1.18 ii iptables 1.4.21-1 ii libapparmor1 2.8.0-5+b1 ii libc62.18-4 ii libdevmapper1.02.1 2:1.02.83-2 ii libsqlite3-0 3.8.3.1-1 ii perl 5.18.2-2+b1 Versions of packages docker.io recommends: ii aufs-tools 1:3.2+20130722-1.1 ii ca-certificates 20140223 ii git 1:1.9.1-1 ii xz-utils 5.1.1alpha+20120614-2 docker.io suggests no packages. -- no debconf information -- see shy jo signature.asc Description: Digital signature
Bug#728127: end game ends the whole session
Stefano Zacchiroli z...@debian.org writes: This seems, in fact, to be a bug in how the end game functionality is implemented. Here is what happens, according to the console log, when using the end game button in the UI: (Game over) new match 3 (zack) end game play (gnubg) (Game over) next game (Game over) next game (Game over) gnubg seems to be properly ending only the current game. In the session I used to produce the above log both players were 2-away from winning. But the UI does not proceed to the next game, it is just stuck with the log of the game who has been ended automatically, and there seems to be no way of proceeding to the next one. If there is a UI feature to do that, it's really well hidden :-) (or else I'm just too dumb to find it). Hi Stefano, I couldn't find this either, but upstream pointed out that you just click on the center of the board where the dice normally are, and that will advance to the next game. (The text command is new game.) In retrospect, that made sense, since it's used in other similar cases, such as to start the game in the first place. I tried this and it worked reliably for me. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740750: MarkInstall resets candidate, breaks interactive problem resolution
(Discussion started here: https://lists.debian.org/deity/2014/03/msg00015.html) On 12 March 2014 01:21, David Kalnischkies da...@kalnischkies.de wrote: On Tue, Mar 11, 2014 at 12:11:57PM +0100, David Kalnischkies wrote: On Thu, Mar 06, 2014 at 10:24:37AM +0800, Daniel Hartwig wrote: commit 446551c8ffd2c9cb9dcd707c94590e73009f7dd9 […] I need to investigate also whether a previous change to call MarkDelete under the same situation also impacts this use case. No idea really, but I would presume that if this is called for a leaf package it is just another unsatisfied dependency to be resolved. If on the other hand it is a request coming from the user it is protected by FromUser (assuming MarkInstall is called this way). I wonder a bit how this all works at all though with this loopbreaking (the MarkDelete is just the topping) as it was introduced in df77d8a5 (May 2011) by - surprise surprise - me. For interactive use it would probably be better to continue and let the user fix the breakage later. I guess we should move this check out into a IsInstallOk submethod so that you can at least disable this check (and we can stop at the beginning rather than somewhere in the middle). Will see if I can make this work. Attached are two changes which should implement it this way and I guess are better suited to fix the problem as they remove this specific loopbreaking from MarkInstall and moving it to IsInstallOk which a frontend can override and hence disable this and/or other checks. I can see in the aptitude code that you are overriding this method already, so in case we would go with this everything should magically work for aptitude again as it used to be back in the old days, right? Or is there something I am missing? Correct. It is working as previously now, thank you. I am reassigning the regression report (#740750) for your closing. Looking with codesearch suggests that no other frontend is playing with IsInstallOk, so the behavior changes only in so far that breakage (introduced in May 2011, so it might very well be expected behavior now) is now more obvious as the loop is not even started instead of broken somewhere down the line, which sounds like a good thing and an easy way out of this problem is present as well if need be. I was surprised that I could not reproduce this in synaptic, though IIRC they use pinning (force version in their lingo) to change the candidate. Thank you for your quick response on this issue. Regards Daniel Hartwig -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
On 22-Mar-14, at 9:38 PM, Lisandro Damián Nicanor Pérez Meyer wrote: On Wednesday 12 March 2014 19:10:25 John David Anglin wrote: [snip] I'm fully willing to make the contribution available under any GNU License Terms. Or BSD-license? Would that help? (Maybe not because of the copyright licensing?) I have no objection to this approach and could try to send a signed email on the weekend. It's something I've never done before. OK, then let's try with an unsigned mail to this address (741190@...) stating that you put the patch under a BSD license. If we then get the requirement to get it signed we will see what to do. Will do tomorrow. Sorry for the delay. I don't understand the copyright situation for these files. It is my understanding that Helge contributed the code that is being removed in my patch. The AVR32 header that is copied has a Digia copyright. Indeed, every file that I looked at has a Digia copyright. AVR32? OK, did you write this patch or did you just copied another header from Qt source and applied it to parisc? In case you have done the latest, did you modify anything? Please try to be as verbose as possible, it will certainly be the best for all of us :-D I did not write the new qatomic_parisc.h header file. I deleted the old qatomic_parisc.h file, copied qatomic_avr32.h to qatomic_parisc.h and changed all instances of AVR32 to PARISC to ensure that the included header is unique to parisc. Only three lines are changed in the original avr32 header: #ifndef QATOMIC_AVR32_H to #ifndef QATOMIC_PARISC_H #define QATOMIC_AVR32_H to #define QATOMIC_PARISC_H #endif // QATOMIC_AVR32_H to #endif // QATOMIC_PARISC_H Thus, there is no functional difference between the AVR32 and PARISC implementations. I understand that m68k is using a similar approach to enable Qt support. I learned this in a message posted by Thorsten Glaser a few months ago, but I haven't seen a m68k patch. I believe the message is in a Debian bug report. This is what led me to develop the change. WRT copyright: if you substantially modify a file you also get a copyright right, except the changes are trivial or come from well defined data. I would prefer not to have copyright on the modified files because of the commercial licensing of Qt. I believe the changes are trivial and simply revert to the atomic implementation used by all other architectures. Regards, Dave -- John David Anglin dave.ang...@bell.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
On Saturday 22 March 2014 22:42:02 John David Anglin wrote: [snip] AVR32? OK, did you write this patch or did you just copied another header from Qt source and applied it to parisc? In case you have done the latest, did you modify anything? Please try to be as verbose as possible, it will certainly be the best for all of us :-D I did not write the new qatomic_parisc.h header file. I deleted the old qatomic_parisc.h file, copied qatomic_avr32.h to qatomic_parisc.h and changed all instances of AVR32 to PARISC to ensure that the included header is unique to parisc. Only three lines are changed in the original avr32 header: #ifndef QATOMIC_AVR32_H to #ifndef QATOMIC_PARISC_H #define QATOMIC_AVR32_H to #define QATOMIC_PARISC_H #endif // QATOMIC_AVR32_H to #endif // QATOMIC_PARISC_H Thus, there is no functional difference between the AVR32 and PARISC implementations. Ahhh, then everything is much easier then. It's just a matter of letting the right people know. I understand that m68k is using a similar approach to enable Qt support. I learned this in a message posted by Thorsten Glaser a few months ago, but I haven't seen a m68k patch. I believe the message is in a Debian bug report. This is what led me to develop the change. WRT copyright: if you substantially modify a file you also get a copyright right, except the changes are trivial or come from well defined data. I would prefer not to have copyright on the modified files because of the commercial licensing of Qt. This is strange for you to say, as the code will remain 100% libre. If you want to make things clearer do not heasitate to write me in private (just because it's off topic for the bug). I believe the changes are trivial and simply revert to the atomic implementation used by all other architectures. Indeed, this changes everything. -- rata hmm, el enchufe hace chispas... -- rata ha dejado este servidor (Leaving). marga ouch Visto en #lugfi, irc.freenode.net Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#742388: libpulse0: spurious files .pulse and .pulse-cookie in /root directory
Package: libpulse0
Version: 2.0-6.1
Severity: normal
Tags: patch
I noticed that the following files and directory keep appearing in
my /root directory even after I remove them and even if root is not
logged in:
/root/.pulse-cookie
/root/.pulse
/root/.pulse/blahblah-runtime - /tmp/pulse-blah
In particular, they appear during system boot, and when hot-plugging
a (USB) audio device.
The latter obviously made udev suspicious, and debugging revealed
that it calls alsactl restore with HOME unset.
Then alsactl, more precisely libpulse0 which it uses, in function
pa_get_home_dir(), finds that HOME is not set and retrieves the root
user's home directory (/root) via getpwuid().
AFAIK that's wrong! /root is meant for root-as-a-user, i.e. when
logged in as root, not for daemons which run with root permissions.
It also doesn't seem to make much sense: These files are apparently
there to find some data for pulse. But pulse runs per-user (and its
home page severly warns against running in system mode), so these
files under /root are probably never seen and used at all.
Maybe the core of the problem is that different developers are
unclear about the role of alsactl and/or libpulse0. (a) Their own
developers may think they're user programs (so HOME should always be
set), but (b) udev developers apparently think it's OK to call them
from a daemon (so HOME is not set).
If (a) is correct, udev must not call alsactl without HOME set.
If (b) is correct, libpulse0 must accept when HOME is not set, and
not try to set it via getpwuid(), and in this case not create those
files and directory at all (if they're pointless anyway) or put them
somewhere under /run.
Work-around:
Even though I'd tend to think (b) is correct, a quick fix is easier
with (a), so I go with that for now. (In the end it must be sorted
out between those developers.)
Instead of setting HOME, this patch sets USERPROFILE (for a more
localized change), which pa_get_home_dir() checks after HOME and
before using getpwuid():
--- 90-alsa-restore.rules
+++ 90-alsa-restore.rules
@@ -1,2 +1,2 @@
ACTION==add, SUBSYSTEM==sound, KERNEL==controlC*, KERNELS==card*, \
-TEST==/usr/sbin/alsactl, RUN+=/usr/sbin/alsactl restore
$attr{number}
+TEST==/usr/sbin/alsactl, ENV{USERPROFILE}=/run/pulseaudio,
RUN+=/usr/sbin/alsactl restore $attr{number}
Note: With this patch, it actually doesn't create those files at all
because /run/pulseaudio doesn't exist. That seems fine to me, since
these files apparently serve no purpose anyway, see above. If you
want them, just create this directory in some init or wrapper
script. (I've tested both cases.)
-- System Information:
Debian Release: 7.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable')
Architecture: i386 (i686)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741190: qt4-x11: Improve atomic support on parisc
Patch pushed upstream, not it's just time to wait for Thiago to check it :) -- Dadme voto electrónico y con una terminal os haré presidente. el.machi Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#740953: [xserver-xorg-video-nouveau]: No devices detected. (anymore)
Dear Paul, look like xserver-xorg-video-nouveau is not compatible with CONFIG_X86_SYSFB=y option in resent Debian kernels. xserver-xorg-video-nouveau work fine with any kernel (tested 3.12, 3.13, 3.14) with this option disabled # CONFIG_X86_SYSFB is not set Best regards, Viktor Malyarchuk
Bug#638760: Removal of grace, pygrace and expeyes
On Sat, Mar 22, 2014 at 04:10:39PM +, Neil Williams wrote: I'm seeking the removal of pygrace and expeyes so that grace can be removed. CC'ing the relevant maintainers (and filing important bugs for each package). I expect the removal to start in two weeks unless I hear back about a viable solution. If just getting standalone t1lib out of the archive is the goal, I don't mind incorporating all of the existing t1lib patches into the embedded copy. As grace is almost exclusively used to plot locally-supplied numeric data, and is not in any way practical to use in a network setting, it has minimal security risk vs. some other former users of t1lib like php5. If getting t1lib in all its forms out of the archive is the goal, then yes, grace would have to be removed. Rewriting it is not practical and there doesn't seem to be anyone with the time + desire + skillset to adopt t1lib. However, there's also no real replacement for grace itself available. -- 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#740983: openvswitch-datapath-dkms: fails to build dkms module
Control: tag -1 upstream This version of openvswitch (1.9.3) is not compatible with Linux kernel versions after 3.8, and a lot of changes are needed to fix that. The current upstream version (2.1.0) supports 3.11 and the upstream master branch supports 3.12, so further patches will be needed to make this work with the current Debian kernel (3.13, to be replaced by 3.14 in a few weeks). The most problematic API change in 3.13 is in genetlink multicast group registration and identification changed. I don't see any good way to hide this in the compat layer. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Bug#742245: how-can-i-help should have --gift interface esp. for newbies.
Hey, On 23/03/14 01:32, shirish शिरीष wrote: Reply in-line :- cut Yes, that is a good point. And even if they do, they will only see some cryptic 'types of opportunities' that might not be meaningful to them. Which brings us to the next question... Hi Tomasz, That is exactly how I felt. While I'm not using it or going to do any commits but I do use it and want to use it whenever and wherever we promote debian within students and general populace at large. Having said the above, it can be observed that most of the bugs which are there at the moment fall under the following categories :- cut I know it's slightly off topic, but I think you nicely described those. I don't want to rewrite any existing manual, but maybe some additions to descriptions on the how-can-i-help wiki page [1] could also help newcomers? Not anything big, just a one or two additional sentences pointing to some important facts (like orphaned packages having some packaging that could be reused). e. Packages removed from testing but no reason given (that I feel is another bug, perhaps already reported) There are quite a few reasons why a package could be removed. At the moment, how-can-i-help cannot tell why so it provides you with qa link (so you can check yourself). Why do you think it is a bug? And lastly bugs about sponsorship (RFS) which probably only an existing DD is able to do anything about it. That is true, but DDs also use how-can-i-help :) Of course, I do agree that many types of opportunities might not be suitable to a fresh newcomer. So while I don't think we should hide them by default, adding an option to show only selected types (using command parameter; no configuration) is a nice idea :) While explaining the syntax and usage of the new option (both in man and in '--help') is straightforward, I wonder if we should specifically mention that the gift bugs are meant for newcomers. Something like: 'Hint: If you want to start contributing to Debian you should probably look at 'gift' bugs first. You can do it by running how-can-i-help (...)'. Should we make such a line appear in '--help' output? Won't pointing at 'gift' bugs reduce changes of spotting other, more fitting opportunities? What do you think? First of all, I'm not saying we do not show them. We could have all kinds of options, something like :- By no means was I planning to hide them. You should be able to show any combination of types. I was just thinking about adding a 'hint' text about trying 'gift' bugs first. This could make someone to look only for those and miss other type of opportunity in a package he or she uses. Probably not a real issue. Regards, T. [1] https://wiki.debian.org/how-can-i-help signature.asc Description: OpenPGP digital signature
Bug#732997: new upstream version(s) available
Antoine Beaupré wrote: 1.3.35 has been released some time ago, so we are several releases behind here... Note that I am currently working on the packaging for LedgerSMB v1.3.38. If v1.3.39 comes out before I'm done with that, I switch to packaging that version. Robert James Clay j...@rocasa.us
Bug#725758: LedgerSMB 1.3.x and Apache v2.4?
Note I am currently working on the packaging for v1.3.38, which includes a working configuration for Apache 2.4. However; if v1.3.39 comes out before I'm done with that, I switch to packaging that version.
Bug#742380: Debian bug #742380: please respect http_proxy settings
Hey, The problem seems to be related to the value http_proxy is set at. If it starts with URI scheme like 'http://' or 'https://' proxy works fine. However, if it doesn't, URI.parse seems to parse it incorrectly (empty values) which makes HTTP.new to ignore proxy. Holger, can you please confirm that this issue manifests itself only when your http_proxy doesn't start with 'http://' or 'https://'? I can think of two workarounds: 1. We can validate the provided http_proxy value with a regexp ($proxy_url =~ /^https?:\/\//i) and prepend 'http://' if it's missing it. There are two problems here, however: a) we assume that 'http://' is correct URI scheme b) we will get a Ruby exception thrown when there is some weird configuration like 'http:example.com' (missing '//') 2. We can check URI kind (proxy_uri.kind_of?(URI::HTTP) || proxy_uri.kind_of?(URI::HTTPS)) and if it is incorrect we can append 'http://'. Problems are similar to those in (1). The only difference that in case of (b) we will download directly instead of getting an exception. In both cases, we should inform the user that since no URI scheme was provided (or we didn't understand it) we will be trying to use http. Regards, T. signature.asc Description: OpenPGP digital signature
Bug#742309: RFS: libvarnam/3.1.3-1
Hello Eric, Thanks for checking out the project. Where should I improve the project description? The debain control files has proper description about the project. Where else should I change? Thanks On Sun, Mar 23, 2014 at 12:40 AM, Eric L. ewl+debian+nospam2...@lavar.de wrote: Hi, I would recommend to improve the short description. The homepage states cross platform transliterator for Indian languages which sounds more informative to me. Eric On 22 March 2014 07:18:18 CET, Navaneeth K N navaneet...@gmail.com wrote: Package: sponsorship-requests Severity: normal Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package libvarnam * Package name: libvarnam Version : 3.1.3-1 Upstream Author : Navaneeth K N navaneet...@gmail.com * URL : http://varnamproject.com * License : MIT Section : libs It builds those binary packages: libvarnam - Varnam 3 shared library libvarnam-dev - Varnam 3 development files varnamc- Commandline interface to libvarnam To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libvarnam Alternatively, one can do wnload the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libv/libvarnam/libvarnam_3.1.3-1.dsc More information about libvarnam can be obtained from http://www.varnamproject.com. Changes since the last upload: libvarnam (3.1.3-1) stable; urgency=low * varnam_init_from_lang will make the suggestions directory * Fixed varnam_init_from_lang() to set errors correctly * Adding MultiArch directories to varnamc search path * Added uninstall target * MultiArch support to the build system * Added manpages for varnamc Regards, Navaneeth K N -- System Information: Debian Release: wheezy/sid APT prefers saucy-updates APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy'), (100, 'saucy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.0-18-generic (SMP w/2 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash I'm on debian-java, java maintainers, vdr maintainers and debian-mentors; no need to CC me on these lists. Thanks! -- Thanks Navaneeth -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742389: security-tracker: Sype Install Fails
Package: security-tracker Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: Kali Linux 1.0.6 Architecture: amd64 (x86_64) Kernel: Linux 3.12-kali1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742308: openssh: [INTL:ru] Russian debconf templates translation
Package: openssh Version: 1:6.6p1-1 Severity: wishlist Tags: l10n patch Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** Russian debconf templates translation is attached. -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 armhf armel Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ru.po.gz Description: GNU Zip compressed data
Bug#742207: [PATCH] Update the handling of colour output for more use-cases.
Disable colours when stdout is not a terminal by default.
Add an option to enable colours when stdout is not a terminal.
Fixes: https://bugs.debian.org/742207
---
codespell.py | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/codespell.py b/codespell.py
index fdbd5cb..1fd8409 100755
--- a/codespell.py
+++ b/codespell.py
@@ -189,9 +189,13 @@ class FileOpener:
def parse_options(args):
parser = OptionParser(usage=USAGE, version=VERSION)
+parser.set_defaults(colors = sys.stdout.isatty())
parser.add_option('-d', '--disable-colors',
-action = 'store_true', default = False,
+action = 'store_false', dest = 'colors',
help = 'Disable colors even when printing to terminal')
+parser.add_option('-c', '--enable-colors',
+action = 'store_true', dest = 'colors',
+help = 'Enable colors even when not printing to
terminal')
parser.add_option('-w', '--write-changes',
action = 'store_true', default = False,
help = 'write changes in place if possible')
@@ -478,7 +482,7 @@ def main(*args):
build_dict(options.dictionary)
colors = TermColors();
-if options.disable_colors:
+if not options.colors:
colors.disable()
if options.summary:
--
1.9.0
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742309: RFS: libvarnam/3.1.3-1
Package: sponsorship-requests Severity: normal Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package libvarnam * Package name: libvarnam Version : 3.1.3-1 Upstream Author : Navaneeth K N navaneet...@gmail.com * URL : http://varnamproject.com * License : MIT Section : libs It builds those binary packages: libvarnam - Varnam 3 shared library libvarnam-dev - Varnam 3 development files varnamc- Commandline interface to libvarnam To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libvarnam Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libv/libvarnam/libvarnam_3.1.3-1.dsc More information about libvarnam can be obtained from http://www.varnamproject.com. Changes since the last upload: libvarnam (3.1.3-1) stable; urgency=low * varnam_init_from_lang will make the suggestions directory * Fixed varnam_init_from_lang() to set errors correctly * Adding MultiArch directories to varnamc search path * Added uninstall target * MultiArch support to the build system * Added manpages for varnamc Regards, Navaneeth K N -- System Information: Debian Release: wheezy/sid APT prefers saucy-updates APT policy: (500, 'saucy-updates'), (500, 'saucy-security'), (500, 'saucy'), (100, 'saucy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.0-18-generic (SMP w/2 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (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#701962: libsodium packaging
Hi Raúl, On Fri, Mar 21, 2014 at 11:32 PM, Raúl Sánchez rasas...@gmail.com wrote: Latest advice from Alessandro was very specific, I updated package on my repository and reply him privately shortly after his email. I'd say package is in good shape and you can take it from either mentors or my repository [0] [0] http://trismegisto.no-ip.org/hg/libsodium-debian Cool! Your debian/copyright looks much better now. I've to check it. It's also my intention to move my repo to debian hosting, but no sooner there's a real need to do so. That would be when the package is accepted into the archive. But as far as I may get commit access to your repository, it's not strictly needed. As I think I mentioned before, I have no plans to push this into the archive until I see a new upstream release. Are you in contact with upstream? Any ETA when s/he will have a new release? I'm curious about what you think the package is missing (beside upstream release). I've some small changes over your packaging[1]. If you really think [1] is really important I may try a refreshed upstream snapshot + mentors upload. It's needed before the package is included in Debian. In general, it would be nice to have the latest git snapshot of upstream source if there's no stable release until then. Regards, Laszlo/GCS [1] dget -x http://www.barcikacomp.hu/gcs/libsodium_0.4.5+git20140313.dbe51e8ff8-1.dsc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720096: rsyslog ignores rotated log file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 That would give me weekly rotatation of /var/log/syslog, doesn't it? I didn't touch the packaged rotation config file of rsyslog, but having different rotation parameters would surely be an advantage. I would suggest to check if one of the SIGHUPs sent to rsyslog in the worst case might get lost. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJTLS8bAAoJEAqeKp5m04HLGe4H/R5h6UrZzOPhoF1TRrKuNzrx RviZkhAQXgpAq8pO3UOq6YuPQ0Z10xz1um0IFzDhP3gBi8+7zj3w3WJaTVYZ/AFJ BtZJkC5+BH0S6MBsnl23OdYI3mrIdJDfaj95W6QUG4XslnS4U7k65xsfasEMQR1f sRQI0mD0/gbdQAoXlwXFdg6R8z7OeAa+ZTpJl6nj5xJpFJ1KYZCmQH8f6gxWo16g t6TkwBJ+zTY+awMMySZSc3+B0qFoeHCuIpyqPdfqMvKM40GZVNgGooNijVZZHDC9 xpiXmojTlpOrc4/Ztv6j4yQsUuxELbF/U6uy8Bf2QTUPdFFESiZvJwHLmDKNx1Q= =hJlX -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#742310: ITP: python-oslotest -- OpenStack test framework
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-oslotest Version : 0.1 Upstream Author : OpenStack developers openstack-...@lists.openstack.org * URL : https://github.com/openstack/oslo.test * License : Apache-2.0 Programming Lang: Python Description : OpenStack test framework OpenStack test framework that provides base classes and fixtures for creating unit and functional tests. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742311: gkrellm-cpufreq: cpufreq plugin displays only zeros for CPU frequencies
Package: gkrellm-cpufreq Version: 0.6.4-4 Severity: important Dear Maintainer, The cpufreq plugin for gkrellm is displaying only zeros for the CPU frequencies. On this machine there are four cores and I have cpufreq configured to display only (no sliders or governor controls). It displays lines for each core, but each line reads as 0 MHz. I do not believe the issue is related to the kernel version. I have another machine running the same kernel version and also using the amd64 branch of Debian. On that machine, the cpufreq plugin is working properly. The CPU in that machine is a much older dual-core AMD CPU, while the machine this report is coming from is a much newer Intel i5-2467M CPU. I don't know if that makes a difference. I have looked at the code for the cpufreq plugin. Documentation for the kernel's cpufreq functions is scarce, but I did find that the function used to query the current CPU frequency will return 0 in the case of an error. I believe this is why zeros are displayed for all four cores, but I have not been able to determine what that error could be or why it works on one machine and not another. I have also downloaded the source for version 0.6.5 of the plugin and compiled it. That version did not behave any differently that the current Debian/testing version. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gkrellm-cpufreq depends on: ii gkrellm 2.3.5-5 ii libatk1.0-0 2.10.0-2 ii libc62.18-4 ii libcairo21.12.16-2 ii libcpufreq0 008-1 ii libfontconfig1 2.11.0-2 ii libfreetype6 2.5.2-1 ii libgdk-pixbuf2.0-0 2.30.6-1 ii libglib2.0-0 2.39.90-2 ii libgtk2.0-0 2.24.22-1 ii libpango-1.0-0 1.36.2-2 ii libpangocairo-1.0-0 1.36.2-2 ii libpangoft2-1.0-01.36.2-2 gkrellm-cpufreq recommends no packages. gkrellm-cpufreq suggests no packages. -- no debconf information -- --John GruenenfelderSystems Manager, MKS Imaging Technology, LLC. Try Weasel Reader for PalmOS -- http://weaselreader.org This is the most fun I've had without being drenched in the blood of my enemies! --Sam of Sam Max signature.asc Description: Digital signature
Bug#742009: liferea: New upstream release 1.10.7
On 03/18/2014 08:10 AM, Christian Marillat wrote: David Smith sidic...@gmail.com writes: Should be all set now. No problems that I've found.. Although I've only tested 1.10.7 for a little over 40 minutes now :D. Good news then. I hope you can upload a new package quickly. Christian Unfortunately it didn't last long.. I got 1.10.7-1 compiled and installed. It ran perfectly fine for about 24 hours.. When I booted up today, it's not running.. Worse, it's Segfaulting everytime I try to start it up.. I went to report a bug about it, but it turns out.. Somebody from Red Hat already did. http://sourceforge.net/p/liferea/bugs/1142/ -David Smith -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741818: tkgate: FTBFS: block.c:1103:20: error: 'Tcl_Interp' has no member named 'result'
I am working on a patch. A quick fix would be to add -DUSE_INTERP_RESULT to CFLAGS. -- أحمد المحمودي (Ahmed El-Mahmoudy) Digital design engineer GPG KeyID: 0xEDDDA1B7 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8 B176 BC19 6A94 EDDD A1B7 signature.asc Description: Digital signature
Bug#742312: gparted misses the mtools as recommended package
Package: gparted Version: 0.18.0-1 Severity: minor Dear Maintainer, I tried to update the label of a vfat partition using gparted but the Label entry was grayed. I had to install the mtools package to enable this feature According to http://gparted.org/features.php#mtools the mtools package is requested to change the label of such a partition. Would you mind adding mtools as a recommended package for gparted (or it might be a use case too rare to be worth mentioning) Thanks, Marc -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.13-1-486 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 gparted depends on: ii libatkmm-1.6-1 2.22.7-2 ii libc6 2.18-4 ii libgcc1 1:4.8.2-16 ii libglib2.0-02.38.2-5 ii libglibmm-2.4-1c2a 2.36.2-1 ii libgtk2.0-0 2.24.22-1 ii libgtkmm-2.4-1c2a 1:2.24.4-1 ii libpangomm-1.4-12.34.0-1 ii libparted0debian1 2.3-16 ii libsigc++-2.0-0c2a 2.2.11-3 ii libstdc++6 4.8.2-16 ii libuuid12.20.1-5.6 gparted recommends no packages. Versions of packages gparted suggests: pn dmraid none ii dmsetup2:1.02.83-2 ii dosfstools 3.0.16-2 pn gpart none pn jfsutils none pn kpartx none ii ntfs-3g1:2013.1.13AR.1-2 pn reiser4progs none pn reiserfsprogs none pn xfsprogs none pn yelp none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742313: wheezy-pu: package catfish/0.3.2-2+deb7u1
Package: release.debian.org Severity: normal Tags: wheezy User: release.debian@packages.debian.org Usertags: pu Hi, catfish currently has 4 unfixed CVE bugs that affect the version in wheezy. All of them were deemed to be minor issues (no DSA) according to the security tracker, so I'd like to fix them via an upload to stable instead. Debdiff is attached below. Jackson: I'll leave it to you to file a bug requesting an upload to squeeze, just so you know how to handle bugs like this in the future. Ping me for an upload when approved by the release team. diff -u catfish-0.3.2/debian/changelog catfish-0.3.2/debian/changelog --- catfish-0.3.2/debian/changelog +++ catfish-0.3.2/debian/changelog @@ -1,3 +1,10 @@ +catfish (0.3.2-2+deb7u1) stable; urgency=medium + + * Add 50Fix_cve.dpatch. Closes: #739958 +- CVE-2014-2093 CVE-2014-2094 CVE-2014-2095 CVE-2014-2096 + + -- Jackson Doak nosk...@ubuntu.com Sat, 01 Mar 2014 08:05:44 +1100 + catfish (0.3.2-2) unstable; urgency=low * Team upload. diff -u catfish-0.3.2/debian/patches/00list catfish-0.3.2/debian/patches/00list --- catfish-0.3.2/debian/patches/00list +++ catfish-0.3.2/debian/patches/00list @@ -4,0 +5 @@ +50Fix_cve.dpatch \ No newline at end of file only in patch2: unchanged: --- catfish-0.3.2.orig/debian/patches/50Fix_cve.dpatch +++ catfish-0.3.2/debian/patches/50Fix_cve.dpatch @@ -0,0 +1,22 @@ +#! /bin/sh /usr/share/dpatch/dpatch-run + +@DPATCH@ +diff -urNad '--exclude=CVS' '--exclude=.svn' '--exclude=.git' '--exclude=.arch' '--exclude=.hg' '--exclude=_darcs' '--exclude=.bzr' catfish-0.3.2~/catfish.py catfish-0.3.2/catfish.py +--- a/catfish.in 2013-02-13 02:45:27 + b/catfish.in 2014-02-28 04:26:26 + +@@ -1,14 +1,2 @@ + #!/usr/bin/env bash +- +-APPNAME=catfish +- +-if [ -e $APPNAME.pyc ] +-then python $APPNAME.pyc $@ +-else +-if [ -e $APPNAME.py ] +-then python $APPNAME.py $@ +-else +-cd %prefix%/share/$APPNAME +-python $APPNAME.pyc $@ +-fi +-fi ++%python% %prefix%/share/catfish/bin/catfish.py $@ Regards, Vincent -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (700, 'testing'), (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-5-vclaptop-amd64 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602711: pbuilder: please add support for debdelta
Control: tag -1 patch On 11/07/2010 07:13 PM, Ritesh Raj Sarraf wrote: Package: pbuilder Version: 0.199 Severity: wishlist debdelta helps lower down the install size of packages. It only downloads the delta. debdelta is now available at debdelta.debian.net Please add support for it into pbuilder. 13:46:31 rrs@zan:/var/tmp$ diff /tmp/pbuilder-updatebuildenv /usr/lib/pbuilder/pbuilder-updatebuildenv 68a69 $CHROOTEXEC /usr/bin/debdelta-upgrade || true It is a one liner so I didn't bother to prepare a proper patch. Please consider integrating it as it would save a lot of resources both, for our users/developers, and our infrastructure. Appended below is the log after applying this patch, and debdelta into action (ofcourse one is expected to install debdelta and its dependencies in the chroot first) 13:38:33 rrs@zan:/var/tmp$ sudo DIST=experimental pbuilder update I: Current time: Sat Mar 22 13:38:35 IST 2014 I: pbuilder-time-stamp: 1395475715 I: Building the build Environment I: extracting base tarball [/var/cache/pbuilder/experimental-amd64-base.tgz] I: creating local configuration I: copying local configuration I: mounting /proc filesystem I: mounting /run/shm filesystem I: mounting /dev/pts filesystem I: Mounting /var/cache/apt/archives/ I: policy-rc.d already exists I: Refreshing the base.tgz I: upgrading packages Hit http://ftp.debian.org sid InRelease Hit http://ftp.debian.org experimental InRelease Hit http://ftp.debian.org sid/main amd64 Packages/DiffIndex Hit http://ftp.debian.org sid/contrib amd64 Packages/DiffIndex Hit http://ftp.debian.org sid/non-free amd64 Packages/DiffIndex Hit http://ftp.debian.org sid/contrib Translation-en/DiffIndex Hit http://ftp.debian.org sid/main Translation-en/DiffIndex Hit http://ftp.debian.org sid/non-free Translation-en/DiffIndex Hit http://ftp.debian.org experimental/main amd64 Packages/DiffIndex Hit http://ftp.debian.org experimental/contrib amd64 Packages/DiffIndex Hit http://ftp.debian.org experimental/non-free amd64 Packages/DiffIndex Hit http://ftp.debian.org experimental/contrib Translation-en/DiffIndex Hit http://ftp.debian.org experimental/main Translation-en/DiffIndex Hit http://ftp.debian.org experimental/non-free Translation-en/DiffIndex Reading package lists... Created,time 0.29sec, speed 500kB/sec, gcc-4.7-base_4.7.3-12_amd64.deb Created,time 0.17sec, speed 866kB/sec, gcc-4.8-base_4.8.2-17_amd64.deb Created,time 0.12sec, speed 509kB/sec, libasan0_4.8.2-17_amd64.deb Delta is not present: libatomic1_4.8.2-16_4.8.2-17_amd64.debdelta Created,time 0.13sec, speed 348kB/sec, libdebconfclient0_0.189_amd64.deb Created,time 0.15sec, speed 236kB/sec, libgcc1_1%3a4.8.2-17_amd64.deb Delta is too big: libitm1_4.8.2-16_4.8.2-17_amd64.debdelta Created,time 0.12sec, speed 1014kB/sec, libquadmath0_4.8.2-17_amd64.deb Created,time 0.24sec, speed 384kB/sec, libtsan0_4.8.2-17_amd64.deb Created,time 0.17sec, speed 332kB/sec, readline-common_6.3-4_all.deb Delta is not present: tzdata_2013i-1_2014a-1_all.debdelta Downloaded, time 0.53sec, speed 2856B/sec, libgomp1_4.8.2-16_4.8.2-17_amd64.debdelta Created,time 0.12sec, speed 183kB/sec, libgomp1_4.8.2-17_amd64.deb Downloaded, time 0.42sec, speed 11kB/sec, libapt-inst1.5_0.9.15.5+b1_0.9.16.1_amd64.debdelta Created,time 0.23sec, speed 678kB/sec, libapt-inst1.5_0.9.16.1_amd64.deb Downloaded, time 0.71sec, speed 23kB/sec,
Bug#742315: libmrss0-dev: arch-dependent file in Multi-Arch: same package
Package: libmrss0-dev
Version: 0.19.2-4
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch
libmrss0-dev is marked as Multi-Arch: same, but the following file is
architecture-dependent:
/usr/share/doc/libmrss0-dev/examples/Makefile.gz
An example diff between i386 and amd64 (after ungzipping) is attached.
--
Jakub Wilk
diff -ur
libmrss0-dev_0.19.2-4_i386/usr/share/doc/libmrss0-dev/examples/Makefile
libmrss0-dev_0.19.2-4_amd64/usr/share/doc/libmrss0-dev/examples/Makefile
--- libmrss0-dev_0.19.2-4_i386/usr/share/doc/libmrss0-dev/examples/Makefile
2014-03-21 01:54:04.0 +0100
+++ libmrss0-dev_0.19.2-4_amd64/usr/share/doc/libmrss0-dev/examples/Makefile
2014-03-21 01:30:12.0 +0100
@@ -76,8 +76,8 @@
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
-build_triplet = i486-pc-linux-gnu
-host_triplet = i486-pc-linux-gnu
+build_triplet = x86_64-pc-linux-gnu
+host_triplet = x86_64-pc-linux-gnu
noinst_PROGRAMS = parser$(EXEEXT) write$(EXEEXT) new$(EXEEXT) \
time$(EXEEXT) search$(EXEEXT)
subdir = test
@@ -174,13 +174,13 @@
ETAGS = etags
CTAGS = ctags
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
-ACLOCAL = ${SHELL} /build/libmrss-J8HLe0/libmrss-0.19.2/missing aclocal-1.14
+ACLOCAL = ${SHELL} /tmp/buildd/libmrss-0.19.2/missing aclocal-1.14
AMTAR = $${TAR-tar}
AM_DEFAULT_VERBOSITY = 1
AR = ar
-AUTOCONF = ${SHELL} /build/libmrss-J8HLe0/libmrss-0.19.2/missing autoconf
-AUTOHEADER = ${SHELL} /build/libmrss-J8HLe0/libmrss-0.19.2/missing autoheader
-AUTOMAKE = ${SHELL} /build/libmrss-J8HLe0/libmrss-0.19.2/missing automake-1.14
+AUTOCONF = ${SHELL} /tmp/buildd/libmrss-0.19.2/missing autoconf
+AUTOHEADER = ${SHELL} /tmp/buildd/libmrss-0.19.2/missing autoheader
+AUTOMAKE = ${SHELL} /tmp/buildd/libmrss-0.19.2/missing automake-1.14
AWK = mawk
CC = gcc
CCDEPMODE = depmode=none
@@ -205,7 +205,7 @@
INSTALL_PROGRAM = ${INSTALL}
INSTALL_SCRIPT = ${INSTALL}
INSTALL_STRIP_PROGRAM = $(install_sh) -c -s
-LD = /usr/bin/ld
+LD = /usr/bin/ld -m elf_x86_64
LDFLAGS = -Wl,-z,relro -lnxml
LIBMRSS_MAJOR_VERSION = 0
LIBMRSS_MICRO_VERSION = 2
@@ -219,7 +219,7 @@
LN_S = ln -s
LTLIBOBJS =
MAINT = #
-MAKEINFO = ${SHELL} /build/libmrss-J8HLe0/libmrss-0.19.2/missing makeinfo
+MAKEINFO = ${SHELL} /tmp/buildd/libmrss-0.19.2/missing makeinfo
MANIFEST_TOOL = :
MKDIR_P = /bin/mkdir -p
NM = /usr/bin/nm -B
@@ -247,10 +247,10 @@
SHELL = /bin/bash
STRIP = strip
VERSION = 0.19.2
-abs_builddir = /build/libmrss-J8HLe0/libmrss-0.19.2/test
-abs_srcdir = /build/libmrss-J8HLe0/libmrss-0.19.2/test
-abs_top_builddir = /build/libmrss-J8HLe0/libmrss-0.19.2
-abs_top_srcdir = /build/libmrss-J8HLe0/libmrss-0.19.2
+abs_builddir = /tmp/buildd/libmrss-0.19.2/test
+abs_srcdir = /tmp/buildd/libmrss-0.19.2/test
+abs_top_builddir = /tmp/buildd/libmrss-0.19.2
+abs_top_srcdir = /tmp/buildd/libmrss-0.19.2
ac_ct_AR = ar
ac_ct_CC = gcc
ac_ct_DUMPBIN =
@@ -260,9 +260,9 @@
am__tar = $${TAR-tar} chof - $$tardir
am__untar = $${TAR-tar} xf -
bindir = ${exec_prefix}/bin
-build = i486-pc-linux-gnu
-build_alias = i486-linux-gnu
-build_cpu = i486
+build = x86_64-pc-linux-gnu
+build_alias = x86_64-linux-gnu
+build_cpu = x86_64
build_os = linux-gnu
build_vendor = pc
builddir = .
@@ -271,17 +271,17 @@
docdir = ${datarootdir}/doc/${PACKAGE}
dvidir = ${docdir}
exec_prefix = ${prefix}
-host = i486-pc-linux-gnu
+host = x86_64-pc-linux-gnu
host_alias =
-host_cpu = i486
+host_cpu = x86_64
host_os = linux-gnu
host_vendor = pc
htmldir = ${docdir}
includedir = ${prefix}/include
infodir = ${prefix}/share/info
-install_sh = ${SHELL} /build/libmrss-J8HLe0/libmrss-0.19.2/install-sh
-libdir = ${prefix}/lib/i386-linux-gnu
-libexecdir = ${prefix}/lib/i386-linux-gnu
+install_sh = ${SHELL} /tmp/buildd/libmrss-0.19.2/install-sh
+libdir = ${prefix}/lib/x86_64-linux-gnu
+libexecdir = ${prefix}/lib/x86_64-linux-gnu
localedir = ${datarootdir}/locale
localstatedir = /var
mandir = ${prefix}/share/man
Bug#742314: libnxml0-dev: arch-dependent file in Multi-Arch: same package
Package: libnxml0-dev
Version: 0.18.3-5
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch
libnxml0-dev is marked as Multi-Arch: same, but the following file is
architecture-dependent:
/usr/share/doc/libnxml0-dev/examples/Makefile.gz
An example diff between i386 and amd64 (after ungzipping) is attached.
--
Jakub Wilk
diff -ur
libnxml0-dev_0.18.3-5_i386/usr/share/doc/libnxml0-dev/examples/Makefile
libnxml0-dev_0.18.3-5_amd64/usr/share/doc/libnxml0-dev/examples/Makefile
--- libnxml0-dev_0.18.3-5_i386/usr/share/doc/libnxml0-dev/examples/Makefile
2014-03-21 01:38:54.0 +0100
+++ libnxml0-dev_0.18.3-5_amd64/usr/share/doc/libnxml0-dev/examples/Makefile
2014-03-21 01:24:05.0 +0100
@@ -76,8 +76,8 @@
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
-build_triplet = i486-pc-linux-gnu
-host_triplet = i486-pc-linux-gnu
+build_triplet = x86_64-pc-linux-gnu
+host_triplet = x86_64-pc-linux-gnu
noinst_PROGRAMS = parser$(EXEEXT) write$(EXEEXT) new$(EXEEXT) \
easy$(EXEEXT) namespace$(EXEEXT)
subdir = test
@@ -174,13 +174,13 @@
ETAGS = etags
CTAGS = ctags
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
-ACLOCAL = ${SHELL} /build/libnxml-kWV_X6/libnxml-0.18.3/missing aclocal-1.14
+ACLOCAL = ${SHELL} /tmp/buildd/libnxml-0.18.3/missing aclocal-1.14
AMTAR = $${TAR-tar}
AM_DEFAULT_VERBOSITY = 1
AR = ar
-AUTOCONF = ${SHELL} /build/libnxml-kWV_X6/libnxml-0.18.3/missing autoconf
-AUTOHEADER = ${SHELL} /build/libnxml-kWV_X6/libnxml-0.18.3/missing autoheader
-AUTOMAKE = ${SHELL} /build/libnxml-kWV_X6/libnxml-0.18.3/missing automake-1.14
+AUTOCONF = ${SHELL} /tmp/buildd/libnxml-0.18.3/missing autoconf
+AUTOHEADER = ${SHELL} /tmp/buildd/libnxml-0.18.3/missing autoheader
+AUTOMAKE = ${SHELL} /tmp/buildd/libnxml-0.18.3/missing automake-1.14
AWK = mawk
CC = gcc
CCDEPMODE = depmode=none
@@ -205,7 +205,7 @@
INSTALL_PROGRAM = ${INSTALL}
INSTALL_SCRIPT = ${INSTALL}
INSTALL_STRIP_PROGRAM = $(install_sh) -c -s
-LD = /usr/bin/ld
+LD = /usr/bin/ld -m elf_x86_64
LDFLAGS = -Wl,-z,relro
LIBNXML_MAJOR_VERSION = 0
LIBNXML_MICRO_VERSION = 3
@@ -219,7 +219,7 @@
LN_S = ln -s
LTLIBOBJS =
MAINT = #
-MAKEINFO = ${SHELL} /build/libnxml-kWV_X6/libnxml-0.18.3/missing makeinfo
+MAKEINFO = ${SHELL} /tmp/buildd/libnxml-0.18.3/missing makeinfo
MANIFEST_TOOL = :
MKDIR_P = /bin/mkdir -p
NM = /usr/bin/nm -B
@@ -242,10 +242,10 @@
SHELL = /bin/bash
STRIP = strip
VERSION = 0.18.3
-abs_builddir = /build/libnxml-kWV_X6/libnxml-0.18.3/test
-abs_srcdir = /build/libnxml-kWV_X6/libnxml-0.18.3/test
-abs_top_builddir = /build/libnxml-kWV_X6/libnxml-0.18.3
-abs_top_srcdir = /build/libnxml-kWV_X6/libnxml-0.18.3
+abs_builddir = /tmp/buildd/libnxml-0.18.3/test
+abs_srcdir = /tmp/buildd/libnxml-0.18.3/test
+abs_top_builddir = /tmp/buildd/libnxml-0.18.3
+abs_top_srcdir = /tmp/buildd/libnxml-0.18.3
ac_ct_AR = ar
ac_ct_CC = gcc
ac_ct_DUMPBIN =
@@ -255,9 +255,9 @@
am__tar = $${TAR-tar} chof - $$tardir
am__untar = $${TAR-tar} xf -
bindir = ${exec_prefix}/bin
-build = i486-pc-linux-gnu
-build_alias = i486-linux-gnu
-build_cpu = i486
+build = x86_64-pc-linux-gnu
+build_alias = x86_64-linux-gnu
+build_cpu = x86_64
build_os = linux-gnu
build_vendor = pc
builddir = .
@@ -266,17 +266,17 @@
docdir = ${datarootdir}/doc/${PACKAGE}
dvidir = ${docdir}
exec_prefix = ${prefix}
-host = i486-pc-linux-gnu
+host = x86_64-pc-linux-gnu
host_alias =
-host_cpu = i486
+host_cpu = x86_64
host_os = linux-gnu
host_vendor = pc
htmldir = ${docdir}
includedir = ${prefix}/include
infodir = ${prefix}/share/info
-install_sh = ${SHELL} /build/libnxml-kWV_X6/libnxml-0.18.3/install-sh
-libdir = ${prefix}/lib/i386-linux-gnu
-libexecdir = ${prefix}/lib/i386-linux-gnu
+install_sh = ${SHELL} /tmp/buildd/libnxml-0.18.3/install-sh
+libdir = ${prefix}/lib/x86_64-linux-gnu
+libexecdir = ${prefix}/lib/x86_64-linux-gnu
localedir = ${datarootdir}/locale
localstatedir = /var
mandir = ${prefix}/share/man
Bug#741543: When build for mips64el, the default target is mipsn32el
Yunqiang Su wzss...@gmail.com writes:
I think so.
Richard is the guy for upstream ?
Hmm, this still looks multiarch-related to me. It looks like it's changing
the default ABI for mips64-linux-gnu from n32 to n64. That might be right
for a Debian multiarch environment but all upstream mips64-*-linux-gnu
configurations need to continue to use n32 as the default. (The *gnuabin32*
stanza is Debian-local.)
Thanks,
Richard
On Fri, Mar 21, 2014 at 9:59 AM, Matthias Klose d...@debian.org wrote:
Isn't that something unrelated to multiarch, and better should go upstream?
Matthias
Am 13.03.2014 17:34, schrieb Yunqiang Su:
Package: gcc-4.9
Version: 4.9-20140303-1
Hi, you lost a segment of patch in gcc-multiarch.diff for mips64(el), etc
--- gcc-4.9-4.9-20140303.orig/src/gcc/config.gcc2014-03-13
16:27:17.509523462 +
+++ gcc-4.9-4.9-20140303/src/gcc/config.gcc 2014-03-13
16:29:31.845902397 +
@@ -1961,8 +1961,11 @@
tm_file=dbxelf.h elfos.h gnu-user.h linux.h linux-android.h
glibc-stdint.h ${tm_file} mips/gnu-user.h mips/gnu-user64.h
mips/linux64.h mips/linux-common.h
extra_options=${extra_options} linux-android.opt
tmake_file=${tmake_file} mips/t-linux64
- tm_defines=${tm_defines} MIPS_ABI_DEFAULT=ABI_N32
+ tm_defines=${tm_defines} MIPS_ABI_DEFAULT=ABI_64
case ${target} in
+ *gnuabin32*)
+ tm_defines=$(echo ${tm_defines}| sed
's/MIPS_ABI_DEFAULT=ABI_64/MIPS_ABI_DEFAULT=ABI_N32/g')
+ ;;
mips64el-st-linux-gnu)
tm_file=${tm_file} mips/st.h
tmake_file=${tmake_file} mips/t-st
See the gcc-multiarch.diff in gcc-4.8 for this patch.
Thank your very much.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742316: Pulseaudio crashes on pavucontrol closer during skype call
Package: pulseaudio Version: 4.0-6 Severity: important Hi, I've been trying pulseaudio again to see if it has improved or not. One of the problems I'm seeing is that I can crash pulseaduio and so killing all my sound. I've been able to reproduce this twice while doing a call with skype by having pavucontrol open, I think even before the call starts, and during the call close pavucontrol. The pulseaudio process is then gone. I didn't try to debug why, but it seems easy enough to reproduce. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717076: libjpeg draft resolution
On Fri, Mar 21, 2014 at 06:00:04PM -0700, Russ Allbery wrote: Kurt Roeckx k...@roeckx.be writes: My understanding is that the point of virtual packages is so that several *can* provide it. But you're now telling 1 package that it can't do that, while you instead could say only one (other) package can do it in this case. That's one use of virtual packages. However, that's not the primary use of virtual packages for -dev packages. As a general rule, we do not want multiple packages in the archive providing the same -dev package name, because that leads to nondeterministic builds for any package that Build-Depends on the virtual -dev package name, and nondeterministic builds are bad. And I believe the buildds don't even allow it. At least we wants to have that fail but I'm not sure it's still the case. So I keep with my suggestion that you say only 1 package should be providing it instead of saying 1 shouldn't provide it. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741189: src:libimobiledevice: does not work with iOS7 (trust/don't trust dialog)
❦ 9 mars 2014 21:37 CET, Vincent Bernat ber...@debian.org : When connecting to an iOS 7 device, I get a Trust/Don't Trust dialog. Clicking on Trust makes the device disconnect and reconnect and the same dialog is proposed. This bug is known upstream and is fixed in git, but not in any released version. See: https://github.com/libimobiledevice/libimobiledevice/issues/48 This has been fixed in upstream version 1.1.6, just released. -- panic(Aarggh: attempting to free lock with active wait queue - shoot Andy); 2.0.38 /usr/src/linux/fs/locks.c signature.asc Description: PGP signature
Bug#739054: fglrx-driver: fglrx segfault
Version: 1:14.1~beta1.3-1 radeon hd7850 Xorg segfault Version: 1:14.2~beta1.3-1 radeon hd7850 Xorg segfault Version: 1:14.3~beta1.3-1 radeon hd7850 Xorg WORKS! Thanks :-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742317: missing 'wine' binary in several architecture
Package: wine-unstable Version: 1.7.14-4 Severity: critical Coin, /usr/bin/wine is missing from wine-unstable in the following architectures: - i386 - kfreebsd-amd64 which means your package is unusable on this architectures. Regards. -- Marc Dequènes (Duck) pgpsMABRvG7Zy.pgp Description: PGP Digital Signature
Bug#742311: gkrellm-cpufreq: cpufreq plugin displays only zeros for CPU frequencies
Hi John! Thanks for your bug report. On 03/22/2014 08:33 AM, John Gruenenfelder wrote: The cpufreq plugin for gkrellm is displaying only zeros for the CPU frequencies. On this machine there are four cores and I have cpufreq configured to display only (no sliders or governor controls). It displays lines for each core, but each line reads as 0 MHz. Interesting. I will try to reproduce it at work where we have various machines with all kind of host CPUs, so I might be able to find the issue. I will also forward this problem upstream. I do not believe the issue is related to the kernel version. I have another machine running the same kernel version and also using the amd64 branch of Debian. On that machine, the cpufreq plugin is working properly. The CPU in that machine is a much older dual-core AMD CPU, while the machine this report is coming from is a much newer Intel i5-2467M CPU. I don't know if that makes a difference. Thanks for doing some testing ahead, that will help pin-pointing it. I have looked at the code for the cpufreq plugin. Documentation for the kernel's cpufreq functions is scarce, but I did find that the function used to query the current CPU frequency will return 0 in the case of an error. I believe this is why zeros are displayed for all four cores, but I have not been able to determine what that error could be or why it works on one machine and not another. Ok, good to know. Thanks for the heads up. I have also downloaded the source for version 0.6.5 of the plugin and compiled it. That version did not behave any differently that the current Debian/testing version. Where did you get hold of 0.6.5? Upstream just has 0.6.4 on his website [1] and I couldn't find 0.6.5 anywhere on the web. Cheers, Adrian [1] http://chw.populus.org/rub/7 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#742318: apt: version 'amd64' has bad syntax
Package: apt
Version: 0.9.16.1
Severity: normal
/etc/kernel/postinst.d/apt-auto-removal is run when installing a new
linux-image package. A package list is generated at some point, and
version numbers extracted:
dpkg -l | awk '/^ii[ ]+(linux|kfreebsd|gnumach)-image-[0-9]*/ $2 !~
/-dbg$/ { print $2 }' | sed -e 's#\(linux\|kfreebsd\|gnumach\)-image-##'
produces this list:
3.11-2-amd64
3.12-1-amd64
3.13-1-amd64
amd64
Internal function `version_test_gt' is then called (inside a `for'
loop) to set two variables ('latest_version' and 'previous_version').
When it comes to the last list member (see list above), a warning
shows up:
dpkg: warning: version 'amd64' has bad syntax: version number does not
start with digit
The patch bellow keeps odd things away from being thrown at `dpkg
--compare-versions':
--- apt-auto-removal.orig 2014-03-14 10:03:02.0 +0100
+++ apt-auto-removal2014-03-20 19:42:02.337443101 +0100
@@ -46,6 +46,11 @@
latest_version=
previous_version=
for i in $list; do
+ case $i in
+ [!0-9]*)
+ continue
+ ;;
+ esac
if version_test_gt $i $latest_version; then
previous_version=$latest_version
latest_version=$i
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages apt depends on:
ii debian-archive-keyring 2012.4
ii gnupg 1.4.16-1.1
ii libapt-pkg4.12 0.9.16.1
ii libc6 2.18-4
ii libgcc1 1:4.8.2-16
ii libstdc++6 4.8.2-16
apt recommends no packages.
Versions of packages apt suggests:
ii apt-doc 0.9.16.1
pn aptitude | synaptic | wajig none
ii dpkg-dev 1.17.6
ii python-apt 0.9.3.4
--===3830908771293557972==
Content-Type: text/x-diff; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=apt-auto-removal.patch
--===3830908771293557972==--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717743: patch to use apache2/conf-available
tags 717743 patch thanks Hi, find attached a draft patch that should fix the issue by applying the slightly modified code used for lighttpd. Additional modifications have to be done for other maintainer scripts. Best regards, Andi --- gosa.postinst_orig 2013-02-07 21:27:07.0 +0100 +++ gosa.postinst 2014-03-22 10:33:54.578236942 +0100 @@ -68,6 +63,40 @@ fi fi +# conf-available +if [ -d /etc/apache2/conf-available ] ; then + + # Copy GOsa configuration to conf-available directory /etc/apache2/conf-available + if [ ! -L /etc/apache2/conf-available/gosa.conf ]; then + +# Remove old instances of this file +if [ -f /etc/apache2/conf-available/gosa.conf ]; then + echo Found old gosa apache configuration in /etc/apache2/conf-available/gosa.conf - moving it to /etc/apache2/conf-available/gosa.conf.orig ... + echo Please check for changes in /etc/apache2/conf-available/gosa.conf.orig if you modified this file! + mv /etc/apache2/conf-available/gosa.conf /etc/apache2/conf-available/gosa.conf.orig +fi + +echo Making /gosa available in /etc/apache2/conf-available + +# Add GOsa include file +ln -s /etc/gosa/gosa-apache.conf /etc/apache2/conf-available/gosa.conf + fi + + if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then + . /usr/share/apache2/apache2-maintscript-helper + apache2_invoke enconf gosa + apache2_invoke enmod headers + fi + # Finally restart servers + if [ -x /usr/sbin/apache2 ]; then + if [ -x /usr/sbin/invoke-rc.d ]; then + invoke-rc.d apache2 reload + else + /etc/init.d/apache2 reload + fi + fi +fi + if [ -d /etc/lighttpd/conf-available ]; then # Copy GOsa configuration to conf-available directories /etc/lighttpd/conf-available
Bug#717076: libjpeg draft resolution
* Kurt Roeckx (k...@roeckx.be) [140322 01:39]: On Fri, Mar 21, 2014 at 11:38:15PM +, Ian Jackson wrote: In general I worry that your interpretation of resolution texts focuses far too much on the exact words used, and far too little on the substance of the underlying issues. In this particular case we have two packages both of which want to claim the libjpeg-dev virtual package name, which for technical reasons ought to be provided by only one of them. Clearly this is a question of overlapping jurisdictions. My understanding is that the point of virtual packages is so that several *can* provide it. But you're now telling 1 package that it can't do that, while you instead could say only one (other) package can do it in this case. Well, there are two use-cases of virtual packages. One is multiple packages providing the same service, like mail-transfer-agent. This is typically the case with non-development/library-packages. The other is to provide a development-interface, so that switching from foo(n) to foo(n+1) is easier. In that case, only one of these packages may provide the foo-dev-interface package, because we want to predict which package is used while building with foo-dev. This is typically the case with development/library-packages. Though I'm currently thinking if it wouldn't be better to do a slim real package, because it would also make the autobuilders more happy. But that (using a virtual package this way, or a real) is IMHO setting technical policy, which is also within the domain of the tech ctte (and if you read 6.1.1, it seems that we can there make a technical decision even if developers decided different initially without requiring a 3:1-majority). The difference in my view is that you decide between how a set of related packages should interact with each other or that you prevent 1 package from following the normal rules. I have no problem interpreting the first case as falling under 6.1(2), but I'm not yet sure about the second. If the policy for development packages would be that usually many of them provide the same virtual -dev-package and we would like to kick one out via explicit directive to the maintainer drop that virtual package, I would agree with you. However, the normal rules here are that only one provides it, so I think we are at the first case. Andi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742319: exim4-config: Exim4 fail to send when set dc_local_interfaces
Package: exim4-config Version: 4.80-7 Severity: normal On /etc/exim4/update-exim4.conf.conf variable dc_other_hostnames='127.0.0.1:192.168.0.104' which corespond loopback interface and eth0 interfaces. Exim4 fail to send messages. when dc_other_interfaces='' is empty Exim4 send and receive mails -- Package-specific info: Exim version 4.80 #3 built 02-Jan-2013 18:59:25 Copyright (c) University of Cambridge, 1995 - 2012 (c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2012 Berkeley DB: Berkeley DB 5.1.29: (October 25, 2011) Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch nis nis0 passwd Authenticators: cram_md5 plaintext Routers: accept dnslookup ipliteral manualroute queryprogram redirect Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp Fixed never_users: 0 Size of off_t: 8 Configuration file is /var/lib/exim4/config.autogenerated # /etc/exim4/update-exim4.conf.conf # # Edit this file and /etc/mailname by hand and execute update-exim4.conf # yourself or use 'dpkg-reconfigure exim4-config' # # Please note that this is _not_ a dpkg-conffile and that automatic changes # to this file might happen. The code handling this will honor your local # changes, so this is usually fine, but will break local schemes that mess # around with multiple versions of the file. # # update-exim4.conf uses this file to determine variable values to generate # exim configuration macros for the configuration file. # # Most settings found in here do have corresponding questions in the # Debconf configuration, but not all of them. # # This is a Debian specific file dc_eximconfig_configtype='internet' dc_other_hostnames='' dc_local_interfaces='' dc_readhost='' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='' CFILEMODE='644' dc_use_split_config='false' dc_hide_mailname='' dc_mailname_in_oh='true' dc_localdelivery='mail_spool' mailname:marian1000.go.ro -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages exim4-config depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.49 exim4-config recommends no packages. exim4-config suggests no packages. -- Configuration Files: /etc/exim4/passwd.client [Errno 13] Permission denied: u'/etc/exim4/passwd.client' -- debconf information: * exim4/dc_other_hostnames: * exim4/dc_eximconfig_configtype: internet site; mail is sent and received directly using SMTP exim4/no_config: true exim4/hide_mailname: exim4/dc_postmaster: asd exim4/dc_smarthost: * exim4/dc_relay_domains: * exim4/dc_relay_nets: * exim4/mailname: marian1000.go.ro exim4/dc_readhost: * exim4/use_split_config: false exim4/exim4-config-title: * exim4/dc_localdelivery: mbox format in /var/mail/ * exim4/dc_local_interfaces: * exim4/dc_minimaldns: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739054: fglrx-driver: fglrx segfault
sounds nice, but where can i get 1:14.3~beta1.3-1? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739054: fglrx-driver: fglrx segfault
I'am very sorry. I mean version from sid: 1:14.3~beta1.0-1 :-) My mistake -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742318: apt: version 'amd64' has bad syntax
Control: merge 741962 -1
Control: tags -1 + pending
Control: found -1 0.9.16
Control: notfound -1 0.9.15.5
On Sat, Mar 22, 2014 at 10:34:17AM +0100, Cristian Ionescu-Idbohrn wrote:
/etc/kernel/postinst.d/apt-auto-removal is run when installing a new
linux-image package. A package list is generated at some point, and
version numbers extracted:
[…]
Correct analyse and patch, thanks!
I have commited yesterday a slightly different fix though which removes
the star from the initial matcher to get to the same behaviour – which
was also the behaviour before 0.9.16 as shell glob vs regex.
Best regards
David Kalnischkies
commit a17482f89b636a52aacc57776bfc8041cf4da508
Author: David Kalnischkies da...@kalnischkies.de
Date: Fri Mar 21 11:47:56 2014 +0100
only consider versioned kernel packages in autoremove
Metapackages like linux-image-amd64 are otherwise matched by our
extraction as well, which later on can't be successfully compared via
dpkg --compare-versions as the 'amd64' bit isn't a version number.
(Luckily none of our architectures starts with a digit.)
This was broken by me in 0.9.16 as I moved a shell-glob matcher to a
regex-based one which has slightly different semantics regarding '*'.
Closes: 741962
diff --git a/debian/apt.auto-removal.sh b/debian/apt.auto-removal.sh
index 0c51586..c004161 100644
--- a/debian/apt.auto-removal.sh
+++ b/debian/apt.auto-removal.sh
@@ -41,7 +41,7 @@ version_test_gt ()
return $?
}
-list=$(${DPKG} -l | awk '/^ii[ ]+(linux|kfreebsd|gnumach)-image-[0-9]*/ $2 !~ /-dbg$/ { print $2 }' | sed -e 's#\(linux\|kfreebsd\|gnumach\)-image-##')
+list=$(${DPKG} -l | awk '/^ii[ ]+(linux|kfreebsd|gnumach)-image-[0-9]/ $2 !~ /-dbg$/ { print $2 }' | sed -e 's#\(linux\|kfreebsd\|gnumach\)-image-##')
latest_version=
previous_version=
diff --git a/test/integration/test-kernel-helper-autoremove b/test/integration/test-kernel-helper-autoremove
index 7713c08..c51caa7 100755
--- a/test/integration/test-kernel-helper-autoremove
+++ b/test/integration/test-kernel-helper-autoremove
@@ -20,6 +20,7 @@ CURRENTKERNEL=linux-image-$(uname -r)
insertinstalledpackage $CURRENTKERNEL 'amd64' '1'
insertinstalledpackage 'linux-image-1.0.0-2-generic' 'amd64' '1.0.0-2'
insertinstalledpackage 'linux-image-100.0.0-1-generic' 'amd64' '100.0.0-1'
+insertinstalledpackage 'linux-image-amd64' 'amd64' '100.0.0-1'
# ensure that the '.' is really a dot and not a wildcard
insertinstalledpackage 'linux-headers-100-1-generic' 'amd64' '100.0.0-1'
signature.asc
Description: Digital signature
Bug#741338: [Pkg-gtkpod-devel] Bug#741338: Bug#741338: some more details
On Wed, Mar 19, 2014 at 11:23:42AM +0100, JohnMario DoeRossi wrote: I left this out before - systemd is pid 1 process: ps --headers -e | grep systemd 1 ?00:00:01 systemd 212 ?00:00:00 systemd-journal 220 ?00:00:00 systemd-udevd 839 ?00:00:00 systemd-logind Ok thank you, I will test your new .deb. Alright, here it is: http://people.debian.org/~hyperair/usbmuxd_1.0.8-3_i386.deb -- Kind regards, Loong Jin signature.asc Description: Digital signature
Bug#741644: RFS: keyringer/0.3.2-1 -- Distributed secret management using GnuPG and Git
Hi, Silvio Rhatto wrote (18 Mar 2014 00:17:11 GMT) : Em Mon, Mar 17, 2014 at 10:29:12AM +0100, intrigeri escreveu: Great! Here's a quick code review of the changes since 0.2.9. Thanks for the review :) You're welcome. In the future, how about releasing a RC, issueing a call for reviews and tests, before going the full way to RFS? Congrats for the improvements. Only two minor glitches remain. I can now see: - echo Fatal: no such key $recipient on your GPG keyring. + echo Fatal: no such key $recipient on your OpenPGP keyring. ... but I'm not sure OpenPGP keyring makes any sense. Unless the OpenPGP standard defines this concept, I think GnuPG keyring would be more correct. +gpg --batch --refresh-keys $recipient I'm not sure this really does what you mean here. At least the GnuPG manpage does not talk about it. Perhaps use --recv-keys for better clarity? Ping? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570141: Specific Homepage entry for abandoned software
On Fri, Mar 21, 2014 at 10:04:48PM +0100, Bill Allombert wrote: On Tue, Feb 16, 2010 at 07:29:28PM -0500, Jonathan Yu wrote: Hi, I would like to propose the following extension to 5.6.23., the Homepage header line: --- If no homepage exists, e.g. because the software is abandoned and vanished off the net, None can be specified. --- While I see the point in having something like this, perhaps some standard page (hosted on the Debian servers somewhere) informing users that the software has been abandoned (and perhaps pointing to a Google cache/Web Archive cache of the original site, or other relevant information) would provide more benefit. In general, I think it's a good idea to move away from abandoned/unsupported software -- if you wish to continue supporting abandoned software, you should fork it/adopt the project upstream. Nowadays, software homepage almost never disappear. Developers have little incentive to delete the homepage of their abandonned projects, and major code hosting website (sourceforge, etc.) almost never remove dead projects. So the absence of a webpage is not a good indicator whether a project is dead or alive (it is more likely the software never add a webpage). And that do not seem to be Moritz intent, though the bug title might induce to think otherwise. IIRC I was doing a QA upload for a package and I wanted to add a Homepage field. After some digging I noticed the original website went away. In that case adding Homepage: None makes this explicit. 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#724722: binNMUs needed
On Fri, Mar 21, 2014 at 11:57:57 +0100, Michael Fladischer wrote: Transition looks fine, but according to [0] it still needs binNMUs for: * collectd * drizzle * nagios-plugins-contrib [0] https://release.debian.org/transitions/html/libmemcached.html hmm, no, that page says those packages have no Depends on libmemcached at all. Turns out collectd and nagios-plugins-contrib stuff their shared library dependencies in Recommends instead... I've scheduled rebuilds for those two, and left drizzle alone. Cheers, Julien signature.asc Description: Digital signature
Bug#724469: FTBFS on all big-endian architectures
Hi, intrigeri wrote (20 Jan 2014 17:58:03 GMT) : https://rt.cpan.org/Ticket/Display.html?id=89552 Sure. Debian porters, I'll let you subscribe to the RT ticket, and hopefully take care of this porting problem. I'd like to see this RC bug fixed eventually, and I still hope this can be done without dropping support for too many architectures in this package. AFAICT the latest patch proposed by upstream on February 9 [1] has been tested on mips only. My understanding is that upstream has been waiting for more test results since then. Can anyone please test this on other big-endian architectures? It would good if we could at least fix this for the 32-bit ones. [1] https://rt.cpan.org/Ticket/Attachment/1324475/702426/0001-Fix-return-value-handling-on-big-endian-architecture.patch Thanks in advance! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742242: please provide a simple way to run simple tests locally without upgrading the system.
Le Fri, Mar 21, 2014 at 09:38:04AM +0100, Jakub Wilk a écrit : devscripts (= 2.14.1) includes sadt(1), a simple autopkgtest runner. You might want to give it a try. It requires an unpackaged source package, but otherwise seems to do exactly what you want. Thanks a lot to you and Martin for your input and your support ! Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731350: gnome-shell: Numlock not properly working since 3.8
On Fri, 2014-03-21 at 23:25 +, althaser wrote: I am running gnome-shell-3.8.4-5+b1 here and I have numlockx installed but I can't reproduce this issue. Could you please still reproduce it with 3.8.4-5+b1 ? I'm also running 3.8.4-5+b1, now am seeing a disabled numlock again. I don't have numlockx installed anymore, but the problem now seems to be the combination of my keyboard (with hardware forcing numlock on) and some other, more basic, package. This time around, I also don't have an enabled numlock in another tty (Ctrl+Alt+F2 for example). Perhaps this bug can be closed now. The problem I could solve by getting rid of numlockx does not seem to be the same as the one I have now. This one doesn't seem related to Gnome. Best regards, Steven signature.asc Description: This is a digitally signed message part
Bug#685506: Problem with *.zip archives
Hi, forget about this - I was using the wrong uscan. Sorry for the noise. BTW, I do not see any sense in having the original *.zip, a xz compressed tar.xz and the stripped +dfsg.orig.tar.xz. IMHO the latter is fully sufficient and the intermediate result (.tar.xz) could go away. Kind regards Andreas. On Sat, Mar 22, 2014 at 12:01:37AM +0100, Joachim Breitner wrote: Hi, Am Freitag, den 21.03.2014, 23:31 +0100 schrieb Andreas Tille: So, we actually are using the same command with different results which is really strange. so starting in an empty directory (maybe that makes a difference), if you do $ apt-get source mothur $ cd mothur-1.33.0+dfsg/ $ path-to-current/devscripts/scripts/uscan.pl --force-download --repack --repack-compression xz $ tar taf ../Mothur.1.33.3.tar.xz|wc -l $ tar taf ../mothur_1.33.3+dfsg.orig.tar.xz|wc -l what do you get? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732169: musl-bin with /usr/bin/ldd
This bug will be fixed with the introduction of musl_1.0.0-1 upwards. There is now a global link /usr/bin/musl-ldd that can be invoked with musl-ldd MUSLBINARY If you still prefer to access the ldd functionality via the command ldd, then follow the instructions found under: http://wiki.musl-libc.org/wiki/FAQ#Q:_where_is_ldd_.3F
Bug#726214: boswars: missing icon entry in menu file Jessie Release Goal
Control: tags -1 patch Dear maintainer, I have committed a patch to boswars' svn repository. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#742320: lxc: Missing dependency towards rsync - lxc-create requires it
Package: lxc Version: 0.9.0~alpha3-2+deb8u1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Installing lxc did not install required dependencies. * What exactly did you do (or not do) that was effective (or ineffective)? Tried to create a container from a template: SUITE=jessie lxc-create -n TEST -t debian * What was the outcome of this action? When trying to copy the rootfs to /var/lib/lxc/TEST, the operation failed due to rsync being unavailable. * What outcome did you expect instead? Creation of the container should not have failed and when installing lxc, the dependency towards rsync should be resolved automatically. *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lxc depends on: ii libapparmor1 2.8.0-5+b1 ii libc6 2.18-4 ii libcap2 1:2.22-1.2 ii multiarch-support 2.18-4 Versions of packages lxc recommends: ii debootstrap 1.0.59 ii libcap2-bin 1:2.22-1.2 lxc suggests no packages. -- no debconf information
Bug#697354: gnome-shell: freezes randomly on alt-tab
Hi althaser. I tried to enable system sounds on my current stable system and can't reproduce freezes. Thanks. В Птн, 21/03/2014 в 19:06 +, althaser пишет: Hey Alexander, Could you please still reproduce this issue with newer gnome-shell version like 3.4.2-7+deb7u1 or 3.8.4-5+b1 ? cheers, althaser signature.asc Description: This is a digitally signed message part
Bug#742320: lxc: Missing dependency towards rsync - lxc-create requires it
close 742320 thanks lxc does not depend on rsync, some singluar parts of it require it, that is why rsync is a recommends. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742321: linux-image-3.11-2-amd64: switch to VT on laptop with external screen doesn't update external screen
Package: src:linux Version: 3.11.10-1 Severity: normal I usually use my laptop with an external screen, using: xrandr --fb 1920x1200 --output VGA-1 --mode 1920x1200 \ --output LVDS-1 --panning 1920x1200 \ xrandr --output LVDS-1 --off in my .xsession script. But when I switch to a VT with Ctrl-Alt-F1, the contents of the external screen remains frozen, until I type Ctrl-Alt-F7 to go back to X. Then I did: xrandr --output LVDS-1 --auto and tried the same thing. Everything was OK on the laptop screen, but the problem remained with the external screen. -- Package-specific info: ** Version: Linux version 3.11-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-7) ) #1 SMP Debian 3.11.10-1 (2013-12-04) ** Command line: root=/dev/mapper/xvii-root ro quiet reboot=pci ** Not tainted ** Kernel log: [10224.200312] microcode: CPU0 sig=0x1067a, pf=0x80, revision=0xa0b [10224.200312] Enabling non-boot CPUs ... [10224.200312] smpboot: Booting Node 0 Processor 1 APIC 0x1 [10224.212681] microcode: CPU1 sig=0x1067a, pf=0x80, revision=0xa07 [10224.216677] microcode: CPU1 updated to revision 0xa0b, date = 2010-09-28 [10224.220940] CPU1 is up [10224.223325] ACPI: Waking up from system sleep state S3 [10224.277204] uhci_hcd :00:1a.0: System wakeup disabled by ACPI [10224.282368] uhci_hcd :00:1a.1: System wakeup disabled by ACPI [10224.288144] uhci_hcd :00:1a.2: System wakeup disabled by ACPI [10224.309058] ehci-pci :00:1a.7: System wakeup disabled by ACPI [10224.329250] uhci_hcd :00:1d.0: System wakeup disabled by ACPI [10224.334306] uhci_hcd :00:1d.1: System wakeup disabled by ACPI [10224.339325] uhci_hcd :00:1d.2: System wakeup disabled by ACPI [10224.356808] ehci-pci :00:1d.7: System wakeup disabled by ACPI [10224.404240] yenta_cardbus :03:01.0: proprietary Ricoh MMC controller disabled (via cardbus function) [10224.404242] yenta_cardbus :03:01.0: MMC cards are now supported by standard SDHCI controller [10224.436384] PM: noirq resume of devices complete after 179.616 msecs [10224.436581] PM: early resume of devices complete after 0.162 msecs [10224.436616] pci:00: System wakeup disabled by ACPI [10224.436626] e1000e :00:19.0: setting latency timer to 64 [10224.436657] e1000e :00:19.0: irq 44 for MSI/MSI-X [10224.438800] pci :00:1e.0: setting latency timer to 64 [10224.438816] ahci :00:1f.2: setting latency timer to 64 [10224.438949] iwlwifi :0c:00.0: RF_KILL bit toggled to disable radio. [10224.439205] uhci_hcd :00:1a.1: setting latency timer to 64 [10224.439235] usb usb3: root hub lost power or was reset [10224.439281] uhci_hcd :00:1a.0: setting latency timer to 64 [10224.439309] usb usb2: root hub lost power or was reset [10224.439596] uhci_hcd :00:1a.2: setting latency timer to 64 [10224.439622] usb usb4: root hub lost power or was reset [10224.439789] ehci-pci :00:1a.7: setting latency timer to 64 [10224.439996] snd_hda_intel :00:1b.0: irq 47 for MSI/MSI-X [10224.440207] uhci_hcd :00:1d.0: setting latency timer to 64 [10224.440234] usb usb5: root hub lost power or was reset [10224.440383] uhci_hcd :00:1d.1: setting latency timer to 64 [10224.440409] usb usb6: root hub lost power or was reset [10224.440576] uhci_hcd :00:1d.2: setting latency timer to 64 [10224.440603] usb usb7: root hub lost power or was reset [10224.440750] ehci-pci :00:1d.7: setting latency timer to 64 [10224.440774] nouveau [ DRM] re-enabling device... [10224.440854] nouveau [ DRM] resuming kernel object tree... [10224.440862] nouveau [ VBIOS][:01:00.0] running init tables [10224.553632] serial 00:08: activated [10224.646752] nouveau [ DRM] resuming client object trees... [10224.647315] nouveau [ DRM] resuming display... [10224.776064] usb 1-6: reset high-speed USB device number 4 using ehci-pci [10224.780056] ata5: SATA link down (SStatus 0 SControl 300) [10224.788062] ata6: SATA link down (SStatus 0 SControl 300) [10224.944078] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [10225.012865] ata2.00: configured for UDMA/100 [10225.054966] dell_wmi: Received unknown WMI event (0x11) [10225.144090] firewire_core :03:01.1: rediscovered device fw0 [10227.896093] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [10227.905758] ata1.00: configured for UDMA/133 [10227.920132] sd 0:0:0:0: [sda] Starting disk [10228.068228] PM: resume of devices complete after 3631.643 msecs [10228.068567] PM: Finishing wakeup. [10228.068569] Restarting tasks ... done. [10228.077436] video LNXVIDEO:00: Restoring backlight state [10228.710908] e1000e :00:19.0: irq 44 for MSI/MSI-X [10228.716208] usb 4-1: USB disconnect, device number 4 [10228.812427] e1000e :00:19.0: irq 44 for MSI/MSI-X [10228.812904] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [10228.956094] usb 4-1: new full-speed USB device number 5 using uhci_hcd [10229.134357] usb 4-1: New USB
Bug#741939: libmagickcore5: display segmentation fault in libMagickCore.so.5 after chop + mouse wheel
On Fri, Mar 21, 2014 at 4:00 PM, Vincent Lefevre vinc...@vinc17.net wrote: On 2014-03-20 20:24:53 +0100, Bastien ROUCARIES wrote: Could you try expérimental version? The chop function is now broken in the experimental version: it always starts at (0,0). Could you give me a test case ? I will report upstream. Bastien -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742322: systemd: Breasks other services to be restarted/ installed during apt-get dist-upgrade
Package: systemd Version: 204-8 Severity: grave Justification: breaks other packages -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I just upgraded from 204-7 to 204-8 and during the process all services which needs to get restared fails to restart: NOTE: I did *not* yet reboot; will check if after filing this bug and add infos too. Also, a manual retry to restart services fails with the same error. (every service I tried failed so far with the same error. I tried gpsd, cups, samba, bluetooth) Please let me know if you need further details. - -- Best regards, Tobias Frost Example below: LANG=C apt-get install -f Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 20 not upgraded. 4 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up cups-daemon (1.7.1-10) ... Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused invoke-rc.d: initscript cups, action start failed. dpkg: error processing package cups-daemon (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of cups-core-drivers: cups-core-drivers depends on cups-daemon (= 1.7.1-10); however: Package cups-daemon is not configured yet. dpkg: error processing package cups-core-drivers (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of cups: cups depends on cups-core-drivers (= 1.7.1-10); however: Package cups-core-drivers is not configured yet. cups depends on cups-daemon (= 1.7.1-10); however: Package cups-daemon is not configured yet. dpkg: error processing package cups (--configure): dependency problems - leaving unconfigured Setting up gpsd (3.10+dev1~a33bfd44-2) ... Creating/updating gpsd user account... update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused invoke-rc.d: initscript gpsd, action start failed. dpkg: error processing package gpsd (--configure): subprocess installed post-installation script returned error exit status 1 Error: Timeout was reached /etc/init.d/gpsd restart Restarting gpsd (via systemctl): gpsd.serviceFailed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Verbindungsaufbau abgelehnt failed! - -- Package-specific info: - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-1 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-51 ii libacl1 2.2.52-1 ii libaudit11:2.3.4-1 ii libc62.18-4 ii libcap2 1:2.22-1.2 ii libcap2-bin 1:2.22-1.2 ii libcryptsetup4 2:1.6.4-4 ii libdbus-1-3 1.8.0-2 ii libgcrypt11 1.5.3-4 ii libkmod2 16-2 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.8-2 ii libselinux1 2.2.2-1 ii libsystemd-daemon0 204-8 ii libsystemd-journal0 204-8 ii libsystemd-login0204-8 ii libudev1 204-8 ii libwrap0 7.6.q-25 ii sysv-rc 2.88dsf-51 ii udev 204-8 ii util-linux 2.20.1-5.6 Versions of packages systemd recommends: ii libpam-systemd 204-8 Versions of packages systemd suggests: pn systemd-ui none - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJTLXV0AAoJEJFk+h0XvV02y+gP/2mJ8TVlARSaoMWYISFm7o65 AkoAokYuQLp2qAnb65NIKDUhNoQ0rTFsXh1YZmBhr0kvw3X9Zokxx551F0bPSpp9 zWVvpBW71Il84GH230hOi7KDOmN6ojydQnr/ahWUObxm7kqOSB4Mwjq4HyJXNzom GPpydKBNWnUukhzv13xwDpa7w+XZxL5lcW3ODW2tmdVakCMh3v2J0eXR8Rus08B9 nw25dvy4qtx7P+LD8B73xkL12sf8bV+L/l8iUDhkcfv/XvQrCvIsQ9Pppi3cB5Vu uKDc9WuMyiwuyI7+DGbosbNf1B101OJTonRBG9ioqxVtfo0lx7Jk/L3l2ZPaYEjq tPR6RrMtQtD8Onj0pvW3f6u094nqQfHhfSouEkHI3/ZQMPIZtxDBFkpUzDgLFgLR nmteHVxXPTAjSyxMWerTPyKr/LgKVOYRN+As3iCx2WEC5KZWzf2WP7b4OKoIttca 2eM5zrs+cufxuaWhZOkMSm4ej6kyRJGQRuk6Lb4nevDIyfYQxTT1TW/EY9aDTn7X cfI7uK/SVt6pPCP4i7vsPjWFRvxCDddDJT97viyg0VeVfwtERI7T2qsYmQrbGhDJ 1YC7Sx4CrF4cHYJoCAjqoIYwnpH+g9HKgibphP0pG3Kftuv1kHXLbmGA2u5zSaFr I1bdy4tvDPKxW+fLp9fD =lvqA -END PGP SIGNATURE- 0 overridden configuration files found. systemctl-dump.txt Description: inode/empty ==
Bug#742323: ITP: wavtool-pl -- tool to concatenate wav files
Package: wnpp Owner: Ying-Chun Liu (PaulLiu) paul...@debian.org Severity: wishlist * Package name: wavtool-pl Version : 0.20140305 Upstream Author : Ying-Chun Liu (PaulLiu) paul...@debian.org * URL : http://sourceforge.jp/projects/wavtool-pl/ * License : GPLv2+ Programming Lang: C Description : tool to concatenate wav files wavtool-pl is a program to concatenate wav files one by one. Offset, length, and volume can be controlled by parameters. Normally used together with Cadencii editor as one of the UTAU cores. It is a drop-in replacement for the proprietary wavtool.exe in UTAU. -- PaulLiu (劉穎駿) E-mail: Ying-Chun Liu (PaulLiu) paul...@debian.org signature.asc Description: OpenPGP digital signature
Bug#738989: postfix: looking for plugins in '/usr/lib/sasl2', failed to open directory, error: No such file or directory
On Fri, Feb 14, 2014 at 17:29:35 +0100, Stefano wrote: Package: postfix Version: 2.11.0-1 Severity: normal Dear Maintainer, after last update, /var/log/auth.log shows more lines like Feb 14 17:06:20 hpdv5 postfix/smtp[23848]: looking for plugins in '/usr/lib/sasl2', failed to open directory, error: No such file or directory I think this is a dupe of #739601, which was fixed in cyrus-sasl2 2.1.26.dfsg1-9 Your report said: ii libsasl2-2 2.1.26.dfsg1-8 Is this fixed with the newer libsasl2-2? Cheers, Julien signature.asc Description: Digital signature
Bug#742322:
PS: Can't reboot by normal means: LANG=C reboot Failed to open /dev/initctl: No such device or address Failed to talk to init daemon. current systemd status: ps x | grep systemd 1 ?Ss 0:06 /lib/systemd/systemd --system --deserialize 17 558 pts/0S+ 0:00 grep systemd 6545 ?Ss 0:00 /lib/systemd/systemd-udevd 6577 ?Ss 0:00 /lib/systemd/systemd-journald 6583 ?Ss 0:00 /lib/systemd/systemd-logind 20611 ?S 0:00 systemd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742324: icedove: Can't create 2nd e-mail account
Package: icedove Version: 24.3.0-2 Severity: normal Dear Maintainer, I'm trying to add a second e-mail account. All looks OK until the very end when it aborts saying Incoming server already exists. It doesn't say where it exists or offer me a button to fix it. The name of the incoming server is not the same as that on the existing account. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages icedove depends on: ii debianutils 4.4 ii fontconfig2.11.0-5 ii libasound21.0.27.2-3 ii libatk1.0-0 2.10.0-2 ii libc6 2.18-4 ii libcairo2 1.12.16-2 ii libdbus-1-3 1.8.0-2 ii libdbus-glib-1-2 0.102-1 ii libevent-2.0-52.0.21-stable-1 ii libffi6 3.0.13-12 ii libfontconfig12.11.0-5 ii libfreetype6 2.5.2-1 ii libgcc1 1:4.8.2-16 ii libgdk-pixbuf2.0-02.30.6-1 ii libglib2.0-0 2.38.2-5 ii libgtk2.0-0 2.24.22-1 ii libhunspell-1.3-0 1.3.2-7 ii libnspr4 2:4.10.4-1 ii libnss3 2:3.16-1 ii libpango-1.0-01.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpangoft2-1.0-0 1.36.3-1 ii libpixman-1-0 0.32.4-1 ii libsqlite3-0 3.8.3.1-1 ii libstartup-notification0 0.12-3 ii libstdc++64.8.2-16 ii libvpx1 1.3.0-2 ii libx11-6 2:1.6.2-1 ii libxext6 2:1.3.2-1 ii libxrender1 1:0.9.8-1 ii libxt61:1.1.4-1 ii psmisc22.21-1 ii zlib1g1:1.2.8.dfsg-1 Versions of packages icedove recommends: ii hunspell-en-us [hunspell-dictionary] 20070829-6 Versions of packages icedove suggests: ii fonts-lyx 2.0.6-1 ii libgssapi-krb5-2 1.12.1+dfsg-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#742323: ITP: wavtool-pl -- tool to concatenate wav files
Sorry. License: GPLv3+ -- PaulLiu (劉穎駿) E-mail: Ying-Chun Liu (PaulLiu) paul...@debian.org signature.asc Description: OpenPGP digital signature
Bug#742322:
Update: After rebooting using Magic SysReq, system boots and apt-get install -f completes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726902: xboard: missing icon entry in menu file Jessie Release Goal
Control: tags -1 patch Dear maintainer, I have committed a patch to the experimental branch of xboard's git repository. Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#729203: Intent to package FFmpeg
Hi Daniel
On 21.03.2014 22:06, Cyborg Ethly Alpha {My Research Desk} wrote:
I'm interested in becoming a co-maintainer.
You are welcome to do so.
There is already a collab-maint git repository on alioth [1], but
unfortunately some permissions are wrong, so I can't push my packaging
to it. I hope one of the alioth maintainers will get around to fix this.
Best regards,
Andreas
1: http://anonscm.debian.org/gitweb/?p=collab-maint/ffmpeg.git;a=summary
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
