Bug#342650: pike7.6: The pike package is present in sarge but missing from etch.
Package: pike7.6 Version: 7.6.24-1 Severity: important Some months ago I upgraded from sarge to etch by simply editing sources.list and running aptitude -u; consequently, I kept the pike7.6 from before the switch. (I'm told a dist-upgrade would have removed it.) This week, I got a new machine, so set it up straight off in testing. The pike7.6 package is not present. I had to add a sarge entry back into sources.list to retrieve it ! So it's *etch*, not pike, that was rendered unusable (for me) by this omission ... -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-11-em64t-p4-smp Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages pike7.6 depends on: ii pike7.6-core 7.6.24-1 Powerful interpreted programming l ii pike7.6-gdbm 7.6.24-1 Gdbm module for Pike ii pike7.6-image 7.6.24-1 Image module for Pike Versions of packages pike7.6 recommends: ii pike7.6-doc 7.6.24-1 Pike 7.6 documentation meta packag -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342650: pike7.6: The pike package is present in sarge but missing from etch.
Thanks for your prompt reply. > http://packages.debian.org/unstable/interpreters/pike7.6 http://www.debian.org/releases/ says that unstable is sid, testing is etch. See bug summary: the problem is with etch. On http://packages.debian.org/testing/interpreters/ I see the alphabetical list go php5-uuid (1.3.1-1) OSSP uuid module for php5 prolog-el (1.3-3) Emacs major mode for editing Prolog code without the intervening several pages of pike that show up on the matching page for unstable. If I try to access http://packages.debian.org/testing/interpreters/pike7.6 I get a 404 response. > As you can see, the package is right there. in sarge and sid but *not in etch* ... Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342650: pike7.6: The pike package is present in sarge but missing from etch.
Hello Marek, > You're right, I misread your initial message heh - I deal with bug reports too - misreading is all too easy. It's an unavoidable problem of knowing enough to usually be right ... > please see http://qa.debian.org/developer.php?excuse=pike7.6 though. I like the url; it has a pleasing honesty to it ^^ > It should be in the testing archive really soon now. Yay :-) Not that it'll affect me until it's updated to a newer version than sarge offered me the other week, since I *do* have it installed, but other users of testing will be better for it :-) Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347389: aptitude: Unscrollable error display on unavailable public key.
Package: aptitude Version: 0.4.1-1 Severity: normal When I aptitude -u I get a red error window saying W: GPG error: ftp://ftp.no.debian.org testing Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F and similar for two other entries from my sources.list, with exactly the same NO_PUBKEY hex number (if anyone can tell me what to do about *that* I'd be grateful, but it's not *this* bug); the big red window this is in has a scroll-bar on the right; neither z nor down-arrow scrolls it; the OK "button" is highlit, but Tab doesn't take me off it to focus the error window. Consequently, I can't read the further error messages (who knows, maybe they end by telling me something I might be able to do about it - or, even, telling me which package is responsible for checking public keys). Assuming those messages were there for a reason, being able to read them probably matters ... I have debian-keyring and debsig-verify installed; but uninstalling them makes no difference to the error message or its unwillingness to scroll. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-11-em64t-p4-smp Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.3-6-3. 0.6.43.1Advanced front-end for dpkg ii libc62.3.5-8 GNU C Library: Shared libraries an ii libgcc1 1:4.1-0exp0 GCC support library ii libncursesw5 5.5-1 Shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.16-2type-safe Signal Framework for C++ ii libstdc++6 4.1-0exp0 The GNU Standard C++ Library v3 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc 0.4.1-1English manual for aptitude, a ter -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347545: login crashes when trying to use nis
Package: nis Version: 3.15-3 Severity: grave Justification: renders package unusable (arguably critical; when installed, renders login unusable) When root tried to su - eddy it got this response on stderr: -su: nss_nis/nis-netgrp.c:79: _nss_nis_setnetgrent: Assertion `malloc_usable_size (netgrp->data) >= len + 1' failed. When I try to log on at a terminal, I get exactly the same response, but without the -su: prefix (however, it was much easier to capture the response from root's shell using 2>file, and e-mail it to myself). I had +::0: as the last line of my /etc/group and [EMAIL PROTECTED]:: as last line of /etc/passwd, for a suitable host name on our local network, and, after first seeing the above error, also added this line at the end of /etc/shadow, but this made no visible difference. Naturally, I had to remove all of those before I could log in. My nis/domain is a local domain served by another host on the local network, which /etc/yp.conf is configured to consult; ypcat passwd's output did include lines for eddy on that server, and /var/yp/binding/ did get entries (.1 and .2) for the domain specified. The debconf info (which used to contain the nis/domain datum discussed above) says nis is "not yet configured". Since I've uninstalled nis and re-installed it recently, I can only suppose this is due to the installation scripts not configuring nis. Getting to the point above had involved a great deal of guess-work, reading of man pages, stumbling by chance on relevant files and filling those with data by trial and error. Nothing made itself even remotely obvious as a "how to tell nis to configure itself", even in the course of all that rummaging. Running dpkg-reconfigure, I get consulted for the nis/domain value; it already knows the value I had configured it to by hand; and I think this was run when I re-installed nis. (The prompt for this is, fundamentally, unhelpful: only when I'd got it wrong, and rummaged a lot as above, did I discover a passing comment, probably in a man page: from which I realized that it isn't a domain name in the normal sense; and gleaned that the datum is stored in /etc/defaultdomain, and must match that on the nis server, so went to the ypserver and looked in its /etc/defaultdomain to discover the correct value. It would be worth saying "look in your NIS server's /etc/defaultdomain for the authoritative version of this variable" or some such.) I didn't get consulted for the ypserver's IP address, nor was I asked whether I wanted to enable nis in passwd and group. Until the package's installation scripts ask those questions and sort out the correct magic in /etc/*, this package is not ready for normal mortals to use: crucial information is only available by asking someone who already knows, or by insane amounts of effort, persistence and lucky guess-work. But I digress. -- Package-specific info: -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-1-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages nis depends on: ii debconf [debconf-2.0] 1.4.66 Debian configuration management sy ii libc6 2.3.5-8GNU C Library: Shared libraries an ii libgdbm3 1.8.3-2GNU dbm database routines (runtime ii libslp1 1.2.1-5OpenSLP libraries ii make 3.80+3.81.b4-1 The GNU version of the "make" util ii netbase 4.24 Basic TCP/IP networking system ii portmap 5-16 The RPC portmapper ii sysvinit 2.86.ds1-4 System-V like init nis recommends no packages. -- debconf information: * nis/not-yet-configured: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#342650: pike7.6: The pike package is present in sarge but missing from etch.
I note with glee, upon my return from mid-winter holidays, that the pike package set now shows up among etch's New Packages (as reported by aptitude) - bug fixed, thank you :-) Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304055: smail: cron.daily script invokes checkerr, which must be run as root, via su mail
Package: smail Version: 3.2.0.115-5.1 Severity: normal File: /etc/cron.daily/smail My daily anacron job is telling me: /etc/cron.daily/smail: checkerr: ERROR: you must be root to do this! The (package-supplied) cron.daily script overtly does a su mail -c to run checkerr, despite starting with a comment to the effect that we have to be root to log-rotate, so may as well run checkerr while we're at it ! -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages smail depends on: ii cron3.0pl1-86management of regular background p ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an ii libident0.22-3 simple RFC1413 client library - ru ii libwrap07.6.dbs-8Wietse Venema's TCP wrappers libra -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294350: coreutils: sort(1)'s +$num flag is not mentioned in the man page
Package: coreutils Version: 5.2.1-2 Followup-For: Bug #294350 I am used to sort historically supporting a +$num option. This would appear to be supported by the present coreutils sort. It is not, however, mentioned in the manual page. This is related to #294350: having now done some experiments, I find that +$n is an undocumented form of -k $(( 1 + $n )). If it is deprecated, then the man page should say so (both to help us old dogs learn new tricks and to explain to anyone who's inherited scripts from us what we thought we were doing). But the description of -k (aside from being split between where -k appears in the option list and the paragraph which follows the last options) is ... probably perfectly clear to someone who already knows what -k does ... but was so mysterious I had to conduct experiments to find out what -k really does. Have pity on the poor newcomers with less prior knowledge ! Saying "(origin 1)" meant something to me, but I suspect a newcomer would be more likely to understand "(left-most field is number 1)". It would probably be better to say (see below) at the end of -k's description, and explain the numbering after "F is the field number" in the later paragraph. Furthermore, in -k's description, POS2 is mis-spelt "POS 2". And the later paragraph appears to claim I can give options to both POS1 and POS2; but applicable options would apply to the whole key, so this seems somewhat spurious ... though possibly correct. -- System Information: Debian Release: 3.1 APT prefers experimental APT policy: (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages coreutils depends on: ii libacl1 2.2.23-1 Access control list shared library ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294350: coreutils: sort(1)'s +$num flag is not mentioned in the man page
Hi Jim, Thanks for the quick response - so much for those (typically among the proprietary suppliers whose support is worst) who say Free Software lacks support ;^) > The main trick is knowing that the `real' documentation ... ah, I see. I guess that's why the COPYRIGHT notice is (mildly inappropriately) for the program described, without saying so, rather than for the man page itself ... of course, since copyright notices became optional some time ago, this is not an issue. Perhaps it would be worth making the situation obvious earlier; e.g. add a second line to DESCRIPTION along the lines of This is just terse help: SEE ALSO points to full documentation. added to the man page while adding the SEE ALSO section; or, indeed, the whole SEE ALSO section could be made redundant by adding For full documentation use command: info coreutils sort to the --help output after what becomes the first line of DESCRIPTION. As an ageing emacs junkie, it occurs to me that mentioning that C-h i d m sort is another route to SEE ALSO's destination. Then again, anyone who needs it can probably work that out from what you said ;^) >> ... +$n is an undocumented form of -k $(( 1 + $n )). If it is >> deprecated, then the man page should say so ... > It does say so -- in the real (`info sort') documentation. (nod) >> Saying "(origin 1)" meant something to me, but I suspect a newcomer >> would be more likely to understand "(left-most field is number 1)". > But then it wouldn't fit on one line :-) 1/2 and I see the info page is suitably clearer :-) > At least one option (`b') can be applied to either > the start field or end field -- or to both, but it's a little > esoteric and not often useful. ah, OK. I tentatively guess *trailing* space is ignored for all fields ? > SIZE may be followed by the following multiplicative suffixes: % 1% > of memory, b 1, K 1024 (default), and so on for M, G, T, P, E, Z, Y. woaaah ! Yotta-bytes ? Even 64-bit machines are going to have trouble addressing that big (1L << 80) a chunk of memory ! (Same problem for zetta-bytes.) I guess that's what you call "forward compatibility" ;^) I think the above should say "byte" where it's the unit and be punctuated as: SIZE may be followed by the following multiplicative suffixes - %: 1% of memory; b: 1 byte; K: 1024 bytes (default); and so on for M, G, T, P, E, Z, Y. I also note that the paragraph beginning "Mandatory options" belongs in the preamble, since it doesn't (I assume) apply only to the Ordering options ! So it should appear before that sub-heading. The indentation leaves a little to be desired. The explanative texts for -b, -t and --help itself appear inline with the actual option illustrations (which is fine for the --help output but not so good for the man page); and it would be nicer if at least the sub-headings - "Ordering options" and "Other options:" - were less indented than the actual option illustration (the running text could sensibly share their indentation), e.g. DESCRIPTION Write sorted concatenation of all FILE(s) to standard output. This is just terse help: SEE ALSO points to full documentation. Mandatory arguments to long options are mandatory for short options too. Ordering options: -b, --ignore-leading-blanks ignore leading blanks and so on (it almost seems a shame to give a help text when the long option is so informative). Yes, I am a pythonista; and no, I don't remember enough [gnt]roff to know how to fix that. I learned a new format - HTML - over a decade ago, and have forgotten several old ones from disuse. Thanks again for your help, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298097: /usr/bin/ar: same elfcode.h internal error happens with ar
Package: binutils Version: 2.15-6 Followup-For: Bug #298097 When running ar crs to add a large number of files to an existing large .a I got: BFD: BFD 2.15 internal error, aborting at ../../bfd/elfcode.h line 188 in bfd_elf32_swap_symbol_in BFD: Please report this bug. I see a bug report listed for binutils with similar message, but against ld; it would appear that ld isn't the only one suffering from this ! -- System Information: Debian Release: 3.1 APT prefers experimental APT policy: (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages binutils depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an -- debconf information: * binutils/kernel_link_warning: binutils/oformat_warning: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397310: How do I repair my config ?
This bug sounds like why my intraweb site's AuthLDAP stopped working. Some password-protected documents became 500: Internal Server Error. I'm using AuthLDAP with require valid-user. First, error.log reported "Invalid command 'AuthLDAPEnabled'", which doesn't have any visible equivalent in the up-to-date documentation, so I commented that out of my .htaccess and reloaded the page. Next objection was to AuthLDAPAuthoritative; documentation offered me AuthzLDAPAuthoritative to replace it (though emacs' apache-mode hasn't been updated to recognize this instead of the old form). After that, it said: configuration error: couldn't check user. No user file? leaving me stranded - the ldap:// URL I'm using as AuthLDAPURL worked fine before the upgrade. Whad else do I need to change to make this work ? [EMAIL PROTECTED]:~$ dpkg -s apache2 Package: apache2 Status: install ok installed Priority: optional Section: web Installed-Size: 84 Maintainer: Debian Apache Maintainers Architecture: all Version: 2.2.3-3 Depends: apache2-mpm-worker (>= 2.2.3-3) | apache2-mpm-prefork (>= 2.2.3-3) | apache2-mpm-event (>= 2.2.3-3) Description: Next generation, scalable, extendable web server Apache v2 is the next generation of the omnipresent Apache web server. This version - a total rewrite - introduces many new improvements, such as threading, a new API, IPv6 support, request/response filtering, and more. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397310: How do I repair my config ?
> This bug sounds like why my intraweb site's AuthLDAP stopped working. > What else do I need to change to make this work ? I forgot to mention: I *did* shuffle the symlinks in /etc/apache2/mods-enabled/ to include authnz_ldap.load and ldap.load but not auth_ldap.load (since it's empty). Are there others I need ? Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397310: How do I repair my config ?
>> What else do I need to change to make this work ? > I forgot to mention: I *did* shuffle the symlinks and when I symlinked *all* auth* into enabled, and restarted, I got: [Wed Nov 08 19:50:26 2006] [notice] caught SIGTERM, shutting down [Wed Nov 08 19:50:35 2006] [notice] Digest: generating secret for digest authentication ... [Wed Nov 08 19:50:35 2006] [notice] Digest: done [Wed Nov 08 19:50:35 2006] [notice] Apache/2.2.3 (Debian) mod_perl/2.0.2 Perl/v5.8.8 configured -- resuming normal operations [Wed Nov 08 19:50:43 2006] [error] Internal error: pcfg_openfile() called with NULL filename [Wed Nov 08 19:50:43 2006] [error] [client 10.20.19.123] (9)Bad file descriptor: Could not open password file: (null), referer: http://whorl/~eddy/ Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397310: our workaround
Thank you Joseph - that fixed mine, too :-) Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413095: libc6: Typo in ldd script: refers to file_magic_regex but filename_magix_regex was set
Package: libc6 Version: 2.3.6.ds1-11 Severity: normal In /usr/bin/ldd there is a variable, filename_magic_regex, which is set before argument parsing and passed to egrep when checking the name of a non-executable file. Later, when checking the output of file -L, a variable file_magic_regex is referenced: however, this variable is nowhere set. It would appear, from context, that it *isn't* a typo for filename_magic_regex. However, it should probably also be set, somewhere ! Alternatively, the test based on file -L | sed 10q needs to be revised in some way: at present, it fatuously always passes, since egrep '' matches everything. No patch, as I'm unable to guess what regex was intended. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Versions of packages libc6 depends on: ii tzdata2006p-1Time Zone and Daylight Saving Time libc6 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413095: libc6: Typo in ldd script: refers to file_magic_regex but filename_magix_regex was set
> this is already fixed in experimental along with bug 165417 in fact. OK, good to hear. I'm on etch, so behind the curve on updates. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410740: x11-common: please conflict with opera (<< 9.10-20061214.6)
Hi Debian, I'm the Opera package maintainer. This bug doesn't say what the cause for the needed conflict is. However, the .5 (sarge) and .1 (static) builds released at the same time as the specified .6 (etch) build almost certainly had whatever fix was relevant, just as good as the .6 one did. So the final .6 suffix causes builds from the same day, but for sarge and older, to be in conflict. It may thus make some sense to drop this suffix. You would also do well to conflict with opera-static with version numbers matching the same constraint as opera. I've been told that the conflict has to do with the opera symlink in /usr/X11R6/bin/: I suppose the 20061214 build is the first official release your correspondent met in which the bug is fixed. However, the bug was fixed in 2006/May (and went into assorted unofficial builds between then and the official release). This should have gone into the 9.00 official release. So, if the conflict is about the symlink, you should be able to amend the version to 9.00-20060600 or similar. If the problem wasn't that symlink, I'd greatly appreciate it if you can tell me the details. I can ask our QA team to give a more precise date on the correct release version. If it's a bug I didn't notice myself fixing, I may need to port it to newer branches of the packaging scripts ! Edward Welbourne, for the Opera packaging team. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410740: x11-common: please conflict with opera (<< 9.10-20061214.6)
Hi again Julien,
> If you can give us a more accurate version number to conflict with,
> we'll gladly change it.
OK, QA helpfully dug through the archive. The earliest public release
which included the fix was 9.00-20060616 (and all variant builds
included the fix). So the correct conflict would be
Conflicts: opera (<< 9.00-20060616)
Let us know if you run into any similar problems in future, we're
always eager to make our packages fit in better with distributions,
Edward Welbourne, for the Opera packaging team.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#725017: closed by Markus Koschany (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 (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 (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 (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#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): 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 un chromium-l10n(no description available) un chromium-testsuite (no description available) 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 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 un chromium-l10n(no description available) un chromium-testsuite (no description available) 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 NCurses version 5.9 libsigc++ version: 2.2.11 Ept support enabled. Gtk+ support
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. # 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 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#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: 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. 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#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 (, , 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 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#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 Ve
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 "" > 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 "" 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: 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 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#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 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 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 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 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 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 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-event pn apache2-mpm-itk ii apache2-mpm-prefork 2.2.22-13 pn apache2-mpm-worker -- Configuration Files: /etc/apache2/mods-available/userdir.conf changed: UserDir web UserDir disabled root AllowOverride FileInfo AuthConfig Limit Indexes Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec # Ignore default's allow/deny: over-ridden by server config. /etc/apache2/ports.conf changed: Listen 80 # If you add NameVirtualHost *:443 here, you will also have to change # the VirtualHost statement in /etc/apache2/sites-available/default-ssl # to # Server Name Indication for SSL named virtual hosts is currently not # supported by MSIE on Windows XP. Listen 443 Listen 443 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@
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#725017: closed by Markus Koschany (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#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: cvs update: warning: unrecognized response `Use of uninitialized value $wrev in string ne at /usr/bin/git-cvsserver line 1262, 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, line 1447.' from cvs server cvs update: `Vault.png' is no longer in the repository 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: ssh -o 'RemoteForward 2402 localhost:2401' chaos 'cd public_html && cvs up' my /etc/services has cvspserver 2401/tcp# CVS client/server operations cvspserver 2401/udp and inetd.conf says cvspserver stream tcp nowait eddy /usr/bin/git-cvsserver git-cvsserver pserver /home/eddy/.repository/chaos.git The remote end's CVS/Root files say :pserver:anonymous@localhost:2402/home/eddy/.repository/chaos.git 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#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 pn freemind-plugins-help pn freemind-plugins-script 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#556555: closed by Arnaud Fontaine (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#556555: closed by Arnaud Fontaine (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#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#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#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 interfa
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#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
Traceback (most recent call last):
File "/usr/bin/slimit", line 5, in
from pkg_resources import load_entry_point
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1189, in
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'
which wasn't much use. The problem is that last stack frame, in
pkg_resources.py, where
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],
...
presumes that the module platform has python_version as an attribute
(that is, no less, callable returning a sequence). A quick python
session:
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 "", line 1, in
AttributeError: 'module' object has no attribute 'python_version'
>>> platform.version
>>> 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]'
reveals that this is an unrealistic expectation.
Continuing,
>>> import pkg_resources
Traceback (most recent call last):
File "", line 1, in
File "pkg_resources.py", line 1189, in
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'
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:
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
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
python-pkg-resources recommends no packages.
Versions of packages python-pkg-resources suggests:
pn python-distribute
pn python-distribute-doc
-- 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#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#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#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#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#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#432847: /usr/bin/xload: xload needs a way to limit range of values it can display
> Unfortunately, most tiny X programs like this one usually don't get much > maintenance. So you should probably try to come with a patch if you > really want this to be implemented :/ Fair enough. If I find the time ... Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#465427: libc6: strftime gets confused by the invalid format specifier "%20#%"
Package: libc6
Version: 2.7-6
Severity: minor
I used the following program to probe the behaviour of strftime:
#include
#include
const int bufsize = 4096;
int main(int count, char *args[])
{
char buf[bufsize];
time_t now = time(NULL);
struct tm rom, *when = localtime_r(&now, &rom);
int i = 1;
if (when == 0)
return 1;
while (i < count)
{
size_t len = strftime(buf, bufsize, args[i++], when);
if (len)
puts(buf);
}
return 0;
}
(I wanted to know what modifiers it supported to the various
format specifiers; I could only see E and O mentioned in either POSIX
or glibc's own manual page, but there are obvious uses for field
widths on %A and %B, for example, and systematic support for '0' and '
' would enable a simplification of the spec (e.g. we'd only need one
of H, k), so I was pleased to find field widths supported and curious
to see what, if anything else, is.)
I found that printf's '#', '-' and '0' modifiers are honoured (but '+'
and ' ' aren't). These don't really make sense, aside from "%0l"
(ell) and "%0k" - and even these are mere aliases fo "%I" and "%H", so
not actually useful. This is harmless.
However, when I tried the malformed format string "|%20#%|" it emitted
|%20#%|
in which it's converted %20# to a string of width 20 (thanks to the
field width), then decided not to treat it as a format specifier after
all, so used %20# as the "content" right-justified within those 20
characters. For contrast, snprintf simply emitted the format
specifier verbatim - as I expected, given that this is how invalid
format specifiers are generally handled by both functions.
This behaviour is inconsistent with the general handling of invalid
format specifiers, although it probably isn't strictly a bug - I
imagine the spec says the behaviour on undefined format specifiers is
undefined. However, it does suggest some confusion in the
implementation, so seems worth reporting upstream.
It's not important or urgent, though !
-- 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 libc6 depends on:
ii libgcc1 1:4.3-20080116-1 GCC support library
libc6 recommends no packages.
-- debconf information:
glibc/restart-failed:
glibc/restart-services:
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423014: console's last three lines become inaccessible once xdm start up
Package: xdm Version: 1:1.1.4-3 Severity: critical Tags: security Justification: breaks unrelated software When I start up xdm, the console starts to imagine that there are three more lines available than actually exist. The console actually has 25 lines; but the console ttys think it has 28 lines. The resize command reports LINES=28. Even if I export LINES=25 and then fire up screen, my shell within screen has LINES=28. This means that I can't see the last three lines of output, once output gets to the bottom of the screen; it means that the emacs minibuffer and the aptitude dialog area are invisible; these don't even scroll into view after it's too late. This makes both emacs and aptitude almost impossible to use (hence: breaks unrelated software) and makes it almost impossible for root to do anything (hence: critical) if I follow the cautious policy of never letting root do anything in a window under X. The console becomes extremely difficult (and dangerous - see below) to use. It means that, when dpkg is installing a package, I'm apt to be asked some question I can't see and given a prompt I can't see and left waiting for the program to do something, so I end up hitting return and getting whatever the default was for the question I never saw being asked (on account of this last, I have added "security" as a tag); after that, dpkg begins producing more output and the entire dialog in which I have just played my blind part scrolls into view. Obviously, dpkg is not the only software (reportbug springs to mind) that relies on me to respond to prompts, after producing enough output that it's apt to be in the last three lines of the screen; nor is dpkg the only one for which random answers to unseen prompts may result in security-relevant disasters. The problem is *not* that the screen is mis-sized; if I shrink vertical on the screen, I still don't see the missing lines, though the lines I do see now fit into a smaller vertical span on my screen. In any case, if I suppress xdm's start-up (by adding an early exit 0 to /etc/init.d/xdm) I see normal console behaviour. It would not, however, surprise me if the problem is really with something else (xdm is merely triggering it); there may be some package doing something clever with the frame-buffer (bug I don't have a logo visible on screen). The problem *may* (but I'd be surprised) be related to the fact that my xorg.conf Display sections say Modes "1280x1024" "1152x864" "1024x768" "832x624" "800x600" "720x400" "640x480" "1600x1200" with the highest-resolution last (when I put it first, xdm failed to start up, albeit taking three tries at it before giving up; moving it to the end lets xdm start, after which Ctrl+Alt+keypad(-) suffices to get me to the highest resolution; leaving it on the default doesn't help the console, though). About three months ago, I saw this same problem, tried to find its cause, gave up and then was surprised, upon running the euro-test script (which failed) to find the problem had gone away. Today I moved desks, so re-booted (for the first time since the power outage three months ago - I love stable software ;-); and euro-test now passes, without fixing this problem. The fact that euro-test used to be able to fix it does imply that there must be some way to work around the problem (I'd be delighted if anyone can identify what; I've been carefully through euro-test without finding what it did that solved the problem). I tried /etc/init.d/console-screen.sh, invoked the same way euro-test was doing so three months ago, but that wasn't what was solving the problem. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-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 xdm depends on: ii cpp 4:4.1.1-15 The GNU C preprocessor (cpp) ii debconf [debconf-2.0] 1.5.13 Debian configuration management sy ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libice6 1:1.0.3-2X11 Inter-Client Exchange library ii libpam0g0.79-4 Pluggable Authentication Modules l ii libselinux1 1.32-3 SELinux shared libraries ii libsm6 1:1.0.2-2X11 Session Management library ii libx11-62:1.0.3-7X11 client-side library ii libxau6 1:1.0.1-2X11 authorisation library ii libxaw7 1:1.0.2-4X11 Athena Widget library ii libxdmcp6 1:1.0.2-2X11 Display Manager Control Protoc ii libxext61:1.0.1-2X11 miscellaneous extension librar ii libxinerama11:1.0.1-4.1 X11 Xinerama extension library ii libxmu6
Bug#423014: console's last three lines become inaccessible once xdm start up
>> Section "Device" >> Identifier "Intel 82915G/GV/910GL" >> Driver "vesa" >> BusID "PCI:0:2:0" >> EndSection >> > Did you try the "i810" driver instead of "vesa"? > Also, do you use a fb console? This is the point where I should point out that I am not a sysadmin. (I *have* been using X since the early '90s, so I can work out how to use startx manually, though.) Consequently, it'll be worth going into slightly more detail when asking me for more information, so I know what to do to discover the answers you need. Relevant command-lines should suffice. I'm guessing that if I run dpkg-reconfigure on the xserver package, it'll ask me to select a driver and I can change from vesa to i810. However, I've no idea how to find out whether I'm using an fb console. I have six virtual consoles and an X session, accessible by Alt+F[1-7], with help from Ctrl if coming from the X session. Please suggest a command that'll reveal whether I have an fb console. > This is weird... ah. Well, let's see where it goes ... Thanks for your help, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423014: console's last three lines become inaccessible once xdm start up
Hi again Julien, Everone else went home, so I have a chance to break things^W^W experiment. Upon re-booting and actually checking what resize and $LINES say when the X server hasn't messed things up, I find that I've mis-described this bug. The normal state does in fact have 28 lines; when the X server starts up, something causes the console to be only able to display 25 of them; I think these are slightly taller, since they fill the same amount of screen. None the less, screen resizing via the hardware controls doesn't help. So something has changed the console - maybe its font ? Any idea how I can ask it about that ? So, sorry about having it partially back-to front; but the same consequences flow from it ! >> I'm guessing that if I run dpkg-reconfigure on the xserver package, >> it'll ask me to select a driver and I can change from vesa to i810. > > That, or replace vesa with i810 in /etc/X11/xorg.conf and restart X. I had to reboot anyway (to restore normal mode), so might as well use the brute force approach and let the system do any updates it deems prudent. This also meant that I saw that the part of the configuration which offered me a choice between using the frame buffer and not using it was set to not use it. I left it that way. Interestingly, the reconfigure has put my Modes lines into the usual order, with 1600x1200 first, and xdm has no problem starting up; so clearly whatever problem it was having (before I bodged the order as described previously) has been solved. >> Please suggest a command that'll reveal whether I have an fb console. > Maybe lsmod will show whether a fb driver is loaded. lsmod | grep fb yielded no output. The full output of lsmod contained 58 lines but I have no delusions of understanding it. Do you want to see it all ? lsmod | grep i810 yielded i810_audio 32916 0 ac97_codec 17196 1 i810_audio soundcore 9248 2 i810_audio,snd Rebooting without xdm (and confirming that I was still in normal mode), I logged in as a non-privileged user (me) and ran startx (with no args); it started up X just fine, and all my consoles went into "only displaying 25 lines" mode, as before. So your guess that xdm is not the culprit is vindicated. I'm now running (and was when testing startx) with Section "Device" Identifier "Intel Corporation 82915G/GV/910GL Integrated Graphics Controller" Driver "i810" BusID "PCI:0:2:0" EndSection and I still get the (++) using VT number 7 (WW) xf86OpenConsole: setpgid failed: Operation not permitted (WW) xf86OpenConsole: setsid failed: Operation not permitted which you deemed weird earlier. If you want full output from your earlier script, just ask and I can do that again. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#423014: console's last three lines become inaccessible once xdm start up
Interestingly, when aptitude fires up the console-graphical package configuration tool, during installation of new packages, it manages to put the OK selector where I *can* see it, even though aptitude itself fails to show me its last three lines. (For example, when asking me to hit return to continue, it does so where I can't see it; I have no way to know whether it's showing that prompt or just taking a long time to install some package that it's mentioned on a line I can't see.) Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#467004: apache2: Apply IfModule to the internationalized error messages stanza of config
Package: apache2 Version: 2.2.8-1 Severity: wishlist Tags: patch The shipped apache2.conf ends (before the last two include directives) with a section dealing with internationalized error responses. This is commented out but preceded by a comment saying # The internationalized error documents require mod_alias, mod_include # and mod_negotiation. To activate them, uncomment the following 30 lines. It would make more sense to simply wrap these 30 lines in suitable IfModule directives and leave the uncommented by default. @@ -1,3 +1,4 @@ +# -*- Mode: Apache -*- # # Based upon the NCSA server configuration files originally by Rob McCool. # @@ -240,42 +252,43 @@ # even on a per-VirtualHost basis. The default include files will display # your Apache version number and your ServerAdmin email address regardless # of the setting of ServerSignature. -# -# The internationalized error documents require mod_alias, mod_include -# and mod_negotiation. To activate them, uncomment the following 30 lines. - -#Alias /error/ "/usr/share/apache2/error/" -# -# -#AllowOverride None -#Options IncludesNoExec -#AddOutputFilter Includes html -#AddHandler type-map var -#Order allow,deny -#Allow from all -#LanguagePriority en cs de es fr it nl sv pt-br ro -#ForceLanguagePriority Prefer Fallback -# -# -#ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var -#ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var -#ErrorDocument 403 /error/HTTP_FORBIDDEN.html.var -#ErrorDocument 404 /error/HTTP_NOT_FOUND.html.var -#ErrorDocument 405 /error/HTTP_METHOD_NOT_ALLOWED.html.var -#ErrorDocument 408 /error/HTTP_REQUEST_TIME_OUT.html.var -#ErrorDocument 410 /error/HTTP_GONE.html.var -#ErrorDocument 411 /error/HTTP_LENGTH_REQUIRED.html.var -#ErrorDocument 412 /error/HTTP_PRECONDITION_FAILED.html.var -#ErrorDocument 413 /error/HTTP_REQUEST_ENTITY_TOO_LARGE.html.var -#ErrorDocument 414 /error/HTTP_REQUEST_URI_TOO_LARGE.html.var -#ErrorDocument 415 /error/HTTP_UNSUPPORTED_MEDIA_TYPE.html.var -#ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var -#ErrorDocument 501 /error/HTTP_NOT_IMPLEMENTED.html.var -#ErrorDocument 502 /error/HTTP_BAD_GATEWAY.html.var -#ErrorDocument 503 /error/HTTP_SERVICE_UNAVAILABLE.html.var -#ErrorDocument 506 /error/HTTP_VARIANT_ALSO_VARIES.html.var - + + + +Alias /error/ "/usr/share/apache2/error/" + + +AllowOverride None +Options IncludesNoExec +AddOutputFilter Includes html +AddHandler type-map var +Order allow,deny +Allow from all +LanguagePriority en cs de es fr it nl sv pt-br ro +ForceLanguagePriority Prefer Fallback + + +ErrorDocument 400 /error/HTTP_BAD_REQUEST.html.var +ErrorDocument 401 /error/HTTP_UNAUTHORIZED.html.var +ErrorDocument 403 /error/HTTP_FORBIDDEN.html.var +ErrorDocument 404 /error/HTTP_NOT_FOUND.html.var +ErrorDocument 405 /error/HTTP_METHOD_NOT_ALLOWED.html.var +ErrorDocument 408 /error/HTTP_REQUEST_TIME_OUT.html.var +ErrorDocument 410 /error/HTTP_GONE.html.var +ErrorDocument 411 /error/HTTP_LENGTH_REQUIRED.html.var +ErrorDocument 412 /error/HTTP_PRECONDITION_FAILED.html.var +ErrorDocument 413 /error/HTTP_REQUEST_ENTITY_TOO_LARGE.html.var +ErrorDocument 414 /error/HTTP_REQUEST_URI_TOO_LARGE.html.var +ErrorDocument 415 /error/HTTP_UNSUPPORTED_MEDIA_TYPE.html.var +ErrorDocument 500 /error/HTTP_INTERNAL_SERVER_ERROR.html.var +ErrorDocument 501 /error/HTTP_NOT_IMPLEMENTED.html.var +ErrorDocument 502 /error/HTTP_BAD_GATEWAY.html.var +ErrorDocument 503 /error/HTTP_SERVICE_UNAVAILABLE.html.var +ErrorDocument 506 /error/HTTP_VARIANT_ALSO_VARIES.html.var + + + # Include of directories ignores editors' and dpkg's backup files, # see README.Debian for details. and it would clearly be even better to move the result (and the comments preceding it) to a separate conf.d/localized-error (left as a trivial exercise for whoever merges the patch). -- Package-specific info: Config file syntax check failed. List of /etc/apache2/mods-enabled/*.load: alias auth_basic authn_file authnz_ldap authz_default authz_host authz_user autoindex cgid dir* env ldap mime negotiation perl setenvif ssl status userdir (A * means that the .conf file for that module is not enabled in /etc/apache2/mods-enabled/) -- 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 apache2 depends on: ii apache2-mpm-worker2.2.8-1High speed threaded model for Apac apache2 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, em
Bug#467480: apache2: default autoindex.conf uses bomb icon for file called score
Package: apache2 Version: 2.2.8-1 Severity: minor Tags: patch I saw occasional files and directories showing up with a bomb icon; I guessed they were broken symlinks or some such glitch, but closer investigation revealed no problem. Eventually, I noticed their names all ended in "core" and guessed what was happening. Sure enough, AddIcon is tested as a wild-card or a suffix of the name, so deems (for example) score to be a match for core, so displays it as a bomb. Likewise dual-core, quad-core and so on. --- /etc/apache2/mods-available/autoindex.conf.orig 2008-01-17 21:13:45.0 +0100 +++ /etc/apache2/mods-available/autoindex.conf 2008-02-25 20:19:01.0 +0100 @@ -36,7 +36,8 @@ AddIcon /icons/uuencoded.gif .uu AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl AddIcon /icons/tex.gif .tex -AddIcon /icons/bomb.gif core +# It's a suffix rule, so simply matching "core" matches "score" as well ! +AddIcon /icons/bomb.gif /core AddIcon (SND,/icons/sound2.gif) .ogg AddIcon (VID,/icons/movie.gif) .ogm To my mild surprise, I found that matching isn't only done on the name of the file (relative to its directory); it includes enough of the path that /core does indeed match a file called simply "core". So it proved easy enough to fix the problem :-) The documentation at /doc/apache2-doc/manual/en/mod/mod_autoindex.html#addicon is also, consequently, mildly inaccurate when it ends the list of things that name can be with "or a complete filename." It's always matched against suffixes, so the only way to make it *only* match as a complete filename is to include a leading / (and I don't know whether there are any limitations on that). Ideally, there'd be some way to ensure the AddIcon rule for the bomb would only match a *file* named (exactly) core; a directory of the same name should just be displayed as a directory. However, I couldn't immediately see how to fix that and don't happen to have any directories with this name in my local webspace, so didn't look harder. -- Package-specific info: Config file syntax check failed. List of /etc/apache2/mods-enabled/*.load: alias auth_basic authn_file authnz_ldap authz_default authz_host authz_user autoindex cgid dir* env ldap mime negotiation perl setenvif ssl status userdir (A * means that the .conf file for that module is not enabled in /etc/apache2/mods-enabled/) -- 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 apache2 depends on: ii apache2-mpm-worker2.2.8-1High speed threaded model for Apac apache2 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:
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.
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
--- /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 {
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
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.
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]
Bug#456904: w3c-markup-validator: Broken HOMEPAGE support (Debian addition to upstream)
Subject: w3c-markup-validator: Broken HOMEPAGE support (Debian addition to
upstream)
Package: w3c-markup-validator
Version: 0.7.4-4
Severity: minor
I noticed some warnings in my apache error logs, which contained
many repeats of each of:
error.log.22.gz:[Wed Jul 18 08:15:45 2007] check: Use of uninitialized value in
concatenation (.) or string at /usr/lib/cgi-bin/check line 685.
error.log.22.gz:[Wed Jul 18 08:19:19 2007] check: Unrecognized escape \H passed
through at /usr/lib/cgi-bin/check line 1025.
and, sure enough, I find lines 1023-1025 in sub report_valid saying:
# Modification in Debian package: to make the package independent,
# badges can be specified as being relative to the home page.
$cfg->{Badge}->{URI} =~ s|^\HOMEPAGE/|$CFG->{'Home Page'}|;
from which I'm strongly inclined to suspect that you meant
$cfg->{Badge}->{URI} =~ s|^\$HOMEPAGE/|$CFG->{'Home Page'}|;
(and that HOMEPAGE support probably isn't working !)
The error at line 685 (after comment "Tell onsgmls about the SGML
Library.") presumably means some field of $CFG->{Paths}->{SGML}-> is
unset, but I can't immediately see where that gets its values, so
haven't investigated further.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (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 w3c-markup-validator depends on:
ii apache22.2.3-4+etch1 Next generation, scalable, extenda
ii apache2-mpm-worker [httpd] 2.2.3-4+etch1 High speed threaded model for Apac
ii debconf [debconf-2.0] 1.5.11Debian configuration management sy
ii libconfig-general-perl 2.31-3Generic Configuration Module
ii libhtml-parser-perl3.55-1A collection of modules that parse
ii libhtml-template-perl 2.8-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-2Manipulates and accesses URI strin
ii libwww-perl5.805-1 WWW client/server library for Perl
ii opensp 1.5.2-3 OpenJade group's SGML parsing tool
ii perl 5.8.8-7etch1 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 w3c-linkchecker4.3-1 W3C Link Checker
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: Apache-SSL
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436704: java-gcj-compat: Undeclared (and unresolved) dependency on libstdc++-libc6.1-1.so.2
Package: java-gcj-compat
Version: 1.0.65-10
Severity: grave
Justification: renders package unusable
$ cd /usr/opt/j2sdk1.4.0_01/jre/lib/i386/client
$ ldd libjvm.so
libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb7aae000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7aaa000)
libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7a92000)
libstdc++-libc6.1-1.so.2 => not found
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7a5d000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7916000)
/lib/ld-linux.so.2 (0x8000)
Consequently, libjvm.so can't be loaded (I have
/usr/lib/libstdc++-libc6.2-2.{so,a}.3
on my lenny system, supplied by package libstdc++2.10-glibc2.2).
Since ../libawt.so and ../libjava.so depend on libjvm.so, they also
can't be loaded. This severely limits the utility of this JRE.
The java-gcj-compat package doesn't mention any dependency on any
libstdc++ variant. It needs to Depend on the variant it's built with
- and be built with a modern enough version that the dependency can be
met !
I really want to be able to list java-gcj-compat among the JREs that
Opera Suggests:, but this currently amounts to a fatal bug with it ...
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.21-2-686 (SMP w/2 CPU cores)
Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages java-gcj-compat depends on:
ii fastjar 2:0.95-1 Jar creation utility
ii gij-4.1 4.1.1-20 The GNU Java bytecode interpreter
ii java-common 0.26 Base of all Java packages
ii libgcj-common 1:4.1.1-21 Java runtime library (common files
ii libgcj7-jar 4.1.1-20 Java runtime library for use with
java-gcj-compat recommends no packages.
-- 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(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 ii
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:
struct Base { virtual const int stupid() = 0; };
struct Derived : public Base { virtual int stupid() { return 1; } };
and run the compiler on it, with warnings. I get:
$ 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
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 (no description available)
ii gcc-4.3-doc 4.3.2.nf1-1 documentation for the GNU compiler
pn libstdc++6-4.3-dbg (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366695: xserver-xorg-video-i810: Depends on unavailable xserver-xorg-core on etch.
Package: xserver-xorg-video-i810 Version: 1:1.5.1.0-2 Severity: grave Justification: renders package unusable Due to a power outage, I had to re-boot my etch box after some months, during which I'd updated it, so am now using the modern xserver-xorg-* package fragments, where I was using a more monolithic xorg when last I booted. When re-booted, I got no xdm up. Initially, this was because /etc/init.d/xdm referred to /usr/bin/X11/xdm, which no longer exists. When I amended that, I still got failure, since /etc/X11/default-display-manager had also survived, and referred to the same xdm. Reverting the prior amend and inserting a symlink in /usr/X11R6/bin/ solved those problems, so that xdm at least *tried* to start up. It still failed, now saying that it couldn't make sense of the hardware (I've had a very grim six hours since then, of trying to get my machine back in an X-compatible state, without success, so don't remember the exact wording; having now reverted to as close as I can remember to that state, I lack the /usr/bin/X that xdm wants). Then I remembered that xorg had recently gone into many-package form, so went looking for a suitable xserver-xorg-video-* for the hardware reported to me by lspci: :00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Express Chipset Family Graphics Controller (rev 04) It looks like the package I want is xserver-xorg-video-i810; but, when I tried to install that, it was broken, because it depends on xserver-xorg-core, which is not present in etch. So I can't actually install this package to find out whether it really is what I need. There seems little point making a package available to testing when it depends on a package unavailable to testing. Carving up a package into lots of little packages is a cool move, as long as all hardware set-ups whose support has moved into one of those packages are still catered to by a set-up on the branch (in this case testing) on which the big package provided support before its demise. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686-smp Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366695: xserver-xorg-video-i810: Depends on unavailable xserver-xorg-core on etch.
> Remove the individual i810 driver package, it wouldn't install, so that was be a no-op ! > the xserver-xorg package in testing includes the driver you want. when I dpkg-reconfigure it, it starts by asking whether I want to let it autodetect: and says that it can't recognize what it finds. > If it doesn't support your card, then use the vesa driver duly configured to do so. This initially failed, for want of the X and then xrdb binaries in /usr/bin; they're in /usr/bin/X11/ (and dpkg -S doesn't know of a package that owns X), so I hard-linked them and my X server starts up fine. That sufficed to get xdm started (yay), though I notice it starts about seven processes, each with parent PID 1, each allegedly running the xdm binary. Odd, but working - thank you for your guidance. > Second, the xdm bug is an actual bug in the dependencies that will only > affect testing until the rest of X11R7 migrates. For that you'll just have > to be patient. Use an alternate *dm or just use startx for the time being. or cope with some bodgery (see above). > We're working hard on getting all the pieces in to testing, I'd noticed - lots of interesting change has been going on when I update. Good luck getting it all to work. > for now every part of the 6.9 release except for xdm will work just > as it always has. OK, I'll remember to treat xdm with care, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366695: xserver-xorg-video-i810: Depends on unavailable xserver-xorg-core on etch.
> http://packages.debian.org/xserver-xorg-core Yes, I know that package is not available on testing. That's why I submitted the bug against xserver-xorg-video-i810, not against xserver-xorg-core. http://packages.debian.org/xserver-xorg-video-i810 says it's available on testing. It * appears to be my best bet for support for my video card, * depends on xserver-xorg-core and, thus, * is broken, on testing. Before the xserver-xorg package split off its per-device packages, it supported my video card on testing. Now, testing does not support that video card. I am suddenly without X server. I'm hoping testing shall support my video card, one way or another, by the time I get back from the fortnight's holiday that I needed to get a bunch of stuff done before, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366695: xserver-xorg-video-i810: Depends on unavailable xserver-xorg-core on etch.
> This is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365134 >> It still failed, now saying that it couldn't make sense of the >> hardware ... Then I remembered that xorg had recently gone into >> many-package form, so went looking for a suitable >> xserver-xorg-video-* for the hardware reported to me by lspci: > xserver-xorg 6.9.0.dfsg.1-6 is still in testing, so you do not need > xserver-xorg-video-i810. Yup, once I'd worked round the xdm problems, it does indeed turn out that the xserver-xorg was OK - I just got mislead by the initial xdm problems into thinking the problem was in the server. Feel free to kill this bug as misguided ... Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#377635: coreutils: man install sends me to non-extant (in etch) info pages
Package: coreutils Version: 5.96-3 Severity: important The man page for install(1) tells me that: The full documentation for install is maintained as a Texinfo manual. If the info and install programs are properly installed at your site, the command info install should give you access to the complete manual. Inconveniently, when I type the command specified, info falls back on man pages and shows me the same man page. Thankfully I have working recursion-breaking heuristics to avoid infinite loops. When I look for install in emacs' C-h i buffer, it fails likewise. I inferred that install's info pages were missing, hence that I needed to find out its package name and add -doc. I asked type install and dkpk -S /usr/bin/install so found that install is provided by coreutils. More users shall be able to get more out of Debian when having to infer and ask as above gets less common. I believe I've had similar trouble with other programs provided by the coreutils module. There being no coreutils-doc package (at least, not in etch, whose version of coreutils I'm using), I tried asking info about coreutils (both in emacs and in info) and discover that this works and even provides an entry for install. I can thus amend the above command to info coreutils install to get all the way there in one command. I recommend that the man page of install be amended to supply this command-line, which works, rather than the one it presently supplies - which doesn't work. I believe that there are other man pages for commands in coreutils to which the same problem applies: presumably the same solution is apt to work for these, too. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686-smp Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Versions of packages coreutils depends on: ii libacl1 2.2.39-1 Access control list shared library ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libselinux1 1.30-1 SELinux shared libraries coreutils recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#377635: coreutils: man install sends me to non-extant (in etch) info pages
>>Severity: important > That's a bit of bug inflation. when I began writing it, it was "documentation is not available, making program unusable" - by the time I'd finished writing the details I'd checked enough to find my way round it: but forgot to revise the severity - sorry. > dpkg-installinfo is broken, has been for a long time. I can't fix that. ah. so this is really a duplicate of an already-reported bug in that ? > info coreutils program isn't a reliable fix either. That's a pity - why not ? Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#377635: coreutils: man install sends me to non-extant (in etch) info pages
>> > info coreutils program isn't a reliable fix either. >> That's a pity - why not ? > Let's say you want info on the 'pr' command. So you try: > info coreutils pr > But instead of the "pr invocation" page you get the "Printing text" > page instead. ah - I see. It may still be worth adjusting the man pages for programs (such as install) for which this approach *does* work. But clearly fixing the underlying problem with dpkg's info handling is the only sensible solution, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#369662: fortunes: typo in Brandeis quote: fortune -m 'mean of zeal'
Package: fortunes Version: 1:1.99.1-3 Severity: minor fortune -m 'mean of zeal' returns: (cookie) % "The greatest dangers to liberty lurk in insidious encroachment by mean of zeal, well-meaning but without understanding." -- Justice Louis O. Brandeis (Olmstead vs. United States) % from /usr/share/games/fortunes/cookie I am fairly certain that Brandeis was actually talking about "men of zeal", albeit such as mean well but are unwittingly mean. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686-smp Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages fortunes depends on: ii fortune-mod 1:1.99.1-3 provides fortune cookies on demand ii fortunes-min 1:1.99.1-3 Data files containing fortune cook fortunes recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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: 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. (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#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 host nis 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#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#530535: apache2: Apache fails to follow symlinks via other symlinks
I forgot to mention: the error.log reports the error as Symbolic link not allowed or link target not accessible: /disk/home/eddy/whorlweb/edoc 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#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 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. 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#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): ln -s ../work .w ln -s .w/mine/toys code 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, mv code edoc ln -s ../work/mine/toys code 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, $ 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 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#432847: /usr/bin/xload: xload needs a way to limit range of values it can display
Package: x11-apps Version: 0.1 Severity: wishlist File: /usr/bin/xload The vertical scale of xload adjusts to accommodate the highest load level. It has horizontal lines to indicate the vertical scale. A high enough load shall cause these lines to be so closely spaced that there is no space between them: the entire display is then white (I have reverse video set, so the background is black and scale lines are white) and I can no longer see the load varying, on account of the lines. Modern machines can endure quite immense loads, so this problem can readilly arise (I routinely get it when running make -j -l 12, if some of the processes make first fires off do very vigorous things once started). The machine is happy, but xload becomes useless ! If the load has a transient spike, the vertical scale adapts to let the spike's top be displayed: if the spike is high enough, xload becomes useless until the spike has scrolled off the left hand end - or until I kill it and start a fresh xload, losing all the data that was on display for the prior four hours (yes, xload is almost the full width of my screen). Note that setting the foreground colour of xload doesn't help: the grid lines are drawn on top of the load data, so would hide it. This could readilly enough be remedied by providing a command-line option, --clip-at=n, to tell xload to not try to display any load level above n. More fancy solutions are possible. It may be sufficient simply to draw the load data on top of the scale lines; then -foreground=red would suffice to make the load graph's shape visible, even when the scale lines are so closely packed as to form a featureless background (giving no indication of scale - other than "OMG that's high !"). If the vertical scale is huge enough that the horizontal lines use up more than (say) half of the pixels available for vertical height (at this point, it's possible - but getting hard - to read the display), xload could drop the granularity of its vertical scale; only display one in 10 of the horizontal lines, for example. Naturally, this would require some way to indicate that the scale has been adjusted; e.g. the load-level difference between horizontal lines could be displayed in the top left corner of the chart. Of course, the value of 10 (the base of the number system in use) could be controlled by a command-line parameter; or it could just be hard-coded to ten or 0x10. Alternatively, the horizontal lines could be dashed, with multiples of 10 using longer dashes (and multiples of 100 using longer ones yet). The dashes for adjacent values should be staggered, so that they don't simply from a solid vertical column (hiding data in the interval it spans). -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-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.1.1-15 The GNU C preprocessor (cpp) ii libc6 2.5-9+b1 GNU C Library: Shared libraries ii libfontconfig12.4.2-1.2 generic font configuration library ii libice6 1:1.0.3-2 X11 Inter-Client Exchange library ii libpng12-01.2.15~beta5-2 PNG library - runtime ii libsm62:1.0.3-1 X11 Session Management library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxaw7 1:1.0.3-3 X11 Athena Widget library ii libxcursor1 1:1.1.8-2 X cursor management library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar ii libxft2 2.1.12-2 FreeType-based font drawing librar ii libxkbfile1 1:1.0.4-1 X11 keyboard file manipulation lib ii libxmu6 1:1.0.3-1 X11 miscellaneous utility library ii libxmuu1 1:1.0.3-1 X11 miscellaneous micro-utility li ii libxrender1 1:0.9.2-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 x11-apps recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#432847: /usr/bin/xload: xload needs a way to limit range of values it can display
> This could readilly enough be remedied by providing a command-line > option, --clip-at=n, to tell xload to not try to display any load > level above n. More fancy solutions are possible. closer inspection of the man page suggests this could be implemented as an optional second value for -scale: -scale integer[,integer] This option controls the number of tick marks in the histogram, where one division represents one load average point. If the load goes above the first number, xload shall create more divisions, but it shall never use fewer than this number. The default is 1. If the second number is supplied, xload shall not create more than this many divisions; if load goes above this value, the histogram shall be clipped. The default is to always have enough divisions to display the highest load seen during the displayed time interval. or similar. I also notice that the man page says: -jumpscroll number of pixels The number of pixels to shift the graph to the left when the graph reaches the right edge of the window. The default value is 1/2 the width of the current window. Smooth scrolling can be achieved by setting it to 1. I do not pass this argument, but get smooth scrolling as if I were setting it to 1. I have never seen the graph shift to the right by half the width of the window. Given that I like the smooth scrolling effect, I'd argue for changing the documentation to match the observed behaviour ;-> Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#433113: sun-java5-plugin: package depends on explicit |-list of browsers instead of web-browser virtual package
Package: sun-java5-plugin Version: 1.5.0-10-3 I'm using the Opera web browser. Although sun-java5-plugin doesn't overtly say that it supports all NPP-compatible browsers, I'm guessing it does from the list of browsers it Depends: on. However, that list doesn't inlucde Opera, so I'm obliged to install some other web browser just to get a plugin to find out if it works with Opera ... It would in any case be simpler to Depend on web-browser, the virtual package for all web browsers (if only to save you the need to maintain an ever-growing, always out-of-date list of web browsers); and, arguably, it may be worth only Recommending it, or even Suggesting it, since applications which are not web browsers - e.g. authoring tools - could as readilly make use of it. There would also be some sense to having virtual packages for plugins, such as java-npp-plugin, flash-npp-plugin, etc., which are Provided by the particular plugins, so that browsers can Recommend or Suggest the virtual package for each plugin, rather than an |-list of the known implementations of each plugin. The java-npp-plugin would then Provide the java-plugin virtual package, and likewise for others; similarly, a genuinely xul-dependant plugin could Provide *-xul-plugin, which would Provide *-plugin; mutatis mutandis, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#433113: Acknowledgement (sun-java5-plugin: package depends on explicit |-list of browsers instead of web-browser virtual package)
minor correction to previous: for "web-browser" read "www-browser". -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421615: gimp-help-no: Package description claims it's Korean; but it's actually Norwegian !
Package: gimp-help-no Severity: minor Tags: l10n The packages gimp-help-ko and gimp-help-no were released in parallel. The description for -no is a duplicate of the one for -ko; which overtly says it's a Korean localisation. The -no one needs s/Korean/Norwegian/ ! I should also note that the -no package description should probably give some indication of whether it's a nynorsk, nn, or bokmaal, nb, localisation. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.18-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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#422651: AuthPAM parts not needed
I found that a .htaccess of form AuthType Basic AuthName "Group xxx only" AuthGROUP_Enabled on require group xxx AuthBasicAuthoritative off worked fine, without needing the AuthPAM directives given in this patch. It was, however, necessary to include the last line (which is what had me stumped). The AuthPAM bits might be needed if you have mod-auth-pam enabled, though, Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#422651: libapache2-mod-auth-sys-group: lack of documentation on authorization for group
... but now this has stopped working, without any recent config change (but maybe apache got updated in etch). Since it failed, I've tried adding the PAM config (and removing the AuthGROUP_Enabled line) but this didn't help any :-( Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445104: xscreensaver: aborts X session if I let the log-back-in screen time out while switched to a virtual console
Package: xscreensaver Version: 5.03-2 Severity: critical Justification: causes serious data loss Ever since switching to a Dell flat-screen (2007FPb - I was previously using a CRT) I've experienced a problem where: * I lock my X session, * I switch to a virtual console (Ctrl-Alt-F1, etc.), which (because I touched the keyboard) provokes the password dialog to come up, * I don't switch back to the X display before the password dialog times out, * when I *do* switch back to the X display, my X session dies. Note that the X session is still up and running *before* I Ctrl+Alt+F7 back to try to resume it (as revealed by ps in my virtual console, and by the time-stamp on my .xsession-error). My .xsession-errors ends in: X connection to :0.0 broken (explicit kill or server shutdown). Gdk-ERROR **: Fatal IO error 104 (Connection reset by peer) on X server :0.0. X connection to :0.0 broken (explicit kill or server shutdown). Xlib: connection to ":0.0" refused by server Xlib: Invalid XDM-AUTHORIZATION-1 key (failed key comparison) Error: Can't open display Exiting from getDisplay.cpp at line 47 If I hold Ctrl+Alt until the blue time-out bar has all gone away, in the password dialog, and hit F5 while the "authentication failed" dialog is displayed, the X session dies. Holding Ctrl+Alt a bit longer, until even this dialog has gone, *then* hitting F5 changes console for me, without hurting the X session. Leaving the X session unlocked, switching to a virtual console and remaining there until the screen-saver locks the screen due to its usual time-outs doesn't provoke the problem. If I lock my X session by selecting the relevant root-window menu item and quickly (before the lock has come into force, so that the password dialog doesn't get activated) Ctrl+Alt+F5 away, the X session survives. Usually, xdm manages to start a new X session after mine has died, but not always. When it doesn't, Ctrl+Alt+F7 shows me INIT: version 2.86 reloading Naturally, applications that I've left active in my X session get hosed by the X session's death, taking with them any unsaved data; hence the "data loss" category for this bug. It's not clear to me which of several pieces of software is the culprit. I'm using fvwm as my window manager and xscreensaver as screen saver. The root window within fvwm is displaying xplanet. The virtual consoles run getty; the X session is managed by xdm. However, xscreensaver's password prompt seems pivotal. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.21-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.20.0-1 The ATK accessibility toolkit ii libc6 2.6.1-1+b1GNU C Library: Shared libraries ii libcairo2 1.4.10-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.2-1.2 generic font configuration library ii libglade2-01:2.6.2-1 library to load .glade files at ru ii libglib2.0-0 2.14.0-2 The GLib library of C routines ii libgtk2.0-02.10.13-1 The GTK+ graphical user interface ii libice62:1.0.4-1 X11 Inter-Client Exchange library ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libpam0g 0.99.7.1-4Pluggable Authentication Modules l ii libpango1.0-0 1.18.2-1 Layout and rendering of internatio ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxcursor11:1.1.9-1 X cursor management library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2 X11 miscellaneous 'fixes' extensio ii libxi6 2:1.1.3-1 X11 Input extension library ii libxinerama1 1:1.0.2-1 X11 Xinerama extension library ii libxml22.6.30.dfsg-2 GNOME XML library ii libxmu61:1.0.3-1 X11 miscellaneous utility library ii libxpm41:3.5.7-1 X11 pixmap library ii libxrandr2 2:1.2.2-1 X11 RandR extension library ii libxrender11:0.9.4-1 X Rendering Extension client libra ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii libxxf86misc1 1:1.0.1-2 X11 XFree86 miscellaneous extensio ii libxxf86vm11:1.0.1-2 X11 XFree86 video mode extension l ii netpbm 2:10.0-11 Graphics conversion tools Versions of packages xscreensaver recommends: pn libjpeg-progs (no description avai
Bug#445104: xscreensaver: aborts X session if I let the log-back-in screen time out while switched to a virtual console
> Sounds like X is dying on vt switch. I guess so. > I assume this doesn't happen when xscreensaver isn't running? Indeed. > If X is indeed crashing, can you attach your X log after the crash? > (should be /var/log/Xorg.0.log, or /var/log/Xorg.0.log.old after X has > been restarted) In the interests of brevity, the follows the diff between my current log and the last time I exercised the crash in the course of reproducing the bug. If you want the whole log I can send that, but I notice this does indeed include a backtrace ... Eddy. -- diff -bu /var/log/Xorg.0.log.old /var/log/Xorg.0.log --- /var/log/Xorg.0.log.old 2007-10-03 11:13:27.0 +0200 +++ /var/log/Xorg.0.log 2007-10-04 10:55:29.0 +0200 @@ -11,7 +11,7 @@ Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. -(==) Log file: "/var/log/Xorg.0.log", Time: Wed Oct 3 10:51:22 2007 +(==) Log file: "/var/log/Xorg.0.log", Time: Wed Oct 3 11:13:28 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) @@ -629,7 +629,7 @@ (II) intel(0): [drm] DRM interface version 1.3 (II) intel(0): [drm] created "i915" driver at busid "pci::00:02.0" (II) intel(0): [drm] added 8192 byte SAREA at 0xf89fc000 -(II) intel(0): [drm] mapped SAREA 0xf89fc000 to 0xb7bee000 +(II) intel(0): [drm] mapped SAREA 0xf89fc000 to 0xb7b38000 (II) intel(0): [drm] framebuffer handle = 0xc004 (II) intel(0): [drm] added 1 reserved context for kernel (II) intel(0): Unable to use TTM-based memory manager with DRM version 1.6 @@ -755,7 +755,7 @@ (II) intel(0): xf86UnbindGARTMemory: unbind key 2 (II) intel(0): xf86UnbindGARTMemory: unbind key 3 (II) intel(0): xf86UnbindGARTMemory: unbind key 4 -AUDIT: Wed Oct 3 10:53:07 2007: 19477 X: client 3 rejected from local host (uid 742) +AUDIT: Wed Oct 3 11:13:37 2007: 20319 X: client 3 rejected from local host (uid 742) Auth name: XDM-AUTHORIZATION-1 ID: -1 (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) No APM support in BIOS or kernel @@ -773,35 +773,15 @@ (II) intel(0): Output VGA is connected to pipe A (II) intel(0): [drm] dma control initialized, using IRQ 16 (II) Logitech Mouse: ps2EnableDataReporting: succeeded -(II) AIGLX: Suspending AIGLX clients for VT switch -(II) intel(0): xf86UnbindGARTMemory: unbind key 0 -(II) intel(0): xf86UnbindGARTMemory: unbind key 1 -(II) intel(0): xf86UnbindGARTMemory: unbind key 2 -(II) intel(0): xf86UnbindGARTMemory: unbind key 3 -(II) intel(0): xf86UnbindGARTMemory: unbind key 4 -AUDIT: Wed Oct 3 10:54:42 2007: 19477 X: client 3 rejected from local host (uid 742) - Auth name: XDM-AUTHORIZATION-1 ID: -1 -(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) -(II) No APM support in BIOS or kernel -(II) AIGLX: Resuming AIGLX clients after VT switch -(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x007bf000 (pgoffset 1983) -(II) intel(0): xf86BindGARTMemory: bind key 1 at 0x03a38000 (pgoffset 14904) -(II) intel(0): xf86BindGARTMemory: bind key 2 at 0x0400 (pgoffset 16384) -(II) intel(0): xf86BindGARTMemory: bind key 3 at 0x0500 (pgoffset 20480) -(II) intel(0): xf86BindGARTMemory: bind key 4 at 0x0800 (pgoffset 32768) -(II) intel(0): Output configuration: -(II) intel(0): Pipe A is on -(II) intel(0): Display plane A is now enabled and connected to pipe A. -(II) intel(0): Pipe B is off -(II) intel(0): Display plane B is now disabled and connected to pipe B. -(II) intel(0): Output VGA is connected to pipe A -(II) intel(0): [drm] dma control initialized, using IRQ 16 -(II) Logitech Mouse: ps2EnableDataReporting: succeeded -FreeType: couldn't open face /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/DejaVuSansMono-Roman.ttf: 1 -FreeType: couldn't open face /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/DejaVuSerif-Roman.ttf: 1 (II) 3rd Button detected: disabling emulate3Button FreeType: couldn't open face /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/DejaVuSansMono-Roman.ttf: 1 FreeType: couldn't open face /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType/DejaVuSerif-Roman.ttf: 1 +SetGrabKeysState - disabled +SetGrabKeysState - enabled +SetGrabKeysState - disabled +SetGrabKeysState - enabled +SetGrabKeysState - disabled +SetGrabKeysState - enabled (II) AIGLX: Suspending AIGLX clients for VT switch (II) intel(0): xf86UnbindGARTMemory: unbind key 0 (II) intel(0): xf86UnbindGARTMemory: unbind key 1 @@ -824,115 +804,5 @@ (II) intel(0): Output VGA is connected to pipe A (II) intel(0): [drm] dma control initialized, using IRQ 16 (II) Logitech Mouse: ps2EnableDataReporting: succeeded -(II) AIGLX: Suspending AIGLX clients for VT switch -(II) intel(0): xf86UnbindGARTMemory: unbind key 0 -(II) intel(0): xf86UnbindGARTMemory: unbind key 1 -(II) intel(0): xf86Unbin
Bug#423014: console's last three lines become inaccessible once xdm start up
Incidentally, this bug has become unreproducible since I switched from using the old CRT to using a shiny new flat screen. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#445104: xscreensaver: aborts X session if I let the log-back-in screen time out while switched to a virtual console
> Thanks, I'm reassigning this bug to the X server. The complete log and > your xorg.conf would be useful. OK. X Window System Version 1.3.0 Release Date: 19 April 2007 X Protocol Version 11, Revision 0, Release 1.3 Build Operating System: Linux Debian (xorg-server 2:1.3.0.0.dfsg-12) Current Operating System: Linux whorl 2.6.21-2-686 #1 SMP Wed Jul 11 03:53:02 UTC 2007 i686 Build Date: 09 August 2007 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Oct 3 10:51:22 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Dell 2007FPb" (**) | |-->Device "Intel Corporation 82915G/GV/910GL Integrated Graphics Controller" (**) |-->Input Device "IBM-UK Keyboard" (**) |-->Input Device "Logitech Mouse" (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType (==) RgbPath set to "/etc/X11/rgb" (==) ModulePath set to "/usr/lib/xorg/modules" (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) No APM support in BIOS or kernel (II) Loader magic: 0x81e5140 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 1.2 X.Org XInput driver : 0.7 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "pcidata" (II) Loading /usr/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.2 (++) using VT number 7 (WW) xf86OpenConsole: setpgid failed: Operation not permitted (WW) xf86OpenConsole: setsid failed: Operation not permitted (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,2580 card 1028,0179 rev 04 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,2581 card , rev 04 class 06,04,00 hdr 01 (II) PCI: 00:02:0: chip 8086,2582 card 1028,0179 rev 04 class 03,00,00 hdr 80 (II) PCI: 00:02:1: chip 8086,2782 card 1028,0179 rev 04 class 03,80,00 hdr 80 (II) PCI: 00:1c:0: chip 8086,2660 card , rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1c:1: chip 8086,2662 card , rev 03 class 06,04,00 hdr 81 (II) PCI: 00:1d:0: chip 8086,2658 card 1028,0179 rev 03 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2659 card 1028,0179 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,265a card 1028,0179 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:3: chip 8086,265b card 1028,0179 rev 03 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,265c card 1028,0179 rev 03 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,244e card , rev d3 class 06,04,01 hdr 81 (II) PCI: 00:1e:2: chip 8086,266e card 1028,0179 rev 03 class 04,01,00 hdr 00 (II) PCI: 00:1f:0: chip 8086,2640 card , rev 03 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,266f card 1028,0179 rev 03 class 01,01,8a hdr 00 (II) PCI: 00:1f:2: chip 8086,2651 card 1028,0179 rev 03 class 01,01,8f hdr 00 (II) PCI: 00:1f:3: chip 8086,266a card 1028,0179 rev 03 class 0c,05,00 hdr 00 (II) PCI: 02:00:0: chip 14e4,1677 card 1028,0179 rev 01 class 02,00,00 hdr 00 (II) PCI: End of PCI scan (II) Intel Bridge workaround enabled (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,4), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0002 (VGA_EN is cleared) (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xdfd0 - 0xdfdf (0x10) MX[B] (II) PCI-to-PCI bridge: (II) Bus 2: bridge is at (0:28:0), (0,2,2), BCTRL: 0x0002 (VGA_EN is cleared) (II) Bus 2 non-prefetchable memory range: [0] -1 0 0xdfc0 - 0xdfcf (0x10) MX[B] (II) PCI-to-PCI bridge: (II) Bus 3: bridge is at (0:28:1), (0,3,3), BCTRL: 0x0002 (VGA_EN is cleared) (II) Bus 3 non-prefetchable memory range: [0] -1 0 0xdfb0 - 0xdfbf (0x10) MX[B] (II) Subtractive PCI-to-PCI bridge: (II) Bus 4: bridge is at (0:30:0), (0,4,4), BCTRL: 0x0002 (VGA_
Bug#423014: console's last three lines become inaccessible once xdm start up
> Strange, I am not sure what to do with this bug then. Understandable. > Will you have a chance to try the old CRT again? No - it's been junked (see below for why), that's why I replaced it. This might justify closing the bug as "hardware fault". > Are you sure the bug disappeared because you switched the display > and not because of an upgrade at the same time? The bug persisted through an upgrade shortly before, which broke X support for the old CRT; and we (a sysadmin and I) were unable to work out what was the matter with it; but a replacement display workd fine, so we blamed the CRT. However, in investigating that, we were routinely using the console, which *was* missing its bottom three lines. So I don't believe the disappearance was due to the software upgrade. Eddy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 (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".
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(# 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(# "~/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)
hmm ... seems to implicate rmime a lot.
So I commented out
(add-hook 'rmail-show-message-hook 'rmime-format)
(add-hook 'rmail-edit-mode-hook'rmime-cancel)
(autoload 'rmime-format "rmime" "" nil)
from my config and tried again, getting:
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(# 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(# "~/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)
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#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#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
