Bug#909107: emacsen-common is trying to force me to upgrade from emacs23 to emacs25
Package: emacsen-common Version: 2.0.8 Severity: important Dear Maintainer, I noticed mails from apt saying I had some updates to do, so fired up aptitude and got a conflict. I suspect that it has long been the case that * emacs23 depends on emacs23-bin-common * emacs23-bin-common depends on emacs23-common * emacs23-common depends on emacsen-common It appears that now * emacsen-common conflicts with emacs23-common Thus the recent update to emacsen-common's dependencies forces uninstallation of emacs23, or never update anything again - aptitude has a conflict to resolve, that it can't resolve without removing the last usable version of my editor. -- System Information: Debian Release: buster/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#905276: Suggestion: amend Suggests: to distcc | icecc
Package: ccache Version: 3.4.2-1 Severity: wishlist Dear Maintainer, At present, ccache suggests distcc as a complementary package. An alternative distributed compilation helper is icecc. Either one of them will, presumably, do just as well. So suggesting distcc | icecc seems like a minor improvement. Eddy. -- System Information: Debian Release: buster/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ccache depends on: ii libc6 2.27-5 ii zlib1g 1:1.2.11.dfsg-1 ccache recommends no packages. Versions of packages ccache suggests: pn distcc -- no debconf information
Bug#846575: Acknowledgement (libssl-dev:amd64: struct dh_st is declared and used but nowhere defined)
Debian Bug Tracking System >> If you wish to submit further information on this problem, please >> send it to 846...@bugs.debian.org. Richard Moore: > Openssl 1.1 is not supported. (... by the Qt version in question) Of course not - how silly of me - I forgot that. Then this debian issue can be closed - my bad :-) Eddy.
Bug#846575: libssl-dev:amd64: struct dh_st is declared and used but nowhere defined
Package: libssl-dev
Version: 1.1.0c-2
Severity: important
Dear Maintainer,
I'm building Qt from source and it has some code that accesses a
member of struct dh_st (accessed via its typedef name, DH); my
build failed (for the first time, just after upgrading libssl-dev)
because
error: invalid use of incomplete type ‘DH {aka struct dh_st}’
I find:
$ find /usr/include/openssl /usr/include/x86_64-linux-gnu/openssl \
-type f -print0 | "xargs" -0 -e grep -wnH -e dh_st
/usr/include/openssl/ossl_typ.h:104:typedef struct dh_st DH;
/usr/include/openssl/dh.h:61:/* typedef struct dh_st DH; */
/usr/include/openssl/evp.h:920:struct dh_st;
/usr/include/openssl/evp.h:921:int EVP_PKEY_set1_DH(EVP_PKEY *pkey, struct
dh_st *key);
/usr/include/openssl/evp.h:922:struct dh_st *EVP_PKEY_get0_DH(EVP_PKEY *pkey);
/usr/include/openssl/evp.h:923:struct dh_st *EVP_PKEY_get1_DH(EVP_PKEY *pkey);
Note the declarations and uses; but no definition of the type.
It's possible this struct's internals are meant to be private and
1.1.0c-2 has finally enforced that - in which case Qt is at fault (and
I'll file a bug against Qt). The offending code in Qt is in its
qtbase/src/network/ssl/qssldiffiehellmanparameters_openssl.cpp
There are similar errors for
* EVP_PKEY {aka struct evp_pkey_st}, aggregate ‘EVP_CIPHER_CTX ctx’,
DSA {aka dsa_st} and RSA {aka rsa_st} in
qtbase/src/network/ssl/qsslkey_openssl.cpp
* X509 {aka struct x509_st} and EVP_PKEY {aka struct evp_pkey_st} in
qtbase/src/network/ssl/qsslcertificate_openssl.cpp
Again, find | xargs grep reveals only declarations, no definitions.
-- System Information:
Debian Release: stretch/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.7.0-1-amd64 (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
Init: systemd (via /run/systemd/system)
Versions of packages libssl-dev:amd64 depends on:
ii libssl1.1 1.1.0c-2
Versions of packages libssl-dev:amd64 recommends:
ii libssl-doc 1.1.0c-2
libssl-dev:amd64 suggests no packages.
-- no debconf information
Bug#761980: program not importing ‘platform’ from standard library
> If you do find that âplatformâ was imported from the > wrong place, that indicates a bug in the âslimitâ > program for not importing from the standard library. ... or a platform.py earlier in my custom PYTHONPATH - which, now that I know what to look for, is exactly the problem. PEBKAC - sorry to waste your time - please close this bug, Eddy.
Bug#745425: aptitude: dependency handling jammed on chromium upgrade
> For example, when you saw chromium 34.0.1847.116-1~deb7u1 and marked > for installation (an upgrade of the version of the browser, but > changing the package to that targetted to the stable distribution), > chromium-inspector should have been marked to change to the same > version targetted for stable, 34.0.1847.116-1~deb7u1 (I believe that > they always require to upgrade in lock-step). Or the same with > 34.0.1847.116-1 (without "~deb7u1"), if it was available in your > mirrors. except that, when I positioned the cursor on the 34.*~deb7u1 version that was listed and typed +, aptitude selected the 33.* version rather than the 34.* version, presumably because it had reasons to prefer a testing version over a stable one. It did not report any other 34.* versions. > As I said above, only the versions of chromium* are not enough, there > are many other things at play behind the scenes. Fair enough. Unfortunately, I now only have the information I reported, having long since updated plenty more things. > I think, as I said above, that in that case telling to aptitude to > keep v 33 of both and everything would have been fine, bugs aside. > (So, same result of what happened, just without reinstall). except that doing this involved putting inspector on hold when it claimed to have a security fix to which it wanted to upgrade. > If you don't know about the feature, you can press 'e' when there are > conflicts, and then '.' and ',' to navigate forward and backward the > solutions offered, and press '!' if one of them satisfies you. I did know. I imagine I looked through the options and found the least bad was to hold inspector at its present version, so settled for that, despite having reason to believe there was a major security issue in it. > You can set priorities to the repositories, see "man apt_preferences", Thanks for the tip ;-) > In general, these things are tricky and testing is not always very > stable ;) ... which is, after all, the point - and why we report bugs when we find them, so that they can be fixed before they reach stable ... It sounds like we don't have enough information to pursue this issue further; and I haven't seen similar symptoms in a while. So there are probably more productive uses for your time than investigating further, Eddy.
Bug#745425: aptitude: dependency handling jammed on chromium upgrade
Hi Manuel, > Sorry that this was not handled earlier, maybe now you don't even > remember the details, but I'll have a shot at it... It has been a while, but let's see ... thankfully the report contains enough to jog at least a little memory. > From what you paste above (I don't know if it's correct), I don't see > any obvious problem. The problem is that aptitude claimed there was a problem ! (It claimed I needed to uninstall a browser I was using in order to let it sort out an upgrade of an add-on I wasn't using. It turned out that uninstalling and reinstalling, which should be a no-op, fixed the alleged problem; expecting the user to believe that is a sound course of action is unsound.) I reported all the symptoms, because the problem made too little sense for me to explain it better. > Probably, you could have upgraded from 33.0.1750.152-1 to > 34.0.1847.116-1 or 34.0.1847.116-2 (the versions in testing on the day > that you submitted the report), you don't mention them. I didn't mention them because aptitude didn't tell me about them. It mentioned the 34.0.1847.116-1~deb7u1 version that was for Jessie - thanks for explaining that bit; now I know why aptitude wasn't willing to use that one - but made no mention of any other 34 versions. Since I didn't know about them, I couldn't do anything with them: in particular I couldn't upgrade to them. > Maybe you don't recall them by now, but do you know why you tried the > version with ~deb7u1 rather than the ones without that? Because that was the version that aptitude actually mentioned to me. > So I am not sure about what went wrong in your case, but what you > described so far doesn't is not enough to try to identify an problem > with aptitude behaviour itself. It's probably hard to construct a test-case to illustrate similar behaviour, which would make it hard to reproduce the bug. I don't pretend to fully understand what went wrong; but aptitude said it had a conflict when it sholdn't have - given that uninstalling the packages involved and reinstalling them left them at the same versions with no alleged conflict. Just to be clear here, everything in this was initiated by aptitude - I was doing a routine "if there's anything you think needs updated, let's get on with that" - run aptitude -u, once ready I would just have typed "g" a few times - but aptitude said it had a conflict (it's just for the sake of things like this that I don't just run apt-get update) and I was left to work out what to do about that. Eddy.
Bug#745425: aptitude: dependency handling jammed on chromium upgrade
> To try to see if we are on the same page, this is what I understood so far:
>
> - That at the time, aptitude was happy to keep v 33 of the browser
> packages, it didn't want to remove it before you gave instructions to
> update other packages (how, btw? Command line "aptitude
> safe-upgrade"? "aptitude full-upgrade"? interactive curses
> interface, marking all upgradable packages to upgrade?).
No, not really. As I said:
>>> I'm on testing. I have chromium installed. I use the browser. I
>>> do not use the inspector. None the less, chromium declares that it
>>> depends on chromium-inspector, which is thus installed. Recently
>>> (around the time of heartbleed) there has come a security upgrade
>>> for chromium-inspector. This upgrade conflicts (in some way, I
>>> couldn't see how) with the existing version of chromium.
A routine "aptitude -u" left me looking at the UI saying I had a
conflict. I was obliged to put on hold an update to a package I don't
want, despite this allegedly implicating a security problem for which I
should upgrade. Which was scary, given that heartbleed had just hit the
news.
So no, aptitude was not happy to keep what it had. I had to uninstall a
needed package and an unwanted package and then reinstall the needed
package (which dragged the unwanted one back in) in order to get to the
happy state that *I* can't distinguish from the original, but aptitude
was indeed happy after that. However, it *wasn't* happy to begin with,
which is exactly why I reported a bug.
> - The problem was caused when you asked to upgrade: at that point, it
> only allowed upgrading by wanting to remove "chromium-browser" (or at
> least, offering that as the first alternative to allow the upgrade).
I ran "aptitude -u", to get my package lists up to date. After that, I
had aptitude reporting a conflict. It wanted to upgrade
chromium-inspector (which I don't use) and the upgrade required that I
uninstall chromium-browser (which I do use). I had every reason to
suppose that I would be unable to reinstall it - since it was dragging
in an unwanted package that conflicted with it. I put the upgrade on
hold - hoping it was just some package metadata goof-up that would be
fixed soon enough - and came back to it a few days later. As it wasn't
fixed, I set about documenting prior state and aptitude's behaviour as I
tried the only thing I could think of that might get me out of the
problem.
> Then I assume when you reinstalled ("Eventually, I uninstalled both
> packages, then installed chromium afresh"), only 'chromium' and
> 'chromium-inspector' were involved, or did it also remove / install /
> upgrade other packages?
No, it put back the inspector automagically - as I said in the report:
>>>Eventually, I uninstalled both packages, then installed chromium afresh.
>>>The above dpkg command now reports
>>>
>>>Desired=Unknown/Install/Remove/Purge/Hold
>>>|
>>>Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>>>|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>>>||/ Name Version Architecture Description
>>>+++--=-=-=
>>>ii chromium 33.0.1750.152-1 amd64 Chromium
>>>web browser
>>>un chromium-codecs-ffmpeg (no
>>>description available)
>>>un chromium-codecs-ffmpeg-e (no
>>>description available)
>>>ii chromium-inspector 33.0.1750.152-1 all page
>>>inspector for the Chromium browser
I uninstalled both, then told aptitude to install the one I wanted. It
duly reinstalled the one I didn't want, too. Which is why my report
began with a grumble about the misguided package dependencies. I get
that that's the chromium maintainer's bug, not yours, of course.
> (If it pulled in new library dependencies or upgraded others, that could
> have been what solved the previous conflicts).
... except that the prior conflict made no mention of any other such
dependencies; and the uninstall-and-reinstall left me with *exactly the
same* versions of all chromium packages that I'd had before. See the
dpkg output sections of the original report.
> What I do not understand is what was improved after you reinstalled:
>
> - After you reinstalled, you could upgrade the browser to v 34 without
> aptitude wanting to remove 'chromium'?
>
> - After you reinstalled, you could upgrade *other parts* of the distro
> (not the browser), without aptitude wanting to remove the browser?
After the uninstall-and-reinstall, aptitude no longer reported a
conflict for chromium, which was still on version 33. I don't
understand why it reported a conflict before; I don't understand why it
was happy after; and it hadn't actually changed the version of the
software it had previously grumbled about.
> That was in the curses
Bug#725017: Fixed in 0.9.0+dfsg2-1
Haven't tried freemind in a while, but just did again today - and it's listening to the keyboard as I expect once more. Hurrah ! Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762914: abinit-data is not a documentation package, but shows up in that category
Source: abinit-data Version: Data package is classified as a documentation package Severity: minor Dear Maintainer, I see the new abinit-data package in the Documentation category, where it surely does not belong. Did someone just copy the control file from abinit-doc when creating the new one, and forget to edit that line ? *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761980: python-pkg-resources: pkg_resources.py wrongly expects packages module to export python_version()
Package: python-pkg-resources
Version: 5.5.1-1
Severity: normal
Dear Maintainer,
I installed the slimit package and, lacking a man page, ran
slimit --help
Instead of help I got
quote
Traceback (most recent call last):
File /usr/bin/slimit, line 5, in module
from pkg_resources import load_entry_point
File /usr/lib/python2.7/dist-packages/pkg_resources.py, line 1189, in
module
class MarkerEvaluation(object):
File /usr/lib/python2.7/dist-packages/pkg_resources.py, line 1193, in
MarkerEvaluation
'python_full_version': platform.python_version,
AttributeError: 'module' object has no attribute 'python_version'
/quote
which wasn't much use. The problem is that last stack frame, in
pkg_resources.py, where
quote
import platform
...
class MarkerEvaluation(object):
values = {
'os_name': lambda: os.name,
'sys_platform': lambda: sys.platform,
'python_full_version': platform.python_version,
'python_version': lambda: platform.python_version()[:3],
...
/quote
presumes that the module platform has python_version as an attribute
(that is, no less, callable returning a sequence). A quick python
session:
quote
Python 2.7.8 (default, Sep 9 2014, 23:55:56)
[GCC 4.9.1] on linux2
Type help, copyright, credits or license for more information.
import platform
platform.python_version
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'module' object has no attribute 'python_version'
platform.version
function version at 0xb72aa56c
platform.version()
'#1 SMP Debian 3.14.15-2 (2014-08-09)'
import sys
sys.version
'2.7.8 (default, Sep 9 2014, 23:55:56) \n[GCC 4.9.1]'
/quote
reveals that this is an unrealistic expectation.
Continuing,
quote
import pkg_resources
Traceback (most recent call last):
File stdin, line 1, in module
File pkg_resources.py, line 1189, in module
class MarkerEvaluation(object):
File pkg_resources.py, line 1193, in MarkerEvaluation
'python_full_version': platform.python_version,
AttributeError: 'module' object has no attribute 'python_version'
/quote
I verify that the problem resides entirely within pkg_resources; it
has nothing to do with how slimit is using it.
Commenting out the python_full_version and python_version entries in
values (quoted above), I discover python_implementation is also a
mythical attribute of platform. Commenting *that* out, I find I am
finally able to import pkg_resources; and slimit --help actually runs,
albeit producing only minimal help. I don't know what else may be
broken by it, but here's the patch I'm left using:
patch
diff -bu /usr/lib/python2.7/dist-packages/pkg_resources.py.orig
/usr/lib/python2.7/dist-packages/pkg_resources.py
--- /usr/lib/python2.7/dist-packages/pkg_resources.py.orig 2014-08-10
19:36:30.0 +0200
+++ /usr/lib/python2.7/dist-packages/pkg_resources.py 2014-09-17
15:00:55.183904273 +0200
@@ -1190,11 +1190,11 @@
values = {
'os_name': lambda: os.name,
'sys_platform': lambda: sys.platform,
-'python_full_version': platform.python_version,
-'python_version': lambda: platform.python_version()[:3],
+#'python_full_version': platform.python_version,
+#'python_version': lambda: platform.python_version()[:3],
'platform_version': platform.version,
'platform_machine': platform.machine,
-'python_implementation': platform.python_implementation,
+#'python_implementation': platform.python_implementation,
}
@classmethod
Diff finished. Wed Sep 17 15:07:54 2014
/patch
This makes pkg_resources.py unusable (can't import it) and makes at
least one other package unusable (slimit, because it expects to be
able to import pkg_resources).
-- System Information:
Debian Release: jessie/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 3.14-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 python-pkg-resources depends on:
pn python:any none
python-pkg-resources recommends no packages.
Versions of packages python-pkg-resources suggests:
pn python-distribute none
pn python-distribute-doc none
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750934: emacs24 failed to uninstall because emacsen-common went first
Package: emacs24 Version: 24.3+1-4 Severity: normal Dear Maintainer, I had some problems with assorted packages not properly installed so resorted to purging them (so as to be able to reinstall afresh); one of these was emacsen-common, so I was forced to also purge emacs23 and emacs24. During the uninstall, emacs23 and emacs24 failed to uninstall for reasons lost in the long pile of output from dpkg; when I told aptitude to try again, they failed due to their prerm scripts invoking /usr/lib/emacsen-common/emacs-remove from emacsen-common, which had already been uninstalled. It would seem emacs2[34] need to, in some way, record the dependency on emacsen-common at uninstall-time, so that emacsen-common doesn't get uninstalled until packages whose prerm scripts depend on it have gone first ! I don't know package-management well enough to even be sure apt/dpkg supports this, so this may need to spawn a feature request there ... Reinstalling emacsen-common so as to be able to uninstall emacs23 and emacs24 was counter-intuitive, but did at least work ! (The subsequent reinstall of everything and its dog also went smoothly, to my great relief.) Eddy. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages emacs24 depends on: ii emacs24-bin-common 24.3+1-4 ii gconf-service3.2.6-2 ii libasound2 1.0.27.2-4 ii libatk1.0-0 2.12.0-1 ii libc62.18-7 ii libcairo-gobject21.12.16-2 ii libcairo21.12.16-2 ii libdbus-1-3 1.8.2-1 ii libfontconfig1 2.11.0-5 ii libfreetype6 2.5.2-1 ii libgconf-2-4 3.2.6-2 ii libgdk-pixbuf2.0-0 2.30.7-1 ii libgif4 4.1.6-11 ii libglib2.0-0 2.40.0-3 ii libgnutls28 3.2.15-1 ii libgomp1 4.9.0-5 ii libgpm2 1.20.4-6.1 ii libgtk-3-0 3.12.2-1 ii libice6 2:1.0.8-2 ii libjpeg8 8d-2 ii libm17n-01.6.4-2 ii libmagickcore5 8:6.7.7.10+dfsg-3 ii libmagickwand5 8:6.7.7.10+dfsg-3 ii libotf0 0.9.13-1 ii libpango-1.0-0 1.36.3-1 ii libpangocairo-1.0-0 1.36.3-1 ii libpng12-0 1.2.50-1 ii librsvg2-2 2.40.2-1 ii libselinux1 2.3-1 ii libsm6 2:1.2.1-2 ii libtiff5 4.0.3-8 ii libtinfo55.9+20140118-1 ii libx11-6 2:1.6.2-2 ii libxft2 2.3.1-2 ii libxml2 2.9.1+dfsg1-3 ii libxpm4 1:3.5.10-1 ii libxrender1 1:0.9.8-1 ii zlib1g 1:1.2.8.dfsg-1 emacs24 recommends no packages. Versions of packages emacs24 suggests: ii emacs24-common-non-dfsg 24.3+1-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658367: mtp-tools: Results of using -h
Package: mtp-tools Version: 1.1.6-51-g1a2669c~ds0-1 Followup-For: Bug #658367 Dear Maintainer, Here's what -h actually does: quote eddy:1:vortex mtp-detect -h mtp-detect: invalid option -- 'h' Unable to open ~/.mtpz-data for reading, MTPZ disabled.libmtp version: 1.1.6 Listing raw device(s) Device 0 (VID=04e8 and PID=6860) is a Samsung Galaxy models (MTP). Found 1 device(s): Samsung: Galaxy models (MTP) (04e8:6860) @ bus 4, dev 6 Attempting to connect device(s) PTP_ERROR_IO: failed to open session, trying again after resetting USB interface LIBMTP libusb: Attempt to reset device LIBMTP PANIC: failed to open session on second attempt Unable to open raw device 0 OK. /quote This takes several minutes. Given that it is doing freaky things to my phone - reset ? what ? eek ! - a reasonable ignorant user may be distinctly nervous both of letting it run and of interrupting it. Not a nice experience; definitely bad news to have the man page mislead one into it. Note that -V, -v and --version also get errors, similar to those above for -h. Running strings /usr/bin/mtp-detect didn't reveal anything useful, either. However, strings does find Usage messages for some (but by no means all) other /usr/bin/mtp-*, albeit the messages omit the mtp- prefix from the command names (e.g. mtp-hotplug has a usage message for hotplug) rather than having a %s to be filled in by basename(argv[0]). The mtpfs man page (separate package, mtpfs) makes the same bogus claim, with similar results when I actually try to use -h or --help. But that package appears to be obsolete now. Eddy. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mtp-tools depends on: ii libc62.18-7 ii libmtp9 1.1.6-51-g1a2669c~ds0-1 mtp-tools recommends no packages. mtp-tools 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#746034: chromium depends on non-existent (in testing) libudev0
Source: chromium Version: 34.0.1847.137-1~deb7u1 Severity: grave Justification: renders package unusable Dear Maintainer, I'm on testing. quote src=cat /etc/apt/sources.list.d/* # Norwegian national repository: deb ftp://ftp.no.debian.org/debian/ testing main non-free contrib deb-src ftp://ftp.no.debian.org/debian/ testing main non-free contrib deb http://security.debian.org/ stable/updates main contrib non-free deb-src http://security.debian.org/ stable/updates main contrib /quote In aptitude, when I select chromium, it's an instant conflict due to its dependency on libudev0 = 146, which is not available. I am consequently unable to install chromium in testing. This is particularly irksome due to the reason I uninstalled it to begin with: I had, some months ago, experienced persistent conflicts between chromium-browser and chromium-inspector; nothing I tried would resolve this, for several weeks; eventually, I'd tried uninstalling both and reinstalling the browser, which worked (and pulled in the inspector, without any apparent problem). I got similar conflicts this morning so did the same, only to find I got this different conflict instead on reinstall. At the time, a version of libudev0 was in fact listed, as deleted but with some config files remaining; it had been deleted when I uninstalled chromium, which was the only package depending on it. Unfortunately, trying to select it for installation was ignored by the aptitude UI. Once I'd purged it (to clear the config files) it was no longer listed; it's apparently not present in testing. So, if I hadn't uninstalled chromium, I'd have had a perfectly good libudev0 lying around that I could have continued using. Unfortunately, chromium's internal conflicts had left me little option but to uninstall it. Fortunately, stable still has a libudev0 with a high enough version, so manually downloading and dpkg -i-ing that works round the problem, enabling me once more to install chromium-browser (and get the whole pile of other chromium stuff I don't want chucked in with it). ... hmm ... and, on doing that, I see apt-listbugs reports exactly this problem, so why didn't reportbug tell me about it ? Possibly something to do with the fact that the package isn't installed ... so I'll post as a follow-up instead of adding another duplicate. Somewhere at the bottom of all of this is a basic error in dependencies among the chromium family of packages: I only actually want the chromium-browser package, but it depends on chromium, which depends on chromium-inspector, which I don't want or need. But for that, I'd not have hit the conflict that forced me to uninstall and left me in a broken state. As long as the chromium package is going to depend on chromium-inspector, i.e. be a top-level package to pull in the whole chromium suite, it should surely also depend on chromium-browser, not the other way around. If there are common packages that the diverse chromium-* programs all depend on, e.g. libudev, then there should be a chromium-common package on which they all depend, with chromium depending on the high-level packages, not depending on the low-level things they need so that chromium-browser has to depend on that in order to get everything and the kitchen sink along with the libraries it needs. I should be able to install the browser without the ancillary tools that aren't actually needed in order to run the browser. Sure, it's good to encourage web designers to actually check what they produce, but that's no reason to burden the browser with an extraneous Depends - it should at most be a Recommends. Until this is fixed (given that there's a FTBFS problem on 32-bit delaying that), how about persuading the libudev maintainers to restore libudev0 in testing ? *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745425: aptitude: dependency handling jammed on chromium upgrade
Package: aptitude Version: 0.6.10-1 Severity: normal Dear Maintainer, I'm on testing. I have chromium installed. I use the browser. I do not use the inspector. None the less, chromium declares that it depends on chromium-inspector, which is thus installed. Recently (around the time of heartbleed) there has come a security upgrade for chromium-inspector. This upgrade conflicts (in some way, I couldn't see how) with the existing version of chromium. Aptitude reported a conflict and offered to resolve it by uninstalling chromium (which I want) or keeping chromium-inspector (which I don't consciously use; and wouldn't have any use for at all without chromium) at its old version (which, apparently, means retaining a known security bug on my system). If chromium actually does use inspector, without my being aware of it, this is a security problem, that I can't fix other than by uninstalling chromium (at which point I may as well uninstall its inspector). [Aside (for the chromium maintainer): I do not think it makes sense for chromium (the browser) to depend on (i.e. force installation of) chromium-inspector if, in fact, it is possible to browse without this tool for web developers. It would make sense for chromium-inspector to depend on chromium, and for chromium to Suggest or Recommend its inspector, but the present Depends seems misguided (regardless of the situation, above, that has brought it to my attention).] dpkg -l 'chromium*' says (once I set COLUMNS to 120 to see full version information): quote Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++--=-=-= ii chromium 33.0.1750.152-1 amd64 Chromium web browser un chromium-codecs-ffmpeg nonenone(no description available) un chromium-codecs-ffmpeg-e nonenone(no description available) ii chromium-inspector 33.0.1750.152-1 all page inspector for the Chromium browser un chromium-l10nnonenone(no description available) un chromium-testsuite nonenone(no description available) /quote In aptitude, I did see a version 34.0.1847.116-1~deb7u1 listed for chromium; but attempting to mark the installed version for deletion and this new version for installation does not work: it merely marks the 33.0... version to be kept installed, with the attendant conflict with its own inspector. I kept inspector at its old version and assumed a compatible version of chromium would show up sooner or later. After about a week, I tried again; nothing had changed. Same conflict, same offered resolutions. Eventually, I uninstalled both packages, then installed chromium afresh. The above dpkg command now reports quote Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++--=-=-= ii chromium 33.0.1750.152-1 amd64 Chromium web browser un chromium-codecs-ffmpeg nonenone(no description available) un chromium-codecs-ffmpeg-e nonenone(no description available) ii chromium-inspector 33.0.1750.152-1 all page inspector for the Chromium browser un chromium-l10nnonenone(no description available) un chromium-testsuite nonenone(no description available) /quote unchanged ! I am unable to make sense of what aptitude was complaining about or why purging and reinstalling has (apparently) fixed the alleged problem. I was wary of uninstall and reinstall, since this would purge the old version of inspector, leaving me without the option of keeping it at its old version; so, if the conflict had still been present, it would have been unresolvable (other than by leaving chromium uninstalled). That this turned out not to be the case is incidental: in order to make the decision to attempt this course of action, I had to accept the possibility that I would be left without chromium. The package manager should not force me into such a choice when there is, in fact, no problem at all ! -- Package-specific info: Terminal: screen.rxvt $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.10 compiled at Feb 20 2014 17:26:22 Compiler: g++ 4.8.2 Compiled against: apt version 4.12.0
Bug#725017: closed by Markus Koschany a...@gambaru.de (Bug#713144: fixed in freemind 0.9.0+dfsg-3)
we often used jedit in the past as a guinea pig that shows if a problem is due to Java and its environment, or to FreeMind/Freeplane. Installed jedit, ran it; it's ignoring keyboard input, too. So sounds like Java's the actual problem. The alternatives system is using java-7-openjdk-amd64. What other does it make sense to try in its place ? Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725017: closed by Markus Koschany a...@gambaru.de (Bug#713144: fixed in freemind 0.9.0+dfsg-3)
If you claim that Freemind was working before, Yes, freemind worked fine some time in spring this year. I forget exactly when. it is more likely that something else changed within your desktop environment. I can't think of a way to work out what. No other application has exhibited any even remotely similar symptoms, aside from freeplane, which appears to just be a variant on freemind. Do you know of other applications that use the same UI toolset, that I could test out to see if they have the same problem ? Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725017: closed by Markus Koschany a...@gambaru.de (Bug#713144: fixed in freemind 0.9.0+dfsg-3)
Thanks for checking up on that. See a couple of comments up from me, where I noted that I've had the same problem in freeplane. Both the freeplane bug you mention and the upstream bug report are worked round by exiting and restarting. This does not work for me: in a cleanly started freemind (or freeplane) session, having just logged in to a fresh X session, the keyboard is simply ignored (except that modifier keys do affect what mouse clicks do). I'll look into this a bit more closely when I'm sober and not about to head out on the town ;- Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725017: closed by Markus Koschany a...@gambaru.de (Bug#713144: fixed in freemind 0.9.0+dfsg-3)
I've just upgraded to freemind 0.9.0+dfsg-3 and tested it out. Sad to say, I see no improvement :-( Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725017: closed by Markus Koschany a...@gambaru.de (Bug#713144: fixed in freemind 0.9.0+dfsg-3)
Curious to know when to expect the mentioned dfsg-3 release to show up, I searched debian.org for freemind and found the thread about adopting it, in which freeplane got mentioned. So I gave that a try, to see if it fares any better: it exhibited exactly the same problem as freemind. Is there a simple way to make sure the freeplane maintainer(s) also get to know about (a) this bug and (b) the changes you believe shall fix it ? Or is the simplest thing for me to just submit an almost-duplicate report against freplane ? Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725017: freemnd: ignores keyboard input
Package: freemind Version: 0.9.0+dfsg-2 Severity: important Dear Maintainer, I opened freemind. It helpfully opened the last .mm I'd been working on (which is about 2.4 MB in size). It was, however, partly off-screen (as it always is; it opens with the top of the window somewhere off the top of the screen). I moved it down to where I could see it all. I clicked in the work area to put focus in the right place and started navigating with the keyboard, as is my wont. Nothing happened; the central node remained selected. I opened other nodes by clicking on them (randomly opening web pages to which some are linked in the process) with the mouse to get to where I wanted to edit the mind-map. I tried keyboard actions at various points, to no avail. I checked the menus to be sure I was typing the right short-cuts. I told it to add a node: but when I typed content for the node, nothing happened. I was, however, able to paste content in from another application. Previously the keyboard worked fine ... I don't know what's changed: the installed version of freemind is the same as in stable, so it's not what changed. Perhaps java ? Hard to tell. I'm using fvwm as my window-manager; other applications get keyboard input just fine. I'm using Debian/testing and typically update each week. It's been several weeks since I last used freemind. Exiting and restarting made no difference. Uninstalling and reinstalling afresh was also no help :-( -- Package-specific info: [debug] /usr/bin/freemind: Found JAVA_HOME = '/usr/lib/jvm/java-7-openjdk-amd64' [debug] /usr/bin/freemind: Found JAVA_CMD = '/usr/lib/jvm/java-7-openjdk-amd64/bin/java' DEBUG: Freemind parameters are ''. DEBUG: Linux vortex 3.10-2-amd64 #1 SMP Debian 3.10.7-1 (2013-08-17) x86_64 GNU/Linux No LSB modules are available. DEBUG: Distributor ID:Debian Description:Debian GNU/Linux testing (jessie) Release:testing Codename: jessie DEBUG: The following DEB packages are installed: ii freemind0.9.0+dfsg-2 allJava Program for creating and viewing Mindmaps ii freemind-doc0.9.0+dfsg-2 all Documentation for FreeMind ii freemind-plugins-svg0.9.0+dfsg-2 allJava Plugin for FreeMind to export Mindmaps to SVG and PDF DEBUG: Link '/usr/bin/freemind' resolved to '/usr/share/freemind/freemind.sh'. DEBUG: Freemind Directory is '/usr/share/freemind'. DEBUG: Calling: '/usr/lib/jvm/java-7-openjdk-amd64/bin/java -Dgnu.java.awt.peer.gtk.Graphics=Graphics2D -Dfreemind.base.dir=/usr/share/freemind -cp ::/usr/share/freemind/lib/freemind.jar:/usr/share/java/SimplyHTML.jar:/usr/share/java/gnu-regexp.jar:/usr/share/java/jibx-run-1.1.6a.jar:/usr/share/java/xpp3.jar:/usr/share/freemind/lib/bindings.jar:/usr/share/java/forms.jar:/usr/share/freemind freemind.main.FreeMindStarter '. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages freemind depends on: ii default-jre 1:1.7-49 ii libjgoodies-forms-java 1.6.0-4 ii libjibx1.1-java 1.1.6a-3 ii simplyhtml 0.16.07-1 Versions of packages freemind recommends: ii freemind-doc 0.9.0+dfsg-2 ii java-wrappers 0.1.27 ii xdg-utils 1.1.0~rc1+git20111210-7 Versions of packages freemind suggests: pn freemind-browser none pn freemind-plugins-helpnone pn freemind-plugins-script none ii freemind-plugins-svg 0.9.0+dfsg-2 -- 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#725017: freemnd: ignores keyboard input
Oddly, I find that freemind *does* know when I'm holding down the shift key: when I select one node, then shift-click to select a second to make a local hyperlink, it works. I'm unable to select the text in a node, e.g. to delete it or over-write it with new text. When I've pasted some text into a new node, there's no way to tell it I've finished, so it doesn't actually save the node until I do something else; creating a new sibling or child node works but I've found various other actions (sorry, didn't note down which) that lead to it still showing the edit box, with my text in it, but saving the node still empty, ignoring the edit it's still displaying. The user experience is full of pain, working without keyboard access ! But I managed (eventually) to make my edits. Something very weird is going wrong here. I can't think of anything else that uses java except web browser applets; I find that the BankID applet (used by Norwegian banks to verify customers) does accept typed input just fine, but I've no idea how the plugin behaviour relates, if at all, to a desktop application's. Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721808: git-cvs: perl warnings from git-cvsserver confuse cvs
Package: git-cvs Version: 1:1.8.4~rc3-1 Severity: minor Dear Maintainer, I'm on testing and yesterday I did an update that took in the new rc of git and all things related. I have a nightly cron job that logs into the host of my public web-site, creates the needed SSL tunnel and has my web-site cvs update itself from the git-cvsserver back home; it's worked fine for ages. (The remote end is somewhat conservatively sysadmined, so hasn't taken in radical new packages like git; it still has the GNU Interactive Tools). The first night after the git upgrade, I got the following mail from cron: quote cvs update: warning: unrecognized response `Use of uninitialized value $wrev in string ne at /usr/bin/git-cvsserver line 1262, STDIN line 1447.' from cvs server cvs update: warning: unrecognized response `Use of uninitialized value $wrev in string ne at /usr/bin/git-cvsserver line 1307, STDIN line 1447.' from cvs server cvs update: `Vault.png' is no longer in the repository /quote which sounds like cvs is getting sent - as part of a protocol in which they have no place - perl's warnings about uninitialised variables. (Oh, and Vault.png is indeed not in the repository, nor has it been for ages, if ever - not sure what that's about.) Are the use strict; and use warnings; lines in git-cvsserver new ? The exact command cron runs is: quote ssh -o 'RemoteForward 2402 localhost:2401' chaos 'cd public_html cvs up' /quote my /etc/services has quote cvspserver 2401/tcp# CVS client/server operations cvspserver 2401/udp /quote and inetd.conf says quote cvspserver stream tcp nowait eddy /usr/bin/git-cvsserver git-cvsserver pserver /home/eddy/.repository/chaos.git /quote The remote end's CVS/Root files say quote :pserver:anonymous@localhost:2402/home/eddy/.repository/chaos.git /quote to match up with all of that. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.10-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages git-cvs depends on: ii cvsps2.1-6 ii git 1:1.8.4~rc3-1 ii libdbd-sqlite3-perl 1.40-1 git-cvs recommends no packages. Versions of packages git-cvs suggests: ii cvs 2:1.12.13+real-11 ii git-doc 1:1.8.4~rc3-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663530: apache2.2-common: ports.conf also specifies NameVirtualHost *:80
That being said please note, that NameVirtualHost itself is deprecated and not used anymore in Apache2 2.4. That's good to hear. Having to hae two things exactly in sync is always a bit weird; might as well eliminate the redundancy instead ! Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663530: apache2.2-common: ports.conf also specifies NameVirtualHost *:80
Package: apache2.2-common Version: 2.2.22-13 Followup-For: Bug #663530 Dear Maintainer, I finally decided to work out why I was getting grumbles from apache about a NameVirtualHost *:80 directive. The only configuration I've actually got enabled (i.e. symlinked from sites-enabled/ to sites-available/) has an explicit IP address rather than a wildcard, so I was initially at a loss. It's based on an old default config, in which the NameVirtualHost line appeared immediately before the VirtualHost directive; and I'd ensured that the two gave the same host:port details, not the default's *:80 but 127.0.0.1:80 in both places. However, closer investigation revealed that /etc/apache2/ports.conf *also* contains a NameVirtualHost *:80 line, which is what the complaints relate to. Commenting it out fixed the warnings about this directive - and fixed several other things that had mysteriously broken some months ago. My configuration's ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ and Alias /doc/ /usr/share/doc/ directives weren't being honoured; I got 404 errors when accessing URLs that should have been resolved by these. These things are all now back to working normally - yay ! The problem is that the NameVirtualHost directive *must* exactly match the VirtualHost directive's parameter. Putting the two in separate files just ensures that the person configuring the server can't actually see that there's a second place that the address:port has to appear, identically, so won't naturally keep the two in sync. Even though I actually have a NameVirtualHost in my enabled sites-available file, matching exactly the same file's VirtualHost parameter, my configuration was broken by a NameVirtualHost *:80 elsewhere, that I knew nothing about. Given that the VirtualHost directive lives in a user-configurable file and *must* exactly match the NameVirtualHost directive, it strikes me that the old way, having the later also in the user-configurable file, was a better approach than the present, where the user must - in fact - edit a file that's not in sub-directory in which user-configuration normally takes place. If there's genuinely a compelling reason to put the NameVirtualHost somewhere other than *right next to* the VirtualHost directive (as I'm fairly sure it used to be), where it'll be obvious that they need to stay in sync, please add a comment to default, immediately before the VirtualHost directive, saying be sure to keep ports.conf's NameVirtualHost in sync; the host:port must match exactly. *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines *** -- Package-specific info: List of enabled modules from 'apache2 -M': actions alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user autoindex cgi deflate dir env include mime negotiation python reqtimeout rewrite setenvif status userdir -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apache2.2-common depends on: ii apache2-utils 2.2.22-13 ii apache2.2-bin 2.2.22-13 ii lsb-base 4.1+Debian12 ii mime-support 3.54 ii perl 5.14.2-21 ii procps 1:3.3.4-2 Versions of packages apache2.2-common recommends: ii ssl-cert 1.0.32 Versions of packages apache2.2-common suggests: ii apache2-doc 2.2.22-13 pn apache2-suexec | apache2-suexec-custom none ii chromium [www-browser] 28.0.1500.71-2 ii opera [www-browser] 12.16.1860 ii opera-next [www-browser]12.16.1860 ii w3m [www-browser] 0.5.3-8 Versions of packages apache2.2-common is related to: pn apache2-mpm-eventnone pn apache2-mpm-itk none ii apache2-mpm-prefork 2.2.22-13 pn apache2-mpm-worker none -- Configuration Files: /etc/apache2/mods-available/userdir.conf changed: IfModule mod_userdir.c UserDir web UserDir disabled root Directory /home/*/web AllowOverride FileInfo AuthConfig Limit Indexes Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec # Ignore default's allow/deny: over-ridden by server config. /Directory /IfModule /etc/apache2/ports.conf changed: Listen 80 IfModule mod_ssl.c # If you add NameVirtualHost *:443 here, you will also have to change # the VirtualHost statement in /etc/apache2/sites-available/default-ssl # to VirtualHost *:443 # Server Name Indication for SSL named virtual hosts is
Bug#685206: libwrap0:amd64: hosts_{options,access}.5.gz inconsistencies on format
Package: libwrap0
Version: 7.6.q-23
Severity: normal
Dear Debian Maintainer,
I tried to configure /etc/hosts.{allow,deny} using what man pages told
me; hosts.allow and hosts.deny alias to hosts_access in man. This told
me I could use lines of form
daemon_list : client_list [ : shell_command ]
but, in fact, I got errors logged by sshd when I used this format, due
to sshd actually using the format described in man hosts_options
daemon_list : client_list : option : option ...
(which should clearly be written as
daemon_list : client_list [ : option ...]
or similar, since options are optional). It was not immediately clear
what sshd was complaining about, of course - I only found out this was
the problem after writing to Wietse Venema for help ! - but once I'd got
the right information it was indeed possible to get what I wanted.
I thus find the man pages to be somewhat confusing - the one I get
naturally tells me a format that isn't actually supported; it does tell
me there's an extended version of the language, but doesn't make clear
that this is what's actually in use. I initially used
ALL : ALL : /usr/bin/logger -p auth.warning -- 'Denied %c (%n) access to %d on
%r'
in my hosts.deny but got error messages which didn't really (given only
the hosts_access man page's content) help me to make sense of what the
error really was; everything in the man page fitted with this being a
valid line to include. Changing to
ALL : ALL : severity auth.warning
did solve the problem. The hosts_access man page did say that
hosts_options supersedes shell_command support; but I, at least, failed
to recognise this as a clue that this was why my shell command wasn't
being recognised.
Further, given that the two syntaxes are incompatible, everything I can
see tells me that reading of /etc/hosts.{allow,deny} is up to each
application independently, so I have no way (as administrator of my box)
to know how I can avoid problems with my setup if some applications
choose to support the hosts_access format instead of the hosts_options
format. Likewise, an application developer has no indication of which
format they should support, to be compatible with configurations
administrators are apt to set up, or of how they should avoid getting
into trouble if the administrator has used the other format than the one
they've chosen to parse.
I can (now that I've tracked down what supplied these man pages) make an
educated guess that libwrap0 provides a library that deals with the
parsing on behalf of applications, but neither man page advises
application developers to use it, nor even mentions the existence of
such a library - as they clearly should. There should be a man page for
the APIs provided by the library and it should be referenced by the man
pages reached by man hosts.{allow,deny}, since that's where a
developer is apt to start trying to find out how to honour the system
configuration specified in these files.
Given that the extended format is now (apparently) what's supported by
default (in particular, it's what sshd expects - developers of other
applications are particularly likely to take their lead from sshd), it
seems to me that it would make sense to amalgamate the two man pages and
either remove all mention of the shell_command syntax or relegate it to
a historical / backwards-compatibility section, with advice on what to
do with files using this syntax, if encountered. The format now in
normal use should no longer be described as extended.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Versions of packages libwrap0:amd64 depends on:
ii libc6 2.13-33
ii multiarch-support 2.13-33
Versions of packages libwrap0:amd64 recommends:
ii tcpd 7.6.q-23
libwrap0:amd64 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#685206: libwrap0:amd64: hosts_{options,access}.5.gz inconsistencies on format
The current documentation has worked well enough for the past 15-20
years or so, but if you really believe that younger sysadmins ...
Hmm ... I think you're assuming that only sysadmins ever need to know
how to secure a computer. I think that every user of Linux is their own
acting sysadmin and, like myself, has no training in sysadmining. If
Linux is to actually be usable by the masses, we need to make it
practical for ordinary users to ensure their machines are suitably
secure. Being able to configure /etc/hosts.{allow,deny} is a proper
part of that. If explained properly, it's simple enough that users have
a fair chance at that; but the present man pages serve a new-comer
poorly.
please send me a patch for hosts_access(5) which removes references to
the old syntax.
I may give that a go - but, to do so, I'll need answers to:
* What are the man pages for libwrap's APIs ? The man pages for
hosts.{allow,deny} should reference these.
* Is it known that nothing still supports the old syntax ? I certainly
don't know. What was the actual history, and is it actually correct
to leave no mention of it ? When was it supported, on what systems,
and what incompatibilities may one encounter by failing to consider
the old syntax ?
The former should be referenced from the hosts_access(5) page; the
latter are matters that should be taken into account when deciding
whether to drop all mention of the old syntax or to include advice on
how to upgrade from it.
You are seriously misunderstanding how libwrap works: it is a library,
and it parses the hosts files by itself.
With due respect, I believe you are seriously misunderstanding my bug
report, a major part of which is that man hosts.{allow,deny} doesn't
give any clue that there's a library to parse these files. You don't
even seem to have noticed that I worked this out (albeit by guesswork
based on the package name, subsequently confirmed by looking at the
package's contents) !
Someone previously ignorant of how hosts.{allow,deny} work shall
naturally type man hosts.allow or man hosts.deny; and the information
they'll get is, frankly, misleading and incomplete. It describes an
out-of-date format for the files and fails to give any clue to the
existence of a library that implements proper support.
I am compelled to wonder how many applications that should be using this
library don't and, in practice, ignore anything but the first two fields
of hosts.{allow,deny} lines, since their authors got confused guidance,
on how to parse anything after that, from the documentation they
properly consulted to find out what to support.
Eddy.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684050: apache2-mpm-prefork: SuppressHTMLPreamble also discards data in the directory listing
Package: apache2-mpm-prefork Version: 2.2.22-9 Severity: normal Dear Maintainer, I was splitting up a validated index.html into README.html and HEADER.html in order to simplify access to contents of a local directory. The added HTML preamble and closing broke validation, so I looked up HeaderName and it advised me to enable IndexOptions +SuppressHTMLPreamble which I duly did in .htaccess; this worked as far as validation went, but the listing of directory contents became an unstyled UL simply listing the directory contents, each as a link. Without this directive, I got a nicely styled table with size, last modification and description, as well as the file-names. The documentation says: SuppressHTMLPreamble If the directory actually contains a file specified by the HeaderName directive, the module usually includes the contents of the file after a standard HTML preamble (html, head, et cetera). The SuppressHTMLPreamble option disables this behaviour, causing the module to start the display with the header file contents. The header file must contain appropriate HTML instructions in this case. If there is no header file, the preamble is generated as usual. Nothing about ditching the default styling of the directory listing ! I expected to simply lose the preamble before HEADER.html's content and /body/html after README.html's, retaining the usual directory listing. -- Package-specific info: List of enabled modules from 'apache2 -M': actions alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user autoindex cgi cgid dir env include info mime negotiation reqtimeout rewrite setenvif status userdir -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Versions of packages apache2-mpm-prefork depends on: ii apache2.2-bin 2.2.22-9 ii apache2.2-common 2.2.22-9 apache2-mpm-prefork recommends no packages. apache2-mpm-prefork 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#643763: dexconf fails due to missing xserver-xorg/config/device/bus_id
There's 1:6.14.2-1~bpo60+1 (and a newer X stack) in squeeze-backports if you want to try something. Thanks - I interpolate that this newer X stack exists in a more recent release of Debian. The given machine's /etc/issue reports Debian 6.0; which I see is squeeze, with wheezy in testing. I take it an upgrade to wheezy should be sufficient (and probably more robust than mixing versions ...), Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643763: dexconf fails due to missing xserver-xorg/config/device/bus_id
Switching to testing would give you a more ârecentâ stack, but you could drag a lot of breaka^Wfun with other packages and upgrade paths which might not be well tested yet. ;-) I'll settle for the fun ;-) Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643763: dexconf fails due to missing xserver-xorg/config/device/bus_id
This crash is fixed in the current upstream driver (as of 6.14.1), but only by disallowing rotation when acceleration is disabled. ah. That is sad. Build Operating System: Linux 2.6.37-trunk-amd64 x86_64 Debian [...] (--) RADEON(0): Chipset: ATI Radeon HD 5450 (ChipID = 0x68f9) [...] (II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS So this is your core problem, and AFAICT it's basically due to the X radeon driver being too old to properly support your card. and, I take it, no newer radeon driver for X is available. The perils of letting sysadmin give me a shiny new box with a very modern graphics card, I guess :-( Thanks for at least identifying what's wrong ! Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556555: closed by Arnaud Fontaine ar...@debian.org (Closing now irrelevant bug reports against python-xml)
It's shipped with python (you can use xml or elementtree module AFAIK). Great - thanks. I'll test the built-in modules and report if symptoms persist, Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556555: closed by Arnaud Fontaine ar...@debian.org (Closing now irrelevant bug reports against python-xml)
As python-xml was removed from the archive and is now only available in oldstable, I'm closing these bug reports. Is there some replacement for it in newer releases ? If so, what's the new package name ? Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643763: dexconf fails due to missing xserver-xorg/config/device/bus_id
Bug: a failing run of dexconf should at least report this ! Reconfiguring xserver-xorg should, ideally, at least fail with $? set when dexconf fails. Actually dexconf should stop existing. OK, and what will create my xorg.conf file ? Or what do I need to configure, instead, to tell the X server I want it to use my screen in portrait mode ? Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643763: dexconf fails due to missing xserver-xorg/config/device/bus_id
Hi again Julien, and thanks for your assistance. Section Monitor Identifier fill in randr output name here Option Rotate left EndSection I take it you mean an xorg.conf containing *only* this section will suffice; any content in xorg.conf will be merged to what would have been used without it. I'm not clear on what fill in randr output name here entails. I have no command named randr. I have one named xrandr; and its man page talks about outputs, but it appears to expect me to know the name of the output already. How do I query the system to obtain the relevant name ? I would previously have found that by looking at the name dexconf wrote into the xorg.conf file I can't get it to generate ... When I run xrandr with no args, it reports: quote Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 8192 x 8192 DVI-0 unknown connection (normal left inverted right x axis y axis) 1360x768 59.8 1152x864 60.0 1024x768 60.0 800x60060.3 640x48059.9 DVI-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 367mm x 275mm 1600x1200 60.0*+ 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x60075.0 60.3 640x48075.0 60.0 720x40070.1 /quote Which part of that is the output name ? Given that DVI-1 has *+ after one of its modes, I take it it's the one that's actually connected to the running X session. However, using DVI-1 as the output name above and restarting xdm, I render the new box unusable - xdm clearly shut down and tried to restart, but then the screen went black and no longer responded to the keyboard - fortunately, I can ssh into it to fix that. (My attempts to start an X session are currently hampered by something not liking the call to shopt in my ~/.bashrc and the uses of the function built-in in ~/.bash_profile, even though whatever's having the problem claims SHELL is /bin/bash - and, obviously, I can see no reason why anything but bash would be reading these files anyway - but I'll fight with that later. I was able to get xrandr to run before that hit ...) Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629526: aptitude: Extend f (forget) to provide for forgetting parts of the new-package list
Package: aptitude Version: 0.6.3-4 Severity: wishlist I mostly keep my systems on stable. When I upgrade to a new version, the New Packages folder in aptitude has thousands of entries. I am not going to succeed in reviewing all of those before the next time my nightly apticron does an update and potentially adds entries to the folders I thought I'd already reviewed; unless I start at the beginning each day (in which case I'll never reach the end) I'll miss some entries. It would be nice if there were some way of marking the entries I *have* reviewed (and decided whether to install) as no longer new without forgetting all the ones I *haven't* yet reviewed. For example: by analogy with f to forget all, F could forget the newness of the item currently selected; that may be a single package or it may be a folder. In the latter case, naturally, the contents of that folder are to be marked as no longer new. (Obviously, if F is already in use to mean some other thing, pick some other suitable key.) This would make it possible to do a rolling review of all new packages when I upgrade; each day I'd review some of the outstanding new packages and F these; the next day, apticron has updated the package list, so some new entries may have appeared in the folders I F'd last time; because I did F what I have reviewed, only these new entries are present in those folders, so I don't have to wade through what was already there to notice them. While it may take a long time to wade through thousands of packages, this at least makes the task feasible without suppressing everything that might update the package list for the duration of the time it takes to review them all. As it is, I either forget thousands of new packages without every reviewing them or never get round to reviewing the thousands of packages new in the new release - either way, I don't actually get to know about fancy new things someone has taken lots of time and effort to make available to me. -- Package-specific info: aptitude 0.6.3 compiled at Apr 2 2011 22:19:05 Compiler: g++ 4.5.2 Compiled against: apt version 4.10.1 NCurses version 5.8 libsigc++ version: 2.2.4.2 Ept support enabled. Gtk+ support disabled. Current library versions: NCurses version: ncurses 5.9.20110404 cwidget version: 0.5.16 Apt version: 4.10.1 linux-gate.so.1 = (0xb7791000) libapt-pkg.so.4.10 = /usr/lib/libapt-pkg.so.4.10 (0xb7664000) libncursesw.so.5 = /lib/libncursesw.so.5 (0xb761f000) libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0xb7619000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0xb7559000) libept.so.1 = /usr/lib/libept.so.1 (0xb7501000) libxapian.so.22 = /usr/lib/sse2/libxapian.so.22 (0xb72e4000) libz.so.1 = /usr/lib/libz.so.1 (0xb72d) libsqlite3.so.0 = /usr/lib/libsqlite3.so.0 (0xb7231000) libboost_iostreams.so.1.42.0 = /usr/lib/libboost_iostreams.so.1.42.0 (0xb721b000) libpthread.so.0 = /lib/i686/cmov/libpthread.so.0 (0xb7202000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb7113000) libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb70ed000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb70d) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb6f75000) libutil.so.1 = /lib/i686/cmov/libutil.so.1 (0xb6f71000) libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb6f6d000) libuuid.so.1 = /lib/libuuid.so.1 (0xb6f69000) libbz2.so.1.0 = /lib/libbz2.so.1.0 (0xb6f58000) librt.so.1 = /lib/i686/cmov/librt.so.1 (0xb6f4e000) /lib/ld-linux.so.2 (0xb7792000) Terminal: screen $DISPLAY is set. `which aptitude`: /usr/bin/aptitude aptitude version information: aptitude linkage: -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages aptitude depends on: ii apt [libapt-pkg4.10]0.8.14.1 Advanced front-end for dpkg ii libboost-iostreams1.42. 1.42.0-4+b1 Boost.Iostreams Library ii libc6 2.13-4 Embedded GNU C Library: Shared lib ii libcwidget3 0.5.16-3 high-level terminal interface libr ii libept1 1.0.5High-level library for managing De ii libgcc1 1:4.6.0-10 GCC support library ii libncursesw55.9-1shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.2.9-1 type-safe Signal Framework for C++ ii libsqlite3-03.7.6.3-1SQLite 3 shared library ii libstdc++6 4.6.0-10 The GNU Standard C++ Library v3 ii libxapian22 1.2.5-1 Search engine library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages
Bug#555647: x11-xserver-utils: xrandr -o left leaves xdm, after I logout, unresponsive, with no login prompt
Sorry for the delay, in the mean time did this get fixed, in squeeze, testing or unstable ? I'll need to log out to test, which would currently be rather disruptive - so there may be some delay ! But I'll try to find time for a test soon. Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607012: Work-around: purge nscd
Package: unscd Version: 0.47-1 Severity: normal When I initially selected unscd for installation, I got a conflict with nscd, so (in aptitude: typed M) marked nscd as only wanted if needed by something else. When it came time to install, I got essentially the same problem as this bug. Exiting aptitude I ran apt-get install uncsd 2unscd.err; here is the output file: file name=unscd.err insserv: script unscd: service nscd already provided! insserv: exiting now! update-rc.d: error: insserv rejected the script header dpkg: error processing unscd (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: unscd E: Sub-process /usr/bin/dpkg returned an error code (1) /file Aptitude indicated nscd, although uninstalled, still had config files (state: c) in place; so I marked it to be purged, with unscd (state: C) still trying to get itself installed. This worked. So purging nscd before installing unscd works round the problem. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages unscd depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib unscd recommends no packages. unscd 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#594334: git-rm after conflict spams me about the files being removed needing resolved
Could you provide some sample output? Yes, I know I can do it myself, but I am lazy. :) quote e...@pool:work$ git merge origin/topic-branch-blah Renaming stuff/parts/foobar.txt = stuff/parts/burble.txt Auto-merging stuff/parts/burble.txt CONFLICT (rename/modify): Merge conflict in stuff/parts/burble.txt CONFLICT (delete/modify): stuff/parts/frobnotz.txt deleted in HEAD and modified in origin/topic-branch-blah. Version origin/topic-branch-blah of stuff/parts/frobnotz.txt left in tree. Recorded preimage for 'stuff/parts/burble.txt' Automatic merge failed; fix conflicts and then commit the result. e...@pool:work$ emacs stuff/parts/burble.txt e...@pool:work$ git add stuff/parts/burble.txt e...@pool:work$ git rm stuff/parts/frobnotz.txt stuff/parts/frobnotz.txt: needs merge rm 'stuff/parts/frobnotz.txt' /quote (Based on an archived emacs M-x shell session from a real merge, but with large amounts of extraneous material deleted and the survivors renamed mercilessly. Obviously, I didn't actually invoke emacs from that command-line ...) Notice that I'm told frobnotz.txt needs merge by the very command in which I resolve its conflicts. Notice that the comparatively complex situation with burble.txt (where my work branch has renamed foobar.txt to it but the topic branch hadn't) is handled more gracefully. Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594334: git-rm after conflict spams me about the files being removed needing resolved
Package: git Version: 1:1.7.1-1.1 Severity: minor Tags: upstream When I've done a merge that got conflicts, I fix up the conflicts, then git add and git rm files as appropriate; git add is silent (even if there are further files in need of attention) but git rm nags me about files that still need merged and reports which files it is removing. The minor inconsistency here (add is silent, rm is chatty, by default) is a blemish, but endurable. More irritatingly, git rm even nags about the files I've told it to remove, before telling me that it's removing them. This nagging serves no purpose, other than to spam my command-line and move meaningful output further up my scroll-space and closer to the top of what I can scroll back to. I told it to remove the files: it should not be nagging me about the fact that I need to do something about them - it should know that I *am* doing something about them ! It is reasonable to report what files are being removed, it is even reasonable to nag me about files still in need of conflict resolution after the removals (albeit the hobgoblin of small minds would be happier of if rm and add behaved the same on this); but nagging me about the need to sort out a file I *am* sorting out, by the git rm command being executed, is pure wanton irritant. It would make sense for git rm's nagging to happen *after* it has done its removals: information about it doing what I told it to do is less interesting than information about what I need to do next, so it makes sense for the nagging to appear last in the output; and doing the check, for what to nag about, *after* the removals would avoid the spam. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages git depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.21.0-1 Multi-protocol file transfer libra ii libdigest-sha1-perl 2.13-1 NIST SHA-1 message digest algorith ii liberror-perl 0.17-1 Perl module for error/exception ha ii libexpat1 2.0.1-7 XML parsing C library - runtime li ii perl-modules5.10.1-14Core Perl modules ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages git recommends: ii less 436-1 pager program similar to more ii openssh-client [ssh-client] 1:5.5p1-4 secure shell (SSH) client, for sec ii patch 2.6-2 Apply a diff file to an original ii rsync 3.0.7-2fast remote file copy program (lik Versions of packages git suggests: pn git-arch none (no description available) ii git-cvs 1:1.7.1-1.1 fast, scalable, distributed revisi pn git-daemon-run none (no description available) ii git-doc 1:1.7.1-1.1 fast, scalable, distributed revisi pn git-emailnone (no description available) ii git-gui 1:1.7.1-1.1 fast, scalable, distributed revisi ii git-svn 1:1.7.1-1.1 fast, scalable, distributed revisi ii gitk 1:1.7.1-1.1 fast, scalable, distributed revisi ii gitweb 1:1.7.1-1.1 fast, scalable, distributed revisi -- 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#588231: apache2: Haphazard permission check on symlinks (might be a Linux bug)
It sounds much more likely that a browser or proxy server was caching the pages. When reloading, apache gave the 403. Can you rule that out? Yes. I use no proxy to access this machine (it's local). The directories in question had been drwx--s--- for many months, during which I'd re-booted the computer at least once and both upgraded and restarted the browser many many times. Many of the pages in question were new since the directory had its restrictive permissions. Yet the pages sometimes displayed - usually enough, in fact, that I only became aware of the problem because of a colleague having problem when he reloaded. So no way had the pages sat in my cache ever since they should have become inaccessible; and there was no proxy involved. Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588231: apache2: Haphazard permission check on symlinks (might be a Linux bug)
Package: apache2.2-common Version: 2.2.15-5 Severity: minor I use symlinks extensively, to expose fragments of my working directories (development source trees) in my userdir (all of which is subject to LDAP-based authentication). I had unwittingly set up some symlinks that went via directories which were drwx--s--- (in group cvs, to which www-data doesn't belong) and thus inaccessible to the web-server (running as user www-data), but the symlinks pointed to sub-sub-directories which were drwxr-xr-x. The web-server succeeded in displaying the contents *usually*, but one of my colleagues noticed that, on reload, he got 403'd. The fact that this (mostly) worked at all suggests that apache is sometimes accessing content as root, instead of as the unprivileged user www-data. The problem *might* be that Linux (the underlying O/S) is being flaky about enforcing permissions. -- Package-specific info: List of enabled modules from 'apache2 -M': actions alias auth_basic authn_file authnz_ldap authz_default authz_host authz_user autoindex cgi dir env ldap mime negotiation perl reqtimeout setenvif ssl status userdir -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages apache2 depends on: ii apache2-mpm-prefork 2.2.15-5 Apache HTTP Server - traditional n ii apache2.2-common 2.2.15-5 Apache HTTP Server common files apache2 recommends no packages. apache2 suggests no packages. Versions of packages apache2.2-common depends on: ii apache2-utils 2.2.15-5 utility programs for webservers ii apache2.2-bin 2.2.15-5 Apache HTTP Server common binary f ii libmagic1 5.04-2 File type determination library us ii lsb-base 3.2-23.1 Linux Standard Base 3.2 init scrip ii mime-support 3.48-1 MIME files 'mime.types' 'mailcap ii perl 5.10.1-13 Larry Wall's Practical Extraction ii procps1:3.2.8-9 /proc file system utilities -- 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#587896: libdevmapper1.02: init.d script prevents sysv-init from migrating to dependency-based boot
Hi Petter, Yeah, the problem is related to how libdevmapper1.02 was replaced with a package with a different version number. The short term solution is to purge the currently no longer installed libdevmapper1.02 package. After brief confusion (searching for libdevmapper got me the libdevmapper1.02.1 package and I didn't initially realise that wasn't the one I was looking for; removing it would have been problematic - I'll hazard a guess it's the replacement package) I find that this package is indeed un-needed. Mildly surprised it wasn't dumped by aptitude's dependency tracking on account of that - aptitude knew it was only present because it was pulled in as a dependency. One dpkg-reconfigure sysv-rc later, quote success: Enabled dependency-based boot system /quote :-) Not sure how to fix the problem properly using the package system. Would a Provides: in the replacement, purporting to provide the old, and maybe a Conflicts: to give it a bit of a kick, help ? Otherwise, find which packages mention it as an alternative in their Requires: or similar headers, get them to all stop mentioning it. I take it it's obsolete anyway ... Thanks for your help, Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#587891: python-ll-core: Depends on python 2.6 instead of, e.g., python2.5 | ...
Package: python-ll-core Version: 1.11.1-1 Severity: important I've asked aptitude to update, only to find it wants to upgrade python to 2.6 (yay !) and two packages (python-ll-core and python-xml) conflict with that because they depend on python 2.6 (i.e. the primary python package must be at a version less than 2.6) rather than depending on availability of a version of python earlier than 2.6. I have python2.5 installed anyway - and it's not going away just because 2.6 is becoming the default - so I can still use these packages, just not in the default python version. Presumably it should suffice to change the requirement to python 2.6 | python2.5 | python2.4 | ... and these packages will be happy with the transition. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages python-ll-core depends on: ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib ii python2.5.4-9An interactive high-level object-o ii python-support1.0.8 automated rebuilding support for P ii python2.5 2.5.5-6An interactive high-level object-o Versions of packages python-ll-core recommends: ii python-imaging1.1.7-1+b1 Python Imaging Library python-ll-core 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#557426: python-xml is unhappy even though I've kept python2.5 after python itself upgraded to 2.6
Package: python-xml Version: 0.8.4-10.1 Severity: normal I've asked aptitude to update, only to find it wants to upgrade python to 2.6 (yay !) and two packages (python-ll-core and python-xml) conflict with that because they depend on python 2.6 (i.e. the primary python package must be at a version less than 2.6) rather than depending on availability of a version of python earlier than 2.6. I have python2.5 installed anyway - and it's not going away just because 2.6 is becoming the default - so I can still use these packages, just not in the default python version. Presumably it should suffice to change the requirement to python 2.6 | python2.5 | python2.4 | ... and these packages will be happy with the transition. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages python-xml depends on: ii libc62.10.2-9Embedded GNU C Library: Shared lib ii python 2.5.4-9 An interactive high-level object-o ii python-central 0.6.14+nmu2 register and build utility for Pyt python-xml recommends no packages. Versions of packages python-xml suggests: pn python-xml-dbgnone (no description available) ii python-xml-doc0.8.4-10.1 XML tools for Python (documentatio -- 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#587896: libdevmapper1.02: init.d script prevents sysv-init from migrating to dependency-based boot
Package: libdevmapper1.02 Version: 2:1.02.08-1 Severity: normal When I install a new version of sysv-rc, it tries to migrate me to dependency-based booting; however, it complains about /etc/init.d/libdevmapper1.02 not having the needed meta-data in a header comment, and aborts. I've no idea what that's all about, only that this package is causing problems for another ! I'm on testing and sysv-rc is currently on version 2.88dsf-9 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages libdevmapper1.02 depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libselinux1 2.0.94-1 SELinux runtime shared libraries ii libsepol1 2.0.41-1 SELinux library for manipulating b libdevmapper1.02 recommends no packages. libdevmapper1.02 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#574624: dibbler-client: Also impossible to upgrade, as prerm fails.
Package: dibbler-client Version: 0.7.3-0.1 Severity: normal dpkg -i /var/cache/apt/archives/dibbler-client_0.7.3-1_i386.deb stdout (Reading database ... 219115 files and directories currently installed.) Preparing to replace dibbler-client 0.7.3-0.1 (using .../dibbler-client_0.7.3-1_i386.deb) ... Stopping DHCPv6 client: Stopping DHCPv6 client: /stdout stderr invoke-rc.d: initscript dibbler-client, action stop failed. dpkg: warning: subprocess old pre-removal script returned error exit status 1 dpkg - trying script from the new package instead ... invoke-rc.d: initscript dibbler-client, action stop failed. dpkg: error processing /var/cache/apt/archives/dibbler-client_0.7.3-1_i386.deb (--install): subprocess new pre-removal script returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/dibbler-client_0.7.3-1_i386.deb /stderr dibbler-client's prerm script fails because it asks the init-script to stop the running dibbler client and the init-script forwards the request to the daemon, which fails (here re-run after a manual init-script start, to find out what went wrong): quote src=/usr/sbin/dibbler-client stop | Dibbler - a portable DHCPv6, version 0.7.3 (CLIENT, Linux port) | Authors : Tomasz Mrugalskithomson(at)klub.com.pl,Marek Senderskimsend(at)o2.pl | Licence : GNU GPL v2 only. Developed at Gdansk University of Technology. | Homepage: http://klub.com.pl/dhcpv6/ Attaching to process 1539 failed: No such process Warning: Can not guarantee for remote process termination Sending TERM signal to process 1539 Signal sending failed: No such process /quote The init-script tells the daemon to stop in a sub-shell that follows up with true, apparently in an effort to ignore any failure here, but this doesn't seem to work ! The init-script fails, so prerm does too. I am thus unable to upgrade dibbler-client from 0.7.3-0.1. However, after a little perseverence, I found that commenting out the set -e line in /etc/init.d/dibbler-client sufficed to solve the problem; that's what causes the failing $DAEMON stop to abort the script. That implies the following suggestion for how to fix this: change prior stop) echo -n Stopping $DESC: ($DAEMON stop 21 /dev/null; true) echo $NAME. ;; /prior to fixed stop) echo -n Stopping $DESC: ($DAEMON stop 21 /dev/null || true) echo $NAME. ;; /fixed and you should be OK :-) The issue is that set -e is inherited by the sub-shell, which duly exits (failing) before your ; true can have any effect; however, || true does what you want - set -e only applies to the end result of any chain of || and operations. You need to do the same in restart|force-reload) as well, where it calls stop. I also note that your 21 /dev/null says send errors to where standard output would previously have gone, but send standard output to /dev/null; if what you want is send errors and output to /dev/null then you need to do the redirects (somewhat counter-intuitively [*]) in the reverse order: /dev/null 21 That applies to both stop and start uses of $DAEMON. [*] if you doubt this, try the following: (echo stderr 2; echo stdout) 21 /dev/null and vary the outer redirects to see how they interact. In the form given, using your redirect, stderr gets displayed. In the reversed /dev/null 21 form, all output is sent to /dev/null -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages dibbler-client depends on: ii debconf 1.5.32 Debian configuration management sy ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.4-5 GCC support library ii libstdc++64.4.4-5The GNU Standard C++ Library v3 ii ucf 3.0025 Update Configuration File: preserv Versions of packages dibbler-client recommends: ii dibbler-doc 0.7.3-1documentation for Dibbler dibbler-client suggests no packages. -- debconf information: * dibbler-client/start: true dibbler-client/title: * dibbler-client/options: dns, domain * dibbler-client/interfaces: eth0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583560: g++-4.1 and gcc-4.1 demand different gcc-4.1-base versions
Package: gcc-4.1-base Version: 4.1.2-27 Severity: important g++-4.1 and libstdc++6-4.1-dev demand gcc-4.1-base = 4.1.2-27 gcc-4.1 and cpp-4.1 demand gcc-4.1-base = 4.1.2-29 I can only avoid conflict by holding everything back at -27 :-( I suppose this is just a release synchronisation glitch. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- 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#553206: libc6: Similar fail for %llu on 0x200000-long string of '9's
OK, I've now built glibc (overnight - it took nearly four hours) in
debug and caught the crash in gdb. We're in ADDW (L_('\0')), right
after the comment /* Convert the number. */ quote src=gdb
(gdb) run
Starting program: /disk/home/eddy/work/mine/toys/sscanferange
Program received signal SIGSEGV, Segmentation fault.
0xb7ee1e81 in _IO_vfscanf_internal (s=0xbfdff2dc, format=0x80485a0 %llu,
argptr=0xbfdff3a8 ¸óÿ¿, errp=0x0) at vfscanf.c:1760
(gdb) p wpsize
$1 = 2097152
(gdb) p wpmax
$2 = 4194304
(gdb) p old
$3 = value optimized out
(gdb) p wp
$4 = 0xbf5fef70 Address 0xbf5fef70 out of bounds
(gdb) p/x wpmax
$5 = 0x40
/quote OK, that sounds like it's probably the problem. Perhaps
alloca can't handle 4MiB allocations ! Unfortunately, its return, in
this case, isn't the NULL checked for. Indeed, ADDW's check for NULL
is pointless - alloca() is not specified to do so:
quote src=man alloca
RETURN VALUE
The alloca() function returns a pointer to the beginning of the
allocated space. If the allocation causes stack overflow,
program behavior is undefined.
/quote
It's also worth noting that, by the time it comes to this call to
alloca, the code has previously alloca()-ed 0x3fff00 bytes of memory,
since ADDW does a doubling game to get to this point; using realloc
might be more apt. Of course, since this is in read-number code, it
might be better yet for the code to notice it's overflowed, set ERANGE
and simply skip over digits of input until it finds something else,
without any copying. Unfortunately, the code is sufficiently
convoluted that I don't see how to change it to do that ...
For reference: quote src=gdb
(gdb) p *s
$6 = {_flags = -72515583, _IO_read_ptr = 0xb3b7 , _IO_read_end =
0xb3b7 , _IO_read_base = 0xbfdff3b7 '9' repeats 200 times...,
_IO_write_base = 0xbfdff3b7 '9' repeats 200 times..., _IO_write_ptr =
0xbfdff3b7 '9' repeats 200 times..., _IO_write_end = 0xbfdff3b7 '9' repeats
200 times..., _IO_buf_base = 0xbfdff3b7 '9' repeats 200 times...,
_IO_buf_end = 0xb3b7 , _IO_save_base = 0x0, _IO_backup_base = 0x0,
_IO_save_end = 0x0, _markers = 0x0, _chain = 0x0, _fileno = 0, _flags2 = 16,
_old_offset = 0, _cur_column = 0, _vtable_offset = 0 '\000', _shortbuf = ,
_lock = 0x0, _offset = 3086879200, _codecvt = 0x, _wide_data =
0xb7ffeff4, _freeres_list = 0x0, _freeres_buf = 0xb7fff670, _freeres_size =
3219125120, _mode = -1, _unused2 =
(øÿ·p\rþ·\001\000\000\000\001\000\000\000\000\000\000\000U\202\004\b\003\000\000\000\000\000\000\000¨\226\004\b\001\000\000}
(gdb) bt
#0 0xb7ee1e81 in _IO_vfscanf_internal (s=0xbfdff2dc, format=0x80485a0 %llu,
argptr=0xbfdff3a8 ¸óÿ¿, errp=0x0) at vfscanf.c:1760
#1 0xb7ee7a65 in *__GI___isoc99_vsscanf (string=0xbfdff3b7 '9' repeats 200
times..., format=0x80485a0 %llu, args=0xbfdff3a8 ¸óÿ¿) at
isoc99_vsscanf.c:44
#2 0xb7ee79bf in __isoc99_sscanf (s=0xbfdff3b7 '9' repeats 200 times...,
format=0x80485a0 %llu) at isoc99_sscanf.c:33
#3 0x080484bf in main () at sscanferange.c:13
(gdb) up 3
#3 0x080484bf in main () at sscanferange.c:13
(gdb) p (buf[0])
$8 = 0xbfdff3b7 '9' repeats 200 times...
/quote so it's just copied the very last character when this
happens.
If there are other things maintainers would like to know about details
of this bug, I can easilly reproduce and ferret out the information
you need - although I'll probably delete my debug build of glibc
before many weeks have passed,
Eddy.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553206: libc6: Similar fail for %llu on 0x200000-long string of '9's
Package: libc6
Version: 2.10.2-6
Severity: normal
Here's a stack-trace: quote src=gdb
(gdb) run
Starting program: /disk/home/eddy/work/mine/toys/sscanferange
Program received signal SIGSEGV, Segmentation fault.
0xb7ee1d2d in _IO_vfscanf_internal (s=0xbfdff2dc, format=0x8048540 %llu,
argptr=0xbfdff3a8 žóÿ¿, errp=0x0) at vfscanf.c:1760
1760vfscanf.c: No such file or directory.
in vfscanf.c
(gdb) bt
#0 0xb7ee1d2d in _IO_vfscanf_internal (s=0xbfdff2dc, format=0x8048540 %llu,
argptr=0xbfdff3a8 žóÿ¿, errp=0x0) at vfscanf.c:1760
#1 0xb7ee79c5 in *__GI___isoc99_vsscanf (string=0xbfdff3b7 '9' repeats 200
times..., format=0x8048540 %llu, args=0xbfdff3a8 žóÿ¿) at
isoc99_vsscanf.c:44
#2 0xb7ee791f in __isoc99_sscanf (s=0xbfdff3b7 '9' repeats 200 times...,
format=0x8048540 %llu) at isoc99_sscanf.c:33
#3 0x08048474 in main () at sscanferange.c:11
/quote produced by this source file name=sscanferange.c
#include stdio.h
#include string.h
#include errno.h
#define SIZE 0x20 // crashes; 0x1f is ok
int main()
{
unsigned long long val;
char buf[SIZE + 1];
memset(buf, '9', SIZE);
buf[SIZE] = '\0';
errno = 0;
return 1 != sscanf(buf, %llu, val) || errno != ERANGE;
}
/file
There appears to be a two megabyte limit on endurable length of
the string of digits.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages libc6 depends on:
ii libc-bin 2.10.2-6 Embedded GNU C Library: Binaries
ii libgcc1 1:4.4.2-9 GCC support library
Versions of packages libc6 recommends:
ii libc6-i6862.10.2-6 GNU C Library: Shared libraries [i
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy
ii glibc-doc 2.10.2-6 Embedded GNU C Library: Documentat
ii locales 2.10.2-6 Embedded GNU C Library: National L
-- debconf information:
* glibc/upgrade: true
* glibc/disable-screensaver:
glibc/restart-failed:
* glibc/restart-services: rsync openbsd-inetd nis exim4 cups cron atd xdm
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559142: reproduced and fixed on x86_64: patch included :-)
Hi again Guillem, It should be under one of the /usr/share/fonts/truetype/ directories, as the server does chdir to them when scanning. Sure enough, found in /usr/share/fonts/truetype/ttf-lucida/ Could you check if there's a broken symlink somewhere there? The same directory contained a bunch of broken symlinks, e.g. LucidaBrightDemiBold.ttf - ../../../../lib/jvm/java-6-sun-1.6.0.12/jre/lib/fonts/LucidaBrightDemiBold.ttf that clearly should have been updated on an upgrade to Java, since /usr/lib/jvm/java-6-sun-1.6.0.16/jre/lib/fonts/ exists, but no java-6-sun-1.6.0.12 Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559142: reproduced and fixed on x86_64: patch included :-)
/quote have you any idea where the core dump went ? I need to find it to tidy it away ! It should be under one of the /usr/share/fonts/truetype/ directories, as the server does chdir to them when scanning. I don't know what's allegedly corrupt about /usr/share/fonts/truetype/; it looks like a perfectly sensible directory to me, with Isabella.ttf and a bunch of subdirectories in it. Could you check if there's a broken symlink somewhere there? OK, I'll be running find in that directory anyway, to find the core files; no doubt it has a combination of options I can use to find broken symlinks, too ... Then again, thinking about it, it's possible that the corruption was an illusion caused by the same bug as caused the crash - I don't think I've seen that message since fixing the bug. Still, doesn't hurt to check ... Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559142: reproduced and fixed on x86_64: patch included :-)
Subject: reproduced and fixed on x86_64: patch included :-)
Followup-For: Bug #559142
Package: xfstt
Version: 1.7-5
*** Please type your report below this line ***
I get
xfstt[3155]: segfault at 4 ip 4085e4 sp 7fffbe604f50 error 4 in
xfstt[40+19000]
on start-up. RandomAccessFile::RandomAccessFile(char * filename)'s
error path, on failure to open file, neglects to set absbase; this leads
to openError() failing to report that open failed, so instances think
they're OK and try to use methods that should only be used if open
succeeded - boom ! Have a trivial patch
diff -u /root/xfstt/xfstt-1.7/libfstt/rafile.cc.orig
/root/xfstt/xfstt-1.7/libfstt/rafile.cc
--- /root/xfstt/xfstt-1.7/libfstt/rafile.cc.orig2010-01-24
06:14:53.0 +0100
+++ /root/xfstt/xfstt-1.7/libfstt/rafile.cc 2010-01-24 06:10:55.0
+0100
@@ -176,7 +176,7 @@
int fd = open(fileName, O_RDONLY);
if (fd = 0) {
debug(Cannot open \%s\\n, fileName);
- ptr = base = 0;
+ ptr = absbase = base = 0;
return;
}
struct stat st;
Diff finished. Sun Jan 24 06:15:47 2010
/patch which has fixed the problem for me.
Incidentally, as I initially followed your instructions: quote src=console
vortex:~# xfstt
corrupt font database!
opening TTF database failed, while reading /usr/share/fonts/truetype to build
it.
Sync in directory /usr/share/fonts/truetype/..
Sync in directory /usr/share/fonts/truetype/ttf-lucida.
[49632.125872] xfstt[11488]: segfault at 0 ip 40b29d sp 7fff5de31680 error 4 in
xfstt[40+21000]
Segmentation fault (core dumped)
vortex:~# list
notes notes.old old/ xfstt/
/quote have you any idea where the core dump went ? I need to find it
to tidy it away !
I don't know what's allegedly corrupt about /usr/share/fonts/truetype/;
it looks like a perfectly sensible directory to me, with Isabella.ttf
and a bunch of subdirectories in it.
For the record, here's my gdb session: gdb
Current directory is /usr/bin/
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu...
(gdb) run
Starting program: /usr/bin/xfstt
corrupt font database!
opening TTF database failed, while reading /usr/share/fonts/truetype to build
it.
Sync in directory /usr/share/fonts/truetype/..
Sync in directory /usr/share/fonts/truetype/ttf-lucida.
Program received signal SIGSEGV, Segmentation fault.
0x0040b29d in RandomAccessFile::readUInt (this=0x12bdd00) at ttf.h:132
(gdb) p ptr
$1 = (u8_t *) 0x0
(gdb) up
#1 0x0040c68e in TTFont (this=0x12bdd00, fileName=0x12bcd3b
LucidaSansOblique.ttf, infoOnly=1) at ttfont.cc:45
(gdb) down
#0 0x0040b29d in RandomAccessFile::readUInt (this=0x12bdd00) at
ttf.h:132
(gdb) bt
#0 0x0040b29d in RandomAccessFile::readUInt (this=0x12bdd00) at
ttf.h:132
#1 0x0040c68e in TTFont (this=0x12bdd00, fileName=0x12bcd3b
LucidaSansOblique.ttf, infoOnly=1) at ttfont.cc:45
#2 0x00405197 in ttSyncDir (infoFile=0x12bc850, nameFile=0x12bca90,
ttdir=0x12bb85b ttf-lucida, gslist=0) at xfstt.cc:198
#3 0x0040582c in ttSyncAll (gslist=0) at xfstt.cc:328
#4 0x004078e9 in main (argc=1, argv=0x7fff6a154438) at xfstt.cc:2039
(gdb) up
#1 0x0040c68e in TTFont (this=0x12bdd00, fileName=0x12bcd3b
LucidaSansOblique.ttf, infoOnly=1) at ttfont.cc:45
(gdb) p *this
$2 = {RandomAccessFile = {ptr = 0x0, base = 0x0, absbase = 0x7f10bc3d8000
Address 0x7f10bc3d8000 out of bounds, length = 140028}, nameTable = 0x0,
headTable = 0x0, maxpTable = 0x0, cmapTable = 0x0, locaTable = 0x0, glyphTable
= 0x0, fpgmTable = 0x0, prepTable = 0x0, cvtTable = 0x0, hheaTable = 0x0,
hmtxTable = 0x0, os2Table = 0x0, ltshTable = 0x0, hdmxTable = 0x0, vdmxTable =
0x0, gaspTable = 0x0, kernTable = 0x0, ebdtTable = 0x0, eblcTable = 0x0,
mortTable = 0x0, vheaTable = 0x0, endPoints = 0x0, points = 0x0}
(gdb) up
#2 0x00405197 in ttSyncDir (infoFile=0x12bc850, nameFile=0x12bca90,
ttdir=0x12bb85b ttf-lucida, gslist=0) at xfstt.cc:198
(gdb) down
#1 0x0040c68e in TTFont (this=0x12bdd00, fileName=0x12bcd3b
LucidaSansOblique.ttf, infoOnly=1) at ttfont.cc:45
(gdb)
#0 0x0040b29d in RandomAccessFile::readUInt (this=0x12bdd00) at
ttf.h:132
(gdb) up
#1 0x0040c68e in TTFont (this=0x12bdd00, fileName=0x12bcd3b
LucidaSansOblique.ttf, infoOnly=1) at ttfont.cc:45
(gdb) down
#0 0x0040b29d in RandomAccessFile::readUInt (this=0x12bdd00) at
ttf.h:132
Breakpoint 1 at 0x40b084: file rafile.cc, line 179. (2 locations)
(gdb) down
Bottom (innermost) frame selected; you cannot go down.
(gdb) up
#1 0x0040c68e in TTFont (this=0x12bdd00, fileName=0x12bcd3b
Bug#556555: python-xml: Round-tripping an XML document wantonly messes up blanks
Package: python-xml
Version: 0.8.4-10.1
Severity: minor
Save the following SVG to a file file
?xml version=1.0 encoding=utf-8?!--*- Mode: sgml; coding: utf-8;
tab-width: 5; -*--
!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.1 Tiny//EN'
'http://www.w3.org/Graphics/SVG/1.1/DTD/svg11-tiny.dtd'
svg baseProfile=tiny version=1.1 xml:lang=en-GB
viewBox=-90 0 3920 4100
xmlns=http://www.w3.org/2000/svg;
xmlns:xlink=http://www.w3.org/1999/xlink;
titleTest-case to illustrate expat issue/title
desc
Parse this with an xml parser then ask the parsed object to
serialise itself as text. The result is not what you started with.
It would be nice if it were.
/desc
path d=M0,1450
L30,1560
L3920,2370
id=high stroke=blue /
/svg
/file then run
from xml.dom.expatbuilder import parse
dom = parse('path/to/the/file.svg')
print dom.toxml('utf-8')
The result has a line-break before the emacs mode-line comment; this
prevents this comment from actually configuring what mode emacs shall
use to handle the resulting file - it only does its magic if it
appears on the first line of the file.
The result also joins the lines of the path element below, notably
those making up its d=... attribute. In the real SVG on which this
test-case is based, the path records several hundred data points: it
is convenient and desirable to break the attribute's value into
convenient-sized lines. Not only does this make the source file
easier to read: it also localizes the changes, when I add new
data-points to the graph; this, in turn, ensures that version-control
software correctly reports sensible diffs, that make it easy to see
the additions, instead of merely recording that the entire attribute
has changed. (Actual additions to the d attribute are made using a
script which uses the above code but manipulates the dom object
between parsing and output, to find the d attribute and add the new
data to it. Having the text changed as described here, rather than
only having the data added, forces me to clean up the result later.)
I have verified that these issues are present in python-xml-0.8.4-10.1.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages python-xml depends on:
ii libc62.10.1-5GNU C Library: Shared libraries
ii python 2.5.4-2 An interactive high-level object-o
ii python-central 0.6.12+nmu1 register and build utility for Pyt
python-xml recommends no packages.
Versions of packages python-xml suggests:
pn python-xml-dbgnone (no description available)
ii python-xml-doc0.8.4-10.1 XML tools for Python (documentatio
-- 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#555648: x11-xserver-utils: xrandr -o left: starts up with squished fonts; aspect ratio not adjusted ?
I've now added Option Rotate left to Section Monitor in my /etc/X11/xrdb.conf so that xrdb operates in portrait mode ab initio, which avoids the need to invoke xrandr -o left, hence avoids the problem. However, it would obviously be better if xrandr and the font infrastructure played nicely with one another anyway ... Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555647: x11-xserver-utils: xrandr -o left leaves xdm, after I logout, unresponsive, with no login prompt
I use xrandr -o left in my .xsession so that I can use my screen in portrait mode. I'm now achieving the equivalent effect by adding Option Rotate left to Section Monitor of my /etc/X11/xorg.conf (which avoids the font problems I had with xrandr -o left) and now find that xdm always hangs after I log out (where, previously, it only used to hang if I ran xrandr -o -left in my user session). When the X session is hanging, after I've logged out, I find that /etc/init.d/xdm stop fails, claiming that the xdm.pid file doesn't exist, even though ps reports that the xdm process is still running. I notice that xmd has two child processes: USER PID PPIDSZVSZ RSZ NI CMD root 17331 1 1399 5596 940 0 /usr/bin/xdm root 20618 17331 6763 27052 15008 0 /usr/bin/X :0 vt7 -nolisten tcp -auth /var/lib/xdm/authdir/authfiles/A:0-chlHyX root 20622 17331 2104 8416 5236 0 -:0 When logging out has hung the X session, killing the last (which has a symlink to /usr/bin/xdm as its /proc/20622/exe) causes xdm to exit; whereas killing the /usr/bin/X process persuades the xdm process to start a new X login prompt, which works as usual. Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555647: x11-xserver-utils: xrandr -o left leaves xdm, after I logout, unresponsive, with no login prompt
Package: x11-xserver-utils Version: 7.4+2 Severity: normal I use xrandr -o left in my .xsession so that I can use my screen in portrait mode. However, after a recent upgrade, I find that when I log out (exit fvwm) I don't get the xdm login prompt I'm expecting. I have to restart xdm. Previously, when I logged out, xdm's login prompt was correctly oriented for the portrait mode in which I was using the screen - which was potentially an issue, since a feature of my session survived to affect whoever might log in after me. However, this worked nicely for me; in particular, it facilitated a work-around for a problem with the fonts used in portrait mode, the first time I logged in; logging out and back in fixed it. I can no longer do that. Tell me what I need to log to help diagnose the problem ... -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages x11-xserver-utils depends on: ii cpp 4:4.3.3-9+nmu1 The GNU C preprocessor (cpp) ii libc6 2.10.1-5 GNU C Library: Shared libraries ii libice6 2:1.0.5-1 X11 Inter-Client Exchange library ii libsm62:1.1.1-1 X11 Session Management library ii libx11-6 2:1.2.2-1 X11 client-side library ii libxau6 1:1.0.5-1 X11 authorisation library ii libxaw7 2:1.0.6-1 X11 Athena Widget library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxi62:1.2.1-2 X11 Input extension library ii libxmu6 2:1.0.4-2 X11 miscellaneous utility library ii libxmuu1 2:1.0.4-2 X11 miscellaneous micro-utility li ii libxrandr22:1.3.0-2 X11 RandR extension library ii libxrender1 1:0.9.4-2 X Rendering Extension client libra ii libxt61:1.0.6-1 X11 toolkit intrinsics library ii libxtrap6 2:1.0.0-5 X11 event trapping extension libra ii libxxf86misc1 1:1.0.1-3 X11 XFree86 miscellaneous extensio ii libxxf86vm1 1:1.0.2-1 X11 XFree86 video mode extension l ii x11-common1:7.4+4X Window System (X.Org) infrastruc x11-xserver-utils recommends no packages. Versions of packages x11-xserver-utils suggests: pn cairo-5c none (no description available) pn nicklenone (no description available) -- 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#555648: x11-xserver-utils: xrandr -o left: starts up with squished fonts; aspect ratio not adjusted ?
Package: x11-xserver-utils Version: 7.4+2 Severity: normal In my .xsession, I run xrandr -o left which lets me use my screen in portrait mode. (Many modern flat screens, including the Dell one I'm using, have a pivot at the back that lets one turn them sideways.) Unfortunately, doing this gets me a bunch of broken fonts. I exec fvwm at the end of .xsession and it comes up with menus that are barely readable: it looks as if the fonts have got their metrics set for the original orientation, or something like that. Until recently, it has been the case that I can simply exit and log in again; the login prompt from xdm came up in the right orientation for portrait mode and I got started sensibly on the second atttempt, with perfectly sensible fonts. I'll report the new problem separately, that now prevents me using that work-around ... it's rather more severe ! I don't know what makes that go wrong, but clearly xrandr needs to do something differently to ensure The Right fonts show up once X gets going - perhaps it needs to restart xfs ? I don't know how any of this works, though. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages x11-xserver-utils depends on: ii cpp 4:4.3.3-9+nmu1 The GNU C preprocessor (cpp) ii libc6 2.10.1-5 GNU C Library: Shared libraries ii libice6 2:1.0.5-1 X11 Inter-Client Exchange library ii libsm62:1.1.1-1 X11 Session Management library ii libx11-6 2:1.2.2-1 X11 client-side library ii libxau6 1:1.0.5-1 X11 authorisation library ii libxaw7 2:1.0.6-1 X11 Athena Widget library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxi62:1.2.1-2 X11 Input extension library ii libxmu6 2:1.0.4-2 X11 miscellaneous utility library ii libxmuu1 2:1.0.4-2 X11 miscellaneous micro-utility li ii libxrandr22:1.3.0-2 X11 RandR extension library ii libxrender1 1:0.9.4-2 X Rendering Extension client libra ii libxt61:1.0.6-1 X11 toolkit intrinsics library ii libxtrap6 2:1.0.0-5 X11 event trapping extension libra ii libxxf86misc1 1:1.0.1-3 X11 XFree86 miscellaneous extensio ii libxxf86vm1 1:1.0.2-1 X11 XFree86 video mode extension l ii x11-common1:7.4+4X Window System (X.Org) infrastruc x11-xserver-utils recommends no packages. Versions of packages x11-xserver-utils suggests: pn cairo-5c none (no description available) pn nicklenone (no description available) -- 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#494267: xscreensaver forgot how to grok xrandr -o left
Yay ! I did an update (on squeeze) yesterday and finally got a version of xscreensaver with this issue fixed :-) Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530535: apache2: Apache fails to follow symlinks via other symlinks
Sorry about the lack of reply - your mail got lost in what came while I was on holiday and I only now got back to it. I can't reproduce your problem. Are you sure all involved directories are accessible for the www-data user? I now slap myself on the fore-head - indeed, one of the directories involved was drwxr-s--- - thank you for spotting my idiotic mistake, this is not a bug ! Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543676: closed by Sven Joachim svenj...@gmx.de (Re: Bug#543676: emacs-23: emacs23 fails to rmail-ify my rmail box due to some problem with a tempfile)
It might be useful to load the uncompiled rmail.el OK, as noted earlier, this made me notice that I had old .elc files lying around; on removing all of those and starting up emacs23, I find that everything works fine Unfortunately, I seem to be a donkey. I actually started up emacs 22 - must have found the wrong icon, by habit, in the menu :-( When I use emacs23 (with no .elc files in site now) I still get the same problem. Please send a lisp backtrace after M-x toggle-debug-on-error. quote Debugger entered--Lisp error: (void-variable rmail-highlight-face) (identity rmail-highlight-face) (or (identity rmail-highlight-face) (if (face-differs-from-default-p ...) (quote bold) (quote highlight))) (defvar rmime-highlight-face (or (identity rmail-highlight-face) (if ... ... ...))) eval-buffer(#buffer *load* nil /disk/home/eddy/.sys/elisp/rmime.el nil t) ; Reading at buffer position 10081 load-with-code-conversion(/disk/home/eddy/.sys/elisp/rmime.el /disk/home/eddy/.sys/elisp/rmime.el t t) require(rmime nil t) unrmail(/disk/home/eddy/.sys/tmp/rmail124673Jw /disk/home/eddy/.sys/tmp/rmail12467EU2) rmail-convert-babyl-to-mbox() rmail-convert-file-maybe() rmail-mode() set-auto-mode-0(rmail-mode nil) byte-code(Å/ ...@Æ! ÇÈ \( ÉÊ \f\( ËÌÅ\\nA *Å [modes mode --dolist-tail-- done keep-mode-if-same nil functionp message Ignoring unknown mode `%s' t set-auto-mode-0 throw nop] 4) set-auto-mode() normal-mode(t) after-find-file(nil t) find-file-noselect-1(#buffer primary ~/mail/pending/primary nil nil /home/eddy/mail/pending/primary ((24595 . 52947) 19)) find-file-noselect(~/mail/pending/primary nil nil t) find-file(~/mail/pending/primary t) call-interactively(find-file nil nil) /quote hmm ... seems to implicate rmime a lot. So I commented out quote (add-hook 'rmail-show-message-hook 'rmime-format) (add-hook 'rmail-edit-mode-hook'rmime-cancel) (autoload 'rmime-format rmime nil) /quote from my config and tried again, getting: quote Debugger entered--Lisp error: (void-variable rmail-highlight-face) (identity rmail-highlight-face) (or (identity rmail-highlight-face) (if (face-differs-from-default-p ...) (quote bold) (quote highlight))) (defvar rmime-highlight-face (or (identity rmail-highlight-face) (if ... ... ...))) eval-buffer(#buffer *load* nil /disk/home/eddy/.sys/elisp/rmime.el nil t) ; Reading at buffer position 10081 load-with-code-conversion(/disk/home/eddy/.sys/elisp/rmime.el /disk/home/eddy/.sys/elisp/rmime.el t t) require(rmime nil t) unrmail(/disk/home/eddy/.sys/tmp/rmail12506W5j /disk/home/eddy/.sys/tmp/rmail12506jDq) rmail-convert-babyl-to-mbox() rmail-convert-file-maybe() rmail-mode() set-auto-mode-0(rmail-mode nil) byte-code(Å/ ...@Æ! ÇÈ \( ÉÊ \f\( ËÌÅ\\nA *Å [modes mode --dolist-tail-- done keep-mode-if-same nil functionp message Ignoring unknown mode `%s' t set-auto-mode-0 throw nop] 4) set-auto-mode() normal-mode(t) after-find-file(nil t) find-file-noselect-1(#buffer primary ~/mail/pending/primary nil nil /home/eddy/mail/pending/primary ((24595 . 52947) 19)) find-file-noselect(~/mail/pending/primary nil nil t) find-file(~/mail/pending/primary t) call-interactively(find-file nil nil) /quote hmm ... still involves lots of rmime - maybe that's built-in these days. Moved my copies of metamail.el, rmailmime.el, rmime.el to an out-of-the-way directory (I think only the last was actually being used, but hey ... its fellow travellers can go with it). The loading of a sample babyl-format file then proceeds with a minor delay but no hitch. So bug is still closed, but I closed it for all the wrong reasons ! Actual cause was an out-of-date rmime.el from I-forget-where, not a problem with .elc files, Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543676: emacs-23: emacs23 fails to rmail-ify my rmail box due to some problem with a tempfile
Unfortunately, the emacs23 emacsclient is not compatible with the emacs22 server, and vice versa. However, M-x server-start in emacs23 should work, That's what I did, when I got the the first error message from reportbug trying to invoke emacsclient, before retrying the edit - with no success. unless you already have a server running from another Emacs session. I'd exited my other emacs session. I trust other users' sessions don't present any problem ... Please send a lisp backtrace will have to wait until I can disrupt work (and saved state in the running session) to do so. Hopefully later today - before I've built up too much saved state ! It might be useful to load the uncompiled rmail.el ah ! Now, therein lies a clue: I hadn't purged emacs22's .elc files before starting emacs23 - might that be apt to cause trouble ? Is /tmp on the same filesystem as /disk/home/eddy/.sys/tmp ? No: quote src=df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 9614116 6811780 2313964 75% / /dev/sda3142260404 55104500 79929468 41% /disk /quote Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543676: emacs-23: emacs23 fails to rmail-ify my rmail box due to some problem with a tempfile
It might be useful to load the uncompiled rmail.el OK, as noted earlier, this made me notice that I had old .elc files lying around; on removing all of those and starting up emacs23, I find that everything works fine - so the problem was only that .elc files needed to be purged (and regenrated). I also find (with my starting of emacsclient adjusted based on your comments) that emacsclient works fine. Sorry to have wasted your time - I should remember to purge .elc files on an upgrade ! This means you can close this bug :-) Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543676: emacs-23: emacs23 fails to rmail-ify my rmail box due to some problem with a tempfile
Package: emacs23 Version: 23.1+1-2 Severity: normal File: emacs-23 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages emacs23 depends on: ii emacs23-bin-common 23.1+1-2 The GNU Emacs editor's shared, arc ii install-info 4.13a.dfsg.1-4Manage installed documentation in ii libasound2 1.0.20-3 shared library for ALSA applicatio ii libc6 2.9-23GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libdbus-1-31.2.16-2 simple interprocess messaging syst ii libfontconfig1 2.6.0-4 generic font configuration library ii libfreetype6 2.3.9-5 FreeType 2 font engine, shared lib ii libgif44.1.6-6 library for GIF images (library) ii libglib2.0-0 2.20.4-1 The GLib library of C routines ii libgpm21.20.4-3.2General Purpose Mouse - shared lib ii libgtk2.0-02.16.5-1 The GTK+ graphical user interface ii libice62:1.0.5-1 X11 Inter-Client Exchange library ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libm17n-0 1.5.4-1+b1a multilingual text processing lib ii libncurses55.7+20090803-1+b1 shared libraries for terminal hand ii libotf00.9.9-1 A Library for handling OpenType Fo ii libpng12-0 1.2.38-1 PNG library - runtime ii librsvg2-2 2.26.0-1 SAX-based renderer library for SVG ii libsm6 2:1.1.0-2 X11 Session Management library ii libtiff4 3.8.2-13+b1 Tag Image File Format (TIFF) libra ii libx11-6 2:1.2.2-1 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxft22.1.13-3 FreeType-based font drawing librar ii libxmu62:1.0.4-2 X11 miscellaneous utility library ii libxpm41:3.5.7-2 X11 pixmap library ii libxrender11:0.9.4-2 X Rendering Extension client libra ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii xaw3dg 1.5+E-17 Xaw3d widget set ii zlib1g 1:1.2.3.3.dfsg-15 compression library - runtime emacs23 recommends no packages. Versions of packages emacs23 suggests: ii emacs23-common-non-dfsg 23.1+1-1 GNU Emacs shared, architecture ind -- 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#543687: reportbug: Changing editor interactively (to vi) got me a vi session, but didn't edit the report.
Package: reportbug Version: 4.6 Severity: normal I have export EDITOR=emacsclient set in my environment. Today I installed emacs23 and immediately hit a bug (can't use rmail), so fired up reportbug. When it came time for me to edit the bug e-mail, I just got error messages in reportbug's virtual console; emacsclient wasn't answering :-( So I opted (I think the command letter was c) to change editor command; I used vi, which was duly started up, but on an empty buffer, instead of on the familiar buffer I expected to see, with package details in it. I described the problem, saved the result and exited; reportbug said I hadn't edited the report, so I tried again; I saw the same file I'd been editing previously. I told reportbug to show me the message it was going to send - it displayed something whose last few lines (my console is inside screen and doesn't respond usefully to anything that I expect to cause scroll-back; nor did reportbug think to pipe the file through a pager) looked like the normal package description that I *expected* to be editing, but hadn't seen. So I duly submitted the bug, over-riding reportbug's desire to abort because I wasn't changing text. Sure enough, when I got the auto-responder mail, I found the familiar package description information with no sign of the text I'd edited. I've now exited emacs23 and started up emacs22, so that I can run reportbug on itself - and sure enough, it invoked emacsclient; but I found myself with a buffer called -dir in the working directory in which I ran reportbug; and that directory turns out to contain a file called -c containing what I edited using vi. A quick grep of the ouptut from ps revealed emacsclient +6 /tmp/reportbug-reportbug-20090826-847-7U03sn so I opened the file that named - only to discover emacs already had a buffer open on it, that I merely hadn't yet seen (another bug for me to report on emacs). So now I'm editing that - who knows, it might even work. This may be a bug in emacsclient; but the fact that vi had similar problems suggests there *is* a bug in reportbug, whether that's provoking the emacsclient problem or merely independent and confusing. ... h ! I have some other suspicious-looking buffers open: -file0 Fundamental /tmp/-file -position0 Fundamental /tmp/-position screen.rxvt 0 Fundamental /tmp/screen.rxvt % 40 Fundamental /dev/pts/4 % -tty 0 Fundamental /dev/pts/-tty % -current-frame 0 Fundamental /dev/pts/-current-frame Again, this is probably emacsclient's fault, but may be material to investigating the reportbug issue ... -- Package-specific info: ** Environment settings: EDITOR=emacsclient VISUAL=emacsclient NAME=Edward Welbourne INTERFACE=text ** /disk/home/eddy/.reportbugrc: reportbug_version 3.44 mode standard ui text -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages reportbug depends on: ii apt 0.7.22.2 Advanced front-end for dpkg ii python2.5.4-2An interactive high-level object-o ii python-reportbug 4.6Python modules for interacting wit reportbug recommends no packages. Versions of packages reportbug suggests: pn debconf-utils none (no description available) ii debsums 2.0.46 verification of installed package ii dlocate 1.02 fast alternative to dpkg -L and dp ii exim4-daemon-light [mail-tran 4.69-11lightweight Exim MTA (v4) daemon ii file 5.03-1 Determines file type using magic ii gnupg 1.4.9-4GNU privacy guard - a free PGP rep pn python-gnome2-extras none (no description available) ii python-gtk2 2.14.1-3 Python bindings for the GTK+ widge pn python-urwid none (no description available) ii python-vte1:0.20.5-1 Python bindings for the VTE widget ii xdg-utils 1.0.2-6.1 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#543676: emacs-23: emacs23 fails to rmail-ify my rmail box due to some problem with a tempfile
Apologies for the empty report text; somewhere between reportbug, emacsclient and vi, I wasn't given the opportunity to edit the report before sending it ! My EDITOR=emacsclient didn't work, for reasons unknown (and, apparently, specific to emacs23) so I told reportbug to use vi; but (I now know) it somehow managed to invoke vi in a way that left me editing a file called -c (in reportbug's working directory), that didn't contain the package description; and, when saved, hadn't changed the file reportbug was expecting me to edit; so I was obliged to over-ride reportbug's unwillingness to submit the bug without an edited body. When I came to report the bug in reportbug, it threw me into emacsclient (now working, as I've exited emacs23 and fallen back on emacs22), but I found myself editing a buffer called -dir, on a file in the working directory of reportbug - and, alongside it, was a file named -c that contained the text I'd prepared, using vi, for this bug: here's what it said quote *sigh* Additionally, I must sadly add that emacsclient doesn't seem to be working. I *would* be editing this using emacsclient otherwise, but I'm forced to use vi, because that at least *works* (damnit). I restarted emacsclient in my running emacs23, to no avail. Anyway, the error message I get when I try to load my mailbox says: Wrote /disk/home/eddy/.sys/tmp/rmail738ElS Writing messages to /disk/home/eddy/.sys/tmp/rmail738mIt... byte-code: Removing old name: no such file or directory, /disk/home/eddy/.sys/tmp/rmail738mIt and I'm left with the babyl file loaded but not processed in rmail mode. Trying to M-x rmail-mode in it, I get Wrote /disk/home/eddy/.sys/tmp/rmail738M7U Writing messages to /disk/home/eddy/.sys/tmp/rmail738ZFb... byte-code: Removing old name: no such file or directory, /disk/home/eddy/.sys/tmp/rmail738ZFb so it seems the problem is really rmail-mode. This (taken together with the failure of emacsclient) is fatal for my use of emacs23; I'll go back to emacs22 in the mean time. /quote (I note that there is ample space on /tmp/: quote src=df /tmp Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 9614116 6778496 2347248 75% / /quote so the problem wasn't that it'd run out of diskspace.) aside subject=emacsclient issues So I ran ps | grep to find out how emacsclient had been invoked: emacsclient +6 /tmp/reportbug-reportbug-20090826-847-7U03sn Perfectly sensible. So I opened that file, only to find I already had an open buffer on it (that simply hadn't been visible, presumably because -dir was opened in the same window later). I also turned out to have an open buffer in dired-mode on the working directory of the reportbug process; and C-x C-b also found the following: -file0 Fundamental /tmp/-file -position0 Fundamental /tmp/-position screen.rxvt 0 Fundamental /tmp/screen.rxvt % 40 Fundamental /dev/pts/4 % -tty 0 Fundamental /dev/pts/-tty % -current-frame 0 Fundamental /dev/pts/-current-frame I was, at least, able to edit the right file to cause that bug-report to be submitted correctly; although I had to C-x # every one of the buffers mentioned, before emacsclient returned to reportbug. This is probably a mis-interaction between emacs23's emacsclient (which the alternatives system has selected for me) and emacs22 - which I'm now running, since emacs 23 doesn't work with rmail; I can't function without that ! It works *better* with emacs22 than with emacs23, but is still behaving strangely ... however, the evidence from emacs22 looks like it should give you some information on what emacsclient was trying to do, that failed to work with emacs23. /aside Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543676: emacs-23: emacs23 fails to rmail-ify my rmail box due to some problem with a tempfile
Alas, my crystal ball is at the repair shop. Would you please give some information about your problem? Yeah - sorry about that; as explained in follow-up, I was having trouble between reportbug, EDITOR=emacsclient and vi as emergency over-ride, Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543687: reportbug: Changing editor interactively (to vi) got me a vi session, but didn't edit the report.
The explanation for emacsclient's mis-behaviour when reporting *this* bug turns out to be fairly easy: emacs23 has installed its emacsclient and told the alternatives system to use that by default, so I was using emacs23's emacsclient with emacs22. The misbehaviour when I told reportbug to use vi, however, remains ... Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530535: apache2: Apache fails to follow symlinks via other symlinks
It occurred to me that the problem might be related to one of the symlinks having a name, .w/, to which Apache normally wouldn't allow access, so I tested with: ln -s ../work w; ln -s w/mine/toys toys but /~eddy/toys/ was also 403. However, /~eddy/code/ has become inaccessible too ! Yet, half an hour ago, I was able to access one of my local URLs that does indeed go via symlinks - and it's also stopped working now. Something is horribly confused here ... Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530535: apache2: Apache fails to follow symlinks via other symlinks
Package: apache2.2-common Version: 2.2.11-3 Severity: normal In my userdir, I did (some time ago, inter alia): kbd ln -s ../work .w ln -s .w/mine/toys code /kbd and I used to be able to visit /~eddy/code/ to see the code fragments therein. I have today run into this not working: I got 403 instead. However, kbd mv code edoc ln -s ../work/mine/toys code /kbd made the content visible again, although /~eddy/edoc/ stil 403s, so the problem seems to be only that Apache has lost the ability to keep following symlinks until it gets to a real path. For reference, quote src=sh $ ls -lAd code edoc .w lrwxrwxrwx 1 eddy eddy 17 2009-05-25 15:16 code - ../work/mine/toys lrwxrwxrwx 1 eddy eddy 12 2009-05-25 15:29 edoc - .w/mine/toys lrwxrwxrwx 1 eddy eddy 7 2006-08-31 19:59 .w - ../work $ for l in code edoc .w; do readlink -f $l; done /disk/home/eddy/work/mine/toys /disk/home/eddy/work/mine/toys /disk/home/eddy/work /quote Naturally, your Options shall have to allow FollowSymLinks or SymLinksIfOwnerMatch to reproduce the half of this where it works. Given that I've used significantly more complex games with symlinks via symlinks, this breaks an internal web-site on which various of my colleagues have come to rely ... I'm going to have to make all my symlinks direct-to-destination, which'll force me to re-do many of them every time I move certain fragments around :-( Such moves used to only require changing one symlink (through which all the others pointed); e.g., if I move ~/work/ to another disk, all symlinks from my userdir to under it shall break, even though I'd naturally replace it with a symlink to where it's gone, which seems to be good enough for all other applications I've tested with. -- Package-specific info: List of enabled modules from 'apache2 -M': actions alias auth_basic authn_file authnz_ldap authz_default authz_host authz_user autoindex cgi dir env ldap mime negotiation perl setenvif ssl status userdir -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages apache2 depends on: ii apache2-mpm-prefork 2.2.11-3 Apache HTTP Server - traditional n apache2 recommends no packages. apache2 suggests no packages. Versions of packages apache2.2-common depends on: ii apache2-utils 2.2.11-3 utility programs for webservers ii libapr11.3.3-3 The Apache Portable Runtime Librar ii libaprutil11.3.4+dfsg-1 The Apache Portable Runtime Utilit ii libc6 2.9-4 GNU C Library: Shared libraries ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries ii libmagic1 5.03-1File type determination library us ii libssl0.9.80.9.8g-16 SSL shared libraries ii libuuid1 1.41.3-1 universally unique id library ii lsb-base 3.2-22Linux Standard Base 3.2 init scrip ii mime-support 3.44-1MIME files 'mime.types' 'mailcap ii net-tools 1.60-23 The NET-3 networking toolkit ii perl 5.10.0-22 Larry Wall's Practical Extraction ii procps 1:3.2.7-11/proc file system utilities ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime -- 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#530535: apache2: Apache fails to follow symlinks via other symlinks
I forgot to mention: the error.log reports the error as quote Symbolic link not allowed or link target not accessible: /disk/home/eddy/whorlweb/edoc /quote Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519382: python-ropemacs: Also can't uninstall or purge :-(
Package: python-ropemacs Version: 0.6c2-3 Severity: normal When I tried to purge the package, I got quote Reading package fields... Done Reading package status... Done Retrieving bug reports... Done Parsing Found/Fixed information... Done Extracting templates from packages: 100% Preconfiguring packages ... dpkg: error processing python-ropemacs (--purge): Package is in a very bad inconsistent state - you should reinstall it before attempting a removal. Errors were encountered while processing: python-ropemacs E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Press return to continue. /quote and similar for uninstall (with --remove in place of --purge). For now, you can just manually add the following line to the python-ropemacs section of /var/lib/dpkg/status: Python-Version: =2.5 Made no ifference to an attempt to purge but - thankfully - did make it possible to install, so my problem is solved, at least - thank you. I wonder though if this isn't a bug in python-central. It does sound that way: if a package contains a mistake (missing Python-Version line), python-central turns it into a problem that completely blocks aptitude from doing anything useful (specifically including backing out of the mistake) until - and I trust this is anathema to everyone - someone intervenes manually to edit an internal config file of dpkg ... -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages python-ropemacs depends on: ii pymacs0.23-1.1 interface between Emacs Lisp and P ii python-rope 0.9.2-1Python refactoring library python-ropemacs recommends no packages. python-ropemacs 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#231808: With no server set-up, installing nis is guaranteed to fail its init.d restart
Since ypbind is able to discover servers automatically What needs to be set up to make that work ? Getting that configured (presumably on the local network) would indeed make this a non-problem, at least for me. Describing these details in the package's README.Debian might help, too ... I'm unable to get a clue from man ypbind, and /usr/share/doc/nis/nis.debian.howto.gz only tells me how to set up each host, not what network (DHCP?) config will ensure that ypbind can discover the right server without me having to hand-edit yp.conf and restart nis after it's failed to start on install; or is this just some detail of the NIS server config, e.g. making it listen for broadcast ? Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#231808: With no server set-up, installing nis is guaranteed to fail its init.d restart
I'll have a look when I'm not at work. OK, thanks - I'll, meanwhile, ask our sysadmins to have a look while they *are* ;-) Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#231808: With no server set-up, installing nis is guaranteed to fail its init.d restart
It should Just Work with no setup required if the server is on the same subnet ... is this just some detail of the NIS server config, e.g. making it listen for broadcast ? The server not listening for broadcast is the most likely explanation. and, sure enough, our sysasmins found that the broadcast was getting caught between the teeth of the firewall. They've now tamed the firewall and the default (functionally empty) yp.conf works fine :-) Eddy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#231808: With no server set-up, installing nis is guaranteed to fail its init.d restart
Package: nis Version: 3.17-18 Severity: normal As it stands, on a first install of nis, postinst is running /etc/init.d/nis start (or invoke-rc.d nis start) before there is anything at all useful in /etc/yp.conf; this leaves me waiting for a pointless attempt to bind when no server is set. Even if I edit the yp.conf, it's too late to help, by the time I see that slowly failing binding ... message that reminds me that I need to hold this package's hand because it doesn't think to ask me for information it absolutely must have before its init.d/ script can succeed. One fix for this would be for the script (either postinst or init.d/) to notice if the yp.conf is unconfigured and not attempt to start the service in that case, e.g. producing a message about the need to put something sensible in yp.conf, like (for postinst): if sed -e 's/#.*//' /etc/yp.conf 2/dev/null | grep . /dev/null then /etc/init.d/nis start else echo Please configure /etc/yp.conf and run /etc/init.d/nis start 2 fi However, the package installs /etc/yp.conf if there wasn't one there previously: when it's installing it, and there was nothing there before, asking the user for their nis server's IP address (and remarking that the numeric address really is needed, but that cmd host nis /cmd might get useful results) would enable the package to install an actually *useful* yp.conf in the first instance, *in time* for its init.d/ script to usefully start NIS services. Any time after the first install, leaving yp.conf alone is of course perfectly sensible, although a really clever (i.e. harder to maintain) system would read it, work out whether it's set ypserver, check that this is actually reachable; if unset or unreachable, ask for a server setting and modify yp.conf - but, as you say, that's a lot of extra effort; and it's almost never needed *after the first time* ... -- Package-specific info: nm-tool is not installed -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages nis depends on: ii debconf [debconf-2.0] 1.5.26 Debian configuration management sy ii libc6 2.9-4 GNU C Library: Shared libraries ii libdbus-1-3 1.2.12-1 simple interprocess messaging syst ii libdbus-glib-1-2 0.80-3 simple interprocess messaging syst ii libgdbm3 1.8.3-4GNU dbm database routines (runtime ii libglib2.0-0 2.20.0-2 The GLib library of C routines ii libslp1 1.2.1-7.5 OpenSLP libraries ii lsb-base 3.2-22 Linux Standard Base 3.2 init scrip ii make 3.81-5 The GNU version of the make util ii netbase 4.34 Basic TCP/IP networking system ii portmap 6.0-9 RPC port mapper nis recommends no packages. nis suggests no packages. -- debconf information: * nis/not-yet-configured: * nis/domain: opera -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#317928: Makes aptitude hard to use when accessing via ssh from console
Package: aptitude Version: 0.4.11.11-1 Severity: normal I routinely admin a satellite box to my workstation using ssh to the box and screen on the box; this combination gets really messed up graphics from aptitude (and from the config tool some packages fire up during installation to ask questions). For example, I see a lot of repeats of the three-character sequence [a-circumflex][C-cedilla][superscript-3] or some lines begin with the two-character sequence [E-acute][A-ring] messing up the display; importantly, this kind of thing causes the cursor to not be in the same place as the text it thinks it's on, and that gets changed if I type; also, updates over-write a part of the screen which isn't where the change is actually happening. Furthermore, the display tends to be off-by-(one or two) in lines from the top of the screen. I've learned to work round it, but it's definitely a nuisance - and a bug ! When going via both ssh and screen, I have TERM=screen.linux; but, upon experimenting, I find that only ssh is actually implicated; if I exit screen, but don't log out, aptitude still shows the messed up lines. In this case, I have TERM=linux, which is indeed the value of TERM before I ssh to the satellite. When I unplug my screen and keyboard from my main workstation and plug them directly into the satellite (exactly the upheaval I'm trying to avoid by using ssh), aptitude displays just fine, as on my local console. I'm also able to run aptitude via screen, locally. If I log in via ssh from an rxvt, aptitude shows relatively minor artifacts ([a-circumflex] at the ends of lines where I think ncurses was probably being asked to draw a scroll-bar (both on a warning dialog about a missing certificate and in the information area, describing the currently selected line of the package list, which shows no such artifacts). This is despite the rxvt running screen locally (from which I ran ssh); I have TERM=screen.rxvt in this case. Hmm ... but from a raw rxvt (no screen), ssh to the box (no screen) has coverity showing the [a-circumflex] as above but also showing pairs of dotted rectangles (outlining character cells) in assorted places within the description area. -- Package-specific info: aptitude 0.4.11.11 compiled at Nov 20 2008 04:02:44 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.20090404 cwidget version: 0.5.12 Apt version: 4.6.0 linux-gate.so.1 = (0xb7f0c000) libapt-pkg-libc6.7-6.so.4.6 = /usr/lib/libapt-pkg-libc6.7-6.so.4.6 (0xb7e3a000) libncursesw.so.5 = /lib/libncursesw.so.5 (0xb7dfc000) libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0xb7df5000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0xb7d31000) libept.so.0 = /usr/lib/libept.so.0 (0xb7c6d000) libxapian.so.15 = /usr/lib/libxapian.so.15 (0xb7b15000) libz.so.1 = /usr/lib/libz.so.1 (0xb7b0) libpthread.so.0 = /lib/i686/cmov/libpthread.so.0 (0xb7ae7000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb79f8000) libm.so.6 = /lib/i686/cmov/libm.so.6 (0xb79d2000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb79c5000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0xb7864000) libutil.so.1 = /lib/i686/cmov/libutil.so.1 (0xb786) libdl.so.2 = /lib/i686/cmov/libdl.so.2 (0xb785b000) /lib/ld-linux.so.2 (0xb7f0d000) Terminal: screen.rxvt $DISPLAY is set. `which aptitude`: /usr/bin/aptitude aptitude version information: aptitude linkage: -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6. 0.7.20.2 Advanced front-end for dpkg ii libc6 2.9-4 GNU C Library: Shared libraries ii libcwidget30.5.12-4 high-level terminal interface libr ii libept00.5.26High-level library for managing De ii libgcc11:4.3.3-3 GCC support library ii libncursesw5 5.7+20090404-1shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.18-2 type-safe Signal Framework for C++ ii libstdc++6 4.3.3-3 The GNU Standard C++ Library v3 ii libxapian151.0.10-2 Search engine library ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-do 0.4.11.11-1 English manual for aptitude, a ter ii libparse-debianchangelog-per 1.1.1-2 parse Debian changelogs and output Versions of packages aptitude suggests: ii debtags
Bug#524854: python-lunar fails to install in squeeze; update-python-modules fails
Package: python-lunar Version: 2.0.1-1 Severity: grave Justification: renders package unusable When aptitude tried to install python-lunar, it said: quote Errors were encountered while processing: python-lunar E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up python-lunar (2.0.1-1) ... Usage: update-python-modules [-v] [-c] package_directory [...] update-python-modules [-v] [-c] package.dirs [...] update-python-modules [-v] [-al-fl-p] update-python-modules: error: /usr/share/python-support/python-lunar.public is not a directory dpkg: error processing python-lunar (--configure): subprocess post-installation script returned error exit status 2 Errors were encountered while processing: python-lunar Press return to continue. /quote (give or take any typos when I transcribed it from the console). A freshly-started python session is subsequently unable to import lunar, so the package is unusable. The update-python-modules script is provided by: ii python-support 0.8.7 automated rebuilding support for Python modules -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages python-lunar depends on: ii libatk1.0-01.24.0-2 The ATK accessibility toolkit ii libc6 2.9-4 GNU C Library: Shared libraries ii libcairo2 1.8.6-2+b1The Cairo 2D vector graphics libra ii libfontconfig1 2.6.0-3 generic font configuration library ii libfreetype6 2.3.9-4 FreeType 2 font engine, shared lib ii libglib2.0-0 2.20.0-2 The GLib library of C routines ii libgtk2.0-02.14.7-5 The GTK+ graphical user interface ii libgtksourceview2.0-0 2.4.2-1 shared libraries for the GTK+ synt ii liblunar-1-0 2.0.1-1 Chinese Lunar library ii libpango1.0-0 1.24.0-3+b1 Layout and rendering of internatio ii python2.5 2.5.4-1 An interactive high-level object-o ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime python-lunar recommends no packages. python-lunar 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#514983: sun-java6-plugin: browser dependency list incomplete: should recommend a virtual package
Followup-For: Bug #514983 Package: sun-java6-plugin Version: 6-12-1 (Reporting via another machine, so sending the file reportbug created; not sure whether its headers belong in mail's headers or body, sorry for the duplication.) sun-java6-plugin states that it Depends: on a long list of browsers. While one needs a browser to do anything useful with it, it is entirely possible to use it without any of the browsers in that list - if only because that list shall always be incomplete; but one could also write a stand-alone local applet-player - so it would be better to merely Recommend. In any case, it would be better to replace the list of browsers with a suitable virtual package. I'm guessing that'd ideally be more specific than just www-browser (some of which might lack NSAPI support, which I'm guessing is why you didn't just go with www-browser anyway) but, as long as it's a Recommend, specifying www-browser should suffice (and most browsers do in practice have NSAPI support anyway). Plenty of things that actually need an x-www-browser make do with www-browser as it is, so things useless without www-nsapi-browser can probably survive likewise. Of course, you should chose one browser to specify first, Recommends: ice-weasel | www-browser so that apt tools know which one to use to satisfy the dependency if it's not met some other way; but save yourself the perpetual stream of bug reports about yet another browser not appearing in the list - use www-browser ! -- System Information: Debian Release: 5.0 APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages sun-java6-plugin depends on: ii iceweasel 3.0.6-1lightweight web browser based on M ii libasound21.0.16-2 ALSA library ii libx11-6 2:1.1.5-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxi62:1.1.4-1 X11 Input extension library ii libxt61:1.0.5-3 X11 toolkit intrinsics library ii libxtst6 2:1.0.3-1 X11 Testing -- Resource extension ii sun-java6-bin 6-12-1 Sun Java(TM) Runtime Environment ( sun-java6-plugin recommends no packages. sun-java6-plugin 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#506331: g++-4.3: Misleading warning claims to ignore spurious qualifiers on return type
Package: g++-4.3
Version: 4.3.2-1
Severity: minor
Put the following ridiculous code in a .cpp file: text
struct Base { virtual const int stupid() = 0; };
struct Derived : public Base { virtual int stupid() { return 1; } };
/text and run the compiler on it, with warnings. I get: quote
$ g++ -O2 -Wall -Wextra -o spurious.o -c spurious.cpp
spurious.cpp:1: warning: type qualifiers ignored on function return type
spurious.cpp:2: error: conflicting return type specified for 'virtual int
Derived::stupid()'
spurious.cpp:1: error: overriding 'virtual const int Base::stupid()'
make: *** [spurious.o] Error 1
/quote
Observe that the warning claims to ignore the spurious const.
However, the error reveals that it was not ignored.
Had it been ignored, the over-ride's return would have matched.
The warning should say
warning: spurious type qualifiers on function return type
or something similar: it should not claim to ignore the type qualifier.
The obvious fix is, of course, to fix the base class: however, if that
is in a library not under my control, this isn't a practical option
when I come to sub-class it. I am consequently obliged to duplicate
the spurious type qualifier and, hence, get even more warnings about
it :-(
Priority is negligible, of course.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages g++-4.3 depends on:
ii gcc-4.3 4.3.2-1The GNU C compiler
ii gcc-4.3-base 4.3.2-1The GNU Compiler Collection (base
ii libc6 2.7-16 GNU C Library: Shared libraries
ii libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library
ii libmpfr1ldbl 2.3.1.dfsg.1-2 multiple precision floating-point
ii libstdc++6-4.3-dev4.3.2-1The GNU Standard C++ Library v3 (d
g++-4.3 recommends no packages.
Versions of packages g++-4.3 suggests:
pn g++-4.3-multilib none (no description available)
ii gcc-4.3-doc 4.3.2.nf1-1 documentation for the GNU compiler
pn libstdc++6-4.3-dbg none (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496025: linux-image-2.6.18-6-k7: New kernels always ruminate about removing the same dangling symlink
Package: linux-image-2.6.18-6-k7 Version: 2.6.18.dfsg.1-22etch2 Severity: minor Every time a new kernel installs, I get a warning message about a dangling symbolic link that it decides to remove. This is produced by the linux-image-*.postinst function fix_build_link when it finds a dangling link - which it always does. Either this warning is irrelevant, in which case the user should not be troubled with it, or it means something, in which case the package building process should be fixed so that you stop shipping packages that contain this dangling symlink. (Forwarded via a different host, since the machine which is old and slow enough to let me read the message has no mail connectivity. It's also running an older kernel, since it fails to find network with the newer kernel - whereas the older kernel's failure to find the mouse is easilly fixed by modprobe psmouse !) -- System Information: Debian Release: 4.0 APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-3-k7 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages linux-image-2.6.18-6-k7 depends on: ii coreutils5.97-5.3The GNU core utilities ii debconf [debconf-2.0]1.5.11etch2 Debian configuration management sy ii initramfs-tools [linux-initr 0.85i tools for generating an initramfs ii module-init-tools3.3-pre4-2 tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.12-18 Yet Another mkInitRD Versions of packages linux-image-2.6.18-6-k7 recommends: ii libc6-i686 2.3.6.ds1-13etch7 GNU C Library: Shared libraries [i -- debconf information: linux-image-2.6.18-6-k7/preinst/initrd-2.6.18-6-k7: linux-image-2.6.18-6-k7/prerm/removing-running-kernel-2.6.18-6-k7: true linux-image-2.6.18-6-k7/postinst/kimage-is-a-directory: linux-image-2.6.18-6-k7/postinst/depmod-error-2.6.18-6-k7: false linux-image-2.6.18-6-k7/preinst/abort-overwrite-2.6.18-6-k7: linux-image-2.6.18-6-k7/preinst/failed-to-move-modules-2.6.18-6-k7: linux-image-2.6.18-6-k7/preinst/lilo-initrd-2.6.18-6-k7: true linux-image-2.6.18-6-k7/postinst/depmod-error-initrd-2.6.18-6-k7: false linux-image-2.6.18-6-k7/postinst/old-system-map-link-2.6.18-6-k7: true linux-image-2.6.18-6-k7/preinst/abort-install-2.6.18-6-k7: shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-6-k7/postinst/create-kimage-link-2.6.18-6-k7: true linux-image-2.6.18-6-k7/postinst/old-dir-initrd-link-2.6.18-6-k7: true linux-image-2.6.18-6-k7/postinst/bootloader-test-error-2.6.18-6-k7: linux-image-2.6.18-6-k7/preinst/lilo-has-ramdisk: linux-image-2.6.18-6-k7/preinst/already-running-this-2.6.18-6-k7: linux-image-2.6.18-6-k7/preinst/elilo-initrd-2.6.18-6-k7: true linux-image-2.6.18-6-k7/prerm/would-invalidate-boot-loader-2.6.18-6-k7: true linux-image-2.6.18-6-k7/preinst/bootloader-initrd-2.6.18-6-k7: true linux-image-2.6.18-6-k7/preinst/overwriting-modules-2.6.18-6-k7: true linux-image-2.6.18-6-k7/postinst/bootloader-error-2.6.18-6-k7: linux-image-2.6.18-6-k7/postinst/old-initrd-link-2.6.18-6-k7: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495047: xscreensaver: Crying wolf undermines the value of the failed login attempt warning
Package: xscreensaver Version: 5.05-3 Followup-For: Bug #495047 This warning should only be produced when someone has actually attempted to log in - that is, hit return while the password field is displayed and selected, optionally after having modified the input fields. Merely prompting the login dialog to be displayed (whether by hitting return, when a screensaver is playing, or by bumping the table, hence causing the mouse to move) should not count as a login attempt. If the application always produces a warning, and the user gets used to ignoring the warning because it doesn't *really* mean someone tried to log in - it just means the cleaner bumped the table while sweeping the floor while I was out over-night - then the user shall *always* ignore the warning, including the times that the black hat has taken a job as a cleaner so as to try to log in to all the machines during the hours when salaried staff aren't on the premises. Once that happens, the warning is worse than useless - it not only *isn't* warning the user about anything useful, despite wasting the user's time waiting for it to go away, but it's *also* training users to ignore warnings. Programs which train users to ignore warnings help phishers and black hats by depriving the users of anything they can meaningfully recognize as a sign of potential trouble. The current behaviour is a classic example of crying Wolf! See: http://www.cs.auckland.ac.nz/~pgut001/pubs/usability.pdf for related observations, or http://www.cs.auckland.ac.nz/~pgut001/ generally. I'm fairly sure xscreensaver used to do this right - this must be a fairly recent change. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages xscreensaver depends on: ii libatk1.0-01.22.0-1 The ATK accessibility toolkit ii libc6 2.7-13GNU C Library: Shared libraries ii libcairo2 1.6.4-6 The Cairo 2D vector graphics libra ii libglade2-01:2.6.2-1 library to load .glade files at ru ii libglib2.0-0 2.16.4-2 The GLib library of C routines ii libgtk2.0-02.12.11-3 The GTK+ graphical user interface ii libice62:1.0.4-1 X11 Inter-Client Exchange library ii libpam0g 1.0.1-2 Pluggable Authentication Modules l ii libpango1.0-0 1.20.5-1 Layout and rendering of internatio ii libsm6 2:1.0.3-2 X11 Session Management library ii libx11-6 2:1.1.4-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library ii libxml22.6.32.dfsg-2 GNOME XML library ii libxmu62:1.0.4-1 X11 miscellaneous utility library ii libxpm41:3.5.7-1 X11 pixmap library ii libxrandr2 2:1.2.3-1 X11 RandR extension library ii libxrender11:0.9.4-2 X Rendering Extension client libra ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii libxxf86misc1 1:1.0.1-3 X11 XFree86 miscellaneous extensio ii libxxf86vm11:1.0.2-1 X11 XFree86 video mode extension l ii xscreensaver-data 5.07-1~pre2 data files to be shared among scre Versions of packages xscreensaver recommends: ii libjpeg-progs 6b-14 Programs for manipulating JPEG fil ii miscfiles [wordlist] 1.4.2.dfsg.1-9Dictionaries and other interesting ii perl [perl5] 5.10.0-11.1 Larry Wall's Practical Extraction ii wbritish [wordlist]6-2.3 British English dictionary words f ii wbritish-huge [wordlis 6-2.3 British English dictionary words f ii wnorwegian [wordlist] 2.0.10-2 Norwegian word list ii xli1.17.0+20061110-2 command line tool for viewing imag ii xloadimage 4.1-16Graphics file viewer under X11 Versions of packages xscreensaver suggests: ii amaya [www-browser] 9.51-2.1 Web Browser, HTML Editor and Testb ii fortune-mod [fortune] 1:1.99.1-3.1 provides fortune cookies on demand ii iceweasel [www-browse 3.0.1-1lightweight web browser based on M ii opera [www-browser] 9.52.2091.gcc4.qt3 The Opera Web Browser pn qcam | streamer none (no description available) ii w3m [www-browser] 0.5.2-2+b1 WWW browsable pager with excellent ii xdaliclock2.25-1 Melting digital clock ii xfishtank 2.2-24.1 turns your X root into an aquarium
Bug#495557: Various packages claim to depend on emacs21 when they really depend on emacs
Package: emacs21 Severity: minor Well, reportbug asked me which package it related to and I tried saying it was general: quote Enter a package: 7 Are you sure this bug doesn't apply to a specific package? [y|N|q|?]? /quote but it *does* apply to a specific package, it's just that that package (emacs21) isn't the one with the bug ! Earlier today I decided to uninstall emacs21, but doing so broke: python-mode records-gnuemacs w3-el-e21 w3-url-e21 xslide While I can believe the w3-*-e21 packages might really depend on emacs21, I'm fairly sure the others don't; however, all of these packages *say* they depend on emacs21, not emacs - possibly because they depend on emacs 20. There may be others that likewise misdescribe themselves (I just don't have them installed). They should be fixed to reference emacs, optionally with a version check. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages emacs21 depends on: pn emacs21-bin-common none(no description available) ii libc6 2.7-13GNU C Library: Shared libraries ii libgif44.1.6-5 library for GIF images (library) ii libice62:1.0.4-1 X11 Inter-Client Exchange library ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libncurses55.6+20080713-1shared libraries for terminal hand ii libpng12-0 1.2.27-1 PNG library - runtime ii libsm6 2:1.0.3-2 X11 Session Management library ii libtiff4 3.8.2-10 Tag Image File Format (TIFF) libra ii libx11-6 2:1.1.4-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxmu62:1.0.4-1 X11 miscellaneous utility library ii libxpm41:3.5.7-1 X11 pixmap library ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii xaw3dg 1.5+E-17 Xaw3d widget set ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime emacs21 recommends no packages. Versions of packages emacs21 suggests: pn emacs21-common-non-dfsg none (no description available) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494267: xscreensaver forgot how to grok xrandr -o left
Well, for you maybe, but not for others I'm afraid. indeed - last thing before going home at the end of the day, I'm not at my brightest ! One way or another, the randr code is clearly getting it wrong. I'll see if I can help work out why. Can you send the output of the test-xinerama and test-randr programs from xscreensaver/driver/? quote src=display/test-randr test-randr: 10:03:45: XRRQueryExtension(dpy, ...) == 115, 186 test-randr: 10:03:45: XRRQueryVersion(dpy, ...) == 1, 2 test-randr: 10:03:45: Screen 0 test-randr: 10:03:45: Available Rotations: 0 90 180 270 test-randr: 10:03:45: Current Rotation:90 test-randr: 10:03:45: Available Reflections: X Y test-randr: 10:03:45: Current Reflections: none test-randr: 10:03:45: + size 0: 1600 x 1200rates: 60 test-randr: 10:03:45: size 1: 1680 x 1050rates: 60 test-randr: 10:03:45: size 2: 1600 x 1024rates: 60 test-randr: 10:03:45: size 3: 1400 x 1050rates: 75 70 60 test-randr: 10:03:45: size 4: 1280 x 1024rates: 85 75 60 test-randr: 10:03:45: size 5: 1440 x 900 rates: 60 test-randr: 10:03:45: size 6: 1280 x 960 rates: 85 60 test-randr: 10:03:45: size 7: 1280 x 800 rates: 60 test-randr: 10:03:45: size 8: 1152 x 864 rates: 85 75 test-randr: 10:03:45: size 9: 1280 x 768 rates: 60 test-randr: 10:03:45: size 10: 1152 x 768rates: 55 test-randr: 10:03:45: size 11: 1024 x 768rates: 85 75 70 60 test-randr: 10:03:45: size 12: 832 x 624 rates: 75 test-randr: 10:03:45: size 13: 800 x 600 rates: 85 72 75 60 56 test-randr: 10:03:45: size 14: 640 x 480 rates: 85 75 73 60 test-randr: 10:03:45: size 15: 720 x 400 rates: 85 70 test-randr: 10:03:45: size 16: 640 x 400 rates: 85 test-randr: 10:03:45: size 17: 640 x 350 rates: 85 test-randr: 10:03:45: Output 0: VGA: connected (73) test-randr: 10:03:45: + CRTC 0 (73): 1200x1600+0+0 test-randr: 10:03:45: CRTC 1 (74): 0x0+0+0 test-randr: awaiting events... /quote NB: I had to interrupt it; it was still waiting ! quote src=display/test-xinerama test-xinerama: 10:06:12: XineramaQueryExtension(dpy, ...) == 0, 0 test-xinerama: 10:06:12: XineramaIsActive(dpy) == True test-xinerama: 10:06:12: XineramaQueryVersion(dpy, ...) == 1, 1 test-xinerama: 10:06:12: 1 Xinerama screens test-xinerama: 10:06:12: screen 0: 1200x1600+0+0 /quote So: xrandr knows we're rotated and even thinks it knows the correct size of the screen, it would seem. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494267: xscreensaver forgot how to grok xrandr -o left
When I previously 0'd out the rotate code,
else if (0 rot (RR_Rotate_90|RR_Rotate_270))
I failed to notice a matching piece of code in the HAVE_RANDR_12
stanza further down; a few judicious fputs revealed to me that the
latter is the one being executed. When I 0 *it* out,
if (0 crtci-rotation (RR_Rotate_90|RR_Rotate_270))
the randr_versus_xinerama_fight message goes away and xscreensaver
behaves correctly.
patch
diff -bu /usr/opt/xscreensaver-5.07/driver/screens.c.orig
/usr/opt/xscreensaver-5.07/driver/screens.c
--- /usr/opt/xscreensaver-5.07/driver/screens.c.orig2008-08-08
23:06:03.0 +0200
+++ /usr/opt/xscreensaver-5.07/driver/screens.c 2008-08-14 10:21:51.0
+0200
@@ -417,7 +417,7 @@
m-x= crtci-x;
m-y= crtci-y;
- if (crtci-rotation (RR_Rotate_90|RR_Rotate_270))
+ if (0 crtci-rotation (RR_Rotate_90|RR_Rotate_270))
{
m-width = crtci-height;
m-height = crtci-width;
Diff finished. Thu Aug 14 10:21:58 2008
/patch
quote src=driver/test-randr
test-randr: 10:22:35: XRRQueryExtension(dpy, ...) == 115, 186
test-randr: 10:22:35: XRRQueryVersion(dpy, ...) == 1, 2
test-randr: 10:22:35: Screen 0
test-randr: 10:22:35: Available Rotations: 0 90 180 270
test-randr: 10:22:35: Current Rotation:90
test-randr: 10:22:35: Available Reflections: X Y
test-randr: 10:22:35: Current Reflections: none
test-randr: 10:22:35: + size 0: 1600 x 1200rates: 60
test-randr: 10:22:35: size 1: 1680 x 1050rates: 60
test-randr: 10:22:35: size 2: 1600 x 1024rates: 60
test-randr: 10:22:35: size 3: 1400 x 1050rates: 75 70 60
test-randr: 10:22:35: size 4: 1280 x 1024rates: 85 75 60
test-randr: 10:22:35: size 5: 1440 x 900 rates: 60
test-randr: 10:22:35: size 6: 1280 x 960 rates: 85 60
test-randr: 10:22:35: size 7: 1280 x 800 rates: 60
test-randr: 10:22:35: size 8: 1152 x 864 rates: 85 75
test-randr: 10:22:35: size 9: 1280 x 768 rates: 60
test-randr: 10:22:35: size 10: 1152 x 768rates: 55
test-randr: 10:22:35: size 11: 1024 x 768rates: 85 75 70 60
test-randr: 10:22:35: size 12: 832 x 624 rates: 75
test-randr: 10:22:35: size 13: 800 x 600 rates: 85 72 75 60 56
test-randr: 10:22:35: size 14: 640 x 480 rates: 85 75 73 60
test-randr: 10:22:35: size 15: 720 x 400 rates: 85 70
test-randr: 10:22:35: size 16: 640 x 400 rates: 85
test-randr: 10:22:35: size 17: 640 x 350 rates: 85
test-randr: 10:22:35: Output 0: VGA: connected (73)
test-randr: 10:22:35: + CRTC 0 (73): 1200x1600+0+0
test-randr: 10:22:35: CRTC 1 (74): 0x0+0+0
test-randr: awaiting events...
/quote
quote src=driver/test-xinerama
test-xinerama: 10:23:13: XineramaQueryExtension(dpy, ...) == 0, 0
test-xinerama: 10:23:13: XineramaIsActive(dpy) == True
test-xinerama: 10:23:13: XineramaQueryVersion(dpy, ...) == 1, 1
test-xinerama: 10:23:13: 1 Xinerama screens
test-xinerama: 10:23:13: screen 0: 1200x1600+0+0
/quote
so randr *still* thinks it's got a 1200x1600 screen !
But now it does something right that it got wrong before !
Eddy.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494267: xscreensaver forgot how to grok xrandr -o left
Sorry, last mail's output from test-randr and test-xinerama was bogus; I'd forgotten to go into dieplay/ and re-make them. quote src=driver/test-randr test-randr: 10:28:56: XRRQueryExtension(dpy, ...) == 115, 186 test-randr: 10:28:56: XRRQueryVersion(dpy, ...) == 1, 2 test-randr: 10:28:56: Screen 0 test-randr: 10:28:56: Available Rotations: 0 90 180 270 test-randr: 10:28:56: Current Rotation:90 test-randr: 10:28:56: Available Reflections: X Y test-randr: 10:28:56: Current Reflections: none test-randr: 10:28:56: + size 0: 1600 x 1200rates: 60 test-randr: 10:28:56: size 1: 1680 x 1050rates: 60 test-randr: 10:28:56: size 2: 1600 x 1024rates: 60 test-randr: 10:28:56: size 3: 1400 x 1050rates: 75 70 60 test-randr: 10:28:56: size 4: 1280 x 1024rates: 85 75 60 test-randr: 10:28:56: size 5: 1440 x 900 rates: 60 test-randr: 10:28:56: size 6: 1280 x 960 rates: 85 60 test-randr: 10:28:56: size 7: 1280 x 800 rates: 60 test-randr: 10:28:56: size 8: 1152 x 864 rates: 85 75 test-randr: 10:28:56: size 9: 1280 x 768 rates: 60 test-randr: 10:28:56: size 10: 1152 x 768rates: 55 test-randr: 10:28:56: size 11: 1024 x 768rates: 85 75 70 60 test-randr: 10:28:56: size 12: 832 x 624 rates: 75 test-randr: 10:28:56: size 13: 800 x 600 rates: 85 72 75 60 56 test-randr: 10:28:56: size 14: 640 x 480 rates: 85 75 73 60 test-randr: 10:28:56: size 15: 720 x 400 rates: 85 70 test-randr: 10:28:56: size 16: 640 x 400 rates: 85 test-randr: 10:28:56: size 17: 640 x 350 rates: 85 test-randr: 10:28:56: Output 0: VGA: connected (73) test-randr: 10:28:56: + CRTC 0 (73): 1200x1600+0+0 test-randr: 10:28:56: CRTC 1 (74): 0x0+0+0 test-randr: awaiting events... /quote quote src=driver/test-xinerama test-xinerama: 10:29:53: XineramaQueryExtension(dpy, ...) == 0, 0 test-xinerama: 10:29:53: XineramaIsActive(dpy) == True test-xinerama: 10:29:53: XineramaQueryVersion(dpy, ...) == 1, 1 test-xinerama: 10:29:53: 1 Xinerama screens test-xinerama: 10:29:53: screen 0: 1200x1600+0+0 /quote Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494267: xscreensaver forgot how to grok xrandr -o left
Does that sound right? To the extent of my limited grasp of the matter, yes ;-) Thanks for making and maintaining xscreensaver, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494267: xscreensaver forgot how to grok xrandr -o left
I'm afraid that someone who actually has access to a system with RANDR and a rotatey monitor is gonna have to debug this and send me a patch... OK, that'd be me then, since I can definitely reproduce the bug. (If you try to debug this, please start with 5.07, not a multiply- patched 5.06, lest confusion continue.) pristine 5.07 tar-ball unpacked, RR_Rotate_* check suppressed. Running ./configure told me: quote Warning: GTK version 2.12.10 was found, but at least one supporting library (libxml-2.0) was not, so GTK can't be used. Perhaps some of the development packages are not installed? Warning: The GTK libraries do not seem to be available; the `xscreensaver-demo' program requires them. /quote and I can't see anything listing which development packages I need to install - any clues or hints would be welcome, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494267: xscreensaver forgot how to grok xrandr -o left
apt-get build-dep xscreensaver should help you.
after that
./configure; make
worked nicely, thank you.
I exited my existing xscreensaver and fired up the one built in
driver/; it promptly said:
xscreensaver: WARNING: RANDR and Xinerama report different
xscreensaver: screen layouts! Believing RANDR.
which looks *a lot* like a clue ;-)
It's still trying to use landscape mode. This is with the
else if (rot (RR_Rotate_90|RR_Rotate_270))
line in screens.c suppressed by prefixing 0 before rot. Re-enabling
and re-building, I get the same warning as above and the same
behaviour.
Something I've neglected to describe before: when I select Screen -
Locking - Lock Screen (XScreenSaver), the *whole* screen fades to
black, but as soon as it's all black it re-displays the bottom portion
of the screen and begins using the top square for xscreensaver
activity.
The error's coming from randr_versus_xinerama_fight(), so I've changed
the code to trust Xinerama instead of RANDR - and the problem's fixed :-)
Have a patch
diff -bu /usr/opt/xscreensaver-5.07/driver/screens.c.orig
/usr/opt/xscreensaver-5.07/driver/screens.c
--- /usr/opt/xscreensaver-5.07/driver/screens.c.orig2008-08-08
23:06:03.0 +0200
+++ /usr/opt/xscreensaver-5.07/driver/screens.c 2008-08-13 20:42:10.0
+0200
@@ -522,10 +522,12 @@
{
fprintf (stderr,
%s: WARNING: RANDR and Xinerama report different\n
- %s: screen layouts! Believing RANDR.\n,
+ %s: screen layouts! Believing Xinerama.\n,
blurb(), blurb());
- free_monitors (xinerama_monitors);
- return randr_monitors;
+ free_monitors (randr_monitors);
+ return xinerama_monitors;
+ /* free_monitors (xinerama_monitors);
+ return randr_monitors; */
}
}
Diff finished. Wed Aug 13 20:42:58 2008
/patch Obviously, I leave it to those with better knowledge of the
code to work out how to do it better ...
Eddy.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494267: xscreensaver forgot how to grok xrandr -o left
Please find a 5.07-1 prelease (i386 binaries) at http://alioth.debian.org/~tormod-guest/xscreensaver/ Thank you - I've fetched and installed all five packages. Restarted xscreensaver, opened config panel to confirm it's now 5.07: but my wrong-orientation variant of the bug is still there. I can't answer for the original two-screen version of the bug, though: I only have one screen. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494267: xscreensaver forgot how to grok xrandr -o left
Package: xscreensaver Version: 5.05-3 Followup-For: Bug #494267 A month or three ago I turned my flat Dell screen on its side, from landscape mode to portrait mode; the last two lines of my .xsession are now: xrandr -o left exec fvwm This initially worked very nicely. Notably, xscreensaver duly played its merry games in the full tall narrow screen and centred its login dialog correctly in the middle when disturbed. I recently got an xscreensaver update (I'm on testing); I don't know what my prior version was, but I now have 5.05-3; and it quite plainly thinks it's working on a screen with the height and width my screen has when in landscape orientation. Thus the locked part of the screen is a square on the short top side, the bottom portion of the screen is visible past the saver and the login dialog, when shown, is vertically centred in the locked square (not the whole screen) and quite distinctly off-centre to the right. These symptoms and the displayed animations quite plainly indicate that it's painting to a rectangle that's the right size but wrongly oriented. So I came to reportbug and its list of active bugs included this one, which sounds suspiciously related. Eddy. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages xscreensaver depends on: ii libatk1.0-01.22.0-1 The ATK accessibility toolkit ii libc6 2.7-10GNU C Library: Shared libraries ii libcairo2 1.6.4-6 The Cairo 2D vector graphics libra ii libglade2-01:2.6.2-1 library to load .glade files at ru ii libglib2.0-0 2.16.4-2 The GLib library of C routines ii libgtk2.0-02.12.10-2 The GTK+ graphical user interface ii libice62:1.0.4-1 X11 Inter-Client Exchange library ii libpam0g 0.99.7.1-7Pluggable Authentication Modules l ii libpango1.0-0 1.20.5-1 Layout and rendering of internatio ii libsm6 2:1.0.3-2 X11 Session Management library ii libx11-6 2:1.1.4-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library ii libxml22.6.32.dfsg-2 GNOME XML library ii libxmu62:1.0.4-1 X11 miscellaneous utility library ii libxpm41:3.5.7-1 X11 pixmap library ii libxrandr2 2:1.2.3-1 X11 RandR extension library ii libxrender11:0.9.4-2 X Rendering Extension client libra ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii libxxf86misc1 1:1.0.1-3 X11 XFree86 miscellaneous extensio ii libxxf86vm11:1.0.2-1 X11 XFree86 video mode extension l ii xscreensaver-data 5.05-3data files to be shared among scre Versions of packages xscreensaver recommends: ii libjpeg-progs 6b-14 Programs for manipulating JPEG fil ii miscfiles [wordlist] 1.4.2.dfsg.1-9Dictionaries and other interesting ii perl [perl5] 5.10.0-11.1 Larry Wall's Practical Extraction ii wbritish [wordlist]6-2.3 British English dictionary words f ii wbritish-huge [wordlis 6-2.3 British English dictionary words f ii wnorwegian [wordlist] 2.0.10-2 Norwegian word list ii xli1.17.0+20061110-2 command line tool for viewing imag Versions of packages xscreensaver suggests: ii amaya [www-br 9.51-2.1 Web Browser, HTML Editor and Testb ii fortune-mod [ 1:1.99.1-3.1 provides fortune cookies on demand ii opera [www-br 9.52.2084.gcc4.qt3 The Opera Web Browser pn qcam | stream none (no description available) ii w3-el-e21 [ww 4.0pre.2001.10.27.nodocs-5 Web browser for GNU Emacs 21 ii w3m [www-brow 0.5.2-2+b1 WWW browsable pager with excellent pn xdaliclocknone (no description available) pn xfishtank none (no description available) ii xscreensaver- 5.05-3 GL(Mesa) screen hacks for xscreens -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494267: xscreensaver forgot how to grok xrandr -o left
Please try 5.07. Marvelously terse and imperative ;-) I've looked at the change-logs and, indeed, find: quote src=http://www.jwz.org/xscreensaver/changelog.html; 5.0710-Aug-2008 Xinerama/RANDR tweaks for old-style multi-screen. ... 5.0616-Jul-2008 Xinerama/RANDR fixes: this time for sure. It should now work to add/remove monitors or resize screens at any time. /quote which does indeed look encouraging. Unfortunately, the download page only has ready-built binaries for Mac and is very unequivocal about how difficult it is to build from source. So I may give it a blast if I can find the time, but debian maintainers are probably more experienced at this than am I ;-) Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475534: x11-apps: oclock fails to show updated time, apparently because repainting hands in wrong colour
I've rotated my screen using xrandr -o left to use it in portrait mode and, to my pleasant surprise, the oclock now works as it always used to. There doesn't appear to have been an upgrade to x11-apps since I reported the bug, but it has been some weeks since I last rebooted or even restarted my X server, so it's possible something else changed in the mean time. Either that or xrandr did some magic that overcame whatever was breaking it; or the change in screen position (it sits in the top right of the screen, which now has a much lower x co-ordinate) was relevant. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484780: Documentation needs to mention bind and server's nisdomainname
I've thought this over a bit and I'm really not comfortbale with doing anything more than adding a generalised Please consult your network administrator statement. That would suffice. The present wording, the first time I met it, lead me to think the name I was supplying was something I could make up and would only be relevant to things I'd be doing locally; it didn't take me long to discover this was wrong, but I was left with no clue as to what to do to find out the right name ! Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476885: mercurial-common: The inotify import error breaks tailor's git-hg support
Package: mercurial-common
Version: 1.0.1-1
Followup-For: Bug #476885
The initially reported bug can be reduced to: quote
Python 2.5.2 (r252:60911, May 28 2008, 08:35:32)
[GCC 4.2.4 (Debian 4.2.4-1)] on linux2
Type help, copyright, credits or license for more information.
import hgext.inotify
Traceback (most recent call last):
File stdin, line 1, in module
File /var/lib/python-support/python2.5/hgext/inotify/__init__.py, line 16,
in module
import client, errno, os, server, socket
File /var/lib/python-support/python2.5/hgext/inotify/server.py, line 15, in
module
import hgext.inotify.linux as inotify
AttributeError: 'module' object has no attribute 'inotify'
/quote i.e. hgext's inotify sub-package fails to import, making it
unusable.
This has nothing to do with help per se, although it has the downside
of breaking help (and it's a pity other things do the same). I met it
because this error also shows up in tailor's broken handling of git -
hg repository transformation.
The problem is that __init__.py says to import server; but server says
to import linux from inotify (i.e. from __init__) whose import hasn't
yet completed, so hgext doesn't yet have a .inotify attribute on which
to look for a .linux attribute to import as inotify.
However, this can be avoided: the reason __init__.py imports client
and server (they'd appear in the package namespace naturally anyway,
so it's not so as to put them there) is so that serve and reposetup
can use them. Fortunately, there's a way round that ...
patch
diff -bu /usr/share/python-support/mercurial-common/hgext/inotify/__init__.py\~
/usr/share/python-support/mercurial-common/hgext/inotify/__init__.py
--- /usr/share/python-support/mercurial-common/hgext/inotify/__init__.py~
2008-05-22 22:48:40.0 +0200
+++ /usr/share/python-support/mercurial-common/hgext/inotify/__init__.py
2008-06-09 19:49:40.0 +0200
@@ -13,7 +13,7 @@
from mercurial.i18n import gettext as _
from mercurial import cmdutil, util
-import client, errno, os, server, socket
+import errno, os, socket
from weakref import proxy
def serve(ui, repo, **opts):
@@ -23,8 +23,10 @@
timeout = float(timeout) * 1e3
class service:
-def init(self):
+import server
+def init(self, server=server):
self.master = server.Master(ui, repo, timeout)
+del server
def run(self):
try:
@@ -47,8 +49,9 @@
# to recurse.
inotifyserver = False
+import client, server
def status(self, files, match, list_ignored, list_clean,
- list_unknown=True):
+ list_unknown=True, client=client, server=server):
try:
if not list_ignored and not self.inotifyserver:
result = client.query(ui, repo, files, match, False,
@@ -91,6 +94,8 @@
files, match or util.always, list_ignored, list_clean,
list_unknown)
+del client, server
+
repo.dirstate.__class__ = inotifydirstate
cmdtable = {
Diff finished. Mon Jun 9 19:50:09 2008
/patch
... since client and server are only actually needed when the
functions get called, which happens after the package has been loaded.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages mercurial-common depends on:
ii python2.5.2-1An interactive high-level object-o
ii python-support0.8.1 automated rebuilding support for P
Versions of packages mercurial-common recommends:
ii mercurial 1.0-4 Scalable distributed version contr
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484780: Documentation needs to mention bind and server's nisdomainname
Package: nis Version: 3.17-14 Severity: minor In nis.debian.howto.gz it says: quote 1. HOW TO SETUP A LOCAL NIS CLIENT 1.1 Install the netbase, portmap and nis packages 1.2 The installation procedure will ask for your NIS domainname. This is just a name which describes the group of systems that use NIS, it is not a hostname. ... /quote Saying just a name isn't very helpful. It's necessary to tell me how I can find out the right name to give ! It seems the name I have to give is in fact the response nisdomainname gives me on the machine I'll be using as server (1.3). 1.2 should say that. I followed the instructions (on a clean shiny new minimally configured virtual server our sysadmins had prepared for me), but /etc/init.d/nis restart failed and backgrounded. I decided to check I'd got the right host IP address, so fed it to the host command, but it wasn't installed. So I installed the bind9-host package. Now host confirmed I had the right address. Hunch suggested bind (which had just been pulled in) might actually be some help; so I tried another restart of nis and this time it worked. I conclude that nis needs bind (or something else pulled in by bind9-host); 1.1 should mention this (and ideally the nis package should actually Depend on it). -- Package-specific info: nm-tool is not installed -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages nis depends on: ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy ii libc6 2.7-10 GNU C Library: Shared libraries ii libdbus-1-3 1.2.1-2simple interprocess messaging syst ii libdbus-glib-1-2 0.74-4 simple interprocess messaging syst ii libgdbm3 1.8.3-3GNU dbm database routines (runtime ii libglib2.0-0 2.16.3-2 The GLib library of C routines ii libslp1 1.2.1-7.3 OpenSLP libraries ii lsb-base 3.2-11 Linux Standard Base 3.2 init scrip ii make 3.81-4 The GNU version of the make util ii netbase 4.32 Basic TCP/IP networking system ii portmap 6.0-5 RPC port mapper nis recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484780: Documentation needs to mention bind and server's nisdomainname
The point here is just that a valid NIS domainname needn't be a valid hostname I realize that's what the present text is saying; I was drawing attention to what it *doesn't* say. - the expectation is that your network administrator will tell you what it is On the other hand, it's always useful to say how the person installing nis can find this out without having to ask someone else. Log into the machine you'll be using as server, type nisdomainname. Done. No waiting for a reply to e-mail. Failing that, the documentation should at least say Ask your network administrator what it is if you don't know. The fact that network administrators call simply refer to it as the NIS domain name without further comment is no help to someone who *isn't* a network administrator, so isn't familiar with the nomenclature, but wants to install nis. Instructions on how to set something up should be targetted at the people who don't already know how to do so ! No, DNS shouldn't be required at all for NIS unless something in your configuration requires it (for example, using a hostname that isn't in /etc/hosts) I specified the server as a numeric IP address. So DNS *really* shouldn't have been needed. But see below. Without knowing what other packages were installed it's a bit difficult to see what might have gone wrong - do you have that information? The other packages uninstalled when I (just now) marked bind9-host as no longer needed were libbind9-30, libdns32, libisc32, libisccc30, libisccfg30, liblwres30. However, uninstalling this set of packages, I do indeed find that nis restart works without them; so whatever was happening, it wasn't bind after all. Fair enough, bind isn't needed. And yet nis restart didn't work until I installed bind9-host ! Perhaps there was some communication problem on our network, that went away at a confusing moment. Very strange. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475534: x11-apps: oclock fails to show updated time, apparently because repainting hands in wrong colour
Interesting. My X session tanked, forcing a re-start. My new oclock remained frozen in time until I switched to a virtual console and back, at which point the frozen hands went black, except for a triangle of yellow where one of them intersects the position it should be in. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475534: x11-apps: oclock fails to show updated time, apparently because repainting hands in wrong colour
Package: x11-apps Version: 7.3+1 Severity: normal A power-cut just forced me to reboot into 2.6.24-1-686, having previously been on a 2.6.18. Most X-related things were restarted within the last two weeks when I did an /etc/init.d/xdm restart, but some have doubtless been updated since. After the power-cut, my oclock has always been stopped. Its hands don't move, although they do change colour I find that an xclock works fine. My fvwm init.hook fires off oclock using + I Exec exec oclock -transparent -geometry -0+0 and post.hook sets Style * SloppyFocus Style oclockNeverFocus, NoTitle, Sticky, NoHandles, StaysOnTop I've started a separate X session, startx -- :1, running fvwm with nothing but an xterm and the xplanet root window (that somehow knew to start up, despite my having moved aside my default config), from which I started oclock -transparent; I see the oclock's hands in their initial position mostly painted black; or, when I had to clear xscreensaver, the green that xscreensaver was doing; so it looks like a failure to repaint. It looks as if the part that remains yellow is the intersection of the initial position of the hands and the position they should currently be in; but the current position is not otherwise drawn. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages x11-apps depends on: ii cpp 4:4.2.2-2 The GNU C preprocessor (cpp) ii libc6 2.7-10 GNU C Library: Shared libraries ii libfontconfig12.5.0-2generic font configuration library ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libpng12-01.2.15~beta5-3 PNG library - runtime ii libsm62:1.0.3-1+b1 X11 Session Management library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxaw7 2:1.0.4-1 X11 Athena Widget library ii libxcursor1 1:1.1.9-1 X cursor management library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxft2 2.1.12-2 FreeType-based font drawing librar ii libxkbfile1 1:1.0.5-1 X11 keyboard file manipulation lib ii libxmu6 2:1.0.4-1 X11 miscellaneous utility library ii libxmuu1 2:1.0.4-1 X11 miscellaneous micro-utility li ii libxrender1 1:0.9.4-1 X Rendering Extension client libra ii libxt61:1.0.5-3 X11 toolkit intrinsics library ii x11-common1:7.2-5X Window System (X.Org) infrastruc ii fvwm 1:2.5.25-1 F(?) Virtual Window Manager, version 2.5 x11-apps recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468358: w3c-markup-validator: Despite config, it looks in /usr/local/validator/ for templates, so fails.
Package: w3c-markup-validator
Version: 0.7.4-5
Severity: important
Tags: patch
When I first tried to use http://localhost/cgi-bin/check it failed, saying:
quote
Software error:
Does not exist or is not a directory: /usr/local/validator/templates
BEGIN failed--compilation aborted at /usr/lib/cgi-bin/check line 217.
/quote It would appear that /cgi-bin/check's default for $base_path is
managing to over-ride /etc/w3c/validator.conf's setting of Base to the actual
install location, /usr/share/w3c-markup-validator/. When I patch
--- /usr/lib/cgi-bin/.check.orig2007-05-16 05:58:49.0 +0200
+++ /usr/lib/cgi-bin/check 2008-02-28 14:59:01.0 +0100
@@ -107,7 +107,7 @@
$ENV{W3C_VALIDATOR_HOME} = $1;
}
- my $base_path = $ENV{W3C_VALIDATOR_HOME} || '/usr/local/validator';
+ my $base_path = $ENV{W3C_VALIDATOR_HOME} ||
'/usr/share/w3c-markup-validator';
#
# Read Config Files.
eval {
/patch change the default, the page loads, but not usefully. Instead of the
expected form into which to input an URL or with which to upload a file, I get
an error page quote
Sorry! This document can not be checked.
Sorry, this type of URL scheme (undefined) is not supported by this service.
Please check that you entered the URL correctly.
/quote in which assorted links are broken: they refer to,
e.g. href=./about.html, i.e. /cgi-bin/about.html, which isn't useful - the
files are installed under /usr/share/w3c-markup-validator/html/.
When I turn on Allow Private IPs = yes in validator.conf and add an explicit
?uri=... to the URL, it adds the given uri, stripped of all its punctuation, to
the start of the authorization realm for the URL it's then trying to access, so
that my authorization attempt fails. This is fairly obviously due to sub
authenticate's deliberate addition of a prefix to the realm, but suppressing
that doesn't actually help; clearly something else is wrong, too :-(
I give up and uninstall the package - the problem I set out to report was
merely important, but fixing it exposes worse problems !
All of this despite my installation on Etch at home working beautifully.
What's up with Lenny's version ? I guess Sid must have broken it ...
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
Versions of packages w3c-markup-validator depends on:
ii apache22.2.8-1 Next generation, scalable, extenda
ii apache2-mpm-worker [httpd] 2.2.8-1 High speed threaded model for Apac
ii debconf [debconf-2.0] 1.5.19Debian configuration management sy
ii libconfig-general-perl 2.37-1Generic Configuration Module
ii libhtml-parser-perl3.56-1A collection of modules that parse
ii libhtml-template-perl 2.9-1 HTML::Template : A module for usin
ii libnet-ip-perl 1.25-2Perl extension for manipulating IP
ii libset-intspan-perl1.07-3.1 Manages sets of integers
ii libtext-iconv-perl 1.4-3 converts between character sets in
ii liburi-perl1.35.dfsg.1-1 Manipulates and accesses URI strin
ii libwww-perl5.808-1 WWW client/server library for Perl
ii opensp 1.5.2-3 OpenJade group's SGML parsing tool
ii perl 5.8.8-12 Larry Wall's Practical Extraction
ii sgml-data 2.0.3 common SGML and XML data
ii w3c-dtd-xhtml 1.1-5 W3C eXtensible HyperText Markup La
ii wwwconfig-common 0.0.48Debian web auto configuration
Versions of packages w3c-markup-validator recommends:
ii w3-dtd-mathml 2.0.0.0-1 Mathematical Markup Language V2.0
-- debconf information:
* w3c-markup-validator/webserver: Apache2
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
