Bug#631314: [cowbuilder] --create fails when removing original tree
Please file a bug against debootstrap. At Sun, 26 Jun 2011 13:31:26 +0200, Emil Langrock wrote: On Sunday 26 June 2011 09:51:27 Emil Langrock wrote: On Sunday 26 June 2011 11:06:05 you wrote: Does it still happen? It doesn't happen for me today. Yes, I still have that problem. But it seems that your newest upload of cowbuilder wasn't accepted yet. it seems to work when I have only cdebootstrap installed -- Emil Langrock -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r569sd96.dancerj%dan...@netfort.gr.jp
Bug#562143: apt is no longer in base system created by debootstrap? (Re: Bug#562143: fails on cowbuilder --create)
It seems like apt is not installed with debootstrap anymore. And it seems to be staying like this. I'm not sure when this happened, but apt used to be build-essential=yes but now it's not. At Wed, 23 Dec 2009 07:53:54 +0100, Soeren Sonnenburg wrote: [1 text/plain; ISO-8859-15 (quoted-printable)] On Wed, 2009-12-23 at 15:28 +0900, Junichi Uekawa wrote: Sounds like a bug for debootstrap, no? Indeed! At Wed, 23 Dec 2009 07:15:53 +0100, Soeren Sonnenburg wrote: Package: cowbuilder Version: 0.60 Severity: grave I guess apt is missing ... sudo cowbuilder --create [...] I: Configuring libtimedate-perl... I: Configuring dpkg-dev... I: Configuring build-essential... I: Base system installed successfully. I: debootstrap finished I: copying local configuration I: Installing apt-lines I: Refreshing the base.tgz I: upgrading packages I: mounting /proc filesystem I: mounting /dev/pts filesystem I: installing dummy policy-rc.d chroot: failed to run command `/usr/bin/apt-get': No such file or directory I: unmounting dev/pts filesystem I: unmounting proc filesystem pbuilder create failed forking: rm -rf /var/cache/pbuilder/base.cow -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-sonne (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cowbuilder depends on: ii cowdancer 0.60 Copy-on-write directory tree utili ii libc6 2.10.2-2 GNU C Library: Shared libraries ii pbuilder 0.194 personal package builder for Debia cowbuilder recommends no packages. cowbuilder suggests no packages. -- no debconf information Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 [2 This is a digitally signed message part application/pgp-signature (7bit)] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562143: fails on cowbuilder --create
Hmm... similar bug, one year ago. https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/254042 At Wed, 23 Dec 2009 07:53:54 +0100, Soeren Sonnenburg wrote: [1 text/plain; ISO-8859-15 (quoted-printable)] On Wed, 2009-12-23 at 15:28 +0900, Junichi Uekawa wrote: Sounds like a bug for debootstrap, no? Indeed! At Wed, 23 Dec 2009 07:15:53 +0100, Soeren Sonnenburg wrote: Package: cowbuilder Version: 0.60 Severity: grave I guess apt is missing ... sudo cowbuilder --create [...] I: Configuring libtimedate-perl... I: Configuring dpkg-dev... I: Configuring build-essential... I: Base system installed successfully. I: debootstrap finished I: copying local configuration I: Installing apt-lines I: Refreshing the base.tgz I: upgrading packages I: mounting /proc filesystem I: mounting /dev/pts filesystem I: installing dummy policy-rc.d chroot: failed to run command `/usr/bin/apt-get': No such file or directory I: unmounting dev/pts filesystem I: unmounting proc filesystem pbuilder create failed forking: rm -rf /var/cache/pbuilder/base.cow -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-sonne (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cowbuilder depends on: ii cowdancer 0.60 Copy-on-write directory tree utili ii libc6 2.10.2-2 GNU C Library: Shared libraries ii pbuilder 0.194 personal package builder for Debia cowbuilder recommends no packages. cowbuilder suggests no packages. -- no debconf information Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 [2 This is a digitally signed message part application/pgp-signature (7bit)] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562143: fails on cowbuilder --create
reassign 562143 ftp.debian.org reopen 562143 thanks Hi, This bug is probably manifestation of ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/germinate/+bug/254042 Apt is included in somewhere from Recommends, and is priority important, so it is considered not build-essential; but it is build-essential. At Wed, 23 Dec 2009 07:53:54 +0100, Soeren Sonnenburg wrote: On Wed, 2009-12-23 at 15:28 +0900, Junichi Uekawa wrote: Sounds like a bug for debootstrap, no? Indeed! At Wed, 23 Dec 2009 07:15:53 +0100, Soeren Sonnenburg wrote: Package: cowbuilder Version: 0.60 Severity: grave I guess apt is missing ... sudo cowbuilder --create [...] I: Configuring libtimedate-perl... I: Configuring dpkg-dev... I: Configuring build-essential... I: Base system installed successfully. I: debootstrap finished I: copying local configuration I: Installing apt-lines I: Refreshing the base.tgz I: upgrading packages I: mounting /proc filesystem I: mounting /dev/pts filesystem I: installing dummy policy-rc.d chroot: failed to run command `/usr/bin/apt-get': No such file or directory I: unmounting dev/pts filesystem I: unmounting proc filesystem pbuilder create failed forking: rm -rf /var/cache/pbuilder/base.cow -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-sonne (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cowbuilder depends on: ii cowdancer 0.60 Copy-on-write directory tree utili ii libc6 2.10.2-2 GNU C Library: Shared libraries ii pbuilder 0.194 personal package builder for Debia cowbuilder recommends no packages. cowbuilder suggests no packages. -- no debconf information Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521545: debootstrap: Failure while unpacking required package with --foreign debootstrap for sid in second stage
Package: debootstrap Version: 1.0.12 Severity: normal Today, debootstrap seems to die in second-stage with W: Failure while unpacking required packages. This will be attempted up to five times. I do not seem to get any debugging message, so it's hard to understand what might be wrong. $ ./pbuilder-i386.sh --create --debug forking: mke2fs -q -F -j -m1 -O sparse_super /home/dancer/tmp/base-i386.qemu forking: tune2fs -c 0 -i 0 /home/dancer/tmp/base-i386.qemu tune2fs 1.41.3 (12-Oct-2008) Setting maximal mount count to -1 Setting interval between checks to 0 seconds forking: mount -o loop /home/dancer/tmp/base-i386.qemu /var/cache/pbuilder/build//qemu.23871 - Invoking debootstrap forking: debootstrap --arch i386 --foreign sid /var/cache/pbuilder/build//qemu.23871 http://localhost:/debian/ I: Retrieving Release I: Retrieving Packages I: Retrieving Packages I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Found additional required dependencies: libdb4.7 I: Checking component main on http://localhost:/debian... I: Retrieving adduser I: Validating adduser I: Retrieving apt I: Validating apt I: Retrieving apt-utils I: Validating apt-utils I: Retrieving aptitude I: Validating aptitude I: Retrieving base-files I: Validating base-files I: Retrieving base-passwd I: Validating base-passwd I: Retrieving bash I: Validating bash I: Retrieving bsdmainutils I: Validating bsdmainutils I: Retrieving bsdutils I: Validating bsdutils I: Retrieving coreutils I: Validating coreutils I: Retrieving cpio I: Validating cpio I: Retrieving cron I: Validating cron I: Retrieving debconf I: Validating debconf I: Retrieving debconf-i18n I: Validating debconf-i18n I: Retrieving debian-archive-keyring I: Validating debian-archive-keyring I: Retrieving debianutils I: Validating debianutils I: Retrieving dhcp3-client I: Validating dhcp3-client I: Retrieving dhcp3-common I: Validating dhcp3-common I: Retrieving diff I: Validating diff I: Retrieving dmidecode I: Validating dmidecode I: Retrieving dpkg I: Validating dpkg I: Retrieving e2fslibs I: Validating e2fslibs I: Retrieving e2fsprogs I: Validating e2fsprogs I: Retrieving ed I: Validating ed I: Retrieving findutils I: Validating findutils I: Retrieving gcc-4.2-base I: Validating gcc-4.2-base I: Retrieving gcc-4.3-base I: Validating gcc-4.3-base I: Retrieving gnupg I: Validating gnupg I: Retrieving gpgv I: Validating gpgv I: Retrieving grep I: Validating grep I: Retrieving groff-base I: Validating groff-base I: Retrieving gzip I: Validating gzip I: Retrieving hostname I: Validating hostname I: Retrieving ifupdown I: Validating ifupdown I: Retrieving info I: Validating info I: Retrieving initscripts I: Validating initscripts I: Retrieving iproute I: Validating iproute I: Retrieving iptables I: Validating iptables I: Retrieving iputils-ping I: Validating iputils-ping I: Retrieving libacl1 I: Validating libacl1 I: Retrieving libattr1 I: Validating libattr1 I: Retrieving libblkid1 I: Validating libblkid1 I: Retrieving libbz2-1.0 I: Validating libbz2-1.0 I: Retrieving libc6 I: Validating libc6 I: Retrieving libcomerr2 I: Validating libcomerr2 I: Retrieving libconsole I: Validating libconsole I: Retrieving libcwidget3 I: Validating libcwidget3 I: Retrieving libdb4.6 I: Validating libdb4.6 I: Retrieving libdb4.7 I: Validating libdb4.7 I: Retrieving libdevmapper1.02.1 I: Validating libdevmapper1.02.1 I: Retrieving libept0 I: Validating libept0 I: Retrieving libgcc1 I: Validating libgcc1 I: Retrieving libgcrypt11 I: Validating libgcrypt11 I: Retrieving libgdbm3 I: Validating libgdbm3 I: Retrieving libgnutls26 I: Validating libgnutls26 I: Retrieving libgpg-error0 I: Validating libgpg-error0 I: Retrieving liblocale-gettext-perl I: Validating liblocale-gettext-perl I: Retrieving libncurses5 I: Validating libncurses5 I: Retrieving libncursesw5 I: Validating libncursesw5 I: Retrieving libnewt0.52 I: Validating libnewt0.52 I: Retrieving libpam-modules I: Validating libpam-modules I: Retrieving libpam-runtime I: Validating libpam-runtime I: Retrieving libpam0g I: Validating libpam0g I: Retrieving libpopt0 I: Validating libpopt0 I: Retrieving libreadline5 I: Validating libreadline5 I: Retrieving libsasl2-2 I: Validating libsasl2-2 I: Retrieving libselinux1 I: Validating libselinux1 I: Retrieving libsepol1 I: Validating libsepol1 I: Retrieving libsigc++-2.0-0c2a I: Validating libsigc++-2.0-0c2a I: Retrieving libslang2 I: Validating libslang2 I: Retrieving libss2 I: Validating libss2 I: Retrieving libssl0.9.8 I: Validating libssl0.9.8 I: Retrieving libstdc++6 I: Validating libstdc++6 I: Retrieving libtasn1-3 I: Validating libtasn1-3 I: Retrieving libtext-charwidth-perl I: Validating libtext-charwidth-perl I: Retrieving libtext-iconv-perl I: Validating libtext-iconv-perl I: Retrieving libtext-wrapi18n-perl I: Validating libtext-wrapi18n-perl I: Retrieving libusb-0.1-4 I: Validating libusb-0.1-4 I:
Bug#521545: debootstrap: Failure while unpacking required package with --foreign debootstrap for sid in second stage
Hi, At Sat, 28 Mar 2009 09:58:35 -0300, Otavio Salvador wrote: Junichi Uekawa dan...@netfort.gr.jp writes: I: Unpacking zlib1g... W: Failure while unpacking required packages. This will be attempted up to five times. It looks like your .deb is broken; could you check it testing the package of your temp dir? I found that there was /debootstrap/debootstrap.log, which contained useful error messages from dpkg. I think this bugreport should be closed now that I have found the problem lies somewhere else. However, it would be nice if /debootstrap/debootstrap.log is documented somewhere, or '--verbose' option did something useful, or debootstrap gave me any error message in console. I filed #521549 for this specific bug: Preparing to replace debianutils 3.0 (using debianutils_3.0_i386.deb) ... Unpacking replacement debianutils ... . . Unpacking sensible-utils (from sensible-utils_0.0.1_all.deb) ... dpkg: error processing sensible-utils_0.0.1_all.deb (--unpack): trying to overwrite `/usr/share/man/fr/man1/sensible-editor.1.gz', which is also in package debianutils Preparing to replace sysvinit-utils 2.86.ds1-61 (using sysvinit-utils_2.86.ds1-61_i386.deb) ... Unpacking replacement sysvinit-utils ... -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#405627: debootstrap: /etc/hosts is needed to run pbuilder
Hi, On Fri, Jan 05, 2007 at 12:19:51AM -0200, Joao Eriberto Mota Filho wrote: Package: debootstrap The /etc/hosts file isn't copied to destination by debootstrap and the pbuilder command needs this file to work correctly. Without /etc/hosts the pbuilder create command shows: E: /etc/hosts does not exist, your setup is insane. fix it cp: cannot stat `/etc/hosts': No such file or directory - Aborting with an error Do you have any comments on the previous bug report? What should be the correct behaviour for debootstrap? I don't think it has been clearly defined, however, in practical terms, /etc/hosts is a machine-dependent configuration. Copying /etc/hosts to be the same might not be a good idea, since debootstrap can create chroots for use on other machines. Isn't the problem avoided when pbuilder create is used? Yes. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installing elilo on MacMiniIntel fails
Hi, here's a full log of my macbook Does your macbook has the bootcamp upgraded firmware? Note that macbooks are initially shipped with 'bootcamp upgraded firmware' that supports BIOS emulation. I think ELILO doesn't work with Debian kernel right now without the patches, so it's currently impossible to boot from EFI[1]. [1] http://bugs.debian.org/376002 regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installing elilo on MacMiniIntel fails
Hi,
$ chroot /target apt-get install refit
$ /target/sbin/gptsync /dev/sda
$ chroot /target
$ lilo /dev/sda3
(ignoring some warnings from lilo)
After this the installation continued fine, and I have no a running Debian
system.
If we can identify a way to discover if it's truely a MacIntel machine
we can make it transparent to end user ... let's see if we can do
that.
dmidecode tells you that it's:
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Apple Computer, Inc.
Product Name: MacBook1,1
Version: 1.0
Serial Number: 4H6231PKU9D
UUID: 9CFE245E-D0C8-BD45-A79F-54EA5FBD3D97
Wake-up Type: Power Switch
SKU Number: System SKUNumber
Family: Napa Mac
Product Name should be enough.
Looking around at kernel patches, they seem to be checking for this also:
http://lkml.org/lkml/2006/7/16/18
+static struct dmi_system_id __initdata pci_mmcfg_dmi_system_apple[] = {
+ { pci_mmcfg_force_system, iMac4,1, {
+ DMI_MATCH(DMI_BIOS_VENDOR,Apple Computer, Inc.),
+ DMI_MATCH(DMI_BIOS_VERSION,iMac4,1) }},
+ { pci_mmcfg_force_system, MacBookPro1,1, {
+ DMI_MATCH(DMI_BIOS_VENDOR,Apple Computer, Inc.),
+ DMI_MATCH(DMI_BIOS_VERSION,MacBookPro1,1) }},
+ { pci_mmcfg_force_system, MacBook1,1, {
+ DMI_MATCH(DMI_BIOS_VENDOR,Apple Computer, Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME,MacBook1,1)}},
+ { pci_mmcfg_force_system, Macmini1,1, {
+ DMI_MATCH(DMI_BIOS_VENDOR,Apple Computer, Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME,Macmini1,1)}},
+ {},
+};
regards,
junichi
--
[EMAIL PROTECTED],netfort.gr.jp} Debian Project
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installing elilo on MacMiniIntel fails
Hi, After electing elilo (GRUB/LILO were presented as alternatives) installing elilo stalled at 50%. I had accepted to install into the only presented partition (/dev/sda1, about 200 MB FAT32 partition, partman reported 3.1 kB free memory before.). This first partition was created my the Apple DiskUtility. /dev/sda6 where I installed the base system was formatted as an ext3 24 GB FS using the Debian installer. try running gptsync. Then installing lilo to partition / grub to partition shoud work. They are looking at FAT tables, not GPT, so you need to clone the data from GPT to FAT, since parted will reset FAT (to the letter of EFI spec). see http://wiki.debian.org/MacBook, which seems to be the most actively maintained out of all intel-mac related pages. We should probably start thinking about consolidating them. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Progress report on CodeFestAkihabara, macbook Debian installation experience
Hi, # apt-get install refit (when it enters past the NEW queue) # gptsync /dev/sda I've temporarily put refit packages on: http://www.netfort.gr.jp/~dancer/tmp/20060702/ I chrooted into /target from the second console of d-i and copied the deb package I got from your link. I the installed it and run # gptsync /dev/sda I then installed lilo and rebooted into osx; installed refit inside osx and now I can succesfully dual boot. Thanx alot for you help. I think parted is being clever and complying with the spec; which means it's creating a MBR FAT(fdisk) partition table containing only one partition. This means if you install with debian-installer, you have a broken FAT partition and a correct GPT partition. At this time, calling gptsync will 'fix' the partition table. Then, you will be able to install lilo, to the partition. Note that you don't install lilo to MBR, because MBR doesn't mean much to MacBook EFI; if you install to the partition, rEFIt will chain load for you. lilo will need to read the FAT partition table, which means GPT and FAT needs to be synced. Also it means that partition to install lilo needs to reside on the first 4 partitions, since FAT only has 4 primary partitions. BTW, the patch below is needed to avoid some warnings Davide [EMAIL PROTECTED]:~/refit/refit-0.7$ diff -u debian/rules.orig debian/rules --- debian/rules.orig 2006-07-03 21:05:28.0 +0200 +++ debian/rules2006-07-04 01:28:42.0 +0200 @@ -42,7 +42,7 @@ -$(MAKE) -C refit clean -$(MAKE) -C gptsync -f Makefile.unix clean #-$(MAKE) -C gptsync -f Makefile clean - -rm gptsync/*.so gptsync/*.o gptsync/gptsync.efi + -rm -f gptsync/*.so gptsync/*.o gptsync/gptsync.efi dh_clean Thanks for the patch. However, this warning could be useful sometimes. It is only emitted for the first-time build only. The error is ignored with a '-' at the beginning. For second-time build, a warning will mean that the rm command is trying to remove something that doesn't exist, which would be nice to know. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Progress report on CodeFestAkihabara, macbook Debian installation experience
Hi, -- Forwarded Message -- ... ... Current work around is to reboot into rEFIt and run gptsync, and then run d-i from CDROM, and then configure the bootloader. could you please give more details about this? # apt-get install refit (when it enters past the NEW queue) # gptsync /dev/sda I've temporarily put refit packages on: http://www.netfort.gr.jp/~dancer/tmp/20060702/ It really needs more work. but I don't know how to properly run this (usin bless I guess, but I have problems with the syntax) $ man bless (on MacOSX) I'm feeling quite stuck since it is impossible to install Debian without either an external storage or a MacOSX installation. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Persistent device names
Hi, Some enterprise-level storage systems have disk-level duplication system, as such, filesystem-label-based mount-point would not be the end-all way of approaching the problem. Can you describe which designs require this? I have never heard of such a setup, and I have some doubts that it's something that should be supported. High-end storage systems available from EMC and HP (at least) have mirror-copy and snapshot-copy features, which provides similar kind of feature-set to LVM snapshots. With LVM snapshots it will be less problem, because LVM volumes are somewhat more logical in its nature and we will have persistent path with LVM names; making filesystem UUID moot. However, for storage-based mirror-copy volumes, they will show up to the operating system as different SCSI/FC disks with same filesystem UUID. It might be less error-prone if bus/card info is used in addition to the filesystem UUID. by-path names are unique enough, anyway. by-path sounds like decently unique, as long as SCSI/FC cards are detected in the same proper order. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Persistent device names
Hi, - Are there likely to be architecture specific issues with persistent device naming? - Or with filesystems other than ext2/ext3? Nothing I know about. tree /dev/disk/ should give you some ideas. by-label links are user friendly, but may become ambiguous if users carelessly duplicate file systems using dd. by-uuid links have the same problem *and* need a suitable identifier in the file system metadata. by-id links are more unique but linked to the physical hardware (you can't have it both ways...) and are a bit ugly. by-path links are very descriptive and really unique, but are *really* unique and will change if a disk is moved to a different bus position or something like this. Some enterprise-level storage systems have disk-level duplication system, as such, filesystem-label-based mount-point would not be the end-all way of approaching the problem. It might be less error-prone if bus/card info is used in addition to the filesystem UUID. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installation difficulties
In trying to install my new copy of Woody ( which I received today) I repeatedly got the message debootstrap exited with an error (return value 1) I have tried installing on two machines, neither of very high quality, with the same result. I am not able to boot up the machine, so my ability to diagnose the problem is limited. You should be able to use a shell by pressing alt-f2 to switch the virtual terminal. You should be able to diagnose the problem. I think there might be something stale in /target/var/cache/, causing your problem. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: user documentation for d-i
I plan to export over the boot-floppies/documentation and import it into the debian-installer/documentation tree, to start the user-documentation task. Any objections, or better ideas? I'd like it so that boot-floppies/documentation is marked that this documentation is deprecated. It's very difficult to track what is deprecated at what point, so better do that sooner. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Alastair?
Hi, I get bounces when I try to mail him. ---BeginMessage--- Hi. This is the qmail-send program at viper2.netfort.gr.jp. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: 212.15.87.208 does not like recipient. Remote host said: 550 5.7.1 [EMAIL PROTECTED]... Relaying denied Giving up on 212.15.87.208. --- Below this line is a copy of the message. Return-Path: [EMAIL PROTECTED] Received: (qmail 10356 invoked from network); 31 Mar 2003 13:21:50 - Received: from unknown (HELO atoron.dancer.pr.jp.netfort.gr.jp) (127.0.0.1) by viper2.netfort.gr.jp with SMTP; 31 Mar 2003 13:21:50 - Date: Mon, 31 Mar 2003 22:20:21 +0900 Message-ID: [EMAIL PROTECTED] From: Junichi Uekawa [EMAIL PROTECTED] To: Alastair McKinstry [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Bug#186999: libnewt0: box lines not drawn on console, only xterm In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.4 - Hosorogi) Content-Type: text/plain; charset=US-ASCII Is this a bug? is there a solution? I think, for boot-floppies, we had a special TERM variable for BOGL, which was not linux. setting TERM=xterm on console does work, so I think there is something like that. regards, junichi ---End Message---
Re: Bug#183453: e2fsprogs-bf: Please provide a lintian override for man pages
Since it's a generic rule that *-bf packages should not contain manpages, I'm of the opinion that a new rule should be added to lintian, rather than adding overrides to all *-bf packages. Further more, since I don't think the new debian-installer is using those *-bf packages, but uses udeb's instead, those *-bf packages may be completely obsolete already. I've got an impression that -bf version is actually a version that is linked against -utf8 libraries. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: m68k, debian-installer, and DevFS
But you are right, we should get 2.4 working instead of hacking devfs into or out of d-i... Sure, but in the mean time we have to make sure there's an installer for m68k that actually works. Else we could just as well shut down all m68k buildd's, as it will not be worth it anymore. It would be nice to have somewhat working support for 2.2 kernels, for we might be unable to ship woody with decent support for some other arches. For example, I have been away from using sparc, but my question would be is there much sparc32 kernel hacking going on? Is 2.4.x usable on sparc32? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#182041: PIC library has bad name
mklibs fails to find the PIC library for reduction since it's called libnewt-utf8_pic.a while mklibs expects it to simply be libnewt_pic.a We're using newt debian-installer so it'd be nice if this were fixed so we could save some bytes on the boot media. :-) I have a few questions: I've thought boot-floppies worked with the name libnewt-utf8_pic.a. Why doesn't debian-installer mklibs not work with it? Because libnewt.so.0.50 is a symlink to libnewt-utf8.so.0.50.17. $ ldd tmp/cdrom/tree/usr/lib/cdebconf/frontend/newt.so libnewt.so.0.50 = /usr/lib/libnewt.so.0.50 (0x40005000) libc.so.6 = /lib/libc.so.6 (0x40014000) libslang.so.1-UTF8 = /lib/libslang.so.1-UTF8 (0x40124000) libm.so.6 = /lib/libm.so.6 (0x40185000) libdl.so.2 = /lib/libdl.so.2 (0x401a6000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) so mklibs only sees libnewt.so.0.50 and strips off the suffix and gets libnewt_pic.a. I got your point, regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#182041: PIC library has bad name
mklibs fails to find the PIC library for reduction since it's called libnewt-utf8_pic.a while mklibs expects it to simply be libnewt_pic.a We're using newt debian-installer so it'd be nice if this were fixed so we could save some bytes on the boot media. :-) I have a few questions: I've thought boot-floppies worked with the name libnewt-utf8_pic.a. Why doesn't debian-installer mklibs not work with it? And why does the boot media get some bytes free by changing the name here ? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Should all udeb binaries use UTF8 libraries?
I've noticed some udebs require on libslang.so.1, while the cdebconf slang frontend require libslang.so.1-UTF8. Should all udeb programs and libraries link with UTF8 versions of libraries, or should we leave it to the package maintainers? I was kind of hoping that we would be able to do away with the non-UTF8 libraries altogether during the sarge development cycle. Everything should be linking against the UTF8 versions in absence of any compelling reason to do differently. me also thinks that should be the case, except for an oddball (whiptail.so, which provides utf-8 verison and non-utf8 version), or unless the packages doesn't work with utf-8 version (which is rather unlikely, or broken). regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mini-debian system via network
I can do a big load at the boot of this mini-system, but due to technical constraints, i can't use a NFS exported partition (of a server) to realize it. What kind of technical constraints is it that you can't use a NFS exported partition? I usually find it convenient to use NFS-root. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: This bug should be fixed on boot-floppies side
I think this bug should be dealt on boot-floppies side. Shouldn't it ? HOW? It would be easy to add this to debootstrap's call, but if the packaging is missing in basedebs.tar, people installing from it would fail. So debootstrap would require an update, or at least a change in basedebs.tar building script and an update of basedebs.tar. I think Anthony is the one to make this decission. Yes, that shounds like it. I don't really like the way the amount of packages debootstrap installs is increasing, but that probably has to be done... There probably needs to be a long-sought distinction between base system and installation system regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
This bug should be fixed on boot-floppies side
eject is missing from the woody basedebs. On powerpc, this makes changing the CDs extremely awkward (newbies rarely dare poke a paper clip into the CD tray). Installation from CD is impeded severely, hence the severity of critical. I think this bug should be dealt on boot-floppies side. Shouldn't it ? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#140579: Report: tftpboot install successfull
I understand that. But just like we have a bunch of architectures, we have a bunch of netboot options. You generally don't have a lot of choices about what your hardware supports. Telling someone whose card doesn't support pxe to use pxe because it's better is no more sensible than telling an m68k user to use the i386 boot floppies because i386 is better. True enough. So why does that prevent us from giving an overview of the various options and providing some criteria to help users pick one or the other? It may be true that generally better or worse doesn't matter -- just anything that works will do. On installing Debian, it would be very difficult for users to get a ROM burning, however there would be a lot of eepro cards which can PXE boot. I would rather like to be able to netboot with grub floppies, so that it only requires one floppy (grub) to start up the installation, but that requires an extracted image of the installation disk to use as NFS root, and a kernel vmlinuz image available via TFTP. I don't think we provide either images per default, but it might be worth considering for an option in the future, if grub cannot load tftpboot images. For using GRUB to start install: set up server to allow TFTP, and provide vmlinuz, and allow nfs export. get grub source and recompile with network card support, and create a floppy using dd command. ./configure --enable-eepro100 make dd if=stage1/stage1 of=image dd if=stage2/stage2 of=image bs=512 seek=1 dd if=image of=/dev/fd0 ; sync Then start the machine with the floppy (the following example will work on many installations): grub ifconfig --address=192.168.1.2 --server=192.168.1.1 grub kernel (nd)/boot/vmlinuz init=/bin/sh root=/dev/nfs nfsroot=192.168.1.1:/,flags=ro init=/bin/sh grub boot The above example will load the kernel via eepro card from /boot/vmlinuz on 192.168.1.1, and use / of the 192.168.1.1 as the / of 192.168.1.2 (the one to be installed) read-only via NFS, using /bin/sh as initial program. It is trivial to start up dbootstrap in this way also. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk frontend status report
We still need to have an eye on the space that is occupied on the ramdisk. The udebs do not contain any unneeded modules or documentation and in some cases they use other compile options then their deb counterparts. They should not be deb/udeb counterparts that are binary-incompatible. Read http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html for what happened to boot-floppies when people had different newt/slang versions that were binary-incompatible. If we used the .deb we needed to pull in sdl and xlibs as well, what is certainly not what we want. This should be done with a new directfb package, with a completely different soname, and pkglibdir (or whereever directfb stores its plugins) regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk frontend status report
We are probably not going to have a floppy image from them (which will involve having PIC packages for each library package, which is a big burden) and if we are not going to need to fit on a floppy, what is the point of making a udeb for ? No, there is no way that they will fit on the floppy image. I tried to make pic files for all of them and reduce them by mklibs simultanously but that did not work out. What does not work out in what way ? But there is still need for the udebs. I am basically thinking of two scenarios: 1) Net Install: After finishing setting up your network, the libraries are pulled in by anna and the frontend can be changed. 2) CD Install: The Disk Image on CD automatically detects the CD Rom drive and sets up anna to pull in the libraries without further user interaction. IMHO this would be the interesting thing for the debian-desktop project. Since anna only handles udebs and the initial ramdisk is limited there is a need to package the prerequisite libraries into udebs. I would personally rather have anna only bootstrap enough so that apt works, than trying to have packages to be turned into udebs, or get anna working with installing debs if necessary. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk frontend status report
We still need to have an eye on the space that is occupied on the ramdisk. The udebs do not contain any unneeded modules or documentation and in some cases they use other compile options then their deb counterparts. A good example is directfb: They should change their sonames, at least this looks very problematic, and will result in relocation errors in some cases. Library from .deb: coyote:~# ldd /usr/lib/libdirectfb-0.9.so.15 libSDL-1.2.so.0 = /usr/lib/libSDL-1.2.so.0 (0x4004f000) libm.so.6 = /lib/libm.so.6 (0x400ba000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x400db000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x40195000) libdl.so.2 = /lib/libdl.so.2 (0x401a2000) libpthread.so.0 = /lib/libpthread.so.0 (0x401a5000) libc.so.6 = /lib/libc.so.6 (0x401f4000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) Library from .udeb coyote:~# ldd /home/sl/debian-installer/usr/lib/libdirectfb-0.9.so.15.0.0 libdl.so.2 = /lib/libdl.so.2 (0x4004b000) libpthread.so.0 = /lib/libpthread.so.0 (0x4004f000) libc.so.6 = /lib/libc.so.6 (0x4009e000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) If we used the .deb we needed to pull in sdl and xlibs as well, what is certainly not what we want. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk frontend status report
I've finally managed to build, but not test, udebs for glib, pango, and gtk+-directfb. I'm having doubts on whether we really need udebs for them. I want some clarification on this point. We are probably not going to have a floppy image from them (which will involve having PIC packages for each library package, which is a big burden) and if we are not going to need to fit on a floppy, what is the point of making a udeb for ? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#171027: boot-floppies
reassign 171027 boot-floppies Does it means changing Subject: for boot floppies? Sorry, if not. It is just a cosmetical/technical thing in the bug tracking system. Not related to the subject. At Thu, 28 Nov 2002 07:58:34 +0100, Ruzsinszky Attila wrote: architecture: sparc model: SUN SparcStation 2 memory:64MB scsi: built in cd-rom:none network card: built in pcmcia:none. Hi, I want to boot over network. My machine got the tftpboot.img file from the TFTP server and started it. On the console I could see: Booting Linux ... ... and that's all! Isn't it just being slow ? I don't know. How long do I have to wait? a.out is waiting for ~10-20secs. I waited many minutes. I will check again. sparc2 is probably been known to be very slow? Also, you may want to try with potato boot images as well (if you've tried only woody images). I don't know if sparc2 has been well tested. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Are we losing users to Gentoo?
Let's first have a working installer on at least a few arches before walking down that road. However, it is a problem which I was notified of a few days ago: d-i relies heavily on devfs and, well, 2.4 doesn't work on m68k and it doesn't look like it will in the foreseeable future. So, help with getting this worked out will be appreciated. I have an impression that 2.4 doesn't (still) work on sparc32 either. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debootstrap question
You seem to have already solved the problem, but pbuilder attempts at this problem and other things by doing a two-phase install. debootstrap the base system, then using APT to install the rest. A two-stage process does not help me. I am trying to build a small but complete system on a compactflash. There is no second stage after reboot. The CompactFlash will go directly into a different system. Ah, okay. So you are cross-installing for a different arch ? If you are native-installing on a flash, then you can chroot and run apt inside the debootstrapped directory. debootstrap is quite weak in some sense due to the fact that it does not take dependency trees in account, and you need to list all the required libs etc. to install, so this two-stage install method is feels quite natural. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debootstrap question
At Tue, 12 Nov 2002 18:24:08 -0500, Bao C. Ha [EMAIL PROTECTED] wrote: I am playing with debootstrap to build a custom base system. I would like to include freeswan in the list of deb packages. Unfortunately, freeswan is in the non-US archive. I just wonder if there is an easy way to do it through debootstrap. You seem to have already solved the problem, but pbuilder attempts at this problem and other things by doing a two-phase install. debootstrap the base system, then using APT to install the rest. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] libdebian-installer2
At 14 Nov 2002 00:10:32 +0100, Martin Sj�gren wrote: [1 text/plain (quoted-printable)] tis 2002-11-05 klockan 03.18 skrev Junichi Uekawa: But surely adding stuff to a data structure is a backward-incompatible change? It depends on the way you do it. You can add stuff to a data structure without breaking backwards compatibility. I'm considering adding more stuff to struct package_t, do you have any hints or pointers on how I should do it, then? You can add members at the end of struct if and only if any other application does not try to malloc it. Otherwise, interface probably needs to be bumped up. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch] cdebconf and i18n
Are you talking about language names? They are either ll or ll_LL. As everything will be UTF-8 encoded, there is no need to add encoding. There is probably a need to add a UTF-8 encoding something, but there probably isn't really a need. Why does it have to be char something[] when char * something will perfectly work ? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch] cdebconf and i18n
I was thinking more of if (locale == C) question user; else get country from locale. It doesn't work, you can't get country from locale, you must always ask user to tell where he lives. Huh? They are in language_country.codeset format. ja_JP is Japan, pt_BR is Brazil. What is the problem? Moreover where does this locale come from? IMO we should at the very beginning ask a. which language to use for installation b. geographic location (a la tzselect/tzconfig) That is the right direction. Introducing different locale variable is a wrong thing to do, however. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch] cdebconf and i18n
They are in language_country.codeset format. ja_JP is Japan, pt_BR is Brazil. What is the problem? [...] Do you really think that there are no Japanese people outside of Japan? Then they should use ja_CA or whatever they want. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch] cdebconf and i18n
Why does it have to be char something[] when char * something will perfectly work ? I did not say it has to be a char[6], I do not care if someone wants to malloc it. Please use strdup and friends, or asprintf, or other kind of things that are less prone to break. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch] cdebconf and i18n
Do you really think that there are no Japanese people outside of Japan? Then they should use ja_CA or whatever they want. No, this locale does not exist. That doesn't really matter if it doesn't currently exist on your system. You can always make one. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Return values of malloc/strdup/... not checked (was Re: [patch] cdebconf and i18n)
Please use strdup and friends, or asprintf, or other kind of things that are less prone to break. Ok, I will use strdup. While we are on it, why are return values of allocation routines never checked? You could add checks, or use/define xstrdup to give some useful error message. They will cause problem sometime in the future, I suspect, so fixing them whenever you notice would be a good start. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch] cdebconf and i18n
There are two points I am unconfortable with this patch: Why not use locale information ? (it is needed for some frontend and other things) and why is the country information 6-chars long? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] libdebian-installer2
we don't need to bump soversion at all, unless we make backward-incompatible changes. just bump minor (and don't change the packaging name). Also, fix shlibs to depend on that version or later. But surely adding stuff to a data structure is a backward-incompatible change? It depends on the way you do it. You can add stuff to a data structure without breaking backwards compatibility. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debootstrap and X
Hrishi Hrishi [EMAIL PROTECTED] immo vero scripsit: I can now chroot to unstable-debian and try to compile debian-installer. Is there anyway I can pop up xterms from the chrooted system ? Yes, you can even ssh into your chroot as well, if you start sshd. I think you need: ssh xbase-clients and some playing with /etc/passwd. -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Another language added to the boot floppies and CD installer
Anmar Oueja [EMAIL PROTECTED] immo vero scripsit: I would like to add another language to the Debain Woody boot floppies. please guide me to where I can learn how to do that. Read gettext manual, on how to edit po files, and get practice doing that, as a first step. -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Cross-Installation for Target Machines
Christoph Plattner [EMAIL PROTECTED] immo vero scripsit: Hi, Example: I have a intel/AMD PC running as host and boot server. I have a net bootable kernel for SPARC and I want to create a valid woody basic installation on a NFS-ROOT exported file system, example `/export/rootfs/hostname/woody' (= root fs). It is rather difficult as of current state, because debootstrap would need to run the postinst scripts inside the chroot, which requires that the host arch=target arch. However, if debootstrap creates the chroot by extracting the debs only, possibly running the sid script to only up to x_feign_install dpkg, and possibly hacking a /sbin/init that has: #!/bin/sh exec /post-install.sh and creating a shell script /post-install.sh which runs the rest of install_debs() from debootstrap natively, it sounds like it could be done. Sounds like a pretty interesting/exciting idea, although it is not currently implemented, it should be doable. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
second-stage i18n for b-f.
Eduard Bloch [EMAIL PROTECTED] immo vero scripsit: really. Is it that difficult? If you absolutely don't want to do this, go hack the new debian-installer - they do need helping hands. How do you know? I do not see anybody saying hey, we have a good and reliable, working d-i build system and need people to design and code. Something tells me it might be time to hack up a bit more and see if boot-floppies can do second-stage install in localized languages. debconf does iconv now. That probably means that second-stage installer can also run inside bogl. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ethdetect build-dependency problem
Thomas Poindessous [EMAIL PROTECTED] immo vero scripsit: It corrects the warning about wait() (missing #include) and it changes slang1-pic to slang1-utf8-pic, since now we uses slang1-utf8 in cdebconf. hmm.. aren't the pic versions of libdebian-installer required ? regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Including usb-storage.o, dropping two languages on i386
On Fri, 20 Sep 2002 20:16:58 +0200 Eduard Bloch [EMAIL PROTECTED] wrote: Putting the driver on the floppy costs space, so two languages would have to go (they will be available when the CDROM is accessible), ja and es. The language catalogs on the floppy image would be: en pt de fr. I object, of course, to the choice made. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
todo in i18n of cdebconf
Hi,
I've just committed the following.
Index: debian/changelog
===
RCS file:
/org/cvs.debian.org/cvs/debian-boot/debian-installer/tools/cdebconf/debian/changelog,v
retrieving revision 1.28
diff -u -r1.28 changelog
--- debian/changelog16 Sep 2002 23:40:53 - 1.28
+++ debian/changelog19 Sep 2002 17:10:01 -
@@ -1,3 +1,13 @@
+cdebconf (0.24) unstable; urgency=low
+
+ * NOT YET RELEASED
+ * Junichi Uekawa:
+- debconf, debconf-copydb, debconf-loadtemplate, dpkg-reconfigure: call setlocale
+- link slang frontend against slang-utf8
+- Build-Depend on slang-utf8-dev
+
+ -- Junichi Uekawa [EMAIL PROTECTED] Fri, 20 Sep 2002 01:37:34 +0900
+
cdebconf (0.23) unstable; urgency=low
* Change the database names to match the names currently used in
Index: debian/control
===
RCS file:
/org/cvs.debian.org/cvs/debian-boot/debian-installer/tools/cdebconf/debian/control,v
retrieving revision 1.15
diff -u -r1.15 control
--- debian/control 7 Sep 2002 02:12:58 - 1.15
+++ debian/control 19 Sep 2002 17:10:06 -
@@ -1,6 +1,6 @@
Source: cdebconf
Section: utils
-Build-Depends: dpkg-dev (= 1.7.0), debhelper (= 2.1.18), slang1-dev, libbogl-dev
[!hurd-i386], libperl-dev, d-shlibs (= 0.3)
+Build-Depends: dpkg-dev (= 1.7.0), debhelper (= 2.1.18), slang1-utf8-dev,
+libbogl-dev [!hurd-i386], libperl-dev, d-shlibs (= 0.3)
Priority: optional
Maintainer: Randolph Chung [EMAIL PROTECTED]
Standards-Version: 3.5.6.1
Index: src/debconf-copydb.c
===
RCS file:
/org/cvs.debian.org/cvs/debian-boot/debian-installer/tools/cdebconf/src/debconf-copydb.c,v
retrieving revision 1.2
diff -u -r1.2 debconf-copydb.c
--- src/debconf-copydb.c26 Aug 2002 12:11:37 - 1.2
+++ src/debconf-copydb.c19 Sep 2002 17:10:06 -
@@ -45,6 +45,7 @@
#include getopt.h
#include unistd.h
+#include locale.h
static struct option g_dpc_args[] = {
{ help, 0, NULL, 'h' },
@@ -72,6 +73,8 @@
void *iter;
int c;
+setlocale(LC_ALL, );
+
while ((c = getopt_long(argc, argv, h, g_dpc_args, NULL) 0))
{
switch (c)
Index: src/debconf-loadtemplate.c
===
RCS file:
/org/cvs.debian.org/cvs/debian-boot/debian-installer/tools/cdebconf/src/debconf-loadtemplate.c,v
retrieving revision 1.6
diff -u -r1.6 debconf-loadtemplate.c
--- src/debconf-loadtemplate.c 7 Aug 2002 16:38:19 - 1.6
+++ src/debconf-loadtemplate.c 19 Sep 2002 17:10:11 -
@@ -47,6 +47,7 @@
#include stdio.h
#include string.h
#include stdlib.h
+#include locale.h
void parsecmdline(struct configuration *config, int argc, char **argv)
{
@@ -79,6 +80,8 @@
struct template *t = NULL;
struct question *q = NULL;
int i = 2;
+
+setlocale(LC_ALL, );
config = config_new();
parsecmdline(config, argc, argv);
Index: src/debconf.c
===
RCS file:
/org/cvs.debian.org/cvs/debian-boot/debian-installer/tools/cdebconf/src/debconf.c,v
retrieving revision 1.7
diff -u -r1.7 debconf.c
--- src/debconf.c 1 Jul 2002 06:58:37 - 1.7
+++ src/debconf.c 19 Sep 2002 17:10:11 -
@@ -6,6 +6,7 @@
#include signal.h
#include string.h
#include getopt.h
+#include locale.h
static struct configuration *config = NULL;
static struct frontend *frontend = NULL;
@@ -77,6 +78,7 @@
int main(int argc, char **argv)
{
signal(SIGINT, sighandler);
+ setlocale (LC_ALL, );
config = config_new();
if (!config) {
Index: src/dpkg-reconfigure.c
===
RCS file:
/org/cvs.debian.org/cvs/debian-boot/debian-installer/tools/cdebconf/src/dpkg-reconfigure.c,v
retrieving revision 1.12
diff -u -r1.12 dpkg-reconfigure.c
--- src/dpkg-reconfigure.c 16 Sep 2002 23:36:09 - 1.12
+++ src/dpkg-reconfigure.c 19 Sep 2002 17:10:17 -
@@ -47,6 +47,8 @@
#include signal.h
#include sys/types.h
#include sys/stat.h
+#include locale.h
+
#include confmodule.h
#include configuration.h
@@ -377,6 +379,7 @@
int opt, ret;
signal(SIGINT, sighandler);
+ setlocale (LC_ALL, );
g_config = config_new();
Index: src/modules/frontend/slang/Makefile
===
RCS file:
/org/cvs.debian.org/cvs/debian-boot/debian-installer/tools/cdebconf/src/modules/frontend/slang/Makefile,v
retrieving revision 1.3
diff -u -r1.3 Makefile
--- src/modules/frontend/slang/Makefile 9 Jul 2002 05:25:04 - 1.3
+++ src/modules/frontend/slang/Makefile 19 Sep 2002 17:10:19 -
@@ -3,5 +3,6 @@
OBJS=slang.opic
MODLDFLAGS=-lslang
+MODCFLAGS=-DUTF8
include ../modules.mak
--
[EMAIL PROTECTED
Re: cvs commit to debian-installer/tools/cdebconf/src by dancer
On 20 Sep 2002 03:32:37 +0200 Tollef Fog Heen [EMAIL PROTECTED] wrote: * Debian Boot CVS Master | add setlocale call to each main(), and switch slang to slang-utf8 Have you tested that slang-utf8 works properly with cdebconf? No. But enabling setlocale requires slang-utf8. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to debian-installer/tools/cdebconf/src by dancer
On 20 Sep 2002 03:32:37 +0200 Tollef Fog Heen [EMAIL PROTECTED] wrote: * Debian Boot CVS Master | add setlocale call to each main(), and switch slang to slang-utf8 Have you tested that slang-utf8 works properly with cdebconf? I've checked now, it seems to be working fine. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: grub-install templates
On Mon, 16 Sep 2002 19:10:34 +0200 Jordi Mallach [EMAIL PROTECTED] wrote: Moshe tells me that I need to commit my Catalan templates in UTF-8 No The templates files should not be in UTF-8. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] Extended 'Description' fields in control files
sure, still valid UTF-8, but it's UTF-8 for what the UTF-8 is if interpreted according to Latin1. I thought dpkg didn't assume anything at all about the encoding in control files? That it expected us-ascii and damn everyone who didn't follow that. Can I fix this somehow, or are we doomed to having several encodings in the file because we can't do UTF-8? I don't think it is a workable solution to have Description-xx fields encoding on 8-bit encoding. Could we move that out of Description-xx: lines to generate some kind of po file? regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] Extended 'Description' fields in control files
On 13 Sep 2002 10:29:55 +0200 Could we move that out of Description-xx: lines to generate some kind of po file? Believe me, nobody would be happier than me if we used po files instead ;) I was only working with it like this because this was the current concept of translating the main menu. It wasn't used though, so I wanted to play around with it and test it a bit. I had an impression that udebs description lines were translated through ddtp also ? regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to debian-installer/doc by porridge
Marcin Owsiany [EMAIL PROTECTED] immo vero scripsit: - since maintaining some authorative lang-charset mapping would be brain damage, we would need to hack debconf to support Description-ll_LL.charset: fields (moreover joeyh says this would cause older debconf versions to crash) We already have many templates files that are in the legacy encoding, and it's not impossible to maintain a lang-charset mapping table. There already is one in the BTS. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i18n requires setlocale
Petter Reinholdtsen [EMAIL PROTECTED] immo vero scripsit: AFAIK, it's not implemented yet in debconf. It is not too hard to implement. I once did part of it for boot-floppies. But I believe it is better to rewrite debconf and cdebconf to use gettext, and perhaps make a small version of gettext to include on boot floppies. Are you mentioning pointerize ? regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to debian-installer/doc by porridge
On Wed, 11 Sep 2002 09:45:54 -0600 Debian Boot CVS Master [EMAIL PROTECTED] wrote: Repository: debian-installer/doc who:porridge time: Wed Sep 11 09:45:54 MDT 2002 Log Message: Tidied up. Comments are very welcome. Files: changed:i18n.txt * cdebconf (and thus whole debian-installer) runs in bterm [1] This is rather limiting. bterm is not the only possibility. Also: New, preferred way: * translators provide messages in po files (using po-debconf) in whatever encoding they prefer * package build procedure recodes the messages when producing the combined template file. The resulting templates file should have a Encoding: UTF-8 header (actually all this should be taken care of by po-debconf). I don't think this is the preferred way. In fact, I think this will cause more load than not converting to utf-8. We need the system for converting from language-legacy encoding to current LC_CHARSET. And: Since we have a transition period coming up anyway as packages begin to move to po-debconf, and since po-debconf's template po files will include encoding info, add onto this transition that po-debnconf generated template files will be in utf-8. This isn't true, right ? and for: [ The following probably are non-issues now sice thanks to modularity we ] [ can fit all messages on the floppy ] They are not non-issues. We can't really fit all messages on the floppy, regardless of what kind of modularity. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I18N roadmap [was: i18n requires setlocale]
On Mon, 9 Sep 2002 15:50:26 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: On Mon, Sep 09, 2002 at 03:36:58PM +0200, Marcin Owsiany wrote: [...] - for debs (base system), we: * make the templates.ll files in whatever encoding * either recode them or not when concatening [...] Some developers keep all translations in a single templates file, see 'adduser' for instance. That's a bad news. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I18N roadmap [was: i18n requires setlocale]
On Mon, 9 Sep 2002 15:36:58 +0200 Marcin Owsiany [EMAIL PROTECTED] wrote: 1. Am I right that cdebconf handles the templates in debian-installer? 2. Is this possible on all architectures? I mean: do all architectures use framebuffer? That also means that bterm will be Essential in debian-installer, since we won't be able to output any localized text without it. UTF-8 does not require bterm and framebuffer. We can still use serial line, etc. Also, fallback to C locale should be possible. 3. That will make debconf depend on libtext-iconv-perl, though and force its inclusion into base system. Is that acceptable? I'd say yes, if it is necessary. I'd rather have a cdebconf with iconv support and without, so that we can fight against space constraints, and still have a full-blown i18n in debconf. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: I18N roadmap [was: i18n requires setlocale]
On Mon, 9 Sep 2002 15:36:58 +0200 Marcin Owsiany [EMAIL PROTECTED] wrote: Hi, - for udebs, we: * make the templates.ll files in whatever encoding we like * recode (say using iconv) the templates.ll to UTF-8 when creating the combined templates file * simply copy the strings read from templates (now in UTF-8) to output at run time. That way cdebconf [1] doesn't need huge conversion tables. * only run cdebconf (and thus whole debian-installer) in bterm [2] - for debs (base system), we: * make the templates.ll files in whatever encoding * either recode them or not when concatening * use iconv at run time in debconf - see the script in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=148490repeatmerged=yes [3] I'd like this kind of text to be committed to doc/ dir of debian-installer repository. We can fix the text contents later to reflect reality. I'd also like some updating of some doc files which seems to have never been updated since joeyh first wrote them... regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partition tools (Re: debian-installer status -- 2002-07-29)
Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit: | Absolutely... I had to cd into each of several dirs containing source | for udebs and run dpkg-buildpackage in each one. I'd like to see a | situation under which I would type make -once-, and it builds all the | udebs. Why? (as in, I think that is a silly idea.) It might be nice to automate the not-yet-uploaded package detection, and compile them all, and other thing... find -type d -name debian | while read A; do ( cd $(dirname $A); debuild-pbuilder; ) done regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#160284: ITP: po-debconf -- Manage translated Debconf templates files with gettext
On Tue, 10 Sep 2002 21:55:29 -0400 Joey Hess [EMAIL PROTECTED] wrote: My plan was to add support to debconf to use iconv to convert to nl_langinfo(CODESET), from the template encoding (which is legacy ISO-8859-whatever, or EUC-whatever). That way, no transition (breakage) in terms of debconf templates files will happen. One concern is that I've heard that UTF-8 is really not all there for Japanese (Chinese?). I'm told that doing a round-trip conversion from Shift-JIS to UTF-8 has issues. I don't know if translators can just avoid those problem encodnings and write ja.po files that are already in UTF-8. ja.po files are in EUC-JP. If that doesn't fly for Japanese, we might have to come up with something more complete, such as Encoding-ll_LL fields in the templates (Encoding-jp: Shift-JIS). po-debconf would then somehow decide which po files to re-encode as utf-8 and which to leave alone, and would add the appropriate Encoding fields. Wouldn't just having Description-ll_LL.ENCODING: fields work fine ? I've got a feeling that it's doable. I can think of ways to implement that at least in C. Note also that the plan for debian-installer is, as I understand it, to make cdebconf templates always be in UTF-8. cdebconf templates, as found in the binary udeb package. Not the ones found in the source package, right ? regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#160284: ITP: po-debconf -- Manage translated Debconf templates files with gettext
On Wed, 11 Sep 2002 00:41:35 -0400 Glenn Maynard [EMAIL PROTECTED] wrote: ja.po files are in EUC-JP. Well, they *can* be UTF-8. They usually aren't. Wouldn't just having Description-ll_LL.ENCODING: fields work fine ? I've got a feeling that it's doable. I can think of ways to implement that at least in C. What's wrong with using UTF-8 for Japanese? Having multiple encodings in a single text file sucks. That's kinda workable. ja.po files don't have multiple encodings in a single file anyway. but they all only seem to be related to the slightly varying vendor tables, and not a problem when iconv is used consistently. What other problems are there that are severe enough to need this? UTF-8 is not a one-to-one match with EUC-JP. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Localized default values (was Re: [d-i] Problems with various debconf templates)
On 09 Sep 2002 09:07:47 +0200 Also, a pretty standard policy when translating things is to try not to change the meaning of the text. Huh? I only want to change the default value, how does it have an impact on the meaning of the text? Changing the default value changes the semantics of a question, does it not? Then you can change the translated question also :) regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i18n requires setlocale
ISO-8859-? for most european countries, EUC-JP in Japan,
and so on.
Not what your environment variable holds.
Hmm. I meant to ask whether or am I cursed with Latin1 because I happen
to live in western Europe? (but I must've forgotten it somehow) which
it seems I am. So my conversion to sv_SE.UTF-8 was pretty much in vain,
then. Dang.
If everything in sv_SE was UTF-8 from the beginning (which sounds
pretty unlikely), then yes...
And on-the-fly conversion is something
that I want debconf to do, but it also requires specifying the encoding
in the templates files.
We know the encoding of the templates files, and we are going towards a
on-the-fly conversion.
Where is this table of known encodings? I mean, where does debconf
define the sv - Latin1 mapping?
I think that was in one of the patches against debconf,
Tomohiro Kubota posted such a list in debian-devel
Thread on Debconf-i18n on July 2002 in debian-devel, and
http://bugs.debian.org/148490 are good examples.
But I don't see the importance of templates not
being in UTF-8.
They should not be in UTF-8 suddenly, without any signification
of them being in UTF-8.
Well, if they had been UTF-8 from the beginning, then that
would be okay.
Unless we mandate that templates are UTF-8 for d-i and only use
UTF-8-capable frontends?
Yes. We can generate UTF-8 templates in the build scripts for
udebs only, so that they have Description-ll-utf8 entries,
instead of Description-ll... (I'm not sure what was decided on this point).
$ du -sh /usr/lib/gconv/
4.4M/usr/lib/gconv
We are not going to fit that onto a floppy.
I know. But what is {c,}debconf using for the on-the-fly conversion
then? It has to be done somehow!
So, boot-floppies has UTF-8-encoded messages to avoid conversion.
debian-installer could do that.
As long as every language has its own templates.X file, I suppose it's
okay, when they are merged together into one file it gives me the creeps
to have contents from several different encodings in a single file.
That's the current state. We can't really edit the file sanely with any existing
editor.
regards,
junichi
--
[EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
i18n requires setlocale
Hi, i18n of messages and other things require setlocale. AFAIK there are no call to setlocale in the sources. Adding setlocale(LC_ALL,); to start of each main() should be enough. Otherwise applications will be running in C locale. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i18n requires setlocale
* main-menu asks debconf for debian-installer/language which afaict doesn't exist. IMO it would be better if the thing that asked for debian-installer/language first, sets LANG=$language after that, so setlocale can be used. * The Packages file parsing didn't support Description-ll_CC, only Description-ll (something I'm working on fixing) and I'm not sure about cdebconf as I get lost in the source code when I try to have a look. * Not all templates are in UTF-8. No templates should be in UTF-8. They need to be converted from their local encoding to the UTF-8 on the fly, or on creation of udebs. * Should we even use debconf i18n (which is pretty limited) or po files as per gettext? It should probably be worked on by Tomohiro Kubota, on the real debconf... We used po files for boot-floppies, and I think it was quite easy to maintain, as far as po files went. But I'm used to po files. I gather that many people are used to maintaining debconf templates, so it shouldn't make much difference. * How much i18n can we (and how much do we want to) fit on the floppy? That is why udebootstrap may be required. Note that debian-installer goes very far back from boot-floppies in respect to i18n. boot-floppies worked around the size constraints by loading locale information from file on CD-Rom, if it was available. (xlp.tgz). regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i18n requires setlocale
Why can't they be in UTF-8? My local encoding *is* UTF-8 Your local encoding is a country default that has been used in the past, and which is used in your debconf templates file, assumed when you do not specify an encoding in your templates file. ISO-8859-? for most european countries, EUC-JP in Japan, and so on. Not what your environment variable holds. (unless I misunderstand what you mean). So there is a misunderstanding. And on-the-fly conversion is something that I want debconf to do, but it also requires specifying the encoding in the templates files. We know the encoding of the templates files, and we are going towards a on-the-fly conversion. But I don't see the importance of templates not being in UTF-8. They should not be in UTF-8 suddenly, without any signification of them being in UTF-8. Well, if they had been UTF-8 from the beginning, then that would be okay. Note that on-the-fly conversion using iconv is very expensive. $ du -sh /usr/lib/gconv/ 4.4M/usr/lib/gconv We are not going to fit that onto a floppy. I'm used to po files too, being a member of the Swedish team in the Translation Project. Using po files is simple enough for a translator (and fairly well documented). exactly. Exactly, and since i18n is such a complicated matter, it makes sense to use what has been produced by others who have thought a lot about it (e.g. gettext) instead of producing something ourselves that may or may not be good enough. ditto, but since debconf has been going in this direction, and joey hess made it the beast it is, it seems like we are sticking to it this way. boot-floppies worked around the size constraints by loading locale information from file on CD-Rom, if it was available. (xlp.tgz). Nod. I'm not 100% up to speed on what the single floppy is supposed to be able to do (bootstrap for systems that can't boot from CDs and netinstall I suppose, but what else?) El-torito bootable CD image ? Are we still using 2.88MB image is used for booting from the CD-Rom? -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i18n requires setlocale
On Sun, 8 Sep 2002 16:51:49 -0700 Chris Tillman [EMAIL PROTECTED] wrote: | For floppy installs, why not plan on having a floppy version available | in each language rather than trying to do a multilingual floppy? Because we will then have a zillion different floppies to choose from? Right, but they're an organized zillion. One user is likely to need only one language, so from that viewpoint he gets to choose from a few. Can we also have a zillion ISO images ? regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
udebootstrap?
Hi, I don't know if it's really a feasible solution, or what people had in mind, but I had a quick-hack into what might be udebootstrap, IMO. This application takes in a predetermined directory filled with udebs and debs, and extract them using tar, ar, and zcat. http://www.netfort.gr.jp/~dancer/software/downloads/list.cgi What I was thinking was to make something mount the CD-Rom, or another floppy, and to populate a chroot (possibly a tmpfs) with debian-installer and it goes off running, so that we can be free from the restrictions imposed by the floppy disk space, and actually get something for i18n, and other stuff. But I've only just started playing with this idea ... and it occurred to me that it could actually be possible to debootstrap udebs as well. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PowerPC kernel repository (was: Woody on IBM RS/6000 7025 F50)
On Tue, 3 Sep 2002 20:44:03 -0700 Chris Tillman [EMAIL PROTECTED] wrote: There was no response to this request on the debian-powerpc list, I guess it really belongs to debian-boot (cc'd). Since the consensus is that the current prep and chrp kernels which we supply as part of boot-floppies are badly broken and unusable, would something like this be considered for a stable point release? Does that mean there will be new kernel-image packages for woody point release? If that is what is required for making this thing install, that probably is a good enough reason to add a new one, if it doesn't intrude with existing installs. Comments? regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PO files location (Was Re: [d-i] Problems with various debconf templates)
On Wed, 4 Sep 2002 09:30:32 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: But where must PO files go? There are at least 2 ways: * all messages in a central place (debian-installer/po/ or debian-installer/libdebian-installer/po/ so that PO catalogs may be shipped with libdebian-installer-dev and used by all modules to generate module-dependent MO files) * each component ships its own po subdirectory IMO the first one is more translator-friendly. It's rather a design decision, but it might be better to collect it in one place, and generate a debian-installer-locales package which has the po files. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle dependencies on unreleased packages?
On 02 Sep 2002 16:48:05 +0200 I've added the build-dep, but I don't get a versioned binary depend. Hmm. Come to think of it, why doesn't libd-i have the SONAME in the package name? Yes, this is a very badly packaged shared library. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle dependencies on unreleased packages?
On 02 Sep 2002 09:56:11 +0200 I'm getting ready to commit my changes that make anna and main-menu share Packages-file parsing code. They do so by a function in libd-i. This means that if you want to build anna or main-menu after I've committed, you first have to build and install the new libd-i, which is still unreleased. Should I let anna and main-menu build-depend on libdebian-installer-dev (= 0.04) so you'll be forced to rebuild libd-i first? Is that enough, or should I add an explicit binary dependency on libdebian-installer (= 0.04) too? Yes, both would be good. If you have the shlibs set properly, that should happen. I haven't looked at libd-i yet, so I cannot tell. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer status -- 2002-08-26
On Tue, 27 Aug 2002 02:36:33 +1000 Anthony Towns [EMAIL PROTECTED] wrote: What's going to go on the rootfs? Presumably something like: libc6, busybox-udeb, ash-udeb udpkg, cdebconf, anna *-retriever and any dependencies they have /lib/modules/kernel/** It could be something that reads multiple floppies, or takes things from CD-ROM, for NFS-root (it would be difficult to ask questions) The floppy is too small a place for putting in i18n locale info, and debian-installer, and I think this was the initial intention of d-i being modular. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-installer status -- 2002-08-26
On 26 Aug 2002 00:39:06 +0200 Tollef Fog Heen [EMAIL PROTECTED] wrote: Hi, It is difficult to reduce a library if you don't know what functions in it will be used. Since additional modules could be dropped onto install media at any time, it is very difficult to guarantee that a reduced libc will have all the symbols they need. The least insane way of handling this is probably to have a libc6 package and other full packages with the libraries we need; this will waste some space, but is probably the only way to go for now. Unless somebody comes up with a better way, that is the way we will go. I was hoping that this problem won't come up, but it seems like it has... I like the way of having a full-libc6 udeb, for additional modules. Logic being that if one can install additional udebs, they should probably be able to install libc6.udeb. I was kind of thinking of udebootstrap, but that might be a bit more tricky. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Addition to choose-mirror template
On 19 Aug 2002 13:05:37 +0200 Tollef Fog Heen [EMAIL PROTECTED] wrote: | UTF-8. | | I think they need to be written in latin-1, and then converted to UTF-8 | possibly in the build scripts. uhm, why? Aren't there already packages which are producing debs and udebs at the same time ? If so, they probably want UTF-8 and non-utf-8 versions of templates, and since non-utf-8 templates predate utf-8 templates (which probably do not exist yet), for compatibility, including utf-8 templates in source are bad. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Addition to choose-mirror template
On 18 Aug 2002 16:51:42 +0200 Tollef Fog Heen [EMAIL PROTECTED] wrote: | Come to think of it. Which character set should be used? I usually use | UTF-8 for everything these days, but I think that Swedish translations | of debconf templates have been in Latin1 before... UTF-8. I think they need to be written in latin-1, and then converted to UTF-8 possibly in the build scripts. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdebconf upload
On 15 Aug 2002 15:34:30 +0200 Tollef Fog Heen [EMAIL PROTECTED] wrote: | you need to coordinate with joey hess before you upload the new | cdebconf. we need debconf to move to the new debconf-api dependency | as well. uhm, can't just cdebconf provide it for now and debconf provide it at next upload? Or what kind of coordination are you asking for? I've got a feeling that it would be nice just to upload first and coordinate later :P Uploading cdebconf (probably) doesn't break anything right now, does it? regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cvs commit to mklibs/debian by blade
Debian Boot CVS Master [EMAIL PROTECTED] immo vero scripsit: Repository: mklibs/debian who:blade time: Sat Jul 27 00:59:00 PDT 2002 Log Message: Added build-deps on binutils and c-compiler They are not necessary, because they are included in the build-essential list. -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] debconf, partitioning widget?
Anthony Towns [EMAIL PROTECTED] immo vero scripsit: b-f's as a fallback doesn't work, it's too thorougly unmaintainable. Or installation system needs _major_ work, easy solutions like just fall back to boot-floppies *don't* work. It's quite interesting that you insist on b-f being so unmaintainable when you don't seem to be involved with boot-floppies. It's not that bad. :P It has (somewhat) working i18n, and somewhat works on most arches. At least we could release woody. I've got an impression that we will hopefully be able to integrate most of what is done on d-i to b-f. Even if it meant we will only be reusing kernel.sh and the installation docs. We don't want to just throw away the translations that was done for b-f, if that means anything. Of course, babbling about it on the list is not useful. Get back to hacking... regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#154169: mklibs: bug re-introduces (symlinks)
Philip Blundell [EMAIL PROTECTED] immo vero scripsit: Is it really useful to be able to do that for the installation disks? Without information on what Debian patches have been applied, knowing the base version number of the library doesn't seem to buy much. If it's important to be able to go back and figure out what libraries are on an old build of boot-floppies after the fact, we ought to ship some kind of explicit file that details what package versions were used in the build. It might be nice to update some stuff and document this. udeb packaging policy; like: install shared library matching their soname -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [d-i] debconf, partitioning widget?
Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit: We can't guarantee anything, but we _will_ have a stable d-i in appropriate time. We _must_ have a stable d-i in time. The alternative is PGI (or both). Not b-f. The reality is: The current alternative is b-f only, and there are a few people working on at least maintaining the code. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch] utilities/dbootstrap/po/Makefile gawk bug
In Mon, 1 Jul 2002 15:24:19 +0200 (CEST) [EMAIL PROTECTED] cum veritate scripsit : One line of advise: Please use diff -u. It's much easier to read. With the attached patch below, I would have spent only 2 seconds. -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [patch] utilities/dbootstrap/po/Makefile gawk bug
Chris Tillman [EMAIL PROTECTED] immo vero scripsit: Note: I have also replaced gawk by awk in the same patch, since I did not find anything needing the full gawk in the very short genc.awk code used (some awk expert please check this). Moreover, this seems to be the only place in this boot-floopies package where gawk is (was?) used. Note: shouldn't some debian dependancy mechanism automagically install gawk when doing apt-get source boot-floopies ? David or someone can look at this patch. We already build depend on gawk. I wonder what this guy is up to. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i, debootstrap: possible fix for 116801: (local components)
Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit: aj and I discussed how to make it possible to get install packages from local components. aj isn't too happy hardcoding anything, so the patch in 116801 isn't acceptable. I need to be able to install base-config from a local repository, so I need a fix for this. What do you need to do ? Wouldn't it be possible to just create your own apt archive with only minimal packages to fool debootstrap into thinking that it is the real archive? -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#149974: debootstrap should download aptitude
Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit: | I'd like to get this bug fixed ASAP or it is impossible to create | fresh sid chroots (and I get loads of bugreports against pbuilder). I'm working on an NMU, since I need some changes for d-i, but I need to test it properly. Whoops, I already uploaded one. -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#149974: debootstrap should download aptitude
Anthony Towns [EMAIL PROTECTED] immo vero scripsit: On Sat, Jun 15, 2002 at 12:56:38PM +0900, Junichi Uekawa wrote: I've pondered with the code a bit, and I think this is an overkill to require aptitude in base. By having base-config Depend: on it, or download it in the normal course of events, you're effectively putting it in base. debootstrap is currently a fragile piece of software, but it works good, and I think it would be better if things could bootstrap from there. Debian base doesn't really need aptitude, a Debian installation requires one. I'd like to get this bug fixed ASAP or it is impossible to create fresh sid chroots (and I get loads of bugreports against pbuilder). regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#149971: pbuilder: creation fails with sid distro cause it doesn't download 'aptitude'
reassign 149971 debootstrap thanks I think this is a bug in base-config or debootstrap. Are we adding aptitude to base ? Today, trying to pbuilder create --distribution sid, creation failed. The reported exit message is: W: Failure while configuring base packages. This will be attempted 5 times. dpkg: dependency problems prevent configuration of base-config: base-config depends on aptitude; however: Package aptitude is not installed. dpkg: error processing base-config (--configure): dependency problems - leaving unconfigured Inded pbuilder had not downloaded aptitude. I guess is enough to add aptitude to the needed package for sid distribution. regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#149974: debootstrap should download aptitude
On Sat, 15 Jun 2002 13:20:33 +1000 Anthony Towns [EMAIL PROTECTED] wrote: On Fri, Jun 14, 2002 at 04:02:11PM +0200, Ivo Timmermans wrote: The new base-config package in sid depends on aptitude, so debootstrap should download it. Bleh. Guys, please file the bug on debootstrap *before* adding new dependencies to base packages and breaking it completely. Joey, are you sure it wouldn't have been better to make base-config use aptitude if present, and file a wishlist bug on debootstrap to ensure its presence on normal installs? I've pondered with the code a bit, and I think this is an overkill to require aptitude in base. We already have network tools up and running, and we can download whatever package into the system. With debootstrap-created base system, it should be possible to install aptitude with the existing tools. Something like: --- lib/60pkgsel-orig Sat Jun 15 12:53:18 2002 +++ lib/60pkgselSat Jun 15 12:54:00 2002 @@ -31,6 +31,9 @@ if [ $RET = dselect ]; then run dselect select elif [ $RET = aptitude ]; then + if [ ! -e /usr/bin/aptitude ]; then + run apt-get install aptitude + fi run aptitude elif [ $RET = tasksel ]; then run tasksel -riqs -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i18n second stage...
Michael Bramer [EMAIL PROTECTED] immo vero scripsit: Yes, and those six months have been spent fixing the existing problems. I'm sorry, but the standard i18n hystrionics aren't helpful or interesting. If you want to ever have Debian support i18n well you need to start working on unstable early in the release cycle and demonstrate some patience and some skill. I am sure: We will make this the next time. Yup, and it's already started. The things currently on my plate (but I'm not currently very active at it) are: support for utf-8 in debconf possible slang-utf-8 for cdebconf ? tweak slang/newt for languages support. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i18n second stage...
Colin Walters [EMAIL PROTECTED] immo vero scripsit: On Wed, 2002-06-12 at 01:59, Junichi Uekawa wrote: For Japanese, we at least need some kind of debconf fix for utf-8 character conversion support, or a working japanese character terminal (jfbterm for all arches?). Couldn't debconf just use iconv, or am I missing something? The only problem being that it doesn't use it right now ? regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i18n second stage...
On Tue, 11 Jun 2002 14:37:24 -0400 Joey Hess [EMAIL PROTECTED] wrote: Sorry, this is just not going to happen for woody, r0 at least. I have never gotten a well-tested patch to base-config that is obviously correct. I did get a great deal of off-the-cuff, untested, large, nonobvious, peicemeil, undocumented patches; not the kind of thing I apply during a freeze. Petter Reinholdtsen was on the right track, I think with bug #135565, but I don't think he ever got back to me with test results. For Japanese, we at least need some kind of debconf fix for utf-8 character conversion support, or a working japanese character terminal (jfbterm for all arches?). regards, junichi -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
patch against cdebconf.
Package: cdebconf Version: 0.10-7.1 Tags: patch Two things: build against slang-utf8, and set UTF8. diff -ru cdebconf-0.10-orig/debian/control cdebconf-0.10/debian/control --- cdebconf-0.10-orig/debian/control Tue Jan 1 03:44:16 2002 +++ cdebconf-0.10/debian/controlWed May 29 15:57:02 2002 @@ -1,6 +1,6 @@ Source: cdebconf Section: utils -Build-Depends: dpkg-dev (= 1.7.0), debhelper (= 2.1.18), slang1-dev, libbogl-dev [!hurd-i386] +Build-Depends: dpkg-dev (= 1.7.0), debhelper (= 2.1.18), slang1-utf8-dev, +libbogl-dev [!hurd-i386] Priority: optional Maintainer: Randolph Chung [EMAIL PROTECTED] Standards-Version: 3.2.1.0 Only in cdebconf-0.10/debian: files Only in cdebconf-0.10/debian: files~ diff -ru cdebconf-0.10-orig/src/modules/frontend/slang/Makefile cdebconf-0.10/src/modules/frontend/slang/Makefile --- cdebconf-0.10-orig/src/modules/frontend/slang/Makefile Sun Jan 21 10:12:40 2001 +++ cdebconf-0.10/src/modules/frontend/slang/Makefile Wed May 29 16:03:27 2002 @@ -1,6 +1,7 @@ SOBJ=slang.so OBJS=slang.opic +MODCFLAGS=-DUTF8 MODLDFLAGS=-lslang include ../modules.mak and shlibdeps are generating warnings, it should be like thus: diff -ru cdebconf-0.10-orig/debian/rules cdebconf-0.10/debian/rules --- cdebconf-0.10-orig/debian/rules Tue Jan 1 03:47:41 2002 +++ cdebconf-0.10/debian/rules Wed May 29 16:03:45 2002 @@ -110,7 +110,7 @@ dh_fixperms -p$@ dh_makeshlibs -p$@ dh_installdeb -p$@ - dh_shlibdeps-p$@ + dh_shlibdeps-p$@ -ldebian/$@/usr/lib dh_gencontrol -p$@ dh_md5sums -p$@ dh_builddeb -p$@ @@ -135,7 +135,7 @@ dh_compress -p$@ dh_fixperms -p$@ dh_installdeb -p$@ - dh_shlibdeps-p$@ + dh_shlibdeps-p$@ -ldebian/$@/usr/lib # Don't write your stupid guesses to debian/files. dh_gencontrol -p$@ -- -fdebian/files~ # Register file manually. But there is also a missing shlibs.local. -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: patch against cdebconf.
Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit: | Two things: | | build against slang-utf8, and set UTF8. have you tested this, or shouldn't it need any source changes? They are source compatible. They are not binary compatible. regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit: The units we are working with in debian-installer are udebs (really policy (why would we want docs and man pages on the installation media?). Ah good. I forgot about udebs. The maintainer might have to maintain both utf8 and non-utf8 templates until we have changed debconf over to utf8. I think we really need to migrate from calling things like Description-ja_JP: to: Description-ja_JP.utf-8: The automatic conversion from native code to utf-8 support could be built into debconf-mergetemplate. Thoughts, joeyh? -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
On 27 May 2002 13:29:35 +0200 Tollef Fog Heen [EMAIL PROTECTED] wrote: The charset in the templates are undefined, but if we decide that we want it to be UTF-8 then that won't be a problem. (Just a small policy decision.) The frontend would have to know how to convert it into something which displays properly, though. Does anybody have a problem with having the templates in UTF8? Are you saying that every debconf template file should be in UTF-8? How do you propose to accomplish the transition ? -- [EMAIL PROTECTED] http://www.netfort.gr.jp/~dancer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit: | Are you saying that every debconf template file should be in UTF-8? | How do you propose to accomplish the transition ? Every debconf template which is used in d-i, yes. Why not? It shouldn't be that many templates. The others can be handled when the time is due. Last time I looked, there is no charset signifier in debconf templates, how does one know if the template is in utf-8 or euc-jp? Or am I misunderstanding what you mean by debconf templates completely? regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Post-woody
Tollef Fog Heen [EMAIL PROTECTED] immo vero scripsit: | I've had zero look at debian-installer. | I wonder if it would have CJK support. | Proper CJK support is a very difficult thing to achieve... It uses cdebconf as the frontend, and if somebody makes sure the bogl frontend is actually working and using the translated strings (look at the text frontend for information about how I've chosen to do it internally.) Last time I checked (which is a long long time ago), debconf had a design problem with utf-8 (the debconf templates are not in utf-8, and it is not automatically obvious which character code they are in). Does cdebconf inherit the same problem? Does it convert to utf-8 on the fly? What is a bogl frontend ? Is it very different from newt-utf8 that boot-floppies uses? regards, junichi -- [EMAIL PROTECTED] : Junichi Uekawa http://www.netfort.gr.jp/~dancer GPG Fingerprint : 17D6 120E 4455 1832 9423 7447 3059 BF92 CD37 56F4 Libpkg-guide: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
