Bug#517927: Install Error Lenny
Michael Richter richter.mich...@gmx.net writes: [...] While trying to install Lenny i always get the message unknown keyboard in configuration file I tried an USB- and a normal-Keyboard, even tried it without any keyboard plugged in. The error-message always appears and the booting-process stops. I can not say anything more, because i had no chance to go further than this step. [...] Did you check the md5sum of the image before burning it? This is an ugly and very strange error. -- O T A V I OS A L V A D O R - E-mail: ota...@debian.org UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] Debian Installer related scripts suitable for moving
* Otavio Salvador [Mon, 02 Mar 2009 20:10:34 -0300]: Hello, Hi, RM people has get in touch with me asking for which script we consider suitable for moving into release.debian.org. I'll note that our goal was/is to do whatever is needed to make your situation better in this regard. I think it was you who suggested this move would make things better for you, that's why I brought it back. Just clarifying this is not a Release Team must do it all! move. Christian writes: Still, having it run under a developer account is a small weakness So, another option would be for d-i to have its own role account, accessible for d-i RMs and other selected people, and that way you can be in charge of maintaining your own scripts. Now, two things: It was make clear to RM team that we need to be able to fix the scripts by ourselfs and I belive that it shouldn't be a problem. Well, if the scripts are going to be run on ftp-master under the release role account, I don't think it's possible to grant you direct modification access *to the code*. So, in this regard, this indeed adds a further level of indirection, and if what you want is to be able to commit to the VCS and have the next run pick up that code without human intervention, maybe you should consider the d-i role acount route. OTOH, for scripts that obtain data from the archive, I can easily provide the initial code attacking the projectb database (rather than the mirror), and the code is public, and patches should be fairly fast to integrate. Additionally, if there are scripts that work against a static list of packages (rather than, say, a dynamic list like all packages providing udebs), then *that static list* can be fetched from the d-i SVN repo, for example, which should account for most of the updates needed, once the code is stable. So, really, please think it over, talk with us about which are your goals and constraints, and we try to figure out what works best for everybody, okay? The only ones that come to my head are: 1. testing summary (http://merkel.debian.org/~joeyh/d-i/testing-summary.html) 2. building summary (http://people.debian.org/~joeyh/d-i/build-logs.html) There is also http://ftp-master.debian.org/d-i. Which has a planned revamp for ourselves, and I will move it to release.d.o at the same time. And, regarding #1 above, I confirm what I said on IRC: I am not able to maintain that, plus it doesn't work against the projectb database, so I'd rewrite it into something I can maintain: python + SQL + html templates. So, I'll wait to hear from you regarding all of the above. I'll repeat that our goal is to make things better for you, and that you have to help us figure out what that entails. Cheers! -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517854: Haven't install Chinese fonts and input engine in locale zh_HK
Christian Perrier wrote:
Quoting Arne Goetje (a...@linux.org.tw):
Christian Perrier wrote:
Damn. This is one of those cases where we suffer from the silly trick
of using zh_CN and zh_TW to differentiate between two different
*scripts*. I really dream of different ISO-639 codes for the two
different written versions of Chinese: Traditional and Simplified.
Err, no. Just use RFC4647 for the whole locale system.
zh-Hans = simplified
zh-Hant = traditional
Which, if I'm correct, would mean having zh-Hans_CN and
zh-Hant_TW|zh-Hant_HK locales, right ?
Almost. :)
RFC4647 uses hyphens instead of underscores.
The format is: langcode-script-territory-variation-x-usertags
where:
langcode = ISO 639-{1|2|3}
script = ISO 15924
territory = ISO 3166
variation = a predefined list of variation tags
x = separator between official tags and user defined tags
(literally 'x')
usertags = user defined tags
and everything except langcode is optional.
So, we would have locales zh-Hans-CN, zh-Hans-SG, zh-Hant-TW, zh-Hant-HK
and zh-Hant-MO. These of course could be shortened to what we have today
(zh-CN, zh-SG, zh-TW, zh-HK, zh-MO), but we would lose the ability to
have a simple fallback mechanism.
RFC4647 has been designed to provide a simple fallback mechanism, means
zh-Hant-MO would fallback to zh-Hant, which would fallback to zh.
nitpick Given that zh is actually a meta tag for any Chinese
language, it would probably even make sense to finally define what we
mean with zh, namely Mandarin Chinese, which has the ISO 639-3
language tag cmn. Means, the locales should actually be
cmn-{Hans|Hant}-{CN|SG|TW|HK|MO}. /nitpick ;)
I'm just convinced that upstream glibc won't want to walk that path.
Also meaning renaming PO files progressively as well.
It would be nice if we could implement this.
Yes, I'm still dreaming... ;)
Cheers
Arne
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517854: Haven't install Chinese fonts and input engine in locale zh_HK
On Tue, Mar 03, 2009 at 10:01:46PM +0800, Arne Goetje wrote:
Christian Perrier wrote:
Quoting Arne Goetje (a...@linux.org.tw):
Christian Perrier wrote:
Damn. This is one of those cases where we suffer from the silly trick
of using zh_CN and zh_TW to differentiate between two different
*scripts*. I really dream of different ISO-639 codes for the two
different written versions of Chinese: Traditional and Simplified.
Err, no. Just use RFC4647 for the whole locale system.
zh-Hans= simplified
zh-Hant = traditional
Which, if I'm correct, would mean having zh-Hans_CN and
zh-Hant_TW|zh-Hant_HK locales, right ?
Almost. :)
RFC4647 uses hyphens instead of underscores.
The format is: langcode-script-territory-variation-x-usertags
where:
langcode = ISO 639-{1|2|3}
script = ISO 15924
territory = ISO 3166
variation = a predefined list of variation tags
x = separator between official tags and user defined tags
(literally 'x')
usertags = user defined tags
and everything except langcode is optional.
Yes; however, RFC4647 defines locales in the context of the
Accept-Language and/or Accept-Encoding headers of RFC2616 (HTTP), which
use a different format from the LANG and LC_* environment variables on a
Unix system.
It is similar enough that we can adapt it for our needs, but then it'd
have to be something like zh-Hans_CN, indeed.
[...]
--
Lo-lan-do Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517859: Used kernel image for VIA C3 Nehemia
Hello, Otavio I read the Bug report #504095. Please merge this bug report with #504095. For completion, there is the output of /proc/cpuinfo in the attachement Regards Bernhard processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 9 model name : VIA Nehemiah stepping: 8 cpu MHz : 666.583 cache size : 64 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse rng rng_en ace ace_en bogomips: 1334.97 clflush size: 32 power management:
Re: debian-installer compile error
On Mon, Mar 02, 2009 at 09:29:35PM +0330, Sameer Rahmani wrote: so where is the problem ? […] KERNEL_FLAVOUR = di_1.76_i386 here Please try to figure things out by yourself before jumping on your keyboard to send an email to this *development* list. Cheers, -- Jérémy Bobbio.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#518018: installation-guide: Appendix B: mkpasswd example wrong
Subject: installation-guide: Appendix B: mkpasswd call wrong Package: installation-guide Version: 20081208 Severity: normal Hi, the mkpasswd example call in the examples for passwd/root-password-crypted says echo r00tme | mkpasswd -s -m md5 but that didn't work for me. (I can't log in with r00tme - OF course the password is something else here :) ) What is working is the following: echo -n r00tme | mkpasswd -s -m md5 because echo then omits the \n which would end up into the hash otherwise... -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' r...@debian.org | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Life - Un salto nella tua filiera
To view the message, please use an HTML compatible email viewer!
Re: [RFC] Debian Installer related scripts suitable for moving
Adeodato Simó d...@net.com.org.es writes: * Otavio Salvador [Mon, 02 Mar 2009 20:10:34 -0300]: Hello, Hi, RM people has get in touch with me asking for which script we consider suitable for moving into release.debian.org. I'll note that our goal was/is to do whatever is needed to make your situation better in this regard. I think it was you who suggested this move would make things better for you, that's why I brought it back. We were at that time talking about the testing package status not being up to date and then we considered it was more logical to move it to a more appropriated place. IIRC this was the basis of our talking at that moment. Just clarifying this is not a Release Team must do it all! move. Sure. We're not considering it this way. Christian writes: Still, having it run under a developer account is a small weakness So, another option would be for d-i to have its own role account, accessible for d-i RMs and other selected people, and that way you can be in charge of maintaining your own scripts. I belive it works for us. Now, two things: It was make clear to RM team that we need to be able to fix the scripts by ourselfs and I belive that it shouldn't be a problem. Well, if the scripts are going to be run on ftp-master under the release role account, I don't think it's possible to grant you direct modification access *to the code*. So, in this regard, this indeed adds a further level of indirection, and if what you want is to be able to commit to the VCS and have the next run pick up that code without human intervention, maybe you should consider the d-i role acount route. OTOH, for scripts that obtain data from the archive, I can easily provide the initial code attacking the projectb database (rather than the mirror), and the code is public, and patches should be fairly fast to integrate. Additionally, if there are scripts that work against a static list of packages (rather than, say, a dynamic list like all packages providing udebs), then *that static list* can be fetched from the d-i SVN repo, for example, which should account for most of the updates needed, once the code is stable. So, really, please think it over, talk with us about which are your goals and constraints, and we try to figure out what works best for everybody, okay? Personally I belive that, after a small period of fixing, those scripts should ramain mostly unmodified for long time. I don't think we'd need to be able to push changes for next run. Most of things will appear as soon as we do the switch and then we'll be in touch to fix the remaning issues and getting it in a stable code. After that, I do belive we can use RM people as a proxy for getting things fixed. Even more due our nice collaboration we've been doing during Lenny and this new development cycle. The only ones that come to my head are: 1. testing summary (http://merkel.debian.org/~joeyh/d-i/testing-summary.html) 2. building summary (http://people.debian.org/~joeyh/d-i/build-logs.html) There is also http://ftp-master.debian.org/d-i. Which has a planned revamp for ourselves, and I will move it to release.d.o at the same time. Yes but this output could be merged into the testing-summary. And, regarding #1 above, I confirm what I said on IRC: I am not able to maintain that, plus it doesn't work against the projectb database, so I'd rewrite it into something I can maintain: python + SQL + html templates. I have no objection on that. I'm used to Python and SQL and can help fixing things if required. So, I'll wait to hear from you regarding all of the above. I'll repeat that our goal is to make things better for you, and that you have to help us figure out what that entails. Sure. Before you start working on the scripts, give some time for people to comment. Cheers, -- O T A V I OS A L V A D O R - E-mail: ota...@debian.org UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517859: Used kernel image for VIA C3 Nehemia
forcemerge 517859 504095 retitle 517859 wrong kernel used for VIA Nehemiah processor thanks Bernhard bwo...@online.de writes: Hello, Otavio I read the Bug report #504095. Please merge this bug report with #504095. [...] So I did. -- O T A V I OS A L V A D O R - E-mail: ota...@debian.org UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed (with 1 errors): Re: Bug#517859: Used kernel image for VIA C3 Nehemia
Processing commands for cont...@bugs.debian.org: forcemerge 517859 504095 Bug#517859: Wrong kernel installed at VIA C3 Bug#504095: installation-report: xen paravirt installation Mismatch - only Bugs in the same package can be forcibly merged: Bug 504095 is not in the same package as 517859 retitle 517859 wrong kernel used for VIA Nehemiah processor Bug#517859: Wrong kernel installed at VIA C3 Changed Bug title to `wrong kernel used for VIA Nehemiah processor' from `Wrong kernel installed at VIA C3'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517900: installation-reports
Improwed file extenion for log files -- С уважением, Vladimir mailto:afanasev...@mail.ru installog.tar.gz Description: GNU Zip compressed data
Re: Installation of sudo based systems
Luk Claes wrote: Hi Jérémy pointed me to this outstanding issue, so I had a look... On Wed, 26 Sep 2007 00:00:45 +0200, Jérémy Bobbio wrote: On Wed, Sep 26, 2007 at 12:42:44AM +0300, Eddy Petrișor wrote: I know that adding another question at high priority might not be a good idea, so an option would be to enable (or ask a confirmation) sudo based installation if the user enters an empty root password during user-setup. Of course, that under the condition that the text displayed at that point says clearly that entering an empty password would lead to such a behaviour. That was my intention. :) Sorry for not being totally clear about it. Please find attached a first try at d-i hacking to implement the above :-) Note that I didn't test it yet. Is there some documentation available to ease testing in some virtual machine setup? Cheers Luk -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517854: Haven't install Chinese fonts and input engine in locale zh_HK
Quoting Arne Goetje (a...@canonical.com):
nitpick Given that zh is actually a meta tag for any Chinese
language, it would probably even make sense to finally define what we
mean with zh, namely Mandarin Chinese, which has the ISO 639-3
language tag cmn. Means, the locales should actually be
cmn-{Hans|Hant}-{CN|SG|TW|HK|MO}. /nitpick ;)
Does it make any sense, here ?
My understanding (but I might be entirely wrong) was, up to now, that
when it comes at written languages, there is basically no point in
making a difference between Mandarin and Cantonese (or other
variants)both being written in either the Traditional way or the
Simplified.
So, roughly, I was understanding Mandarin and Cantonese as two
different spoken language...which happen to be written the same way.
Therefore, as software application is mostly about written languages,
it would not make sense to make a difference between Madarin and other
*spoken* languages.
But, maybe, I'm over-simplificating and you, Arne, know certainly much
more than me about this..:-)
signature.asc
Description: Digital signature
Processed: Re: Bug#517854: Haven't install Chinese fonts and input engine in locale zh_HK
Processing commands for cont...@bugs.debian.org: reassign 517854 tasksel Bug#517854: Haven't install Chinese fonts and input engine in locale zh_HK Bug reassigned from package `debian-installer' to `tasksel'. tags 517854 patch Bug#517854: Haven't install Chinese fonts and input engine in locale zh_HK There were no tags set. Tags added: patch thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517854: Haven't install Chinese fonts and input engine in locale zh_HK
reassign 517854 tasksel tags 517854 patch thanks Quoting Roy Chan (voi...@gmail.com): Package: debian-installer Version: 20090123 The Debian Installer of Debian 5.0.0 don't install chinese fonts and input engine when people choose Traditional Chinese and Hong Kong as the language and region (locale zh_HK). This make the installed Debian system fail to display Chinese but only square symbol. The installer should install ttf-arphic-uming, scim-tables-zh im-switch or any packages required in zh_TW in order to provide a function-able zh_HK environment. I had tested it with Debian 5.0.0 businesscard i386 installation CD several times. Choosing taiwan produce correct Chinese environment but choosing hong kong produce messing environment. The attach patch should fix this problem. We probably have a similar problem with zh_SG. What is used in Singapore? Traditional or Simplified? diff --git a/tasks/chinese-t b/tasks/chinese-t index 3aea4c6..2ee50df 100644 --- a/tasks/chinese-t +++ b/tasks/chinese-t @@ -1,5 +1,5 @@ Task: chinese-t -Test-lang: zh_TW +Test-lang: zh_TW zh_HK Section: l10n Description: Traditional Chinese environment This task installs programs, data files, fonts, and signature.asc Description: Digital signature
Bug#517854: Haven't install Chinese fonts and input engine in locale zh_HK
Quoting Clint Adams (sch...@debian.org): On Tue, Mar 03, 2009 at 10:06:56PM +0100, Christian Perrier wrote: We probably have a similar problem with zh_SG. What is used in Singapore? Traditional or Simplified? They switched to Simplified quite some time ago. Malaysia is still using Traditional, and I'm not sure about Indonesia but I think they're also Traditional. For Malaysia and Indonesia, we don't have the problem as there is no locale..:-) So, zh_SG should be added to the chinese-s task, in Test-Lang, just like I proposed for zh_HK being added in chinese-t signature.asc Description: Digital signature
Bug#517854: Haven't install Chinese fonts and input engine in locale zh_HK
On Tue, Mar 03, 2009 at 10:06:56PM +0100, Christian Perrier wrote: We probably have a similar problem with zh_SG. What is used in Singapore? Traditional or Simplified? They switched to Simplified quite some time ago. Malaysia is still using Traditional, and I'm not sure about Indonesia but I think they're also Traditional. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516347: debian-installer: guided-with-lvm no longer allows multiple primary partition
Hi,
Looking closer at partman logs, I now doubt that this is a
partman-auto-lvm specific issue.
The disk size as seen by the installer is 10947133440 bytes
The initial preseeded recipe is :
96 128 128 ext3 $primary{ } $bootable { } method{ format } \
format{ } use_filesystem{ } filesystem{ ext3 }
mountpoint{ /boot } . \
100 1000 -1 ext3 $lvmok{ } method{ format } format{ } \
use_filesystem{ } filesystem{ ext3 } mountpoint{ / }
Which is transformed by expand_recipe into the following actual scheme
for creating the primary partitions :
128 0 128 ext3 $primary{ } $bootable { } method{ format } \
format{ } use_filesystem{ } filesystem{ ext3
} mountpoint{ /boot } . \
10819 96 -1 ext3 $primary{ } method{ lvm }
This scheme should fit on the disk (10819+128=10947 MiB)
But the partman log extract at the end of this post shows that :
1) when parted_server is asked to create a 128 MiB partition at the
beginning of the disk,
It creates a 131.6 MiB (131604480 bytes) partition beginning at
position 32256, and ending at 131604479.
2) parted_server is then asked to create a 10819 MiB primary partition
to hold the physical volume,
but starting at position 131604480, it can find enough space on the
disk and fails :
How can the gap between what is asked and what is performed by
parted_server be explained ?
- 131572224 B doesn't equal 128 MB, so an International System Units
vs binary Units mismatch doesn't seem to be involved.
- the disk size seems not to be involved either, as having tried a lvm
preseeded recipe on a 70 GB physical hard drive have given the same
result (will try tomorrow with bigger disks)
- is some overhead missing in the partition size calculation by expand_recipe ?
- should the scheme be recomputed with feedback from the parted_server
before creating following partitions ?
On Etch, the same recipe works because the default behavior is to
create the physical volume in a logical partition, using the entire
free space (position parameter set to full).
Any thoughts/questions on the subject are welcome :
- directions to look further
- examples of lvm preseed recipe working with the lenny installer
- requests for precision or execution traces
Regards.
Simon Walter.
Partman log extract :
parted_server: main_loop: iteration 30
parted_server: Opening infifo
/bin/autopartition-lvm: IN: NEW_PARTITION =dev=hda primary ext3
0-10947133439 beginning 12801
parted_server: Read command: NEW_PARTITION
parted_server: command_new_partition()
parted_server: Note =dev=hda as changed
parted_server: Opening outfifo
parted_server: requested partition with type primary
parted_server: requested partition with file system ext3
parted_server: add_primary_partition(disk(21381120),0-25)
parted_server: OUT: OK
parted_server: OUT: 1 32256-131604479 131572224 primary ext3
/dev/hda1
parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 31
parted_server: Opening infifo
/bin/autopartition-lvm: IN: PARTITIONS =dev=hda
parted_server: Read command: PARTITIONS
parted_server: command_partitions()
parted_server: Opening outfifo
parted_server: OUT: OK
parted_server: OUT: 1 32256-131604479 131572224 primary ext3
/dev/hda1
parted_server: OUT: -1 131604480-10939622399 10808017920
pri/log free/dev/hda-1
parted_server: Partitions printed
parted_server: OUT:
parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 32
parted_server: Opening infifo
/bin/autopartition-lvm: IN: PARTITION_INFO =dev=hda 131604480-10939622399
parted_server: Read command: PARTITION_INFO
parted_server: command_partition_info()
parted_server: Opening outfifo
parted_server: command_partition_info: info for partition with id
131604480-10939622399
parted_server: partition_with_id(131604480-10939622399)
parted_server: OUT: OK
parted_server: command_partition_info: partition found
parted_server: OUT: -1 131604480-10939622399 10808017920
pri/log free/dev/hda-1
parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 33
parted_server: Opening infifo
/bin/autopartition-lvm: IN: NEW_PARTITION =dev=hda primary ext3
131604480-10939622399 beginning 1081901
parted_server: Read command: NEW_PARTITION
parted_server: command_new_partition()
parted_server: Note =dev=hda as changed
parted_server: Opening outfifo
parted_server: requested partition with type primary
parted_server: requested partition with file system ext3
parted_server: add_primary_partition(disk(21381120),257040-21387899)
parted_server: OUT: Error
parted_server: OUT: Can't have a partition outside the disk!
parted_server: OUT:
parted_server: OUT: Cancel
parted_server: OUT:
open_dialog NEW_PARTITION primary ext3 0-10947133439 beginning 12801
parted_server: OUT: 1 32256-131604479 131572224 primary ext3
/dev/hda1
/bin/autopartition-lvm: IN: NEW_PARTITION =dev=hda primary ext3
131604480-10939622399
software speech synthesis in d-i?
Hello, I'm starting thinking about _software_ speech synthesis in d-i. A simple solution would be to use espeakup, which connects the espeak software speech synthesis to speakup. That would however depend on: - sound kernel modules - a libespeak udeb and the latter depends on - a libstdc++ udeb - a libportaudio udeb - a libasound udeb Does it sound reasonable to debian-boot and maintainers of the corresponding packages? (I guess that will take a few MBs on the image...) I've already started to work a bit on the sound kernel modules part, something like a sound-pcm-modules kernel wedge. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518088: mklibs handling of STT_SPARC_REGISTER on SPARC64
Package: mklibs
Tags: patch
(Patch previously sent at
http://lists.debian.org/debian-boot/2008/09/msg00860.html, pinged at
http://lists.debian.org/debian-boot/2009/03/msg00049.html. Patch still
applies to current mklibs SVN.)
This patch fixes a problem using mklibs for SPARC64. The psABI for this
platform involves undefined, null-name symbols of type STT_SPARC_REGISTER
describing how registers are used by objects, which are not of any use to
mklibs (which cannot handle unnamed symbols in the output of
mklibs-readelf).
Index: src/mklibs-readelf/main.cpp
===
--- src/mklibs-readelf/main.cpp (revision 55961)
+++ src/mklibs-readelf/main.cpp (working copy)
@@ -82,15 +82,18 @@
}
}
-static void process_symbols_undefined (const
Elf::section_typeElf::section_type_DYNSYM *section)
+static void process_symbols_undefined (const
Elf::section_typeElf::section_type_DYNSYM *section, uint16_t machine)
{
for (std::vectorElf::symbol *::const_iterator it = section-get_symbols
().begin (); it != section-get_symbols ().end (); ++it)
{
const Elf::symbol *symbol = *it;
uint8_t bind = symbol-get_bind ();
uint16_t shndx = symbol-get_shndx ();
+uint8_t type = symbol-get_type ();
if (shndx != SHN_UNDEF)
continue;
+if (machine == EM_SPARCV9 type == STT_SPARC_REGISTER)
+ continue;
if (bind == STB_GLOBAL || bind == STB_WEAK)
std::cout
symbol-get_name_string () ' '
@@ -125,7 +128,8 @@
process_symbols_provided (file-get_section_DYNSYM ());
break;
case COMMAND_PRINT_SYMBOLS_UNDEFINED:
- process_symbols_undefined (file-get_section_DYNSYM ());
+ process_symbols_undefined (file-get_section_DYNSYM (),
+file-get_machine ());
break;
}
}
--
Joseph S. Myers
jos...@codesourcery.com
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
C++ in d-i?
On 02:16 Wed 04 Mar , Samuel Thibault wrote: Hello, Hi, - a libstdc++ udeb I already raised the question about this udeb in 2005. I think there are some interesting software written in C++ that could be nice to have in d-i. Im thinking of gparted. If the d-i team agreed to have this library in d-i, I would be happy to rework on having gparted working. Greetings, -- ,''`. Xavier Oswald x.osw...@free.fr : :' : GNU/LINUX Debian Maintainer `. `' GnuPG Key ID 0x88BBB51E `-938D D715 6915 8860 9679 4A0C A430 C6AA 88BB B51E -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517854: Haven't install Chinese fonts and input engine in locale zh_HK
Christian Perrier wrote:
Quoting Arne Goetje (a...@canonical.com):
nitpick Given that zh is actually a meta tag for any Chinese
language, it would probably even make sense to finally define what we
mean with zh, namely Mandarin Chinese, which has the ISO 639-3
language tag cmn. Means, the locales should actually be
cmn-{Hans|Hant}-{CN|SG|TW|HK|MO}. /nitpick ;)
Does it make any sense, here ?
My understanding (but I might be entirely wrong) was, up to now, that
when it comes at written languages, there is basically no point in
making a difference between Mandarin and Cantonese (or other
variants)both being written in either the Traditional way or the
Simplified.
So, roughly, I was understanding Mandarin and Cantonese as two
different spoken language...which happen to be written the same way.
Nope, certainly not. Those languages use different characters and
different vocabulary. Even when they use the same characters, those
occasionally do have entirely different meanings. That said, one who is
able to read Mandarin, is not automatically able to understand written
Cantonese or any other Chinese language.
But as I indicated, it's nitpicking as the zh tag is commonly associated
with Mandarin Chinese and we use ISO639-3 tags for the other Chinese
languages already.
Cheers
Arne
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Structure of a debian-installer boot CD
hi , what is the structure of a bootable cd that contain debian installer? -- Lucifer
