Bug#983494: arch-test breaks debootstrap into empty chroot
Package: debootstrap Version: 1.0.123 Severity: normal X-Debbugs-Cc: b...@debian.org Hi - I'm using debootstrap to create a fresh new chroot, and it fails immediately: root:~# /usr/sbin/debootstrap --variant=buildd buster /var/chroot/buster-amd64 E: Unable to execute target architecture root:~# cat /var/chroot/buster-amd64/debootstrap/debootstrap.log amd64: not supported on this machine/kernel root:~# In this example, the directory /var/chroot/buster-amd64 did not previously exist. The problem appears to be at the arch-test stage (line 637 of /usr/sbin/debootstreap), where it runs 'arch-test -c "$TARGET" "$ARCH"' to see if the host and target architectures are compatible. AFAICT, when given a chroot via -c, arch-test looks for its test files *inside* the chroot; however, at this stage debootstrap has not yet done any unpacking (or even any downloads), which means the chroot is empty. This maks arch-test fail, even though the host and target architecture are identical, and in turn this makes debootstrap fail before it has a chance to do any real work. If I comment out the arch-test stage at line 632 (i.e., skipping the arch-test block entirely) then debootstrap runs successfully to completion. Thanks - Ben. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debootstrap depends on: ii wget 1.21-1+b1 Versions of packages debootstrap recommends: ii arch-test 0.17-1 ii debian-archive-keyring 2019.1 ii gnupg 2.2.27-1 Versions of packages debootstrap suggests: pn squid-deb-proxy-client pn ubuntu-archive-keyring -- no debconf information
Bug#839638: RM: regina-normal [armel] -- ROM; std::exception_ptr missing on armel
Package: ftp.debian.org Severity: normal The latest release of regina-normal (5.0) uses the C++ type std::exception_ptr, which appears to be missing on armel. As a result the current package in sid fails to build on armel. See #790896 for a similar instances of this problem, or https://lists.debian.org/debian-arm/2013/12/msg0.html for discussion on this and related issues. This is a specialist package for mathematical research, it has no reverse dependencies other than the science-mathematics metapackage (which recommends it), and I would not be at all surprised if it has no active users on armel at all. Moreover, it will be difficult to rewrite the upstream code to avoid use of std::exception_ptr entirely. Therefore I would like to request that regina-normal be removed from armel, so that regina-normal can transition to stretch. Thanks - Ben.
Bug#836710: pkg_resources: ‘load_entry_point’ crashes without Setuptools
> Had you updated your Sid VM recently? Which version of > ‘python-pkg-resources’ was installed when you experienced that > behaviour? Yesterday. The version you added was correct. - b.
Bug#836710: dput: undeclared dependency on setuptools?
Package: dput Version: 0.10.3 Severity: normal Hi, I tried to run dput today in my sid VM, and it gave the following error: bab@sid-amd64:~/debian$ dput ftp-master regina-normal_4.96-4_amd64.changes Traceback (most recent call last): File "/usr/bin/dput", line 6, in from pkg_resources import load_entry_point File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2976, in @_call_aside File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2962, in _call_aside f(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2989, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 660, in _build_master ws.require(__requires__) File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 968, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 854, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'setuptools' distribution was not found and is required by dput After installing python-setuptools, dput worked properly. I'm not sure whether the python-setuptools dependency belongs in dput or in pkg_resources (which currently declares python-setuptools as a mere Suggests:), but it appears that dput cannot run without it. Regards - Ben. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dput depends on: ii gnupg 2.1.15-2 ii python-debian 0.1.29 ii python-pkg-resources 26.1.1-1 pn python:any dput recommends no packages. Versions of packages dput suggests: ii lintian 2.5.46 pn mini-dinstall ii openssh-client 1:7.3p1-1 ii rsync 3.1.1-3 -- no debconf information
Bug#836678: regina-normal: FTBFS: error: narrowing conversion of '-1' from 'int' to 'char' inside { } [-Wnarrowing]
Thanks for the report.
> /«PKGBUILDDIR»/engine/snappea/kernel/tables.c:229:67: error: narrowing
> conversion of '-1' from 'int' to 'char' inside { } [-Wnarrowing]
I believe this is fixed by declaring the elements of index_by_permutation[] as
signed char, not just char. Caveat: I haven’t tried it yet (I’m away from my
usual machines).
The declarations occur in two places:
- engine/snappea/kernel/tables.c, line 213
- engine/snappea/kernel/tables.h, line 30
The array is never actually used in regina, so there should be no side-effects.
- Ben.
Bug#797292: regina-normal: FTBFS: undefined reference to `srchilite::Utils::toupper...
Thanks for the report; I can reproduce the error here also. I haven’t started digging yet for a resolution, but others may be ahead of me - see bug #797234 for the source-highlight package (on which regina-normal depends, and where the linking looks to be failing). - Ben.
Bug#778104: gcc-5 / regina-normal
I’ve just tried to reproduce this, and I can’t - regina-normal seems to be building fine under current sid/amd64 with gcc-5 and g++-5 installed and the relevant CC / CXX environment variables set. The build log confirms that gcc-5 and g++-5 are indeed being called during the build. I’d be happy if you could do another test rebuild to see if it’s still broken at your end, or if the problem has sorted itself out since the bug was filed back in February. Thanks - Ben. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667354: regina-normal: ftbfs with GCC-4.7
FYI, there will be a new upstream release soon (hopefully next week), which has already fixed this and other gcc-4.7-related issues. - Ben. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556318: regina-normal: update coming RSN
A note for these bug reports: much of the development on regina-normal has been queued up behind the fact that the current version (circa 2009) includes a KDE3-based GUI, and much of the new development has been queued behind the (fairly hefty) port of the GUI (KDE3 - KDE4) and the underlying build system (autotools - cmake). This port has been going on for some time now, and it is (finally) almost over: upstream we are down to final cleanups and testing. I hope to have new debian packages in the archive in early September. I expect this should fix #556318 (with the updated build system) and #624882 (the pending upstream version is building fine on amd64 for me at least). The other RC bug (#624588) involves failed unit tests for the python bindings, and I will need to see how those three architectures deal with the new packages when they're ready (but again, with the new build system I'm at least optimistic about this also). - Ben. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545621: regina-normal: FTBFS: problem linking with boost
Hi, No reply in months, uploading an NMU which fixes this FTBFS. Please find the patch attached. Thanks for this (and apologies for the silence). Ben. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548963: libarchive-zip-perl: New upstream release
Hi Ernesto, Regarding libarchive-zip-perl: If you feel you don't have the time or interest to keep up with libarchive-zip-perl, I can transfer it to the pkg-perl project myself. This is probably best.. alas my free time is not what it once was. :) Thanks for looking after this, Ben. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528334: docbook-utils: incorrectly strips whitespace (patch included)
Package: docbook-utils
Version: 0.6.14-1.1
Severity: normal
Tags: patch
Hi,
In the previous upload, docbook2man was patched to escape the special
characters . and ' at the beginning of a line (see #399947).
Unfortunately that patch was incorrect -- as well as escaping the special
characters, it also removes all whitespace from the beginning of
affected lines. As a result, if you are in a block where whitespace
matters (such as screen.../screen) then the output is now incorrect.
This is very easy to fix -- just match the whitespace and preserve it,
instead of tossing it away. The full patch (just two lines) is included
below.
Thanks - Ben.
--- docbook2man-spec.pl.old 2009-05-12 14:09:13.0 +1000
+++ docbook2man-spec.pl 2009-05-12 14:12:57.0 +1000
@@ -1199,8 +1199,8 @@
$_[0] =~ s/\\//g;
# Escape dots and single quotes in column 1
- $_[0] =~ s/^[ \t]*\././;
- $_[0] =~ s/^[ \t]*\'/'/;
+ $_[0] =~ s/^([ \t]*)\./$1./;
+ $_[0] =~ s/^([ \t]*)\'/$1'/;
# In non-'pre'-type elements:
if(!$nocollapse_whitespace) {
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526199: FTBFS with GCC 4.4: missing #include
Hi, Your package fails to build with GCC 4.4 ... Ah, thanks for picking this up. The problem is now fixed upstream in regina-normal 4.6 which is due to be released in May, so I'll leave the upload until then. Ben. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526192: regina-normal: Python2.6 support
Hi Andreas, When python2.6 is added as default in debian, you will probably run into the same FTBFS issue as we did in Ubuntu. Thanks for that. The problem has been fixed upstream, and the patch will be included in regina-normal 4.6 which is due for release next month. Ben. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525621: Help for KDE 3 apps no longer works (patch included)
Package: kdelibs
Version: 4:3.5.10.dfsg.1-2
Severity: normal
Tags: patch
Hi,
Now that debian has switched to KDE 4, the standard Help - Handbook menu
entries fail for KDE 3 applications, typically with an error such as
Could not find service 'khelpcenter'.
If you wish to explicitly reproduce this bug, you can install regina-normal,
run the program regina-kde, and try Help - Regina Handbook. However, I
expect the same thing will happen for almost any KDE 3 app.
It seems that KDE 4's help centre is indeed able to read KDE 3's docbook
help files; it's just a matter of pointing KDE 3 applications to the
correct help viewer. The ubuntu people fixed this in jaunty by patching
KApplication::invokeHelp() -- the relevant patch is
kubuntu_98_fix_khc_invocation.diff, and I have included it below.
I would be grateful if debian could apply this to its kdelibs packages
also -- this would be a great help for the usability of KDE 3 apps,
by restoring easy access to documentation.
Thanks - Ben.
diff -Nur -x '*.orig' -x '*~' kdelibs-3.5.10.dfsg.1/kdecore/kapplication.cpp
kdelibs-3.5.10.dfsg.1.new/kdecore/kapplication.cpp
--- kdelibs-3.5.10.dfsg.1/kdecore/kapplication.cpp 2008-08-19
20:18:18.0 +0200
+++ kdelibs-3.5.10.dfsg.1.new/kdecore/kapplication.cpp 2009-01-18
16:25:42.0 +0100
@@ -2236,20 +2236,14 @@
url = QString(help:/%1/index.html).arg(appname);
QString error;
- if ( !dcopClient()-isApplicationRegistered(khelpcenter) )
- {
- if (startServiceByDesktopName(khelpcenter, url, error, 0, 0,
startup_id, false))
- {
- if (Tty != kapp-type())
- QMessageBox::critical(kapp-mainWidget(), i18n(Could not
Launch Help Center),
- i18n(Could not launch the KDE Help Center:\n\n%1).arg(error),
i18n(OK));
- else
- kdWarning() Could not launch help:\n error endl;
- return;
- }
- }
- else
- DCOPRef( khelpcenter, KHelpCenterIface ).send( openUrl, url,
startup_id );
+ // TODO this should check if cmd has a .desktop file, and use data from it,
together
+ // with sending more ASN data
+ if (kdeinitExec(khelpcenter, url, error, NULL, startup_id ))
+ if (Tty != kapp-type())
+ QMessageBox::critical(kapp-mainWidget(), i18n(Could not Launch Help
Center),
+ i18n(Could not launch the KDE Help Center:\n\n%1).arg(error),
i18n(OK));
+ else
+ kdWarning() Could not launch help:\n error endl;
}
#endif
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476029: regina-normal: FTBFS: /bin/sh: -O2: command not found
severity 476029 important tags 476029 +pending thanks Hi, During a rebuild of all packages in sid, your package failed to build on i386. AFAICT the problem is because your build environment already has pre-set CFLAGS and CXXFLAGS (both set to -g); it should not happen in a clean build environment. For this reason I'm downgrading the bug to important. Of course it still needs to be fixed (and this should just be matter of a couple of quotes in debian/rules). I'll need to do a new upload soon for the python transition, and I'll include the fix in that. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473973: [pkg-boost-devel] Bug#473973: libboost-python-dev: rdeps fails to built - python packaging seems weird
Hi Sune, kdeedu build doesn't fail by itself if it isn't found as it is only optional, but we test afterwards if it is actually build. As an aside, what I've done with regina-normal (which also uses boost.python) is make debian/rules check the config.log immediately after configure finishes, to see whether it plans to build in boost.python or not. This means it can detect the problem (and abort accordingly) at the beginning of the build, which could be useful if kdeedu still takes as long to build as I remember it used to. :) Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468997: python-pgsql: may use different memory API for a given memory block
Hi, Some initial examination suggests that this is a false positive, but I will check all uses of PyMem_* thoroughly at a later date before closing this report. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#435669: Try to split koffice-doc package
Hi, Just happened to see this one as it went past my full and largely unread kde/qt inbox... Thank you for your answer. But is koffice HTML documentation (as provided by koffice-doc-html) still integrated with KHelpCenter ? If true, this bug can be closed for me. I was the one who added koffice-doc-html back in 2001. The situation was (and possibly still is) this: - If you are a KDE user, you can view help for koffice apps in the KDE help centre. This reads the docbook files directly, and so you don't need koffice-doc-html at all. - If you are a GNOME user (or twm or whatever), and you don't have the full kdebase infrastructure installed (in particular, you don't have khelpcenter), and you just have kword/kspread/etc installed because you like them as individual apps, then you cannot view the docbook help files directly. This is why koffice-doc-html was created -- it builds HTML files in advance and installs them in a place where non-KDE users can read them in HTML with their favourite web browsers. So essentially koffice-doc-html is irrelevant to regular KDE people; it only exists to help other users who for whatever reason are dipping their toes in the KDE world. As an aside, if there are plans to remove koffice-doc-html, I'd suggest bumping khelpcenter up from a suggests to a recommends. Actually, given that the installed-size of khelpcenter is smaller than koffice-doc-html, perhaps this is a good idea? *shrug* b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445248: Decompyle and python2.5
Hi, To anyone who might be NMUing this: - It's not clear that decompyle will work under python2.5 (there are sometimes difficulties moving between python versions), although of course this doesn't mean it won't. - Even if it builds under python2.5, it's not clear that it's running correctly. You will need to do some non-trivial testing to be happy that it's doing the right thing. Ta - Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442442: Bug#442417: recommends imagemagick
Hi, This is specifically a response to the konq-plugins bug. However, I'm CCing it to the similar kdebase bug that appeared recently since I expect the general issues involved are the same. Anyway, regarding konq-plugins: konq-plugins recommends imagemagick, presumably for the image gallery creation plugin. It must be a good idea that imagemagick is suggested, but it shouldn't be recommended since image gallery creation is not the only plugin. The counterargument is: Suppose a user installs konq-plugins, expecting that the plugins will just work. If a user tries to use a plugin that needs some missing program: 1. In the worst case the plugin will fail or crash with a mysterious error message that means little to the user. 2. In an ideal world, the plugin will pop up a pretty dialog that says sorry, you need to install the foobar package. This probably won't happen unless somebody goes through and patches the KDE sources to describe debian package requirements. 3. In probably the best case that we can realistically hope for, the plugin will pop up a dialog that says I cannot find /usr/bin/ dofoobar, at which point the user rummages about to find which debian package provides /usr/bin/dofoobar and then installs it themselves. I'd argue that for users who don't know what they're doing, we should avoid (1) at all costs. At the other end of the spectrum, I'd say that (2) is perfectly acceptable but will probably not happen in reality since it requires constant maintenance of debian-specific patches. On the other hand, I'd say that (3) is fine for experienced users who know what they're doing. This is more or less what recommends are for. So I'd argue that recommending imagemagick is indeed the correct solution (I was even more conservative when I maintained konq-plugins -- IIRC I had it as a depends). In particular, my vote (for what it's worth) is that imagemagick should not be weakened to a suggests. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334015: python2.3-dbg: missing gdbinit
Hi, Python 2.3 is no more in Debian, Can you please check if this applies to python2.4-dbg as well? The gdbinit and README.Debian in python2.4-dbg look fine to me --- I'm happy for this to be closed. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391672: quanta: Recommonds non-free and transitional phpdoc
Package: quanta Version: 4:3.5.4-1 Severity: serious Hi, I was cleaning out my system today and noticed that quanta recommends phpdoc, which is a transitional package. Presumably this should be changed to php-doc instead. However: I then noticed that php-doc is in non-free, which is more of a problem (and which is why I've marked this serious) -- policy states that packages in main cannot recommend or depend on contrib/non-free packages. I'm not sure what the correct solution is here; it's been some time since I was working with quanta. IIRC, in the days when I looked after it the recommends was to keep the documentation pane behaving itself. What happens is that quanta ships with php.docrc, which provides the index; thus the documentation pane gives you a full table of contents that you can navigate around, whether the real docs are actually installed or not. I guess the easiest solution is downgrade this to a suggests, and leave a note somewhere for the user to read explaining how to fix the file not found errors in the documentation pane (solution: install php-doc). Hmm. Actually -- having looked at this now, you get file not found even if php-doc _is_ installed. This is because the /usr/share/apps/quanta/doc/php symlink is broken (it points into the old /usr/share/doc/phpdoc instead of the new /usr/share/doc/php-doc). Thus even if the user does have php-doc installed, the documentation pane will refuse to show it to them. So.. apologies for the stream of consciousness here (and for what has turned out to be two bug reports in one); I'm kind of rushed ATM. My suggested solution is: 1. Change Recommends: phpdoc to Suggests: php-doc (note that both the relationship and the package name have changed); 2. Add a note to README.Debian explaining what to do if you get file-not-found errors in your documentation pane (solution is to install the relevant doc package); 3. Fix the /usr/share/apps/quanta/doc/php symlink to point to /usr/share/doc/php-doc/html instead of /usr/share/doc/phpdoc/html . Step (1) will be enough to fix the RC element of this bug, but steps (2) and (3) are easily done at the same time. Thanks - Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages quanta depends on: ii kdelibs4c2a4:3.5.4-3 core libraries and binaries for al ii kfilereplace 4:3.5.4-1 batch search-and-replace component ii klinkstatus4:3.5.4-1 web link validity checker for KDE ii kommander 4:3.5.4-1 visual dialog builder and executor ii libacl12.2.41-1 Access control list shared library ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libattr1 2.4.32-1 Extended attribute shared library ii libaudio2 1.8-2 The Network Audio System (NAS). (s ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii libcvsservice0 4:3.5.4-1 DCOP service for accessing CVS rep ii libfam02.7.0-10 Client library to control the FAM ii libfontconfig1 2.4.0-5 generic font configuration library ii libfreetype6 2.2.1-5 FreeType 2 font engine, shared lib ii libgcc11:4.1.1-13GCC support library ii libice61:1.0.1-2 X11 Inter-Client Exchange library ii libidn11 0.6.5-1 GNU libidn library, implementation ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libpcre3 6.4-2 Perl 5 Compatible Regular Expressi ii libpng12-0 1.2.8rel-5.2 PNG library - runtime ii libqt3-mt 3:3.3.6-4 Qt GUI Library (Threaded runtime v ii libsm6 1:1.0.1-2 X11 Session Management library ii libstdc++6 4.1.1-13 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.0-9 X11 client-side library ii libxcursor11.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxft22.1.8.2-8 FreeType-based font drawing librar ii libxi6 1:1.0.1-3 X11 Input extension library ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxml22.6.26.dfsg-3 GNOME XML library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender11:0.9.1-3 X Rendering Extension client libra ii libxslt1.1 1.1.17-4 XSLT processing library - runtime ii libxt6 1:1.0.2-2 X11 toolkit
Bug#377312: num-utils: typo in long description
Package: num-utils Severity: minor Hi, The long description for num-utils includes the line: * numround: Round each number according to it's value. The word it's should actually be its (no apostrophe). This is one of the terribly many grammatical exceptions in English; the word it's is only ever used as a contraction for it is. Thanks - Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377333: lp-solve: little/no documentation
Package: lp-solve Version: 5.5-2 Severity: important Hi, I've recently installed both lp-solve and liblpsolve55-dev, in the hope that I can use them in some mathematics work that I am doing. Unfortunately I can find no documentation at all in either of these packages that shows me how to use them. For lp-solve, all there is is a README.txt.gz that discusses features but no actual instructions on how to use the program lp_solve. There is no manpage either. The best I could get was the output from lp_solve --help, which gives a flood of command-line options but still leaves out critical information such as what needs to go in the input file. For liblpsolve55-dev, the only documentation seems to be a single example file (demo.c). Whilst this gives hints at how to use the library, it still basically leaves the programmer guessing at the finer details, which from a programming point of view is somewhat dangerous (are there any constraints? preconditions? limitations?). The headers themselves contain almost no information of this sort either. In my opinion, software of this nature desperately needs some form of information for both the casual user (lp-solve) and the programmer (liblpsolve55-dev). Otherwise you are more or less left guessing; even if you do manage to fumble your way around and get some results, you cannot rely on them because you don't know whether you've used the program/library correctly or not. (It is for this reason that I've filed this bug as important: a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone.) I presume there is documentation available -- the lp-solve README.txt.gz refers to full source, examples and manuals, asks the reader to See the reference guide for more information, and in fact speaks of the documentation more precisely: The html files are also in lp_solve_5.5_doc.tar.gz. Start with index.htm ... Also see http://lpsolve.sourceforge.net/ for a on-line documentation. For online users, this is inconvenient (having to locate and download the docs separately); for offline users this is impossible. My suggestion here would be to bundle up this documentation and either include it with lp-solve or as a separate lp-solve-doc package, and if you use a separate package then make a note in README.Debian for both the lp-solve and liblpsolve55-dev packages so users know where to find it. I would also suggest restoring the lp_solve.1 manpage; looking at the debian changelogs, it seems there was a manpage some time in the past; it would be useful if this could be included again (and presumably updated where appropriate). Anyway, that's all from me. It does look like a useful package; it's just unfortunate that (unlike your typical GUI tool or self-documenting proglet) it's more or less impossible for the average user to guess their way through the system based on what debian is currently shipping. Many thanks, Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages lp-solve depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libufsparse 1.2-6 collection of libraries for comput lp-solve recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371062: Bug#371060: libgcj7-dev
No, its enough to rebuild the package with the new gcc package pointing to gcc-4.1 installed. Sure, but relying on (build-essential + libgcj-dev) assumes that the gcc and gcj versions will always be the same. Past experience has suggested this is not the case, which is why I've leaned towards java-gcj-compat-dev instead. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371060: Bug#371062: Bug#371060: libgcj7-dev
IMO its now the best time to get rid of this package totally. FWIW, I'd forgotten that java-gcj-compat-dev even existed until your mailout to d-d-announce last month (GCJ 4.1 transition). In this mailout you ask maintainers of JNI packages to use -I/usr/lib/jvm/java-gcj/include, which relies on symlinks provided by java-gcj-compat and java-gcj-compat-dev. Having said that, I don't particularly care if those packages stay or go. However, if they go then I'd love another mailout explaining the new preferred long-term way of building against jni.h (or, if we are meant to switch to relying on default include paths, some indication that you plan to keep the gcc/gcj versions in sync). Thanks - b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#371060: libgcj7-dev
Hi, Probably a solution would be including libgcj7-dev. It does. It build-depends on libgcj-dev (= 4:4.1.0), which brings in libgcj7-dev. From the amd64 build log (which failed in this way): Unpacking libgcj7-dev (from .../libgcj7-dev_4.1.1-2_amd64.deb) ... I suspect my problem is -I/usr/lib/jvm/java-gcj/include ; the symlinks that point from there to the real jni.h are provided by java-gcj-compat and java-gcj-compat-dev, which I don't build-depend on. It seems the real filenames are now gcc-version-dependent, and look something like /usr/lib/gcc/i486-linux-gnu/4.1.1/include/jni.h, which I expect gcc won't find unless your gcc and gcj versions are the same. So it seems I need to build-depend on java-gcj-compat-dev if I don't want to hard-code the (gcc-version-dependent) path to jni.h. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370183: FTBFS with GCC 4.2: templates may not be 'virtual'
4.2 hasn't even been released yet and won't be for another few months. Thanks; will leave it till upstream 4.3.2 then. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370183: FTBFS with GCC 4.2: templates may not be 'virtual'
Hi, Virtual templates are apparently not allowed in C++ and GCC 4.2 will treat them as errors. Thanks for picking this up. It's now patched upstream for the next release (4.3.2). If g++-4.2 is likely to become default within the next couple of months, I'll patch the debian packages now; otherwise I'll just wait for the next upstream release and close the bug then. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361418: [SPAM?]: Bug#361418: Debian menu and the Apps/Science section
I think it's wonderful that scientists get so much value out of mathematical software, but they are not the only ones -- why does this mean that every piece of mathematical software needs to be filed in the science drawer? Because it is not always possible to draw a clear line between mathematical and (other) scientific software. Often you would have to check both sections to locate an application. Having both of them closer together could reduce confusion. For the scientist, yes. For the economist it's more confusing, and for the mathematician (well, this mathematician at least) it's just annoying. Probably the best analogy I can think of is for a physicist to find all of her applications filed under engineering (because, hey, physics underlies a lot of engineering, and for some software the distinction is not so clear). Anyway. I've said my piece on this. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361418: Debian menu and the Apps/Science section
I added another section named Analysis, that contains general data analysis/plotting/calculation applications. I find them very similar to what is found in Math, so I consider moving Mathematics to Science a good idea. Again: we see that scientists make heavy use of mathematics, so all mathematics packages should be classified under Science? We might as well file all mathematics packages under Economics for the same reason. I think it's wonderful that scientists get so much value out of mathematical software, but they are not the only ones -- why does this mean that every piece of mathematical software needs to be filed in the science drawer? Currently mathematics and science have their own sections in all the places I frequent (debian archive sections, the KDE menu, the debian menu system); this seems quite sane to me, and it's not clear to me why this needs to be changed. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361418: Debian menu and the Apps/Science section
Unconvinced. Theoretical chemistry, as an example, is largely mathematics. But not only in the sense below engineering/physics. To develop novel theoretical chemistry, new mathematics has to be invented. The same for physics/mathematics: remember that Newton had to invent (I know that in some quarters the invention is attributed to another scientists, but the latter was a professional physicist too) infinitesimal calculation. In my mathematics research, I am currently working on problems in computational geometry and topology. The work I am doing is largely algorithmics. Moreover, to obtain new topological results, new data structures had to be invented. This does not mean that algorithmics is a branch of topology. Nor does it mean that data structures is a branch of topology. And it would certainly be very strange for a computer scientist to find all their material on algorithms and data structures filed under Geometry and Topology. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361418: Debian menu and the Apps/Science section
Oh, and a minor typo: The relevant sections are: Mathematics [was:Math] Mathematics-related software. gcalctool, snapea, xeukleides The snappea package has two ps. Ben (the snappea maintainer). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361418: Debian menu and the Apps/Science section
Hi, I think Mathematics is also part of Science. FWIW, I would argue that mathematics is not a science -- it does not use the scientific method, there is no hypothesis and experimentation -- it is a more self-contained discipline that, while it seeks to be useful, is not bound to modelling the physical world. Certainly science _uses_ mathematics, in the same way that engineering uses physics, and so on. But mathematics as a whole is somewhat broader. Anyway, I'd be very happy to see Mathematics and Science kept separate as they are now. I do claim that mathematics is very different from the other disciplines that have been mentioned, in a way that physics, chemistry, biology and so on are not. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361418: Debian menu and the Apps/Science section
FWIW, I would argue that mathematics is not a science -- it does not use the scientific method, there is no hypothesis and experimentation -- it is a more self-contained discipline that, while it seeks to be useful, is not bound to modelling the physical world. I think of new ways to try and simulate things faster or in a simpler way. Then i'll write the simulation and try the ideas and measure its performance and accuracy. This applied mathematics is very much like a real-world engineering problem with hypothesis and experimentation. Hmm, perhaps I didn't express myself properly. Of course, any discipline can use hypothesis and experimentation, from the arts to astrology. What I mean is: in the physical sciences, hypothesis and experimentation are fundamental to building scientific truth. This is because the basis of science is trying to understand the physical world, formulating theories that explain what is seen, and then testing and refining these theories. This is what the scientific method is for. On the other hand, mathematical truth is based on pure logic and proof. It need not have any link to the physical world (though it often does). Experimentation can be a useful guide, but it is certainly not essential, and indeed experimental results are generally not accepted as a method of establishing mathematical facts. The result of all of this is that mathematicians can be more sure of their truths than scientists, but on the other hand their work is often somewhat less useful from a practical point of view. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355996: Processed: tagging 355996
tags 355996 - patch thanks dear Hi, There are a number of gcc-4.1 build errors with magnus; the patch submitted to the BTS only addresses the simpler errors and not the harder ones. I'm therefore removing the patch tag for now, since this is not a simple thing that can be applied and uploaded to fix the breakages. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361406: ftp.debian.org: Please remove decompyle2.2 from unstable/testing
Package: ftp.debian.org Severity: normal Hi, The decompyle2.2 package is a legacy package, offered in debian as a safety net in case the newer (and heavily redesigned) decompyle should fail. However, decompyle2.2 requires python2.2 -- no newer python version will work. With the coming removal of python2.2, it seems that decompyle2.2 has reached the end of its life. Please remove decompyle2.2 from unstable (and testing when appropriate). Thanks, Ben (decompyle2.2 maintainer). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360175: linux-image-2.6-vserver-686: description identical to non-vserver packages
Package: linux-image-2.6-vserver-686 Severity: minor Hi, The new linux-image-X-vserver-Y packages all appear to have short and long descriptions that are identical to the corresponding non-vserver linux-image-X-Y packages. (I have only verified this for linux-image-2.6-vserver-686 and linux-image-2.6.16-1-vserver-686, but I presume it happens for other archs also). This makes it quite difficult to tell what the difference is between the vserver and non-vserver packages. It would be great if you could add some text to the vserver kernel package descriptions explaining how they differ from the plain kernels. Thanks - Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359737: Please remove build-dependency on libgcj-dev
Given that gcj depends on the -dev package ... Ah, so it does. This used to be a recommends only (hence the extra -dev build-depends). Please drop it. Will do. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347320: KNemo bug reproducible
Hi, I get this problem also. What is happening on first reboot is this: I log into KDE and the KNemo icon appears in the top-left corner of the screen (not in the system tray). The icon is stuck above everything else (i.e., it obstructs whatever is supposed to be in that corner and cannot be moved out of the way). There is a _space_ for knemo in the system tray, i.e., a 22x22 gap where it is presumably supposed to be sitting. It's just that the knemo widget doesn't get put there. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355483: drgeo-doc: depends on dillo (extra)
Package: drgeo-doc Version: 1.5-2.1 Severity: serious Hi. It seems that drgeo-doc (optional) depends on the web browser dillo (extra). This means that a higher-priority package depends on a lower-priority package, which is not allowed by policy (section 2.5). However, I don't see why dillo is required at all -- as far as I can see, the drgeo documentation is shipped as HTML which means it should be readable by any web browser. I would therefore suggest replacing the dillo dependency with the virtual package www-browser instead. When choosing the default browser, I'd also suggest something more low-impact, such as lynx or w3m. e.g.: Depends: w3m | www-browser Thanks - Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315289: Orphaning jython
retitle 315289 O: jython -- Python seamlessly integrated with Java thanks mate Hi all, This is an FYI that I've just orphaned jython, as of version 2.1.0-21. As when I orphaned it last June, my time is squeezed and I don't use java much at all nowadays. Again, see #315289 for a summary of relevant issues if you are looking at adopting it. This is one of those packages that is keeping python2.1 in the archive, so I expect someone will either want to take it over or have it removed completely at some stage. If you are adopting it and you have any questions, please feel free to mail me. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315289: Orphaning jython
If you are okay with this I will adopt it under the Debian Java Maintainers group coordination. I will take care of it and do an upload to show this in the next days. Works for me -- thanks for looking after it. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353814: Forwarded meinproc bug
forwarded 353814 http://bugs.kde.org/show_bug.cgi?id=122465 thanks mate Hi, I've filed this one upstream as well (#122465). FYI. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353795: collatinus-doc: please give a proper description
Package: collatinus-doc Severity: minor Hi, Currently the long description for collatinus-doc is: html and pdf files. This is extremely brief (in fact it's not even a sentence), and it says nothing about what collatinus is. Could the long description be changed to use proper sentences, and to say a little more about the package? e.g.: This package provides documentation for Collatinus in HTML and PDF formats. . Collatinus is an application for lemmatising Latin texts, and it provides a nice graphical front-end. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353814: kdelibs-bin: meinproc is relicensing my code
Package: kdelibs-bin Version: 4:3.5.1-2 Severity: serious Hi, I have a KDE application whose documentation is licensed under the GPL. In particular, its index.docbook contains the line: legalnoticeunderGPL;/legalnotice When I build the application and meinproc is run over the docbook files, it generates an HTML index that looks like: Title (large bold heading) Author Revision number Copyright notice Legal Notice Abstract ... In past versions of KDE, the legal notice was actually a short blurb stating which license was used. Now it is simply a hyperlink with the two words Legal Notice. So: To find out the license, you must click on the Legal Notice hyperlink, and --- it sends you to help:/common/fdl-notice.html, which states that the documentation is licensed under the GFDL version 1.1 or later. For the obvious reasons, I most certainly do _not_ want my documentation licensed under the GFDL. It is GPLed, as stated in index.docbook, and the documentation that appears in the help centre should not be telling users something different. I am marking this bug as serious, since meinproc is used to generate all of the KDE help centre documentation, and so users are being presented with license information that is incorrect. As for the cause: I'm not too familiar with meinproc internals, but I suspect the culprit is /usr/share/apps/ksgmltools2/customization/kde-chunk.xsl. Around lines 90--100 it does look rather like the fdl-notice is being dropped into the documentation regardless of what actually appears inside the legalnotice tag. Ben. -- System Information: Debian Release: testing/unstable Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Versions of packages kdelibs-bin depends on: ii kdelibs4c2a 4:3.5.1-2 core libraries for all KDE applica ii libart-2.0-2 2.3.17-1Library of functions for 2D graphi ii libaudio21.7-4 The Network Audio System (NAS). (s ii libbz2-1.0 1.0.3-2 high-quality block-sorting file co ii libc62.3.6-1 GNU C Library: Shared libraries an ii libcupsys2 1.1.23-15 Common UNIX Printing System(tm) - ii libfontconfig1 2.3.2-2 generic font configuration library ii libfreetype6 2.1.10-1FreeType 2 font engine, shared lib ii libgcc1 1:4.0.2-9 GCC support library ii libice6 6.9.0.dfsg.1-4 Inter-Client Exchange library ii libidn11 0.5.18-1GNU libidn library, implementation ii libjpeg626b-11 The Independent JPEG Group's JPEG ii libpng12-0 1.2.8rel-5 PNG library - runtime ii libqt3-mt3:3.3.5-3 Qt GUI Library (Threaded runtime v ii libsm6 6.9.0.dfsg.1-4 X Window System Session Management ii libstdc++6 4.0.2-9 The GNU Standard C++ Library v3 ii libx11-6 6.9.0.dfsg.1-4 X Window System protocol client li ii libxcursor1 1.1.3-1 X cursor management library ii libxext6 6.9.0.dfsg.1-4 X Window System miscellaneous exte ii libxft2 2.1.8.2-3 FreeType-based font drawing librar ii libxi6 6.9.0.dfsg.1-4 X Window System Input extension li ii libxinerama1 6.9.0.dfsg.1-4 X Window System multi-head display ii libxml2 2.6.23.dfsg.2-1 GNOME XML library ii libxrandr2 6.9.0.dfsg.1-4 X Window System Resize, Rotate and ii libxrender1 1:0.9.0.2-1 X Rendering Extension client libra ii libxslt1.1 1.1.15-3XSLT processing library - runtime ii libxt6 6.9.0.dfsg.1-4 X Toolkit Intrinsics ii menu-xdg 0.2.2 freedesktop.org menu compliant win ii perl 5.8.8-2 Larry Wall's Practical Extraction ii python 2.3.5-5 An interactive high-level object-o ii zlib1g 1:1.2.3-9 compression library - runtime Versions of packages kdelibs-bin recommends: ii perl-suid 5.8.8-2Runs setuid Perl scripts -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353814: kdelibs-bin: meinproc is relicensing my code
Hi again, Just to confirm: As for the cause: I'm not too familiar with meinproc internals, but I suspect the culprit is /usr/share/apps/ksgmltools2/customization/kde-chunk.xsl. Around lines 90--100 it does look rather like the fdl-notice is being dropped into the documentation regardless of what actually appears inside the legalnotice tag. If you comment out lines 90--100 (the xsl:template block that deals with legalnotice), the GFDL link goes away and the correct notice is displayed instead (in my example, it correctly states that the program is licensed under the GPL). This should give you a quick fix for the RC bug. However, this is a rather serious issue -- meinproc should not be arbitrarily changing authors' licenses, and for some licenses (such as GPL) it _cannot_ relicense under the GFDL. This does therefore need to go upstream; I would be most appreciative if whoever is best in touch with upstream these days could do this. Thanks - Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349730: jikes-gij: Uninstallable; please depend on libgcj6-jar
Package: jikes-gij Version: 1:1.22-3 Severity: serious Hi, Currently jikes-gij is uninstallable in sid, since none of the libgcj*-common dependencies can be satisfied. It seems the jar is now provided by libgcj6-jar, not libgcj6-common. I therefore suspect that you'll be fine if you add a libgcj6-jar option to the dependency list. Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346323: libgphoto2-2: Canon IXUS 750 does not set camera group permissions
Package: libgphoto2-2
Version: 2.1.6-6
Severity: normal
Hi,
It seems libgphoto2-2 with udev does not support the Canon IXUS 750, at
least in the sense that the device is not getting permissions for the
camera group, and so gphoto2 must be used as root.
Adding the following line to /etc/udev/rules.d/025_libgphoto2.rules
fixes it for me:
# Canon Digital IXUS 750 (PTP mode)
SYSFS{idVendor}==04a9, SYSFS{idProduct}==3116,
RUN+=/etc/hotplug/usb/libgphoto2
I presume this is something that needs to be included in the output of
/usr/lib/libgphoto2/print-udev-rules.
The relevant section of /proc/bus/usb/devices is:
T: Bus=03 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 12 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=04a9 ProdID=3116 Rev= 0.02
S: Manufacturer=Canon Inc.
S: Product=Canon Digital Camera
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 2mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=06(still) Sub=01 Prot=01 Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=83(I) Atr=03(Int.) MxPS= 8 Ivl=64ms
Thanks - Ben.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages libgphoto2-2 depends on:
ii adduser 3.80 Add and remove users and groups
ii libc6 2.3.5-9GNU C Library: Shared libraries an
ii libexif12 0.6.12-2 library to parse EXIF files
ii libgphoto2-port0 2.1.6-6gphoto2 digital camera port librar
ii libjpeg62 6b-11 The Independent JPEG Group's JPEG
Versions of packages libgphoto2-2 recommends:
ii udev [hotplug]0.079-1/dev/ and hotplug management daemo
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308987: Doc-base file fixed
close 308987 4.2-2 thanks mate The doc-base file was fixed in the 4.2-2 upload on 29 Aug 2005. Closing this bug accordingly. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337412: Intention to NMU
Hi Luk, There's a couple of other patches queued that I might take another look at -- the larger python-pgsql update has been stalled to date because of a bug in python2.4. At any rate, since this is a serious issue I'll do an upload this week. If you haven't heard from me by the weekend, please go ahead with the NMU. Ta - Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342631: kile-i18n: uninstallable due to non-binNMU-safe dependency on kile
A no source-changes upload should be enough to fix this bug, thanks in advance. I can also provide a NMU if needed. Please do -- I'm out of action here until Dec 15. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337412: python2.1-pgsql: Uninstallable due to unavailable python2.1-egenix-mxdatetime
python2.1-egenix-mxdatetime is not available in sid. Maybe python2.1-pgsql should be dropped in favor of python2.4-pgsql? There are problems with bringing in python2.4-pgsql, see #334022. However, I'll do an upload this weekend that removes 2.1 and 2.2 (this has been waiting in the wings for some time until 2.4 was ready). Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315340: Orphaning kbear
Hi, I'm looking at my time constraints (which are not getting any better these days), and I've decided I will need to orphan kbear. I'm making my last upload today to change maintainer to the Debian QA group. Pedro: Are you still interested in adopting kbear? If not, please let me know and I'll retitle this bug to O: (or please feel free to do it yourself). If you are still interested then that's fine (but due to said time constraints I'm afraid I won't be able to act as sponsor). If anyone else is looking at this package, please see the initial message on http://bugs.debian.org/315340 for some notes about what may be involved if you choose to adopt it. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334174: ftp.debian.org: please remove gb from unstable/testing
Package: ftp.debian.org Severity: normal Hi. I currently maintain gb (Gnome Basic). This software was officially abandoned by upstream some years back, with its final release in 2001. Now that the mono project ships with a VB-like BASIC compiler, this package is also redundant. Please remove the gb source package and its associated binary packages from unstable (and from testing when appropriate). Thanks - Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334015: python2.3-dbg: missing gdbinit
Package: python2.3-dbg Version: 2.3.5-8 Severity: minor Hi, In python2.3-dbg's README.Debian, it says: For debugging python and extension modules, you may want to add the contents of /usr/share/doc/python2.3/gdbinit to your ~/.gdbinit file. However, there is no gdbinit shipped with python2.3. I presume either the missing gdbinit should be added to python2.3, or else this message should be removed from python2.3-dbg. Thanks, Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages python2.3-dbg depends on: ii blt 2.4z-3 the BLT extension library for Tcl/ ii libbz2-1.01.0.2-10 high-quality block-sorting file co ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libdb4.3 4.3.28-3 Berkeley v4.3 Database Libraries [ ii libgdbm3 1.8.3-2GNU dbm database routines (runtime ii libgmp3c2 4.1.4-10 Multiprecision arithmetic library ii libncurses5 5.4-9 Shared libraries for terminal hand ii libreadline5 5.0-11 GNU readline and history libraries ii libssl0.9.7 0.9.7g-2 SSL shared libraries ii libx11-6 6.8.2.dfsg.1-8 X Window System protocol client li ii python2.3 2.3.5-8An interactive high-level object-o ii tcl8.48.4.11-1 Tcl (the Tool Command Language) v8 ii tk8.4 8.4.11-1 Tk toolkit for Tcl and X11, v8.4 - ii xlibs 6.8.2.dfsg.1-8 X Window System client libraries m ii zlib1g1:1.2.3-4 compression library - runtime python2.3-dbg recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334022: python2.4: incomplete numerical comparisons
Package: python2.4 Version: 2.4.2-1 Severity: normal Hi, I've been tracking down the regression failure in python-pgsql under python2.4, and here's what it comes down to. Python-pgsql includes a short int type named PgInt2, which allows itself to be coerced into all of the usual numeric types. The regression that fails is when a PgInt2 is compared with a float. In this case python determines that the comparison is not implemented. The problem is this: - Under python2.4, the float type includes tp_richcompare but not tp_compare. - When calling try_rich_to_3way_compare(), python does not try any kind of numeric coercion, and so the comparison fails. - When calling try_3way_compare(), python successfully coerces the PgInt2 into a float, but then the comparison fails because the float type has no tp_compare routine. Presumably what would fix things would be one of the following: - Bring back the trivial float_compare() routine, which was removed with python2.4 when they brought in the new float_richcompare() instead; - In try_3way_compare(), if the coercion succeeds and neither object has a tp_compare routine, try tp_richcompare before failing completely. Does either of these solutions seem feasible? Thanks - Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages python2.4 depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libdb4.3 4.3.28-3 Berkeley v4.3 Database Libraries [ ii libncurses5 5.4-9 Shared libraries for terminal hand ii libreadline5 5.0-11 GNU readline and history libraries ii libssl0.9.7 0.9.7g-2 SSL shared libraries ii python2.4-minimal 2.4.2-1A minimal subset of the Python lan python2.4 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333497: CAN-2005-2971: Heap overflow in kword's RTF import
An exploitable heap overflow has been found in kword's RTF import function. The patch for sarge was already sent to the security team earlier today, and the sid packages are being uploaded tonight. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333497: CAN-2005-2971: Heap overflow in kword's RTF import
Ah, yes, I forgot to mention this when I mailed the security team earlier. Note that according to the Ubuntu advisory, this bug might also be present in the koffice-libs package. The issue for debian lies specifically within the kword binary package. Unless I'm mistaken, debian's koffice-libs is not affected. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#287164: Bug#317208: Intention to NMU
Hi, Attached the patch for the version I intend to upload. Regarding koffice: I'd be happy if you could give me another 48 hours or so to finish the koffice 1.4.2 packaging (which I agree has been terribly delayed thus far). If you don't see anything uploaded by then however, please do go ahead with the NMU. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330934: Intention to NMU
Hi, Attached the patch for the version I intend to upload. Please respond if you don't want this NMU to happen, if you are working yourself on a patch or if you think that the attached patch won't work. Looks fine to me, please do go ahead with the NMU. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329160: doxygen-doc: Comment blocks broken in examples
Package: doxygen-doc Version: 1.4.4-1 Severity: normal Hi, Something seems to be wrong with the doxygen documentation. Take a look at /usr/share/doc/doxygen/html/docblocks.html for example -- both examples 1 and 2 at the beginning of the page are broken. In each case, the leading /* seems to have been dropped (and presumably the closing */ also, if there is meant to be one). This is not restricted to docblocks.html -- it seems to be happening throughout the doxygen docs. Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) doxygen-doc depends on no packages. Versions of packages doxygen-doc recommends: ii doxygen 1.4.4-1Documentation system for C, C++ an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327332: several kde-i18n packages share files with old kturtle
Package: kde-i18n Severity: serious Hi, Several kde-i18n packages contain files that used to be shipped with the old kturtle ( 4:3.4.2). There is no versioned replaces however, which means the upgrade can break (as happened with me today). The old kturtle package provided the following files, which moved to kde-i18n with KDE 3.4: /usr/share/apps/kturtle/data/logokeywords.nl.xml /usr/share/apps/kturtle/data/logokeywords.fr_FR.xml /usr/share/apps/kturtle/data/logokeywords.de_DE.xml /usr/share/apps/kturtle/data/logokeywords.sv.xml /usr/share/apps/kturtle/data/logokeywords.sr.xml Please add versioned replaces on kturtle ( 4:3.4.2) for each of the corresponding kde-i18n-* packages. Thanks, Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327334: libqscintilla6: should conflict with libqscintilla5
Package: libqscintilla6 Version: 1.6-1 Severity: serious Hi, Both libqscintilla5 and libqscintilla6 ship the file: /usr/lib/qt3/plugins/designer/libqscintillaplugin.so However, libqscintilla6 contains no conflict with libqscintilla5. As a result, the system will happily try to install them together until the files clash (at which point the installation breaks with an error). Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libqscintilla6 depends on: ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libgcc1 1:4.0.1-6 GCC support library ii libqt3-mt 3:3.3.4-7 Qt GUI Library (Threaded runtime v ii libstdc++64.0.1-6The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-6 X Window System protocol client li ii libxext6 6.8.2.dfsg.1-6 X Window System miscellaneous exte ii xlibs 6.8.2.dfsg.1-6 X Window System client libraries m libqscintilla6 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326610: kde-i18n-de: kde-i18n / khangman problem affect several languages
Package: kde-i18n-de Version: 4:3.4.2-3 Followup-For: Bug #326610 Hi, Bug #326610 was filed because kde-i18n-de needs to replace khangman ( 4:3.4.2). In fact this affects several languages, not just kde-i18n-de. The old khangman provided all of the following files: /usr/share/apps/khangman/ca.txt /usr/share/apps/khangman/cs.txt /usr/share/apps/khangman/da.txt /usr/share/apps/khangman/de.txt /usr/share/apps/khangman/es.txt /usr/share/apps/khangman/fi.txt /usr/share/apps/khangman/fr.txt /usr/share/apps/khangman/hu.txt /usr/share/apps/khangman/nb.txt /usr/share/apps/khangman/pt.txt /usr/share/apps/khangman/sl.txt /usr/share/apps/khangman/[EMAIL PROTECTED] /usr/share/apps/khangman/sv.txt /usr/share/apps/khangman/tg.txt These are now provided by kde-i18n, and so all of the corresponding kde-i18n-* packages will need the versioned replaces. Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kde-i18n-de depends on: ii kdelibs4c24:3.4.2-3 core libraries for all KDE applica kde-i18n-de recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327396: koffice: FTBFS: ISO C++ forbids declaration of 'QComboBox' with no type
Hi, There's in fact a major new upstream release (1.4.1) which I hope to have out this weekend. I plan on doing some non-trivial things (like rearranging the library packages), so it will be useful if this and the C++ ABI transition happen together. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325996: ftp.debian.org: please remove konq-speaker from testing/unstable
Package: ftp.debian.org Severity: normal Hi, The konq-speaker package has outlived its usefulness. There has been no upstream action on konq-speaker for several years, and the official KDE text-to-speech system shipped with kdeaccessibility is now sophisticated enough that I think konq-speaker will not be missed. Please remove konq-speaker from unstable (and from testing when appropriate). Note that I was the maintainer of konq-speaker from its initial upload until just last week, when I orphaned it (#325996). Since taking a closer look at KDE 3.4, I have decided that it's better removed instead. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327167: libboost-dev: please prevent very long compiler warning
Package: libboost-dev Version: 1.33.0-1 Severity: minor Tags: upstream patch Hi, I'm using boost.python, and for every one of my source files I get a compiler warning from /usr/include/boost/tuple/detail/tuple_basic.hpp. Unfortunately this compiler warning is about 100 lines long, and so it's really quite hard to find warnings in my own code amongst all the noise. It should be a trivial fix. The warning is: /usr/include/boost/tuple/detail/tuple_basic.hpp:366: warning: unused parameter 't1' It should just be a matter of removing the unused variable name. The (one-line) patch is included below: --- /usr/include/boost/tuple/detail/tuple_basic.hpp 2004-10-18 16:03:18.0 +1000 +++ tuple_basic.hpp 2005-09-08 14:20:51.0 +1000 @@ -362,7 +362,7 @@ template class T2, class T3, class T4, class T5, class T6, class T7, class T8, class T9, class T10 - cons( const null_type t1, T2 t2, T3 t3, T4 t4, T5 t5, + cons( const null_type, T2 t2, T3 t3, T4 t4, T5 t5, T6 t6, T7 t7, T8 t8, T9 t9, T10 t10 ) : head (), tail (t2, t3, t4, t5, t6, t7, t8, t9, t10, detail::cnull()) Thanks - Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-1-686-smp Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Versions of packages libboost-dev depends on: ii libstdc++5-3.3-dev [libstdc++ 1:3.3.6-9 The GNU Standard C++ Library v3 (d ii libstdc++6-4.0-dev [libstdc++ 4.0.1-6The GNU Standard C++ Library v3 (d ii libstdc++6-dev [libstdc++-dev 3.4.4-8The GNU Standard C++ Library v3 (d libboost-dev recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326547: kbabel installation would remove k*-dev packages
Hi, I would be very grateful if you could take a second look on this issue. I uploaded a new package about 10-11 hours ago that was rebuilt with libfam-dev instead of libgamin-dev (in fact, you should have receieved a message around that time closing this bug). So wait for kbabel 4:3.4.2-2 to hit your mirror, then it should all be good. Note that part of the problem is also because kdelibs had some dependencies that were unnecessarily strict. I'd suggest you also upgrade your kdelibs4 to the latest in sid (it seems you're still using 3.4.1). Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325406: poxml: split2po failed
Hi, I've taken a look at this. The problem is that split2po expects each XML file to contain just one top-level element (e.g., book, article, whatever). Your files begin with a sect2.../sect2, followed by another sect2.../sect2. It's therefore ignoring the second sect2 completely. My understanding is that XML only allows a single top-level element (though please do correct me if I'm wrong). In this case, the files 1.xml and 2.xml are technically incorrect -- what split2po should do in this situation is output a meaningful error message. My guess is that split2po is not even looking for more text after the top-level element is closed (and so doesn't even realise that something's wrong). But I have yet to dig through the source to see for certain. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326619: kdeedu: FTBFS on GNU/kFreeBSD
Hi, kdeedu currently fails to build on GNU/kFreeBSD, due to outdated libtool and due to a couple of missing #ifdef. Please find attached a patch to fix that. Could you please add it in the next upload? In your patch you included a completely new file debian/kstars.install.kfreebsd-i386. AFAICT this is identical to debian/kstars.install except that you have removed the v4l drivers (which are excluded in the Makefile.am under an if LINUX). Was this deliberate? i.e., should the kfreebsd-specific files be included in the main debian sources? Or was this an accident (you forgot to strip it from your patch before mailing it), and the kfreebsd files are handled by the bsd people separately? (I'm not exactly sure of how the kfreebsd port fits into the larger debian structure.) b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326458: kbear: Broken dependency with KDE 3.4
Hi, KBear is in the process of being adopted by someone else, but I haven't yet heard if they plan on taking it through the g++-4 transition. If I don't hear back in the next day or so, I'll transition it myeslf (at which point it will become installable again). b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317201: Status update
Hi, Just a note: Although most of kdeaddons' build-deps are ready now, we're still waiting on libdb4.2++ to be transitioned. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326535: kdeaddons wants to remove lot of KDE -dev packages
Hi, atlantik-dev fam kdebase-dev kdelibs4-dev kdemultimedia-dev kdepim-dev kolf-dev kspy libfam-dev libfam0 libkcal2-dev libkdeedu-dev libkdegames-dev libkdepim1-dev libkgantt0-dev libkiten-dev libkleopatra0-dev libkonq4-dev libkpimexchange1-dev libksieve0-dev libktnef1-dev libmimelib1-dev What versions of these packages do you have installed? Hmm, it might be a pain to check them all out. At least, what versions of kdelibs4-dev, libfam-dev, atlantik-dev and libkiten-dev do you have installed? Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326535: kdeaddons wants to remove lot of KDE -dev packages
Hi, Further to my last mail: This may be related to a problem in kdelibs 4:3.4.2-1 where the libfam0-dev dependency was too tight. This was fixed in kdelibs4-dev 4:3.4.2-2. Please try upgrading your kdelibs4-dev, let me know if this fixes things. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326547: 3.4.2 package depend on libgamin0 instead of libfam0
Hi, I have kbabel 4:3.4.2-1 and kdelibs4c2 4:3.4.2-3 installed together quite happily. libgamin0 conflicts libfam0, and here you have the problem. But libgamin0 also provides libfam0, which means the kdelibs4c2 dependency is satisfied. Please try upgrading your kdelibs4 and see if that fixes things. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326535: kdeaddons wants to remove lot of KDE -dev packages
Rightio: If you change your libfam-dev to a libgamin-dev, you can install everything in the short term. Otherwise, I'll be rebuilding those three modules (kdesdk, kdeaddons, kdeedu) against libfam-dev shortly. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326159: Please provide python-pgsql packages that work with python2.4
Hi, Please provide python-pgsql packages that work with python 2.4 I've looked into this -- the problem is that python-pgsql fails some regression tests under 2.4, which is why I haven't uploaded it to date. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326159: Please provide python-pgsql packages that work with python2.4
Do you have details on these regression tests so I can see if this is going to be a show stopper for me too? I remember at least one issue involving comparisons with floats, but beyond that my memory fails me (it's been a while since I looked into it). Though you can find more information in the BTS at http://www.sf.net/projects/pypgsql , where others have reported similar problems. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325996: O: text-to-speech plugins for Konqueror and Kate -- extra
Package: wnpp Severity: normal I'm hereby orphaning konq-speaker. This package contains text-to-speech plugins for Konqueror (the KDE file manager and web browser) and Kate (a KDE text editor). Text-to-speech is provided by the festival speech system. These plugins can be accessed through Konqueror's Tools menu and the plugin manager in Kate settings. The package is not complicated to maintain. Upstream has not worked on it for many years, but it still works fine and is interesting from an accessibility point of view. Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325995: O: XMMS playlist manager with search support -- optional
Package: wnpp Severity: normal Hi. I'm hereby orphaning qbble: Qbble is a playlist manager based on Qt. It will connect to a running XMMS session and display the current playlist in a more manageable format. It also functions as an XMMS general plugin. The key feature is the ability to type a string into the 'search' box at the top of the dialog, and have the playlist reduced to items containing your search text as a substring. It's quite simple to maintain, but there has been no activity from upstream for many years now. Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315340: Your plans for kbear
Hi, I accidentally put the bug # in the subject field for my previous mail.. so if you're ignoring it as BTS junk, please take another look. The summary is that one of us needs to do a kbear upload for the g++-4 transition, so if you could let me know what your plans are for kbear that would be great (so I can take it through the transition if necessary). Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315336: Plans for kdbg
Hi, May I ask when you're looking at uploading kdbg? One of us will need to take it through the g++-4 transition, which is nearing an end. Anyway, let me know if you're not uploading soon and I'll put it through the transition this weekend. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315336: Plans for kdbg
Okay; I'll leave it to you to do the g++-4 transition then. :) b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325992: ftp.debian.org: please remove kcd from testing/unstable
Package: ftp.debian.org Severity: normal Hi, The kcd package is buggy and dead upstream. When KDE 3.4 arrives in sid it will have a multimedia applet that handles CD players, so kcd will become well and truly redundant. Please remove this package from unstable (and testing when appropriate). Thanks - Ben. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325079: quanta: New upstream version
It seems that there is a new upstream version of Quanta (3.4.2) and that the package as it stands depends on libraries that no longer exist in unstable (kdelibs4, libqt3c102-mt). Any chance of an updated package soon? We're currently in the middle of the kde 3.4 / g++-4 transition, and quanta (along with the rest of kdewebdev) will have to wait its turn. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315340: ITA: kbear -- graphical ftp client for KDE
Hi, i'm interested in adopting this package. if there's no problem, i'll apply the patch available [1], and repackage a new revision. Thanks for taking care of this. Note that you should also submit patch [1] to upstream via the sourceforge.net bug tracker, so that if they ever make a new release then this patch may be included in it. I don't know if you are available for sponsoring this package. I'm afraid not -- not so much time available these days. :/ Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322163: kword: please recompile to depends on libwv2-1c2
Hi, libwv2-1 disappear from unstable, please recompile it with newest libwv2-dev to depends on libwv2-1c2. This will have to wait until KDE goes through the g++-4 transition, I'm afraid -- I can't do any KDE uploads until then. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322200: noatun-plugins: depends on package slang1, but package is not available
Hi, The package depends on slang1 which is not available in unstable. This renders the package unusable/uninstallable in unstable. Can't do anything about this until the KDE/gcc4 transition goes through, I'm afraid. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322012: koffice-i18n: Dummy packages (2) built from these sources still needed?
severity 322012 wishlist thanks mate This source package includes koffice-i18n-zhcngb2312 and koffice-i18n-zhtwbig5. These otwo packages are dummy packages that were present in sarge, etch and sid but were not present in woody. Why is this RC? Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322012: koffice-i18n: Dummy packages (2) built from these sources still needed?
Why is this RC? Because these packages are unsuitable for release. They were upgrade packages from a name change that occurred during the (very long) sarge release cycle. I kept them in sarge because I wanted to support an upgrade from (sarge == testing back then) to (sarge == stable). Sure they can go now, but I don't see an (old sarge to new sarge) dummy package as any more RC than a (woody to sarge) dummy package. Anyway, I have better things to do with my morning than argue over this RC bug. Do what you want with the severity, I'll get to it when I get to it. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320879: reminder: aalib transition
Just a reminder that it's been a week since I filed bugs about the aalib transition and these bugs are not yet fixed. This one's gotta wait for the KDE transition I'm afraid, but it will be fixed then. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321322: marked as done (cervisia: refuses to execute any cvs command with any repository)
Honest, all I did was view the rc file for cervisia in vi and loaded cervisia with a directory location on the command line that it had previously failed to accept in the GUI - suddenly it's all working. I don't understand but the bug needs to be closed anyway. Hmm, curious. Ah well, all's well that ends well. b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320879: aalib transition
Thanks. Will do this when kdeaddons gets its turn for the C++ transition (which will probably be a while, since kdeaddons depends on many other parts of KDE). b. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320532: KHangMan will not start, seems to be missig a file
Hi, What version of debian are you using (sid? stable? testing?) What version of the kdelibs4 package do you have? Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320275: debian-science list proposal
Hi, A debian-science list sounds useful to me -- adding my AOL to this request. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319993: regina-normal: FTBFS with gcc-3.4/gcc-4.0: various
tags 319993 + pending severity 319993 serious thanks mate Hi, Thanks for the report. There is in fact a new upstream release waiting (which fixes gcc4 compatibility and some other things), which currently has to wait until the KDE transition has sorted itself out. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319553: g++-4.0: HUGE_VAL causes error with -pedantic
Package: g++-4.0
Version: 4.0.1-2
Severity: normal
Hi,
I've run into a build failure whilst transitioning one of my packages to
g++-4.0. The error occurs when HUGE_VAL is used with -pedantic in C++ code,
as in the following program:
#include math.h
int main() {
double d = 1.0;
if (d == HUGE_VAL)
return 1;
return 0;
}
When compiled with g++-3.3, it prints a warning (use of C99 hexadecimal
floating constant, as described elsewhere in #231748) but compiles fine.
example:~ g++-3.3 -pedantic huge_val.cc
huge_val.cc:6:14: warning: use of C99 hexadecimal floating constant
example:~
However, when compiled with g++-4.0 it prints the same warning and then
gives an error (floating constant exceeds range of 'double').
example:~ g++-4.0 -pedantic huge_val.cc
huge_val.cc:6:14: warning: use of C99 hexadecimal floating constant
huge_val.cc:6: error: floating constant exceeds range of 'double'
example:~
If you remove the -pedantic, it compiles fine. If you compile it with
gcc-4.0 as a C program, it also compiles fine (just the warning, no error).
example:~ g++-4.0 huge_val.cc
example:~ gcc-4.0 -pedantic huge_val.c
huge_val.c:6:14: warning: use of C99 hexadecimal floating constant
example:~
I'm filing this as a separate bug from #231748, since it occurs in
different contexts (v4.0 only, C++ only), the error is different and
the result is more severe (build failure, not just warning).
Ben.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.10-1-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages g++-4.0 depends on:
ii gcc-4.0 4.0.1-2 The GNU C compiler
ii gcc-4.0-base4.0.1-2 The GNU Compiler Collection (base·
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libstdc++6-4.0-dev 4.0.1-2 The GNU Standard C++ Library v3 (d
g++-4.0 recommends no packages.
-- no debconf information
Bug#319154: kile: ftbfs [sparc] error: ISO C++ forbids declaration of 'KXMLGUIClient' with no type
reassign 319154 kdelibs4-dev thanks mate (Reassigning to kdelibs which provides the offending headers.) Hi Blars, Things will almost certainly be broken at the moment for KDE packages while the gcc4 transition is taking place. All gcc4-related errors will be dealt with by the maintainers during that transition, so I'd suggest that you wait until the transition is complete before you file more FTBFS bugs on KDE packages. Ben. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
