Bug#835567: installation-reports: Debian testing failed to install on ThinkPad T43p
Me: > Another thing: I went for "Graphical install" but ended up using the > keyboard rather than the mouse. If I remember correctly, buttons at > the bottom of the screen were not accessible using the mouse because > the mouse pointer would wrap around back to the top of the screen a > few centimetres before the bottom. The screen is 1600x1200. I realised that this is very unlikely and booted the installer again to check. What's really happening is that the touchpad is in "absolute mode". I didn't even know there was such a thing. Now I do.
Bug#835567: installation-reports: Debian testing failed to install on ThinkPad T43p
Package: installation-reports Yesterday I tried to install Debian testing on a ThinkPad T43p using the then current version of debian-testing-i386-netinst.iso, which was dated 2016-08-22. I chose the default at almost all stages and everything seemed to work up to the bit where it told me to remove the installation media and reboot. It started to reboot, but I don't think it got as far as mounting the disc. It complained about some missing firmware (not a bug), then just stopped, with some sporadic disc activity continuing for a while, according to the LED. I left it for ages in case it was running fsck invisibly (which is a stupid thing to do but I've seen Linux systems do that) but it never got anywhere. I tried the whole thing twice, with and without disc encryption. With disc encryption it did get as far as asking for the passphrase, which it recognised when I typed it correctly the second time, so it must have read some data from the disc. Afterwards I successfully installed using debian-8.5.0-i386-netinst.iso on the same hardware. Another thing: I went for "Graphical install" but ended up using the keyboard rather than the mouse. If I remember correctly, buttons at the bottom of the screen were not accessible using the mouse because the mouse pointer would wrap around back to the top of the screen a few centimetres before the bottom. The screen is 1600x1200.
Re: ThinkPad 570 disc not detected
Joey Hess <[EMAIL PROTECTED]>: > Frans Pop wrote: > > The 20040430 images are pretty old. A lot has happened since then. > > I missed the versio number before. The main happening is we've switched > to the 2.4.26 kernel, so those floppys won't be able to find any kernel > module udebs for 2.4.25 in the archive, and won't work. Can I then suggest that the old non-working images be removed from the FTP site so that other people don't waste time trying them? (And the installer could detect the kernel version mismatch, if the latest version doesn't already do so.) > > Could you please try again using [1]? > > [1] http://people.debian.org/~joeyh/d-i/images/daily/floppy/ > > Please do. I tried it, and the disc was detected this time. I didn't get much further, however, because my wife told me to "turn that bloody thing off" because she wanted a lift to work. I'll let you know if there are any other problems when I continue the process later ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ThinkPad 570 disc not detected
> The machine boots into Windows 98, presumably using some kind of disc, > so the hardware does exist. Moreover, installation using /debian/dists/woody/main/disks-i386/3.0.23-2002-05-21/images-1.44 is working nicely. So that's a regression in sarge, though perhaps all it needs is a boot argument to make the sarge installer work. The machine is from 1999, not all that ancient. The sarge installer looks very good, by the way. Congratulations to everyone who worked on it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ThinkPad 570 disc not detected
I'm trying to install on an IBM ThinkPad 570 with the floppy images from /debian/dists/sarge/main/installer-i386/20040430/images/floppy but the disc seems to be invisible: /proc/ide only contains drivers, there's no /dev/hda, etc. Any advice for me? The bit of the installer where it's telling you to partition your discs is a bit confusing in this case, when there aren't any discs. You might want to consider not offering to partition them when there aren't any. The machine boots into Windows 98, presumably using some kind of disc, so the hardware does exist. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please check language/region choices for new installer
Petter Reinholdtsen <[EMAIL PROTECTED]>: > Please check the CVS version at > > > http://cvs.debian.org/debian-installer/tools/languagechooser/languagelist.l10n?rev=HEAD&content-type=text/vnd.viewcvs-markup>, > > and send updates to [EMAIL PROTECTED] Esperanto: Elektu ĉi tion por daŭrigi en Esperanto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Always use UTF-8 when running base-config?
}
}
- plot ();
+ plot (bg);
done:
bogl_drawing = 0;
Bterm optimisations:
diff -u --recursive bogl/bogl-term.c bogl-ac/bogl-term.c
--- bogl/bogl-term.c2002-08-17 21:27:06.0 +0100
+++ bogl-ac/bogl-term.c 2002-12-17 01:49:59.0 +
@@ -1,6 +1,9 @@
/* BOGL - Ben's Own Graphics Library.
This file is by Edmund GRIMLEY EVANS <[EMAIL PROTECTED]>.
+ Rendering optimisation and delay code
+ (c) Copyright Red Hat Inc 2002 <[EMAIL PROTECTED]>
+
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of the
@@ -55,16 +58,18 @@
memset(&term->ps, 0, sizeof(&term->ps));
term->screen = malloc(term->xsize * term->ysize * sizeof(wchar_t));
+ term->dirty = malloc(term->xsize * term->ysize);
term->screenfg = malloc(term->xsize * term->ysize * sizeof(int));
term->screenbg = malloc(term->xsize * term->ysize * sizeof(int));
term->screenul = malloc(term->xsize * term->ysize * sizeof(int));
term->cchars = malloc(term->xsize * term->ysize * sizeof(wchar_t *));
- if (!term->screen || !term->screenfg || !term->screenbg || !term->screenul ||
!term->cchars) {
+ if (!term->screen || !term->screenfg || !term->screenbg || !term->screenul ||
!term->cchars || !term->dirty) {
free(term->screen);
free(term->screenfg);
free(term->screenbg);
free(term->screenul);
free(term->cchars);
+free(term->dirty);
free(term);
return 0;
}
@@ -74,6 +79,7 @@
term->screenbg[i] = term->def_bg;
term->screenul[i] = 0;
term->cchars[i] = 0;
+term->dirty[i] = 1;
}
term->yorig = 0;
@@ -85,6 +91,65 @@
#define SCR(x, y) \
((x) + (((y) + term->yorig) % term->ysize) * term->xsize)
+
+static int term_match(struct bogl_term *term, int p1, int p2)
+{
+if(term->screen[p1] != term->screen[p2])
+ return 0;
+if(term->screenfg[p1] != term->screenfg[p2])
+ return 0;
+if(term->screenbg[p1] != term->screenbg[p2])
+ return 0;
+if(term->screenul[p1] != term->screenul[p2])
+ return 0;
+return 1;
+}
+
+static int term_is_clear(struct bogl_term *term, int p1)
+{
+if(term->screen[p1] != ' ')
+ return 0;
+if(term->screenfg[p1] != term->fg)
+ return 0;
+if(term->screenbg[p1] != term->bg)
+ return 0;
+if(term->screenul[p1] != 0)
+ return 0;
+return 1;
+}
+
+/* We are scrolling so anything which isnt the same as the spot below
+ is deemed dirty */
+
+static void dirty_scroll(struct bogl_term *term)
+{
+int x,y;
+
+for(y = 0; y < term->ysize-1; y++)
+ for(x=0; x < term->xsize; x++)
+{
+ /* FIXME - why doesn't this logic work */
+ // if(!term_match(term, SCR(x,y), SCR(x,y+1)))
+ term->dirty[SCR(x,y)]=1;
+}
+}
+
+/* We are backscrolling so anything which isnt the same as the spot above
+ is deemed dirty */
+
+static void dirty_backscroll(struct bogl_term *term)
+{
+int x,y;
+
+for(y = 1; y < term->ysize; y++)
+ for(x=0; x < term->xsize; x++)
+{
+ /* FIXME - why doesn't this logic work */
+ // if(!term_match(term, SCR(x,y), SCR(x,y-1)))
+ term->dirty[SCR(x,y)]=1;
+}
+}
+
static void
cursor_down (struct bogl_term *term)
{
@@ -95,7 +160,10 @@
return;
}
+
++term->yorig;
+dirty_scroll(term);
+
for (i = 0; i < term->xsize; i++)
{
int p = SCR(i, term->ypos);
@@ -104,12 +172,10 @@
term->screenfg[p] = term->fg;
term->screenbg[p] = term->bg;
term->screenul[p] = 0;
+term->dirty[p] = 1;
free (term->cchars[p]);
term->cchars[p] = 0;
}
-
-/* If we had a bogl_move or bogl_scroll we could use it here. */
-bogl_term_redraw (term);
}
static void
@@ -163,9 +229,8 @@
fg = term->screenbg[i], bg = term->screenfg[i];
else
fg = term->screenfg[i], bg = term->screenbg[i];
-
-put_char (term, x, term->ypos, term->screen[i], term->cchars[i],
- fg, bg, term->screenul[i]);
+put_char(term, x, term->ypos, term->screen[i], term->cchars[i], fg, bg,
term->screenul[i]);
+term->dirty[SCR(x, term->ypos)] = 1;
}
}
@@ -176,11 +241,14 @@
if (!term->screen[i])
{
for (j = i - 1; !term->screen[j]; j--)
+{
+if(term->screen[j] != ' ')
+ term->dirty[j] = 1;
term->screen[j] = ' ';
+}
term->
Re: Always use UTF-8 when running base-config?
I applied Alan Cox's patches to bogl-0.1.12 and found that bogl-bterm-udeb's bterm scrolled much faster. I have forwarded the patches to Daniel Jacobowitz. Anyone else who wants them, let me know. It's probably worth checking Red Hat's sources in case there are any other improvements in there. The latest Red Hat version I found was bogl-0.1.9-26.src.rpm. Can anyone tell me how to get at the contents of a src.rpm? Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Always use UTF-8 when running base-config?
Tomohiro KUBOTA <[EMAIL PROTECTED]>: > When I used bogl-bterm with i386 machine (faster than 1GHz), I > felt it was very slow. If the installation process meets scrolling > of the screen, I think bogl-bterm is too slow. I don't know about > VMWare nor other architectures. I did the first version of bogl-bterm but haven't touched it for a long time. In December 2002 Alan Cox sent me a patch for speeding up scrolling. I assume the patch also went into a Red Hat version of bterm. Is this patch included in Debian's bterm? If it isn't, then I probably owe you all an apology for not bringing it to your attention earlier. Look for [EMAIL PROTECTED] in bogl-vga16.c and bogl-term.c. Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: eo & fi boot-floppies translations
Phil Blundell <[EMAIL PROTECTED]>: > The Woody boot-floppies have apparently been translated to Finnish and > Esperanto. However, because there are no language definition files for > these translations, they are not showing up in the language chooser that > the user sees. I've just added utilities/dbootstrap/langs/esperanto.src to CVS, copying the model of the other files. I haven't tested it, so I hope it doesn't contain a typo that breaks the build. Does the file have to be added to some list somewhere, too? Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Demographic analysis of debian user's language (was Re: b-f one-liner needs translating
Perhaps if you put all the localisation data for each language into a separate file that is searched for in the root directory of the floppy, then people could download a localisation file separately and copy it onto the floppy. It wouldn't then matter so much which localisations are included with the standard floppy image. Also, it would be possible to add and update localisations without rereleasing the floppy image. When implementing something like that you should be careful to treat all languages symmetrically, so you can correct a typo in the English version without having to update every other language as a consequence. Of course, this doesn't answer the question of what to do with woody's boot-floppies. Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Locale for boot-floppies
GOTO Masanori <[EMAIL PROTECTED]>: > > LC_COLLATE > > copy "POSIX" > > END LC_COLLATE > > Wrong. `iso14651_t1' is appropriate for the UTF-8 locale. Normally I would agree, but I chose POSIX for LC_COLLATE for two reasons: it's smaller; lots of people don't like the new-fangled collation (they don't like the case-insensitive ordering of the output of "ls", for example). Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Locale for boot-floppies
Edmund GRIMLEY EVANS <[EMAIL PROTECTED]>: > Probably we should create a new minimal locale which is just like C, > except that it uses UTF-8. Maybe we can call it "C.UTF-8". > > I'm not an export on locales, but I'll try to have a look at it and > see if I can make something work. I tried blending "i18n" and "POSIX" to create the attached version of /usr/share/i18n/locales/C@utf-8. The name "C.UTF-8" doesn't seem to be usable. The /usr/lib/locale/C@utf-8/ that results is still 158 KB, but the compressed tar archive is about 30 kB. The big file is LC_CTYPE. I don't suppose you could make that file smaller, but maybe you could make it more compressible. Edmund comment_char % escape_char / LC_IDENTIFICATION title "POSIX/i18n locale for UTF-8" source "" address"" contact"" email "[EMAIL PROTECTED]" tel"" fax"" language "" territory "" revision "draft" date "2001-05-30" % category "C@utf-8:2000";LC_IDENTIFICATION category "C@utf-8:2000";LC_CTYPE category "C@utf-8:2000";LC_COLLATE category "C@utf-8:2000";LC_TIME category "C@utf-8:2000";LC_NUMERIC category "C@utf-8:2000";LC_MONETARY category "C@utf-8:2000";LC_MESSAGES category "C@utf-8:2000";LC_PAPER category "C@utf-8:2000";LC_NAME category "C@utf-8:2000";LC_ADDRESS category "C@utf-8:2000";LC_TELEPHONE END LC_IDENTIFICATION LC_COLLATE copy "POSIX" END LC_COLLATE LC_MESSAGES copy "POSIX" END LC_MESSAGES LC_NUMERIC copy "POSIX" END LC_NUMERIC LC_TIME copy "POSIX" END LC_TIME LC_ADDRESS copy "i18n" END LC_ADDRESS LC_CTYPE copy "i18n" END LC_CTYPE LC_MEASUREMENT copy "i18n" END LC_MEASUREMENT LC_MONETARY copy "i18n" END LC_MONETARY LC_NAME copy "i18n" END LC_NAME LC_PAPER copy "i18n" END LC_PAPER LC_TELEPHONE copy "i18n" END LC_TELEPHONE
Re: Locale for boot-floppies
Marcin Owsiany <[EMAIL PROTECTED]>: > Now that we decided to use glibc's UTF-8 support in > boot-floppies, we need a locale definition to use on the root > disk. > > C.UTF-8 doesn't exist in /etc/locale.gen. en_IN.UTF-8 which > I chose semi-randomly for my own builds is 480 kb, which is > _way_ to big for the root disk. Probably we should create a new minimal locale which is just like C, except that it uses UTF-8. Maybe we can call it "C.UTF-8". I'm not an export on locales, but I'll try to have a look at it and see if I can make something work. I'll take a wild guess that a lot of the kilobytes are used up by the data needed for collating. If you look at some of the bug reports for libc6 and locales you'll see that the sophisticated collating that glibc now does is rather unpopular with many users. Many people prefer to use LC_COLLATE=C. So that's one way we can make C.UTF-8 smaller. Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: woody b-f seems quite usable
konstantin cherkasoff <[EMAIL PROTECTED]>: > Hi. > EGE> Or are you seeing no borders at all, > Yes. No borders. > EGE> and the text on a button (e.g. > EGE> "Ok") is duplicated briefly when you select the button? > Hm, what meen "duplicated briefly"? Running the program "testgrid", which comes with newt, I see no borders at all when I run it on a (frame-buffer) Linux console with TERM=linux. If I run it on a (frame-buffer) Linux console with TERM=xterm-debian it seems to work, so the problem might be with the terminfo. Can you cure the problem by adjusting TERM? Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dbootstrap's zh_CN.po encoding
Marcin Owsiany <[EMAIL PROTECTED]>:
> Looks like something's wrong with the chineese po file. Can
> someone more competent look at it? The following is a snippet
> from 'make ../all.utf' in boot-floppies/utilities/bogl
>
> iconv -f "`grep -a '^"Content-Type:' zh_CN.po | sed -e
>'s/^.*charset=\\(.*\\)n.*/\\1/'`" -t utf-8 < zh_CN.po > utf/zh_CN.po
> iconv: illegal input sequence at position 990
What appears to have happened is that some program has reformated the
file, splitting multibyte characters between lines.
So you can fix the problem with something like:
cd utilities/dbootstrap/po
mv -i zh_CN.po zh_CN.po-
perl -e '$_=join("",<>);s/"\n"//g;print;' zh_CN.po- > zh_CN.po
That might be a permanent solution, because msgmerge didn't seem to
split strings dangerously when I tried it. However, if the problem
keeps reappearing then you might need to apply something like the
attached UNTESTED patch to utilities/dbootstrap/po/Makefile. But try
fixing just the PO file first.
Edmund
--- Makefile.orig Wed May 23 23:48:04 2001
+++ MakefileMon May 28 13:43:50 2001
@@ -51,9 +51,9 @@
if [ $$lang = 'zh_TW' ]; then \
mv $$lang.po $$lang.old.po; \
echo "$$lang:"; \
- iconv -f "`grep -a '^"Content-Type:' $$lang.old.po | sed -e
's/^.*charset=\\(.*\\)n.*/\\1/'`" -t utf-8 < $$lang.old.po > $$lang.old.utf.po; \
+ perl -e '$_=join("",<>);s/"\n"//g;print;' $$lang.old.po | iconv -f "`grep -a
+'^"Content-Type:' $$lang.old.po | sed -e 's/^.*charset=\\(.*\\)n.*/\\1/'`" -t
+utf-8 > $$lang.old.utf.po; \
if msgmerge $$msgmergeopt -v $$lang.old.utf.po $(PACKAGE).pot -o
$$lang.utf.po; then \
- iconv -f utf-8 -t "`grep -a '^"Content-Type:' $$lang.old.po | sed -e
's/^.*charset=\\(.*\\)n.*/\\1/'`" < $$lang.utf.po > $$lang.po; \
+ perl -e '$_=join("",<>);s/"\n"//g;print;' $$lang.utf.po | iconv -f utf-8
+-t "`grep -a '^"Content-Type:' $$lang.old.po | sed -e
+'s/^.*charset=\\(.*\\)n.*/\\1/'`" > $$lang.po; \
rm -f $$lang.old.po $$lang.old.utf.po $$lang.utf.po; \
else \
echo "msgmerge for $$cat failed!"; \
@@ -90,7 +90,7 @@
@msgfmt --statistics -o $@ $<
utf/%.po: %.po
- iconv -f "`grep -a '^"Content-Type:' $< | sed -e
's/^.*charset=\\(.*\\)n.*/\\1/'`" -t utf-8 < $< > $@
+ perl -e '$_=join("",<>);s/"\n"//g;print;' $< | iconv -f "`grep -a
+'^"Content-Type:' $< | sed -e 's/^.*charset=\\(.*\\)n.*/\\1/'`" -t utf-8 > $@
%.pox: %.po
$(MAKE) $(PACKAGE).pot
@@ -154,9 +154,9 @@
if [ $$lang = 'zh_TW' ]; then \
mv $$lang.po $$lang.old.po; \
echo "$$lang:"; \
- iconv -f "`grep -a '^"Content-Type:' $$lang.old.po | sed -e
's/^.*charset=\\(.*\\)n.*/\\1/'`" -t utf-8 < $$lang.old.po > $$lang.old.utf.po; \
+ perl -e '$_=join("",<>);s/"\n"//g;print;' $$lang.old.po | iconv -f "`grep
+-a '^"Content-Type:' $$lang.old.po | sed -e 's/^.*charset=\\(.*\\)n.*/\\1/'`" -t
+utf-8 > $$lang.old.utf.po; \
if msgmerge $$msgmergeopt -v $$lang.old.utf.po $(PACKAGE).pot -o
$$lang.utf.po; then \
- iconv -f utf-8 -t "`grep -a '^"Content-Type:' $$lang.old.po | sed -e
's/^.*charset=\\(.*\\)n.*/\\1/'`" < $$lang.utf.po > $$lang.po; \
+ perl -e '$_=join("",<>);s/"\n"//g;print;' $$lang.utf.po | iconv -f utf-8
+-t "`grep -a '^"Content-Type:' $$lang.old.po | sed -e
+'s/^.*charset=\\(.*\\)n.*/\\1/'`" > $$lang.po; \
rm -f $$lang.old.po $$lang.old.utf.po $$lang.utf.po; \
else \
echo "msgmerge for $$cat failed!"; \
Re: libutf8, bogl, bgf fonts and tools vs boot-floppies
Daniel Jacobowitz <[EMAIL PROTECTED]>: > > I may have committed a fix for the same bug today. Please check. > > Indeed you did, and it's a similar fix. This is what I originally > did: > > @@ -206,18 +206,11 @@ > -for (; (k = mbrtowc (&wc, s, n, &term->ps)) >= 0; s += k, n -= k) > +for (; n > 0 && (k = mbrtowc (&wc, s, n, &term->ps)) >= 0; s += k, n -= k) > > Your patch seems rather more complete; should I use that instead? Yes, I think so. > > BTW: now that we use glibc's UTF8 support, what locale should > > we use? I've found en_IN.UTF-8 (in my /etc/locale.gen) to work, > > but I don't even know what that means. > > Indian, I think... I have asked before, but never received a satisfactory answer, what you should do if you want a "standard" UTF-8 locale. Probably there should be something like "C.UTF-8". Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libutf8, bogl, bgf fonts and tools vs boot-floppies
Daniel Jacobowitz <[EMAIL PROTECTED]>: > > We need to have the stuff in subject included in bf bould > > process somehow. The question is: how? AFAIK bterm has its own > > package (bogl-bterm), as does bdf fonts' source. (Now we either > > need to put libutf8 in its package or make bterm work without > > it - I'd say we should do the former, since it's probably > > easier and so require less time). > > No, the latter. Since I did it several months ago; see bogl-bterm's > changelog. Oops. Wait. I forgot to upload that; I'm sorry. I'll do > it soon. I may have committed a fix for the same bug today. Please check. Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: woody b-f seems quite usable
> By the way, what about slang and frame-borders on console? > I did not find any records about this in its bug-logs. > What package has this bug (or it's not a bug)? What is the problem, exactly? Is it that you get ASCII graphics +---+ | like this | +---+ instead of graphics characters? Or are you seeing no borders at all, and the text on a button (e.g. "Ok") is duplicated briefly when you select the button? Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: woody bf-utf8 (Re: slang, boot-floppies, and wide character support)
Marcin Owsiany <[EMAIL PROTECTED]>: > > Thanks! Now we have to check newt-utf8 by Enrique, then check the problem > > in bogl-bterm which impede bterm working without libutf8. > > So do we actually stick to libutf8 or try to make it work with > glibc? We make it work with glibc. Done. CVS log for bogl-term.c: With glibc-2.2.3, mbrtowc(&wc, s, 0, &ps) seems to return 0 instead of (size_t)(-2). I think this is a bug in glibc-2.2.3. Make sure we work either way. Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible editor for installer: QEmacs
> There isn't a Debian package yet. There is now, because I just made one: http://rano.org/qemacs/ I'm not a Debian maintainer, of course, so if any maintainer wants to review this and upload it, that might be useful. (I know there are these things called ITPs.) Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
possible editor for installer: QEmacs
If we are going to use UTF-8 for the installer, then we need a new editor instead of ae. I looked at the source for ae and thought it would be easier to write a new editor from scratch than to add multibyte support to ae. QEmacs may be the answer: http://www-stud.enst.fr/~bellard/qemacs/ Last time I looked, ae was 23888 bytes. The binary for version 0.2 of QEmacs is 24060 bytes. I've just tried it out quickly, and, yes, it does allow me to edit a UTF-8 file in a UTF-8 xterm. I did manage to segfault it, though, so it's not a finished work. Also, I'm not sure whether it can do 8-bit charsets or only UTF-8. Worth looking at, I think. There isn't a Debian package yet. Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#95018: UTF-8 Patch breaks slrn display on UTF-8 terminal
Jim Mintha <[EMAIL PROTECTED]>: > There seem to be a whole bunch of problems with the utf8 slang > packages. People are having trouble with slrn, lynx, etc. Possibly > these packages just need to be recompiled but the following seems more > serious: > > > On Sat, Apr 21, 2001 at 11:36:38PM +0200 , Jim Mintha wrote: > > > I just uploaded them. (I just realized that i missed adding the > > > Closes, but I'll do it by hand) Let me know if there are problems. > > > > there are. like debconf/whiptail segfaulting. Not evern recompile helps. > > Arguably it's a bug in newt, because it's not using the correct slang type > > defines, but still. It changes the API of slang, so every program using it, > > must be recompiled. Also querybts doesn't work > > > > Petr Cech > > Any thoughts at what should be done? Can these be fixed, or should we > make a seperate slang-utf8 package? Was this the latest, patched newt that you recompiled (0.50.17-4)? If so, please tell me more about the segfault. The UTF-8 slang certainly has a changed binary interface, so recompilation of other packages is required. It's debatable whether you should call it a changed API, but it's not surprising if some packages require minor bug fixes as well as recompilation. The same fixes will be required for slang2, anyway. Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: woody bf-utf8 (Re: slang, boot-floppies, and wide character support)
Peter Novodvorsky <[EMAIL PROTECTED]>: > > So we should provide libutf8 package, or make bogl-bterm statically > > linked to libutf8 library. > > Bruno Haible's page states that libutf8 is needed only libc versions > below 2.2. So, 2.2.2-4 should work fine. This is correct. I stopped using libutf8 when I upgraded my libc6 to 2.2. The main difference with using glibc is that you have to set up the locale (by editing /etc/locale.gen and running localegen), whereas libutf8 just detects the mention of "UTF-8" in the appropriate environment variable (LANG or LC_*). The implementations are not identical, of course, so it is possible that using glibc instead of libutf8 will expose a bug that was previously hidden. Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: slang, boot-floppies, and wide character support
Adam Di Carlo <[EMAIL PROTECTED]>: > > Do you have a check list of the programs that will be linked against > > slang in boot-floppies? > > No, sorry. I just tried ldd on all the executable files in http://http.us.debian.org/debian/dists/potato/main/disks-i386/current/images-1.44/root.bin The ones linked against slang are: ae cfdisk dbootstrap It looks like the first two use slcurses.h, and the last one uses libnewt, which uses slang.h (slang proper). Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: slang, boot-floppies, and wide character support
> I shall try to produce an up-to-date slang-1.4.4-ege.diff soon. http://www.rano.org/mutt/slang-1.4.4-ege2.diff.gz Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: slang, boot-floppies, and wide character support
Adam Di Carlo <[EMAIL PROTECTED]>: > You seem to be avoiding the question here -- patch slang1, use > slang1-ja, or make a new slang1-wide package with these patches? It's hardly feasible to make a version of slang1 that works in UTF-8 and is bug-free and binary-compatible with ordinary slang1. (It's not impossible, but it's far too much effort.) So, if you want a slang1 that works in UTF-8, you should make a new slang1-wide package. If you want Japanese and UTF-8 support on the same floppy it would be worth investigating whether slang1-wide could be made to work in CJK encodings without too much trouble, as this would avoid wasting space for two versions of the same library. It would also mean there would be a united effort in making slang1 work in arbitrary encodings which would probably contribute to making slang2 happen. I would guess, based on my experience of what happened with Mutt, that not much extra has to be done to make slang1-wide (the patched slang1) support CJK encodings. But CJK speakers would have to help. Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: slang, boot-floppies, and wide character support
Adam Di Carlo <[EMAIL PROTECTED]>: > I have a patch from the boot-floppies archives to give slang wide > character support. I've attached that patch. Since making slang-1.4.0-ege5.diff I have fixed at least one bug and ported the patch to slang-1.4.2, I think. I shall try to produce an up-to-date slang-1.4.4-ege.diff soon. Please note that the patched slang1 is not binary compatible with the unpatched slang1. Making it binary compatible would be a horrible hack as the slang API exposes the internal representation of the contents of a screen cell as a 32-bit word. I have no idea whether the current patched slang is usable for Japanese; I have only used it for UTF-8. However, there's a good chance it might work for Japanese encodings. With glibc-2.2's wide character support it is possible to use the same code for UTF-8 as for Japanese character encodings. So it would nice if someone Japanese could try it or have a look. If we could patch slang1 so that it works with glibc-2.2 in UTF-8 or CJK encodings, but isn't binary-compatible with the unpatched slang1, would that be an acceptable solution for boot-floppies? Do you have a check list of the programs that will be linked against slang in boot-floppies? I don't know what's happening about slang2, but I assume it won't be ready in time for Woody. (There are parts of the slang API which I think should be redesigned to cope better with combining characters - needed in Thai, for example. We really need John Davis to contribute to updating the API for slang2.) Edmund -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
