Bug#675465: diffstat doesn't handle svn diff with spaces in path
Package: diffstat Version: 1.53-1 Severity: normal Tags: upstream patch Hi! diffstat in both squeeze and sid doesn't handle svn diff output nicely if there are spaces in the file path. I guess that's probably considered just punishment for creating files or directories with spaces in them... but it does make the output of diffstat somewhat less useful. The attached example illustrates the problem: $ diffstat svn_diff_example ergh |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) and the attached patch (against 1.55-2 and suitable for debian/patches/) fixes this: $ diffstat svn_diff_example quux bar baz |2 +- quux bar baz2 |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) cheers Stuart -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-0.bpo.2-686-pae (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages diffstat depends on: ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib diffstat recommends no packages. diffstat suggests no packages. -- no debconf information Index: ergh eek arf/quux bar baz === --- ergh eek arf/quux bar baz (.../branch1) (revision 4) +++ ergh eek arf/quux bar baz (.../branch2) (revision 4) @@ -1 +1 @@ -foo goo +foo bar Index: ergh eek arf/quux bar baz2 === --- ergh eek arf/quux bar baz2 (.../branch1) (revision 4) +++ ergh eek arf/quux bar baz2 (.../branch2) (revision 4) @@ -1 +1 @@ -foo goo +foo bar Description: Handle pathnames with spaces in svn diff format Author: Stuart Prescott stuart+deb...@nanonanonano.net --- a/diffstat.c +++ b/diffstat.c @@ -1444,6 +1444,10 @@ hour, minute, second) == 9 date_delims(yrmon, monday) !version_num(b_fname)) + || (sscanf(buffer, + *** %[^\t]\t(%[^)])\t(%[^)]), + b_fname, b_temp1, b_temp2) == 3 +!version_num(b_fname)) || sscanf(buffer, *** %[^\t ]%[\t ]%[^ ] %[^ ] %d %d:%d:%d %d, b_fname,
Bug#674824: Please install icons for xpra system tray menu
Package: xpra Version: 0.1.0.1+dfsg-1~bpo60+1 Severity: wishlist Hi! The xpra binary package is missing its icon set. If the icons directory in the source package is installed as /usr/share/xpra/icons/, then xpra will use these icons for the system tray icon and the menu that is spawned from the system tray. (The icons are missing in the backports package in the Version header here and also in the 0.3.0+dfsg-1 version in unstable.) cheers Stuart -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (550, 'stable-updates'), (550, 'proposed-updates'), (550, 'stable'), (60, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-0.bpo.2-686-pae (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 xpra depends on: ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libx11-6 2:1.3.3-4 X11 client-side library ii python2.6.6-3+squeeze7 interactive high-level object-orie ii python-dbus 0.83.1-1 simple interprocess messaging syst ii python-gtk2 2.17.0-4 Python bindings for the GTK+ widge ii python-imaging1.1.7-2Python Imaging Library ii python-wimpiggy 0.1.0.1+dfsg-1~bpo60+1 library for writing window manager ii x11-xserver-utils 7.5+3 X server utilities ii xvfb 2:1.7.7-14 Virtual Framebuffer 'fake' X serve xpra recommends no packages. Versions of packages xpra suggests: ii openssh-client1:5.5p1-6+squeeze2 secure shell (SSH) client, for sec ii openssh-server1:5.5p1-6+squeeze2 secure shell (SSH) server, for sec -- 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#672488: debian-handbook: Please use codenames not stable in sources.list examples
Package: debian-handbook Version: 6.0+20120509 Severity: normal Hi! A user in #debian just pointed out that Example 6.1 (and following) of the Debian Administrator's Handbook was using stable rather than squeeze in its examples for the sources.list file. We've only just (finally!) got rid of these from sources.list(5) and having a new source recommending this isn't great. The problem is, of course, that upgrading from oldstable→stable is no longer just a simple matter of apt-get dist-upgrade with most releases having some extra hurdles such as upgrading kernel and udev then rebooting then upgrading the rest of the system -- while you can sometimes get away without doing these extra steps, it's one of those you get to keep all the pieces when it breaks moments and the release notes only include those steps because significant and difficult-to-fix breakage has been reported in upgrading tests. Soon after a stable release, #debian sees people who have accidentally made mixed oldstable+stable systems or end up with very confused package management systems trying to install one or two new packages into their oldstable machine without having done the full upgrade. Since we can pretty much guarantee that all the versioned dependencies won't be of perfect tightness to ensure that the mixed system works, we just have to accept that such partial upgrades are not likely to be happily functioning systems. We really need to do our best in *all* documentation published to avoid mixed systems like this. There is more discussion on this in #531492 which led to sources.list(5) finally being fixed for squeeze. It would be nice if we could have similar set of fixes for the debian-handbook since it has a lot of people looking at it. thanks -- and thanks for putting together so much documentation for users cheers Stuart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671564: src:xtables-addons: Fails to build twice in a row
Package: src:xtables-addons Version: 1.42-1 Severity: important User: debian...@lists.debian.org Usertags: qa-doublebuild Hi! The xtables-addons package fails to build twice in a row. The clean target leaves lots of files behind leading to the following error: make[1]: Leaving directory `/tmp/xtables-addons-1.42' dh_autoreconf_clean dh_clean dpkg-source -b xtables-addons-1.42 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building xtables-addons using existing ./xtables-addons_1.42.orig.tar.gz dpkg-source: warning: ignoring deletion of file Makefile.in dpkg-source: warning: ignoring deletion of file configure dpkg-source: warning: ignoring deletion of file aclocal.m4 dpkg-source: warning: ignoring deletion of file m4/ltoptions.m4 dpkg-source: warning: ignoring deletion of file m4/libtool.m4 dpkg-source: warning: ignoring deletion of file m4/ltversion.m4 dpkg-source: warning: ignoring deletion of file build-aux/config.guess dpkg-source: warning: ignoring deletion of file build-aux/missing dpkg-source: warning: ignoring deletion of file build-aux/ltmain.sh dpkg-source: warning: ignoring deletion of file build-aux/config.sub dpkg-source: warning: ignoring deletion of file build-aux/compile dpkg-source: warning: ignoring deletion of file build-aux/depcomp dpkg-source: warning: ignoring deletion of file build-aux/install-sh dpkg-source: warning: ignoring deletion of file extensions/Makefile.in dpkg-source: warning: ignoring deletion of file extensions/ACCOUNT/Makefile.in dpkg-source: warning: ignoring deletion of file extensions/pknock/Makefile.in dpkg-source: warning: ignoring deletion of file geoip/Makefile.in dpkg-source: info: local changes detected, the modified files are: xtables-addons-1.42/extensions/.libxt_CHAOS.oo.d xtables-addons-1.42/extensions/.libxt_DELUDE.oo.d xtables-addons-1.42/extensions/.libxt_DHCPMAC.oo.d xtables-addons-1.42/extensions/.libxt_DNETMAP.oo.d xtables-addons-1.42/extensions/.libxt_ECHO.oo.d xtables-addons-1.42/extensions/.libxt_IPMARK.oo.d xtables-addons-1.42/extensions/.libxt_LOGMARK.oo.d xtables-addons-1.42/extensions/.libxt_RAWDNAT.oo.d xtables-addons-1.42/extensions/.libxt_RAWSNAT.oo.d xtables-addons-1.42/extensions/.libxt_STEAL.oo.d xtables-addons-1.42/extensions/.libxt_SYSRQ.oo.d xtables-addons-1.42/extensions/.libxt_TARPIT.oo.d xtables-addons-1.42/extensions/.libxt_condition.oo.d xtables-addons-1.42/extensions/.libxt_dhcpmac.oo.d xtables-addons-1.42/extensions/.libxt_fuzzy.oo.d xtables-addons-1.42/extensions/.libxt_geoip.oo.d xtables-addons-1.42/extensions/.libxt_gradm.oo.d xtables-addons-1.42/extensions/.libxt_iface.oo.d xtables-addons-1.42/extensions/.libxt_ipp2p.oo.d xtables-addons-1.42/extensions/.libxt_ipv4options.oo.d xtables-addons-1.42/extensions/.libxt_length2.oo.d xtables-addons-1.42/extensions/.libxt_lscan.oo.d xtables-addons-1.42/extensions/.libxt_psd.oo.d xtables-addons-1.42/extensions/.libxt_quota2.oo.d xtables-addons-1.42/extensions/ACCOUNT/.libxt_ACCOUNT.oo.d xtables-addons-1.42/extensions/pknock/.libxt_pknock.oo.d dpkg-source: info: you can integrate the local changes with dpkg-source --commit dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/xtables-addons_1.42-1.diff.UQjc1V dpkg-buildpackage: error: dpkg-source -b xtables-addons-1.42 gave error exit status 2 cheers Stuart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666277: build vs build-arch
Hi! This appears to be due to the change from calling debian/rules build to calling debian/rules build-arch. The failure on the buildds in experimental is the same. Running dpkg-buildpackage -B fails -- making the build-arch target depend on the build target would be enough to solve this. happy hunting! Stuart -- Stuart Prescott--www.nanonanonano.net signature.asc Description: This is a digitally signed message part.
Bug#667359: ftbfs with GCC-4.7
Package: rosegarden
The attached patch, grabbed from upstream svn, fixes the FTBFS issue. I've
not had a chance to test the resultant package so this is just to file
the patch for safe-keeping.
Upstream is also heading towards a new release (that will incorporate this
patch), so it's almost worth waiting for that...
Description: fix compilation with gcc-4.7
Many fixes to allow compilation with gcc-4.7
Author: Brendan Jones of Fedora
Origin: upstream svn r12770
Bug-Debian: #667359
--- rosegarden-11.11.42.orig/src/sound/RingBuffer.h
+++ rosegarden-11.11.42/src/sound/RingBuffer.h
@@ -18,6 +18,7 @@
#include sys/types.h
#include sys/mman.h
+#include string.h
#include Scavenger.h
--- rosegarden-11.11.42.orig/src/document/RosegardenDocument.cpp
+++ rosegarden-11.11.42/src/document/RosegardenDocument.cpp
@@ -2359,13 +2359,13 @@ RosegardenDocument::stopRecordingMidi()
++i) {
Segment *s = i-second;
-Segment::iterator i = s-begin();
+Segment::iterator j = s-begin();
-if (i == s-end() || !(*i)-isa(Clef::EventType)) continue;
+if (j == s-end() || !(*j)-isa(Clef::EventType)) continue;
-if ((*i)-getAbsoluteTime() meaningfulBarStart) {
-Event *e = new Event(**i, meaningfulBarStart);
-s-erase(i);
+if ((*j)-getAbsoluteTime() meaningfulBarStart) {
+Event *e = new Event(**j, meaningfulBarStart);
+s-erase(j);
s-insert(e);
}
}
--- rosegarden-11.11.42.orig/src/gui/editors/notation/Inconsistencies.h
+++ rosegarden-11.11.42/src/gui/editors/notation/Inconsistencies.h
@@ -52,11 +52,11 @@ public :
timeT end = comp-getEndMarker();
typename std::maptimeT, OverlapRangeT ::iterator it;
-if (getFirst(start, end, it)) {
+if (this-getFirst(start, end, it)) {
for (;;) {
timeT t1, t2;
-if (!isConsistent(it)) {
-getTimeRange(it, t1, t2);
+if (!this-isConsistent(it)) {
+this-getTimeRange(it, t1, t2);
int bar1 = comp-getBarNumber(t1) + 1;
int bar2 = comp-getBarNumber(t2) + 1;
str += QString(blockquote);
@@ -68,18 +68,18 @@ public :
}
str += QString(blockquote);
-const std::vectorSegment * *s = getSegments(it);
+const std::vectorSegment * *s = this-getSegments(it);
std::vectorSegment *::const_iterator sit;
for (sit = s-begin(); sit != s-end(); ++sit) {
if (sit != s-begin()) str += QString(br);
T pr = OverlapsT::getPropertyAtTime(*sit, t1);
str+= segLine
.arg(QString::fromStdString((*sit)-getLabel()))
- .arg(getTranslatedName(pr));
+ .arg(this-getTranslatedName(pr));
}
str += QString(/blockquote/blockquote);
}
-if (!getNext(end, it)) break;
+if (!this-getNext(end, it)) break;
}
}
}
--- rosegarden-11.11.42.orig/src/gui/studio/AudioPluginOSCGUIManager.cpp
+++ rosegarden-11.11.42/src/gui/studio/AudioPluginOSCGUIManager.cpp
@@ -37,7 +37,7 @@
#include QString
#include lo/lo.h
-
+#include unistd.h
namespace Rosegarden
{
--- rosegarden-11.11.42.orig/src/gui/application/LircClient.cpp
+++ rosegarden-11.11.42/src/gui/application/LircClient.cpp
@@ -29,6 +29,7 @@
#include QSocketNotifier
#include fcntl.h
#include cstdlib
+#include unistd.h
namespace Rosegarden
{
--- rosegarden-11.11.42.orig/src/gui/application/LircCommander.cpp
+++ rosegarden-11.11.42/src/gui/application/LircCommander.cpp
@@ -31,7 +31,7 @@
#include document/CommandHistory.h
#include QObject
-
+#include unistd.h
namespace Rosegarden
{
--- rosegarden-11.11.42.orig/src/gui/application/main.cpp
+++ rosegarden-11.11.42/src/gui/application/main.cpp
@@ -49,6 +49,7 @@
#include QStringList
#include sys/time.h
+#include unistd.h
using namespace Rosegarden;
--- rosegarden-11.11.42.orig/src/base/Sets.h
+++ rosegarden-11.11.42/src/base/Sets.h
@@ -349,7 +349,7 @@ AbstractSetElement, Container::initial
m_final = m_baseIterator;
sample(m_baseIterator, true);
-if (getAsEvent(m_baseIterator)-isa(Note::EventType)) {
+if (AbstractSet::getAsEvent(m_baseIterator)-isa(Note::EventType)) {
m_initialNote = m_baseIterator;
m_finalNote = m_baseIterator;
}
@@ -362,7 +362,7 @@ AbstractSetElement, Container::initial
for (i = j = m_baseIterator; i != getContainer().begin() test(--j); i = j){
if (sample(j, false)) {
m_initial = j;
-if (getAsEvent(j)-isa(Note::EventType)) {
+if
Bug#670061: src:xpra: Needs versioned build-depends on cython (requires 0.14.0 or later)
Package: src:xpra Version: 0.1.0.1+dfsg-1 Severity: normal Hi! When trying to build a backport of xpra 0.1.0.1+dfsg-1 in a squeeze environment, the build failed with the following error: dh clean --with python2 dh_testdir dh_auto_clean ERROR: Your version of Cython is too old to build this package You have version 0.12.1 Please upgrade to Cython 0.14.0 or better dh_auto_clean: python2.5 setup.py clean -a returned exit code 1 make: *** [clean] Error 1 dpkg-buildpackage: error: debian/rules clean gave error exit status 2 It would be appropriate to declare a versioned build-dependency on cython so that backporters will pick up the cython version from squeeze-backports rather than the older version in squeeze. thanks! Stuart -- System Information: Debian Release: 6.0.4 APT prefers stable-updates APT policy: (550, 'stable-updates'), (550, 'proposed-updates'), (550, 'stable'), (60, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686-bigmem (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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667826: reassign back to ktikz
reassign 667826 ktikz forcemerge 669506 667826 tags 669506 + pending thanks ktikz on mentors.debian.net has the updated Build-depend on libmagickcore- extra instead of libmagickcore4-extra -- Stuart Prescott--www.nanonanonano.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666161: psi: FTBFS if built twice in a row
Source: psi Version: 0.14-2 Severity: important User: debian...@lists.debian.org Usertags: qa-doublebuild Hi! When building the psi package twice in a row, the second build fails with the following error: dpkg-source -b psi-0.14 dpkg-source: warning: no source format specified in debian/source/format, see dpkg-source(1) dpkg-source: info: using source format `1.0' dpkg-source: info: building psi using existing psi_0.14.orig.tar.gz dpkg-source: info: building psi in psi_0.14-2.diff.gz dpkg-source: error: cannot represent change to psi-0.14/iris/lib/libirisnet.a: binary file contents changed dpkg-source: error: cannot represent change to psi-0.14/iris/lib/libiris.a: binary file contents changed dpkg-source: warning: the diff modifies the following upstream files: README.Debian README.chinese_fonts iris/conf.pri iris/lib/libiris.prl iris/lib/libirisnet.prl iris/src/xmpp/xmpp-im/xmpp_task.cpp psi.1 psi.xpm src/msgmle.cpp src/src.pro dpkg-source: info: use the '3.0 (quilt)' format to have separate and documented changes to upstream files, see dpkg-source(1) dpkg-source: unrepresentable changes to source dpkg-buildpackage: error: dpkg-source -b psi-0.14 gave error exit status 1 It looks like the clean target needs to get rid of those .a files too. regards Stuart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657499: python-django-djblets and pootle
Hi Dmitry! It's great to see that you're looking at packaging these modules. For purely historical reasons, they are currently sitting as embedded copies in our pootle packages that we will hopefully upload to unstable soon. When your packages are ready, we can have the pootle package depend on them instead of using the embedded copies. Our current djblets are in http://anonscm.debian.org/viewvc/debian- l10n/pootle/trunk/external_apps/djblets/ If I can be of assistance with this packaging, please feel free to contact me. regards Stuart -- Stuart Prescott--www.nanonanonano.net signature.asc Description: This is a digitally signed message part.
Bug#658621: translate-toolkit: pocommon.py raises UnicodeEncodeError on UTF-8 encoded translator comments
Package: translate-toolkit
Version: 1.9.0-1
Severity: normal
Tags: upstream patch
Hi!
The translate-toolkit's po reading code ends up choking on translator
comments that are UTF-8 encoded. A fix for the issue has been committed to
upstream svn but there is no ETA for a release of the next version.
http://bugs.locamotion.org/show_bug.cgi?id=1951
Several of the example terminology files shipped with pootle include problematic
translator comments hence fixing this is a pre-requisite to being able to ship
a pootle package.
The attached patch backports this fix to the translate-toolkit currently
in Debian. I have been using a package containing this patch in testing out
the current pootle packaging.
cheers
Stuart
Description: Handle errors in the po encoding
Origin:
http://translate.svn.sourceforge.net/viewvc/translate/src/trunk/translate/storage/pocommon.py?view=patchr1=17737r2=17736pathrev=17737
Bug: http://bugs.locamotion.org/show_bug.cgi?id=1951
Author: Stuart Prescott stuart+deb...@nanonanonano.net
Based on patch applied to upstream svn and shouldn't be needed in the release
following 1.9.0.
--- a/translate/storage/pocommon.py
+++ b/translate/storage/pocommon.py
@@ -47,7 +47,12 @@
def unquote_plus(text):
unquote('%7e/abc+def') - '~/abc def'
-return urllib.unquote_plus(text).decode('utf-8')
+try:
+return urllib.unquote_plus(text).decode('utf-8')
+except UnicodeEncodeError, e:
+# for some reason there is a non-ascii character here. Let's assume it
+# is already unicode (because of originally decoding the file)
+return text
class pounit(base.TranslationUnit):
Bug#657499: RFP: pootle -- Web-based translation and translation management tool
Dear Martin, I'm glad to find more DDs interested in Pootle. There is indeed activity aimed at getting pootle back into debian: http://lists.alioth.debian.org/pipermail/debian-l10n-devel/2011- November/001463.html I think what the packages need at this stage is testing (in particular, upgrade testing). If you're in a position to help with that, then that would be wonderful. cheers Stuart -- Stuart Prescott--www.nanonanonano.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652925: encourage use of smtphost reportbug.debian.org especially for novice users
Package: reportbug Version: 4.12.6 Severity: wishlist Hi! We frequently see problems in #debian where the user has tried to send a bug report with reportbug but it has never arrived. Invariably, it's sitting in their local mail spool as they have a minimally configured exim4 from install time. reportbug asks: | Do you have a mail transport agent (MTA) like Exim, Postfix or SSMTP configured on this | computer to send mail to the Internet? [Y|n|q|?]? well... no idea, I guess the defaults are sane is a pretty common answer to that. But of course the default install doesn't give you a working smtp server like this so the user is left high and dry. Should the default answer to that question (and also the subsequent one on whether to use reportbug.debian.org as the submission host) be set up so that, at least in novice mode, the user will actually end up with a working reportbug? Actually, I'd argue that using reportbug.debian.org is a sane default for any user, given that if you're on a machine that is indeed configured for internet mail then the local user is likely to know that fact so can answer accordingly. Moreover, accidentally using reportbug.debian.org instead of your local MTA is less likely to be a problem (and is a more minor problem) than the other way around. cheers Stuart -- System Information: Debian Release: 6.0.3 APT prefers stable-updates APT policy: (550, 'stable-updates'), (550, 'stable'), (101, 'proposed-updates'), (60, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686-bigmem (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 reportbug depends on: ii apt0.8.10.3+squeeze1 Advanced front-end for dpkg ii python 2.6.6-3+squeeze6 interactive high-level object-orie ii python-reportbug 4.12.6Python modules for interacting wit reportbug recommends no packages. Versions of packages reportbug suggests: ii debconf-utils1.5.36.1debconf utilities ii debsums 2.0.48+nmu3 tool for verification of installed ii dlocate 1.02fast alternative to dpkg -L and dp pn emacs22-bin-common | none (no description available) ii exim44.72-6+squeeze2 metapackage to ease Exim MTA (v4) ii exim4-daemon-light [ 4.72-6+squeeze2 lightweight Exim MTA (v4) daemon ii file 5.04-5 Determines file type using magic ii gnupg1.4.10-4GNU privacy guard - a free PGP rep ii python-gtk2 2.17.0-4Python bindings for the GTK+ widge pn python-gtkspell none (no description available) pn python-urwid none (no description available) pn python-vte none (no description available) ii xdg-utils1.0.2+cvs20100307-2 desktop integration utilities from -- 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#632722: Reassign to openjdk; mark as fixed
reassign 632722 openjdk-6-jre 6b18-1.8.7-2~squeeze1 fixed 632722 6b23~pre10-1 affects 632722 latexdraw close 632722 thanks Dear Boris, As noted by Arno (who is the upstream developer of LaTeXDraw), this is an openjdk bug -- one that has now been fixed in wheezy/sid. If you're using squeeze, your only sensible option to work around this bug is to use the non- free sun-java6-jre instead of openjdk. thanks for drawing our attention to this regards Stuart -- Stuart Prescott--www.nanonanonano.net signature.asc Description: This is a digitally signed message part.
Bug#640817: plasma-widget-networkmanagement: signal user that kded must reload networking component
Package: plasma-widget-networkmanagement Version: 0.1+git20110422.810bc16-1~bpo60+1 Severity: minor To summarise discussion on #debian-qt-kde: Upgrading from the squeeze n-m packages to the pnm package in backports leaves the kde networking subsystem in a confused state, at least with respect to wireless connections. This will also happen with squeeze-wheezy and even for upgrades within wheezy and sid as time goes on. The user apparently needs know that they should either: * qdbus org.kde.kded /kded unloadModule networkmanagement; qdbus org.kde.kded /kded loadModule networkmanagement * reload the networking component in system settings * log out / log back in * reboot It would be much nicer for the user if one of the following happened instead: * user session notices that networking components/pnm/n-m have been upgraded and reloads them * postinst notifies user sessions over dbus that upgrades have happened and user session reloads them * postinst tells user they should log out/log in * postinst tells user they should reboot, e.g.: [ -x /usr/share/update-notifier/notify-reboot-required ] /usr/share/update-notifier/notify-reboot-required Complexity vs ease of implementation... cheers Stuart -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (550, 'stable-updates'), (550, 'stable'), (101, 'proposed-updates'), (60, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686-bigmem (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 plasma-widget-networkmanagement depends on: ii kdebase-runtime 4:4.4.5-1 runtime components from the offici ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libkdecore5 4:4.4.5-2+squeeze2 the KDE Platform Core Library ii libkdeui5 4:4.4.5-2+squeeze2 the KDE Platform User Interface Li ii libkio5 4:4.4.5-2+squeeze2 the Network-enabled File Managemen ii libkutils44:4.4.5-2+squeeze2 various utility classes for the KD ii libplasma34:4.4.5-2+squeeze2 the Plasma Library for the KDE Pla ii libqt4-dbus 4:4.6.3-4+squeeze1 Qt 4 D-Bus module ii libqt4-network4:4.6.3-4+squeeze1 Qt 4 network module ii libqt4-svg4:4.6.3-4+squeeze1 Qt 4 SVG module ii libqt4-xml4:4.6.3-4+squeeze1 Qt 4 XML module ii libqtcore44:4.6.3-4+squeeze1 Qt 4 core module ii libqtgui4 4:4.6.3-4+squeeze1 Qt 4 GUI module ii libsolid4 4:4.4.5-2+squeeze2 Solid Library for KDE Platform ii libsolidcontrol4 4:4.4.5-7+squeeze1 library for Solid based network ma ii libstdc++64.4.5-8The GNU Standard C++ Library v3 ii mobile-broadband-prov 20101106-1 database of mobile broadband servi ii network-manager 0.8.4.0-2~bpo60+1 network management framework (daem Versions of packages plasma-widget-networkmanagement recommends: ii kwalletmanager4:4.4.5-1 secure password wallet manager ii network-manager-openvpn 0.8.1-1network management framework (Open ii network-manager-pptp 0.8.1-1network management framework (PPTP ii network-manager-vpnc 0.8.1-1network management framework (VPNC Versions of packages plasma-widget-networkmanagement suggests: ii kdebase-workspace-bin 4:4.4.5-7+squeeze1 core binaries for the KDE Plasma W -- 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#632684: pastebinit: empty URL
Hi! Since November 2010, paste.debian.net has enforced a 2 or 3-line minimum on pastes to stop spammers. This is actually returned to XML-RPC clients and also to web-users but the error message (and the fact that the paste failed) is ignored by pastebinit. This means that (date; echo; echo) | pastebinit -b http://paste.debian.net works just fine, while date | pastebinit -b http://paste.debian.net will fail without a useful error message to the user. I doubt that Sary's Xorg.0.log file was empty (although that's possible), so it's more likely that it exceeded the 90kB limit of paste.debian.net. Rolf, a couple of things come out of this -- * pastebinit could either pad pastes that are too short with a couple of lines, tell the user in advance that there's a minimum paste length (or both). It could conceivably also tell users in advance that pastes are too long. * ignoring the return information/failures is a separate bug (perhaps you could forward that upstream if you can't see where to fix it yourself) cheers Stuart (and thanks to formerer on #debian-devel for some information on what is happening here) -- Stuart Prescott--www.nanonanonano.net signature.asc Description: This is a digitally signed message part.
Bug#634407: pyx: FTBFS: Queue.full exception
reassign 634407 texlive-binaries forcemerge 633011 634407 thanks Building with texlive-bin packages 2009-8+b1 on amd64 leads to this FTBFS, building with 2009-9 completes just fine; as such, I'm merging (and hence closing) this bug. Julian, thanks for your analysis and the hint about this texlive-binaries problem. PyX can actually call either tex or latex depending on how it is used. cheers Stuart -- Stuart Prescott--www.nanonanonano.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633645: apt-listchanges: New users are finding (END) from less confusing
Package: apt-listchanges
Version: 2.85.7+squeeze1
Severity: normal
Tags: patch
Hi!
Now that apt-listchanges is priority standard, it's installed on a lot more
systems. New users seem not to understand that the information is being shown
to them in the less program (in the default configuration) and even if they
did they do understand that much, they don't necessarily know how to exit less.
We're seen this quite a number of times in #debian over the last few months
where users ask questions like:
user How do I make Christian Perrier go away?
(that one took us a while to work out... the user was stuck in apt-listchanges
following an update to the samba package).
And again today, a user was saying that aptitude install didn't want to do
anything and the pastebin of the session showed it going as far as
Reading changelogs... Done. When asked what happened after that, he said
nothing. Not knowing how to exit the pager, he was closing that terminal
window meaning that aptitude never actually did the things it was supposed to
do.
The attached (quite trivial) patch tries to make this situation a little better.
If pager is to be used and if LESS is not defined in the environment already
(a user who can set LESS can work out what (END) means themselves), it fiddles
with LESS to make the final prompt a little more intuitive. This covers the
default install situation where frontend=pager and pager-less. Perhaps
different words would be better, perhaps adding it to the xterm-pager code
would be appropriate too (although if you're reconfiguring apt-listchanges,
perhaps you know what less is already), perhaps it could do with some i18n/l10n.
If you think a small patch like this is acceptable for apt-listchanges, it would
be great to see if the SRMs would be prepared to accept it into squeeze at a
future point release since it is affecting stable users.
thanks!
Stuart
-- System Information:
Debian Release: 6.0.2
APT prefers stable
APT policy: (500, 'stable'), (500, 'stable-updates'), (101,
'proposed-updates'), (60, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.38-2-686-bigmem (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 apt-listchanges depends on:
ii apt 0.8.10.3+squeeze1 Advanced front-end for dpkg
ii debconf [debconf-2.0] 1.5.36.1 Debian configuration management sy
ii debianutils 3.4Miscellaneous utilities specific t
ii python2.6.6-3+squeeze6 interactive high-level object-orie
ii python-apt0.7.100.1+squeeze1 Python interface to libapt-pkg
ii python-support1.0.10 automated rebuilding support for P
ii ucf 3.0025+nmu1Update Configuration File: preserv
Versions of packages apt-listchanges recommends:
ii exim44.72-6+squeeze2 metapackage to ease Exim MTA (v4)
ii exim4-daemon-light [mail 4.72-6+squeeze2 lightweight Exim MTA (v4) daemon
Versions of packages apt-listchanges suggests:
ii iceweasel [www-browser]5.0-1~bpo60+1 Web browser based on Firefox
ii konqueror [www-browser]4:4.4.5-2 advanced file manager, web browser
ii konsole [x-terminal-emulat 4:4.4.5-2 X terminal emulator
ii lynx-cur [www-browser] 2.8.8dev.5-1 Text-mode WWW Browser with NLS sup
ii python-glade2 2.17.0-4 GTK+ bindings: Glade support
ii python-gtk22.17.0-4 Python bindings for the GTK+ widge
ii w3m [www-browser] 0.5.2-9 WWW browsable pager with excellent
ii xterm [x-terminal-emulator 261-1 X terminal emulator
-- debconf information:
apt-listchanges/confirm: false
apt-listchanges/which: news
apt-listchanges/frontend: pager
apt-listchanges/email-address: root
apt-listchanges/save-seen: true
--- apt_listchanges.py.orig 2011-07-12 10:39:53.171591784 +0100
+++ apt_listchanges.py 2011-07-12 10:45:17.364029925 +0100
@@ -249,4 +249,6 @@
class pager(runcommand, ttyconfirm, fancyprogress, frontend):
def __init__(self, *args):
+if not 'LESS' in os.environ:
+os.environ['LESS'] = -P?e(q to quit)
apply(frontend.__init__, [self] + list(args))
self.command = self.config.get('pager', 'sensible-pager')
Bug#628174: debian-policy: Link §7.1 (relationship fields) to §11.1 architecture specification strings
Package: debian-policy Version: 3.9.2.0 Severity: normal Currently, §7.1 refers to the archtecture restriction syntax and architecture wildards without defining what the syntax for these restrictions is. The syntax for these clauses is defined in §11.1 (§11.1.1 in particular) but is not linked to from §7.1. It is also perhaps somewhat odd that the syntax for architecture restrictions lives in §11 at all, given the rest of the relationship definitions is in §7 and the control file syntax definition is in §5. cheers Stuart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627171: texlive-binaries: mktexpk (and mktexnam) don't cope with unset $HOME
Package: texlive-binaries Version: 2009-8 Severity: wishlist Hi! Some buildds now have $HOME unset and this leads to breakages in the compilation of various bits of documentation on the buildd; it may be a combination of reduced permissions on the buildd as well as $HOME being unset that causes font selection problems. On buildds where $HOME is defined, when using latex and then dvips, a warning is emitted, but font selection works fine, falling back to /tmp: -- 8 -- kpathsea: Running mktexpk --mfmode ljfour --bdpi 600 --mag 1+264/600 --dpi 864 bbding10 mkdir: cannot create directory `././home/buildd': Permission denied mktexpk: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1+264/600; nonstopmode; input bbding10 mktexpk: /tmp/texfonts/pk/ljfour/public/bbding/bbding10.864pk: successfully generated. -- 8 -- On buildds where $HOME is not defined, the same situation leads to an unwanted font substitution: -- 8 -- kpathsea: Running mktexpk --mfmode ljfour --bdpi 600 --mag 1+264/600 --dpi 864 bbding10 mkdir: cannot create directory `././.texmf-var': Permission denied mktexpk: /usr/share/texmf/web2c/mktexdir /.texmf-var/fonts/pk/ljfour/public/bbding failed. kpathsea: Appending font creation commands to missfont.log. dvips: Font bbding10 not found, using cmr10 instead. -- 8 -- In the case where pdflatex is used, font substitution leads to an error: -- 8 -- kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+264/600 --dpi 864 bbding10 mkdir: cannot create directory `././.texmf-var': Permission denied mktexpk: /usr/share/texmf/web2c/mktexdir /.texmf-var/fonts/pk/ljfour/public/bbding failed. kpathsea: Appending font creation commands to missfont.log. LaTeX Font Warning: Some font shapes were not available, defaults substituted. (see the transcript file for additional information) !pdfTeX error: pdflatex (file bbding10): Font bbding10 at 864 not found == Fatal error occurred, no output PDF file produced! -- 8 -- It's possible to work around this by creating a writable directory in debian/rules and then exporting HOME pointing to that directory prior to commencing the build. Doing so causes the following files to be created when building the documents shown above: -- 8 -- ..texmf-var/fonts ..texmf-var/fonts/pk ..texmf-var/fonts/pk/ljfour ..texmf-var/fonts/pk/ljfour/public ..texmf-var/fonts/pk/ljfour/public/bbding ..texmf-var/fonts/pk/ljfour/public/bbding/bbding10.864pk -- 8 -- For reference, these logs come from the buildd failures of pyxplot 0.8.4-2 when building the documentation; while the documentation ends up in an arch:all package, building it also acts as a test suite. The complete logs are available at: https://buildd.debian.org/status/logs.php?pkg=pyxplotver=0.8.4-2 While this problem is clearly quite unlikely to ever hit a regular user of latex or pdflatex, it's a nuisance on the buildds (and quite hard to debug too), so better handling of this situation would be great. many thanks Stuart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617420: googleearth-package: Please specify an Installed-Size field in the created googleearth package
Package: googleearth-package Version: 0.6.1 Severity: wishlist The lack of an Installed-Size header in the created package means that the googleearth package won't correctly appear in the output of things like dpigs. It also accidentally breaks other tools that naively try to process the output of tools like grep-status. cheers Stuart -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (550, 'stable'), (500, 'squeeze-updates'), (101, 'proposed-updates'), (60, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.37-1-686-bigmem (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 googleearth-package depends on: ii bzip2 1.0.5-6high-quality block-sorting file co ii curl 7.21.0-1 Get a file from an HTTP, HTTPS or ii dpkg-dev 1.15.8.10 Debian package development tools ii fakeroot 1.14.4-1 Gives a fake root environment ii file 5.04-5 Determines file type using magic ii wget 1.12-2.1 retrieves files from the web ii x11-common1:7.5+8X Window System (X.Org) infrastruc ii x11-utils 7.5+4 X11 utilities googleearth-package recommends no packages. googleearth-package 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#612116: Show download links for oldstable on Getting Debian page
Hi! Since the release of squeeze and deployment of the shiny new website, a FAQ on #debian has been where can I find lenny iso images. While stable is the thing we want to offer people most easily, these are normally people who want oldstable for a specific purpose (usually to do a test install of lenny so they can then practice lenny-squeeze on a test server or VM prior to doing it on hardware they depend upon.) I had to do a fair amount of hunting on the website to find links to them (as opposed to just knowing where they were...). Is it feasible to provide a link to older releases or similar from the Getting Debian page so that when people click Getting Debian they can actually end up at http://www.debian.org/releases/lenny/debian-installer/ more easily? While we're re-imagining the download pages, a couple of other points that come up semi-regularly on #debian: * where are the md5sum (sha*sum etc) files for the ISO images? Reason: they're in the same directory, but they're not linked to from the download pages. * zomg there are so many CDs which one do I need? (variations: what's the kde cd, what's the netinst etc) Reason: users are ending up at http://cdimage.debian.org/debian- cd/6.0.0/i386/iso-cd/ or mirrors just by browsing through the mirror structure or directly from searching. These pages give no context to the files that are in there. Can we put a README or HEADER in there (if we can assume that style of index generation) that at least directs people to the Getting Debian page for more details or preferably also describes what is in each CD set. This should be propagated to the mirrors too, obviously. cheers Stuart -- Stuart Prescott--www.nanonanonano.net signature.asc Description: This is a digitally signed message part.
Bug#613062: rarian-compat: Please include man pages
Package: rarian-compat Version: 0.8.1-5 Severity: wishlist rarian-compat doesn't include man pages for the following: /usr/bin/rarian-sk-get-content-list /usr/bin/rarian-sk-get-extended-content-list /usr/bin/rarian-sk-migrate /usr/bin/rarian-sk-update /usr/bin/rarian-sk-gen-uuid /usr/bin/rarian-sk-config /usr/bin/rarian-sk-rebuild /usr/bin/rarian-example /usr/bin/rarian-sk-get-cl /usr/bin/rarian-sk-install /usr/bin/rarian-sk-preinstall /usr/bin/rarian-sk-extract /usr/bin/rarian-sk-get-scripts It would be much easier to read some documentation rather than wade through either scripts or source code to figure out what they do and how. The package's README.gz file defines many of these programs in terms of the previous scrollkeeper equivalent; documentation for the scrollkeeper programs is of course no longer available (if it ever existed). cheers Stuart -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (550, 'stable'), (500, 'squeeze-updates'), (60, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.37-trunk-686-bigmem (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 rarian-compat depends on: ii docbook-xml 4.5-7 standard XML documentation system ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii librarian00.8.1-5Documentation meta-data library (l ii libstdc++64.4.5-8The GNU Standard C++ Library v3 ii xml-core 0.13 XML infrastructure and XML catalog rarian-compat recommends no packages. rarian-compat 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#612772: www.debian.org: packages.debian.org footer overlaps with right sidebar links
Package: www.debian.org Severity: minor The footer on the packages.debian.org package pages (containing the language selector and contact details) overlaps the package links bar that runs down the right side of the page. This causes the background of the right side bar to change towards the bottom, package names in the similar packages list might get a line through them (the border to the footer) and the popup language selector can make clicking on packages in the similar packages list quite hard. Unlike most design issues, this is worse for people with wider windows because the content of the main part gets shorter. The page I noticed this on was particularly bad because it's an arch:all package with few dependencies so the content part of the page is very short: http://packages.debian.org/squeeze/pychecker I also noticed that I'm finding it slower to find the relevant information on this page with the new theme (even though the same information is in the same places!). I don't know if that's just because the page looks different (in which case time will cure this problem) or because the reduction in other visual cues on the page -- the page used to have different a background colour for the bar down the right side that perhaps made that information stand out a bit better. I don't know if doing that would make sense in the new design or not; I'll just pass on this observation. Kudos for the great work! Stuart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612295: Version detection of Jarfile name breaks with suffixes
Hi Moritz, debian/rules currently auto-generates the name of the jar file by parsing debian/changelog: VERSION=$(shell dpkg-parsechangelog | sed -n 's/Version: \(.*\)+[0-9\-]*/\1/p') If you add a suffix, the build fails: [...] excellent point! I've got a little post-squeeze tidying to do on the package anyway so will add that to the todo list. Thanks for your report. regards Stuart -- Stuart Prescott--www.nanonanonano.net signature.asc Description: This is a digitally signed message part.
Bug#610194: Quick way to purge packages
There have been suggestions on d-devel@ of some sort of script to work out what packages need purging. A relatively easy approach is to: aptitude purge '~c' which will purge all removed-but-not-purged packages. One should be careful that this doesn't blow away config files that you actually wanted though -- there's a sound reason for separating package remove and config file removal. aptitude search '~c' will give a list of packages that would be purged. Perhaps §4.1.6 is an appropriate place to put this information. cheers Stuart -- Stuart Prescott--www.nanonanonano.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601219: unblock pyxplot/0.8.3-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear release team,
I think my original request got caught in a race condition between me drafting
it, getting the package uploaded (three weeks ago), letting it age and you
requesting that all unblock requests go via the bts rather than directly to
the mailing list.
My original request was at:
http://lists.debian.org/201010172314.51489.stuart+deb...@nanonanonano.net
but is included below for your convenience. I hope that the extra delay in
making this request via the bts isn't problematic.
many thanks
Stuart
8 ---
Dear release team,
I would like to request a freeze exception for version 0.8.3-1 of pyxplot to
enter squeeze. It is primarily a bugfix release from upstream with a couple
of slight changes to functionality. It would be great if squeeze users could
have 0.8.3 rather than 0.8.2 to both fix these bugs and also to ensure that
documentation on upstream's website is consistent with the behaviour in the
Debian package in the case where functionality has changed. The package has
gracefully aged in unstable for 13 days now.
Thanks in advance for considering!
regards
Stuart
Upstream changelog:
2010 Sep 15: PyXPlot 0.8.3
- @ macro expansion operator implemented.
- assert command implemented.
- for command behaviour changed such that for i=1 to 10 includes a
final
iteration with i=10.
- Point types rearranged into a more logical order.
- Improved support for newer Windows bitmap images.
- Bugfix to the 'set unit preferred' command.
- Binary not operator bugfixed.
- Bugfix to handling of comma-separated horizontal datafiles.
- Mathematical function finite() added.
Debian changelog:
pyxplot (0.8.3-1) unstable; urgency=low
* New upstream (bugfix) release
* Add additional copyright holders to debian/copyright
* Set DM-Upload-Allowed: yes
-- Stuart Prescott stuart+deb...@nanonanonano.net Sun, 03 Oct 2010
13:04:39 +0100
Non-documentation diffstat:
$ debdiff --exclude doc pyxplot_0.8.{2,3}-1.dsc | diffstat
…
28 files changed, 379 insertions(+), 122 deletions(-)
(this would be less if it upstream weren't so keen on $Id$)
--
Stuart Prescott www.nanoNANOnano.net
signature.asc
Description: This is a digitally signed message part.
Bug#600600: upgrade-reports: lenny-squeeze and libuuid-perl (and apt-get vs aptitude)
Package: upgrade-reports
Severity: normal
In a base install of lenny (with only openssh-server added beyond the standard
task), the following is observed when trying to upgrade from lenny to squeeze,
following a procedure that reflects the current state of the release notes.
Of particular note is that libuuid-perl, which is a dependency of linux-base
in squeeze, is not installed at this stage in lenny.
# sed -i 's/lenny/squeeze/;s/^.*volatile/#/' /etc/apt/sources.list
# apt-get update
# aptitude install linux-image-`uname -r | sed 's,[^-]*-[^-]*-,,'`
[...]
The following packages are BROKEN:
perl
The following NEW packages will be installed:
firmware-linux-free{a} libuuid-perl{a} linux-base{a}
linux-image-2.6.32-5-686{a} linux-image-686
The following packages will be upgraded:
libuuid1 perl-base
The following packages are RECOMMENDED but will NOT be installed:
uuid-runtime
2 packages upgraded, 5 newly installed, 0 to remove and 201 not upgraded.
Need to get 28.7MB of archives. After unpacking 78.6MB will be used.
The following packages have unmet dependencies:
perl: Depends: perl-base (= 5.10.0-19lenny2) but 5.10.1-15 is to be installed.
The following actions will resolve these dependencies:
Remove the following packages:
perl
perl-modules
Leave the following dependencies unresolved:
exim4-base recommends perl-modules
Score is -16
Accept this solution? [Y/n/q/?] ^C
Eek! Trying again with apt-get instead:
# apt-get install linux-image-`uname -r | sed 's,[^-]*-[^-]*-,,'`
[...]
The following extra packages will be installed:
firmware-linux-free libdb4.7 libuuid-perl libuuid1 linux-base
linux-image-2.6.32-5-686 perl perl-base perl-modules
Suggested packages:
linux-doc-2.6.32 perl-doc libterm-readline-gnu-perl
libterm-readline-perl-perl make
Recommended packages:
uuid-runtime
The following NEW packages will be installed
firmware-linux-free libdb4.7 libuuid-perl linux-base
linux-image-2.6.32-5-686 linux-image-686
The following packages will be upgraded:
libuuid1 perl perl-base perl-modules
4 upgraded, 6 newly installed, 0 to remove and 199 not upgraded.
Need to get 36.6MB of archives.
After this operation, 81.0MB of additional disk space will be used.
Do you want to continue [Y/n]? ^C
That now looks much nicer and should allow us to upgrade the kernel etc
to do the appropriate udev dance.
A couple of related points:
* upgrading aptitude prior to trying this out doesn't help
* aptitude is capable of doing the right thing here with some prompting:
- say n at the [Y/n/q/?] prompt to get another solution; the 3rd
presented solution is to upgrade perl as well
- or, tell aptitude to install perl at the same time as the kernel:
aptitude install linux-image-`uname -r | sed 's,[^-]*-[^-]*-,,'` perl
* the release notes for squeeze currently say to use lenny's aptitude to
install the squeeze kernel. That seems to be bad advice (use apt-get instead).
* installing lenny's libuuid-perl first is another valid approach to this,
but would require yet another step for the user to perform in the upgrade.
(but this step may possibly be easier than working through a large pile of
perl's rdeps, depending on what sort of versioned-dependencies other complex
sets of packages have on perl or perl modules -- I've not explored under
what circumstances this is actually a problem)
* Users of backports.org kernels will actually have a lot easier time of all
of this because they will already have lenny's libuuid-perl installed and
also a kernel that will work with udev. Telling people to go via the kernel
on backports would a real possibility to all this, but it's a level of
unwelcome complexity.
(thanks to CutMeOwnThroat on #debian for highlighting this problem)
cheers
Stuart
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600600: aptitude vs apt-get with lenny-squeeze
As a follow-up to my earlier tests, if you hit aptitude over the head to force
its resolver to behave more safely on package installation, then the first
thing it offers to do is fine.
Having reverted the VM used in the earlier tests to a lenny snapshot:
# aptitude --safe-resolver install linux-image-`uname -r | sed 's,
[^-]*-[^-]*-,,'`
The following NEW packages will be installed:
firmware-linux-free{a} libdb4.7{a} libuuid-perl{a} linux-base{a}
linux-image-2.6.32-5-686{a} linux-image-686
The following packages will be upgraded:
libuuid1 perl perl-base perl-modules
The following packages are RECOMMENDED but will NOT be installed:
uuid-runtime
4 packages upgraded, 6 newly installed, 0 to remove and 199 not upgraded.
Need to get 36.6MB of archives. After unpacking 81.0MB will be used.
Do you want to continue? [Y/n/?]
which is exactly what is wanted. The same behaviour is seen with both the
lenny and squeeze versions of aptitude.
Presumably the same could be achieved by fiddling with aptitude's scores or
levels until it did the right thing with whatever resolver it is using for an
install request.
regards
Stuart
(who wonders if he should clone this bug over to aptitude too...)
--
Stuart Prescott www.nanoNANOnano.net
signature.asc
Description: This is a digitally signed message part.
Bug#597923: rubber: fix for md5 deprecation warning broken
Package: rubber
Version: 1.1-2.3
Severity: important
Tags: patch
When rubber tries to take the md5 of files, it now crashes (it used to issue
a DeprecationWarning).
test.tex: - 8 --
\documentclass{article}
\begin{document}
test
\end{document}
8 --
$ rubber test.tex
compiling test.tex...
Traceback (most recent call last):
File /usr/bin/rubber, line 9, in module
sys.exit(Main()(sys.argv[1:]))
File /usr/share/rubber/rubber/cmdline.py, line 296, in __call__
return self.main(cmdline)
File /usr/share/rubber/rubber/cmdline.py, line 260, in main
ret = env.final.make(self.force)
File /usr/share/rubber/rubber/__init__.py, line 237, in make
ret = self.run()
File /usr/share/rubber/rubber/rules/latex/__init__.py, line 1223, in run
if self.compile(): return 1
File /usr/share/rubber/rubber/rules/latex/__init__.py, line 1129, in compile
self.aux_md5[aux] = md5_file(aux)
File /usr/share/rubber/rubber/util.py, line 22, in md5_file
m = md5.new()
AttributeError: 'builtin_function_or_method' object has no attribute 'new'
The attached (trivial) patch finishes the conversion to hashlib.
cheers
Stuart
diff -U2 -r rubber-1.1-old/src/util.py rubber-1.1/src/util.py
--- rubber-1.1-old/src/util.py 2010-09-24 10:47:49.0 +0100
+++ rubber-1.1/src/util.py 2010-09-24 10:46:01.0 +0100
@@ -20,5 +20,5 @@
Compute the MD5 sum of a given file.
- m = md5.new()
+ m = md5()
file = open(fname)
for line in file.readlines():
Bug#597408: debian-maintainers: Please add Stuart Prescott as a Debian Maintainer
Package: debian-maintainers -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Please add Stuart Prescott stuart+deb...@nanonanonano.net to the Debian Maintainer keyring. many thanks Stuart -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkyWEUIACgkQn+i4zXHF0agViQCePAS9G0nSiDyNpFeGtKCabVmd oQUAnjgJJhjpFxOeKPAw28WCDqjZhvvr =ekev -END PGP SIGNATURE- Comment: Add Stuart Prescott stuart+deb...@nanonanonano.net as a Debian Maintainer Date: Wed, 15 Sep 2010 23:36:39 +0100 Action: import Recommended-By: Mike O'Connor s...@debian.org, Alan Woodland awoodl...@debian.org, Vincent Fourmond fourm...@debian.org Agreement: http://lists.debian.org/debian-newmaint/2010/09/msg00025.html Advocates: http://lists.debian.org/debian-newmaint/2010/09/msg00026.html http://lists.debian.org/debian-newmaint/2010/09/msg00028.html http://lists.debian.org/debian-newmaint/2010/09/msg00041.html Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (GNU/Linux) mQGiBECQZY8RBADHwNNVQ4p+sdy7USQe398vQvani3QQmbPCg8i2PPWZEeugVHMd INe5mysYQOnwtmzDZFX3Cqjb/pdYGtWkOTFRtC328Y4Fg3or85vhD77r/AWOECQq y52GMAQcE+qoB/ZIS4lqVdTvW3NnDH/GC/KJXfhRh6vSeTzIryurWA8zpwCg3VTX eRZWyEQUX5RwgQ63qjBvIZkD/1BuB3JTip8BxcKUhEyPu/eSlFaVJJ9uMNgZN0GZ ZPyRhOV7c328CdtjKBj4mi0x/lO+qyJmORx3o54cNj6FnwiSFh9pragPS1XGih+u KZ+vkMGThkJvESdQCy6tjTz6X9QROjoIeG/qQYjNlTBM2Yil5h4R3eRRNQkzW4AJ nUkMA/9bQvIaMCN2AykQ6nvfckVa7DOKQm74+cRIqbttxSM4aiLv7T97YGheHoQt efmbSWLJGpV64NfC7mQSNaNkjBhwzDBs8Rn1GwIQ+6i6pVrVVXlSNH3MrVGncOMr EwbJ5oqaYJDDLObwutdfBoQtffL6K0ehZa7AJ2HUHhY2eIMzxrQpU3R1YXJ0IFBy ZXNjb3R0IDxzdHVhcnRAbmFub25hbm9uYW5vLm5ldD6IYAQTEQIAIAUCRye9mQIb IwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEJ/ouM1xxdGoVp4An1+mVHJYzsFJ eMRWJAPcqwkAz4D9AKCGcZCQjaCXzl2JvQ4pVfHYlJ3x3YhgBBMRAgAgAhsjBgsJ CAcDAgQVAggDBBYCAwECHgECF4AFAkSP5B0ACgkQn+i4zXHF0aiFIACePxZbsGcC FOmXyih46SdKLlsqVZkAnAq41JbE83xvmf7a+nhQ6/Lx1zxHiGAEExECACACGyMG CwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCRI/kDgAKCRCf6LjNccXRqAeuAJ0TmhsJ hZrPYTmYJoJa8Gpna8tIywCgzoKr2RCOqf6A066urE6909KqfxGIRgQQEQIABgUC SkkWbAAKCRDnTSm4K+FtAfkzAKCkzXDh9DQNrx9ef+pZUEhJ/TpUcACfQRwgWj/r cHB1nVWF65yaCPzpQTWIWwQTEQIAGwUCQJBljwYLCQgHAwIDFQIDAxYCAQIeAQIX gAAKCRCf6LjNccXRqPbHAJ9Qyb1m6D9ELP7lQcMbTf3c4eZ1lgCeInTJhVx8L8+r VkkYx/F+ja3ItOyIWwQTEQIAGwYLCQgHAwIDFQIDAxYCAQIeAQIXgAUCRI/kHQAK CRCf6LjNccXRqJZMAKCJCGZzFkl6Jej/o7XfTi/cnQXWYACdEODRFg5RREwU1fNC ScexrMdA4cKIYQQTEQIAIQYLCQgHAwIDFQIDAxYCAQIeAQIXgAUCRI6K0wUJBkjQ xAAKCRCf6LjNccXRqB8OAJ9YduZZKkYot3wV9PVX6n21zlHSuwCfRNMg6AOaf7d8 KgAtiTHoXyFsGfSIYwQTEQIAIwIbIwYLCQgHAwIEFQIIAwQWAgMBAh4BAheABQJH J8UuAhkBAAoJEJ/ouM1xxdGo12kAn1o2eaYr5ZdeAbx/XjfRGEhYqqC3AJ95Y7WM 2tDrIMmRsRYIlGvMhNYM5ohkBBMRAgAkAhsjAh4BAheAAhkBBQJKFCrABQsJCAcD BRUKCQgLBRYCAwEAAAoJEJ/ouM1xxdGordoAoMW/ljqTjvwXjVr1potjBW/SySrU AKC5jkJ38/ORpHW0zmSVDjohMcHFqYhmBBMRAgAmBQJEjoynAhsjBQkGSNDEBgsJ CAcDAgQVAggDBBYCAwECHgECF4AACgkQn+i4zXHF0aijQwCgv0ffpbYbibGa6jC9 5zqruuG2Ph8AoI0qN7ZvUlG8I9p/VrKns0J8+8+KiQEcBBABAgAGBQJL0wFFAAoJ EMkPnLkOH60Mk7sIAK46jkDTJ+96A0uncgTTTjaTCHfKjb3OUasoYZOTKkA95e09 Vu8XHfgAwwnTEFQm8epcR3QDdBpWz02AUQQKoHuBSCmhuidRWOCdv5hL1uGqeUsj 9Tyz0Ux0WWeJBEuQ7h+TuZM16VumZnprH2rrR9W+jhcQ7z08JEdukZwFh3bfgJtS B9iC6iO96KyauPr49wOeggDO2vqke8DXjcy/2IdF9CaLylFD7mLdrzEsgP9K1M+Z DgwIFsYDLnKtBfZhNsIr/gyYbNcTyNWyXOUxaljHGXSPVvKVoD0QkrZY+sH+NKpw TIi3klSfoGSqfZWK/qVrj/rkw+mfQNDw623CBLKIRgQQEQoABgUCTErcSwAKCRCY dolhntEBv5DkAKDKHMhIFFdoz8oDEdmEG7bd+7s2YgCgl0yRiw1RM/eNO41jxzX5 DDi90F20MFN0dWFydCBQcmVzY290dCA8c3R1YXJ0K2RlYmlhbkBuYW5vbmFub25h bm8ubmV0PohgBBMRAgAgBQJHJ8LlAhsjBgsJCAcDAgQVAggDBBYCAwECHgECF4AA CgkQn+i4zXHF0agSAACfV2M7vZmJTwREkKKGKSoU+xsY9jsAnRsYqbaw5Eihzpzm NDbLgE6E+UTmiEYEEBECAAYFAkpJTuEACgkQ500puCvhbQG1/gCgjlh9QNRsL/Lj 0+lHODVfQDTEyOYAn3Eb/l5qITodVU4FVWTSqgVeU7sUiGEEExECACECGyMCHgEC F4AFAkoUKsYFCwkIBwMFFQoJCAsFFgIDAQAACgkQn+i4zXHF0ailtgCfScoLRfAy jX2FKCxvawhbhqXPaN0AoNTRzFfxWK1Y44C3oa1jgEBPJbNPiQEcBBABAgAGBQJL 0wFFAAoJEMkPnLkOH60M8aMH/j4rG5ZggJZFBf2toZ2Nnci9SOUOxmqI640TJ66g ZVwoU5+XyF172lnssp5E0scotSO8ynl3F1VoH6PIXBLe0eMK80JUK/ZgDC6Y96Gw J7XWuimE/A5wqzDvS8U7KHOhvQIUwxqwDPmQe1aOJiOVDLd8s1xOw8ZSLS727CfU l3TeunrKL4YXjWiTTNobVQkKjO10iTqXYoRJ/BhGqkPLxXygfyCA0aiSXoRZFneM C4JbfDaOFqa4WC0godmCCvFfMl/VEyVGBviozeqdqZW+lt8UKFkH9Ga4AmaRop8X bLASzzfm2ob8vQII2mr3TY4wMSrCBU7gNU+K0ucfzGGIFKOIRgQQEQoABgUCTErc SwAKCRCYdolhntEBv9sAAJ0WAhGUZqk01anphSCz8o/9JgM1qgCeNLh7orgNtWXD DvGnFKWXniru+Cy0L1N0dWFydCBQcmVzY290dCA8c3R1YXJ0LnByZXNjb3R0QGJy aXN0b2wuYWMudWs+iEYEEBECAAYFAkpJFmwACgkQ500puCvhbQEqlACff4AvBZUF sdXqW75HCC2d4CbqfFIAn0HFs9XQWVYZ9ZJwxLdWGKA3pnTTiGAEExECACACGyMG CwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCRI/kDgAKCRCf6LjNccXRqAeuAJ0TmhsJ hZrPYTmYJoJa8Gpna8tIywCgzoKr2RCOqf6A066urE6909KqfxGIYQQTEQIAIQIb IwIeAQIXgAUCShQqxgULCQgHAwUVCgkICwUWAgMBAAAKCRCf6LjNccXRqAEIAJ9h N7Z4FbCYJPePtXN/UWdrR8a3rwCgvaTjg1Vn0V+qpv9Yyj5fQA5kB1aIZgQTEQIA JgUCRI6L+AIbIwUJBkjQxAYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEJ/ouM1x
Bug#546202: levmar package question
Hi! I have indeed done a little work on packaging levmar for debian but my efforts stalled in the following places: * it seems that the upstream developers see levmar as some code you include in some other project not as a shared library. They have at least started providing a so-producing makefile, but I'm not sure how committed to binary compatibility they are. * I wasn't sure that SONAMEs were being bumped correctly and I don't yet know enough about SONAMEs to do this confidently on my own, so it slipped down my priority list somewhat. * I originally thought that there were several users of levmar already in debian but when I went looking there appears to only be one (hugin) which is using a heavily modified, very old internal copy of levmar and the prospects of getting hugin to use a shared library version of levmar seem slim in the short term at least. * I tried to contact the upstream authors of levmar to talk to them about packaging their library and to start developing a working relationship with them but never received a reply to my emails. Having said that, levmar still looks like interesting code and it might be useful to have it in debian anyway, although the general rule that it's not worth packaging a library until there is some other package in debian to use it make me wonder if it's worth it at this stage. Chicken and egg. I'd like to revisit levmar once squeeze is released and see if hugin can start using a newer version of levmar as a shared object instead. I'd be looking for someone with more experience in packaging libraries to help me with this though. cheers Stuart -- Stuart Prescott www.nanoNANOnano.net signature.asc Description: This is a digitally signed message part.
Bug#591538: pyxplot: FTBFS due to latex errors
Hi KiBi, your package FTBFS (apparently reliably) due to latex errors on various architectures, as seen on: https://buildd.debian.org/status/package.php?p=pyxplot this is actually that pyxplot fails to generate valid EPS files on big-endian architectures so the figures are not present when it comes to compiling the manual. So it's not really latex that's failing here but earlier error(s) that disappear into the noise of the build log. I have actually already taken this bug upstream and the iminent 0.8.2 release will fix this problem. (having the build fail earlier at the first error is also on the todo list) thanks for making sure it was on my radar Stuart -- Stuart Prescott www.nanoNANOnano.net signature.asc Description: This is a digitally signed message part.
Bug#589696: pyxplot: No plots displayed when X11 terminal is set
Dear Nathan, Thanks for reporting this. in pyxplot, if you set viewer gv and then retry one of your plotting commands, does it then work fine? Thanks, Stuart -- Stuart Prescott www.nanoNANOnano.net ph +44 117 33 18387 fax +44 117 925 0612 signature.asc Description: This is a digitally signed message part.
Bug#586527: addendum to patch
Hi, Looking at Bernd Zeimetz's patch for this, the sed expressions in debian/script.in/nsscheck.sh also need fixing so that apache2 is correctly restarted. (trivial) patch to do this attached. cheers Stuart -- Stuart Prescott www.nanoNANOnano.net --- debian/script.in/nsscheck.sh-orig 2010-06-27 15:16:22.0 +0100 +++ debian/script.in/nsscheck.sh 2010-06-27 15:18:46.0 +0100 @@ -5,4 +5,5 @@ check=$(echo $check | \ sed -e's/\bapache2-common\b/apache2/g' \ + -e's/\bapache2.2-common\b/apache2/g' \ -e's/\bat\b/atd/g' \ -e's/\bdovecot-common\b/dovecot/g' \ signature.asc Description: This is a digitally signed message part.
Bug#578854: New workding for Conflicts, Breaks, and related sections
On Wednesday 16 June 2010 19:07:33 Russ Allbery wrote: + Normally, ttBreaks/tt should be used in conjunction + with ttReplaces/tt.footnote + To see why ttBreaks/tt is required in addition + to ttProvides/tt, consider the ^ + case of a file in the package packagefoo/package being + taken over by the package packagefoo-data/package. + ttReplaces/tt will allow packagefoo-data/package to + be installed and take over that file. However, + without ttBreaks/tt, nothing + requires packagefoo/package to be upgraded to a newer + version that knows it does not include that file and instead + depends on packagefoo-data/package. Nothing would + prevent the new packagefoo-data/package package from + being installed and then removed, removing the file that it + took over from packagefoo/package. After that + operation, the package manager would think the system was in + a consistent state, but the packagefoo/package package + would be missing one of its files. + /footnote Shouldn't this Provides be Replaces? Otherwise, it sounds good to me. It certainly answers my original question that caused me to look at policy (and as in #d-mentors) as well as answering a few others that I didn't even know I should ask before. cheers Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#572253: Should Conflicts be added to the Replaces example for package splitting?
Hi! The discussion for #572253 has resulted in the following inclusion in policy (to be released as 3.8.5): p + For example, if a package packagefoo/package is split + into packagefoo/package and packagefoo-data/package + starting at version 1.2-3, packagefoo-data/package should + have the field + example compact=compact +Replaces: foo (lt;lt; 1.2-3) + /example + in its control file. The package packagefoo/package + doesn't need any special control fields in this example, + although would generally depend on or + recommend packagefoo-data/package. + /p i.e. the example of what to do when you split a package only mentions that foo-data should have a versioned-Replaces on the pre-split packages. The discussion in #578854, however, seems to indicate that the preference is actually to use both a versioned-Replaces _and_ a versioned-Conflicts in this situation. Is my reading of the discussion in #578854 wrong? or would the following be a better example to include? Conflicts: foo ( 1.2-3) Replaces: foo ( 1.2-3) Changing the example to this would mean that the example is in the wrong section and should appear in §7.6.2 not §7.6.1. We're clearly diverging from the original intent of the patch that was applied for #572253 here. I guess this is symptomatic of #578854 where clearer wording for the Conflicts section is discussed. But it looks to me like conflicting advice in #578854 vs #572253 needs to be ironed out in any case. (If I had looked only at policy about how to split a package and not at #578854, what example would I be likely to copy into $package? If I've missed the point of these discussions and these two are _not_ conflicting in their advice, then that's also an indication that the wording really needs to be clarified because they sure look like they do.) It also occurs to me that a concrete example of how to split a package like this is really good to have, but by the time it needs considerable explanation and additional fields added, it may actually start to distract from the purpose of policy and perhaps should be in dev-ref... but that's a completely different discussion again. regards Stuart (Please Cc me as I'm not subscribed to the bugs/lists in question) -- Stuart Prescott www.nanoNANOnano.net signature.asc Description: This is a digitally signed message part.
Bug#585345: pyxplot: Python string exceptions no more allowed in Python 2.6
tags 585345 + pending stop PyXPlot 0.8.1 is soon to be uploaded to Debian. This package is a complete rewrite of PyXPlot in C so python string exceptions will no longer be a problem. -- Stuart Prescott www.nanoNANOnano.net ph +44 117 33 18387 fax +44 117 925 0612 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579603: aptitude: ?archive(now) matches all installed or removed (not purged) packages
Hi Daniel, The string now actually comes directly from apt. I could filter it in search patterns (it's already filtered in various parts of the UI), but I know that people use the aptitude command-line in scripts, and making now no longer match anything would be a backwards-incompatible change. So, +wontfix on that. yes, I found the filtering for now in the source code for the UI parts. I understand not wanting to make a backwards-incompatible change. Perhaps it should be documented for ?archive() in that case to save people spending quite so much time as I did the other day trying to work out why they couldn't negate the match properly. As for the rest of your report, I think that you want a ?downloadable pattern that would apply on a per-version basis, right? I don't think there's really a way to get at that information via the current set of patterns, so a new one would make sense. (it's similar to making ?obsolete check per version, but doesn't break backwards compatibility) Yes! a ?downloadable would be good. I presume it would automatically limit itself to package-versions that are installed and not return all versions of packages like ?installed does. Not limiting itself like that would require the use of ?narrow() all the time, I think. Would it actually make more sense to be in the negated sense already (something like, ?noarchive), since I would imagine that its primary use will be to find things that *aren't* downloadable. ?noarchive looks a lot nicer to deal with than ?not(?downloadable)?installed which I think is assuming that the ?downloadable package-version set would be equal to ?narrow(?version(CURRENT),?downloadable). If it's not, then there would need to be additional ?narrow statements in there somewhere. [or, more likely, I've misunderstood what you're suggesting here] Another option would be to implement an idea I've had for a while, to more fully support more types in the search language. So you'd have something like: ?has-version(?has-archive(?not(?archive(now I know you said something like, but I'm not quite sure how that will work since '?not(?archive(now))' will provide a list of all packages in a p state and not any of the not-downloadable packages. But I can see what you're trying to sketch here. Yes, having the ability to include some sorts of tests in the search language would be nice. Since I presume that these sorts of things won't be available until squeeze+1 at this stage, I'll stick with the monstrosity I included earlier for the time being. I'm sort of glad that there isn't some really easy way to do this that I'd just fundamentally missed. thanks for your thoughts Stuart -- Stuart Prescott www.nanoNANOnano.net signature.asc Description: This is a digitally signed message part.
Bug#579603: aptitude: ?archive(now) matches all installed or removed (not purged) packages
Package: aptitude
Version: 0.4.11.11-1~lenny1
Severity: normal
Short version:
--
aptitude search '?archive(now)'
matches all packages that are in installed or removed (not purged) states.
Naturally,
aptitude search '?archive(foobar)'
matches 0 packages and
aptitude search '?archive(stable)'
matches (most) of the packages on this machine (not backports.org etc).
So it seems that now is a special, undocumented value for the archive
match. I can't see that now would have any use and (as below) it makes life
a little harder than it should be to do things.
Long version:
-
I was trying to be far too clever for my own good with an aptitude search to
find all packages that don't have a current version in a repository. (Note:
this is a different search to ?obsolete, as packages which have either a
newer or older version in any archive are not considered obsolete, even though
the installed version is not available from any archive. I'd be happy to have
my aptitude-fu improved with suggestions on how else to do this, btw)
I was looking at ?archive() as a search term to spot packages that didn't have
an available archive.
In a squeeze chroot, I installed three packages that are not from testing (one
local package, one package from lenny, one package from sid). The search:
aptitude search '?narrow(?archive(testing),?version(CURRENT))'
correctly finds the packages that are installed and currently available from
the testing repo and doesn't list the archive-less test packages.
Hoping to be able to match packages with no archive set, I tried ?archive(^$)
to no avail. I don't know if this is just another manifestation of ?archive(now)
or if there's some other regular expression that should be used.
So let's try negating that to find the package versions that have no repo:
aptitude search '?narrow(?not(?archive(testing)),?version(CURRENT))'
and this correctly lists the three test packages I have in the chroot that are
not from testing (one local package, one package from lenny, one package from
sid).
Now part of the objective here was to write a recipe that would work across all
releases, rather than having to substitute testing in there. This is
particularly relevant for backports.org users as you end up needing:
aptitude search
'?narrow(?not(?archive(~(stable~|lenny-backports~))),?version(CURRENT))'
which is starting to look like line noise, and to write an exhaustive list of
archives would be tedious. But all of these archives are just [a-z]+ as a
regular expression, so this should work:
aptitude search '?narrow(?not(?archive([a-z]+)),?version(CURRENT))'
Except that now also matched [a-z]+ so this search doesn't return anything.
Perhaps one could construct various assertions against now for ?archive():
aptitude search '?narrow(?not(?archive(^[^now]{3}.*$)),?version(CURRENT))'
which works, up to the point where it relies on Debian releases never having
names like bo.
So, working around now seems quite difficult; there's probably an easier way
to achieve this target anyway and I'd be happy to hear suggestions.
cheers
Stuart
-- Package-specific info:
aptitude 0.4.11.11 compiled at Dec 5 2008 02:43:34
Compiler: g++ 4.3.2
Compiled against:
apt version 4.6.0
NCurses version 5.6
libsigc++ version: 2.0.18
Ept support enabled.
Current library versions:
NCurses version: ncurses 5.7.20081213
cwidget version: 0.5.12
Apt version: 4.6.0
linux-gate.so.1 = (0xb7ef3000)
libapt-pkg-libc6.7-6.so.4.6 = /usr/lib/libapt-pkg-libc6.7-6.so.4.6
(0xb7e1a000)
libncursesw.so.5 = /lib/libncursesw.so.5 (0xb7ddc000)
libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0xb7dd5000)
libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0xb7d11000)
libept.so.0 = /usr/lib/libept.so.0 (0xb7c5)
libxapian.so.15 = /usr/lib/libxapian.so.15 (0xb7afa000)
libz.so.1 = /usr/lib/libz.so.1 (0xb7ae5000)
libpthread.so.0 = /lib/i686/cmov/libpthread.so.0 (0xb7acc000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb79dd000)
libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb79b7000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb79aa000)
libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb784f000)
libutil.so.1 = /lib/i686/cmov/libutil.so.1 (0xb784b000)
libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb7846000)
/lib/ld-linux.so.2 (0xb7ef4000)
Terminal: xterm
$DISPLAY is set.
`which aptitude`: /usr/bin/aptitude
aptitude version information:
aptitude linkage:
-- System Information:
Debian Release: 5.0.4
APT prefers stable
APT policy: (900, 'stable'), (60, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages aptitude depends on:
ii apt [libapt-pkg-libc6. 0.7.20.2+lenny1 Advanced front-end for dpkg
ii libc6
Bug#573802: Rosegarden 10,.04
Hi Alf, Well i think its important to go straight to version 10.04, mostly of a serius bug in 10.02 in notations editon. Yes, with today's release of 10.04 (which hasn't actually appeared on the rosegarden website just yet!), we will most likely we will jump to 10.04, yes. I've already started looking at it. There's perhaps some merit in actually uploading 10.02 to let snapshot.debian.org get hold of it -- any opinions? cheers Stuart -- Stuart Prescott www.nanoNANOnano.net ph +44 117 33 18387 fax +44 117 925 0612 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578004: aspline includes duplicate points in output
Package: spline Version: 1.1-11 Severity: important Tags: pending The spline package in squeeze/sid (1.1-14) shows duplicated output on i386: # aptitude install spline=1.1-11 $ echo -e 1\n2\n3\n | aspline -a 1 -n 6 0 1 0.33 1.25926 0.67 1.74074 1 2 1.3 2.18519 1.7 2.59259 # aptitude install spline=1.1-14 $ echo -e 1\n2\n3\n | aspline -a 1 -n 6 0 1 0.33 1.25926 0.67 1.74074 1 2 1 2 1.3 2.18519 1.7 2.59259 2 3 It turns out that the lenny package will also exhibit this problem if simply recompiled with the newer gcc that is in lenny -- the version of spline in lenny was compiled with a much older gcc (gcc-4.1 4.1.2-11): $ apt-get source -b spline=1.1-11 # dpkg -i spline_1.1-11_i386.deb $ echo -e 1\n2\n3\n | aspline -a 1 -n 6 0 1 0.33 1.25926 0.67 1.74074 1 2 1 2 1.3 2.18519 1.7 2.59259 2 3 Thus rendering the package unsafe for binNMUs etc. The behaviour appears to be arch-dependent and compiler flag dependent. Disabling optimisation (-O0) solves the problem and it is not seen on amd64 or PPC. Using -mfpmath=387 on amd64 also causes the erroneous output. This is fixed in a new upstream version -- inclusion of a build-time test for this problem seems sensible to test across other architectures. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575906: lilypond default options don't work with only depended packages installed (needs ghostscript)
Package: lilypond Version: 2.12.3-5 Severity: normal By default, lilypond attempts to produce pdf output (as per the man page): --pdf generate PDF (default) In a clean installation (sid chroot), this default fails to work: $ lilypond test.ly GNU LilyPond 2.12.3 Processing `test.ly' Parsing... Interpreting music... [8][16] Preprocessing graphical objects... Finding the ideal number of pages... Fitting music on 2 or 3 pages... Drawing systems... Layout output to `test.ps'... Converting to `./test.pdf'... `gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -q -r1200 -sDEVICE=pdfwrite -sOutputFile=./test.pdf -c .setpdfwrite -f test.ps' failed (32512) error: failed files: test.ly because ghostscript is not installed. Most users would presumably have ghostscript installed as it will have been dragged in by something else... but lilypond should probably at least Recommend ghostscript so that it just works out of the box. (If it weren't the default behaviour of lilypond to use ghostscript, then I would have filed a wishlist bug for this). cheers Stuart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575162: texify upstream
From the copyright file for this package: http://packages.debian.org/changelogs/pool/main/t/texify/current/copyright ,-- | It was copied from /local/snacks/bin/ from the computers at | the Department of informatics, at the University of Oslo. `- Which, is where the previous Debian maintainer is (or was) located. With this maintainer retiring from Debian, it would seem that there is no longer any access to the upstream for this package. Any prospective adopter should (a) see if the Department of informatics at the University of Oslo is interested in becoming an upstream for this package themselves (seems unlikely) or (b) be prepared to be both upstream and Debian maintainer. The package has relatively few bugs historically and a non-zero (but not huge) popcon so it can probably continue as a QA case for a while even if considered dead-upstream. cheers Stuart -- Stuart Prescott www.nanoNANOnano.net signature.asc Description: This is a digitally signed message part.
Bug#574973: fglrx-glx uninstallable on i386: depends on amd64-only package fglrx-glx-ia32
Package: fglrx-glx
Version: 1:10-3~prerelease-1
Severity: grave
Justification: renders package unusable
The dependencies of fglrx-glx are currently use ${shlibs:Depends} in the
control file and the substvars after building in a clean i386 sid chroot have:
misc:Depends=
shlibs:Depends=fglrx-glx-ia32, libc6 (= 2.1.3), libc6 (= 2.3.6-6~), libgcc1
(= 1:4.1.1), libxext6 (= 0)
which results in the i386 package having a dependency on an amd64-only package.
This is, of course, unsatisfiable and the package is then uninstallable.
The packages recently uploaded to sid show this problem too.
have fun!
Stuart
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574743: popularity-contest: all-popcon-results.txt.gz contains bogus data
Package: popularity-contest Version: 1.46 Severity: normal The popcon summary data at http://popcon.debian.org/all-popcon-results.txt.gz contains bogus data on lines 85993 to 85995 (at present): Package: pyF4hon-central 0 0 0 1 Package: /usr/lib/mime/packages/mime-suprort 0 0 0 1 Package: grofE6-base 0 1 0 0 This is presumably all dodgy data from just one submitter... perhaps the popcon aggregation scripts should filter such data that has package names that are clearly incorrect like these? (i.e. the package names are non-conformant with policy §5.6.7/§5.6.1) I presume that there is a simple checksum included in the data as it submitted by popcon so that issues with corruption in transit aren't an issue and that the data in question here indicates some poor user with a very badly broken status file. Dodgy data like this is an issue for consumers of the popcon results such as the UDD (which obviously needs to be made more robust to such bad input). cheers Stuart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573972: pyxplot: Depends on obsolete libmagickcore2-extra
Hi, Following the soname bump of libmagickcore, I now have #573972: pyxplot explicitly depends on libmagickcore2-extra, which no longer exists after the recent imagemagick upload to unstable; it's been replaced by libmagickcore3-extra. Please check and update your build-dependency. This is a trivial thing for me to fix in the pyxplot packaging, but the fact that pyxplot requires a sourceful upload when something it only ever calls at the command line undergoes a soname bump probably points to something wrong here. The only reason that pyxplot build-depends on libmagickcore2-extra is to get svg to png conversion functionality in imagemagick. Since pyxplot doesn't actually use any symbols itself from imagemagick at all (it just calls convert!), it shouldn't need to worry about transitions in helper utilities that it calls. Is there already a better way for me to write a depends line that brings this functionality into convert? If not, should there be? I don't really want pyxplot (and however many other package out there) to require sourceful uploads every time you need a soname bump on imagemagick :( Would Provides: libmagickcore-extra be a reasonable solution so that packages can depend on that instead? thanks in advance Stuart (who was tempted to clone this bug as a wishlist bug against libmagickcore3-extra but thought he'd ask first!) -- Stuart Prescott www.nanoNANOnano.net signature.asc Description: This is a digitally signed message part.
Bug#573972: pyxplot: Depends on obsolete libmagickcore2-extra
Hi,
The only reason that pyxplot build-depends on libmagickcore2-extra is to
get svg to png conversion functionality in imagemagick. Since pyxplot
doesn't actually use any symbols itself from imagemagick at all (it just
calls convert!), it shouldn't need to worry about transitions in helper
utilities that it calls.
[..]
Stupid question: wouldn't graphicsmagick (and
graphicsmagick-imagemagick-compat) be sufficient for your use case?
A good thought as that would at least side-step this dependency problem, but
no, graphicsmagick does not correctly convert the svg to png in this case so
it's not a suitable solution.
So back to plan A... since I'm not linking against symbols in
libmagickcore{2,3}-extra at all, it's probably wrong for me to have to depend
on the package at all. That the soname change has affected pyxplot in this
way illustrates the point... getting the right library for imagemagick to be
able to manipulate svg files should be the job of magick packages and not
other unrelated packages. If I'm not linking against the library then I
shouldn't have to worry about its soname. The wrong person is having to worry
about these details; the abstraction isn't working properly.
The suggestion was made on IRC that ideally, there should be a binary package
imagemagick+extra (or something), which would depend on the libmagickcoreN
and libmagickcoreN-extra packages for the correct N to provide the
functionality required.
Thoughts?
cheers
Stuart
--
Stuart Prescott www.nanoNANOnano.net
signature.asc
Description: This is a digitally signed message part.
Bug#573901: [latexdraw] choice of jre in wrapper script
tags 573901 +pending thanks Hi Adrian, Thanks for your report The wrapper script /usr/bin/latexdraw is set up to ignore alternatives settings and serach for jre's. Unfortunately, /usr/bin/java doesn't necessarily point to a java installation that is actually capable of running latexdraw even though there has to be one installed that will due to the dependencies. Wrapper scripts like this are a horrid hack at best. The speed and rendering performance of latexdraw are far superior when run under sun-java. That's an interesting observation and not one I can reproduce. However, I have some sympathy for the point of view that if you've taken the effort to install the non-free JRE you probably want it used so I'll make the switch in any case. If you have a useful test-case where the performance is significantly and reproducibly faster with Sun JRE over OpenJDK, then the openjdk people would be quite interested in knowing about this. Please report this either to their upstream bugzilla or through reportbug so that it gets some attention. The more details about this performance problem you can provide the better. cheers Stuart -- Stuart Prescott www.nanoNANOnano.net signature.asc Description: This is a digitally signed message part.
Bug#572364: apt doesn't forget auto-install state on package removal; interacts badly with dpkg -i
Package: apt Version: 0.7.25.3 Severity: minor Removing a package leavesh information about the package still in /var/lib/apt/extended_state which means that subsequently installing the package manually with dpkg -i doesn't remove this information and the (now manually) installed package is incorrectly listed as automatically installed leading to incorrect package removal by a subsequent apt-get autoremove/aptitude run. e.g. in a clean sid chroot: apt-get -o APT::Install-Recommends=true install git-core # package less is installed automatically apt-get remove git-core apt-get autoremove aptitude show less | head -2 Package: less State: not installed # so far so good, except... grep -A1 less /var/lib/apt/extended_states Package: less Auto-Installed: 1 dpkg -i /var/cache/apt/archives/less_436-1_i386.deb aptitude show less | head -3 Package: less State: installed; will be removed because nothing depends on it Automatically installed: yes apt-get autoremove # removes less as promised but probably not desired So the stale extended_states information hangs around and causes issues in this (admittedly small) corner case. It seems unnecessary for these extended states to be preserved after package removal and it seems odd to require that the user run dpkg -i foo.deb ; apt-mark unmarkauto foo every time they manually install a package just in case there is stale extended state information hanging around. While I've illustrated this using apt-get, the same behaviour is seen when using aptitude given that automatic removals is now part of apt itself. cheers Stuart (micah pointed this out on #debian-devel and I managed to reproduce this. He promptly ran away and left me to report the bug :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571926: popularity-contest: popcon doesn't track usage of python modules in a consistent manner
Package: popularity-contest
Version: 1.46
Severity: wishlist
Hi!
popcon currently uses the regexp:
m{/bin/|/sbin/|/lib/.+/|^/usr/games/|\.[ah]$|\.pm$|\.php$|^/boot/System\.map-}
to detemine if the atime/ctime etc for a file should be checked in order to
decide if the package has been used recently.
This means that a python module that has no C extensions (i.e. a collection
of .py files only in /usr/share/pyshared) always shows up as being nofiles,
whereas a python module that has a C extension and so installs .so files into
/usr/lib/pyshared/python2.X/package/ will report recent usage etc.
Given the explicit inclusion of .pm files to indicate usage of perl modules
and .php to pick up php snippets/modules/scripts/whatever, it would seem more
useful to collect python data in a similar fashion. That the data for a python
module also depends on whether or not it has a C module or not (something that
is entirely opaque to the end user!) is also a bit odd.
Perhaps add |\.py$ to that regexp?
cheers
Stuart
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571926: popularity-contest: popcon doesn't track usage of python modules in a consistent manner
Hi, Perhaps add |\.py$ to that regexp? We cannot do that because the .py files are read by the python compiler at package installation time to generate the .pyc file, and never after, so the atime of the .py file is useless (it is always equal to the installation time). See also bug #265360. duh... of course. Can we come up with some way of making popcon more useful for python module packages then? (Other than just number of installations) The discussion of how widely used a package is (i.e. is it low popcon and a candidate for removal because it looks orphaned etc) is harder to have if you don't know if the X installation reports are actually using module or if it just happened to be installed once back on the box when it was running potato and left to rot there... As a (probably poorly-conceived) idea, would it be too much hard work for the popcon scripts to special-case \.py$ to actually take the atime of the corresponding \.pyc$ file? Popcon would need to know where pysupport/pycentral is sticking these files of course. cheers Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571334: Bug #567714 causes ftbfs: merging and making RC
reassign 571334 tex-common forcemerge 567714 571334 severity 567714 serious stop The current uninstallability of tex-common causes the plastex package to ftbfs. This is clearly not a bug in plastex so reassigning to tex-common. It's still a ftbfs-issue so probably still serious but I have precisely zero interest in arguing about severity levels. cheers Stuart -- Stuart Prescott www.nanoNANOnano.net signature.asc Description: This is a digitally signed message part.
Bug#560604: new dependency for imagemagick required
Hi, The solution to this FTBFS appears to be to build-depend also on libmagickcore2-extra as the imagemagick package has been rearranged such that the SVG conversion plugins are in a separate package. Happy hunting, Stuart -- Stuart Prescott www.nanoNANOnano.net signature.asc Description: This is a digitally signed message part.
Bug#555677: debhelper: dh_installdocs should warn if it skips badly formatted doc-base files
Package: debhelper
Version: 7.4.3
Severity: wishlist
Tags: patch
Today on #debian-mentors, we were looking to see why a doc-base file didn't
appear in the final package, depsite the call to dh_installdocs being included
in the build log. It turned out that there was a spare space at the start of
the Document: line so debhelper ignores the file.
Any other sort of malformed doc-base file would also be silently ignored.
Sure, crappy doc-base files shouldn't be in debian/ but it would be nicer if
dh_installdocs complained about them rather than just passing over it.
The attached patch emits a warning if the /^Document\s*:\s*(.*)/ match fails.
(warning rather than verbose_print as this is something that the maintainer
almost certainly should be fixing)
cheers
Stuart
--- dh_installdocs-orig 2009-11-11 00:03:24.0 +
+++ dh_installdocs 2009-11-11 00:32:03.0 +
@@ -279,4 +279,6 @@
$doc_ids{$fn}=$1;
last;
+ } else {
+ warning(Ignoring $fn as it is incorrectly
formatted.);
}
}
Bug#555123: python-plastex: plastex copies links to icons into icons directory rather than copying files
Package: python-plastex
Version: 0.9.1-1
Severity: normal
Tags: patch
Hi!
When using plastex to compile documentation, for example:
TEXINPUTS= plastex -d html pyxplot.tex
the html/icons directory is full of links to the actual icons:
blank.gif -
/usr/share/python-support/python-plastex/plasTeX/Renderers/XHTML/Themes/default/icons/blank.gif
which only makes sense if the package depends on plastex as well as using it
to build the documentation. Since plastex uses python-support to build, any
change in python-support such as changing the location of shared files to
/usr/share/pyshared/ (which has already recently happened) will also break all
these links. In a plastex-rendered document, these probably should be the real
files not symlinks, and I'm pretty sure this is what is intended by the upstream
authors for plastex and we are getting symlinks in Debian only because Debian
supports multiple python versions using symlink farms.
In a makefile using plastex, these symlinks can be reverted to real files
using a snippet like:
find doc/html -type l \
-exec sh -c 'cp --remove-destination $$(readlink {}) {}' \;
but that's pretty ugly to have to do.
The problem seems to come from around line 322 in
Renderers/PageTemplate/__init__.py
where the theme files are just blindly copied across rather than the symlinks
being dereferenced. Changing the copytree call to not make symlinks and the
copy call to a copyfile call as per the attached patch solves this problem.
Since upstream have explicitly used copytree in a way that it should copy over
symlinks, it might be worthwhile dicussing this change with them prior to
patching the Debian package, although I don't believe that it was upstream's
intention to end up with broken symlinks like this.
cheers
Stuart
--- Renderers/PageTemplate/__init__.py-orig 2009-11-08 15:15:03.0
+
+++ Renderers/PageTemplate/__init__.py 2009-11-08 15:31:51.0 +
@@ -328,7 +328,7 @@
if not os.path.isdir(os.path.join(cwd,item)):
os.makedirs(os.path.join(cwd,item))
-copytree(item, cwd, True)
+copytree(item, cwd, False)
elif os.path.splitext(item)[-1].lower() not in
extensions:
-shutil.copy(item, os.path.join(cwd,item))
+shutil.copyfile(item, os.path.join(cwd,item))
os.chdir(cwd)
Bug#553271: python-pyx: import failing because of missing link to mesh.py in /usr/lib/python2.*/site-packages/pyx
Hi Johann, Thanks for the report. This looks decidedly like a bug in python-central: http://bugs.debian.org/479852 although there is some discussion as to whether each separate package should work around this bug itself or if python-central should deal with this situation. Can you confirm for me that you previously had python-pyx installed and that this was an upgrade from a version 0.10-0+nmu1 or earlier? (i.e. not a fresh installation) The directory where you found all the pyx files ( /usr/lib/python2.5/site-packages/pyx) actually should be empty with this package now; pyx should be found in /usr/lib/pymodules/python2.5/pyx/. If you upgraded from the 0.9 version, then you could well have a very strange mix of 0.9 and 0.10 in there. In any case, running pycentral pkgremove python-pyx should clean up that directory (it should remove /usr/lib/pymodules/python2.5/pyx/ in fact), leaving you with a working pyx installation. I have an updated package ready to do this automatically on upgrade but want to make sure that I understand the problem first. regards Stuart -- Stuart Prescott www.nanoNANOnano.net ph +44 117 33 18387 fax +44 117 925 0612 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547962: Updated version of pyxplot (0.7.0)
Hi Sam and Vincent, I've now got pyxplot 0.7.0 in good shape and have uploaded it to mentors: http://mentors.debian.net/debian/pool/main/p/pyxplot/pyxplot_0.7.0+1-1.dsc pyxplot (0.7.0+1-1) unstable; urgency=low * New maintainer. Thanks to Sam Morris for his previous work. * New upstream release (closes: #547962). * Replace obsolete dependencies on gs-* packages (closes: #534900). * Depend on texlive-latex-base to ensure that latex is installed (closes: #497918). * Move gv to recommends and use a wrapper to find other postscript viewers and allow user configuration of this (closes: #492804). * Move python-scipy to a Recommends as it is possible to use pyxplot without this package installed (closes: #478834). * Document recommended packages and the functionality they provide in README.Debian. * Add menu entry, icons and mime-type assosciation for pyxplot files. * Change build system to dh7+quilt. * Bump standards version to 3.8.3 (no changes required). -- Stuart Prescott stuart+deb...@nanonanonano.net Tue, 13 Oct 2009 15:11:08 +0100 Your testing and review of this updated package would be most welcome. I've also tested it with python 2.6 and it (now) seems to be fine as long as pyx is binNMUd for that transition -- getting pyx into good shape for python 2.6 is what has delayed this work. Seeing as mentors discards the binary packages, here's the .deb that was generated in case you want to do some testing prior to building the package yourself: http://www.nanonanonano.net/tmp/pyxplot_0.7.0+1-1_all.deb Note that it requires pyx 0.10 which is only in sid at present (although the sid package installs quite happily into lenny as well). Let me know how the package is looking and if you have any further suggestions for it. Sam: as per your last message, I've taken over the package -- but it occured to me that you implied that your lack of time to devote to pyxplot might be a transitory thing. I'll happily add you back in as a co-maintainer and perhaps import that package into the python applications team svn if you want to do that. cheers Stuart -- Stuart Prescott www.nanoNANOnano.net signature.asc Description: This is a digitally signed message part.
Bug#550215: fakeroot messes with TEMP environment variable, breaks ghostscript
Package: fakeroot Version: 1.13.1 Severity: normal Tags: patch Hi! Investigating a FTBFS, I found that building the package in a clean chroot with dpkg-buildpackage failed, but each step of the build worked fine when run manually. Slowly breaking down the problem, I eventually found the following: # aptitude install fakeroot ghostscript # ps2pdf testprint.ps # ls testprint.ps testprint.ps # fakeroot ps2pdf testprint.ps # ls testprint.ps testprint.ps # export TEMP=/tmp # fakeroot ps2pdf testprint.ps GPL Ghostscript 8.70: Could not open temporary file -- 'ps2pdf' 'testprint.ps'/gs_9FcqUJ Unable to open the initial device, quitting. So ghostscript is trying to use the literal: -- 'ps2pdf' 'testprint.ps'/gs_9FcqUJ as the temp file and of course the directory -- 'ps2pdf' 'testprint.ps' doesn't exist so it all fails. Sure, it would be better if ghostscript didn't use a nonstandard environment variable to set its temp directory, but that's not going to change any time soon. It would also be preferable for fakeroot to refrain from polluting the environment. The attached patch renames the TEMP variable in /usr/bin/fakeroot to something that should prevent such clashes in the future. There are undoubtedly other approaches that would prevent fakeroot from polluting the environment (and perhaps there are other commonly used variables that also should not be touched in /usr/bin/fakeroot; PREFIX and BINDIR are two that jump to mind). cheers Stuart --- fakeroot.orig 2009-10-08 13:07:55.0 +0100 +++ fakeroot2009-10-08 13:07:30.0 +0100 @@ -47,8 +47,8 @@ case $GETOPTEST in getopt*) # GNU getopt -TEMP=`getopt -l lib: -l faked: -l unknown-is-real -l fd-base: -l version -l help -- +l:f:i:s:ub:vh $@` +FAKE_TEMP=`getopt -l lib: -l faked: -l unknown-is-real -l fd-base: -l version -l help -- +l:f:i:s:ub:vh $@` ;; *) # POSIX getopt ? -TEMP=`getopt l:f:i:s:ub:vh $@` +FAKE_TEMP=`getopt l:f:i:s:ub:vh $@` ;; esac @@ -58,5 +58,5 @@ fi -eval set -- $TEMP +eval set -- $FAKE_TEMP FAKEDOPTS=
Bug#549564: okular package could provide postscript-viewer
Package: okular Severity: wishlist Hi! The package description for okular indicates that the package provides a postscript viewer. It would be nice if the package could include a Provides header to this effect (Provides: postscript-viewer) so that okular satisfies the dependency for packages that depend/recommend postscript-viewer. Doing so would save packages like gv or evince being dragged in to satisfy such a dependency when okular already suffices. Doing so also makes it easier for maintainers to indicate that a postscript viewer would be useful for their package without having to enumerate every single postscript viewer in the archive. A list of current users of postscript-viewer can be seen by running: apt-cache showpkg postscript-viewer thanks, Stuart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547872: pyx: manipulates site-packages/ directly, failing with Python 2.6
Hi Ernesto, Knowing that this transition was coming soon, I have already started work on fixing the build system to solve this problem [1]. And yes, switching to dh7 is most certainly the easiest way of doing this -- almost all the complexity of the current rules file can just vanish which is most pleasing. Let me know if you want to take up maintenance of the package again and I can send you my work so far for you to complete the upload. I'd appreciate at least a reply to any of the emails I've sent you about pyx both via the BTS and privately. Any one of: * please leave the package alone, I'm working on it * an NMU is fine by me, go for it * please look after it for me, I no longer have the time and inclination to work on it would be enough... Assuming your continued silence, I guess I'll just carry on and arrange an NMU as before (but it would be much nicer if you'd ACK it!). regards Stuart [1] given that you seem to be inactive, as the last NMUer of the package, I'm taking responsibility for its health. It's also a package I use on a daily basis so I care about it being in good shape! -- Stuart Prescott www.nanoNANOnano.net signature.asc Description: This is a digitally signed message part.
Bug#547962: pyxplot: Please package upstream version 0.7.0
Package: pyxplot Severity: wishlist Hi Sam, Version 0.7.0 of pyxplot has been out for a while now and depends on pyx 0.10. Since pyx 0.10.0 is now in the archive, pyxplot 0.7.0 can now enter the archive. That pyxplot has a dependency on the older version of pyx is also keeping pyx out of testing at present. As I indicated to you some time ago by private email, I'm happy to look at packaging the new version if you'd like some assistance -- if you've already started work on it then it would be better not to duplicate that effort. Please let me know either way. regards Stuart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546744: [build-rdeps] only allows for unstable in sources.list and not sid
Package: devscripts Version: 2.10.35lenny7 Severity: wishlist File: /usr/bin/build-rdeps Tags: patch build-rdeps will only find Sources files if you use unstable in your sources.list and will fail to find any Sources files if you list sid. i.e. this sources line will result in a message telling you to run apt-get update: deb-src http://ftp.uk.debian.org/debian/ sid main where as this line will work fine: deb-src http://ftp.uk.debian.org/debian/ unstable main Both lines are accepted by apt and other programs that deal with Sources files will handle either just fine. The attached patch allows for the use of either sid or unstable in the sources.list. cheers Stuart --- /usr/local/bin/build-rdeps 2009-09-15 12:05:29.0 +0100 +++ /usr/bin/build-rdeps2009-09-10 20:25:34.0 +0100 @@ -71,5 +71,5 @@ my $dctrl = /usr/bin/grep-dctrl; my $sources_path = /var/lib/apt/lists/; -my $source_pattern = .*_dists_(sid|unstable)_.*Sources\$; +my $source_pattern = .*_dists_unstable_.*Sources\$; my @source_files; my $sources_count=0;
Bug#546744: [build-rdeps] only allows for unstable in sources.list and not sid
Hi Patrick, On Tue, Sep 15, 2009 at 01:41:39PM +0100, Stuart Prescott wrote: build-rdeps will only find Sources files if you use unstable in your sources.list and will fail to find any Sources files if you list sid. thanks for your report. But this bug is already fixed in a newer version of devscripts. bah! I thought I already had the sid version on the box I was using. The attached patch allows for the use of either sid or unstable in the sources.list. The attached patch seems.. odd. I guess you diffed the wrong way round? ;) oh no, I really am having a bad day, aren't I? /me hangs head in shame Sorry for the noise Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527149: ITA: spline
retitle 527149 ITA: spline -- Akima spline interpolation owner 527149 ! thanks Dear David, As I indicated to you by private email, I have occasion to make use of this utility in data manipulation so will take over maintenance of this package. Thanks for your many years of contributions to Debian. Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539014: qa.debian.org: show link to removal bug on package QA page
Package: qa.debian.org Severity: wishlist Helping people on #debian, I often need to work out why a package is no longer available. This tends to be asked in the following situations: * why isn't package xyz available in lenny (or squeeze or sid)? It used to exist in etch! (Answer: could be renamed, dead upstream, etc) * why isn't package xyz available in lenny? it's in both etch and sid! (Answer: it was removed from testing just before release because it was RC buggy, but working out precisely why this is can be harder after the release has been made) * why isn't package xyz available in testing but it's in unstable? (Answer: all the usual migration and rc buggy reasons and fairly easy to answer these days) A recent example was the grace6 package. So let's see what was required: 1. Go to the source package's QA page http://packages.qa.debian.org/g/grace6.html 2. look down the list of News items to find a Removed from unstable entry 3. look at news item to see bug number 4. go to bugs.debian.org/bugnumber 5. finally I get to look at the reasons why the package was removed Solving the why did package xyz not make it into the current stable release question is usually just a matter of wandering down to find the removed from testing news entry instead and repeating the above process. It would be *much* nicer if the QA page had a link to the RM bug itself as that cuts out quite a few manual steps in the middle. So instead of: [2009-06-14] Removed 5.99.1+dev4-7 from unstable (Frank Lichtenheld) can we have [2009-06-14] Removed 5.99.1+dev4-7 from unstable #459484 RM: grace6 -- RoQA; orphaned, buggy, not really version 6 (Frank Lichtenheld) or similar? (with appropriate hyperlinks) Have thoughts! cheers Stuart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529252: latexdraw: doesn't start -- fixed by newer version of openjdk-6
unarchive 529005 reassign 529005 openjdk-6 reassign 529252 openjdk-6 close 529252 merge 529005 529252 thanks Hi Paul, Looking at the recent changes in openjdk-6, this bug has been closed with newer versions of that package and no longer applies. Thanks for taking the time to report it. cheers Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#535384: tagging 535384
# Automatically generated email from bts, devscripts version 2.10.35lenny3 # Fix will be included in next upload tags 535384 + pending -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534265: acx100-source: module does not build without dpatch installed; should depend (or recommend?) dpatch
Package: acx100-source Version: 20080210-1 Severity: normal The acx100-source module fails to build with module-assistant in a sid chroot: aptitude install module-assistant acx100-source m-a -i -l 2.6.30-1-686 a-i acx100-source Updated infos about 1 packages Getting source for kernel version: 2.6.30-1-686 Kernel headers available in /lib/modules/2.6.30-1-686/build apt-get -y install build-essential Reading package lists... Done Building dependency tree Reading state information... Done build-essential is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Done! unpack Extracting the package tarball, /usr/src/acx100.tar.gz, please wait... /usr/share/modass/overrides/acx100-source build KVERS=2.6.30-1-686 KSRC=/lib/modules/2.6.30-1-686/build KDREV=2.6.30-1 kdist_image debian/rules:9: /usr/share/dpatch/dpatch.make: No such file or directory make: *** No rule to make target `/usr/share/dpatch/dpatch.make'. Stop. debian/rules:9: /usr/share/dpatch/dpatch.make: No such file or directory make: *** No rule to make target `/usr/share/dpatch/dpatch.make'. Stop. BUILD FAILED! Installing the dpatch package solves this problem. regards Stuart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#454765: python-pyx: Diff for updated package
Package: python-pyx
Followup-For: Bug #454765
It's a shame that version 0.10 hasn't been uploaded in the 18 months since it
was released and this great package didn't make it into Lenny.
Attached is an interdiff that takes the packaging for version 0.9 and updates
it for version 0.10 as well as fixing the remaining bugs in the BTS. I have
uploaded the package to mentors.debian.net as well:
http://mentors.debian.net/debian/pool/main/p/pyx/pyx_0.10-1+nmu1.dsc
BTW if you are lacking time to look after pyx, I would be happy to take it
over or to co-maintain it as I use it regularly so have a definite interest
in this package. Please let me know what you think.
diff -u pyx-0.9/debian/rules pyx-0.10/debian/rules
--- pyx-0.9/debian/rules
+++ pyx-0.10/debian/rules
@@ -55,7 +55,7 @@
dh_testroot
install -D -o root -g root -m 0644 manual/manual.pdf $(CURDIR)/debian/python-pyx-doc/$(docdir)/manual.pdf
install -D -o root -g root -m 0644 faq/pyxfaq.pdf $(CURDIR)/debian/python-pyx-doc/$(docdir)/pyxfaq.pdf
- find gallery examples \( -name *.py -o -name *.dat \) \
+ find gallery examples \( -name *.py -o -name *.dat -o -name *.jpg\) \
-exec install -D -m 0644 {} $(CURDIR)/debian/python-pyx-doc/usr/share/doc/python-pyx-doc/{} \;; \
dh_installchangelogs -i CHANGES
dh_installdocs -i -A README AUTHORS
diff -u pyx-0.9/debian/changelog pyx-0.10/debian/changelog
--- pyx-0.9/debian/changelog
+++ pyx-0.10/debian/changelog
@@ -1,3 +1,15 @@
+pyx (0.10-1+nmu1) unstable; urgency=low
+
+ * Non-maintainer upload
+ * New upstream release (closes: #454765)
+ * Update build-deps to use texlive rather than tetex
+ * Update depends to use texlive rather than tetex (closes: #467207)
+ * Recommend a smaller latex package to reduce the installation size.
+texlive-latex-base seems to be the smallest package that allows at least
+the (trivial) examples to be built (closes: #503577)
+
+ -- Stuart Prescott stuart+deb...@nanonanonano.net Fri, 15 May 2009 00:23:04 +0100
+
pyx (0.9-4) unstable; urgency=low
* New maintainer (closes: #408140).
diff -u pyx-0.9/debian/control pyx-0.10/debian/control
--- pyx-0.9/debian/control
+++ pyx-0.10/debian/control
@@ -4,14 +4,14 @@
Section: python
Priority: optional
Build-Depends: debhelper (= 5.0.37.1), python-all-dev, libkpathsea-dev, python (= 2.3.5-7), python-central (= 0.5)
-Build-Depends-Indep: tetex-extra, tipa
+Build-Depends-Indep: texlive-latex-extra, texlive-latex-recommended, texlive-fonts-recommended, tipa
XS-Python-Version: all
Package: python-pyx
Architecture: any
Depends: ${shlibs:Depends}, ${python:Depends}
-Recommends: tetex-extra
-Suggests: python-pyx-doc, python-imaging
+Recommends: texlive-latex-base
+Suggests: python-pyx-doc, python-imaging, texlive-fonts-recommended
Conflicts: python2.3-pyx, python2.2-pyx, python-pyx-common
Replaces: python2.3-pyx, python-pyx-common
XB-Python-Version: ${python:Versions}
only in patch2:
unchanged:
--- pyx-0.10.orig/manual/graph.tex
+++ pyx-0.10/manual/graph.tex
@@ -1,6 +1,8 @@
\chapter{Graphs}
\label{graph}
+\let\e=\textbackslash
+
\section{Introduction} % {{{
\PyX{} can be used for data and function plotting. At present
x-y-graphs and x-y-z-graphs are supported only. However, the component
Bug#532255: bootchart-view: bootchart can now use the jlibeps package for EPS rendering
Package: bootchart-view
Version: 0.10~svn407-3
Severity: wishlist
Tags: patch
Hi Jörg,
Ages ago we talked about bootchart using jlibeps for EPS rendering and I see
that bootchart is now using jlibeps rather than the rather difficult-to-find
EPSGraphics2D library.
Now that jlibeps is available in Debian as a separate package, it would be
preferable to use it in bootchart-view rather than an internal copy of the
jlibeps library. The attached patch changes the build-depends for the package
to use libjlibeps-java and adds the private copy of jlibeps to the list of
internal libaries to be removed at build time. It also brings in
libjlibeps-java as a dependency of bootchart-view.
Let me know if you have any queries or comments about switching over to use
jlibeps.
regards
Stuart
diff -u bootchart-0.10~svn407/debian/rules bootchart-0.10~svn407/debian/rules
--- bootchart-0.10~svn407/debian/rules
+++ bootchart-0.10~svn407/debian/rules
@@ -9,7 +9,7 @@
# Force ant to use gcj as JDK to make the build more reproducible
export JAVA_HOME=/usr/lib/jvm/java-gcj
-export CLASSPATH=/usr/share/java/commons-cli.jar:/usr/share/java/commons-compress.jar
+export CLASSPATH=/usr/share/java/commons-cli.jar:/usr/share/java/commons-compress.jar:/usr/share/java/net.sourceforge.jlibeps.jar
# This has to be exported to make some magic below work.
export DH_OPTIONS
diff -u bootchart-0.10~svn407/debian/control bootchart-0.10~svn407/debian/control
--- bootchart-0.10~svn407/debian/control
+++ bootchart-0.10~svn407/debian/control
@@ -4,7 +4,7 @@
Maintainer: Jörg Sommer jo...@alea.gnuu.de
Build-Depends: debhelper, dpatch
Build-Depends-Indep: ant, java-gcj-compat-dev, libcommons-cli-java,
- libcommons-compress-java
+ libcommons-compress-java, libjlibeps-java
Standards-Version: 3.7.3
Homepage: http://www.bootchart.org/
Vcs-Browser: http://git.debian.org/?p=users/jo-guest/bootchart.git
@@ -26,7 +26,7 @@
Package: bootchart-view
Architecture: all
Depends: java-gcj-compat | java-runtime | java2-runtime, libcommons-cli-java,
- libcommons-compress-java
+ libcommons-compress-java, libjlibeps-java
Recommends: bootchart
Suggests: gqview, librsvg2-bin, gimp-svg
Description: Boot process performance analyser (visualisation)
diff -u bootchart-0.10~svn407/debian/bin/bootchart bootchart-0.10~svn407/debian/bin/bootchart
--- bootchart-0.10~svn407/debian/bin/bootchart
+++ bootchart-0.10~svn407/debian/bin/bootchart
@@ -1,7 +1,7 @@
#!/bin/sh
MAIN_CLASS=org.bootchart.Main
-CLASSPATH=/usr/share/bootchart-view/bootchart.jar:/usr/share/java/commons-cli.jar:/usr/share/java/commons-compress.jar
+CLASSPATH=/usr/share/bootchart-view/bootchart.jar:/usr/share/java/commons-cli.jar:/usr/share/java/commons-compress.jar:/usr/share/java/net.sourceforge.jlibeps.jar
PROPERTY=java.awt.headless=true
exec java -D$PROPERTY -classpath $CLASSPATH $MAIN_CLASS $@
diff -u bootchart-0.10~svn407/debian/patches/remove-internal-libs.dpatch bootchart-0.10~svn407/debian/patches/remove-internal-libs.dpatch
--- bootchart-0.10~svn407/debian/patches/remove-internal-libs.dpatch
+++ bootchart-0.10~svn407/debian/patches/remove-internal-libs.dpatch
@@ -6,8 +6,8 @@
dpatch_patch ()
{
-tar vcf debian/patched/remove-internal-libs.tar lib/org/apache
-rm -r lib/org/apache
+tar vcf debian/patched/remove-internal-libs.tar lib/org/apache lib/org/sourceforge/jlibeps
+rm -r lib/org/apache lib/org/sourceforge/jlibeps
}
dpatch_unpatch ()
Bug#431905: fixed 431905 in 2.0.2+1-2, closing 431905
# Automatically generated email from bts, devscripts version 2.10.35lenny3 #Uploaded to the archive fixed 431905 2.0.2+1-2 close 431905 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#431907: fixed 431907 in 0.14.2+3-1, closing 431907
# Automatically generated email from bts, devscripts version 2.10.35lenny3 #Uploaded to the archive fixed 431907 0.14.2+3-1 close 431907 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#447525: fixed 447525 in 0.1+2-1, closing 447525
# Automatically generated email from bts, devscripts version 2.10.35lenny3 #Uploaded to the archive fixed 447525 0.1+2-1 close 447525 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531492: apt: man 5 sources.list examples with stable are a time bomb
Package: apt Version: 0.7.20.2+lenny1 Severity: wishlist Tags: patch At present, the man page for the sources.list file has the following example: deb http://http.us.debian.org/debian stable main contrib non-free One thing that has been quite common in #debian (both freenode and oftc) since the release of lenny is people coming in with boxes in a wildly inconsistent state with a lovely mishmash of etch and lenny. They have had a sources.list with entries pointing to stable and then performed what they thought was a fairly safe apt-get update apt-get upgrade. Sure, there were a lot of packages updated when I did that, but I figured they were necessary. These are obviously people who are not subscribed to debian-announce, do not have apt-listchanges installed and probably don't really understand debian release cycles. Sure, it's PEBKAC, but the documentation encouraged them to do this (sources.list(5) being only one of a great many sources of documentation that suggest the use of stable in the sources.list). In previous eras when upgrading between releases was literally as easy as doing a dist-upgrade, having stable in the sources.list probably wasn't so bad. Nowadays, it's a time bomb just waiting to make a mess of a box. We are similarly seeing people with stable and etch/updates in their sources.list which means that they also are often not picking up security updates correctly. (There were a lot of these turning up just after DSA1571 caused people to pay a little more attention to their boxes than they normally do.) A patch to change some of these uses of stable to lenny is attached. It was prepared against 0.7.21 from sid. An alternative that uses an entity to include the current stable codename would possibly be preferable for you. Happy hunting! --- sources.list.5.xml-orig 2009-06-01 23:44:49.0 +0100 +++ sources.list.5.xml 2009-06-01 23:48:19.0 +0100 @@ -61,7 +61,10 @@ archive, filenamedistribution/component/filename. Typically, literaldistribution/literal is generally one of literalstable/literal literalunstable/literal or - literaltesting/literal while component is one of literalmain/literal + literaltesting/literal (or a release name such as + literallenny/literal literalsqueeze/literal or + literalsid/literal) + while component is one of literalmain/literal literalcontrib/literal literalnon-free/literal or literalnon-us/literal The literaldeb-src/literal type describes a debian distribution's source @@ -110,7 +113,7 @@ paraSome examples:/para literallayout -deb http://http.us.debian.org/debian stable main contrib non-free +deb http://http.us.debian.org/debian lenny main contrib non-free deb http://http.us.debian.org/debian dists/stable-updates/ /literallayout @@ -193,8 +196,8 @@ literallayoutdeb http://archive.debian.org/debian-archive hamm main/literallayout paraUses FTP to access the archive at ftp.debian.org, under the debian - directory, and uses only the stable/contrib area./para - literallayoutdeb ftp://ftp.debian.org/debian stable contrib/literallayout + directory, and uses only the lenny/contrib area./para + literallayoutdeb ftp://ftp.debian.org/debian lenny contrib/literallayout paraUses FTP to access the archive at ftp.debian.org, under the debian directory, and uses only the unstable/contrib area. If this line appears as
Bug#529252: latexdraw: doesn't start
Hi Paul, I cannot start LaTeXdraw. I don't have a lot of Java stuff installed, when I tried to start LaTeXdraw, I got the following trace: % latexdraw Exception in thread main java.lang.UnsatisfiedLinkError: Can't load library: /usr/lib/jvm/java-6-openjdk/jre/lib/ext/libjava-access-bridge-jni.so at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1666) at [...] This smells decidedly like http://bugs.debian.org/529005 which should be fixed in 6b16-1 which is now in unstable. Can you update to that version and make sure that this bug goes away? As a separate issue, libaccess-bridge-java-jni needs to be installed (and you said it is) -- what version of the libaccess-bridge-java-jni package do you have installed? thanks, Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529195: latexdraw: Typo in long description
tags 529195 pending thanks Hi Kai, Thank you for packaging latexdraw. There is a minor typo in the package's long description: PSTricks in an extension of LaTeX which allows the creation of drawings, ^^ PSTricks is an ... Ha! Well spotted. To think how many times I had read that and missed it. It's fixed in my local sources and will be fixed in a future upload. thanks Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492661: developers-reference: Bogus phrasing about .orig.tar.gz repackaging.
Hi all, -emphasis role=strongmust/emphasis contain detailed information how the -repackaged source was obtained, and how this can be reproduced in the +emphasis role=strongmust/emphasis be documented. Detailed information on how the +repackaged source was obtained, and on how this can be reproduced must be provided in filenamedebian/copyright/filename. What format should this detailed description be in? How detailed? * A description in words of what was done: The non-free font files were deleted from the source tarball * A description in commands of what was done: find -name \*.ttf -delete * A brief description with a pointer to a log of what was done? The non-free font files were were stripped from the downloaded file to create the 'orig' source package. See the file README.Debian-source for full details. I like the last of these the best, where the log file is generated from a standard (yet to be decided!) repackaging tool that clearly shows what was originally downloaded and what was done to it. Perhaps it's also time to start thinking about how the machine-readable copyright files [1] fit into this. [1] http://wiki.debian.org/Proposals/CopyrightFormat Since the point of the machine-readable copyright proposal is to remove arbitrary free form lumps of text from this file, it is perhaps opportune to consider the side-effects of this new language on that proposal which mandate the inclusion of unspecified amounts of details. (Despite the efforts of two or three contributors to the copyright format proposal, there is still nowhere to include anything about repackaging; the suggested fields are routinely removed -- perhaps this illustrates a shortcoming of a wiki for writing such documents more than anything else!) It is also a good idea to provide a literalget-orig-source/literal target in your filenamedebian/rules/filename file that repeats the process, as described Is this wording is slightly at odds with what policy 4.9? (Although that is a matter of interpretation that can't be agreed upon, it would seem, see #466550.) get-orig-source (optional) This target fetches the most recent version of the original source package from a canonical archive site (via FTP or WWW, for example), does any necessary rearrangement to turn it into the original source tar file format described below, and leaves it in the current directory. Thus policy currently states that get-orig-source should (a) fetch the tarball and (b) repackage it, while the wording in that patch to devref only has get-orig-source repackaging the tarball. There is then the old chestnut of what one means by most recent source for the get-orig-source target. Presumably one doesn't mean the most recent release from upstream as we already have uscan to do that. Using get-orig-source only to do the repackaging to regenerate the debian orig tarball would seem to make the most sense. I wonder if the work to clean up this part of devref actually needs to be part of a wider effort to work out what is meant by get-orig-source and to appropriately document it. Placing yet another divergent interpretation of get-orig-source into devref doesn't seem to work towards that goal. food for thought! cheers Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512312: cowdancer: cowbuilder does not umount bind mounts before cleanup if used over ssh
Package: cowdancer Version: 0.47~bpo40+1 Severity: normal Hi! If cowbuilder is invoked over ssh and the ssh connection is broken for any reason (e.g. network failure, user closes terminal without logging out of cowbuilder --login first) then the bind mounts are not released prior to the chroot being cleaned up. The result of this is that any data in any bind mounts will be lost. I suspect that if a user logged out of their X session without first logging out of any cowbuilders, then this would also happen, although I have not tested this. Steps to reproduce: ssh buildbox cowbuilder --create echo 'BINDMOUNTS=/var/cache/pbuilder/result' ~/.pbuilderrc touch /var/cache/pbuilder/result/foo cowbuilder --login (terminate the ssh connection with ~. , by unplugging cable, having the wireless connection drop out, etc) results: data loss! /var/cache/pbuilder/result/foo has disappeared and the bind mounts are still in place. The problem seems to be related to output to the tty during the cleanup phase as illustrated in the further test cases appended to this bug report. I have also checked this with the version of cowdancer in sid and the behaviour is the same. Obviously, running cowbuilder through screen is one way of preventing this being a problem, but accidentally wiping out bind mounts is not a good thing. Data loss would be justification for a grave severity for this bug but I will leave it to others to decide whether it is enough of a corner case to allow that to be ignored. Please let me know if there is further information that I can provide. cheers Stuart (Fortunately, I only had /var/cache/pbuilder/result and /tmp/.X11-unix in the bind mounts so I lost nothing important and will just need to restart X to allow me to start new programs in X; if I had $HOME in the bind mounts too, then that would have been considerably more painful.) 8 -- further test cases 8 -- Output (or lack of) from cowbuilder when connection is interrupted: ssh buildbox echo 'BINDMOUNTS=/var/cache/pbuilder/result' ~/.pbuilderrc touch /var/cache/pbuilder/result/foo cowbuilder --login | tee logfile (terminate the ssh connection with ~. or by unplugging cable etc) results: data loss! /var/cache/pbuilder/result/foo has disappeared and the bind mounts are still in place. Log file reads as follows: - Running in no-targz mode - copying local configuration - mounting /proc filesystem - mounting /dev/pts filesystem - Mounting /var/cache/pbuilder/result - policy-rc.d already exists Obtaining the cached apt archive contents - entering the shell (note that there are no clean up messages) Preventing all stdout and stderr from cowbuilder when connection is interrupted: ssh buildbox echo 'BINDMOUNTS=/var/cache/pbuilder/result' ~/.pbuilderrc touch /var/cache/pbuilder/result/foo cowbuilder --login logfile (terminate the ssh connection with ~. or by unplugging cable etc) results: OK! /var/cache/pbuilder/result/foo is still there, bind mounts have been removed during cleanup. Log file reads: - Running in no-targz mode - copying local configuration - mounting /proc filesystem - mounting /dev/pts filesystem - Mounting /var/cache/pbuilder/result - policy-rc.d already exists Obtaining the cached apt archive contents - entering the shell Hangup Copying back the cached apt archive contents - unmounting /var/cache/pbuilder/result filesystem - unmounting dev/pts filesystem - unmounting proc filesystem (note cleanup messages present) Sending signals while not running through ssh: echo 'BINDMOUNTS=/var/cache/pbuilder/result' ~/.pbuilderrc touch /var/cache/pbuilder/result/foo cowbuilder --login (kill -1 $LOGIN_SHELL so that the tty disappears) result: data loss! same as before. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (900, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages cowdancer depends on: ii libc6 2.3.6.ds1-13etch8 GNU C Library: Shared libraries ii pbuilder 0.161 personal package builder for Debia cowdancer recommends no packages. -- no debconf information (Note that the system informartion, above, is for an etch box using the cowdancer from backports.org, but I have also verified this behaviour on a lenny-only machine and a lenny machine with sid's cowdancer) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504918: [Debian Wiki] Update of NewInLenny : Upgrade over SSH issue
Hi Franklin, (I hope you are the right Stuart) yes, indeed. I didn't found a bug report from you. However I fount those two bug that are similar. * Network-manager shouldn't stop the network during an upgrade http://bugs.debian.org/474352 * Updating to lenny failed when NetworkManager got updated http://bugs.debian.org/504918 These are indeed related bugs. In message #10 of #474352, the maintainer notes that this bug should be fixed now, or at least mitigated [ minimize the downtime (with ethernet it's a matter of seconds)]. Depending on the ssh settings and the user's reaction to seeing the upgrade hang, that may or may not work out OK. If it is a wireless connection, however, the downtime can be much longer and my experience is that it is likely to hang. It looks like it could hurt many user that upgrade [lots of] desktops over ssh. Possibly -- but would they use network manager in such a situation? (I don't know). My feeling is that it would be fairly uncommon to upgrade over ssh for machines that actually used network manager; the intersection of upgrade-over-ssh and users of network manager (which is a desktop-centric tool) would seem small. As such, I had thought it was probably just a document that you shouldn't do this situation rather than an RC bug in network-manager. In the same way that upgrading over telnet or within a gdm session is not supported, this is just documented rather than being a grave bug in the package. See section 4.1.4 of the etch release notes (which is currently unchanged in the lenny release notes) which explicitly warns against upgrading within a telnet, rlogin, rsh, xdm, gdm or kdm session. I doubt this is something that can or will be cured before lenny releases so I'm guessing that this is going to be fixed by documentation for the time being at least. (Which is why I flagged it as an issue in the release notes wiki.) Happy hunting! cheers, Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447525: ITP: jlibeps -- Java library to create EPS images
Hi Olivier, I think that this lib is embedded in package bootchart already, Yes, this is correct -- I am already in contact with the bootchart packager(s) and in fact they were involved in the original decision to fork jlibeps from its no-longer-free upstream. thanks for the heads up anyway! cheers Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501518: upgrade-reports: etch-lenny works better with etch's apt-get than lenny's aptitude
Package: upgrade-reports Severity: normal On an etch box with X, KDE and assorted office-type applications installed, I followed the sequence of steps outlined on d-d-a [1]: aptitude update aptitude upgrade sed -i 's/etch/lenny/g' /etc/apt/sources.list aptitude update aptitude install dpkg aptitude So far, so good. The next step is the problematic one. aptitude full-upgrade: xserver-xorg-video-all is broken as the individual video drivers are not installable. This leads to 95 other packages being removed including a lot of graphical ones, but not all of xorg or kde. Saying n twice to get aptitude to look for a different solution causes it to come up with what seems like a more sensible solution. aptitude full-upgrade xserver-xorg-video-all+ Hinting at the installation of the video drivers (or indeed just the video driver package you need) goes straight to the same sensible solution as above. apt-get dist-upgrade Using etch's apt-get for the upgrade wants to remove 15 packages, none of which I'm that attached to so it would also be a sensible solution to the upgrade. (for the record: fftw3 libdiscover1 libft-perl libgfortran1 libgsl0 libgssapi2 libldap2 libpci2 libperl5.8 librpm4 libsasl2 libstlport4.6c2 selinux-policy-refpolicy-targeted tetex-doc xserver-xorg-video-newport) Perhaps this is as you would expect, but it's pretty unnerving being presented with a long list of broken packages and removals. Some degree of documentation of this would be good in that case. Following this, the upgrade completed successfully. [1] http://lists.debian.org/debian-devel-announce/2008/10/msg0.html -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (100, 'stable'), (60, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.24-etchnhalf.1-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491074: fixed!
openjdk-6-jdk version 6b11-1 seems to have solved this bug. Thanks all! -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491074: openjdk-6-jdk: sigsegv when compiling with javac
Package: openjdk-6-jdk Version: 6b10dfsg-2 Severity: normal When compiling the source for LaTeXDraw [1] (which I am in the process of packaging), I get a SIGSEGV from javac. The actual file being compiled when this occurs varies but is generally the 50 to 70th file in the compilation process (of the 111 source files). The crashdump generated by the jvm is attached. Compilation is being performed in sid cowbuilder on an etch machine. The same source compiles with no problems with the javac from the sun-java6-jdk package. It seems that this (or a related problem) has been seen in various javac's since java 5 [2,3] and the same workaround is applicable: passing -client to the jvm prevents the segfault (add -J-client if using javac directly or use ANT_OPTS=-client; ant if using ant). There appear to be related bugs in both the icedtea bugzilla [4,5] and in the sun bugs db [6]; as per discussion on #debian-java, here's a bug in the Debian bts too. Let me know if I can provide any further information. cheers Stuart [1] latexdraw.sf.net version 1.9.5 -- http://downloads.sourceforge.net/latexdraw/LaTeXDraw1.9.5_src.zip?modtime=1193349194big_mirror=0 [2] Googling for libjvm.so sigsegv turns up a few discussions of this. [3] e.g. http://forum.java.sun.com/thread.jspa?threadID=5132238tstart=75 [4] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=152 [5] Additional related bugs that mostly have no comments attached to them other than the original report at http://icedtea.classpath.org/bugzilla/buglist.cgi?quicksearch=libjvm.so [6] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6708395 -- System Information: Debian Release: 4.0 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (100, 'stable'), (60, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.24-etchnhalf.1-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x403572ac, pid=32014, tid=1815362448 # # Java VM: OpenJDK Server VM (1.6.0_0-b10 mixed mode linux-x86) # Problematic frame: # V [libjvm.so+0x1bf2ac] # # If you would like to submit a bug report, please visit: # http://icedtea.classpath.org/bugzilla # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --- T H R E A D --- Current thread (0x08103c00): JavaThread CompilerThread1 daemon [_thread_in_native, id=32024, stack(0x6c2c4000,0x6c344000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x Registers: EAX=0x, EBX=0x407b68a0, ECX=0x140c, EDX=0x6c342700 ESP=0x6c341f10, EBP=0x6c341f68, ESI=0x087e2a2c, EDI=0x EIP=0x403572ac, CR2=0x, EFLAGS=0x00010216 Top of Stack: (sp=0x6c341f10) 0x6c341f10: 085aa018 0004 4073ef64 0x6c341f20: 0001 01342700 000d 084a4704 0x6c341f30: 0003 0001 0001 0x6c341f40: 08078cb8 087c8e9c 0004 087c8990 0x6c341f50: 08785190 0010 085aa018 407b68a0 0x6c341f60: 08785190 6c342700 6c342088 403593f8 0x6c341f70: 6c342700 0001 6c34276c 6c34206c 0x6c341f80: 0869eba0 7fec 6c342010 6c34206c Instructions: (pc=0x403572ac) 0x4035729c: 89 46 18 8b 7d f0 8b 07 89 3c 24 ff 50 40 89 c7 0x403572ac: 8b 00 21 46 34 8b 47 04 21 46 38 8b 47 08 21 46 Stack: [0x6c2c4000,0x6c344000], sp=0x6c341f10, free space=503k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1bf2ac] V [libjvm.so+0x1c13f8] V [libjvm.so+0x212aa8] V [libjvm.so+0x213f57] V [libjvm.so+0x1adcdd] V [libjvm.so+0x218718] V [libjvm.so+0x218e00] V [libjvm.so+0x53e0c7] V [libjvm.so+0x542b86] V [libjvm.so+0x542c32] V [libjvm.so+0x467fb7] C [libpthread.so.0+0x5f3b] Current CompileTask: C2:106 ! com.sun.tools.javac.parser.Parser.literal(Lcom/sun/tools/javac/util/Name;)Lcom/sun/tools/javac/tree/JCTree$JCExpression; (751 bytes) --- P R O C E S S --- Java Threads: ( = current thread ) 0x08105800 JavaThread Low Memory Detector daemon [_thread_blocked, id=32025, stack(0x6c20,0x6c25)] =0x08103c00 JavaThread CompilerThread1 daemon [_thread_in_native, id=32024, stack(0x6c2c4000,0x6c344000)] 0x08102800 JavaThread CompilerThread0 daemon [_thread_in_native, id=32023, stack(0x6c044000,0x6c0c4000)] 0x08101400 JavaThread Signal Dispatcher daemon [_thread_blocked, id=32022, stack(0x6bff4000,0x6c044000)] 0x080e8800 JavaThread Finalizer daemon [_thread_blocked, id=32021, stack(0x6bfa4000,0x6bff4000)] 0x080e4400 JavaThread Reference Handler daemon [_thread_blocked, id=32020, stack(0x6bf54000,0x6bfa4000)] 0x08057400 JavaThread main [_thread_in_native, id=32016, stack(0x40c0b000,0x40c5b000)] Other Threads: 0x080e1000 VMThread [stack: 0x6bed4000,0x6bf54000] [id=32019] 0x08107000
Bug#447525: Work in progress for jlibeps, java-imaging-utilities, latexdraw
reopen 431907 reopen 431905 thanks, mate Work is in progress of preparing these packages. I hope to be in a position to ask for some more feedback on my work soon. -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476474: Backport of fglrx 8.47.3-3 from Lenny works nicely with etchnhalf
Hi all, I took a deep breath the other day and installed the etchnhalf packages from etch-proposed-updates on my laptop. (Dell Inspiron 6400 with ATI X1400). What I did is sketched out below [1]. I now have a nice etchnhalf kernel with fglrx working quite happily. 3D acceleration is working and it seems to be surviving suspend-to-disk cycles without any hassles either (which was one of the things I was seeking to improve with this exercise). I hope this is useful information for you. It at least tells you that it's all possible even if some of the details below are a little scant and you would obviously do things slightly differently for backports.org. Please let me know if I can provide further information. cheers Stuart fglrx lenny-etchnhalf log # Install etchnhalf kernel and kernel headers aptitude install linux-image-2.6.24-etchnhalf.1-686 \ linux-headers-2.6.24-etchnhalf.1-686 # reboot into new kernel, cross fingers reboot # dance around the room when it all seems to come up working OK. laptop # install build-deps for Lenny's fglrx-driver [2] apt-get install x11proto-core-dev libx11-dev libxtst-dev \ libxxf86misc-dev libxxf86vm-dev libxinerama-dev \ docbook-xml docbook-xsl xsltproc rpl # build a backport of the fglrx-driver [3] apt-get -b source -t testing fglrx-driver # pull the kernel module from Lenny too and build it apt-get install -t testing fglrx-kernel-src m-a build fglrx-kernel-src # install the lot dpkg -i fglrx-driver_8.47.3-3_i386.deb \ fglrx-glx_8.47.3-3_i386.deb \ /usr/src/fglrx-kernel-2.6.24-etchnhalf.1-686_8.47.3-3+2.6.24-6~etchnhalf.1_i386.deb # load module, start x etc as per normal [1] Apologies... this is only an approximate log as it wasn't entirely as linear as this and I was also futzing with getting iwlwifi to work in place of ipw3945 which confuses things a little too. In any case, it shows that it is possible to get Lenny's fglrx working with etch's xorg which is the main issue here. [2] I can't recall why I didn't just apt-get build-dep here... [3] Yeah, OK... dch --bpo etc would be preferable. Final state: $ dpkg -l fglrx* linux-image* xserver-xorg | grep ^ii ii fglrx-driver8.47.3-3 non-free AMD/ATI r5xx, r6xx display driver ii fglrx-glx 8.47.3-3 proprietary libGL for the non-free AMD/ATI r ii fglrx-kernel-2.6.24-etchnhalf.1-686 8.47.3-3+2.6.24-6~etchnhalf.1 ATI binary kernel module for Linux 2.6.24-et ii fglrx-kernel-src8.47.3-3 kernel module source for the non-free AMD/AT ii linux-image-2.6.24-etchnhalf.1-686 2.6.24-6~etchnhalf.1 Linux 2.6.24 image on PPro/Celeron/PII/PIII/ ii xserver-xorg7.1.0-19 the X.Org X server -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449423: glibc2.7 followup
Dear Pierre, Calm down! For further information, see http://lists.debian.org/debian-devel/2007/11/msg00033.html And ? What does it proves ? As a member of the glibc packaging team I quite know what I'm saying. I know that you know that -- that comment wasn't for you but for the original reporter and anyone else who might (like I did) waste considerable time trying to work out what was wrong with the locales package. I eventually found the above explanation of what was going on. When what *seems* like a pretty major problem is closed with no more than this is not a bug, the reporter and anyone else experiencing that problem is left dazed and confused. I know that glibc2.7 has been keeping you very busy, and all of the Debian community appreciates the effort that you (collectively) put into such an important package. But attaching more information (such as the link to d-d) to your email closing the bug would have been nice, helpful, polite, etc... Since you had not offered any explanation as to why it was not a bug, I thought I would to save others time and confusion. Locales from glibc 2.7 aren't installable, bummer. It doesn't prevents you to install any other debian package as none depends upon glibc 2.7 (or that's a bug in them). Actually, it is causing problems in pbuilders -- this is a default pbuilder install within etch of a sid chroot. For example: sun-java6-jdk depends on sun-java6-jre sun-java6-jre depends on locales locales in sid is 2.7-0exp6 and depends on glibc-2.7-1 glibc-2.7-1 is not installable. Therefore, sun-java6-jdk is not installable. There are a lot of packages that depend on locales and if locales is not installable within a chroot, then those packages are also not installable. If you believe this is an incorrect dependency, then there are quite a few bugs that need filing. Pulling the locales package from lenny would solve this problem, but that seems somehow dirty. I guess an existing pbuilder would probably also continue as it could just use an older locales to work and that it's just new chroots that are broken. This is a temporary situation, please live with it. I can and happily will. Good luck with the rest of the glibc2.7 transition and thanks again. cheers Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449423: glibc2.7 follow-up
For further information, see http://lists.debian.org/debian-devel/2007/11/msg00033.html -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447525: ITP: jlibeps -- Java library to create EPS images
Package: wnpp Severity: wishlist Owner: Stuart Prescott [EMAIL PROTECTED] * Package name: jlibeps Version : 0.1.0 Upstream Author : Arnaud BLOUIN [EMAIL PROTECTED] * URL : http://jlibeps.sourceforge.net/ * License : GPLv2 or later Programming Lang: Java Description : Java library to create EPS images The jlibeps classes are a set of Java classes for creating EPS images. They are suitable for creating high quality EPS graphics for use in documents and papers, and can be used just like a standard Graphics2D object within Java applications that are using AWT. jlibeps is a fork of the last GPL version of the EpsGraphics2D package from jibble.org. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431905: ITP: latexdraw -- vector drawing program for LaTeX using PSTricks
Package: wnpp Severity: wishlist Owner: Stuart Prescott [EMAIL PROTECTED] * Package name: latexdraw Version : 1.9.3 Upstream Author : Arnaud BLOUIN [EMAIL PROTECTED] * URL : http://latexdraw.sourceforge.net/ * License : GPL Programming Lang: Java Description : vector drawing program for LaTeX using PSTricks LaTeXDraw is a free PSTricks code generator or PSTricks editor for LaTeX. It has the usual drawing tools (lines, rectangles, circles, Bezier curves) and can resize, rotate, move and join objects using vector transformations. Figures can be exported as PSTricks code, eps, jpg, bmp, png, ppm. PSTricks in an extension of LaTeX which allows the creation of drawings, diagrams and graphs in 2D or 3D. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431907: ITP: java-imaging-utilities -- library to load, analyze, process and save pixel images and sample application
Package: wnpp Severity: wishlist Owner: Stuart Prescott [EMAIL PROTECTED] * Package name: java-imaging-utilities Version : 0.14.2 Upstream Author : Marco Schmidt [EMAIL PROTECTED] * URL : http://schmidt.devlib.org/jiu/` * License : GPL Programming Lang: Java Description : library to load, analyze, process and save pixel images and sample application This package is a dependency of latexdraw (see #431905). Three packages from this source package: libjiu-java: JIU, the Java Imaging Utilities, is a library which offers functionality to load, analyze, process and save pixel images. It can handle a variety of different image formats (PBM, PNG, GIF, TIFF, PSD etc) and perform a number of sophisticated transformations to the images including color adjustments, analysis and image filtering. java-imaging-utilities: Demonstration programs that come with the java-imaging-utilities library, found in package libjiu-java. java-imaging-utilities-doc: JIU, the Java Imaging Utilities, is a library which offers functionality to load, analyze, process and save pixel images. This package contains the API documentation for the library. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431908: ITP: libwmfview-java -- library to load and display wmf images
Package: wnpp Severity: wishlist Owner: Stuart Prescott [EMAIL PROTECTED] * Package name: libwmfview-java Version : 0.8.1 Upstream Author : Marco Schmidt [EMAIL PROTECTED] * URL : http://latexdraw.sf.net/ * License : GPL Programming Lang: Java Description : library to load and display wmf images This package is a dependency of latexdraw (see #431905). Provides a GPL java library to permit Java AWT applications to display Windows Meta File (WMF) images. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383019: modify jabref launch script to use a specific java
Hi all, Requiring that the user runs update-alternatives to run jabref is pretty crude and is the source of quite a few not-a-bug-reports against jabref. It possible that this step can be made unnecessary so it would seem sensible to do so. It seems wrong that jabref can insist that the system-wide default java is sun-java what happens if there is another package on the system that requires free-java? The user doesn't want to have to switch back and forth all the time (and only the sysadmin can switch... what if you have multiple users on the box wanting the two apps at the same time?). So there are a few options: * hard code the paths for the sun jre into /usr/bin/jabref But that could be fragile as you say. Still, it would be better than the current situation! Requiring update-alternatives is even more fragile as evidenced by the number of bug reports that are solved just by running update-alternatives. * have /usr/bin/jabref search all versioned paths To start with you could just use either /usr/lib/j2re1.5-sun/bin/java or /usr/lib/j2re1.6-sun/bin/java depending on what is installed. If you wanted to get more fancy, you could iterate over all versioned paths for the form j2re*-sun. That's also potentially inelegant as it doesn't allow the user to specify to use java5 or java6 etc. But it would mean that jabref works out of the box which is a big improvement. * have an extra entry in /etc/alternatives for sunjava This would require cooperation from the packager(s) of the sun-java packages but would probably be the most elegant solution. One would have /usr/bin/sunjava - /etc/alternatives/sunjava - /usr/lib/j2re1.5-sun/bin/java Thus a script can just use /usr/bin/sunjava and get the system-wide default sun-java implementation not just the system-wide java. This seems to me to be the best solution in the long run, but I know little about debian java packaging! cheers Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412504: installation-report: daily netinstall fails desktop task (installation report)
Dear Frans et al., We will need the exact error to further investigate this. Yes, I figured that -- sorry for the useless error report -- I didn't realise that it was all in syslog or I would have sent it with the original bug report. The exact error starts with: W: GPG error: http://download.mirror.ac.uk etch Release: .. And then the killer is later: WARNING: the following packages cannot be authenicated! popularity-contest E: There are problems and -y was used without --force-yes Followed by the prompt that I was able to describe to you earlier. Attached is the syslog(.gz) as requested. I tried a number of different .uk mirrors and ftp.d.o itself and all of them had the same behaviour so it's not just a mirror sync problem. In fact, the only way I was able to successfully complete the installation was by telling the netinst image not to use a mirror and only install the minimalist base system. Enabling security support was OK, however. The only way of proceding from this question was Ctrl+Alt+Del and try again For reference, I was also able to kill aptitude from VT2 which allowed me to back up and have a play. Further investigation with aptitude running the tasksel matching itself seems to show this is an apt key problem and perhaps already known to you. It was a known problem, but one that has been fixed. It should not happen on daily installation images. That was my understanding, hence the bug report. Perhaps this is related, given the timing? http://packages.qa.debian.org/d/debian-archive-keyring/news/20070225T233906Z.html Can you please send us the /var/log/syslog (gzipped!) for a failed installation? Hope it's useful to you cheers Stuart -- Stuart Prescott www.nanoNANOnano.net syslog.gz Description: GNU Zip compressed data
Bug#401901: openoffice.org: oocalc script hides useful -calc option
Hi Jim, Unfortunately, the oocalc program itself doesn't work in this way and the feature is lost. Neither of these work in the desired way: oocalc foo.dat oocalc -calc foo.dat I think this relates to the upstream features. Can you report what happens if the file is re-named to foo.csv before opening? If renamed to csv, then the file is always opened in oocalc. Even if you specify oowriter foo.csv if is openned in oocalc :( I guess the problem is that the openoffice package provides a set of programs (oocalc, oowriter, etc) that claim that they will open your file in the specified component when in actual fact they do not. They just open the file in openoffice and let it work out which component the files should be opened in which it only does by file extension and not by what you actually want to do with the file. If you want to open it in a component then you have to use the (undocumented) soffice program, as pointed out to me by upstream: http://www.openoffice.org/issues/show_bug.cgi?id=72325 Are oocalc etc Debian-isms or are they from upstream? If they are from upstream, then perhaps we should reopen the above bug with the additional details. (Or open a new bug report) cheers Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401901: openoffice.org: oocalc script hides useful -calc option
Package: openoffice.org Version: 2.0.4-7 Severity: minor The oocalc script has a -calc option that only opens a new oocalc session. In fact, there is an option to soffice itself that can also be used to *force* OOo to open a document in calc instead of one of the other components. For example a data file foo.dat can be opened in oocalc rather than oowriter by specifying: soffice -calc foo.dat This is a really useful feature. Unfortunately, the oocalc program itself doesn't work in this way and the feature is lost. Neither of these work in the desired way: oocalc foo.dat oocalc -calc foo.dat With the data file being opened in oowriter instead of in calc. Perhaps the ooo-wrapper script needs changing to respect this option? Perhaps an soffice man page is needed to advertise this option? -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (600, 'testing'), (100, 'stable'), (50, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.4.20060713 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages openoffice.org depends on: ii openoffice.org-base 2.0.4-7OpenOffice.org office suite - data ii openoffice.org-calc 2.0.4-7OpenOffice.org office suite - spre ii openoffice.org-core 2.0.4-7OpenOffice.org office suite archit ii openoffice.org-draw 2.0.4-7OpenOffice.org office suite - draw ii openoffice.org-impress2.0.4-7OpenOffice.org office suite - pres ii openoffice.org-java-common2.0.4-7OpenOffice.org office suite Java s ii openoffice.org-math 2.0.4-7OpenOffice.org office suite - equa ii openoffice.org-writer 2.0.4-7OpenOffice.org office suite - word openoffice.org recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339418: using pdnsd with resolvconf
tags 339418 +patch
thanks, mate
Hi!
I had been happily using ifplugd+guessnet+resolvconf to manage my connection
for the past two years and I stuck with Sarge when it went stable. I am also
using pdnsd as a caching nameserver to speed things up a little. It's been a
very nice setup that all just worked (TM) and I've been really happy with it.
But the other day I held my breath and upgraded to etch and I have since been
having no end of trouble with this combination, particularly with dns lookups
failing all the time. While I expected a few thing to get broken with such a
big upgrade, I didn't expect this would be one of them, and it due to a big
change in the behaviour of resolvconf.
A quick look through /etc/resolv.conf showed me that my nameservers were never
listed in there (127.0.0.1 was in there for pdnsd to work)
but /e/n/interfaces static dns-nameserver entries and dhcp-derived nameserver
entries were never present.
After much frustration and working my way manually through the execution
of /etc/resolvconf/update.d/libc I have tracked it down to the ending at
127.* change.
This is already listed as bug #339418, but I see that it's marked wontfix.
But it makes the pdnsd + resolvconf useless for people who are switching
networks (which after all is the entire point of resolvconf!) ... you might
as well mark them as conflicting.
My understanding is that pdnsd gets its config information about which
nameservers to use from /etc/resolv.conf. So pdnsd will *never* work with
resolvconf as
* 127.0.0.1 (from lo.pdnsd) *must* be first in the file (otherwise pdnsd would
never be used), but
* pdnsd will never see any configuration information because there are no
servers after that configured
In bug #339418 you suggest that the real nameserver could be added
in /etc/resolveconf/resolve.conf.d/tail so that it always shows through.
Unfortunately, this is only a workaround for people who are always sitting on
the one network... (in which case why bother using resolvconf at all?). In my
case, my laptop needs to be able to pick up different dns servers depending
on whether it is at work, at home, an internet cafe, a hotel etc etc and
this is surely not an unusual use and this is exactly what resolvconf is for.
So... I could work around this in a number of ways...
* I can just give up on pdnsd (or any other caching nameserver, I guess)
* I can hack around with interface-order so that lo.pdnsd is *never* picked up
and put 127.0.0.1 in the head file (it can't be in base as you check that
* revert your 127.* change to /etc/resolvconf/update.d/libc myself
None of these is satisfactory and the second two mean messing around with
distributed files and hoping that you don't make too many releases so that I
can do it each time :(
So can you please please please reconsider that #339418 is wontfix? Or
could you at the very least make stopping at a 127.* address a config option
from /etc/default/resolvconf? (something like the attached patch, perhaps...
that's what I'm now running with)
thanks in advance for your assistance
cheers
Stuart
--- libc-dist 2006-03-24 13:35:33.0 +
+++ libc 2006-03-24 15:56:24.0 +
@@ -18,4 +18,5 @@
# Default value
REPORT_ABSENT_SYMLINK=yes
+ALL_SERVERS_127=no
# Default override
@@ -75,5 +76,10 @@
done
NMSRVRS=${NMSRVRS:+$NMSRVRS }$1
- case $1 in (127.*) return 0 ;; esac
+
+case $ALL_SERVERS_127 in
+n|N|no|NO|No)
+case $1 in (127.*) return 0 ;; esac
+;;
+esac
N=$(($N + 1))
[ $N = 3 ] return 0
Bug#295019: #295019 - qemu: -user-net does not work - still a problem
reopen 295019 thanks, mate Hi! With the packages in both Sarge (0.6.1-1) and Sid (0.6.1+20050407-1), this is still a problem. If I pull down the qemu package and run qemu -localtime -cdrom /dev/cdrom -user-net -smb /home/stuart c.vfat then the internal DHCP server does not give the win98 guest an IP address. I pulled down the sources from fabrice.bellard.free.fr/qemu/ and this worked OOTB. Definitely a packaging bug... BTW on a related note, as packaged, the -smb option only works if qemu is run by root (it's a permissions problem on /var/lib/samba -- either qemu needs to do some sudo magic in invoking samba, or use a different samba conf to store the necessary files somewhere more sensible!) kind regards Stuart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297220: incorrect download size still in user prompt
reopen 297220 tags 297220 +patch thanks, mate. Hi Johannes, It seems there is another place to change it still... It would appear that the actual change that I first noted is required in /usr/sbin/update-f-prot, a transcript of the session is below, showing the remark about 1.8MB and then 2.9MiB download. A trivial patch for that script is attached. thanks again! Stuart Setting up f-prot-installer (0.5.14) ... installing f-prot Downloading file fp-linux-ws.tar.gz.md5 from ftp://ftp.f-prot.com/pub/linux/ 10:48:05 URL: ftp://ftp.f-prot.com/pub/linux/fp-linux-ws.tar.gz.md5 [53] - fp-linux-ws.tar.gz.md5 [1] md5sum looks O.K. The two checksums are not identical This usually means that there is a new Version of F-prot for Small Business available. I'm going to download the new version now. Download size is approximately 1.8 MByte. --10:48:05-- ftp://ftp.f-prot.com/pub/linux/fp-linux-ws.tar.gz = `fp-linux-ws.tar.gz' Resolving ftp.f-prot.com... 204.118.23.102, 204.118.23.101 Connecting to ftp.f-prot.com[204.118.23.102]:21... connected. Logging in as anonymous ... Logged in! == SYST ... done.== PWD ... done. == TYPE I ... done. == CWD /pub/linux ... done. == PASV ... done.== RETR fp-linux-ws.tar.gz ... done. Length: 2,974,177 (unauthoritative) 100%[] 2,974,177 72.85K/s ETA 00:00 10:48:49 (70.48 KB/s) - `fp-linux-ws.tar.gz' saved [2974177] . fp-linux-ws.tar.gz successfully downloaded from ftp://ftp.f-prot.com/pub/linux/.. Patching /tmp/fp-unpack.XXX9Kk1H9/f-prot/tools/check-updates.pl ... Patching /tmp/fp-unpack.XXX9Kk1H9/f-prot/man_pages/check-updates.pl.8 ... Checking if virus definitions need to be updated... *** * F-Prot Antivirus Updater* *** There's a new version of: Document/Office/Macro viruses signatures on the web. Starting to download... Download completed. There's a new version of: Application/Script viruses and Trojans signatures on the web. Starting to download... Download completed. Preparing to install Application/Script viruses and Trojans signatures. Application/Script viruses and Trojans signatures have successfully been installed. Preparing to install Document/Office/Macro viruses signatures. Document/Office/Macro viruses signatures have successfully been installed. ** * Update completed successfully. * ** --- update-f-prot 2005-03-14 11:05:26.0 +1100 +++ update-f-prot-dist 2005-03-14 10:58:06.0 +1100 @@ -139,7 +139,7 @@ available. I'm going to download the new version now. -Download size is approximately 2.9 MByte. +Download size is approximately 1.8 MByte. EOF
Bug#297220: f-prot-installer: incorrect download size in user prompt
Package: f-prot-installer Version: 0.5.13 Severity: minor In the prompt to download the new version of f-prot, the script says: I'm going to download the new version now. Download size is approximately 1.8 MByte. However, the actual (current) download is 2.8 MiB (2,912,664 bytes). Not a problem for me (fast connection etc), but others might get a shock when the download is considerably larger than expected! thanks for a really useful script! Stuart -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (600, 'testing'), (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages f-prot-installer depends on: ii debconf 1.4.30.12 Debian configuration management sy ii debianutils 2.8.4 Miscellaneous utilities specific t pn libwww-perl Not found. ii unzip 5.51-2 De-archiver for .zip files ii wget 1.9.1-8retrieves files from the web -- debconf information: f-prot-installer/action: Download and install * f-prot-installer/configured: false f-prot-installer/note_cron: f-prot-installer/where_are_files: /tmp * f-prot-installer/renamed: f-prot-installer/reinstall: true f-prot-installer/failed: * f-prot-installer/update_defs: true f-prot-installer/install_later: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
