Bug#963804: Bug in debootstrap/functions
Package: debootstrap
Version: 1.0.123
There are three lines similar to this
for c in ${COMPONENTS:-$(echo ${USE_COMPONENTS} | tr '|' ' ')}; do
This triggers an error during stage 2 when trying to create a chroot
for potato-i386
/debootstrap/debootstrap: /debootstrap/functions: line 1536: syntax error near
unexpected token `|'
Those lines should be patched like this:
for c in ${COMPONENTS:-$(echo "${USE_COMPONENTS}" | tr '|' ' ')}; do
If I do so the image is correctly created.
--
Rob. (Robert de Bath )
<http://www.debath.co.uk/>
Bug#890124: Arithmetic Expansion should do Parameter Expansion
Package: posh Version: 0.13.1 http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_04 "The shell shall expand all tokens in the expression for parameter expansion, command substitution, and quote removal." Script: #!/bin/posh if (eval 'P=1 && : $((M$P=3)) && Q=500 && : $((M$Q+=1)) && : $((M$P+=1)) && [ $((M$P)) = 4 -a $((M$Q)) = 1 ]' ) 2>/dev/null then : else echo 'ERROR: The shell must be POSIX compatible' >&2 exit 1 fi echo The shell is working correctly. Expected result: The shell is working correctly. Actual result: ERROR: The shell must be POSIX compatible -- Rob. (Robert de Bath <robert$ @ debath.co.uk>) <http://www.debath.co.uk/>
Bug#861089: Improve Handling of certificates for Pound [PATCH]
Package: pound
Version: 2.7-1.3
Hi everyone,
This patch allows Pound to present ECDHA certificates to clients that
can use them while still presenting RSA certificates to older clients.
Robert de Bath <robert$@debath.co.uk>
Index: pound-2.7/config.c
===
This patch alters the way the "Cert" loads certificates and keys.
If the Common Name on the certificate is distinct from those on other
ones the operation is unchanged. However, if the Common Name on this
certificate matches one used on a previous certificate this one will
be loaded into the same SSL context as the previous one. The result is
that if you load two (or three) certificates will different signature
algorithms all the OpenSSL ciphers that require any of the loaded
algorithms will be available to communicate with the client.
This allows ECDHA certificates to be presented to clients that can use
them while still presenting RSA certificates to older clients.
--- pound-2.7.orig/config.c 2017-04-22 18:42:23.412469733 +0100
+++ pound-2.7/config.c 2017-04-22 18:43:16.020025597 +0100
@@ -1041,50 +1041,72 @@ parse_HTTPS(void)
#ifdef SSL_CTRL_SET_TLSEXT_SERVERNAME_CB
/* we have support for SNI */
FILE*fcert;
-charserver_name[MAXBUF], *cp;
+charserver_name[MAXBUF], *cp, *server_cname;
X509*x509;
+ regmatch_t CN_matches[2];
+ int extra_cert = 0;
if(has_other)
conf_err("Cert directives MUST precede other SSL-specific
directives - aborted");
+
+lin[matches[1].rm_eo] = '\0';
+if((fcert = fopen(lin + matches[1].rm_so, "r")) == NULL)
+conf_err("ListenHTTPS: could not open certificate file");
+if((x509 = PEM_read_X509(fcert, NULL, NULL, NULL)) == NULL)
+conf_err("ListenHTTPS: could not get certificate subject");
+fclose(fcert);
+memset(server_name, '\0', MAXBUF);
+X509_NAME_oneline(X509_get_subject_name(x509), server_name, MAXBUF
- 1);
+
+if(!regexec(, server_name, 2, CN_matches, 0)) {
+server_name[CN_matches[1].rm_eo] = '\0';
+if((server_cname = strdup(server_name + CN_matches[1].rm_so))
== NULL)
+conf_err("ListenHTTPS: could not set certificate
subject");
+} else
+conf_err("ListenHTTPS: could not get certificate CN");
+
if(res->ctx) {
for(pc = res->ctx; pc->next; pc = pc->next)
-;
-if((pc->next = malloc(sizeof(POUND_CTX))) == NULL)
-conf_err("ListenHTTPS new POUND_CTX: out of memory -
aborted");
-pc = pc->next;
+if (strcmp(pc->server_name, server_cname) == 0) {
+ extra_cert = 1;
+ break;
+ }
+ if (!extra_cert && strcmp(pc->server_name, server_cname) == 0)
+ extra_cert = 1;
+
+ if (!extra_cert ) {
+ if((pc->next = malloc(sizeof(POUND_CTX))) == NULL)
+ conf_err("ListenHTTPS new POUND_CTX: out of memory -
aborted");
+ pc = pc->next;
+ }
} else {
if((res->ctx = malloc(sizeof(POUND_CTX))) == NULL)
conf_err("ListenHTTPS new POUND_CTX: out of memory -
aborted");
pc = res->ctx;
}
-if((pc->ctx = SSL_CTX_new(SSLv23_server_method())) == NULL)
-conf_err("SSL_CTX_new failed - aborted");
-pc->server_name = NULL;
-pc->next = NULL;
-lin[matches[1].rm_eo] = '\0';
+
+ if (!extra_cert) {
+ if((pc->ctx = SSL_CTX_new(SSLv23_server_method())) == NULL)
+ conf_err("SSL_CTX_new failed - aborted");
+ pc->server_name = NULL;
+ pc->next = NULL;
+ }
+
if(SSL_CTX_use_certificate_chain_file(pc->ctx, lin +
matches[1].rm_so) != 1)
conf_err("SSL_CTX_use_certificate_chain_file failed -
aborted");
if(SSL_CTX_use_PrivateKey_file(pc->ctx, lin + matches[1].rm_so,
SSL_FILETYPE_PEM) != 1)
conf_err("SSL_CTX_use_PrivateKey_file failed - aborted");
if(SSL_CTX_check_private_key(pc->ctx) != 1)
conf_err("SSL_CTX_check_private_key failed - aborted");
-if((fcert = fopen(lin + matches[1].rm_so, "r")) == NULL)
-conf_err("ListenHTTPS: could not open certificate file");
-if((x509 = PEM_read_X50
Bug#846165: .../.ssh/config line 127: Bad protocol spec '1'.
Reading back, I may have been a little unclear. It's probably because the arrogance of the openssl people has always aggravated me. (For example the "none" cipher where they, basically, said eveyone else is too stupid to use it sensibily) In this instance they have made the $HOME/.ssh/config file a common configuration file between the ssh1 and openssh2 packages. But due to an overly agressive error message it cannot actually be used safely by both packages. Safely would mean that if ssh1 is NOT installed ssh does not connect to a host labeled as "Protocol 1". It does not mean that it sulks until all hints of "Protocol 1" have been removed from the config file. Safely means that if the "ssh1" package is installed it is ONLY used for connections that are EXPLICITLY labeled as "Protocol 1" as the other end may still support ssh1 or there may be a downgrade attack in progress. My personal solution to this on another OS was to create a wrapper that looked down two different config files for the two different versions. If it found the remote host in one of them it used that particular version of the connection tool. If it wasn't found the wrapper used the preferred tool. I think I eventually put the older tool into a library directory where it wasn't even on the path, it could only be used if I had actually created an entry for it. Of course, this used two independent configuration files. BTW: This was a LONG time ago, it was actually between "ssh" and "rsh". As you see the ssh people have a long history. I'm actually a bit surprised that it's taken as long as it has for them to do something like this to kill off V1, ... maybe they're getting better ... or maybe there's just more people to shout at them now. PS: Can the completely insecure ssh1 package have the "none" cipher please. ;-) -- Rob. (Robert de Bath <robert$ @ debath.co.uk>) <http://www.debath.co.uk/>
Bug#846165: .../.ssh/config line 127: Bad protocol spec '1'.
That's exactly what I want to do, I have a session in the config file for the ssh1 package. The ssh2 package breaks when it sees it. Now what I would think as a nice polite feature would be for the application that has the '/usr/bin/ssh' name to call the right version of ssh if it sees a 'bad' "protocol", "Cipher" or "Ciphers" line in an active part of the .config file. A poorer implementation would error if it's actually told to attempt an ssh1 connection. Throwing it's toys out of the pram when it's supposed to be ignoring a "Protocol 1" line is not what I would expect. -- Rob. (Robert de Bath <robert$ @ debath.co.uk>) <http://www.debath.co.uk/> On Mon, 28 Nov 2016, Russ Allbery wrote: Robert de Bath <robert$@debath.co.uk> writes: Package: ssh Version: 1:7.3p1-3 This error occurs whatever I attempt to connect to, even though the particular stanza of the config as nothing to do with the host I'm connecting to. It is obviously inefficient and much too aggressive. I obviously still have a use for v1 as there isn't an ssh v2 sufficiently portable to install on the machine in question. Per /usr/share/doc/openssh-client/NEWS.Debian.gz (which apt-listchanges would show to you automatically): openssh (1:7.1p1-2) unstable; urgency=medium OpenSSH 7.0 disables several pieces of weak, legacy, and/or unsafe cryptography. * Support for the legacy SSH version 1 protocol is disabled by default at compile time. Note that this also means that the Cipher keyword in ssh_config(5) is effectively no longer usable; use Ciphers instead for protocol 2. The openssh-client-ssh1 package includes "ssh1", "scp1", and "ssh-keygen1" binaries which you can use if you have no alternative way to connect to an outdated SSH1-only server; please contact the server administrator or system vendor in such cases and ask them to upgrade. [...] -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
Bug#846166: .../.ssh/config line 127: Bad protocol spec '1'.
Package: ssh Version: 1:7.3p1-3 This error occurs whatever I attempt to connect to, even though the particular stanza of the config as nothing to do with the host I'm connecting to. It is obviously inefficient and much too aggressive. I obviously still have a use for v1 as there isn't an ssh v2 sufficiently portable to install on the machine in question. This is the stanza at line 127. # simh vax running Ultrix 4.5 Host ultrix User robert Port 2120 HostName 127.0.0.1 AddressFamily inet HostKeyAlias=ultrix Protocol 1 Cipher blowfish -- Rob. (Robert de Bath <robert$ @ debath.co.uk>) <http://www.debath.co.uk/>
Bug#846165: .../.ssh/config line 127: Bad protocol spec '1'.
Package: ssh Version: 1:7.3p1-3 This error occurs whatever I attempt to connect to, even though the particular stanza of the config as nothing to do with the host I'm connecting to. It is obviously inefficient and much too aggressive. I obviously still have a use for v1 as there isn't an ssh v2 sufficiently portable to install on the machine in question. This is the stanza at line 127. # simh vax running Ultrix 4.5 Host ultrix User robert Port 2120 HostName 127.0.0.1 AddressFamily inet HostKeyAlias=ultrix Protocol 1 Cipher blowfish -- Rob. (Robert de Bath <robert$ @ debath.co.uk>) <http://www.debath.co.uk/>
Bug#780118: FW: Bug#780118: Unable to install to Plain machine
This problem was, as expected, due to a mis-match between the netboot.tgz
and the archives downloaded during the initial part of the installation.
The direct cause seems to be that the kernel packages may not be
compatible between patch versions and this means that it was not
possible to load the kernel module for ext4 until the netboot.tgz
archive was updated on ftp.debian.org.
This is due to the kernel package not actually having any way to manage
old versions of the package (ie delete 'expired' versions) and so the
old version was, in effect, directly overwritten by the new, incompatible,
version.
It, of course, got "fixed" once the netboot file was regenerated.
Note: For the record, I was a little unclear, but by a "plain" machine
I basically meant every machine I tried it on, two laptops and various
virtual machines. But, I had already stated the exact installer I was
using by name and SHA1.
As this, mis-feature is part of the kernel package I suggest this bug
is closed as it has been a known 'feature' of the kernel package for
a very long time.
Thankyou for your time, I wouldn't have raised this if I'd realised
before that it was a symptom of the kernel package.
--
Rob. (Robert de Bath <robert$ @ debath.co.uk>)
<http://www.debath.co.uk/>
On Tue, 5 Jul 2016, Robert de Bath wrote:
-Original Message-
From: Neil Williams [mailto:codeh...@debian.org]
Sent: 28 June 2016 12:26
To: 780...@bugs.debian.org; 780118-submit...@bugs.debian.org
Subject: Bug#780118: Unable to install to Plain machine
tag 780118 + moreinfo
thanks
On Mon, 9 Mar 2015 13:31:05 + Robert de Bath <rob...@tvisiontech.co.uk>
wrote:
Package: debian-installer
This changed over the weekend without any change to the
'debian-installer' code itself. It was working on Friday.
I GUESS the problem will be related to packages that are downloaded
during the early part of the install; probably partman-auto.
Problem:
I'm installing using the current AMD64 netboot installer.
Sha1sum:
6c27efd31f462b0954ea7ca5983ca01f633b8afa netboot.tar.gz
The disk is wiped and has no partitions. During install I selected
"Guided disk" and "Everything in one partition".
The installer creates the partitions and formats the ext4 root
partition. But is unable to mount the partition for installation of
the base system.
Rebooting and trying again does not help. There is no option to "just
use the existing ext4 partition as root" and redoing the partitions
leaves me still unable to install.
If I do an "sfdisk -R /dev/sda" on the "ALT-F2" console it claims that
the Drive is in use and will not refresh the partition table.
This looks pretty release critical to me :-(
Apologies for the delay in responding to this but there is a lack of
information in the report to be able to identify the problem.
Have you tried to reproduce this since filing the report?
How was the install run - netinst/CD/DVD, architecture, stable or testing,
version, what kind of machine? ('Plain' doesn't mean a lot.)
Numerous other tests and installs have successfully happened since the bug
report, so there is presumably something about how this test was done which
triggered the problem.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
Bug#824883: Simh/unstable is very out of date
Package: simh Version: 3.8.1-5 The currently release version is 3.9-0 and it was released Thu May 3 14:31:47 2012 -0700 It has security features like support for various methods of connecting to the network without running as root and performance features like improved CPU Idle detection on the vax emulator and floating point on the pdp-11. The current Beta of version 4.0 may also be a reasonable update. -- Rob. (Robert de Bath <robert$ @ debath.co.uk>) <http://www.debath.co.uk/>
Bug#805417: Dtach leaves signals ignored in slave process.
Package: dtach Version: 0.8-2.1 On a 'dtach'ed shell $ grep Sig /proc/self/status SigQ: 2/48068 SigPnd: SigBlk: SigIgn: 01001001 SigCgt: 00018000 $ Expected result, eg running under ssh or an XTerm: $ grep Sig /proc/self/status SigQ: 0/62981 SigPnd: SigBlk: SigIgn: SigCgt: 00018000 $ Converting the SigIgn to binary 100010001 98765432109876543210987654321 2211 Signal 1 -> SIGHUP Signal 13 -> SIGPIPE Signal 25 -> SIGXFSZ This means that processes within a pipeline will ignore the SIGPIPE that's supposed to terminate them when the process at the end of the pipeline finishes early and, if programmed correctly, they will complain about an I/O error on writing to their stdout. Resetting the signal() to SIG_DFL in the child, just before exec(), does NOT seem to work. Trapping the signals that are ignored in dtach and routing them to a no-op handler appears to give the required semantics. But the simplest solution/workaround seems to be to move the signal(SIGxxx, SIG_IGN) calls after the call to init_pty() so that the signals are not actually ignored when the child is forked off. -- Rob. (Robert de Bath <robert$ @ debath.co.uk>) <http://www.debath.co.uk/>
Bug#789536: Bug Confirmed -- Locale stupidity
Package: findutils Version: 4.4.2-9+b1 $ find Vol* -print | grep KV359-374a | wc -l 1 $ find Vol* -name \* -print | grep KV359-374a | wc -l 0 $ LC_ALL=C find Vol* -name \* -print | grep KV359-374a | wc -l 1 $ LC_ALL=C find Vol* -name \* -print | grep KV359-374a | hd 00: 56 6f 6c 20 31 35 20 56 69 6f 6c 69 6e 20 73 6f Vol 15 Violin so 10: 6e 61 74 61 73 20 28 47 72 75 6d 69 61 75 78 20 natas (Grumiaux 20: 61 2e 6f 2e 29 2f 63 64 20 31 2f 31 33 20 2d 20 a.o.)/cd 1/13 - 30: 31 32 20 56 61 72 69 61 74 69 6f 6e 73 20 69 6e 12 Variations in 40: 20 47 20 4b 56 33 35 39 2d 33 37 34 61 20 6f 6e G KV359-374a on 50: 20 5b 4c 61 20 42 65 72 67 e8 72 65 20 43 e9 6c [La Berg³re C³l 60: 69 6d e8 6e 65 5d 2e 6d 70 33 0a im³ne].mp3␊ $ The filename in question contains character sequences that are not valid utf-8, they are instead valid ISO-8859-1. With normal locale processing find joins the set of linux utilities that now act in a completely brain dead manner on a system that uses multiple character sets. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/
Bug#787137: Logjam security notes.
Package: pound Version: 2.6-6.1 I did some checking with the site: https://www.ssllabs.com/ssltest/ This highlighted a couple of issues. 1) The new Logjam issue has made 1024bit DH keys problematic. Pound will normally use an uncommon prime so it's probably not insecure, but it's not completely certain as Debian uses binary packages. 2) Pound does NOT support ECDHE based key exchange at all. OpenSSL does, but it needs more configuration to enable it. From my recent reading it appears that this is now the preferred protocol both because it's faster than a secure DHE and it's possibly more secure. Both these changes are now in the upstream version 2.7 so I'm requesting a refresh. Hopefully into stable as they are significant security issues even if they are not immediate threats. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783604: apt list segfaults
Package: apt Version: 1.0.9.8 I've just upgraded my big machine to jessie and you've replace my nice little apt script with something else ... Okay I say let's see if it's any good... $ apt d E: Invalid operation d $ apt apt 1.0.9.8 for i386 compiled on Apr 13 2015 17:23:06 Usage: apt [options] command CLI for apt. Basic commands: list - list packages based on package names search - search in package descriptions show - show package details update - update list of available packages install - install packages remove - remove packages upgrade - upgrade the system by installing/upgrading packages full-upgrade - upgrade the system by removing/installing/upgrading packages edit-sources - edit the source information file $ apt list Segmentation fault $ Well, that was disappointing ... Anything unusual you ask ... well not really I say, the only thing I have in my lists at this very moment is jessie. ... well, it's not really unusual but perhaps this ... $ uname -a Linux mayday 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 GNU/Linux $ dpkg --print-architecture i386 $ dpkg --print-foreign-architectures amd64 armhf $ No symbols of course... $ gdb --args apt list GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i586-linux-gnu. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from apt...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/apt list Listing... 1% Program received signal SIGSEGV, Segmentation fault. 0xf7e2b2cb in ?? () from /usr/lib/i386-linux-gnu/libapt-private.so.0.0 (gdb) bt #0 0xf7e2b2cb in ?? () from /usr/lib/i386-linux-gnu/libapt-private.so.0.0 #1 0xf7e1a8b4 in ?? () from /usr/lib/i386-linux-gnu/libapt-private.so.0.0 #2 0xf7e29a9d in DoList(CommandLine) () from /usr/lib/i386-linux-gnu/libapt-private.so.0.0 #3 0xf7f488fa in CommandLine::DispatchArg(CommandLine::Dispatch*, bool) () from /usr/lib/i386-linux-gnu/libapt-pkg.so.4.12 #4 0x5655680a in main () (gdb) q A debugging session is active. Inferior 1 [process 5784] will be killed. Quit anyway? (y or n) y $ -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780118: Unable to install to Plain machine
Package: debian-installer This changed over the weekend without any change to the 'debian-installer' code itself. It was working on Friday. I GUESS the problem will be related to packages that are downloaded during the early part of the install; probably partman-auto. Problem: I'm installing using the current AMD64 netboot installer. Sha1sum: 6c27efd31f462b0954ea7ca5983ca01f633b8afa netboot.tar.gz The disk is wiped and has no partitions. During install I selected Guided disk and Everything in one partition. The installer creates the partitions and formats the ext4 root partition. But is unable to mount the partition for installation of the base system. Rebooting and trying again does not help. There is no option to just use the existing ext4 partition as root and redoing the partitions leaves me still unable to install. If I do an sfdisk -R /dev/sda on the ALT-F2 console it claims that the Drive is in use and will not refresh the partition table. This looks pretty release critical to me :-( Robert de Bath TVISION TECHNOLOGY LTD Email: rdeb...@tvisiontech.co.uk Tel: + 44 (0) 1483 751 888 Mob: +44 (0) 7831 151 906 Fax: + 44 (0) 1483 768 440 Web: www.tvisiontech.co.uk Premier House, 15-19 Church Street West, Woking, Surrey GU21 6DJ The information included in this e-mail is of a confidential nature and is intended only for the addressee. If you are not the intended addressee, any disclosure, copying or distribution by you is prohibited and may be unlawful. Disclosure to any party other than the addressee, whether inadvertent or otherwise is not intended to waive privilege of confidentiality. If you have received this email in error, please forward it to supp...@tvisiontech.co.uk thank you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770423: More GCC multiarch/cross
Package: gcc Version: 4:4.6.3-8 Severity: wishlist I continue to be impressed on how far multiarch is getting but as always I wish for more... I can successfully do this: # OTHER=armhf # dpkg --add-architecture $OTHER # apt-get update # apt-get install qemu-user-binfmt hello:$OTHER -y # hello Hello, world! # file `which hello` /usr/bin/hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x4c2e100656ca58942705d1e5318f7a5a76aeea39, stripped # file `which file` /usr/bin/file: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xd6ffe91c953260380237096e219c9b80e5abb8b7, stripped # # apt-get install gcc:$OTHER libc6-dev:$OTHER make:$OTHER -y # gcc -o hi hi.c # ./hi Hi there # file ./hi ./hi: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xf4c684569858d35787e15264b18e00fd95e9b849, not stripped # It all works wonderfully, except, it replaces the native GCC. I can do the same with gcc-mingw-w64-i686, including running the resulting executable (with wine), BUT that doesn't force the current GCC to be uninstalled. So, from here it looks like surely it's easy to ... I see two possible solutions. Making the entire of GCC fully multiarch or adding matched cross compile sets. When is this likely to happen ? :-) ie: How easy is it really!! PS: Just in case: # apt-get remove --purge .\*:armhf -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768885: Performance has plummeted compared to 'wheezy'
On Tue, 18 Nov 2014, Andrea Bolognani wrote: Beef's focus is on flexibilty rather than performance: as you noticed, previous versions were not among the fastest Brainfuck interpreters ... Then perhaps you should document where it's a flexible interpreter because at the moment I'm not seeing anything. I suppose I might look for, at first, things like changing the cell size at run time: 8/16/32 bits, maybe 64, 128 or unlimited bits, maybe ONE bit for 'boolfuck'. That could lead onto variations in the front end processing; perhaps a macro language, perhaps variant syntaxes like Ook, Blub and fuckfuck. Other things could include variations on the I/O, reading from a string (Looks like you have the ability to 'fdreopen' the standard in from a file, though I'm not sure why, after all shell redirection works fine and is well known) mixing reading the program and data from the stdin, either in the traditional compile style (with a !, but obviously that's a comment character so it should be possible to disable it) or the scrablmed 'easy' style. You have EOF processing, but you missed the 'abort on EOF' variation. Things that can apply to both I/O might include ASCII vs Binary and Unicode vs Decimal, perhaps the EsoAPI you have a wishlist for. In the middle you can have optimisations, there's the short list of 'brainfuck' optimisations: RLE, SetZero, RailRunners, RailCleaners, CopyLoops, Simple (what I would call MaAd) loops and so forth. Then there's the more traditional optimisations starting with constant folding. Next there's how you run it, obviously a plain interpreter is one option. Then there are lots of languages you could convert it to ... Assembler, B, C, D, E, F#, Go, Haskell ... Perl, php, Python ... Ruby, Scheme, TCL ... Lua, Ksh, Julia ... fuckfuck ... that list is endless. Other features might relate to debugging, breakpoints, tracing, profiling, conditional breakpoints and more. Finally, there are language variations, extra commands, Forks, Files, Functions, Math and Boolean operations, Stack support, Clocks, timers and events ... this list is also endless. Some of these will be slow, or really slow, but BF is such a small language that nothing stops you including multiple interpreters; one with every bell an whistle you can think of and other smaller, much faster ones. I look forward to your next version, but, seriously, this version should be withdrawn until it's performance is better. I'd accept sort of okay, after all it'd be a lot better than now. How about a little starter ... with the rather appropriate/inappropriate name of 'deadbeef' https://gist.github.com/rdebath/a12653a3c167cf93ab6a -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768883: Impossible to run Prime.b
Package: hsbrainfuck Version: 0.1-6 The original brainfuck distribution written by Urban Müller in 1993 has a few example programs in it one of these is a prime number generator. I would expect a brainfuck interpreter to be able to run this code hsbrainfuck cannot! I would expect a reasonable brainfuck interpreter to get to 255 in less than twenty seconds. A good one will be subsecond. Download: http://aminet.net/dev/lang/brainfuck-2.lha Readme: http://aminet.net/dev/lang/brainfuck-2.readme Extracted copy of prime.b https://github.com/rdebath/Brainfuck/raw/a7caec11b54dd960ecf6172b58822997b5208bb9/src/prime.b Slightly 'modernised' version of prime.b https://github.com/rdebath/Brainfuck/raw/master/testing/Prime.b -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/
Bug#768885: Performance has plummeted compared to 'wheezy'
Package: beef
Version: 1.0.1-1
The performace of the 1.0.1 version has dropped by about 98% compared
to version 0.0.6 in wheezy. It now runs far slower than a naïve
implementation such as the 22 line 'microbf' program and clocks in
at around 2 times slower than the fastest implementations.
The 0.0.6 version was already one of the slower C based interpreters
around but the version 1.0.1 performance is well below the norm and
in the range normally occupied by interpreters written in intepreted
languages.
There is obviously a serious problem here.
$ echo 255 | time beef bfprog/prime.b
Primes up to: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73
79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173
179 181 191 193 197 199 211 223 227 229 233 239 241 251
real17m 16.24s
user17m 15.87s
sys 0m 0.00s
$ echo 255 | time bf.bin/microbf bfprog/prime.b
Primes up to: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73
79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173
179 181 191 193 197 199 211 223 227 229 233 239 241 251
real0m 50.31s
user0m 50.29s
sys 0m 0.00s
$ echo 255 | time ~/beef-0.6 bfprog/prime.b
Primes up to: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73
79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173
179 181 191 193 197 199 211 223 227 229 233 239 241 251
real0m 26.69s
user0m 26.68s
sys 0m 0.00s
$ echo 255 | time bf.bin/deadbeef bfprog/prime.b
Primes up to: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73
79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173
179 181 191 193 197 199 211 223 227 229 233 239 241 251
real0m 11.30s
user0m 11.29s
sys 0m 0.00s
$ echo 255 | time bf.bin/bfi bfprog/prime.b
Primes up to: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73
79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173
179 181 191 193 197 199 211 223 227 229 233 239 241 251
real0m 0.04s
user0m 0.04s
sys 0m 0.00s
$
Microbf.c ...
#define _POSIX_C_SOURCE 200809L
#include stdio.h
int main (int argc, char *argv[]) {
char *b=0, *p, t[65536]={0};
unsigned short m=0;
int i=0;
FILE *fp=argc1?fopen(argv[1], r):stdin;
size_t r=0;
if(!fp || getdelim(b,r,argc1?'\0':'!',fp)0)
perror(argv[1]);
else if(br0)for(p=b;*p;p++)switch(*p) {
case '': m++;break;
case '': m--;break;
case '+': t[m]++;break;
case '-': t[m]--;break;
case '.': putchar(t[m]);break;
case ',': {int c=getchar();if(c!=EOF)t[m]=c;}break;
case '[': if(t[m]==0)while((i+=(*p=='[')-(*p==']'))p[1])p++;break;
case ']': if(t[m]!=0)while((i+=(*p==']')-(*p=='['))pb)p--;break;
}
return 0;
}
--
Rob. (Robert de Bath robert$ @ debath.co.uk)
http://www.debath.co.uk/
Bug#768883: [Pkg-haskell-maintainers] Bug#768883: Impossible to run Prime.b
On Sun, 9 Nov 2014, Joachim Breitner wrote:
thanks for your report. It seems that hsbrainfuck is not maintianed by
upstream any more. Maybe we should just remove it, and patch lambdabot
not to use it.
Ah, that explains it, it's not supposed to be a standalone interpreter.
I would say that it's not really useful on it's own ('useful' as a
programmer's toy that is.) as it can't run anthing that uses the input
command or takes more than a few million BF instructions. I suspect it's
specifically designed as the reverse of a dumb text to BF converter.
ie: the most complicated it expects is something like:
+++[++-]---.+.--.++.+
.+.--.-..+...++.--...-.
So, yes, it can go as a standalone package, but it may be reasonable to
merge it into the lambdabot package as a contrib or something.
Greetings,
Joachim
--
Rob. (Robert de Bath robert$ @ debath.co.uk)
http://www.debath.co.uk/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758473: PuTTY upgrade needed.
package: pterm version: 0.63-5 http://svn.tartarus.org/sgt?view=revisionrevision=10206 The current testing version has this timer bug and I'm getting it big time with the normal Debian testing package. Please upgrade from upstream at least this fix. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708070: enable x32 support for the amd64 kernels
On Fri, 25 Jul 2014, Robert de Bath wrote:
On Fri, 25 Jul 2014, Ben Hutchings wrote:
I had an idea how to unblock this, and finally got round to trying it,
and it seems to work. That is, we build in x32 support but require a
run-time parameter to enable. So, please try the attached patch
(against the sid branch), adding syscall.x32=y to the kernel command
line.
Okay,
With the flag set the kernel boots happily and runs gcc-mx32 executables.
With the flag off ...
First (simple) thing; with the patch in the kernel tree there is no
configuration to default the x32 switch to on. Thinking ahead to when
this may be well tested, I think it'd be nice if there were a .config
option to default this patch to enabling the x32 syscalls and have a
kernel command line option to disable them in special cases.
More importantly ... this is rather ugly; I think you're going to get
complaints when ld.so segfaults.
You may want to reinstate the ENOEXEC error for the 'wrong sort' of executables.
# strace ./x
execve(./x, [./x], [/* 17 vars */]) = 0
[ Process PID=12286 runs in x32 mode. ]
brk(0) = -1 ENOSYS (Function not implemented)
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOSYS (Function not implemented)
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1
ENOSYS (Function not implemented)
writev(2, [{./x, 3}, {: , 2}, {error while loading shared libra..., 36}, {: , 2}, {, 0}, {, 0},
{cannot create cache for search p..., 35}, {: , 2}, {Cannot allocate memory, 22}, {\n, 1}], 10) = -1 ENOSYS (Function not
implemented)
exit_group(127) = ?
... exit_group resumed _exit returned!
) = ?
_exit(127) = ?
... _exit resumed _exit returned!
) = ?
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault
#
--
Rob. (Robert de Bath robert$ @ debath.co.uk)
http://www.debath.co.uk/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708070: enable x32 support for the amd64 kernels
On Sat, 26 Jul 2014, Ben Hutchings wrote: On Sat, 2014-07-26 at 10:52 +0100, Robert de Bath wrote: On Fri, 25 Jul 2014, Robert de Bath wrote: On Fri, 25 Jul 2014, Ben Hutchings wrote: What do you mean, reinstate? This is the same behaviour you get at present. Well, here's a new version that might do that. I was sure ... hmmm, segfault? ... Oh I see. I'd copied the (static) exe to a wheezy (3.2 kernel) machine; that's where it gives a 'cannot execute' error. I suppose that means it's an upstream 'bug'. Okay, the new patch is good for me. I've again tried it with the flag both ways. It runs the executables correctly when the flag is set and gives a reasonably nice (and quite specific) error when it's not. (Exec format error) I also have a i386 userspace running happily. I'd say it's good to go. Ben. -- Ben Hutchings 73.46% of all statistics are made up. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708070: enable x32 support for the amd64 kernels
On Fri, 25 Jul 2014, Ben Hutchings wrote: No, there should be no extra kernel flavours for i386 or amd64. Hmm, still not getting this. I thought the point of flavours was to split off options that, though popular, have undesirable side effects. I had an idea how to unblock this, and finally got round to trying it, and it seems to work. That is, we build in x32 support but require a run-time parameter to enable. So, please try the attached patch (against the sid branch), adding syscall.x32=y to the kernel command line. But this sounds perfectly acceptable. The general instructions for building a patched package are: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official. Oh, yes ... I remember that :-( You'll need to follow subsection 4.2.3 and apply the patch like so: patch -p1 ../x86-syscall-make-x32-syscall-support-conditional.patch quilt push Will try this shortly. Though I may have to spin up a VM to build it. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708070: enable x32 support for the amd64 kernels
On Thu, 24 Jul 2014, Ian Campbell wrote: On Thu, 2014-07-24 at 13:20 +0200, Carlos Alberto Lopez Perez wrote: I was just hit by bug https://bugs.debian.org/736659 after installing gcc-multilib and later rebuilding my initramfs. I don't think this situation of having several x32 packages on the archive (which other packages depend on) while the official debian kernel don't supports x32 at all is sustainable in the long run. Please consider enabling CONFIG_X86_X32 on 3.14 and superior. I think Ben has been pretty clear in his first reply to this bugreport about what needs to happen first. Yes, he's made it clear that such a kernel would be considered as much of a risk as the amd64 syscalls were originally. So I've been quietly waiting for them to be treated the same way ... When are we going to get a special variant of the kernel package with this attribute turned on ? -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708070: enable x32 support for the amd64 kernels
On Thu, 24 Jul 2014, Ian Campbell wrote: On Thu, 2014-07-24 at 20:22 +0100, Robert de Bath wrote: On Thu, 24 Jul 2014, Ian Campbell wrote: But that's rather different to now enabling x32 in the arch=amd64 kernel which is what #708070 is about. Likewise creating a new flavour=x86,arch=amd64 kernel. What the people responsible for the x32 arch on debian-ports do wrt an arch=x32 flavour is up to them, but that's the situation analogous to what you are referring to. Ian. I was referring to the package that's now called linux-image-3.14-1-amd64:i386 not linux-image-3.14-1-amd64:amd64 The equivalents would be approximatly linux-image-3.14-1-x32:amd64 and linux-image-3.14-1-x32:i386 not any packages in the new port. Frankly when Ben said ... those where the administrator actually wants to support x32. I took that to be him hinting that there would be such a package shortly so the administrator could make the choice easily. As that doesn't seem to be the case I decided to speak up; but now I'm wondering where you're going with this? -- To unsubscribe, send mail to 708070-unsubscr...@bugs.debian.org. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476441: Please revist this choice. AES128 vs AES256 (for gnutls)
Okay 'cited': Summary for drop dead of TDEA aka 3DES from (for example) http://www.keylength.com/en/4/ Seems to be from: http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf which explicitly drops approval of 3DES in 2030. Re: Windows XP; that's now officially no longer a problem as Windows XP is officially going out of support. The next batch of updates on the 8/4/14 will be the last. https://support.microsoft.com/gp/lifeselectindex -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476441: Please revist this choice. AES128 vs AES256 (for gnutls)
On Fri, 21 Mar 2014, Daniel Kahn Gillmor wrote: [re: GnuTLS default ciphers] On 03/21/2014 06:15 AM, Robert de Bath wrote: I notice that the distribution of RSA key sizes distributed with Debian has changed. The 2048 bit keys are still the most common but 20% of the keys are now 4096 bit with only 12% still being 1024 bit. (The 4k and 1k keys have basically changed places) which keys are you talking about here? where are these numbers from? I ran the one line script in this bug report against a current Debian testing install. $ for i in /etc/ssl/certs/*; do certtool -i $i; done|grep 'bits'|sort|uniq -c The Modulus lines are: 76 Modulus (bits 1024): 424 Modulus (bits 2048): 136 Modulus (bits 4096): Here is a modern report from ENISA, which includes a survey of a bunch of other literature: http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report in this report, AES-128 is considered roughly equivalent to RSA-3Kbit; to be equivalent to AES-256, an RSA key would need to be ~15Kbit. 4Kbit RSA is not a large margin more than AES-128 by these metrics. Very interesting, there is (not really unexpectedly) a very large spread in these results. The estimates are changing over time mostly in the same direction; but I really would be dubious about seeing a trend here. By the exact numbers of the most recent reports the strength of AES-128 is lower than RSA 4K but the error bands here seem to be so large that this is by no means certain. As the RSA key is usually the headline strength indicator for the algorithms other keysizes IMO should equal or exceed this value; AES-128 appears not to for 4k RSA keys. I agree that it's slightly below, but i think it's in the same ballpark -- if we're balancing crypto, it's roughly balanced. If anything, i'd argue that the default RSA key generation size (2432-bit RSA, which is ~112-bit equivalent) should be raised to match AES-128, e.g. certtool --sec-param high --generate-privkey. Yes, from the estimates above that may be a good idea. A 4K key would be overkill, but 3K as in their 'Future' suggestions might be right. What's more as this is often used once per connection (not per byte) your power/heat budget note isn't as applicable. Please cite your sources explicitly. Google does not return the same answers for everyone, or over time. Sorry, on rechecking this seems to be the drop dead date for 3DES; I though 3DES was already dead ... oh well. I agree we need to be conservative about our default algorithm choices, but i don't think a move to AES-256 by default is the the right place to push right now. I now agree, though I still believe that AES-128 is probably 'substantially' weaker than RSA 4K, but this is by no means certain and I have no reason to believe that the additional strength is in any way necessary. Thank you for reply on the current state of this 'bug' and the link to the updated research report. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476441: Please revist this choice. AES128 vs AES256
I notice that the distribution of RSA key sizes distributed with Debian has changed. The 2048 bit keys are still the most common but 20% of the keys are now 4096 bit with only 12% still being 1024 bit. (The 4k and 1k keys have basically changed places) Based on the (now rather dated IMO) papers you cite the 4k keysize exceeds the strength of AES-128 by a large margin. As the RSA key is usually the headline strength indicator for the algorithms other keysizes IMO should equal or exceed this value; AES-128 appears not to for 4k RSA keys. In addition a quick Google around appears to imply that at current rates AES-128 will be considered unsafe by around 2030. This is well before the 2070 estimate of the 2004 paper; perhaps because of the now widespread and cheap use of 'GPU cracker' hardware from the bitcoins events and the now common inclusion of AES hardware assists in modern CPUs. Mostly because of the 4k RSA keys I believe the default should be changed from AES-128 to AES-256 in the near future as would have (still resonably light) doubts that AES-128 will be sufficient for the predicted lifetime of the jessy release. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727765: dc is not flushing output.
Package: dc Version: 1.06.95-8 The main() function for dc has a call at the start like this: (void) setvbuf(stdout, NULL, _IOLBF, 0); This should be using unbuffered I/O not Line buffered; ie: setbuf(stdout, NULL); Reasoning: dc was designed to be called as a filter on the standard out of the bc(1) command so that the parsing of infix notations and similar could be run in a separate process to the calculation engine that is dc. As it replaces the standard output it must be possible to output prompts ie: Enter a number: that do not have a trailing newline through it. With the output of dc set to line buffered and the standard input set to the process that compiles the source language into dc code this will not happen. An alternate option would be to do a fflush() after every print like command in the same way that the stdio library has already been configured to do for the p command. This would (possibly) have the advantage of slightly better performance than single character writes. As it stands gnu-dc is broken when used in an output filter chain for a bc command or any other program doing a simlar process. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711592: Current x86 linux kernel is misconfigured.
Package: linux-image-686-pae Version: 3.2+46 On current Debian kernels the the WCHAN column for procps is NOT working. Run this command: # cat /proc/*/wchan For current Debian kernels you get all zeros, you should get something like: devtmpfsdsys_pauserescuer_threadbdi_sync_superskjournald2rescuer_threadhub_threadrescuer_threadrescuer_threadrescuer_threadscsi_error_handlerscsi_error_handlerscsi_error_handlerscsi_error_handlerscsi_ etc etc. This is all due to the configuration of the frame pointers, there are two confgurations that work, the current release format isn't one of them... Current setting -- not working: CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_WANT_FRAME_POINTERS=y # CONFIG_FRAME_POINTER is not set Working setting without frame pointers (except sched.o): # CONFIG_SCHED_OMIT_FRAME_POINTER is not set CONFIG_ARCH_WANT_FRAME_POINTERS=y # CONFIG_FRAME_POINTER is not set Working setting with frame pointers (Ubuntu): CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_WANT_FRAME_POINTERS=y CONFIG_FRAME_POINTER=y The the with frame pointers method (like Ubuntu) gives more detailed information than without frame pointers, but for me both are reasonable. The CONFIG_SCHED_OMIT_FRAME_POINTER option is rather confusing, it only changes the compile options if it's NOT set. If it's set the frame pointer option says what we get. If it's not set an extra no-omit-frame-pointer is added to the compile of kernel/sched.c; so if the kernel is compiled with frame pointers it has no effect. Note: This only applies to x86 and amd64; the not working combination where ALL frame pointers are omitted works fine on some processors, especially if it's impossible to remove the frame pointers anyway. IIRC: ARM needs frame pointers, Spark always has frame pointers. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583849: You don't need a metapackage
This message is a bit old but the problem is still current and it has a simple solution. You create your own metapackage ... The equivs package is designed for precisely this situation ... you need dpkg/apt to think you have a particular package installed but you don't want any of the contents of the package to be installed. All you do is give equivs the name and version (and any of several other things you may want) of the package you want to fake then install the fake package it generates. Problem solved. Bug 583849 FIXED. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711305: Loading i915 with modeset=1 disables display
Package: xserver-xorg-video-intel Version: 2:2.13.0-7 This is an interaction of several different packages. Firstly, as you know the X video driver needs the i915 module to be loaded to work correctly; furthermore it requires the module to attempt to set the video mode during initilisation. Without this X doesn't load the video driver. With it the driver get loaded and works correctly. But, the kernel driver is buggy, if loaded with modeset=1 it will corrupt the display controller blanking the display. Unfortunatly, udev loads all drivers it can during the boot and uses the configuration set for modprobe. Luckily, someone seems to have though of this. When udev loads modules it supplies the --use-blacklist option, whereas X calls modprobe without the --use-blacklist option. So please set the contents of the file /etc/modprobe.d/i915-kms.conf to this: ! blacklist i915 options i915 modeset=1 ! This means it isn't loaded during boot and is loaded correctly when X starts. It also means that xinit true loads the video driver correctly and fixes the screen mode after booting vga=0x305 ... bit of an overkill but never mind that :-) It seems I also need it on one machine for the radeon driver; this being so I would suggest it's a good idea for all drivers using kms and requiring the kernel to do a modeset. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698072: Hard coded ISO-8859-1
Package: xml2
Version: 0.4-3.1
The html2 executable generated from this package has a hard coded
character set declared as ISO-8859-1.
As follows:
init(sax);
if (1 == argc !strcmp(name,html2)) {
ctxt = htmlCreatePushParserCtxt(sax,NULL,NULL,0,stdin,
XML_CHAR_ENCODING_8859_1);
parseChunk = htmlParseChunk;
freeCtxt = htmlFreeParserCtxt;
do_compress_whitespace = 1;
} else if (1 == argc !strcmp(name,xml2)) {
ctxt = xmlCreatePushParserCtxt(sax,NULL,NULL,0,stdin);
parseChunk = xmlParseChunk;
freeCtxt = xmlFreeParserCtxt;
do_ignore_whitespace = 1;
IMO this should now be changed to UTF-8, ie: XML_CHAR_ENCODING_UTF8
Note: A complete solution should probably be to allow the character
set to be chosen from the command line, however, this tiny mod would
be sufficient for a simple workaround using iconv.
--
Rob. (Robert de Bath robert$ @ debath.co.uk)
http://www.debath.co.uk/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691128: Swapspace ignores memory allocated to /dev/shm [PATCH]
Package: swapspace
Version: 1.10-4
# mount -oremount,size=2000G /dev/shm
# cp -a /usr /dev/shm/usr
If you do the two commands above swapspace will NOT allocate more swapfiles and
the system will OOM.
They make the limit on the size of a tmpfs unreasonably high, then fill
it up with far too much data.
The problem appears to be that the memory usage is recorded in the item Shmem
and this isn't in your calculations. If I add it in (as in the
attached patch) the system survives.
This is with the patch ...
# cat /proc/meminfo
MemTotal:1026156 kB
MemFree: 22804 kB
Buffers: 19852 kB
Cached: 866908 kB -- Not actually freeable.
SwapCached: 5636 kB
Active: 107544 kB
Inactive: 817916 kB
Active(anon): 34136 kB
Inactive(anon): 712684 kB
Active(file): 73408 kB
Inactive(file): 105232 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal:134996 kB
HighFree: 2452 kB
LowTotal: 891160 kB
LowFree: 20352 kB
SwapTotal: 1299780 kB
SwapFree: 512740 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 33064 kB
Mapped:19664 kB
Shmem:708120 kB -- 'cause it's used by this.
Slab: 39124 kB
SReclaimable: 16056 kB
SUnreclaim:23068 kB
KernelStack:1464 kB
PageTables: 1404 kB
NFS_Unstable: 0 kB
Bounce:0 kB
WritebackTmp: 0 kB
CommitLimit: 1812856 kB
Committed_AS:1697188 kB
VmallocTotal: 122880 kB
VmallocUsed: 15760 kB
VmallocChunk: 97884 kB
HardwareCorrupted: 0 kB
HugePages_Total: 0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize: 4096 kB
DirectMap4k: 20472 kB
DirectMap4M: 884736 kB
#
--
Rob. (Robert de Bath robert$ @ debath.co.uk)
http://www.debath.co.uk/diff -urd ../old/./swapspace-1.10/src/memory.c ./swapspace-1.10/src/memory.c
--- ../old/./swapspace-1.10/src/memory.c2006-07-25 03:28:25.0
+0100
+++ ./swapspace-1.10/src/memory.c 2012-10-21 20:04:12.730266259 +0100
@@ -209,7 +209,8 @@
Writeback,
SwapCached,
SwapTotal,
- SwapFree;
+ SwapFree,
+ Shmem;
};
@@ -240,6 +241,7 @@
else if (strcmp(inf-entry+4, Free)==0) st-SwapFree = inf-value;
else if (strcmp(inf-entry+4, Cached)==0) st-SwapCached = inf-value;
}
+if (strcmp(inf-entry,Shmem)==0)st-Shmem = inf-value;
break;
case 'W':
if (strcmp(inf-entry,Writeback)==0)st-Writeback = inf-value;
@@ -310,7 +312,7 @@
/// How much cache space can we expect the system to free up?
static inline memsize_t cache_free(const struct memstate *st)
{
- const memsize_t cache = st-Cached - (st-Dirty + st-Writeback);
+ const memsize_t cache = st-Cached - (st-Dirty + st-Writeback + st-Shmem);
return (cache 0) ? (cache/100)*cache_elasticity : 0;
}
Bug#688505: MariaDB packaging.
Package: mysql-server Version: 5.5.24+dfsg-8 Severity: wishlist My very technically savvy webhost has recently switched from MySQL to MariaDB and claim it's for both technical and political reasons. Both of these reasons (better performance and better licensing) appear to be good reasons for the software to be packaged as a Debian package and I expect it's getting to the point that someone will do it themselves. BUT the software is technically still not a forked variant of MySQL but a patched version where the maintainers continually resync to the Oracle releases. For this reason I would like to see it treated as just a simple MySQL version within Debian. This way the users (ie: me) can simply switch by prodding apt in the right way. For this to work seamlessly (unlike, for example, the recent multimedia troubles) the MariaDB package should be packaged identically to MySQL, which IMO is best done by the same Debian maintainers. So my request is that you package the MariaDB as a secondary version of MySQL in such a way that the two packages can be seamlessly switched within the Debian system. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682080: deluge-console doesn't like deluged running as another user
Unfortunatly, neither is wrong. Deluge-gtk will run in 'classic' mode where it automatically starts it's own torrent engine. Deluge-console only connects to the demon, it never runs in classic mode. To get the link to the daemon working you need to disable classic mode for the deluge-gtk and make sure the 'auth' file in $HOME/.config/deluge/ contains a matching user and password for both of them (and the web UI). As deluged can now be started by an initscript it will probably be necessary for the user and password for the daemon running under debian-deluged to be configurable on install. The same would be true for the deluged-web interface; after all it probably needs an initscript too and to know both the userpass for the daemon and have a password configured to allow access to itself. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670816: Patch is wrong.
Please ignore the patch, it only works because it more or less disables the special processing of style tags. Robert de Bath -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670816: Sanatizer breaks html message if STYLE contains comment markers.
Package: sanitizer
Version: 1.76-3
If a style block politely contains !-- and -- comment markers to hide the
style sheet on old browsers the sanitizer code to hide the style sheet for
impolite mail generators breaks the message.
It leaves the opening style tag incomplete in the form style_01 with the
comment marker following after.
This patch adds a trailing '' to the style tag to close it so the produced
HTML isn't severely broken in this case.
Robert de Bath
--- HTMLCleaner.pm 2012-04-29 10:08:09.0 +0100
+++ /usr/share/perl5/Anomy/HTMLCleaner.pm 2012-04-29 10:09:47.0
+0100
@@ -791,7 +791,7 @@
my $data = shift;
my $cnt = $self-{style_index}++;
$self-{styles}-[$cnt] = $data;
- return style_$cnt ;
+ return style_$cnt ;
}
# This routine sanitizes a snippet of HTML.
@@ -827,8 +827,8 @@
{
$self-{style_count} += ($$data_ptr =~ s/(style[^]*)/
$self-record_style($1) /geis);
}
-$self-{style_count} -= ($$data_ptr =~ s/style_(\d+)(
[^]+)(\/style)/$self-{styles}-[$1]$2$3/gis);
-$self-{style_count} -= ($$data_ptr =~ s/style_(\d+)
([^]+)/$self-{styles}-[$1]$2/gis);
+$self-{style_count} -= ($$data_ptr =~ s/style_(\d+)(
[^]+)(\/style)/$self-{styles}-[$1]$2$3/gis);
+$self-{style_count} -= ($$data_ptr =~ s/style_(\d+)
([^]+)/$self-{styles}-[$1]$2/gis);
# Check for trailing tags...
if ($$data_ptr =~ s/((?:!--\s+)?[A-Za-z]+[^]+)$//s)
@@ -838,7 +838,7 @@
{
if (($self-{style_count} 0)
# Fix this long evil tag we artificially spawned above...
- (my $n = ($leftovers =~ s/style_(\d+)
([^]*)$/$self-{styles}-[$1]$2/is)))
+ (my $n = ($leftovers =~ s/style_(\d+)
([^]*)$/$self-{styles}-[$1]$2/is)))
{
$self-{style_count} -= $n;
}
Bug#622318: iscsitarget-dkms: Does not compile with linux-image-2.6.38-2-686
Package: iscsitarget-dkms Version: 1.4.20.2-4 Severity: normal root@debroot:~# more /var/lib/dkms/iscsitarget/1.4.20.2/build/make.log DKMS make.log for iscsitarget-1.4.20.2 for kernel 2.6.38-2-686 (i686) Tue Apr 12 06:33:47 BST 2011 make: Entering directory `/usr/src/linux-headers-2.6.38-2-686' LD /var/lib/dkms/iscsitarget/1.4.20.2/build/built-in.o LD /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/built-in.o CC [M] /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/tio.o CC [M] /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/iscsi.o CC [M] /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/nthread.o CC [M] /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/wthread.o /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/wthread.c: In function 'worker_thread': /var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/wthread.c:75: error: implicit declaration of function 'copy_io_context' make[4]: *** [/var/lib/dkms/iscsitarget/1.4.20.2/build/kernel/wthread.o] Error 1 make[3]: *** [/var/lib/dkms/iscsitarget/1.4.20.2/build/kernel] Error 2 make[2]: *** [_module_/var/lib/dkms/iscsitarget/1.4.20.2/build] Error 2 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 make: Leaving directory `/usr/src/linux-headers-2.6.38-2-686' root@debroot:~# -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages iscsitarget-dkms depends on: ii dkms 2.1.1.2-6 Dynamic Kernel Module Support Fram ii make 3.81-8.1 An utility for Directing compilati iscsitarget-dkms recommends no packages. iscsitarget-dkms 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#611976: Ping run takes zero time.
Package: iputils-ping Version: 3:20071127-1+lenny1 The 'time' value displays zero milliseconds for preloaded pings and slightly short times for normal pings. I would expect the time taken from when the first ping was preloaded into the outbound queue; of the order of 36ms in this example. # ping -w 5 -l 3 -c 3 www.google.com PING www.l.google.com (209.85.143.104) 56(84) bytes of data. 64 bytes from dy-in-f104.1e100.net (209.85.143.104): icmp_seq=1 ttl=56 time=34.5 ms 64 bytes from dy-in-f104.1e100.net (209.85.143.104): icmp_seq=2 ttl=56 time=35.1 ms 64 bytes from dy-in-f104.1e100.net (209.85.143.104): icmp_seq=3 ttl=56 time=35.8 ms --- www.l.google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 0ms = This line == rtt min/avg/max/mdev = 34.530/35.203/35.881/0.572 ms, pipe 3 # Same thing happens with ping6. # ping6 -w 5 -l 3 -c 3 ipv6.google.com PING ipv6.google.com(2a00:1450:8006::93) 56 data bytes 64 bytes from 2a00:1450:8006::93: icmp_seq=1 ttl=57 time=27.5 ms 64 bytes from 2a00:1450:8006::93: icmp_seq=2 ttl=57 time=28.6 ms 64 bytes from 2a00:1450:8006::93: icmp_seq=3 ttl=57 time=30.5 ms --- ipv6.google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 27.539/28.934/30.582/1.270 ms, pipe 3 # -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606527: Use the source
And in particular there is a candidate patch at http://lists.exim.org/lurker/message/20101209.172233.abcba158.en.html#e xim-dev (although sadly I can't see how to get it to render in a fixed-width font). Check the source to that page; remove a few br tags and replace some amp; entities and it looks good. Robert de Bath
Bug#598035: LILO doesn't allow md version 1.0 raid1 boot drives.
Package: lilo
Version: 22.8-8.3
The attached patch turns off the error Inconsistent Raid version
information for Version 1.0 md RAID mirror pairs. It also corrects
the error message as the version information is just incompatible not
inconsistent.
No other charges are required as 1.0 devices have the same layout
as v0.90 devices except that they work with drives in excess of 2TB.
It does not update for version 1.2 raid superblocks, this would require
a much more complex patch.
With the following lilo.conf the standard debian initrd and kernel boot
off of an LVM logical drive on an MD raid1 array consisting of two
whole disk devices (/dev/sda /dev/sdb). With this patch the array
can use version 1.0 superblocks so these devices can be the new 3TB
Seagate drives.
boot=/dev/md0
raid-extra-boot=mbr-only
map=/boot/map
delay=20
default=Linux
append=quiet root=/dev/mapper/vg0-root
image=/vmlinuz
label=Linux
read-only
initrd=/initrd.img
--
Rob. (Robert de Bath robert$ @ debath.co.uk)
http://www.debath.co.uk/Index: lilo-22.8/geometry.c
===
--- lilo-22.8.orig/geometry.c 2010-09-25 17:38:55.315820444 +0100
+++ lilo-22.8/geometry.c2010-09-25 17:39:16.016827136 +0100
@@ -1116,9 +1116,19 @@
if (ioctl(md_fd,GET_ARRAY_INFO,md_array_info) 0)
die(Unable to get RAID info on %s, mdxxx);
- if ((md_array_info.major_version != md_version_info.major)
- (md_array_info.minor_version != md_version_info.minor))
- die(Inconsistent Raid version information on %s, mdxxx);
+if (md_version_info.major != 0 || md_version_info.minor != 90 ||
+((md_array_info.major_version != 0 ||
+md_array_info.minor_version != 90)
+ (md_array_info.major_version != 1 ||
+md_array_info.minor_version != 0))
+) {
+die(Incompatible Raid version information on %s (RV=%d.%d
GAI=%d.%d),
+mdxxx,
+(int)md_version_info.major,
+(int)md_version_info.minor,
+(int)md_array_info.major_version,
+(int)md_array_info.minor_version);
+}
if (md_array_info.level != 1)
die(Only RAID1 devices are supported for boot images);
raid_limit = md_array_info.raid_disks + md_array_info.spare_disks;
Index: lilo-22.8/raid.c
===
--- lilo-22.8.orig/raid.c 2010-09-25 17:38:55.327820457 +0100
+++ lilo-22.8/raid.c2010-09-25 17:44:33.408833700 +0100
@@ -157,10 +157,14 @@
if (verbose = 4) printf(GET_ARRAY_INFO version = %d.%d\n,
(int)md_array_info.major_version,
(int)md_array_info.minor_version);
- if ((md_array_info.major_version != md_version_info.major)
- (md_array_info.minor_version != md_version_info.minor)) {
- die(Inconsistent Raid version information on %s (RV=%d.%d
GAI=%d.%d),
- boot,
+if (md_version_info.major != 0 || md_version_info.minor != 90 ||
+((md_array_info.major_version != 0 ||
+md_array_info.minor_version != 90)
+ (md_array_info.major_version != 1 ||
+md_array_info.minor_version != 0))
+) {
+die(Incompatible Raid version information on %s (RV=%d.%d
GAI=%d.%d),
+boot,
(int)md_version_info.major,
(int)md_version_info.minor,
(int)md_array_info.major_version,
Bug#588892: Doesn't follow filesystem recommendations
Package: mhddfs Version: 0.1.35 Severity: minor Tags: patch When filling a filesystem mhddfs will normally fill one of the component filesystems to a fixed amount less than the total capacity of the filesystem before it moves onto the next. If the filesystems have different capacities the percentage of free space remaining cannot be forced into the range suggested at the maximum by the filesystem writers. Eg. If you arrange for the free space on one drive to be 25% of the capacity a drive of half the capacity will end up at 50% and a drive of double will end up at 12%. The default value mean that a modern hard disk will be filled up to 100% before moving onto the next drive. The attached patch uses a free percentage calculation so that the drives will be filled one by one as now, but to a free percentage before moving onto the next drive. Once all the drives have been filled to this percentage the drive space will be allocated to the drive with the minimum allocated (integer) percentage. The use of an integer means that related files are likely to be clustered on the same drive as subsequent files will be placed on the same drive until the percentage value ticks over to the next integer value. This has several advantages; the simplest being that a default setup of (say) 25% is good for all drives. Others are all the reasons for keeping a filesystem under 85% usage in the first place. I have chosen 25% free as the default because it gives a good headroom to go buy an extra drive before you hit the 85% I mentioned before. Robert de Bath rdeb...@tvisiontech.co.uk percent_patch.diff.gz Description: percent_patch.diff.gz
Bug#588892: Doesn't follow filesystem recommendations
Dmitry, I've looked at the changes you've made (haven't actually tested yet though) One thing I've noticed so far is that you've made 100% an error. IMO it is a reasonable request and means that the user wants the entire virtual drive to filled up using the percentage by percentage method rather than the maximum free space method. Robert. -Original Message- From: Dmitry E. Oboukhov [mailto:un...@debian.org] Sent: 13 July 2010 12:29 To: Robert de Bath; 588...@bugs.debian.org Cc: cont...@bugs.debian.org Subject: [NOTWHITELIST] Re: Bug#588892: Doesn't follow filesystem recommendations severity 588892 minor tags 588892 patch thanks Hi, Robert! I've edited Your patch a bit and uploaded new version upto Debian/experimental. Please test it :) Thanks for Your work! On 09:40 Tue 13 Jul , Robert de Bath wrote: RdB Package: mhddfs RdB Version: 0.1.35 RdB Severity: minor RdB Tags: patch RdB When filling a filesystem mhddfs will normally fill one of the component filesystems to a fixed amount less than the total capacity of the filesystem before it moves onto the next. If the filesystems have different capacities the percentage of free space remaining cannot be forced into the range suggested at the maximum by the filesystem writers. Eg. If you arrange for the free space on one drive to be 25% of the capacity a drive of half the capacity will end up at 50% and a drive of double will end up at 12%. The default value mean that a modern hard disk will be filled up to 100% before moving onto the next drive. RdB The attached patch uses a free percentage calculation so that the drives will be filled one by one as now, but to a free percentage before moving onto the next drive. Once all the drives have been filled to this percentage the drive space will be allocated to the drive with the minimum allocated (integer) percentage. The use of an integer means that related files are likely to be clustered on the same drive as subsequent files will be placed on the same drive until the percentage value ticks over to the next integer value. RdB This has several advantages; the simplest being that a default setup of (say) 25% is good for all drives. Others are all the reasons for keeping a filesystem under 85% usage in the first place. RdB I have chosen 25% free as the default because it gives a good headroom to go buy an extra drive before you hit the 85% I mentioned before. RdB Robert de Bath RdB rdeb...@tvisiontech.co.uk -- ... mpd playing: U.D.O. - The Key . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Bug#588892: [NOTWHITELIST] Re: Bug#588892: Doesn't follow filesystem recommendations
Dmitry, I don't really agree with the default being the fixed value 4Gb, I think the only time it's right is for an underlying filesystem of around 16-24Gb so I basically never used the default even before this patch. Except, occasionally, for very small file systems; where it was effectively infinite. IMHO the 25% value would be a good guess for any new user in any unknown situation. But, you've seen your other users' use-cases so I have no problem deferring to your decision and continuing to use the option. Robert. -Original Message- From: Dmitry E. Oboukhov [mailto:un...@debian.org] Sent: 13 July 2010 14:07 To: Robert de Bath Cc: 588...@bugs.debian.org Subject: [NOTWHITELIST] Re: Bug#588892: Doesn't follow filesystem recommendations RdB I've looked at the changes you've made (haven't actually tested yet RdB though) One thing I've noticed so far is that you've made 100% an error. IMO it is a reasonable request and means that the user wants the entire virtual drive to filled up using the percentage by percentage method rather than the maximum free space method. Yes, You are right. But I don't know should we change default behaviour. I've already received one letter from subscribed users. I think I'll set old default. -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
Bug#485989: mdadm metadata issue
Sorry, long posponed email here: I'm sending it because the last retorical questions are still relevent. On Wed, 16 Sep 2009, Neil Brown wrote: metadata=0.9 would never work. It is a version number, not a decimal number. metadata=0.90 is correct and totally different from metadata=0.9 That's what I figured. Do you have any idea what upgrade script put metadata=0.9 in there? I don't know, My best guess it that it's come from the initramdisk creation as that's the only thing that cared, but that uses mdadm (mkconf) to create the file. Thinking it through, I suspect it's possible that it's a leftover from long ago and only recently has the initrd begun to care. It would have still been created from a script or an mdadm conf though. I note that mdadm does different lines depending on how you call it ... # mdadm --detail --scan --config=partitions ARRAY /dev/md0 level=raid1 num-devices=7 metadata=00.90 UUID=6daad342:4f295c4f:a3bab061:9112c3c7 ARRAY /dev/md1 level=raid10 num-devices=6 metadata=01.02 name=RIPLinuX:1 UUID=fa6457c6:33314a03:36f96c6c:5a867416 ARRAY /dev/md2 level=raid10 num-devices=6 metadata=01.02 name=RIPLinuX:2 UUID=a2070504:b2adff98:de745c49:e2623eb7 # mdadm --examine --scan --config=partitions ARRAY /dev/md0 level=raid1 num-devices=7 UUID=6daad342:4f295c4f:a3bab061:9112c3c7 ARRAY /dev/md/1 level=raid10 metadata=1.2 num-devices=6 UUID=fa6457c6:33314a03:36f96c6c:5a867416 name=RIPLinuX:1 ARRAY /dev/md/2 level=raid10 metadata=1.2 num-devices=6 UUID=a2070504:b2adff98:de745c49:e2623eb7 name=RIPLinuX:2 Which form of the metadata would be 'right'? Why does --examine _sometimes_ omit it? -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550748: Acknowledgement (Cannot remove gcc-4.3-base)
Severity: wishlist Okay, sorry, it appears that this packages is nothing to do with the compiler itself, it just contains a few text files. So I've downgraded the bug and now just wish it didn't have such a confusing name. Say gcc-4.3-version-list, not something that implies that it contains the basic components of the complier. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550748: Cannot remove gcc-4.3-base
Package: gcc-4.3-base Version: 4.3.2-1.1 If I try to run: $ apt-get remove gcc-4.3-base apt+ I get: libgcc1: Depends: gcc-4.3-base libcstd++6: Depends: gcc-4.3-base $ As I can have multiple versions of gcc-*-base installed a dependancy on any one version seems very wrong. But most importantly this prevents me from creating a Debian system without a C compiler. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#398957: Workaround.
Instead of root=/dev/mapper/vg-root use append=root=/dev/mapper/vg-root Then lilo doesn't bugger around with the option. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#485989: mdadm metadata issue
On Sun, 30 Aug 2009, martin f krafft wrote: Why specify it in the first place? I suggest to remove all metadata= stuff from mdadm.conf. Inspect the /usr/share/mdadm/mkconf output. I didn't. It got added automatically... Bug? -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#485989: mdadm metadata issue
mdadm is VERY touchy about the metadata= item in the /etc/mdadm/mdadm.conf file. For example I've just done an upgrade and the upgrade script put metadata=0.9 in the file. This was not acceptable to mdadm -A only when I changed it to metadata=0.90 was mdadm -A able to assemble the array. I expect the same issue happens with metadata=1 and metadata=1.0 -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#489072: Partition table damaged
Package: debian-installer Version: 20070308etch2 I did a Debian install on a machine that already had XP installed, grub gave Error 18, I replaced this with an LBA MBR and Lilo in the partition boot sector and got L 99 after adding ignore-table. I removed and reinstalled the debian partitions and the install succeeded on the second try. I was unable to repeat the failure, however, I suspect part of the cause was the very ugly partition table (which did repeat): Script started on Thu 03 Jul 2008 00:21:29 BST debian:~# sfdisk -l /dev/hda Disk /dev/hda: 77520 cylinders, 16 heads, 63 sectors/track Warning: extended partition does not start at a cylinder boundary. DOS and Linux will interpret the contents differently. Units = cylinders of 516096 bytes, blocks of 1024 bytes, counting from 0 Device Boot Start End #cyls#blocks Id System /dev/hda1 0+ 15884 15885- 8006008+ 7 HPFS/NTFS end: (c,h,s) expected (1023,15,63) found (1023,239,63) /dev/hda2 * 15889+ 74890- 59001- 29736315 83 Linux start: (c,h,s) expected (1023,15,63) found (997,0,1) end: (c,h,s) expected (1023,15,63) found (1023,254,63) /dev/hda3 74890+ 775192630- 1325362+ 5 Extended start: (c,h,s) expected (1023,15,63) found (1023,254,63) end: (c,h,s) expected (1023,15,63) found (1023,254,63) /dev/hda4 0 - 0 00 Empty /dev/hda5 74890+ 775192630- 1325331 82 Linux swap / Solaris start: (c,h,s) expected (1023,15,63) found (1023,254,63) end: (c,h,s) expected (1023,15,63) found (1023,254,63) debian:~# sfdisk -d /dev/hda Warning: extended partition does not start at a cylinder boundary. DOS and Linux will interpret the contents differently. # partition table of /dev/hda unit: sectors /dev/hda1 : start= 63, size= 16012017, Id= 7 /dev/hda2 : start= 16016805, size= 59472630, Id=83, bootable /dev/hda3 : start= 75489435, size= 2650725, Id= 5 /dev/hda4 : start=0, size=0, Id= 0 /dev/hda5 : start= 75489498, size= 2650662, Id=82 debian:~# Script done on Thu 03 Jul 2008 00:23:55 BST There are three CHS values here: BIOS invention: 1024:240:63 Kernel invention: 1024:16:63 Fdisk invention: 1024:255:63 I would expect only the CHS invented by the BIOS is of any interest to anyone. The fact that the fdisk tool you used has seen fit to invent a layout is definitly a bug, however, is probably triggered by the kernel's randomness. Note, before debian-installer messed with it the partition table was identified correctly as being created under a BIOS 1024:240:63 layout by both fdisk and sfdisk. (I used fdisk to resize the windows partition) On install I chose Guided install on empty disk space (slightly paraphrased) and everything in one partition. The only other non-henpeck option was use of UK English (it detected a laptop install) -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326461: acpi
Sorry no, The laptop went 'missing' when it was sent in for a repair. So I now have a shiny new laptop c/o DHL which should keep me going for another three years. But it has only one battery so I can't help with this issue anymore. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ On Fri, 13 Jun 2008, Michael Meskes wrote: Hi, is it possible for you to try the same setup again with a newer version of acpi and possibly a newer kernel? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404885: FOUND IT
It's in hw/xfree86/int10/xf86int10.c Function int1A_handler(xf86Int10InfoPtr pInt) For AX values 0xb108, 0xb109, 0xb10a, 0xb10b, 0xb10c and 0xb10d The entire contents of edi is used as a pci register number, only DI should be used. For this specific bios X86_ECX = pciReadLong(tag, X86_EDI); -- X86_ECX = pciReadLong(tag, X86_DI); in case 0xb10a: fixes my problem. Now I have a driver that's both stable and not too slow. :-) -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ On Wed, 25 Jul 2007, Julien Cristau wrote: On Fri, May 4, 2007 at 19:27:03 +0100, Robert de Bath wrote: Well, looks like I was wrong, the current unstable (1:7.2-3) locks up with 100% cpu. The process can be kill -9'd and the attached log is what remains. In addition after resetting the console I can see the messages: f000:5054: 01 ILLEGAL EXTENDED X86 OPCODE! XIO: fatal IO error 104 (Connection reset by peer) on X server :0.0 after 0 requests (0 known processed) with 0 events remaining. This is either a bug in the x86 emulator included in the X server, or a bug in your vbios. In either case, it'd probably work if you didn't use the vesa driver. Is there any particular reason you use it instead of an appropriate driver for your video card? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404885: xserver-xorg-video-vesa VERY SLOW
On Wed, 25 Jul 2007, Julien Cristau wrote: On Fri, May 4, 2007 at 19:27:03 +0100, Robert de Bath wrote: Well, looks like I was wrong, the current unstable (1:7.2-3) locks up with 100% cpu. The process can be kill -9'd and the attached log is what remains. In addition after resetting the console I can see the messages: f000:5054: 01 ILLEGAL EXTENDED X86 OPCODE! XIO: fatal IO error 104 (Connection reset by peer) on X server :0.0 after 0 requests (0 known processed) with 0 events remaining. This is either a bug in the x86 emulator included in the X server, or a bug in your vbios. In either case, it'd probably work if you didn't use the vesa driver. Is there any particular reason you use it instead of an appropriate driver for your video card? To some extent you're right, the kernel frame buffer works, the svgalib driver (chipset VESA) works and debian stable xserver-xorg-video-vesa driver works. The current card specific driver also works (and it uses vesa) but bugs 402673 and 407620 make it a pain to use, especially as 402673 understates the problem somewhat. All those except the older xserver work in linear mode. One thing I've noticed in the log is this: ... *Mode: 118 (1024x768) ModeAttributes: 0x9b WinAAttributes: 0x7 WinBAttributes: 0x0 WinGranularity: 64 ... DirectColorModeInfo: 0 PhysBasePtr: 0x0 Mode: 117 (1024x768) ... What does the X server do when that PhysBasePtr is zero ? Why is it zero and not 0xf000 ? Google seems to say that you need to ask for the linear mode to get the specs for it but the int(10,4f01) table looks like it doesn't need to change. The kernel seems to do it that way, it looks like X asks for the specs to paged mode, but it's very confused, does it? This is what vesafb says ... vesafb: framebuffer at 0xf000, mapped to 0xe088, using 6144k, total 32768k vesafb: mode is 1024x768x32, linelength=4096, pages=9 vesafb: protected mode interface info at c000:85ba vesafb: pmi: set display start = c00c85e9, set palette = c00c8652 vesafb: scrolling: redraw vesafb: Truecolor: size=0:8:8:8, shift=0:16:8:0 fb0: VESA VGA frame buffer device I am reminded about how these BIOSs have probably been tested, and with which (single) driver, that driver just tries the mode and if the user doesn't respond in a few seconds switches back to one that was working. So shouldn't the vesa driver use the same sequence of calls it does, with the mode sniffing of course but also an I don't care what you smell, just jump option too. So how easy would a 'paranoid but under orders mode' be :-) Anyway in the short term that machine is back on stable using the slow X vesa driver and mplayer -vo svga for fullscreen video. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404885: xserver-xorg-video-vesa VERY SLOW
On Sun, 29 Apr 2007, Brice Goglin wrote: Hi Robert, A couple months ago, you reported a bug to the Debian BTS regarding the X server being very slow with the vesa driver. Does this problem still happen today? There has not been many changes upstream in the vesa For stable and testing ... xserver-xorg: 1:7.1.0-18 xserver-xorg-video-vesa: 1:1.3.0-1 Kernel: Linux version 2.6.18-4-686 (Debian 2.6.18.dfsg.1-12) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Mon Mar 26 17:17:36 UTC 2007 -- xorg (II) VESA(0): VESA VBE OEM Vendor: TRIDENT MICROSYSTEMS INC. (II) VESA(0): VESA VBE OEM Product: CYBER 2100 (II) VESA(0): VESA VBE OEM Product Rev: RXT 7.3 (16.28) (II) VESA(0): virtual address = 0xb7b3b000, physical address = 0xa, size = 65536 (==) VESA(0): Default visual is TrueColor (==) VESA(0): Backing store disabled -- mplayer VO: [x11] 480x352 = 480x352 Planar YV12 [zoom] SwScaler: using unscaled yuv420p - rgb32 special converter -- top PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 3095 root 5 -10 30044 22m 6064 S 46.9 4.4 1:13.40 Xorg 4166 robert15 0 50444 22m 15m S 2.7 4.4 0:05.50 mplayer The problem still exists in testing. For unstable ... The following packages will be REMOVED tzdata util-linux util-linux-locales The following packages will be upgraded: libc6 libc6-dev libdrm-dev libdrm2 locales xserver-xorg xserver-xorg-core WARNING: The following essential packages will be removed. This should NOT be done unless you know exactly what you are doing! util-linux tzdata (due to util-linux) so I really don't want to try to upgrade to unstable right now :-) Still I _think_ the problem is in the vesa driver itself which is the same version across all of stable, testing and unstable. However, I will try again next week. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405191: [PATCH] Fix for new font locations in etch + workaround for #262510
Package: fbiterm
Version: 0.5-5.4
The patch contains a minor change for the new locasions of the default X
fonts used and an addidional option (-s) to disable bitmap scrolling.
The latter has two uses; it disables the code that causes bug #262510
and for some AGP and similar hardware it prevents the VERY slow reading
back from the display memory used when scrolling the display.
--
Rob. (Robert de Bath robert$ @ debath.co.uk)
http://www.debath.co.uk/--- iterm-0.5.orig/unix/fbiterm/src/VTScreenView.c
+++ iterm-0.5/unix/fbiterm/src/VTScreenView.c
@@ -90,7 +90,8 @@
view-draw_text = VTScreenView_draw_text;
view-clear_rect = VTScreenView_clear_rect;
view-set_rendition = VTScreenView_set_rendition;
- view-scroll_view = VTScreenView_scroll_view;
+ if (!pIterm-noscroll)
+view-scroll_view = VTScreenView_scroll_view;
return view;
}
--- iterm-0.5.orig/unix/fbiterm/src/fbiterm.c
+++ iterm-0.5/unix/fbiterm/src/fbiterm.c
@@ -44,6 +44,7 @@
options:\n\
-a fontfile\tascii text font\n\
-m fontfile\tunicode text font\n\
+ -s\t\tdisable bitmap scrolling\n\
-v\t\tprint version information and exit\n\
-h\t\tthis help message\n);
@@ -79,7 +80,7 @@
ascfontname = DefaultAsc;
mbfontname = DefaultMB;
- while ((i = getopt (argc, argv, a:m:hv)) != EOF)
+ while ((i = getopt (argc, argv, a:m:shv)) != EOF)
switch (i)
{
case 'a':
@@ -101,6 +102,10 @@
exit (0);
break;
+ case 's':
+ pIterm-noscroll = 1;
+ break;
+
case 'h':
default:
iterm_usage ();
--- iterm-0.5.orig/unix/fbiterm/src/fbiterm.h
+++ iterm-0.5/unix/fbiterm/src/fbiterm.h
@@ -53,8 +53,8 @@
#define FB_ENVFRAMEBUFFER
#define FB_DEFDEV /dev/fb0
-#define DefaultAsc /usr/lib/X11/fonts/misc/8x16.pcf.gz
-#define DefaultMB /usr/lib/X11/fonts/misc/unifont.pcf.gz
+#define DefaultAsc /usr/share/fonts/X11/misc/8x16.pcf.gz
+#define DefaultMB /usr/share/fonts/X11/misc/unifont.pcf.gz
#define DefaultFont/usr/local/share/iterm/fonts/8x16.pcf.gz
enum ITERM_RETCODE
@@ -127,6 +127,7 @@
char charset;/* char area for distinguishing UK or
special graph */
int lock;/* lock flag for the display control
at the time of the change of a virtual
terminal */
+ int noscroll;/* Disable bitmap scroll */
}
Iterm;
Bug#395441: System go Kaboom!
Just to inform you it appears that this dependancy (half) killed my system. I recently upgraded to testing from stable and this package pulled in the package 'hal', which pulled in 'udev' which REMOVED 'hotplug' but this wasn't a working replacement because of the kernel versions. So I didn't have my drivers. I realise this isn't _your_ bug but it does seem to be a very unwise dependancy to have. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389433: Probable fix for fbdev shadow framebuffer issues
That's bug #338241. I'm pondering changing the fbdev driver to default to 32bpp though. Well I suppose 32bpp is more likely with modern hardware. Still even if you can't easily get fb_var_screeninfo.bits_per_pixel as your default a big fat warning that they don't match and how to fix it would be in order IMO. I noticed that, but it's more likely a bug in vesafb. As the log indicates, the fbdev driver actually queries the framebuffer device on the usability of each mode. I've had a look at the kernel code ... Well it seems that the vesafb doesn't have an fb_check_var function to call so the FBIOPUT_VSCREENINFO ioctl is defined by fbmem.c to be the same as FBIOGET_VSCREENINFO. This is actually reasonable, it's trying to tell you the closest mode to the one you asked for. But X will have to check that the mode it gets back is the same as the one it asked for and reject it if not. (Especially if the returned mode is SMALLER than the request!) Most of the kernel fb drivers seem to be reasonably lax in what they accept as a mode request (those that can change the mode) and so I think this will definitly be a working as designed for the kernel. Also the TEST function doesn't look like it's implemented properly in all the drivers; I'd make sure you 'GET' the original setup and 'TEST' it after you've tested all your configured modes! ... But back to the beginning; the bug this report was opened for looks fixed to me. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403975: Upgrade report, continues
Segfault appear to be fixed by upgrade to vesa driver that's arrived in test today. However, the vesa driver is VERY slow compared to the trident driver when using mplayer even though I've disabled XVideo in the trident driver (mplayer window is blue when enabled). The Trident driver also claims the display has 8192 kByte of memory, it actually has 32768 kBytes. (It ignores a VideoRam option) The ShadowFB makes little difference to the vesa driver (for video) but prevents the trident driver working if it's set to yes; the screen remains in what appears to be a corrupted textmode. Note, however, this is NOT actually textmode as I have a vga=0x318 in my lilo.conf. I've also now tried the fbdev driver; it appears to be getting the video planes wrong in some way, I get four distorted copies of the desktop across the screen. (ppmtofb works fine; once package problem is overridden) # fbsev -i mode 1024x768-76 # D: 78.653 MHz, H: 59.949 kHz, V: 75.694 Hz geometry 1024 768 1024 768 32 timings 12714 128 32 16 4 128 4 rgba 8/16,8/8,8/0,0/0 endmode Frame buffer device information: Name: VESA VGA Address : 0xf000 Size: 6291456 Type: PACKED PIXELS Visual : TRUECOLOR XPanStep: 0 YPanStep: 0 YWrapStep : 0 LineLength : 4096 Accelerator : No # cat /proc/version Linux version 2.6.14-2-686 (Debian 2.6.14-6bpo1) ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 1:3.3.5-13)) #2 Fri Dec 30 03:19:34 CET 2005 # -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/# /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type man /etc/X11/xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Files FontPath/usr/share/fonts/X11/misc FontPath/usr/X11R6/lib/X11/fonts/misc FontPath/usr/share/fonts/X11/cyrillic FontPath/usr/X11R6/lib/X11/fonts/cyrillic FontPath/usr/share/fonts/X11/100dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/100dpi/:unscaled FontPath/usr/share/fonts/X11/75dpi/:unscaled FontPath/usr/X11R6/lib/X11/fonts/75dpi/:unscaled FontPath/usr/share/fonts/X11/Type1 FontPath/usr/X11R6/lib/X11/fonts/Type1 FontPath/usr/share/fonts/X11/100dpi FontPath/usr/X11R6/lib/X11/fonts/100dpi FontPath/usr/share/fonts/X11/75dpi FontPath/usr/X11R6/lib/X11/fonts/75dpi # path to defoma fonts FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module Loadbitmap Loaddbe Loadddc Loaddri # Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadvbe # This disables XVideo SubSection extmod Option omit XVideo Option omit XVideo-MotionCompensation EndSubSection EndSection Section DRI Mode0666 EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc105 Option XkbLayout gb EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/psaux Option Protocol PS/2 Option Emulate3Buttons true EndSection Section InputDevice Identifier Synaptics Touchpad Driver synaptics Option SendCoreEventstrue Option Device/dev/psaux Option Protocol auto-dev Option HorizScrollDelta 0 EndSection Section Device Identifier Trident Microsystems CyberBlade XP4m32 Driver trident BusID PCI:1:0:0 Option CyberStretch yes #Option ShadowFB yes #Option VideoRam 32768 EndSection Section Device Identifier VMVware device Driver vmware EndSection Section Device Identifier VESA device Driver vesa
Bug#389433: Stage 1
Section Screen Identifier FB Device FB device Monitor LCD DefaultDepth24 DefaultFbBpp32 SubSection Display Depth 24 FbBpp 32 Modes 1024x768 EndSubSection EndSection If I add the FbBbp and DefaultFbBpp to xorg.conf or set the -fbbpp 32 command line option the display becomes readable. BUT rotation does NOT work, it appears that the shadowFB is not actually being used. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403975: Upgrade report
Package: x11-common Version: 1:7.1.0-8 Upgrade report from sarge. Packages removed for x11-common to be able to install: ucbmpeg-play qvwm opera-static The existing xorg.conf was very complex; it caused the Xserver to segfault. I have attached it but am not currently using it; I will probably be re-adding may of the changes if I find a specific problem I will add it here. I regenerated a new xorg.conf accepting the defaults (except for the display name and acceptable video modes). The machine this is on is a Toshiba Portage R100. Value in XkbLayout of generated xorg.conf file was uk the correct value is gb. With uk the keyboard was in us layout and the Ctrl-Alt Fkeys did not work. The default layout also used the synaptics driver for the 'touch-pad' mouse, I understand the device is an 'ALPS Glidepad'. This is sufficiently different from a synaptics for the default setup of the synaptics driver to be unusable and the documentation is not sufficient to correct this without a LOT of guesswork. I have disabled the synaptics driver and am using the default ps/2 setup. The known bugs in the xv extension and the DPMS are still present. 01:00.0 VGA compatible controller: Trident Microsystems CyberBlade XP4m32 (rev 91) -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/# XF86Config-4 (XFree86 X server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type man XF86Config-4 at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 /var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 Section ServerFlags # OptionHandleSpecialKeys Always # OptionXkbDisable Option VTSysReq on # OptionVTSysreqToggle # OptionDontVTSwitch EndSection Section Files FontPathunix/:7100# local font server FontPathunix/:7110# local font server # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/CID FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module Loadbitmap Loaddbe Loadddc Loaddri Loadfreetype Loadglx Loadint10 Loadrecord Loadtype1 # Load xtrap Loadvbe # Load GLcore # Not xorg # Load speedo # Not xorg Loadextmod # This disables XVideo # SubSection extmod # Option omit XVideo # Option omit XVideo-MotionCompensation # EndSubSection EndSection ### Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc105 Option XkbLayout gb #Option XkbOptionscompose:ralt Option XkbOptionscompose:caps #Option XkbOptionscaps:shift #Option XkbOptionssrvrkeys:none # No Ctrl-Alt-F1 #Option XkbRules xorg #Option XkbModel pc104 #Option XkbLayout us EndSection Section InputDevice Identifier PS Mouse Driver mouse Option CorePointer Option Device/dev/psaux Option Buttons 2 Option Protocol auto Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier GPM Mouse Driver mouse Option CorePointer Option Device/dev/gpmdata Option Buttons 2 Option Protocol MouseSystems Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section
Bug#84930: mc disables ^S/^Q flow.
On Fri, 27 Jan 2006, Ludovic Drolez wrote: Hi, Since mc works with screen, it's the proof that's not a 'mc' problem but a Wrong, it's mc that clears the stty crtscts flag. It has no business doing that. Screen OTOH knows that it shouldn't clear the flag even if the program in it's faked terminal does so. terminal settings or Yup, it's the terminal settings that mc messes up. terminal emulation problem. Nope, the VT emulation of a wyse terminal is _better_ than for example the Linux console. It actually emulates a couple of things I didn't think were worthwhile putting into PuTTY too. The bug should be reassigned to another package... But which one ?!? It's right exactly where it is. The only thing another package (like screen) can do it work around the mc bug. You could also try an 'export TERM=vt100/whatever' to check if it solves your problem. Nothing to do with it. The use of RTS/CTS flow control is independent of the terminal type. Cheers, -- Ludovic Drolez. http://www.palmopensource.com - The PalmOS Open Source Portal http://www.drolez.com - Personal site - Linux and PalmOS stuff -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#84930: mc disables ^S/^Q flow.
Okay,
I've just downloaded the source for mc version 4.6.1.
The problem is in the SLang_init_tty() function, basically it forces the
application (mc) to decide if XON/XOFF flow control should be on.
The application has no way of knowing this.
(NB I said RTS/CTS in my last mail that should have been XON/XOFF)
The problem line is:
if (no_flow_control) newtty.c_iflag = ~IXON; else newtty.c_iflag |= IXON;
There needs to be a way of telling the init routine that you want to
leave the IXON setting the way that the user set it in her .profile,
perhaps the line could be put inside a:
if (no_flow_control=0) {
...
}
or perhaps it'd be best to have the line as:
if (no_flow_control) newtty.c_iflag = ~IXON;
That way the second argument to SLang_init_tty() could be zero for normal
use and only set to one for programs that do silly things like using ^S
for search.
I suppose this now means that the bug is shared between mc and slang :-)
--
Rob. (Robert de Bath robert$ @ debath.co.uk)
http://www.debath.co.uk/
On Fri, 27 Jan 2006, Ludovic Drolez wrote:
Robert de Bath wrote:
On Fri, 27 Jan 2006, Ludovic Drolez wrote:
Hi,
Since mc works with screen, it's the proof that's not a 'mc' problem
but a
Wrong, it's mc that clears the stty crtscts flag. It has no business
doing that. Screen OTOH knows that it shouldn't clear the flag even if
the program in it's faked terminal does so.
Could you try the UTF-8 mc is uploaded to experimental ? It's based on
libslang2, so the bug could be fixed in that library...
TIA,
--
Ludovic Drolez.
http://www.palmopensource.com - The PalmOS Open Source Portal
http://www.drolez.com - Personal site - Linux and PalmOS stuff
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348319: python-minimal is a forced install.
Package: python-minimal Version: 2.3.5-4 I am currently running mostly sarge, however, I have the testing and unstable urls in my sources.list and 'disable' them with a preferences containing bits like: Package: * Pin: release unstable Pin-Priority: 50 This works fine for everything except python-minimal. If apt is setup as I describe this package is a forced upgrade (with dist-upgrade) that _removes_ the standard sarge python package (Plus a couple of hundred packages that depend on it!). While this isn't a problem for me in unstable (I've just removed the binaries deb line) it will be much more serious if it gets into testing. Once I remove the unstable URI 'apt-get dist-upgrade' is fine. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337454: Stable package out of date
LibClamAV Warning: LibClamAV Warning: *** This version of the ClamAV engine is outdated. *** LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/faq.html *** LibClamAV Warning: The current version in stable claims that it is a security risk. IMO this should be viewed as a security bug and fixed as such, however, just before I fired off a bug report to that effect I looked at the URL above (I had already checked the Debian package and bug pages) and found the reference to the volatile project. Now this is a problem; I still see a bug here but I'm now not sure who's bug it is. In reality it's probably not a clamav bug because the 'volatile' package fixes it. It probably should be a bug in the policy for security-fix packages but it would appear that that it's a large political problem that it being addressed by the people behind the 'volatile' project. In the mean time I still had to go away from Debian to find that Debian could actually fix the bug with clamav/stable so IMHO there should be a very obvious reference that debian-security is not supporting this package and that you need to go to debian-volatile to get security fixes. So can I suggest that you leave this bug open (perhaps with a can't fix or won't fix flag) so that it can prevent somebody going off and buying f-prot because Debian can't do the job :-) OTOH: If you know where to put a bug against the debian website that might be a good place to assign this ... -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337454: Stable package out of date
package: clamav version: 0.84-2.sarge.4 This page needs a reference to the debian volatile project. http://volatile.debian.net/mirrors.html URLs Like this in your sources.list deb http://ftp.uk.debian.org/debian-volatile sarge/volatile main Oh, look there's one :-) -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#270679: I bet this is the problem [Was: Speech output is at double of normal speed]
$ text2wave file.txt -o file.wav $ play file.wav sox: Sound card appears to only support 2 channels. Overriding format $ Sox plays it fine. BTW: This text2wave thing is a very poor hack, it doesn't start outputing until it's converted the entire input file and uses obscene amounts of cpu and swapspace. -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326461: acpi with two batteries
Package: acpi Version: 0.09-1 Severity: important $ acpi Battery 1: discharging, 61%, 01:59:19 remaining Battery 2: discharging, 61%, 03:51:48 remaining $ acpi Battery 1: charging, 61%, 01:01:58 until charged Battery 2: charged, 60% $ When discharging the two times are no use in estimating how long there is left. This is because there is no indication as to which battery is the bigger and by how much. In this example the actual time could reasonably be anything between two and four hours before even trying to think about usage patterns. (The only reason I know it's not six hours is that I know it won't last that long from experience.) For charging example above I have no indication how long the second battery will take on top of the hour for the first battery; from the other infomation below I guess it's about another two hours and that's only easy because the two batteries are at the same percentage. NB: Battery 2 is not 'charged' it's status will become 'charging' once battery 1 has got to 100%. And yes the computer does charge the battries one at a time as this implies. Additional info: $ more `find /proc/acpi/battery/ -type f ` | cat :: /proc/acpi/battery/BAT2/alarm :: alarm: 734 mWh :: /proc/acpi/battery/BAT2/state :: present: yes capacity state: ok charging state: charged present rate:6021 mW remaining capacity: 22194 mWh present voltage: 11340 mV :: /proc/acpi/battery/BAT2/info :: present: yes design capacity: 38880 mWh last full capacity: 36406 mWh battery technology: rechargeable design voltage: 10800 mV design capacity warning: 734 mWh design capacity low: 0 mWh capacity granularity 1: 10 mWh capacity granularity 2: 10 mWh model number:G71C4210 serial number: 080323 battery type:Li-ION OEM info: :: /proc/acpi/battery/BAT1/alarm :: alarm: 378 mWh :: /proc/acpi/battery/BAT1/state :: present: yes capacity state: ok charging state: charging present rate:5983 mW remaining capacity: 13348 mWh present voltage: 11410 mV :: /proc/acpi/battery/BAT1/info :: present: yes design capacity: 19008 mWh last full capacity: 18478 mWh battery technology: rechargeable design voltage: 10800 mV design capacity warning: 378 mWh design capacity low: 0 mWh capacity granularity 1: 10 mWh capacity granularity 2: 10 mWh model number:G71C0002Q210 serial number: 2100046367 battery type:Li-ION OEM info: $ -- Rob. (Robert de Bath robert$ @ debath.co.uk) http://www.debath.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
