Bug#705029: please provide nethack-curses build
Package: nethack Severity: wishlist There is Yet Another Patch for nethack that adds curses support, and which is available on NOA: http://nethackwiki.com/wiki/Curses_interface It is quite pretty.. for a rationale: http://nethack-curses.wikia.com/wiki/Why_Curses Here's a diffstat: README-curses.txt | 168 ++ doc/window.doc |7 include/config.h | 21 include/flag.h | 10 include/ntconf.h |4 include/rm.h |1 include/system.h |2 include/unixconf.h |4 include/wincurs.h | 291 include/winprocs.h |9 src/cmd.c |2 src/drawing.c | 19 src/options.c | 112 + src/rip.c |2 src/windows.c |6 sys/unix/Makefile.src | 60 sys/winnt/cursmake.gcc | 1348 ++ sys/winnt/defaults.nh | 119 + sys/winnt/nhsetup.bat | 11 util/makedefs.c|3 win/curses/cursdial.c | 1591 ++ win/curses/cursdial.h | 35 win/curses/curses-todo.txt | 92 + win/curses/cursinit.c | 1197 +++ win/curses/cursinit.h | 19 win/curses/cursmain.c | 719 +++ win/curses/cursmesg.c | 485 win/curses/cursmesg.h | 21 win/curses/cursmisc.c | 1003 win/curses/cursmisc.h | 48 win/curses/cursstat.c | 2727 + win/curses/cursstat.h | 12 win/curses/curswins.c | 815 + win/curses/curswins.h | 46 win/tty/termcap.c |7 35 files changed, 10980 insertions(+), 36 deletions(-) -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_CA.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#705030: Insufficient docs about changes due to insserv/startpar
Package: sysv-rc Version: 2.88dsf-41 Severity: minor Ever since I started using SysV, putting a script into e.g. /etc/rcS.d/S99foobar was an acceptable way of ensuring its execution at boot. Arguably, that is not the Debian way and might even be against policy, but it's worked for 20+ years. It no longer does. The reason is that startpar now decides what to run, rather than readdir(), using information provided by insserv. Using update-rc.d to install a symlink to a script in init.d does work. However, this is not really explained in /etc/rcS.d/README, nor in /etc/init.d/README, nor in /usr/share/doc/sysv, nor in the manpages of startpar or insserv. Instead, these documents carry a lot of historical information that isn't really applicable or interesting anymore to anyone but researchers looking into the evolution of SysV on Debian. I realise I am growing old. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sysv-rc depends on: ii debconf [debconf-2.0] 1.5.49 ii insserv1.14.0-5 ii sysvinit-utils 2.88dsf-41 Versions of packages sysv-rc recommends: ii lsb-base 4.1+Debian9 Versions of packages sysv-rc suggests: pn bum none pn sysv-rc-conf none -- debconf information excluded -- .''`. martin f. krafft madduck@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#703468: [3.2.35-2 - 3.2.39-1 regression] fails to boot on apple iMac
On 08/04/13 16:28, Jonathan Nieder wrote: Thanks for testing. As a next test, can you try the 3.4.4 binary package from http://snapshot.debian.org/package/linux/? Hope that helps, Jonathan I've tried that. The 3.4.4-1~eperimental.1 linux-image I built from those sources does not boot, it fails in the same manner as the other 3.2 kernels after 3.2.35. What's next? Cheers, Geoff -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612402: upgraded systems won't boot from UUID volumes
On Sun, 2013-04-07 at 17:15 +0100, Ben Hutchings wrote: So it seems that this is only going to be an issue if users take the unusual step of changing /etc/fstab to refer to LVs by UUID. But maybe there are management tools that do that as a matter of course? I vaguely recall the occasion which caused me to file this bug report but I can't recall any of the specifics about how I got into this state. (Which points to something of a shortcoming in my bug report, sorry). I do notice that I sent the report from a work machine so it might be something to do with Xen, but it is equally likely to be something on one of our server machines or I just happened to send it from work in my lunch hour. I can't think of a reason why I would have deliberately switched from the LV name to a UUID in fstab, but that's not to say I didn't. It's also possible that this was just a transient issue in the installer or grub or some other component which is gone now. Sorry for not being much help here. Ian. signature.asc Description: This is a digitally signed message part
Bug#705031: base: netdev boot sequence problem and possible fix
Package: base
Severity: important
When using iSCSI devices with multipathd, the open-iscsi boot script is started
before multipathd, hence the system tries to mount _netdev devices before
multipath is up-and-running. Thus my iSCSI devices are not mounted at boot time
and need thus be mounted manualy, which is not a handy thing to do for /home
I created a new script called /etc/init.d/mountnetdev, which can be run with
start|stop to mount/umount all _netdev devices or one can use the stop with a
subsystem to stop only part of the mounts.
One important note: the script is in a very early stage, and still requires
bash since dash does not support ${var:x:y}. In the open-iscsi script I
replaced umountiscsi.sh with: mountnetdev stop iscsi
In /etc/rc2.d I created a symlink S23z-mountnetdev so the script is started at
boot after all _netdev required daemons are started.
Hope this helps to make Debian an even better distro.
Greetings,
Dennis Leeuw
Script:
#! /bin/bash
### BEGIN INIT INFO
# Provides: mountnetdev
# Required-Start:
# Required-Stop:
# Should-Start: $network
# Default-Start: S
# Default-Stop:
# Short-Description: Wait for network file systems to be mounted
# Description: Mount and umount _netdev marked filesystems
### END INIT INFO
. /lib/init/vars.sh
. /lib/lsb/init-functions
do_stop_subsys() {
local mountpnt=
local device=
local syspath=
case $1 in
iscsi)
# It can be a multipath device
# a LVM device
# a plain ISCSI disk
# FIXME make sure /etc/fstab is there
for mountpnt in `grep _netdev /etc/fstab | cut -d' ' -f1 | cut -d
-f1`; do
# Strip trailing /
device=${mountpnt%/}
# Strip path
device=${device##*/}
# Strip part
device=${device%-*}
# Check to see if it is a multipath device, very basic check
if [ ${device:0:5} = mpath ]; then
# It's a multipath device: get the active path's disk
device=`multipath -l $device | grep -A1 status=active |
tail -1 | cut -d' ' -f4`
fi
# FIXME make sure /sys/ is mounted
# Find the disk in /sys/
syspath=`find /sys/ -name $device`
syspath=${syspath%/session*}
# See if it has iscsi_host set
if [ -e ${syspath}/iscsi_host ]; then
log_daemon_msg Unmounting iscsi filesystem ${mountpnt}
UMOUNT_RESULT=1
if umount ${mountpnt} /dev/null 21; then
UMOUNT_RESULT=0
fi
log_end_msg $UMOUNT_RESULT
fi
done
;;
esac
}
case $1 in
start)
# Let's mount
log_daemon_msg Mounting _netdev filesystems
MOUNT_RESULT=1
if mount -a -O _netdev /dev/null 21; then
MOUNT_RESULT=0
fi
log_end_msg $MOUNT_RESULT
;;
restart|reload|force-reload)
echo Error: argument '$1' not supported 2
exit 3
;;
stop)
if [ $2 = ]; then
# Let's umount
log_daemon_msg Unmounting _netdev filesystems
UMOUNT_RESULT=1
if umount -a -O _netdev /dev/null 21; then
UMOUNT_RESULT=0
fi
log_end_msg $UMOUNT_RESULT
else
do_stop_subsys $2
fi
;;
*)
echo Usage: $0 start|stop 2
exit 3
;;
esac
: exit 0
-- System Information:
Debian Release: 6.0.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-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
--
De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht
ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct
te informeren door het bericht te retourneren. Het Universitair Medisch
Centrum Utrecht is een publiekrechtelijke rechtspersoon in de zin van de W.H.W.
(Wet Hoger Onderwijs en Wetenschappelijk Onderzoek) en staat geregistreerd bij
de Kamer van Koophandel voor Midden-Nederland onder nr. 30244197.
Denk s.v.p aan het milieu voor u deze e-mail afdrukt.
--
This message may contain confidential information and is intended exclusively
for the addressee. If you receive this message unintentionally, please do not
use the contents but notify the sender immediately by return e-mail. University
Medical Center Utrecht is a
Bug#612610: lintian: should suggest switching to 3.0 (quilt)
Thanks for this interesting discussion. I think it's an important one to have, too. Generally speaking, Debian needs a way to promote best practices, because there *are* practices that are better than others and uniforming on them is a way to both improve the quality of our maintenance work and reduce barriers to contributions (because learning one practice you can then contribute to many packages, as opposed to having to learn many different practices to contribute to different packages). The underlying question here is *where* Debian should do that. For one thing, according to the customs of the Policy editors, the Policy is not such a place. Policy rules on something when it's already the de facto standard in the archive, to have a process that makes what is not following it already converge to it (Russ will surely correct me on this point if I'm wrong). The Developer's Reference is possibly a good place, and has been used in the past to promote best practices: the example of DEP-1 and NMU rules comes to mind. The problem with devref is that it's not directly actionable: we can edit the devref and amend it, but noone will notice until much later. Also, using only the devref is very far from hacker's practices. What we do want to be notified of best practices, is a sort of test suite that yells when we are not following them, as in test harness situations. I.e.: something very similar to lintian :-) On Fri, Mar 29, 2013 at 01:28:29AM +0100, Niels Thykier wrote: I am not sure we can in general promote the use of 3.0 (quilt) over 1.0 via Lintian at the moment[1]. […] [1] Basically it is the same reasons as mentioned in #702671. If I'm not mistaken, that reason is the following, right? Russ Allbery wrote: I agree, but that's not really the point -- the point, rather, was that several long-time DDs responded to the suggestion that it become mandatory with quite a bit of outrage in debian-devel, and several people said that they absolutely refused to add it. That kind of argument is very well-known, but I do question its validity. For one thing, IIRC the discussion Russ was referring to, it happened a long time ago, it might be time to reassess it. Second, the part long-time DDs is questionable, as their opinion is not necessarily more valuable than those of others. It *could* very much be, due to experience and capacities, but old-timers tend also to be much more inclined to stay put with old practices, which are not necessarily the best ones. Finally, there is the usual counter-argument that those vocals on lists are not necessarily representative of a majority of a population: they might be a strict, but very vocal, minority. Personally, I'd love if the lintian maintainers could assume their responsibility as promoting the adoption of best-practices. After all, it is you people who are the first steward of package quality, thanks to lintian. As a developer I'd have no problem whatsoever in trusting your judgement about that. And if I will ever find myself in disagreement I can either stop using lintian (with all the associated negative quality consequences), add an override documenting my disagreement, or try to convince you that you're wrong discussing in a bug report as we do for every other package. Failing that, we might consider delegating the responsibility of promoting best practices to the devref editors, and have lintian implement what is written in there. But that is a much more heavyweight process in terms of community costs and is more far away from hacker standard practices. As such, it has much less possibilities of having an impact onto best practices adoption in the archive. Hope this helps, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#612610: lintian: should suggest switching to 3.0 (quilt)
Stefano Zacchiroli z...@debian.org writes: Personally, I'd love if the lintian maintainers could assume their responsibility as promoting the adoption of best-practices. After all, it is you people who are the first steward of package quality, thanks to lintian. As a developer I'd have no problem whatsoever in trusting your judgement about that. And if I will ever find myself in disagreement I can either stop using lintian (with all the associated negative quality consequences), add an override documenting my disagreement, or try to convince you that you're wrong discussing in a bug report as we do for every other package. My comment earlier in this bug is that the blow-up about this happened a long time ago, and while I don't think we should just add this without any discussion, I think someone should just bring it up on debian-devel again. My guess is that time has gone by, people have calmed down, and people have seen the reasons why 3.0 (quilt) with single-debian-patch is clearly better than 1.0 in terms of avoiding mistakes, and I doubt there will be any opposition this time. If there's still opposition, we can have the conversation again, but there doesn't seem to be any point in borrowing trouble when we could just mail debian-devel and ask and quite possibly have an unproblematic consensus. -- 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#705032: manpages-posix: typo in eval.1
Package: manpages-posix Version: 2.16-1 Severity: minor Tags: patch The EXAMPLES section reads: foo=10 x=foo y='$'$x echo $y $fooeval y='$'$x echo $y 10 There is clearly a missing newline between $foo and eval on the 4th line here. It's also all in bold, which is unnecessary and confusing. Suggested patch: --- /tmp/eval.1posix.orig 2005-12-13 11:00:50.0 + +++ /tmp/eval.1posix2013-04-09 08:53:08.0 +0100 @@ -64,9 +64,10 @@ \fBfoo=10 x=foo y='$'$x echo $y -\fP\fB$foo\fP\fBeval y='$'$x +\fP$foo +\fBeval y='$'$x echo $y -\fP\fB10\fP +\fP10 .fi .RE .SH RATIONALE Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704457: [php-maint] Bug#704457: gd extension broken due new embedded libgd functions not added to gd_compat layer
I would recommend to NOT USE php from experimental if you need to rely on it. The version in experimental is not intended to be used for anything than testing. — Ondřej Surý On Sun, Apr 7, 2013 at 1:33 PM, Riaas Mokiem arucar...@gmail.com wrote: I also had this problem, so I was happy to see it was already fixed. Though i noticed on php.net that another php beta release should be available in a few days, I was hoping that this an interim version (5.5.0~beta2-2 perhaps?) could be uploaded already, because the owncloud 5.0.3 package was uploaded yesterday and it seems to require gd to work. So this is no longer a matter of merely having persistent error notifications. If this is not possible, I will just have to wait a little while longer (it's all from experimental anyway, so it's to be expected). It might still be useful to communicate this to the owncloud maintainers though.
Bug#705033: subversion: obsolete conffile not removed
Package: subversion
Version: 1.7.9-1
Severity: important
Usertags: conffile
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate
The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by dh_installdeb
to remove these obsolete conffiles on upgrade.
http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
http://manpages.debian.net/man/1/dh_installdeb
This bug report brought to you by adequate:
http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/
pabs@chianamo ~ $ adequate subversion
subversion: obsolete-conffile /etc/emacs/site-start.d/50psvn.el
pabs@chianamo ~ $ dpkg-query -W -f='${Conffiles}\n' subversion | grep obsolete
/etc/emacs/site-start.d/50psvn.el 8354cb014ecbde901559dcfd41fb9737 obsolete
pabs@chianamo ~ $ dpkg -L subversion | sort -u | grep /etc 1
pabs@chianamo ~ $ dpkg-deb --contents
/var/cache/apt/archives/subversion_1.7.9-1_amd64.deb | sed
's/^.*\.\//\//;s_/$__' | sort -u | grep /etc 2
pabs@chianamo ~ $ diff -u 1 2
--- 1 2013-04-09 16:01:27.465790624 +0800
+++ 2 2013-04-09 16:01:48.349790425 +0800
@@ -1,7 +1,6 @@
/etc
/etc/bash_completion.d
/etc/bash_completion.d/subversion
-/etc/emacs/site-start.d/50psvn.el
/etc/subversion
/etc/subversion/config
/etc/subversion/servers
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (700, 'testing'), (600, 'unstable'), (550, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-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 subversion depends on:
ii libapr1 1.4.6-3
ii libc6 2.13-38
ii libsasl2-2 2.1.25.dfsg1-6
ii libsvn1 1.7.9-1
Versions of packages subversion suggests:
ii db5.1-util5.1.29-5
ii patch 2.6.1-3
pn subversion-tools none
--
bye,
pabs
http://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Bug#703852: [Pkg-mediawiki-devel] Bug#703852: Bug#703852: [mediawiki] mw{en, dis}ext ineffective for new installs
On Mon, 8 Apr 2013, Filipus Klutiero wrote: It seems easy to workaround by modifying that file to support a double inclusion. Probably. mediawiki-extensions-base currently provides 2 extensions which provide Special:Interwiki: the old extension, SpecialInterwiki, and the new extension, Interwiki (although the version of Interwiki packaged is outdated). However, Ah. It was designed to provide SpecialInterwiki (only). The rest just got pulled into the package because the source package for mediawiki-extensions likes to pull in whole directories from Subversion. The package “provides” the, apparently “old”, extension (I use it and know it works, and didn’t know of the “new” one, so…). bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705034: libsvn1: missing dependencies on KDE stuff
Package: libsvn1 Version: 1.7.9-1 Severity: important User: debian...@lists.debian.org Usertags: library-not-found undefined-symbol adequate libsvn1 contains the libsvn_auth_kwallet-1 library which uses KDE libraries, but libsvn1 does not depend on any KDE stuff. This and #634073 can probably be solved by splitting libsvn_auth_kwallet-1 into a separate package or something. This bug report brought to you by adequate: http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/ pabs@chianamo ~ $ adequate libsvn1 libsvn1:amd64: library-not-found /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1.0.0 = libkdecore.so.5 libsvn1:amd64: library-not-found /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1.0.0 = libkdeui.so.5 libsvn1:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1.0.0 = _ZN7KWallet6Wallet15keyDoesNotExistERK7QStringS3_S3_ libsvn1:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1.0.0 = _ZN7KWallet6Wallet10openWalletERK7QStringmNS0_8OpenTypeE libsvn1:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1.0.0 = _ZN14KComponentDataD1Ev libsvn1:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1.0.0 = _ZN7KWallet6Wallet13NetworkWalletEv libsvn1:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1.0.0 = _ZN7KWallet6Wallet6isOpenERK7QString libsvn1:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1.0.0 = _Z5ki18nPKc libsvn1:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1.0.0 = _ZN14KComponentDataC1EPK10KAboutDataNS_25MainComponentRegistrationE libsvn1:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1.0.0 = _ZN12KCmdLineArgs4initEiPPcRK10QByteArrayS4_RK16KLocalizedStringS4_S7_6QFlagsINS_13StdCmdLineArgEE libsvn1:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1.0.0 = _ZN12KCmdLineArgs9aboutDataEv libsvn1:amd64: undefined-symbol /usr/lib/x86_64-linux-gnu/libsvn_auth_kwallet-1.so.1.0.0 = _ZN16KLocalizedStringD1Ev -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-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 libsvn1 depends on: ii libapr11.4.6-3 ii libaprutil11.4.1-3 ii libc6 2.13-38 ii libdb5.1 5.1.29-5 ii libexpat1 2.1.0-1 ii libldap-2.4-2 2.4.31-1 ii libneon27-gnutls 0.29.6-3 ii libsasl2-2 2.1.25.dfsg1-6 ii libserf1 1.1.0-2 ii libsqlite3-0 3.7.13-1 ii multiarch-support 2.13-38 ii zlib1g 1:1.2.7.dfsg-13 -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#705035: r-base-dev: generated dependency in substvars should specify a maximum R version
Package: r-base-dev
Version: 3.0.0-2
Tags: patch
After the call for all the r-cran packages to be updated for R 3.0,
which is binary(?) incompatible with earlier versions, and the later
reference to ${R:Depends} in the ongoing discussion, I realised that
the ${R:Depends} is currently faulty: packages built under R 2.x have
a generated Depends line which reads: r-base-core (= 2.14.1-2) or
similar, but actually, this should be tighter, and also specify
r-base-core ( 3), as it appears that packages built under R 2.x will
not run under R 3.x. The attached patch modifies the r-cran.mk file
to specify that r-base-core has to be less than the next major
version, under the assumption that this is the only time that binary
incompatibilities are introduced for packages built with earlier
versions of R. This patch also assumes that there is no epoch,
otherwise the expr command will fail.
Julian
--- /tmp/r-cran.mk.orig 2013-04-03 16:29:47.0 +0100
+++ /tmp/r-cran.mk 2013-04-09 09:11:48.0 +0100
@@ -61,6 +61,8 @@
# dpkg-parsechangelog -l- --count 1 | \
# awk '/^Version/ {print $$2}')
rversion := $(shell dpkg-query -W -f='$${Version}' r-base-dev)
+rmajorversion := $(shell echo $(rversion) | cut -d. -f1)
+rnextmajorver := $(shell expr $(rmajorversion) + 1)
## we use these results for the to-be-installed-in directory
debRlib := $(CURDIR)/debian/$(package)/$(debRdir)
@@ -76,7 +78,7 @@
dh_installdirs $(debRdir)
##
## support ${R:Depends} via debian/${package}.substvars
- echo R:Depends=r-base-core (= ${rversion}) debian/$(package).substvars
+ echo R:Depends=r-base-core (= ${rversion}), r-base-core ( $(rnextmajorver)) debian/$(package).substvars
##
## call R to install the sources we're looking at
## use this inside xvfb-run if this wrapper is installed
Bug#705032: manpages-posix: typo in eval.1
On Tue, Apr 09, 2013 at 08:54:21AM +0100, Julian Gilbey wrote: Package: manpages-posix Version: 2.16-1 Severity: minor Tags: patch The EXAMPLES section reads: foo=10 x=foo y='$'$x echo $y $fooeval y='$'$x echo $y 10 There is clearly a missing newline between $foo and eval on the 4th line here. It's also all in bold, which is unnecessary and confusing. I think this format-only changes could be applied. Note that in general POSIX does not admit changes to the pages by license. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705032: manpages-posix: typo in eval.1
On Tue, Apr 09, 2013 at 10:20:50AM +0200, Francesco P. Lovergine wrote: On Tue, Apr 09, 2013 at 08:54:21AM +0100, Julian Gilbey wrote: Package: manpages-posix Version: 2.16-1 Severity: minor Tags: patch [...] I think this format-only changes could be applied. Note that in general POSIX does not admit changes to the pages by license. Perhaps this could then be forwarded upstream? Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696337: RFS: dualword/1.3.0-1 [ITP] [new package]
On Wed, Jan 23, 2013 at 10:39 AM, Paul Wise wrote: I am willing to sponsor it when it is ready. How is the update going Alexander? Do you have a new package ready? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617425: Working on this package
I've now finished the work mentioned above. Unfortunately I can't support the package in Debian at present but I believe the package is essentially ready for Debian use. Note it requires a patched JavaCC to compile properly: https://launchpad.net/~tbooth/+archive/ppa1/+files/javacc_5.0-5fix1ubuntu2.dsc TIM -- Tim Booth tbo...@ceh.ac.uk NERC Environmental Bioinformatics Centre Centre for Ecology and Hydrology Maclean Bldg, Benson Lane Crowmarsh Gifford Wallingford, England OX10 8BB http://nebc.nerc.ac.uk +44 1491 69 2705 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705036: logidee-tools: verif_dep.sh not shipped
Package: logidee-tools Version: 1.2.12 Severity: normal The Makefiles shipped by logidee-tools reference a verif_dep.sh script that is only part of the source package, which breaks some targets. The following patch adds the script to the binary package, and links it to the work directory as part of the setup. Index: bin/setup === --- bin/setup (révision 133) +++ bin/setup (copie de travail) @@ -54,6 +54,7 @@ test -d charte || mkdir charte ln -sf $root/charte/* charte/ +ln -sf $root/bin/verif_dep.sh . # Setup perl -pi -e s|^REP\s*=.*$|REP=$directories| Makefile Index: debian/logidee-tools.install === --- debian/logidee-tools.install(révision 133) +++ debian/logidee-tools.install(copie de travail) @@ -5,3 +5,4 @@ vim usr/share/logidee-tools/ xml usr/share/logidee-tools/ Makefile* usr/share/logidee-tools/ +verif_dep.sh usr/share/logidee-tools/bin/ -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages logidee-tools depends on: ii ghostscript9.05~dfsg-6.3 ii imagemagick8:6.7.7.10-5 ii libxml22.8.0+dfsg1-7+nmu1 ii perl 5.14.2-20 ii psutils1.17.dfsg-1 ii texlive-fonts-recommended 2012.20120611-5 ii texlive-latex-extra2012.20120611-2 ii texlive-latex-recommended 2012.20120611-5 ii texlive-pstricks 2012.20120611-2 ii xsltproc 1.1.26-14.1 logidee-tools recommends no packages. logidee-tools suggests no packages. -- no debconf information -- Roland Mas A man walks into a bar. Bang. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680065: ddclient fails also on dyndns.strato.com using ssl
I can confirm: ddclient works with ssl=no: ssl=no use=web, web=checkip.dyndns.com/, web-skip='IP Address' protocol=dyndns2 server=dyndns.strato.com login= password= but it does not works with ssl=yes: ssl=yes Log with ssl=yes: DEBUG:proxy = DEBUG:url= checkip.dyndns.com/ DEBUG:server = checkip.dyndns.com CONNECT: checkip.dyndns.com CONNECTED: using HTTP SENDING: GET / HTTP/1.0 SENDING: Host: checkip.dyndns.com SENDING: User-Agent: ddclient/3.8.0 SENDING: Connection: close SENDING: RECEIVE: HTTP/1.1 200 OK RECEIVE: Content-Type: text/html RECEIVE: Server: DynDNS-CheckIP/1.0 RECEIVE: Connection: close RECEIVE: Cache-Control: no-cache RECEIVE: Pragma: no-cache RECEIVE: Content-Length: 104 RECEIVE: RECEIVE: htmlheadtitleCurrent IP Check/title/headbodyCurrent IP Address: xxx/body/html DEBUG:get_ip: using web, checkip.dyndns.com/ reports xxx INFO: forcing updating xxx because no cached entry exists. DEBUG: DEBUG: nic_dyndns2_update --- INFO: setting IP address to xxx for xxx UPDATE: updating xxx DEBUG:proxy = DEBUG:url= http://dyndns.strato.com/nic/update?system=dyndnshostname=xxxmyip=xxx DEBUG:server = dyndns.strato.com CONNECT: dyndns.strato.com WARNING: cannot connect to dyndns.strato.com:443 socket: Die Verbindung wurde vom Kommunikationspartner zurückgesetzt IO::Socket::IP configuration failed error::lib(0):func(0):reason(0) FAILED: updating xxx: Could not connect to dyndns.strato.com. Log with ssl=no: DEBUG:proxy = DEBUG:url= checkip.dyndns.com/ DEBUG:server = checkip.dyndns.com CONNECT: checkip.dyndns.com CONNECTED: using HTTP SENDING: GET / HTTP/1.0 SENDING: Host: checkip.dyndns.com SENDING: User-Agent: ddclient/3.8.0 SENDING: Connection: close SENDING: RECEIVE: HTTP/1.1 200 OK RECEIVE: Content-Type: text/html RECEIVE: Server: DynDNS-CheckIP/1.0 RECEIVE: Connection: close RECEIVE: Cache-Control: no-cache RECEIVE: Pragma: no-cache RECEIVE: Content-Length: 105 RECEIVE: RECEIVE: htmlheadtitleCurrent IP Check/title/headbodyCurrent IP Address: xxx/body/html DEBUG:get_ip: using web, checkip.dyndns.com/ reports xxx DEBUG: DEBUG: nic_dyndns2_update --- INFO: setting IP address to xxx for xxx UPDATE: updating xxx DEBUG:proxy = DEBUG:url= http://dyndns.strato.com/nic/update?system=dyndnshostname=xxxmyip=xxx DEBUG:server = dyndns.strato.com CONNECT: dyndns.strato.com CONNECTED: using HTTP SENDING: GET /nic/update?system=dyndnshostname=xxxmyip=xxxHTTP/1.0 SENDING: Host: dyndns.strato.com SENDING: Authorization: Basic xxx SENDING: User-Agent: ddclient/3.8.0 SENDING: Connection: close SENDING: RECEIVE: HTTP/1.0 200 OK RECEIVE: Date: Tue, 09 Apr 2013 09:22:33 GMT RECEIVE: Server: Apache/1.3.41 (Unix) mod_deflate/1.0.21 mod_perl/1.31 mod_ssl/2.8.31 OpenSSL/0.9.8o RECEIVE: Connection: close RECEIVE: Content-Type: text/plain; charset=ISO-8859-1 RECEIVE: RECEIVE: good xxx SUCCESS: updating xxx: good: IP address set to xxx -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ddclient depends on: ii debconf [debconf-2.0] 1.5.49 ii initscripts2.88dsf-41 ii lsb-base 4.1+Debian8 ii perl [perl5] 5.14.2-20 Versions of packages ddclient recommends: ii libio-socket-ssl-perl 1.76-2 ddclient suggests no packages. -- debconf information: * ddclient/fetchhosts: From list * ddclient/blankhostslist: ddclient/run_daemon: true * ddclient/hostslist: ddclient/names: ddclient/interface: ddclient/modifiedconfig: * ddclient/checkip: true * ddclient/server: members.dyndns.org * ddclient/protocol: dyndns2 ddclient/run_ipup: false * ddclient/username: srv1.system-services-limbeck.de ddclient/daemon_interval: 300 * ddclient/service: www.dyndns.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704748: task-gnome-desktop: uninstallable on kfreebsd-*
Quoting Steven Chamberlain (ste...@pyro.eu.org):
Control: tags -1 = d-i patch
On 08/04/13 16:21, Julien Cristau wrote:
AFAIK that has been reverted.
Oh it has, thanks. The purpose of the branches makes sense now.
Attached is a patch for master, and with the right bug number this time.
After some resyncing in master (it still had the drop menu change),
I come up with the attached debdiff wrt 3.14+nmu1.
Basically:
[ Christian Perrier ]
* Add iw package to Recommends for the laptop and desktop tasks,
so that the 'iw' command is available to users.
Closes: #697890
[ Kenshi Muto ]
* Add mozc-utils-gui to japanese-desktop.
[ Steven Chamberlain ]
* Downgrade network-manager-gnome to Recommends, because a
Depends relation could only be satisfied on [linux-any]
(Closes: #704748)
[ Thijs Kinkhorst ]
* Language cleanups in Dutch translations.
kmuto change and l10n changes can of course be dropped if we very
strictly want to stick to the RC issue. I would prefer keeping them if
we can.
diff -Nru tasksel-3.14+nmu1/debian/changelog tasksel-3.15/debian/changelog
--- tasksel-3.14+nmu1/debian/changelog 2013-01-31 19:19:56.0 +0100
+++ tasksel-3.15/debian/changelog 2013-04-09 10:37:41.0 +0200
@@ -1,3 +1,23 @@
+tasksel (3.15) UNRELEASED; urgency=low
+
+ [ Christian Perrier ]
+ * Add iw package to Recommends for the laptop and desktop tasks,
+so that the 'iw' command is available to users.
+Closes: #697890
+
+ [ Kenshi Muto ]
+ * Add mozc-utils-gui to japanese-desktop.
+
+ [ Steven Chamberlain ]
+ * Downgrade network-manager-gnome to Recommends, because a
+Depends relation could only be satisfied on [linux-any]
+(Closes: #704748)
+
+ [ Thijs Kinkhorst ]
+ * Language cleanups in Dutch translations.
+
+ -- Christian Perrier bubu...@debian.org Mon, 25 Feb 2013 07:17:51 +0100
+
tasksel (3.14+nmu1) unstable; urgency=low
[ Julien Cristau ]
diff -Nru tasksel-3.14+nmu1/debian/control tasksel-3.15/debian/control
--- tasksel-3.14+nmu1/debian/control2013-01-31 19:17:35.0 +0100
+++ tasksel-3.15/debian/control 2013-04-09 10:39:06.0 +0200
@@ -57,6 +57,8 @@
libgl1-mesa-dri,
# Make sure that CDs etc can be ejected. May not be installed by d-i.
eject,
+# wireless networking tools (they're more and more used on desktops too)
+ iw,
# sound
alsa-utils,
alsa-base,
@@ -72,9 +74,7 @@
Depends: ${misc:Depends},
task-desktop,
# only depend on a very minimal gnome desktop, to ensure it fits on CD1
- gnome-core,
-# but we need a working network setup at least
- network-manager-gnome
+ gnome-core
Recommends:
# The full gnome desktop environment should be included if possible
# even if the larger gnome metapackage doesn't fit.
@@ -100,6 +100,8 @@
hunspell-en-us,
# make hyphenation work
hyphen-en-us,
+# we need a working network setup at least
+ network-manager-gnome
Package: task-kde-desktop
Architecture: all
@@ -256,8 +258,11 @@
acpi,
acpi-support,
pcmciautils,
+# wireless networking tools
+ iw,
wireless-tools,
wpasupplicant,
+#
avahi-autoipd,
bluetooth,
powertop,
@@ -1488,6 +1493,7 @@
uim,
uim-anthy,
uim-mozc,
+ mozc-utils-gui,
anthy,
libreoffice-l10n-ja,
libreoffice-help-ja,
diff -Nru tasksel-3.14+nmu1/.gitattributes tasksel-3.15/.gitattributes
--- tasksel-3.14+nmu1/.gitattributes1970-01-01 01:00:00.0 +0100
+++ tasksel-3.15/.gitattributes 2013-04-09 08:09:39.0 +0200
@@ -0,0 +1 @@
+debian/changelog merge=dpkg-mergechangelogs
diff -Nru tasksel-3.14+nmu1/po/nl.po tasksel-3.15/po/nl.po
--- tasksel-3.14+nmu1/po/nl.po 2013-01-31 19:17:35.0 +0100
+++ tasksel-3.15/po/nl.po 2013-04-09 08:07:58.0 +0200
@@ -1,14 +1,13 @@
-# SOME DESCRIPTIVE TITLE.
-# Copyright (C) YEAR Free Software Foundation, Inc.
-# FIRST AUTHOR EMAIL@ADDRESS, YEAR.
-#
+# Dutch
+# Translation file for tasksel to Dutch
+# Copyright (C) 2013 Free Software Foundation, Inc.
msgid
msgstr
Project-Id-Version: Taksel\n
Report-Msgid-Bugs-To: \n
POT-Creation-Date: 2012-06-21 11:36-0400\n
-PO-Revision-Date: 2006-01-07 00:44+0100\n
-Last-Translator: Bart Cornelis cob...@linux.be\n
+PO-Revision-Date: 2013-03-09 08:53+0100\n
+Last-Translator: Thijs Kinkhorst th...@debian.org\n
Language-Team: debian-l10n-dutch debian-l10n-du...@lists.debian.org\n
Language: \n
MIME-Version: 1.0\n
@@ -30,12 +29,12 @@
Gebruik:\n
tasksel install taak...\n
tasksel remove taak...\n
-tasksel [opties];\n
-\t-t, --test test-modus, enkel simuleren niet echt uitvoeren\n
-\t--new-install automatische installatie van een aantal taken\n
-\t--list-tasksgeef een lijst weer taken en sluit daarna af\n
-\t--task-packages geef de beschikbare pakketten van een taak weer\n
-\t--task-desc geef de
Bug#705037: FTBFS on sparc
Package: liburcu Version: 0.7.6-1 Severity: serious Hi, Your package seems to be marked Architecture: any but seems to FTBFS on multiple architectures, some of them even release architectures. mipsel has already been marked as Not-For-Us. One of them is sparc which built for 0.6.7-1 but has failed on 0.7.6-1 since Jan 20th with: In file included from urcu/static/wfqueue.h:33:0, from wfqueue.c:25: ./urcu/uatomic.h:23:2: error: #error Cannot build: unrecognized architecture detected. This would prevent your package from entering testing, should the release happen and testing unfroze. From what I see, fixing sparc shouldn't be a big deal. kfreebsd-* which also FTBFS could be a bit less trivial to fix but still doable as a maintainer's job. Additionally, since upstream is clearly supporting selected architectures and falling back to #error for unsupported ones, your package should properly mark those supported ones in the Architecture field instead of relying on porters noticing and marking as Not-For-Us. It would also help reverse deps (I maintain one of them) to actually know in which architectures they should limit the b-d on, since clearly an unrestricted one would just result into more build failures. Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688779: liburcu1: shlibs too weak
On Tue, Sep 25, 2012 at 12:04:59PM -0400, Aaron M. Ucko wrote: Package: liburcu1 Version: 0.7.4-1 Severity: serious Justification: Policy 8.6 This is a bug report against liburcu/0.7.4-1 but you seem to have closed it in an ltt-control upload. If it wasn't a liburcu bug in the first place, you should have reassigned the bug before closing it; if it is a liburcu bug OTOH, you shouldn't Close it from a different package. From what I can see, the bug is still considered by britney for migrations. You should either fix it, or mark notfound liburcu/0.7.4-1 found ltt-control/$brokenversion as to fix this inconsistency. Regards, Faidon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704748: task-gnome-desktop: uninstallable on kfreebsd-*
Christian PERRIER bubu...@debian.org (09/04/2013): After some resyncing in master (it still had the drop menu change), I come up with the attached debdiff wrt 3.14+nmu1. Couldn't we just pretend 3.14+nmu1 never happened? See below. Basically: [ Christian Perrier ] * Add iw package to Recommends for the laptop and desktop tasks, so that the 'iw' command is available to users. Closes: #697890 Did you see the netcfg upload? Having that in a task is slightly different (especially for already-installed systems), but I think the netcfg part is sufficient. [ Kenshi Muto ] * Add mozc-utils-gui to japanese-desktop. Not convinced it's still time to do such things. Not sure of the impact on installer images, either. [ Steven Chamberlain ] * Downgrade network-manager-gnome to Recommends, because a Depends relation could only be satisfied on [linux-any] (Closes: #704748) If we were to keep that change (still not sure, waiting for Steve to comment on whether we want tasksel or debian-cd patched at this point), it would be nice to mention a Recommends was added in that version, rather than changed from a previous version that didn't really exist. [ Thijs Kinkhorst ] * Language cleanups in Dutch translations. Why not. From tasksel (3.14+deb7u1), which you didn't mention: + [ Joey Hess ] + * Fix typo in changelog. Closes: #694894 Why not. + [ Christian Perrier ] + * Add Depends to network-manager-gnome on task-gnome-desktop +Closes: #697868 Not certain, and see above, keep that only in 3.15. + * Drop menu from the desktop task. Closes: #699390 6 months into the freeze? I'm not sure we want that at this point, but I won't stop release managers from asking for its being merged if they were so inclined. Mraw, KiBi. signature.asc Description: Digital signature
Bug#704748: task-gnome-desktop: uninstallable on kfreebsd-*
On Tue, Apr 9, 2013 at 12:11:06 +0200, Cyril Brulebois wrote: + * Drop menu from the desktop task. Closes: #699390 6 months into the freeze? I'm not sure we want that at this point, but I won't stop release managers from asking for its being merged if they were so inclined. Release managers have said they don't want non-RC changes anymore. Cheers, Julien signature.asc Description: Digital signature
Bug#705035: r-base-dev: generated dependency in substvars should specify a maximum R version
Julian,
Thanks for work on this.
The bug report is essentially a duplication of #704805.
On 9 April 2013 at 09:17, Julian Gilbey wrote:
| Package: r-base-dev
| Version: 3.0.0-2
| Tags: patch
|
| After the call for all the r-cran packages to be updated for R 3.0,
| which is binary(?) incompatible with earlier versions, and the later
Half-binary.
R sees the older version of its package and just does not use it. Not
binary in the classic sense.
edd@max:~$ R -q
R library(fasttime)## from rforge.net, have not yet rebuilt
Error: package ‘fasttime’ was built before R 3.0.0: please re-install it
| reference to ${R:Depends} in the ongoing discussion, I realised that
| the ${R:Depends} is currently faulty: packages built under R 2.x have
| a generated Depends line which reads: r-base-core (= 2.14.1-2) or
| similar, but actually, this should be tighter, and also specify
| r-base-core ( 3), as it appears that packages built under R 2.x will
| not run under R 3.x. The attached patch modifies the r-cran.mk file
| to specify that r-base-core has to be less than the next major
| version, under the assumption that this is the only time that binary
| incompatibilities are introduced for packages built with earlier
Wrong assumption, sadly.
We also needed a rebuild at 2.10 which was not a major. For this, the patch
simply does not help at all. As that is a major shortcoming I don't think I
can use it.
Dirk
| versions of R. This patch also assumes that there is no epoch,
| otherwise the expr command will fail.
|
|Julian
|
| --
| --- /tmp/r-cran.mk.orig 2013-04-03 16:29:47.0 +0100
| +++ /tmp/r-cran.mk2013-04-09 09:11:48.0 +0100
| @@ -61,6 +61,8 @@
| #dpkg-parsechangelog -l- --count 1 | \
| #awk '/^Version/ {print $$2}')
| rversion := $(shell dpkg-query -W -f='$${Version}' r-base-dev)
| +rmajorversion := $(shell echo $(rversion) | cut -d. -f1)
| +rnextmajorver := $(shell expr $(rmajorversion) + 1)
|
| ## we use these results for the to-be-installed-in directory
| debRlib := $(CURDIR)/debian/$(package)/$(debRdir)
| @@ -76,7 +78,7 @@
| dh_installdirs $(debRdir)
| ##
| ## support ${R:Depends} via debian/${package}.substvars
| - echo R:Depends=r-base-core (= ${rversion})
debian/$(package).substvars
| + echo R:Depends=r-base-core (= ${rversion}), r-base-core (
$(rnextmajorver)) debian/$(package).substvars
| ##
| ## call R to install the sources we're looking at
| ## use this inside xvfb-run if this wrapper is installed
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704748: task-gnome-desktop: uninstallable on kfreebsd-*
Quoting Cyril Brulebois (k...@debian.org): Christian PERRIER bubu...@debian.org (09/04/2013): After some resyncing in master (it still had the drop menu change), I come up with the attached debdiff wrt 3.14+nmu1. Couldn't we just pretend 3.14+nmu1 never happened? See below. I'm lost...:-) The one that really didn't happen is 3.14+deb7u1. 3.14+nmu1 happened. [ Christian Perrier ] * Add iw package to Recommends for the laptop and desktop tasks, so that the 'iw' command is available to users. Closes: #697890 Did you see the netcfg upload? Having that in a task is slightly different (especially for already-installed systems), but I think the netcfg part is sufficient. Strictly speaking, yes. [ Kenshi Muto ] * Add mozc-utils-gui to japanese-desktop. Not convinced it's still time to do such things. Not sure of the impact on installer images, either. Something I have no idea about, sure. Maybe safer to drop. [ Steven Chamberlain ] * Downgrade network-manager-gnome to Recommends, because a Depends relation could only be satisfied on [linux-any] (Closes: #704748) If we were to keep that change (still not sure, waiting for Steve to comment on whether we want tasksel or debian-cd patched at this point), it would be nice to mention a Recommends was added in that version, rather than changed from a previous version that didn't really exist. If we claim that 3.14+nmu never existed, yes. :-) [ Thijs Kinkhorst ] * Language cleanups in Dutch translations. Why not. These alone do not, of course, motivate an upload. From tasksel (3.14+deb7u1), which you didn't mention: Because it never existed..:-) + [ Joey Hess ] + * Fix typo in changelog. Closes: #694894 Why not. + [ Christian Perrier ] + * Add Depends to network-manager-gnome on task-gnome-desktop +Closes: #697868 Not certain, and see above, keep that only in 3.15. Well, it is in 3.14+nmu1, so it is already in wheezy, which explains why I didn't mention it. + * Drop menu from the desktop task. Closes: #699390 6 months into the freeze? I'm not sure we want that at this point, but I won't stop release managers from asking for its being merged if they were so inclined. Julien commented on IRC that it's not wished. I guess he was speaking with an RM hat, so I think we shouldn't include this. signature.asc Description: Digital signature
Bug#705038: evolution: dependencie on libgnome-desktop-3-7
Package: evolution Version: 3.8.0-1 Severity: normal Dear Maintainer, evolution should depend on libgnome-desktop-3-7 intead of libgnome-desktop-3-2 to allow installation of all gnome 3.8 components. Cheers Mike -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-trunk-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages evolution depends on: ii dbus1.6.8-1 ii debconf [debconf-2.0] 1.5.49 ii evolution-common3.8.0-1 ii evolution-data-server 3.8.0-2 ii gnome-icon-theme3.7.91-1 ii libatk1.0-0 2.8.0-1 ii libc6 2.17-0experimental2 ii libcairo-gobject2 1.12.2-3 ii libcairo2 1.12.2-3 ii libcamel-1.2-43 3.8.0-2 ii libebackend-1.2-6 3.7.92-1 ii libebook-1.2-14 3.7.92-1 ii libebook-contacts-1.2-0 3.8.0-2 ii libecal-1.2-15 3.7.92-1 ii libedata-book-1.2-173.7.92-1 ii libedataserver-1.2-17 3.8.0-2 ii libenchant1c2a 1.6.0-7 ii libevolution3.8.0-1 ii libgail-3-0 3.8.0-1 ii libgdk-pixbuf2.0-0 2.28.0-1 ii libglib2.0-02.36.0-2 pn libgnome-desktop-3-2none ii libgtk-3-0 3.8.0-1 ii libgtkhtml-4.0-04.6.0-1 ii libgtkhtml-editor-4.0-0 4.6.0-1 ii libical00.48-2 ii libjavascriptcoregtk-3.0-0 1.11.91-1 ii libnotify4 0.7.5-2 ii libnspr42:4.9.6-1 ii libnspr4-0d 2:4.9.6-1 ii libnss3 2:3.14.3-1 ii libnss3-1d 2:3.14.3-1 ii libpango1.0-0 1.32.5-3 ii libsecret-1-0 0.14-1 ii libsoup2.4-12.42.0-1 ii libsqlite3-03.7.16.1-1 ii libwebkitgtk-3.0-0 1.11.91-1 ii libxml2 2.8.0+dfsg1-7+nmu1 ii psmisc 22.20-1 Versions of packages evolution recommends: ii bogofilter 1.2.2+dfsg1-3 ii evolution-plugins 3.8.0-1 ii evolution-webcal 2.32.0-2+b1 ii yelp 3.6.1-1 Versions of packages evolution suggests: pn evolution-dbg none pn evolution-exchange none pn evolution-plugins-experimental none ii gnupg 1.4.12-7 ii network-manager 0.9.8.0-2 -- debconf information: evolution/kill_processes: evolution/needs_shutdown: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656586: fails to purge - rmdir: failed to remove '/var/lib/routino/data': No such file or directory
Followup-For: Bug #656586 Control: tag -1 patch Hi, I'm attaching a patch to fix the postrm. This is targeted at testing-proposed-updates, but the same can be applied to sid, too. Unfortunately the git repository is not up-to-date, otherwise I would have sent some git commits :-) I'll ask for a t-p-u approval and intend to NMU routino to t-p-u to get this fixed for wheezy. Andreas diffstat for routino-2.2 routino-2.2 changelog |9 + routino-www.postrm | 27 --- 2 files changed, 13 insertions(+), 23 deletions(-) diff -Nru routino-2.2/debian/changelog routino-2.2/debian/changelog --- routino-2.2/debian/changelog 2012-05-09 08:28:30.0 +0200 +++ routino-2.2/debian/changelog 2013-04-09 12:24:54.0 +0200 @@ -1,3 +1,12 @@ +routino (2.2-4+deb7u1) testing; urgency=low + + * Non-maintainer upload. + * routino-www.postrm: Don't fail on removal of a non-existing directory. +Don't repeat the same actions on remove and purge - only remove the +results directory during purge. (Closes: #656586) + + -- Andreas Beckmann a...@debian.org Tue, 09 Apr 2013 12:09:30 +0200 + routino (2.2-4) unstable; urgency=low * routino-www: added OSM CycleMap to list of layers diff -Nru routino-2.2/debian/routino-www.postrm routino-2.2/debian/routino-www.postrm --- routino-2.2/debian/routino-www.postrm 2012-03-07 11:07:10.0 +0100 +++ routino-2.2/debian/routino-www.postrm 2013-04-09 12:15:25.0 +0200 @@ -7,29 +7,10 @@ set -x fi -case $1 in - purge) - rm -rf /var/lib/routino/results - rmdir --ignore-fail-on-non-empty /var/lib/routino/data - - ;; - remove) - rm -rf /var/lib/routino/results - rmdir --ignore-fail-on-non-empty /var/lib/routino/data - - ;; - - upgrade) - - ;; - - failed-upgrade|abort-install|abort-upgrade|disappear) - ;; -*) -echo postrm called with unknown argument \`$1' 2 -exit 1 - -esac +if [ $1 = purge ]; then + rm -rf /var/lib/routino/results + rmdir --ignore-fail-on-non-empty /var/lib/routino/data || true +fi #DEBHELPER#
Bug#705035: r-base-dev: generated dependency in substvars should specify a maximum R version
On Tue, Apr 09, 2013 at 05:21:37AM -0500, Dirk Eddelbuettel wrote:
| reference to ${R:Depends} in the ongoing discussion, I realised that
| the ${R:Depends} is currently faulty: packages built under R 2.x have
| a generated Depends line which reads: r-base-core (= 2.14.1-2) or
| similar, but actually, this should be tighter, and also specify
| r-base-core ( 3), as it appears that packages built under R 2.x will
| not run under R 3.x. The attached patch modifies the r-cran.mk file
| to specify that r-base-core has to be less than the next major
| version, under the assumption that this is the only time that binary
| incompatibilities are introduced for packages built with earlier
Wrong assumption, sadly.
We also needed a rebuild at 2.10 which was not a major. For this, the patch
simply does not help at all. As that is a major shortcoming I don't think I
can use it.
In which case, a simple modification of the patch would be to require
the same major and minor version, so r-base-core (= 3.0.0-2),
r-base-core ( 3.1) should do it. But that would require rebuilds
every time the minor version changes. A better long-term solution
would probably be to ask the upstream R developers to make
half-binary incompatible changes when and only when changing the
major version number. Because as it is, our package management system
isn't handling the unpredictable nature of this package with the
present system. One possible way round this is by having something
like an r-base-binary-version dummy package which bumps its version
number every time there is a half-binary change. So you'd have:
Package: r-base-core
Version: 3.0.0-2
Depends: r-base-binary-version (= 3.0)
Package: r-cran-foo
Depends: r-base-core, r-base-binary-version (= 3.0)
and an empty package r-base-binary-version which is updated as and
when there's a half-binary change.
Julian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705039: tpu: routino/2.2-4+deb7u1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package routino Hi, I'd like to NMU routino to t-p-u to get this postrm bug fixed for wheezy (#656586): * purge fails on removal of a no longer existing directory * remove and purge repeat the same action - only do it during purge sid already has a new upstream version. Andreas unblock routino/2.2-4+deb7u1 diffstat for routino-2.2 routino-2.2 changelog |9 + routino-www.postrm | 27 --- 2 files changed, 13 insertions(+), 23 deletions(-) diff -Nru routino-2.2/debian/changelog routino-2.2/debian/changelog --- routino-2.2/debian/changelog 2012-05-09 08:28:30.0 +0200 +++ routino-2.2/debian/changelog 2013-04-09 12:24:54.0 +0200 @@ -1,3 +1,12 @@ +routino (2.2-4+deb7u1) testing; urgency=low + + * Non-maintainer upload. + * routino-www.postrm: Don't fail on removal of a non-existing directory. +Don't repeat the same actions on remove and purge - only remove the +results directory during purge. (Closes: #656586) + + -- Andreas Beckmann a...@debian.org Tue, 09 Apr 2013 12:09:30 +0200 + routino (2.2-4) unstable; urgency=low * routino-www: added OSM CycleMap to list of layers diff -Nru routino-2.2/debian/routino-www.postrm routino-2.2/debian/routino-www.postrm --- routino-2.2/debian/routino-www.postrm 2012-03-07 11:07:10.0 +0100 +++ routino-2.2/debian/routino-www.postrm 2013-04-09 12:15:25.0 +0200 @@ -7,29 +7,10 @@ set -x fi -case $1 in - purge) - rm -rf /var/lib/routino/results - rmdir --ignore-fail-on-non-empty /var/lib/routino/data - - ;; - remove) - rm -rf /var/lib/routino/results - rmdir --ignore-fail-on-non-empty /var/lib/routino/data - - ;; - - upgrade) - - ;; - - failed-upgrade|abort-install|abort-upgrade|disappear) - ;; -*) -echo postrm called with unknown argument \`$1' 2 -exit 1 - -esac +if [ $1 = purge ]; then + rm -rf /var/lib/routino/results + rmdir --ignore-fail-on-non-empty /var/lib/routino/data || true +fi #DEBHELPER#
Bug#704741: waagent: fails to remove: postrm called with unknown argument `remove'
Andreas Beckmann a...@debian.org writes: Hi, Package: waagent Version: 1.2-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to remove. From the attached log (scroll to the bottom...): Removing waagent ... postrm called with unknown argument `remove' dpkg: error processing waagent (--purge): subprocess installed post-removal script returned error exit status 1 Errors were encountered while processing: waagent looks like the bug I already noticed while updating to 1.3.2 some weeks ago. Will confirm this by running piuparts on my side. The prerm script is entirely useless, there is no prerm purge. ok. Will fix. For the postrm use if [ $1 = purge ] ; then ... fi and avoid all the remaining boilerplate code and comments. ok The postinst I don't really get - why are there that many rm's on configuration files? The files (for now) are created by waagent. This means: - if the package is removed (but not purged), we won't be able to purge it by using waagent -uninstall (since waagent will be gone) - iirc, if the package is removed purged, the purge step will be called after the removal of waagent so, again, using waagent -uninstall won't work. So, the postrm script has to remove them by hand. The configuration step via waagent --setup --force is not suitable for Debian systems, as it does not preserve user modifications to the configuration files it creates, which is a policy violation. Try e.g. dpkg-reconfigure waagent after editing all the configuration files. The main problem is that I've seen any guaranty that the files created by the agent won't change. I can try to be clever and check if there's a waagent.conf file or the init script and in this case not run waagent --setup --force but I fear of the breakages it may creates. We have to be careful as the system running it is a Azure VM so if we break stuff, it may be hard to recover. Arnaud -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704830: [Pkg-ltsp-devel] Bug#704830: ltsp-client-core: the init script should provide a hook for code snippets
On Mon, Apr 08, 2013 at 02:44:07PM -0700, Vagrant Cascadian wrote:
On Sat, Apr 06, 2013 at 03:58:09PM +0200, Wolfgang Schweer wrote:
to fetch config values out of LDAP and to add them to those provided on
the kernel command line or in lts.conf, code has to be executed inside
of the init script. While it is possible to modify the init script in
such a way using a script in init-ltsp.d [1], it would be better to have a
hook inside of the initscript serching for code in some directory, say
ltsp-client-core.d
Or you could also use /usr/share/ltsp/ltsp_config.d...
First location I tried, but it didn't work out for me.
Why is this better to do it from ltsp-client-core?
Cause then a network connection to the LDAP server is possible.
# Save as /usr/share/ltsp/init-ltsp.d/70-edu-client-core
# This snippet modifies /etc/init.d/ltsp-client-core on-the-fly.
#
# Get config stored in LDAP for Debian Edu ltsp clients (thin and fat).
#
sed -i '/Starting\ LTSP\ client.../ a\
/usr/share/ltsp/get-ldap-ltsp-config\
cat /var/cache/ltsp/ltsp_config_edu
/var/cache/ltsp/ltsp_config_env\
' /etc/init.d/ltsp-client-core
Why don't you call get-ldap-ltsp-config from ltsp_config.d or init-ltsp.d
instead?
Tried both locations; init-ltsp.d is far to early. As far as
ltsp_config.d is concerned, it seems to be the same (no connection to
ldap server). So this weird workaround. The script get-ldap-ltsp-config
is attached, maybe you're able to figure our some other way.
Wolfgang
#!/bin/sh
# Store as /opt/ltsp/$arch/usr/share/ltsp/get-ldap-ltsp-config
#
# Fetch LTSP client settings from LDAP based on MAC address
#
# Uses ethernet address as stored in the dhcpHost objectclass using
# the dhcpHWAddress attribute or as stored in the ieee802Device
# objectclass with the macAddress attribute.
#
# This module is written to be schema agnostic, and only depend on the
# existence of attribute names.
#
# The LTSP configuration variables are saved directly using a
# ltspConfig attribute. To set the SERVER variable, set a ltspConfig
# attribute to 'SERVER=value'.
#
# Some LDAP schema should be created with all the relevant
# configuration settings. Something like this should work:
#
# attributetype ( some-OID NAME 'ltspConfig'
#DESC 'LTSP config setting'
#SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
#
# objectclass ( some-OID NAME 'ltspClientConfigAux'
#DESC 'LTSP client configuration attributes'
#SUP top
#AUXILIARY
#MAY ( ltspConfig ))
#
# objectclass ( some-OID NAME 'ltspClientConfig'
#DESC 'LTSP client configuration attributes'
#SUP top
#STRUCTURAL
#MUST ( cn )
#MAY ( ltspConfig ))
#
# Example LDAP object:
#
# dn: cn=ltspConfigDefault,ou=somewhere
# objectclass: device
# objectclass: ltspClientConfigAux
# cn=ltspConfigDefault
# ltspConfig: SERVER=ltspserver.somewhere
# ltspConfig: SOUND=N
#
# dn: cn=hostname,ou=somewhere
# objectclass: ieee802Device
# objectclass: domainRelatedObject
# objectclass: ltspClientConfigAux
# cn=hostname
# macAddress: 00:01:02:03:04:05
# associatedDomain: hostname.somewhere
# ltspConfig: SOUND=N
#
# GOSA also have a LDAP approach for the tftp content (PXE arguments),
# searching for
#
# filter = ((macAddress=$mac)(objectClass=gotoTerminal)),
# attrs = [ 'gotoTerminalPath', 'gotoBootKernel',
#'gotoKernelParameters', 'gotoLdapServer', 'cn' ] );
#
# See the fts-ltsp-ldap package for this. The gotoTerminal object
# class is auxiliary, allowing it to be combined with other
# objectclasses.
echo Fetching ltsp config from ldap
#LDAP_HOST=tjener.intern
#BASE_DN=dc=skole,dc=skolelinux,dc=no
cachefile=/var/cache/ltsp/ltsp_config_edu
envfile=/var/cache/ltsp/ltsp_config_env
PATH=/bin:/usr/bin:/usr/sbin
setup_from_ldap() {
filter=((ltspConfig=*)$1)
config=$(ldapsearch -h $LDAP_HOST -b $BASE_DN -x $filter ltspConfig
| \
awk '/^ltspConfig: [^=]*=[^;]*$/ { print $2 }')
if [ $config ] ; then
if eval $config ; then
echo $config $cachefile
else
logger -t ltsp-ldap got invalid LTSP config from LDAP: '$config'
fi
foundinldap=true
fi
}
lookup_mac_addrs() {
PATH=/sbin:$PATH LANG=C ifconfig 2/dev/null | grep -i hwaddr | awk '{print
$5}' | sort -u
}
# Only check LDAP when the result can be cached
if touch $cachefile touch $envfile; then
if [ -z $LDAP_HOST ] ; then
LDAP_HOST=$(debian-edu-ldapserver || :)
fi
if [ $LDAP_HOST ] ping -W2 -c2 $LDAP_HOST /dev/null 21 ; then
if [ -z $BASE_DN ] ; then
BASE_DN=$(debian-edu-ldapserver -s $LDAP_HOST -b || :)
fi
if [ $BASE_DN ] ; then
# First set default values if found
setup_from_ldap '(cn=ltspConfigDefault)'
# Next, look up the host MAC address(es).
foundinldap=false
if [ -e /proc/net/dev ] ; then
for MAC in $(lookup_mac_addrs) ; do
Bug#704741: waagent: fails to remove: postrm called with unknown argument `remove'
On 2013-04-09 12:29, Arnaud Patard wrote: The postinst I don't really get - why are there that many rm's on configuration files? The files (for now) are created by waagent. This means: - if the package is removed (but not purged), we won't be able to purge it by using waagent -uninstall (since waagent will be gone) - iirc, if the package is removed purged, the purge step will be called after the removal of waagent so, again, using waagent -uninstall won't work. So, the postrm script has to remove them by hand. Yes. The post*rm*. But not the post*inst* script. The configuration step via waagent --setup --force is not suitable for Debian systems, as it does not preserve user modifications to the configuration files it creates, which is a policy violation. Try e.g. dpkg-reconfigure waagent after editing all the configuration files. The main problem is that I've seen any guaranty that the files created by the agent won't change. I can try to be clever and check if there's a waagent.conf file or the init script and in this case not run waagent --setup --force but I fear of the breakages it may creates. We have to be careful as the system running it is a Azure VM so if we break stuff, it may be hard to recover. Can't you use waagent --setup to generate the configuration files at build time in some other PREFIX than /? And ship them instead of doing any maintainer script magic? Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697868: tasksel arch any vs. keeping track of n-m in debian-cd?
On Fri, Apr 05, 2013 at 10:47:33PM +0200, Cyril Brulebois wrote:
Joey Hess jo...@debian.org (07/03/2013):
Re #697868, I would much rather leave it to the maintainers of
desktop environments (and/or Tech Ctte :P) to ensure that they have
eg, necessary network-manager dependencies on appropriate
architectures, rather than making tasksel need to track
that. Reading that bug, the only reason task-gnome is depending on
network-manager is to ensure it gets on CD#1. There are other ways
to do that, particularly debian-cd's generate_di+k_list is
appropriate since netcfg arranges for network-manager to be
installed.
I know you're joking but that maintainers vs. tech-ctte was insane
already, so I'd rather adjust d-i (through tasksel) to make sure we
have decent networking support in the installed system.
Delegating such things to debian-cd seems like the wrong way to fix
it, but let's see what Steve thinks of it (personally, I'd hate to
have to keep track of such things in debian-cd).
What I did for RC1 in debian-cd was to add network-manager and
network-manager-gnome to tasks/wheezy/Debian-{gnome,generic} *before*
task-essential-gnome. That made sure that those two packages made it
onto CD#1 regardless of other dependencies.
I'm OK with doing that kind of thing in future (or for other people to
do it too - just ask for commit access to the debian-cd repo), *but*
only (a) where it's strictly necessary and (b) in limited
circumstances for corner-cases like this. It's very much overkill
territory to do this often, and will be prone to breakage.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Armed with Valor: Centurion represents quality of Discipline,
Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
concord the digital world while feeling safe and proud.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705040: virtaal: Can not open any file
Package: virtaal Version: 0.7.1-1 Severity: grave Justification: renders package unusable Dear Maintainer, When opening any po file, including the tutorial one, the program refuse to open it and states: DatabaseError: database disk image is malformed The last time I used the software, in 2012 november I think, I didn’t had problems. I tried purging/installing the package again, and also tried removing the .virtaal in my home, neither solved the problem. It looks like it is a python error, but I am not competent to have more than a feeling. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages virtaal depends on: ii python 2.7.3-4 ii python-glade2 2.24.0-3+b1 ii python-gobject 3.2.2-2 ii python-gtk22.24.0-3+b1 ii python-lxml2.3.2-1 ii python-pycurl 7.19.0-5 ii python2.7 2.7.3-6 ii translate-toolkit 1.9.0-3 Versions of packages virtaal recommends: ii libreoffice-common 1:3.5.4+dfsg-4 ii python-gtkspell 2.25.3-12 ii python-levenshtein 0.10.1-2 ii python-psycopg2 2.4.5-1 virtaal suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704829: unblock: asterisk/1:1.8.13.1~dfsg-2
On 09.04.2013 11:34, Tzafrir Cohen wrote: On Tue, Apr 09, 2013 at 01:30:01AM +0200, Tzafrir Cohen wrote: Done. It turned out to be much smaller than the original one. At first glance there isn't any other code path. http://anonscm.debian.org/viewvc/pkg-voip/asterisk/trunk/debian/patches/AST-2012-014?revision=10137view=markup All other requested changed are commited to SVN. I'll rebuild -3 morning. Debdiff attached. Upload? Please go ahead; thanks. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667904: RFS: mitlm/0.4-1 [ITP] -- MIT Language Modeling
Lintian emits: X: libmitlm0: shlib-calls-exit usr/lib/libmitlm.so.0.0.0 I believe this is true-positive. exit() is indeed called in some methods that are part of public API: NgramLM::Initialize NgramModel::LoadComputedFeatures They should probably throw an exception instead. Also, printing errors/warnings to stderr (here via the Logger class) is not something you normally do in a shared library. At the very least there should be a way to turn these messages off, or redirect them somehwere else. But anyway, if you want me to upload the package as-is, I can do it. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697868: tasksel arch any vs. keeping track of n-m in debian-cd?
Thanks Steve.
Steve McIntyre st...@einval.com (09/04/2013):
What I did for RC1 in debian-cd was to add network-manager and
network-manager-gnome to tasks/wheezy/Debian-{gnome,generic} *before*
task-essential-gnome. That made sure that those two packages made it
onto CD#1 regardless of other dependencies.
I'm OK with doing that kind of thing in future (or for other people to
do it too - just ask for commit access to the debian-cd repo), *but*
only (a) where it's strictly necessary and (b) in limited
circumstances for corner-cases like this. It's very much overkill
territory to do this often, and will be prone to breakage.
Then I think I'd rather ask you to keep doing so for wheezy's
lifetime, than trying to fiddle with tasksel at this very late point
of the freeze.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Bug#705015: ITP: ie7-js -- help Internet Explorer behave like a standards-compliant browser
Quoting David Prévot (2013-04-09 00:13:02) [ moving the discussion to a better place ] Good idea :-) Le 08/04/2013 16:41, Jonas Smedegaard a écrit : For general use I believe, however, that html5shiv has proven a better shim. It is part of Modernizr already packaged for Debian. It might make sense to mention that in long description of this package. Thanks for pointing it, do you have a proposal for that? As you may have noticed, I don’t know anything about html5shiv. I suggest adding the following paragraph to long description: NB! This package is mainly provided for use by existing projects already using IE7.js. For other uses, the separately packaged Modernizr (with its embedded html5shim/html5shiv) may be a better choice. Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704950: logrotate: Errors last rotated in the future -- rotation forced
severity 704950 minor retitle 704950 logrotate: Error and forced rotation if timezone change moves localtime date backwards a day thanks On Mon, Apr 08, 2013 at 08:20:49PM +0200, Vincent Lefevre wrote: severity 704950 grave done because obvious critical data loss (though the case is not common). One part of the bug is that logrotate rotates the log files instead of not changing anything if it incorrectly guesses that a file has been written in the future. So, if the timezone changes several times (e.g. during a travel), some logs may be lost, even recent ones, while they would normally be kept e.g. for several weeks! Logs are important data. Losing logs is not acceptable. It's not the intention to protect system administrators against the consequences of their own policies. Severity minor because it only affects a minority of users. This is not a grave bug as it is the system administrator's choice to change local timezone, and they should be aware of the consequences of how that affects cron jobs. It's also telling you that it's doing what it's doing, rather than silently losing data. The time in future warning is there to advise of a broken system clock, not against a system administrator intentionally breaking that clock. The alternative is a system that potentially never rotates its log files. cron runs in the system's local timezone, hence logrotate follows what cron does. I've given you a workaround that will help you. I will not be closing this bug as it provides a helpful reference for others in your situation. Alternatively, if you find yourself changing timezones regularly, run the system in UTC (or your home timezone) and have your own login set an appropriate timezone as part of its ~/.profile -- Paul Martin p...@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#705041: chromium: Fails to attach files of low size in gmail.
Package: chromium Version: 25.0.1364.160-1 Severity: normal 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: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages chromium depends on: ii chromium-inspector 25.0.1364.160-1 ii gconf-service 3.2.5-1+build1 ii libasound2 1.0.25-4 ii libatk1.0-0 2.4.0-2 ii libbz2-1.0 1.0.6-4 ii libc6 2.13-38 ii libcairo2 1.12.2-3 ii libcups21.5.3-5 ii libdbus-1-3 1.6.8-1 ii libevent-2.0-5 2.0.19-stable-3 ii libexpat1 2.1.0-1 ii libflac81.2.1-6 ii libfontconfig1 2.9.0-7.1 ii libfreetype62.4.9-1.1 ii libgcc1 1:4.7.2-5 ii libgconf-2-43.2.5-1+build1 ii libgcrypt11 1.5.0-5 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.33.12+really2.32.4-5 ii libgnome-keyring0 3.4.1-1 ii libgtk2.0-0 2.24.10-2 ii libjpeg88d-1 ii libnspr42:4.9.2-1 ii libnss3 2:3.14.3-1 ii libnss3-1d 2:3.14.3-1 ii libpango1.0-0 1.30.0-1 ii libpulse0 2.0-6 ii libspeex1 1.2~rc1-7 ii libstdc++6 4.7.2-5 ii libudev0175-7.1 ii libvpx1 1.1.0-1 ii libx11-62:1.5.0-1 ii libxcomposite1 1:0.4.3-2 ii libxext62:1.3.1-2 ii libxfixes3 1:5.0-4 ii libxml2 2.8.0+dfsg1-7+nmu1 ii libxrandr2 2:1.3.2-2 ii libxrender1 1:0.9.7-1 ii libxslt1.1 1.1.26-14.1 ii libxss1 1:1.2.2-1 ii xdg-utils 1.1.0~rc1+git20111210-6 chromium recommends no packages. Versions of packages chromium suggests: pn chromium-l10n 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#640873: Licensing issue solved
I just stumbled across this bug and saw that the licensing issue was solved earlier this year in upstream version 3.3.0, see the link above or http://issues.igniterealtime.org/browse/SMACK-352 for details. Erik
Bug#705020: gvfs automaticly close cd tray
Am 09.04.2013 00:36, schrieb Klaus Ethgen: Package: gvfs Severity: critical Sorry for the high severity but it breaks the system in a very hard way, breaking the hardware cdrom tray and harming humans. The problem is that when I open the cd tray to insert a cd, gvfs has installed triggers to automatically close it. Unfortunately, it do ignore if the cd is fully mounted or if there is a finger in the way that is just insterting the cd. Unfortunately there is also other software like for example virt-manager, that depends indirectly on gvfs, even if gvfs is not needed or even wanted. As I have to uninstall the gvfs to not harm myself or other, such software as virt-manager is not installable too so it is broken. My guess is, that this is due to broken firmware, where polling the state of the CD drive (media inserted) causes it to close. The component responsible for that is udisks. Does it help when you disable polling via udisks --inhibit-all-polling. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#704741: waagent: fails to remove: postrm called with unknown argument `remove'
Andreas Beckmann a...@debian.org writes: On 2013-04-09 12:29, Arnaud Patard wrote: The postinst I don't really get - why are there that many rm's on configuration files? The files (for now) are created by waagent. This means: - if the package is removed (but not purged), we won't be able to purge it by using waagent -uninstall (since waagent will be gone) - iirc, if the package is removed purged, the purge step will be called after the removal of waagent so, again, using waagent -uninstall won't work. So, the postrm script has to remove them by hand. Yes. The post*rm*. But not the post*inst* script. oh. postinst. Sorry, misread. postinst rm stuff was to put system back to a clean state in case of failures during installation. The configuration step via waagent --setup --force is not suitable for Debian systems, as it does not preserve user modifications to the configuration files it creates, which is a policy violation. Try e.g. dpkg-reconfigure waagent after editing all the configuration files. The main problem is that I've seen any guaranty that the files created by the agent won't change. I can try to be clever and check if there's a waagent.conf file or the init script and in this case not run waagent --setup --force but I fear of the breakages it may creates. We have to be careful as the system running it is a Azure VM so if we break stuff, it may be hard to recover. Can't you use waagent --setup to generate the configuration files at build time in some other PREFIX than /? And ship them instead of doing any maintainer script magic? Not without patching unfortunately. Arnaud -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705035: r-base-dev: generated dependency in substvars should specify a maximum R version
On 9 April 2013 at 11:33, Julian Gilbey wrote:
| On Tue, Apr 09, 2013 at 05:21:37AM -0500, Dirk Eddelbuettel wrote:
| | reference to ${R:Depends} in the ongoing discussion, I realised that
| | the ${R:Depends} is currently faulty: packages built under R 2.x have
| | a generated Depends line which reads: r-base-core (= 2.14.1-2) or
| | similar, but actually, this should be tighter, and also specify
| | r-base-core ( 3), as it appears that packages built under R 2.x will
| | not run under R 3.x. The attached patch modifies the r-cran.mk file
| | to specify that r-base-core has to be less than the next major
| | version, under the assumption that this is the only time that binary
| | incompatibilities are introduced for packages built with earlier
|
| Wrong assumption, sadly.
|
| We also needed a rebuild at 2.10 which was not a major. For this, the patch
| simply does not help at all. As that is a major shortcoming I don't think I
| can use it.
|
| In which case, a simple modification of the patch would be to require
| the same major and minor version, so r-base-core (= 3.0.0-2),
| r-base-core ( 3.1) should do it. But that would require rebuilds
| every time the minor version changes. A better long-term solution
We most definitely do *not* want that. R 2.* went from 2.0.0 to 2.15.0, and I
think 2.10 and maybe 2.14 were the only ones requiring a rebuilt.
This patch would do real damage in that case.
| would probably be to ask the upstream R developers to make
| half-binary incompatible changes when and only when changing the
| major version number. Because as it is, our package management system
| isn't handling the unpredictable nature of this package with the
They have to care about Windows and OS X and all of Linux. Our particular
concerns are with a single-digit percentage of their users (yet a larger
percentage of the devs). Still: not a chance.
| present system. One possible way round this is by having something
| like an r-base-binary-version dummy package which bumps its version
| number every time there is a half-binary change. So you'd have:
|
| Package: r-base-core
| Version: 3.0.0-2
| Depends: r-base-binary-version (= 3.0)
|
| Package: r-cran-foo
| Depends: r-base-core, r-base-binary-version (= 3.0)
|
| and an empty package r-base-binary-version which is updated as and
| when there's a half-binary change.
Which is essentially the proposal to have a virtual package r-core-api
whatever we call it -- and why I told you in my first email that your bug
report was the same as #704805.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705042: gwibber-service-facebook: clicking authorize brings up blank page instead of authorization page
Package: gwibber-service-facebook Version: 3.0.0.1-2.2 Severity: normal While facebook authorization has already been broken for months (see bug #636702), it is even more broken now and fails at a yet earlier state: Choosing Add a new account for Facebook and then clicking authorize brings up a blank page. I suppose that the URL in /usr/share/gwibber/plugins/facebook/gtk/facebook/__init__.py no longer works, due to some change by facebook. Gwibber-service-facebook 3.5 from experimental is also affected. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable'), (450, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gwibber-service-facebook depends on: ii gwibber-service 3.0.0.1-2.2 gwibber-service-facebook recommends no packages. gwibber-service-facebook suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705031: Processed: Re: Processed (with 2 errors): Re: Bug#705031: base: netdev boot sequence problem and possible fix
Your original comment = When using iSCSI devices with multipathd, the open-iscsi boot script is started before multipathd, hence the system tries to mount _netdev devices before multipath is up-and-running. Thus my iSCSI devices are not mounted at boot time and need thus be mounted manualy, which is not a handy thing to do for /home open-iscsi is supposed to start before multipathd. It is because you many have a root on multipathd (underneath having an iscsi) setup. You could still mark the multipath device as _netdev. Does that not work? On Tuesday 09 April 2013 02:42 PM, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: reassign 705031 open-iscsi Bug #705031 [base] base: netdev boot sequence problem and possible fix Bug reassigned from package 'base' to 'open-iscsi'. Ignoring request to alter found versions of bug #705031 to the same values previously set Ignoring request to alter fixed versions of bug #705031 to the same values previously set thanks Stopping processing here. Please contact me if you need assistance. -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Bug#705043: ITP: libmodule-install-contributors-perl -- add an x_contributors section to your META.yml
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard d...@jones.dk * Package name: libmodule-install-contributors-perl Version : 0.001 Upstream Author : Toby Inkster toby...@cpan.org * URL : https://metacpan.org/release/Module-Install-Contributors * License : Artistic or GPL-1+ Programming Lang: Perl Description : add an x_contributors section to your META.yml Module::Install::Contributors is a plugin for Module::Install. It adds a x_contributors section to your META.yml file. This is an array of strings, which should normally be in Name email format. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705040: virtaal: Can not open any file
severity 705040 important tags 705040 unreproducible thanks Quoting Vincent Lhote (deb...@vincent.lhote.name): Package: virtaal Version: 0.7.1-1 Severity: grave Justification: renders package unusable Dear Maintainer, When opening any po file, including the tutorial one, the program refuse to open it and states: DatabaseError: database disk image is malformed The last time I used the software, in 2012 november I think, I didn’t had problems. I tried purging/installing the package again, and also tried removing the .virtaal in my home, neither solved the problem. It looks like it is a python error, but I am not competent to have more than a feeling. I can't reproduce that issue on my system signature.asc Description: Digital signature
Bug#704870: opus: cve-2013-0899
Hi, On Sat, Apr 06, 2013 at 08:00:56PM -0400, Michael Gilbert wrote: Package: opus Severity: serious Version: 0.9.14+20120615-1 Tags: security Hi, the following vulnerability was published for opus. So ... I'm not particularly convinced that this issue is actually 'serious' in the RC sense of that severity, and I did mention as much to #-security when I indicated that the tracker was only following this for chrome. It requires an application to willingly pass a packet 16MB to the decoder (after unpacking that from its transport container itself), when the maximum size of a single frame according to the Opus standard is capped at 1275 bytes. And the maximum packet duration is capped at 120ms, which even in the most pathological case (which no current encoder gets anywhere near) means valid packets (with multiple frames) will still always be 64kB. So any application which might do this, is probably at fair risk of exploding in its own right due to some bug in its own code before the packet ever got to the decoder ... and there is so far no actual indication that any of the apps currently in Wheezy are vulnerable to this at all. Which isn't to say we shouldn't fix this, but a quick look over the commits between the version we currently have and the one that fixes this issue shows a number of other issues that would be far more likely to ruin a user's day in some way, some of which also require a badly written app to trigger, yet none of which I'd really consider major release-blockers in their own right (at this stage of the release), but many of which I'd consider more serious and real 'threats' to users than this issue. The idea of blindly applying a cherry-picked patch with some fuzz, without properly analysing its interaction with the patches that wouldn't be applied or assessing its severity against those does sound a lot like security theater to me. It would be pasting over bugs in other applications, without actually guaranteeing they are no longer vulnerable to problems with accepting insane packets, while ignoring real problems where the codec itself may do something 'harmful' to users, and other problems where application developers could similarly hurt themselves through lack of care. All on the basis of someone (not upstream) deciding to file a CVE for this one without knowing about any of the others ... I'm not going to play severity ping-pong here, but if someone from -release or -security wants to downgrade this or wheezy-ignore it, then I won't object to that given what we currently know. If we're going to fix the currently 'known problems' with this package properly, we really want 1.0.2, which I'll push out as soon as the freeze is over. Unless someone can show there is an application in wheezy where this is more than a purely theoretical problem, I think that's the only thing that will actually make any real difference to any existing users here. (and if someone can show that, they'll probably find a whole bunch of other potentially serious bugs in that app too would be my first bet ... which would still be a better use of time than blind patching without any real testing ever being done) Cheers, Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705044: python-liblo: build against python3
Package: python-liblo Version: 0.9.1-2+b1 Severity: normal Dear Maintainer, Please build this against python 3 -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-rt-amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-liblo depends on: ii libc6 2.13-38 ii liblo7 0.26~repack-7 ii python 2.7.3-4 ii python2.6 2.6.8-1.1 ii python2.7 2.7.3-6 python-liblo recommends no packages. Versions of packages python-liblo suggests: pn pyliblo-utils 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#705045: libjson-spirit-dev: missing header file in /usr/include
Package: libjson-spirit-dev Version: 4.05-1 Severity: important Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? updating from 4.04 to 4.05 * What exactly did you do (or not do) that was effective (or ineffective)? I am including json_spirit.h in my source file. The latter includes json_spirit_writer.h which tries to include json_spirit_writer_options.h. json_spirit_writer_options.h does not exist in /usr/include/. * What was the outcome of this action? Cannot build my program. I had to correct manualy the json_spirit_writer.h file. * What outcome did you expect instead? *** End of the template - remove these lines *** -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) 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 libjson-spirit-dev depends on: ii libboost-dev 1.49.0.1 libjson-spirit-dev recommends no packages. libjson-spirit-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697890: Gnome installability vs. GNU/kFreeBSD (was: tasksel arch any vs. keeping track of n-m in debian-cd?)
Cyril Brulebois k...@debian.org (09/04/2013): Then I think I'd rather ask you to keep doing so for wheezy's lifetime, than trying to fiddle with tasksel at this very late point of the freeze. To clarify as I did on IRC: 1. I thought both the addition of iw and network-manager-gnome as Depends or Recommends in tasksel was depending on that arch: all vs. arch: any discussion. 2. However, the current tasksel package in wheezy and sid already implements the Depends: on network-manager-gnome, for all archs. Since we just agreed with Steve to keep the NM-related dependencies on the debian-cd side (iw was already taken care of in src:netcfg), we could think of uploading tasksel with just that network-manager-gnome dependency dropped, which would fix installability issues on kfreebsd-*. I'm not exactly sure how well Gnome is supported on GNU/kFreeBSD anyway, so that might not be a huge practical issue. But if -bsd@ people want that fixed, they can still chime in *right now*, so that we can patch tasksel while src:debian-installer is getting built, before we prepare d-i wheezy rc2 images. Mraw, KiBi. signature.asc Description: Digital signature
Bug#687563: RFS: opengrm-ngram/1.0.3-1 [ITP] -- opengrm n-gram, library
Lintian emits: X: libngram0: shlib-calls-exit usr/lib/libngram.so.0.0.0 Do I understand correctly that this comes from libfst, and would have to be fixed there? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696782: RFS: sequitur-g2p/0.0.r1668-1 [ITP] -- Grapheme to Phoneme conversion tool
* Giulio Paci giuliop...@gmail.com, 2013-04-06, 04:37: If I were packaging this myself, I'd use 0+r1668-1 as version number, just in case upstream decides to make a proper release versioned 0.0.1. But you can keep the current versioning scheme if you like it, of course. Changed the version to 0+r1668-1. Please update debian/watch, too. :) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705044: (no subject)
I need python3-liblo for stuff like lisaloqt https://github.com/nilsgey/lisaloQt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705040: Bug is in translate-toolkit
reassign 705040 translate-toolkit affects 705040 +virtaal thanks After looking at the error in the console, I found out that the file that point the error is from the translate-toolkit. I found there is a .translate_toolkit in my home with a stats.db file. I trashed the file, and virtaal opened files without errors. I would gladly join the stats.db file to the bug but it is 98,2 Mo. ERROR:root:MainController.open_file(filename=/usr/bin/../share/virtaal/tutorial.pot, uri=) Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/virtaal/controllers/maincontroller.py, line 208, in open_file self.store_controller.open_file(filename, uri, forget_dir=forget_dir) File /usr/lib/python2.7/dist-packages/virtaal/controllers/storecontroller.py, line 220, in open_file self.store = StoreModel(filename, self) File /usr/lib/python2.7/dist-packages/virtaal/models/storemodel.py, line 61, in __init__ self.load_file(fileobj) File /usr/lib/python2.7/dist-packages/virtaal/models/storemodel.py, line 147, in load_file self.update_stats(filename=filename) File /usr/lib/python2.7/dist-packages/virtaal/models/storemodel.py, line 171, in update_stats stats = statsdb.StatsCache().filestatestats(filename, self._trans_store, extended=True) File /usr/lib/python2.7/dist-packages/translate/storage/statsdb.py, line 337, in __new__ return make_database(statsfile) File /usr/lib/python2.7/dist-packages/translate/storage/statsdb.py, line 314, in make_database if clear_old_data(cache): File /usr/lib/python2.7/dist-packages/translate/storage/statsdb.py, line 299, in clear_old_data cache.cur.execute(SELECT min(toolkitbuild) FROM files) DatabaseError: database disk image is malformed signature.asc Description: This is a digitally signed message part
Bug#704884: alot: doesn't properly instantiate GPGProblem
Hi Vasudev, Quoting Vasudev Kamath (2013-04-07 08:09:35) Package: alot Version: 0.3.4-1 Severity: normal tag: patch Dear Maintainer, There was a bug in gpg signing part of alot which was failing when gpg-agent is either not running or password is not present in agent (mostly due to the improper configuration of gpg-agent). Here alot was not properly doing error handling and was not displaying proper error message display. I discussed this with upstream author and he provided a fix which is already on upstream Git but I'm attaching same patch with this mail. Please consider applying this patch to the alot package till upstream releases new tarball with this fix. [1] https://github.com/pazz/alot/issues/590 I've actually encountered this error yesterday, thanks for the patch and the forwarding upstream :-). I'll upload a fixed version ASAP. Cheers, Simon signature.asc Description: signature
Bug#704807: uruk: autodetect non-routable nets
Hoi, On Mon, Apr 08, 2013 at 04:57:39PM +0200, Casper Gielen wrote: Op 06-04-13 06:35, Joost van Baal-Ilić schreef: Package: uruk Tags: patch, upstream Hoi, Thanks for your bugreport. I am submitting it to the Debian BTS, so it won't get lost. Please reply to bugnr@bugs.debian.org if you have any more remarks on this issue. O! On which uruk-version are you working? 20130226-1 That's current latest upstream, OK thanks. your patch contains: - case $1 in - 192.168.*) echo 192.168.0.0/24 ;; - 172.16.*) echo 172.16.0.0/12 ;; - *) echo $1 ;; - esac it misses some ranges: joostvb@janacopoulos:~/git/uruk/uruk% grep \^ip._noroute_ranges script/uruk ip4_noroute_ranges='127.0.0.1/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16' ip6_noroute_ranges='::1/128 :0:0::/96 fc00::/7 fec0::/10 0200::/7 2001:0db8::/32' Furthermore, 172.16.0.0/12 is 172.16.0.0 - 172.31.255.255. Your code would wrongly place 172.32.0.1 in 172.16.0.0/12. Care to fix that? Hrm, there might be an easier way to work around the problem btw. We could e.g. state that autodetect-ips doesn't support that situation, and tell people to use another trick. The patch would update documentation only. I am not sure yet what's the best solution. Anyway, thanks for your work! Bye, Joost -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705046: unblock: debian-gis/0.0.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package debian-gis As announced in [1] I now uploaded debian-gis metapackages targeting at Wheezy. The changes in the debian-gis package are to a large extend auto generated by blends-dev and the full debdiff (attached debian-gis_0.0.2.debdiff.gz) is a bit hard to read because the files in tasks/ are serving at the same time used as documentation for the Debian GIS web sentinel[2]. There is no reasonable way to maintain this in a separate source so the diff is larger than you would usually accept these days. However, this was explained in [1] and was done this way in the last releases as well (and recently for other Blends). To enable you concentrating on the *relevant* changes which are caused due to changes in the package pool (some packages became removed and some became accepted since the last generation of the metapackages) I have split of the parts of the debdiff which are more easy to inspect to see what relevant changes in the dependencies have actually happended. Please feel free to inspect: debian-gis_0.0.2.debdiff_tasks.gz: diff -Nru debian-gis-0.0.1/debian-gis-tasks.desc debian-gis-0.0.2/debian-gis-tasks.desc --- debian-gis-0.0.1/debian-gis-tasks.desc 2010-07-07 12:10:02.0 +0200 +++ debian-gis-0.0.2/debian-gis-tasks.desc 2013-04-02 12:02:12.0 +0200 This shows in the most simple way what recommends were added / removed debian-gis_0.0.2.debdiff_control.gz: diff -Nru debian-gis-0.0.1/debian/changelog debian-gis-0.0.2/debian/changelog --- debian-gis-0.0.1/debian/changelog-2010-07-07 11:09:29.0 +0200 +++ debian-gis-0.0.2/debian/changelog-2013-04-02 11:50:56.0 +0200 diff -Nru debian-gis-0.0.1/debian/control debian-gis-0.0.2/debian/control --- debian-gis-0.0.1/debian/control---2010-07-07 12:10:03.0 +0200 +++ debian-gis-0.0.2/debian/control---2013-04-02 12:02:16.0 +0200 diff -Nru debian-gis-0.0.1/debian/control.stub debian-gis-0.0.2/debian/control.stub --- debian-gis-0.0.1/debian/control.stub--2010-07-07 11:28:01.0 +0200 +++ debian-gis-0.0.2/debian/control.stub--2013-04-02 11:59:57.0 +0200 This extract from debdiff shows the changes inside debian/. debian-gis_control_0.0.1-0.0.2.wdiff.gz: This was created using wdiff debian-gis-0.0.1/debian/control debian-gis-0.0.2/debian/control and is a better way to see the differences in the list of Recommends / Suggests inside the metapackages than a plain diff. Feel free to ask for any further information if needed. Kind regards and thanks for working on the Wheezy release Andreas. [1] https://lists.debian.org/debian-release/2012/06/msg00323.html [2] http://blends.alioth.debian.org/gis/tasks/ unblock debian-gis/0.0.2 -- System Information: Debian Release: 6.0.7 Architecture: i386 (i686) Kernel: Linux 2.6.36-xenU-4814-i386 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash debian-gis_0.0.2.debdiff.gz Description: GNU Zip compressed data debian-gis_0.0.2.debdiff_control.gz Description: GNU Zip compressed data debian-gis_0.0.2.debdiff_tasks.gz Description: GNU Zip compressed data debian-gis_control_0.0.1-0.0.2.wdiff.gz Description: GNU Zip compressed data
Bug#663927:
see: http://bugs.python.org/issue13736
Bug#705040: Bug is in translate-toolkit
Quoting Vincent Lhote (deb...@vincent.lhote.name): reassign 705040 translate-toolkit affects 705040 +virtaal thanks After looking at the error in the console, I found out that the file that point the error is from the translate-toolkit. I found there is a .translate_toolkit in my home with a stats.db file. I trashed the file, and virtaal opened files without errors. I would gladly join the stats.db file to the bug but it is 98,2 Mo. No problem sending it to the BTS (o need to CC me). I suggets you compress it with xz beforehand but that is not even madatory. signature.asc Description: Digital signature
Bug#705047: ITP: ruby-hiredis -- redis ruby driver using Hiredis
Package: wnpp Severity: wishlist Owner: Apollon Oikonomopoulos apoi...@gmail.com * Package name: ruby-hiredis Version : 0.4.5 Upstream Author : Pieter Noordhuis pcnoordh...@gmail.com * URL : http://github.com/pietern/hiredis-rb * License : BSD Programming Lang: Ruby Description : redis ruby driver using Hiredis ruby-hiredis provides a Ruby extension that wraps hiredis. Both the synchronous connection API and a separate protocol reader are supported. It is primarily intended to speed up parsing multi bulk replies. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679125: doesn't honor ACLs
Package: clamfs Version: 1.0.1-1 Severity: normal Hello, did anyone read this bug report? I have hit this bug as well - ACL permissions are not honored, only classic unix user/group/others permissions. Is there any way how I can help do to get this bug fixed? Regards Vladislav Kurz -- System Information: Debian Release: 6.0.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686-bigmem (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 clamfs depends on: ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib pn libcommoncpp2-1.6-0 none (no description available) ii libfuse22.8.4-1.1Filesystem in USErspace library ii libgcc1 1:4.4.5-8GCC support library pn libpocofoundation5 none (no description available) pn libpoconet5 none (no description available) pn librlog1c2a none (no description available) ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages clamfs recommends: pn clamav-daemon none (no description available) clamfs suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705049: ITP: dhcpd-pools -- ISC dhcpd lease analysis and reporting tool
X-Debbugs-CC: debian-de...@lists.debian.org X-Debbugs-CC: kerol...@iki.fi Package: wnpp Onwer: h.gro...@cygnusnetworks.de * Package name: dhcpd-pools Version : 2.21 Upstream Author : Sami Kerola kerol...@iki.fi * URL : http://dhcpd-pools.sf.net/ * License : BSD-2-clause + GPL-3+ (for embedded gnulib) Programming Lang: C Description : ISC dhcpd lease analysis and reporting tool Long description from upstream: This is dhcpd-pools ISC dhcp shared network and pool range usage analysis. Purpose of command is to count usage ratio of each IP range and shared network pool which ISC dhcpd is in control of. Users of the command are most likely ISPs and other organizations that have large IP space. . Program is written C. Design goal is to get analysis done quickly where there is lots of data. On cheap laptop the speed of analysis is roughly 100k leases per second. Number of ranges, or shared networks, does not make any significant difference in getting analysis done. I think that any large scale user of isc-dhcp-server would be interested in this package, because it is an excellent diagnostics tool. The closest thing already in Debian is libtext-dhcpleases-perl. A preliminary packaging is attached for those who need it now, but I intend to wait for the next upstream release, because the test suite is currently dysfunctional. Upstream is nice to interact with. I am not opposed to shared/team maintenance or reviews. Helmut dhcpd-pools_2.21-1.debian.tar.gz Description: GNU Zip compressed data
Bug#705050: libpyzy: FTBFS when char is unsigned
Source: libpyzy
Version: 1.0.1-1
Severity: serious
Justification: fails to build from source
Builds of libpyzy on architectures in which the standard char type is
unsigned have been failing:
DoublePinyinTable.h:376:1: error: narrowing conversion of
'-0x1' from 'int' to 'const char' inside { } [-fpermissive]
Could you please take a look? I'd suggest adding an explicit cast to
PINYIN_ID_VOID's definition, on line 29 of src/Types.h:
#define PINYIN_ID_VOID ((char)-1)
Thanks!
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696782: RFS: sequitur-g2p/0.0.r1668-1 [ITP] -- Grapheme to Phoneme conversion tool
Il 09/04/2013 15:03, Jakub Wilk ha scritto: * Giulio Paci giuliop...@gmail.com, 2013-04-06, 04:37: If I were packaging this myself, I'd use 0+r1668-1 as version number, just in case upstream decides to make a proper release versioned 0.0.1. But you can keep the current versioning scheme if you like it, of course. Changed the version to 0+r1668-1. Please update debian/watch, too. :) Done. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705051: mirror listing update for ftp.sv.debian.org
Package: mirrors Severity: minor Submission-Type: update Site: ftp.sv.debian.org Aliases: debian.salud.gob.sv Type: leaf Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc Archive-ftp: /debian/ Archive-http: /debian/ Archive-rsync: debian/ IPv6: no Archive-upstream: syncproxy2.eu.debian.org Updates: push Maintainer: Carlos Juan Martin Perez cmar...@salud.gob.sv Country: SV El Salvador Location: Calle Arce #827, San Salvador, El Salvador Sponsor: Ministry of Health / Ministerio de Salud http://www.salud.gob.sv Comment: Only updating email sponsor info -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705052: [initscripts] if-up.d/mountnfs: won't mount if lo is last interface to be configured
Package: initscripts
Version: 2.88dsf-41
Severity: important
Tags: patch
When doing ifup -a (as done on boot) it can happen that lo is brought up last.
Then the combination of
# Not for loopback!
[ $IFACE != lo ] || exit 0
and
# Wait until all auto interfaces are up before attemting to mount
# network file systems.
exit_unless_last_interface
ensures that nfs is not mounted.
Attached patch ignores lo in exit_unless_last_interface.
Greetings
Timo
--- mountnfs.dpkg-dist 2012-10-15 19:30:41.0 +0200
+++ mountnfs 2013-04-09 15:45:56.375942703 +0200
@@ -121,6 +121,9 @@
exit_unless_last_interface() {
ifaces=$(ifquery --list)
for i in $ifaces ; do
+ if [ $i = lo ]; then
+ continue
+ fi
if ! grep -q $i /etc/network/run/ifstate ; then
msg=if-up.d/mountnfs[$IFACE]: waiting for interface $i before doing NFS mounts
log_warning_msg $msg
signature.asc
Description: This is a digitally signed message part.
Bug#705053: jack-rack does not link with -lm
Package: jack-rack Version: 1.4.8~rc1-1 User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu raring ubuntu-patch jack-rack FTBFS in Ubuntu because it does not explicitly link with -lm. There's a patch for this already, but it doesn't include -lm even though the upstream bug does include it. So I updated the patch (below). This succeeds in Debian right now because the linker isn't as pedantic as Ubuntu's, but you might want to update this for the future. Thanks diff -Nru jack-rack-1.4.8~rc1/debian/patches/02-gcc45_binutils_gold.patch jack-rack-1.4.8~rc1/debian/patches/02-gcc45_binutils_gold.patch --- jack-rack-1.4.8~rc1/debian/patches/02-gcc45_binutils_gold.patch 2011-05-29 09:11:30.0 + +++ jack-rack-1.4.8~rc1/debian/patches/02-gcc45_binutils_gold.patch 2013-04-09 14:18:14.0 + @@ -1,21 +1,25 @@ Description: Fix FTBFS with newest GCC4.5 and linker. + Updated 2013-04-09 by Robie Basak robie.ba...@canonical.com: + * Added -lm; this is already in the upstream bug. Author: Alessio Treglia ales...@debian.org Forwarded: https://sourceforge.net/apps/trac/jack-rack/ticket/1 Also forwarded to torb...@gmx.de, leslie.pol...@gmx.net, adamsamp...@users.sourceforge.net +Last-Update: 2013-04-09 --- src/Makefile.am |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) jack-rack.orig/src/Makefile.am -+++ jack-rack/src/Makefile.am -@@ -61,7 +61,8 @@ jack_rack_CFLAGS = \ +--- a/src/Makefile.am b/src/Makefile.am +@@ -61,7 +61,9 @@ -DGNOME_DISABLE_DEPRECATED=1 -jack_rack_LDFLAGS = \ +LIBS = \ + -ldl \ ++ -lm \ $(JACK_LIBS) \ $(GTK_LIBS) \ $(GNOMEUI_LIBS) \ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659861: Processed: your mail
Control: notfound -1 1:1.12.13-12+squeeze1 On Fri, 2013-04-05 at 17:16:47 +0200, Guillem Jover wrote: Control: fixed -1 1:1.12.13-12+squeeze1 It's closed, but marked as still affecting the version in stable. I think the above should fix that. Nope, I guess this one should do, though: http://bugs.debian.org/cgi-bin/version.cgi?info=1;absolute=0;fixed=cvs%2F1%3A1.12.13-12%2Bsqueeze1;fixed=cvs%2F2%3A1.12.13%2Breal-8;collapse=1;package=cvs Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705054: mongodb-server: lacks a README.Debian file telling Debian-specific adaptations
Package: mongodb-server
Version: 1:2.0.7-1
Severity: normal
The mongodb packages in Debian are in a not-so-great state of maintenance.
In particular, the mongodb-server package does not say which adaptations (to
conform to the Debian policy) were made to the package.
For instance, it lacks a README.Debian file telling *where* the databases
are stored (that is, /var/lib/mongodb), as it diverges from upstream's
default:
http://docs.mongodb.org/manual/reference/configuration-options/#dbpath
The actual package where *any* README.Debian is found is in the mongodb
package, which is a metapackage depending on both the server and the client.
Even then, the information about Debian-specific parts is missing from that
file.
BTW, the user that chooses to install only the the server package will not
have the documentation.
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705015: ITP: ie7-js -- help Internet Explorer behave like a standards-compliant browser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 09/04/2013 07:09, Jonas Smedegaard a écrit : I suggest adding the following paragraph to long description: Thanks, staged for -2: http://anonscm.debian.org/gitweb/?p=pkg-javascript/ie7-js.git;a=commitdiff;h=f99c01a Regards David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRZCrGAAoJELgqIXr9/gnycKoP+gK9wq7aRd/XA/OnQ/YCaiGu 5689nFt+torGFjCc0YdAzJywHkyGQ3cVRMO++dknFkn4WfKTPtljeccriN5pDWxb AKTcCvTJvNhWhBf1UPFK/kUHpvJ3lvDuFR/eB38B6tq/1SnRhq4w7gvDhinD5CWi sUmowknFj0X2njt4uyns1j1E8d11G0oCSNs4OQQ5/ch9aZXcCV97nWqlZRdaHaNX 6jYVtL/FFdvUvO62YkFyEX2aGQE8Ej+HN1uvmQWIYh5ZpNx/r8TJSO1D5vFmE2RW Ip1buxUj11ZfWLNSsutFF684w1dyO4F4ajZzeueboMYFeVi44QYEc1VhIBD+DHw+ ZgIey8ykfg2QD7EUl3krIboXLn0jBr124LZfHVm/qQSVFbQUqTKqJRqGZmzmAsXU mFqy9aOBhXlmt1VRcxBzkY0ZRIbAnveEsy6Z/P6QO+lsFInUuJBDt0Lvzf4iONnB j5JcA8+ru5+/DVEXFGRH02STMnb6KzLKi5+brfxrp7EyBmyRwstKN7EdlUmSIUtp nRUGRGKvzlElZpeSa5MEhC6WUcLy5Zkfl3oaL6vw+Qmg4aiQ9ixQjnywMf0m54Lv wHQOVBDfSnFQ7r+psZOWkajWHjorHPL6JGyeTjmBkmD2k2+MEtFDiM6ZkSxZShb3 2bZhsQLsnXDoQBRjnROm =Ghml -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#705017: tvtime: Crash while switch in fullscreen
I confirm this bug After I moved tvtime windows to the left-bottom corner of desktop and switch to fullscreen, posibility to run again tvtime without crash is to delete .tvtime config folder ( or tvtime.xml file from this folder) and reconfigure tvtime With tvtime -v it looks like this: xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 768x576 window inside 768x576 space. xcommon: Received a map, marking window as visible (69). [...] xcommon: Displaying in a 531x398 window inside 531x421 space. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 540x405 window inside 540x421 space. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 542x406 window inside 542x421 space. xcommon: Pixel aspect ratio 1:1. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 1x1 window inside 135543928x1 space. xcommon: Pixel aspect ratio 1:1. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 1x1 window inside 135543928x1 space. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 1280x960 window inside 1280x1024 space. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 542x406 window inside 542x421 space. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 0x0 window inside 0x1 space. xvoutput: Received X error: BadValue (integer parameter out of range for operation) tvtime: Cleaning up. Thank you for using tvtime. Second try: xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 768x576 window inside 768x576 space. xcommon: Received a map, marking window as visible (69). [...] xcommon: Displaying in a 465x349 window inside 490x349 space. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 488x366 window inside 488x372 space. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 487x365 window inside 487x374 space. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 486x364 window inside 486x377 space. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 486x364 window inside 486x379 space. xcommon: Pixel aspect ratio 1:1. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 0x0 window inside 12420352x0 space. xvoutput: Received X error: BadValue (integer parameter out of range for operation) tvtime: Cleaning up. Thank you for using tvtime. Third try: xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 768x576 window inside 768x576 space. xcommon: Received a map, marking window as visible (69). [...] xcommon: Pixel aspect ratio 1:1. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 429x322 window inside 433x322 space. xcommon: Pixel aspect ratio 1:1. xcommon: Pixel aspect ratio 1:1. xcommon: Displaying in a 0x0 window inside 12420352x0 space. xvoutput: Received X error: BadValue (integer parameter out of range for operation) tvtime: Cleaning up. Thank you for using tvtime. Please apply patch to corect this bug. Best regards.
Bug#705055: mongodb: sources listed in VCS-Git field do not match those uploaded to the archive
Source: mongodb
Version: 1:2.4.1-2
Severity: normal
Essentially, subject says it all: the repository pointed to [0] by the
Debian infrastructure doesn't match what was uploaded for version 1:2.4.1-2,
as no branch in said repository has those sources (which precludes
collaboration and patches).
[0]: https://github.com/bobek/mongo-debian
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable'), (100, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64
Kernel: Linux 3.8-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-- no debconf information
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705056: /etc/default/devpts instructions to set mesg n by default don't work
Package: initscripts,libc6 /etc/default/devpts reads: # Set to 600 to have `mesg n' be the default TTYMODE=620 But this doesn't really work. Even if you mount /dev/pts with mode=600, your pty devices will end up with 620 permissions. This is because well-behaved software calls grantpt(), which changes the device permissions. Either grantpt() should be fixed not to touch permissions if /dev/pts is a devpts fs (as it did in the past[0]) or initscripts should be fixed not to claim you can have mesg n by default. [0] http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=292e3abebff9f94ca47c1a725a691cb6ed6cff5f -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695299: please update markdown-mode
Package: emacs-goodies-el Version: 35.2ubuntu2 Followup-For: Bug #695299 Note that markdown-mode 2.0 is now released. -- System Information: Debian Release: wheezy/sid APT prefers quantal-updates APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500, 'quantal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5.0-25-generic (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 emacs-goodies-el depends on: ii bash 4.2-5ubuntu1 ii dpkg 1.16.7ubuntu6 ii emacs24 [emacsen] 24.2+1-1ubuntu2 ii install-info 4.13a.dfsg.1-10ubuntu2 Versions of packages emacs-goodies-el recommends: ii dict 1.12.0+dfsg-5 ii perl-doc 5.14.2-13ubuntu0.2 ii wget 1.13.4-3ubuntu1 emacs-goodies-el suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705057: lxpanel loses configuration after upgrading squeeze to wheezy
Package: lxpanel Version: 0.5.10 I had a clean debian squeeze 6.0.6 installed with lxde-core and I upgraded to testing (by making changing 'squeeze' to 'wheezy' in /etc/apt/sources.list and issuing apt-get dist-upgrade). After rebooting and logging in, LXDE started normally, but the panel was missing. I found that the directory ~/.config/lxpanel/LXDE/ was empty. The issue was fixed by copying the original files from /etc/xdg/lxpanel/profile/LXDE/ to ~/.config/xlpanel/LXDE/ and rebooting. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705058: libpyzy: FTBFS on non-amd64: symbols not as expected
Source: libpyzy Version: 1.0.1-1 Severity: serious Justification: fails to build from source Builds of libpyzy on architectures other than amd64 and kfreebsd-amd64 that get past #705050 have been failing due to platform-specific variation in mangled symbol names (and formal types, presumably). Could you please account for this variation? Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705059: emacs-goodies-el: Time to start winding up this package?
Package: emacs-goodies-el Version: 35.2ubuntu2 Severity: wishlist This package has a large number of outstanding bugs, which are unlikely (at the present rate) to be resolved either in Debian, or for that matter upstream (I doubt many upstreams check the Debian BTS). On the other hand, a major rationale for the existence of the package, namely to ease the convenient installation of a wide range of Emacs modes, no longer exists, as ELPA, Marmalade and el-get all cater to this. ELPA ships with Emacs 24, and el-get is packaged in Debian, so perhaps it would be more profitable now to defer to them: they are often more up-to-date than the Debian package, and are better linked to upstream. emacs-goodies-el has no rdepends, so this would be quite safe to do. It could usefully retain any files that are not packaged in one of the above-mentioned Emacs repos, though arguably any such files should be submitted to those repos. A good place to start with deciding what to remove from emacs-goodies-el would be packages with many requests for updates, e.g. markdown-mode. -- System Information: Debian Release: wheezy/sid APT prefers quantal-updates APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500, 'quantal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5.0-25-generic (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 emacs-goodies-el depends on: ii bash 4.2-5ubuntu1 ii dpkg 1.16.7ubuntu6 ii emacs24 [emacsen] 24.2+1-1ubuntu2 ii install-info 4.13a.dfsg.1-10ubuntu2 Versions of packages emacs-goodies-el recommends: ii dict 1.12.0+dfsg-5 ii perl-doc 5.14.2-13ubuntu0.2 ii wget 1.13.4-3ubuntu1 emacs-goodies-el suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#656868: emacs-goodies-el: markdown-mode should be loaded automatically for suffix .md
Package: emacs-goodies-el Version: 35.2ubuntu2 Followup-For: Bug #656868 This can be achieved by adding the following line, I suggest just next to the commented out line that reads: ;(add-to-list 'auto-mode-alist '(\\.text$ . markdown-mode)) The new line is: (add-to-list 'auto-mode-alist '(\\.md\\' . markdown-mode)) The .el file comments also suggest adding a similar line for the .markdown suffix. -- System Information: Debian Release: wheezy/sid APT prefers quantal-updates APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500, 'quantal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5.0-25-generic (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 emacs-goodies-el depends on: ii bash 4.2-5ubuntu1 ii dpkg 1.16.7ubuntu6 ii emacs24 [emacsen] 24.2+1-1ubuntu2 ii install-info 4.13a.dfsg.1-10ubuntu2 Versions of packages emacs-goodies-el recommends: ii dict 1.12.0+dfsg-5 ii perl-doc 5.14.2-13ubuntu0.2 ii wget 1.13.4-3ubuntu1 emacs-goodies-el suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705060: mongodb: contains lintian overrides that aren't used
Source: mongodb Severity: normal Trying to understand where the javascript part of mongodb comes from, I noticed that the sources contain lintian overrides for xulrunner-1.9.1 which I *do* not have installed on my system (but mongodb works here). So, I guess that this bug is actually a multipart one: 1 - The overrides are not used, as indicated by lintian. 2 - The source tree for mongodb contains a lot of convenience copies of other programs (e.g., the whole src/third_party directory) that may be used during the build process. The first point is illustrated by: ,[ lintian -IE *.deb | grep -i override ] | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongo /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongo /usr/lib64/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongodump /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongodump /usr/lib64/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongoexport /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongoexport /usr/lib64/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongofiles /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongofiles /usr/lib64/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongoimport /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongoimport /usr/lib64/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongorestore /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongorestore /usr/lib64/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongostat /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongostat /usr/lib64/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongo /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongo /usr/lib64/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongodump /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongodump /usr/lib64/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongoexport /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongoexport /usr/lib64/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongofiles /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongofiles /usr/lib64/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongoimport /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongoimport /usr/lib64/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongorestore /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongorestore /usr/lib64/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongostat /usr/lib/xulrunner-1.9.1 | I: mongodb-clients: unused-override binary-or-shlib-defines-rpath usr/bin/mongostat /usr/lib64/xulrunner-1.9.1 | I: mongodb-server: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongod /usr/lib/xulrunner-1.9.1 | I: mongodb-server: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongod /usr/lib64/xulrunner-1.9.1 | I: mongodb-server: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongos /usr/lib/xulrunner-1.9.1 | I: mongodb-server: unused-override binary-or-shlib-defines-rpath ./usr/bin/mongos /usr/lib64/xulrunner-1.9.1 | I: mongodb-server: unused-override binary-or-shlib-defines-rpath usr/bin/mongod /usr/lib/xulrunner-1.9.1 | I: mongodb-server: unused-override binary-or-shlib-defines-rpath usr/bin/mongod /usr/lib64/xulrunner-1.9.1 | I: mongodb-server: unused-override binary-or-shlib-defines-rpath usr/bin/mongos /usr/lib/xulrunner-1.9.1 | I: mongodb-server: unused-override binary-or-shlib-defines-rpath usr/bin/mongos /usr/lib64/xulrunner-1.9.1 ` The second point should be clearly documented in README.source or something equivalent. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (100, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel:
Bug#704068: brltty: obsolete-conffile as told by adequate
Samuel Thibault sthiba...@debian.org writes: Hello, shirish शिरीष, le Wed 27 Mar 2013 20:39:34 +0530, a écrit : Adequate reports that brltty has an obsolete conffile. Please fix the same. $ adequate brltty brltty: obsolete-conffile /etc/brltty/brl-sk-all.ktb I'm not sure we really want to see newer versions of brltty to be dropping previously-provided tables, at least since the user might have configured their use in their brltty.conf, and wouldn't like to see that broken just because the table was renamed or removed upstream. I see your point, and I agree. However, in this particular case, the table is autoloaded by the sk driver, and as far as I know, the user has no way of configuring its use in any other context. This applies to /etc/brltty/brl-*.kt* -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer URL:http://debian.org/ .''`. | Get my public key via finger mlang/k...@db.debian.org : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- URL:http://delysid.org/ URL:http://www.staff.tugraz.at/mlang/ pgpE2v7sKpwVP.pgp Description: PGP signature
Bug#705062: ITP: libperlx-maybe-xs-perl -- XS backend for PerlX::Maybe
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard d...@jones.dk * Package name: libperlx-maybe-xs-perl Version : 0.004 Upstream Author : Toby Inkster toby...@cpan.org * URL : https://metacpan.org/release/PerlX-Maybe-XS * License : Artistic or GPL-1+ Programming Lang: Perl, C Description : XS backend for PerlX::Maybe PerlX::Maybe::XS is a (possibly 30% faster) XS implementation of PerlX::Maybe. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688896: This is a bad idea
Hi Laurent, I had a look at fpm a while back, but the way it's implemented makes it a pretty bad idea, in my opinion. It will generate a .deb file by running tar and ar etc manually, completely bypassing what dpkg does. While this happens to work and *might* be the right thing to do on non-Debian systems, I don't think it's something a tool in Debian should do. Please consider at least patching it so it uses dpkg behind the radar, rather than trying to bypass it entirely. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691455: Provide entry points for all supported python3 versions
Control: tags -1 -pending +wishlist Control: severity -1 wishlist The consensus on debian-python was to simply remove the nosetests-3.x scripts. As an alternative, one now can use commands like “python3.x -m nose …” or simply call /usr/bin/nosetests3. See http://lists.debian.org/debian-python/2013/02/msg00209.html for details. -- Dmitry Shachnev -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705063: kstart: Does not retry in the event of temporary DNS errors
Package: kstart Version: 4.1-2 Severity: normal Whilst troubleshooting an issue with startup of a daemon invoked via k5start and supervise, we noticed that k5start appears to exit, rather than retrying, if it is unable to resolve DNS (in this case, the local caching resolver was not started, owing to system startup dependency issues), whist getting AFS tokens. Here's a manual test with the resolver down. flexible-demeanour:/home/dom# /usr/bin/k5start -f /etc/apache2-instances/sysdev.oucs-register/krb5.keytab -l 10h -K 10 -t -I ox.ac.uk -S afs -v -U -- /usr/bin/fghack /usr/sbin/apache2 -f /etc/apache2-instances/sysdev.oucs-register/apache2.conf -k start Kerberos initialization for www-data/flexible-demeanour.oucs.ox.ac...@ox.ac.uk for service afs/ox.ac.uk k5start: authenticating as www-data/flexible-demeanour.oucs.ox.ac...@ox.ac.uk k5start: getting tickets for afs/ox.ac...@ox.ac.uk k5start: error getting credentials: Resource temporarily unavailable flexible-demeanour:/home/dom# echo $? 1 I wasn't sure whether this counted as a normal bug or a wishlist feature request, although I note that the manpage says, of -K: If an error occurs in refreshing the ticket cache, the wake-up interval will be shortened to one minute and the operation retried at that interval for as long as the error persists. which one might interpret to mean that this error should be caught and retries should happen. The system in question wasn't the one where I'm writing this report, but it was also a wheezy system. Thanks, Dominic. -- System Information: Debian Release: 7.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kstart depends on: ii libc6 2.13-38 ii libkrb5-3 1.10.1+dfsg-4+nmu1 kstart recommends no packages. kstart suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705064: ITP: rfc5766-turn-server - STUN/TURN server
Package: wnpp Severity: wishlist The TURN Server is a VoIP media traffic NAT traversal server and gateway. It can be used as a general-purpose network traffic TURN server/gateway, too. This implementation also includes some extra features. Supported RFCs: TURN specs: - RFC 5766 - base TURN specs - RFC 6062 - TCP relaying TURN extension - RFC 6156 - IPv6 extension for TURN - Experimental DTLS support as client protocol. STUN specs: - RFC 5389 - base new STUN specs - RFC 5769 - test vectors for STUN protocol testing - RFC 5780 - NAT behavior discovery support The implementation fully supports UDP, TCP, TLS and DTLS as protocols between the TURN client and the TURN Server. Flat files, MySQL or PostgreSQL are supported for the user repository (if authentication is required). Both short-term and long-term credentials mechanisms are supported. TURN Server REST API for time-limited secret-based authentication is implemented. The implementation is supposed to be simple, easy to install and configure. The project focuses on performance, scalability and simplicity. To achieve high performance and scalability, the TURN server is implemented with the following features: - High-performance industrial-strength Network IO engine libevent2 is used - Configurable multi-threading model implemented to allow full usage of available CPU resources (if OS allows multi-threading) - Multiple listening and relay addresses can be configured - Efficient memory model used - The TURN project code can be used in a custom proprietary networking environment. In the TURN server code, an abstract networking API is used. Only couple files in the project have to be re-written to plug-in the TURN server into a proprietary environment. With this project, only implementation for standard UNIX Networking/IO API is provided, but the user can implement any other environment. The TURN server code was originally developed for a high-performance proprietary corporate environment, then adopted for UNIX Networking API - The TURN server works as a user space process, without imposing any special requirements on the system - Contact: email:mom040...@gmail.com
Bug#703376: javahelper: Remove Maven support from jh_makepkg
Niels Thykier: I am planning on a rewrite of jh_makepkg and have therefore not applied your patch as-is. I wasn't aware (forgot) about jh_makepkg and just had a look at it. I don't think we should have 2 dh-make-* style programs in the java team: jh_makepkg and mh_make. It's already enough logic duplication between dh-make, dh-make- perl, dh-make-php, dh-make-drupal, gem2deb, python-stdeb, haskell-devscripts, ... We might be the only language team that does not use its own programming language for this kind of tool. While I'm more fluent in Python, it might be better to converge on Perl as much of javahelper is already written in Perl. Niels: What are your plans for the jh_makepkg rewrite? Regards, Thomas Koch, http://www.koch.ro -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705035: r-base-dev: generated dependency in substvars should specify a maximum R version
On Tue, Apr 09, 2013 at 06:54:49AM -0500, Dirk Eddelbuettel wrote: | and an empty package r-base-binary-version which is updated as and | when there's a half-binary change. Which is essentially the proposal to have a virtual package r-core-api whatever we call it -- and why I told you in my first email that your bug report was the same as #704805. Ah, oops, read that now - going to comment on that Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673424: Fwd: Bug#673424: bbswitch packaging
On Thu, Apr 4, 2013 at 5:22 PM, Vincent Cheng vincentc1...@gmail.com wrote: On Wed, Apr 3, 2013 at 5:13 AM, Aron Xu a...@debian.org wrote: [snip] Then could you add it to Debian's git repo? Done. But in the process of building the packages I hit another issue [1], so please hold off (yet again) on uploading primus until it gets fixed. Do you think it's time to upload bumblebee? As an aside, I made a comment about the current architecture field of bbswitch after Ratesh uploaded 0.6, but I suppose you may have missed them: Also, why did you opt for Architecture: linux-any for a dkms package? Everything inside the binary package is installed into an arch-independent location, so I think it should probably be arch:all instead, and most dkms packages [1] adhere to being arch:all, including dkms itself. But since you've explicitly moved the package from arch:all to arch:linux-any, I'll just leave it be... AFAIK even though bbswitch does not contain any architecture specific file, it does not work on other platforms other than linux-any, e.g. kfreebsd and hurd. So I moved it to linux-any. (And yes, there is dkms support for kfreebsd.) However, we end up duplicating the package on all linux archs (there's no difference between the bbswitch package built on i386 vs. amd64, or mips, or sparc, or ppc...). It just feels redundant to me, but on the whole it's just a minor issue. I'm fine with leaving it as-is. How about bumblebee though? That really should be restricted to i386 and amd64 only; Nvidia Optimus is AFAIK only supposed to work with Intel+Nvidia hardware combinations, so that pretty much limits it to being used on i386 + amd64. I guess yes? Don't know other people's opinion. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687563: RFS: opengrm-ngram/1.0.3-1 [ITP] -- opengrm n-gram, library
Il 09/04/2013 14:57, Jakub Wilk ha scritto: Lintian emits: X: libngram0: shlib-calls-exit usr/lib/libngram.so.0.0.0 Do I understand correctly that this comes from libfst, and would have to be fixed there? I have not found any direct exit reference in libngram source code. So I checked libfst code and there are just a few calls: 1) One is in FailedNewHandler() in src/lib/compat.cc. As far as I can tell this is only a convenience function to call exit and print an error message, to be used with std::set_new_handler() in applications. 2) Some are in SetFlags() in src/lib/flags.cc. This seems a convenience function to be used at the begin of a program to parse flags, handle errors and exit if needed (I am not 100% sure anyway). It is also called by the deprecated similar convenience function InitFst(). 3) Another one is in LogMessage() in src/include/fst/log.h, when invoked with FATAL type. 4) TestProperties() in src/include/fst/test-properties.h, if FLAGS_fst_verify_properties is set, LogMessage(FATAL) may be called. 5) If FLAGS_fst_error_fatal is set all FSTERROR() calls results in a LogMessage(FATAL) call. 1), 2), 4), 5) are not directly called in libngram. 3) is used several way in libngram instead. I am not sure about how to deal with this issue. OpenFST exit calls seem reasonable to me, while LOG(FATAL) calls in libngram seem not. What is your opinion about this? Bests, Giulio. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#368297: About the libgcrypt and OpenLDAP issue
Hi, Carlos Alberto Lopez Perez clo...@igalia.com writes: Now I'm convinced that the right fix for this is to revert upstream d769529a71ccda4e833f919f3c5693d25b005ff0 [1] commit on libgcrypt like Ubuntu did. The Regression introduced on python-gnutls by such reversion was already fixed on Ubuntu with another patch (see LP:#1013798 [2]) and they have been running with the patch for some time without more problems (AFAIK) so I think that we can assume that there are no more regressions. Therefore I think we should reassign this bug back to libgcrypt11. Fix it with a patch that reverts d769529a71ccda4e833f919f3c5693d25b005ff0 [1] and then fill another RC bug for python-gnutls asking for applying the same patch that Ubuntu applied (see LP:#1013798 [2]) At work we are running into this problem while testing wheezy. setuid programs were failing when authenticating over ldap. I've tested a patch to libgcrypt11 reverting d769529a71ccda4e833f919f3c5693d25b005ff0 and it fixes the problem for us, with no obvious regressions. If you want me to do any more testing I can do so. Is it possible to get this fixed for the wheezy release? It would greatly smooth our rollout of wheezy. Thanks to all for your work on this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645713: fails to upgrade a default GNOME desktop installation from squeeze → sid
On Thu, Apr 4, 2013 at 10:46 PM, Julien Cristau jcris...@debian.org wrote: On Sun, Mar 24, 2013 at 18:17:46 +0100, David Kalnischkies wrote: Pictures^Wdpkg-status files or it didn't happen, as I said multiple times now. You'll find the (compressed) status file attached. […] E: Could not perform immediate configuration on 'openjdk-6-jre'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2) Thanks. After wasting a few days on this now I know at least who is at fault: me. And as I am not a dependency I pass the blame on to Java5 and OpenOffice. [I will spare you the details now, you will find some below as very long P.S.] I have done very few tests, but it seems like bringing openoffice.org-core back (as a transitional package) is the simplest workaround. If I remember right all status-files I have seen so far about this issue (not that many, but yeah) included openoffice (as I wondered why it was touched so early and wanted to investigate this after wheezy), so while this sounds indeed crazy I guess it would solve all known issues. Hence CC'ing the previous maintainers to gaining some intelligence on how feasible this is. (Such a transition package needs to break at least openoffice.org-report-builder-bin as it is otherwise not removed on upgrade. I have no idea what else / how depends should look like) Alternatively we could provide a fixed apt/squeeze which removes the most offending lines (and reopens bugs), but the usual problems arise from that. Best regards David Kalnischkies, who works on a timemachine now to travel ~3 years into the past to prevent a certain someone from committing something harmful … (… and ~10 more to prevent the other half by various others). P.S.: I mentioned the Provides change earlier which after carefully looking at it breaks now after 3 years into pieces and I wonder how it worked at all … (not that the code before that would be bug-free, I just enhanced it) Describing whats going on is a bit hard and frankly I haven't worked out myself in completion what the code does, just what it should do and while this overlaps at many points, in edgecases the code runs amok … This code is run for all dependencies effected by a remove, but a problem will only arise if you have an or-group somewhere behind that dependency which features virtual packages AND [pretty freaky ordering conditions – I will refer to it as magic]. In the testcase we happen to meet these conditions once: While removing openoffice.org-core we call this code for many openoffice.org-* packages one of those is openoffice.org-officebean which features such a magic or-group beginning with default-jre | …. The magic will help us skipping over most of the or-group, but we will end-up with java5-runtime being mistakenly chosen for immediate promotion to a package needing immediate configuration (better: a provider as java5 is virtual). So we end up with stuff like 'openjdk6-jre' as kinda pseudo essential. (I am positive that it works with other openoffice.org-* packages too, as long as they need the core package and java [in that order], which is true in the example for openoffice.org-base, too – and it works with promoting others like gcj-jre, too. Which one is chosen exactly depends on magic, just like promotions in real life do [SCNR]). That these packages become kinda pseudo essential is a bug, but in most cases apt/squeeze can work with that. Sometimes it can't, which is a known bug [hopefully] fixed in apt/wheezy which I suspected as being at fault here as the usual symptoms apply (and disappear with apt/wheezy). I am working for a while now on fixing this code, which basically means a complete rewrite of the DepRemove method, but as usually the bug leads just to a non-optimal ordering, we could (and I tend to should) happily delay this until jessie and work around it as we usually do it with bugs in APT. P.P.S.: The Conf Broken error(s) can be ignored as they just happen in simulation. In the real run APT will tell dpkg to do the right thing™ and it usually does (like configuring two packages at the same time). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705065: buggy magic: HTML as C++/ASCII text
Package: file Version: 5.11-2 Severity: normal file give suprising result for: $ sudo apt-get install libutffcpp-doc $ file /usr/share/doc/libutfcpp-doc/utf8cpp.html /usr/share/doc/libutfcpp-doc/utf8cpp.html: C++ source, ASCII text where: $ head /usr/share/doc/libutfcpp-doc/utf8cpp.html !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head meta name=generator content= HTML Tidy for Linux/x86 (vers 1st November 2002), see www.w3.org meta name=description content= A simple, portable and lightweigt C++ library for easy handling of UTF-8 encoded strings meta name=keywords content=UTF-8 C++ portable utf8 unicode generic templates meta name=author content=Nemanja Trifunovic title thanks -- System Information: Debian Release: 6.0.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages file depends on: ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libmagic1 5.11-2 File type determination library us ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime file recommends no packages. file suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704805: Depend precisely on a versionned R API via R:Depends.
On Sat, Apr 06, 2013 at 12:58:39PM +0900, Charles Plessy wrote:
This can be done with the attached patch, that I tested locally.
One tiny fix to the patch is needed (presumably a typo):
-rversion := $(shell dpkg-query -W -f='$${Version}' r-base-dev)
+rAPIversion := $(shell dpkg-query -W -f='$${Provides}' r-base-core | grep
-o 'r-api.[^,]')
This grep command should be grep -o 'r-api[^,]*' (with a '*' and
perhaps no '.') so that r-api-3a will be returned as r-api-3a and not
r-api-3 as needed.
Other than that, I fully support the need for this patch, for the
reasons given in the bug report.
On the related subject of debian-r.debian.net (which I had been
unaware of), it is not clear from the packages which version of R they
are built against, and therefore whether they will work on R 2.14 or
on R 3.0; this would solve that problem entirely (assuming that the
packages are then built using the appropriate r-api-* dependency).
On a side note, I wonder whether it's worth me having my tiny handful
of r-cran-* packages in Debian at all; as they are more likely to be
updated regularly (and, presumably, automatically) on that site, that
would be much more useful to people in the long run. So perhaps I
should just ask for my packages to be removed from testing? Comments
would be appreciated!
Julian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704805: Depend precisely on a versionned R API via R:Depends.
On 9 April 2013 at 17:22, Julian Gilbey wrote:
| On Sat, Apr 06, 2013 at 12:58:39PM +0900, Charles Plessy wrote:
| This can be done with the attached patch, that I tested locally.
|
| One tiny fix to the patch is needed (presumably a typo):
|
| -rversion := $(shell dpkg-query -W -f='$${Version}' r-base-dev)
| +rAPIversion:= $(shell dpkg-query -W -f='$${Provides}' r-base-core
| grep -o 'r-api.[^,]')
|
| This grep command should be grep -o 'r-api[^,]*' (with a '*' and
| perhaps no '.') so that r-api-3a will be returned as r-api-3a and not
| r-api-3 as needed.
|
| Other than that, I fully support the need for this patch, for the
| reasons given in the bug report.
|
| On the related subject of debian-r.debian.net (which I had been
| unaware of), it is not clear from the packages which version of R they
As with previous 'cran2deb' efforts: always the most current one in the
distro flavour. So testing for testing (when Charles and I did cran2deb).
| are built against, and therefore whether they will work on R 2.14 or
| on R 3.0; this would solve that problem entirely (assuming that the
| packages are then built using the appropriate r-api-* dependency).
It really isn't needed as debian-r.debian.net / cran2deb is a huge big fat
binNMU generator (and more, package creator).
| On a side note, I wonder whether it's worth me having my tiny handful
| of r-cran-* packages in Debian at all; as they are more likely to be
It depends on maintainer committement. My 100+ r-cran-* are generally
current, sadly I don't always feel the same about debian-{med,science}.
| updated regularly (and, presumably, automatically) on that site, that
| would be much more useful to people in the long run. So perhaps I
| should just ask for my packages to be removed from testing? Comments
| would be appreciated!
That is a discussion we should have about the possible moonshoot of having
the 4400+ CRAN package (or a reasonable [ for different definitions of
reasonable ]) subset in Debian.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659335: Summary of current experimental tags
Control: tags + patch
* Russ Allbery r...@debian.org, 2013-04-07, 12:22:
* python(3)-depends-but-no-python(3)-helper 2.5.4 (Nov 2011)
- In total, some 40-46 cases
- both tags are serious/possible (E)
- I am considering to promote to non-experimental.
I was going to propose to un-experimental this one, too.
Unfortunately, a few of these tags are false positive. This is because
people do crazy things like this:
WITH_PYTHON2 = $(shell test -f /usr/bin/dh_python2 echo --with python2)
%:
dh $@ ${WITH_PYTHON2}
Lintian has of course no way of knowing with will WITH_PYTHON2 expand
to... But perhaps in these crazy cases people should just add
overrides. (FTR, this is tracked as #659335.)
We could also just assume that anyone using shell substitution
variables in the dh line of debian/rules know what they're doing.
Lintian makes similar assumptions elsewhere in rules handling.
Yes, of course. I don't know why I didn't thought about this earlier.
Thanks!
Here's a patch to implement it.
--
Jakub Wilk
diff --git a/checks/debhelper b/checks/debhelper
--- a/checks/debhelper
+++ b/checks/debhelper
@@ -182,6 +182,11 @@
}
}
}
+if (m,\$[({]\w,) {
+# the variable could contain any add-ons
+$seen_python_helper = 1;
+$seen_python3_helper = 1;
+}
if ($seen_python_helper == 0) {
$seen_python_helper = -1; # maybe; we'll check that later
}
diff --git a/checks/debhelper.desc b/checks/debhelper.desc
--- a/checks/debhelper.desc
+++ b/checks/debhelper.desc
@@ -265,7 +265,6 @@
Tag: python-depends-but-no-python-helper
Severity: serious
Certainty: possible
-Experimental: yes
Info: The source package declares a dependency on ${python:Depends} in the
given binary package's debian/control entry. However, debian/rules doesn't
call any helper that would generate this substitution variable.
@@ -277,7 +276,6 @@
Tag: python3-depends-but-no-python3-helper
Severity: serious
Certainty: possible
-Experimental: yes
Info: The source package declares a dependency on ${python3:Depends} in the
given binary package's debian/control entry. However, debian/rules doesn't
call any helper that would generate this substitution variable.
Bug#705066: g++-4.7: wrong line indicated in warning for synthesized method
Package: g++-4.7
Version: 4.7.2-5
Severity: minor
$ g++ -c -std=c++11 -Wunused-parameter test.cpp
test.cpp:3:8: warning: unused parameter ‘p’ [-Wunused-parameter]
test.cpp: In function ‘int main()’:
test.cpp:21:17: note: synthesized method ‘A A::operator=(A)’ first
required here
$ cat test.cpp
#include functional
struct A // line pointed-to by warning
{
struct B
{
B operator=(B) { return *this; }
};
B f;
A() = default;
A operator=(A p) = default; // where the method is declared
};
int main()
{
A a;
A b;
b = std::move(a);
}
$ g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.7.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-
bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-
languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7
--enable-shared --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-
gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-
sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-
time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-
arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64
-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
-- System Information:
Debian Release: 7.0
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (401,
'experimental'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.8.5 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages g++-4.7 depends on:
ii gcc-4.7 4.7.2-5
ii gcc-4.7-base4.7.2-5
ii libc6 2.13-38
ii libgmp102:5.0.5+dfsg-2
ii libmpc2 0.9-4
ii libmpfr43.1.0-5
ii libstdc++6-4.7-dev 4.7.2-5
ii zlib1g 1:1.2.7.dfsg-13
g++-4.7 recommends no packages.
Versions of packages g++-4.7 suggests:
ii g++-4.7-multilib4.7.2-5
ii gcc-4.7-doc 4.7.2-2
pn libstdc++6-4.7-dbg 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#705067: FTBFS on powerpc: Missing WebRTC entries in configure.ac
Package: iceweasel Version: 20.0-1 Severity: serious Tags: upstream patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Attachment https://bug814693.bugzilla.mozilla.org/attachment.cgi?id=698508 of upstream bug report https://bugzilla.mozilla.org/show_bug.cgi?id=814693 fixes this and makes iceweasel 20 build and run on powerpc. - -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (102, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 3.7.4+ Locale: LANG=de_CH.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages iceweasel depends on: ii debianutils 4.3.4 ii fontconfig 2.9.0-7.1 ii libc6 2.13-38 ii libgcc1 1:4.8.0-2 ii libgdk-pixbuf2.0-0 2.28.0-1 ii libglib2.0-02.36.0-2 ii libgtk2.0-0 2.24.17-1 ii libnspr42:4.9.6-1 ii libnspr4-0d 2:4.9.6-1 ii libsqlite3-03.7.16.1-1 ii libstdc++6 4.8.0-2 ii procps 1:3.3.4-2 ii xulrunner-20.0 20.0-1 iceweasel recommends no packages. Versions of packages iceweasel suggests: ii fonts-stix [otf-stix] 1.1.0-1 ii libgssapi-krb5-2 1.10.1+dfsg-5 pn mozplugger none Versions of packages xulrunner-20.0 depends on: pn libasound2none ii libatk1.0-0 2.8.0-1 ii libbz2-1.01.0.6-4 ii libc6 2.13-38 ii libcairo2 1.12.14-1 ii libdbus-1-3 1.7.0-1 ii libdbus-glib-1-2 0.100.2-1 ii libevent-2.0-52.0.19-stable-3 ii libfontconfig12.9.0-7.1 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.8.0-2 ii libgdk-pixbuf2.0-02.28.0-1 ii libglib2.0-0 2.36.0-2 ii libgtk2.0-0 2.24.17-1 ii libhunspell-1.3-0 1.3.2-4 ii libmozjs20d 20.0-1 ii libnspr4 2:4.9.6-1 ii libnss3 2:3.14.3-1 ii libpango-1.0-01.32.5-3 ii libpangocairo-1.0-0 1.32.5-3 ii libpangoft2-1.0-0 1.32.5-3 ii libpixman-1-0 0.26.0-4 ii libsqlite3-0 3.7.16.1-1 ii libstartup-notification0 0.12-2 ii libstdc++64.8.0-2 ii libvpx1 1.1.0-1 ii libx11-6 2:1.5.0-1 ii libxext6 2:1.3.1-2 ii libxrender1 1:0.9.7-1 ii libxt61:1.1.3-1 ii zlib1g1:1.2.7.dfsg-13 Versions of packages xulrunner-20.0 suggests: ii libcanberra0 0.30-1 ii libgnomeui-0 2.24.5-2 - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iD8DBQFRZERJWoGvjmrbsgARAvZLAKCwM0BRBwwLa/pijqQ1xpoLyquo7QCgikVR TAKDoP0h/h/G8ytWcYyGMWM= =xUG4 -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
