Bug#361872: debconf-copydb: Trashes debconf database in /target
On Tue, Jun 20, 2006 at 04:40:53PM +0200, Steinar H. Gunderson wrote: On Mon, Jun 19, 2006 at 08:57:02PM +0200, Steinar H. Gunderson wrote: After some discussion on IRC, here's the updated patch. One change is needed yet; the current code in debconf-copydb simply turns off i18n support (since the old code couldn't handle that properly, it seems, or perhaps it's even older). Just nuke the setenv() line from debconf-copydb.c and we should be okay. BTW, Joey: There _are_ lots of non-UTF-8 strings out there, it seems -- it's unfortunate, but we can't nuke the support from debconf just yet. :-/ In case this is of interest for someone, here are some figure: * There are 7 packages in unstable with Field-xx translated fields (i.e. without encoding): pool/main/a/amavis-ng/amavis-ng_0.1.6.9-1_all.deb pool/main/b/bottlerocket/bottlerocket_0.05b3-6.1_i386.deb pool/main/c/chdrv/chdrv_1.0.13p-2_i386.deb pool/main/f/filterproxy/filterproxy_0.30-6_all.deb pool/main/i/ifupdown/ifupdown_0.6.7_i386.deb pool/main/n/ndtpd/ndtpd_3.1.5-6.3_i386.deb pool/main/x/x-symbol/x-symbol_4.43-5_all.deb * There are 107 (180 in main + 5 in contrib + 2 in non-free) packages in unstable with non UTF-8 (and non utf-8 :)) Field-xx.encoding translated fields. Note that many packages need more than a simple rebuild because they implemented the hack described in http://lists.debian.org/debian-i18n/2003/07/msg00026.html to ease woody portability. * There is no package with Field-xx.utf8 translated field, so the applied fix looks safe. IIRC cdebconf does only support UTF-8 on output too, so it cannot replace debconf when run under a non UTF-8 locale. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Tue, Jun 20, 2006 at 03:31:14PM +0200, Frans Pop wrote: Joey applied this patch yesterday and today I've built cdebconf for the new version and after that a mini.iso including that. When pkgsel is run, the debconf database is still being trashed... /me is confused Ouch, that's not good. The simplest test for this is to open debconf-copydb.c, remove the setenv() call and see if you still get the warnings about unknown field names. That's what used to happen, at least, so you can see if there really is a change or if something else has happened... /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Monday 19 June 2006 20:57, Steinar H. Gunderson wrote: After some discussion on IRC, here's the updated patch. Joey applied this patch yesterday and today I've built cdebconf for the new version and after that a mini.iso including that. When pkgsel is run, the debconf database is still being trashed... /me is confused pgptHNA8LHsW7.pgp Description: PGP signature
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Mon, Jun 19, 2006 at 08:57:02PM +0200, Steinar H. Gunderson wrote: After some discussion on IRC, here's the updated patch. One change is needed yet; the current code in debconf-copydb simply turns off i18n support (since the old code couldn't handle that properly, it seems, or perhaps it's even older). Just nuke the setenv() line from debconf-copydb.c and we should be okay. BTW, Joey: There _are_ lots of non-UTF-8 strings out there, it seems -- it's unfortunate, but we can't nuke the support from debconf just yet. :-/ /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
(Keeping Steinar in To: in the hope he'll want to try this one as well ;-) On Tuesday 20 June 2006 16:40, you wrote: One change is needed yet; the current code in debconf-copydb simply turns off i18n support (since the old code couldn't handle that properly, it seems, or perhaps it's even older). Just nuke the setenv() line from debconf-copydb.c and we should be okay. Works much better with that removed. You were right though that the database is completely reorganized... After some sed and sort magic, I could verify the contents. The only remaining issue is that after the debconf-copydb all Owners: fields from the original templates.dat in target are lost. Only three templates were added: Name: debian-installer/country Name: debian-installer/keymap Name: debian-installer/language The config.dat looks good too, with the three templates added and a value for passwd/username merged. pgpuCP0to85BE.pgp Description: PGP signature
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Thu, Jun 15, 2006 at 10:44:23PM +0200, Frans Pop wrote:
The relevant files (hope the filenames speak for themselves) and an strace
are available from:
http://people.debian.org/~fjp/d-i/debconf-copydb.tgz
(uploaded instead of attached because of size)
I figured out the bug. If you tweak the source a bit to re-enable some
warnings that are normally hidden, you get
Unknown localized field:
Description-ar.utf-8
Unknown localized field:
Description-cs.utf-8
(ad infinitum)
Now, cdebconf has no proper character set support; it could have (and it
shouldn't be all that hard), but I don't think one would want pulling iconv
into d-i, and I've never seen any templates _not_ in UTF-8 or ASCII, so I
guess it would be a bit pointless. However, it special-cases fields like
Description-xx.UTF-8, so this should really have worked... until you
consider that it searches for .UTF-8 using strstr(), which is
case-sensitive, and debconf (which wrote the template file in the first
place) writes .utf-8.
The patch below makes cdebconf use strcasestr() instead of strstr(), which
fixes the problem for all but one template in that file, namely
ifupdown/convert-interfaces, which I believe is rather broken anyhow as it
uses UTF-8 without specifying a character set (just Description-xx: ). (At
least it looks that way; the ordering of the fields is too different to
simply diff, but the template file seems to be about the right size.) It's
quite trivial once you know what's causing the problems:
--- cdebconf-0.102.orig/src/template.c 2005-09-21 19:07:46.0 +0200
+++ cdebconf-0.102/src/template.c 2006-06-19 18:12:12.0 +0200
@@ -354,7 +354,7 @@
free(orig_field);
return NULL;
}
-cp = strstr(altlang, .UTF-8);
+cp = strcasestr(altlang, .UTF-8);
if (cp + 6 == altlang + strlen(altlang) cp != altlang + 1)
{
*cp = 0;
@@ -465,7 +465,7 @@
free(orig_field);
return;
}
-cp = strstr(altlang, .UTF-8);
+cp = strcasestr(altlang, .UTF-8);
if (cp + 6 == altlang + strlen(altlang) cp != altlang + 1)
{
*cp = 0;
@@ -617,7 +617,7 @@
template_lset(t, NULL, default, p+9);
else if (i18n strstr(p, Default-) == p t != 0)
{
- cp = strstr(p, .UTF-8: );
+ cp = strcasestr(p, .UTF-8: );
if (cp != NULL cp != p+8)
{
lang = strndup(p+8, (int) (cp - p - 8));
@@ -635,7 +635,7 @@
template_lset(t, NULL, choices, p+9);
else if (i18n strstr(p, Choices-) == p t != 0)
{
- cp = strstr(p, .UTF-8: );
+ cp = strcasestr(p, .UTF-8: );
if (cp != NULL cp != p+8)
{
lang = strndup(p+8, (int) (cp - p - 8));
@@ -653,7 +653,7 @@
template_lset(t, NULL, indices, p+9);
else if (i18n strstr(p, Indices-) == p t != 0)
{
- cp = strstr(p, .UTF-8: );
+ cp = strcasestr(p, .UTF-8: );
if (cp != NULL cp != p+8)
{
lang = strndup(p+8, (int) (cp - p - 8));
@@ -696,7 +696,7 @@
}
else if (i18n strstr(p, Description-) == p t != 0)
{
- cp = strstr(p, .UTF-8: );
+ cp = strcasestr(p, .UTF-8: );
if (cp != NULL cp != p+12)
{
lang = strndup(p+12, (int) (cp - p - 12));
Of course, one might want to teach cdebconf to use .utf-8 everywhere
instead, but I'm not sure if it's the right fix, and it would probably
require changing a ton of udebs.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Mon, Jun 19, 2006 at 01:10:47PM -0400, Joey Hess wrote: If it's using ascii that's valid, anyway cdebconf should also be sure to copy Description-xx[_XX] fields too, as debconf will store them that way if the package doesn't specifiy an encoding. Well, some of the fields seem to be ASCII; some of them are UTF-8. What do you propose in this case -- hacking support for this kind of undefined encoding stuff into cdebconf? We'd probably need to carry quite a bit of metadata around even if we only wanted to copy the character set, much less parse it... (Disclaimer: I haven't looked properly at cdebconf source since I was active in d-i development around 2003 or so, so there might be easier ways.) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
Steinar H. Gunderson wrote: shouldn't be all that hard), but I don't think one would want pulling iconv into d-i, and I've never seen any templates _not_ in UTF-8 or ASCII, so I guess it would be a bit pointless. However, it special-cases fields like Description-xx.UTF-8, so this should really have worked... until you consider that it searches for .UTF-8 using strstr(), which is case-sensitive, and debconf (which wrote the template file in the first place) writes .utf-8. Nice detective work. The patch below makes cdebconf use strcasestr() instead of strstr(), which fixes the problem for all but one template in that file, namely ifupdown/convert-interfaces, which I believe is rather broken anyhow as it uses UTF-8 without specifying a character set (just Description-xx: ). If it's using ascii that's valid, anyway cdebconf should also be sure to copy Description-xx[_XX] fields too, as debconf will store them that way if the package doesn't specifiy an encoding. -- see shy jo signature.asc Description: Digital signature
Bug#361872: debconf-copydb: Trashes debconf database in /target
Steinar H. Gunderson wrote: Well, some of the fields seem to be ASCII; some of them are UTF-8. What do you propose in this case -- hacking support for this kind of undefined encoding stuff into cdebconf? No, I don't think that cdebconf should worry about supporting this stuff beyond not corrupting it if reading a debconf database file. -- see shy jo signature.asc Description: Digital signature
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Mon, Jun 19, 2006 at 01:23:17PM -0400, Joey Hess wrote: What do you propose in this case -- hacking support for this kind of undefined encoding stuff into cdebconf? No, I don't think that cdebconf should worry about supporting this stuff beyond not corrupting it if reading a debconf database file. Well, debconf-copydb does: - Read in first and second config.dat. - Read in first and second template.dat. - Make a new second config.dat, writing all the data from RAM. - Make a new second template.dat, writing all the data from RAM. All this is done via the normal reading functions, which parses everything over to cdebconf's internal C structs (AFAICS). How should cdebconf keep track of all this information (which I guess is what you mean by not corrupting) without adding almost full support for it (modulo charset conversion) everywhere? This looks like a quite extensive change to me. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
First of all, this is a bit of a side issue since as noted any reasonable current package that's translated with po-debconf is going to use proper utf-8 fields. Steinar H. Gunderson wrote: Well, debconf-copydb does: - Read in first and second config.dat. - Read in first and second template.dat. - Make a new second config.dat, writing all the data from RAM. - Make a new second template.dat, writing all the data from RAM. All this is done via the normal reading functions, which parses everything over to cdebconf's internal C structs (AFAICS). How should cdebconf keep track of all this information (which I guess is what you mean by not corrupting) without adding almost full support for it (modulo charset conversion) everywhere? This looks like a quite extensive change to me. The easiest way would probably be to not track the information and store (and output) the field as utf-8 without doing any transcoding. This is not exactly what debconf does, but fields that do not define an encoding are basically using an undefined encoding and it's ok if cdebconf assumes it's really utf-8. If this causes a mojibake then the right way to fix it is to make the package define an encoding. The debconf spec does allow for Description-ll fields so even if they're not well defined cdebconf should not ignore/strip them. -- see shy jo signature.asc Description: Digital signature
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Mon, Jun 19, 2006 at 01:42:53PM -0400, Joey Hess wrote:
The easiest way would probably be to not track the information and store
(and output) the field as utf-8 without doing any transcoding. This is
not exactly what debconf does, but fields that do not define an encoding
are basically using an undefined encoding and it's ok if cdebconf
assumes it's really utf-8. If this causes a mojibake then the right way
to fix it is to make the package define an encoding.
After some discussion on IRC, here's the updated patch.
--- cdebconf-0.102.orig/src/template.c 2005-09-21 19:07:46.0 +0200
+++ cdebconf-0.102/src/template.c 2006-06-19 20:54:35.0 +0200
@@ -354,7 +354,7 @@
free(orig_field);
return NULL;
}
-cp = strstr(altlang, .UTF-8);
+cp = strcasestr(altlang, .UTF-8);
if (cp + 6 == altlang + strlen(altlang) cp != altlang + 1)
{
*cp = 0;
@@ -465,10 +465,23 @@
free(orig_field);
return;
}
-cp = strstr(altlang, .UTF-8);
-if (cp + 6 == altlang + strlen(altlang) cp != altlang + 1)
+cp = strcasestr(altlang, .UTF-8);
+
+/* Plain debconf supports undefined character sets, on the
+ form Description-nb_NO: , which is valid if the text is
+ ASCII (but debconf still uses that syntax regardless of
+ validity if the application does not specify a character
+ set). To avoid losing these fields, we simply read them
+ in as if they were UTF-8 fields, as valid ASCII is always
+ valid UTF-8 as well.
+
+ -- sesse, 2006-06-19
+*/
+if ((cp + 6 == altlang + strlen(altlang) cp != altlang + 1)
+ || strchr(altlang, '.') == NULL)
{
-*cp = 0;
+if (cp != NULL)
+*cp = 0;
template_lset(t, altlang, orig_field, value);
}
#ifndef NODEBUG
@@ -617,7 +630,7 @@
template_lset(t, NULL, default, p+9);
else if (i18n strstr(p, Default-) == p t != 0)
{
- cp = strstr(p, .UTF-8: );
+ cp = strcasestr(p, .UTF-8: );
if (cp != NULL cp != p+8)
{
lang = strndup(p+8, (int) (cp - p - 8));
@@ -635,7 +648,7 @@
template_lset(t, NULL, choices, p+9);
else if (i18n strstr(p, Choices-) == p t != 0)
{
- cp = strstr(p, .UTF-8: );
+ cp = strcasestr(p, .UTF-8: );
if (cp != NULL cp != p+8)
{
lang = strndup(p+8, (int) (cp - p - 8));
@@ -653,7 +666,7 @@
template_lset(t, NULL, indices, p+9);
else if (i18n strstr(p, Indices-) == p t != 0)
{
- cp = strstr(p, .UTF-8: );
+ cp = strcasestr(p, .UTF-8: );
if (cp != NULL cp != p+8)
{
lang = strndup(p+8, (int) (cp - p - 8));
@@ -696,7 +709,7 @@
}
else if (i18n strstr(p, Description-) == p t != 0)
{
- cp = strstr(p, .UTF-8: );
+ cp = strcasestr(p, .UTF-8: );
if (cp != NULL cp != p+12)
{
lang = strndup(p+12, (int) (cp - p - 12));
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Mon, Jun 19, 2006 at 09:58:17PM +0200, Denis Barbier wrote: I am not sure that this is desirable, next time you will encounter utf8 instances, and maybe other names too (except that I cannot find another one ;)) Well, either we'll have to keep adding special-casing of UTF-8, or we'll have to add proper character set support. Or we could adjust the debconf spec to say that only UTF-8 and ASCII are supported, as I can't find an example of anything else, and Joey says that anything using po-debconf will do that anyhow. I'll leave that part to Joey, in that case :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Mon, Jun 19, 2006 at 08:57:02PM +0200, Steinar H. Gunderson wrote: On Mon, Jun 19, 2006 at 01:42:53PM -0400, Joey Hess wrote: The easiest way would probably be to not track the information and store (and output) the field as utf-8 without doing any transcoding. This is not exactly what debconf does, but fields that do not define an encoding are basically using an undefined encoding and it's ok if cdebconf assumes it's really utf-8. If this causes a mojibake then the right way to fix it is to make the package define an encoding. After some discussion on IRC, here's the updated patch. --- cdebconf-0.102.orig/src/template.c2005-09-21 19:07:46.0 +0200 +++ cdebconf-0.102/src/template.c 2006-06-19 20:54:35.0 +0200 @@ -354,7 +354,7 @@ free(orig_field); return NULL; } -cp = strstr(altlang, .UTF-8); +cp = strcasestr(altlang, .UTF-8); I am not sure that this is desirable, next time you will encounter utf8 instances, and maybe other names too (except that I cannot find another one ;)) +/* Plain debconf supports undefined character sets, on the + form Description-nb_NO: , which is valid if the text is + ASCII (but debconf still uses that syntax regardless of + validity if the application does not specify a character + set). To avoid losing these fields, we simply read them + in as if they were UTF-8 fields, as valid ASCII is always + valid UTF-8 as well. Ditto, this is supported by debconf for compatibility reasons, but we should try hard to get rid of undefined encodings wherever possible. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
Denis Barbier wrote: After some discussion on IRC, here's the updated patch. --- cdebconf-0.102.orig/src/template.c 2005-09-21 19:07:46.0 +0200 +++ cdebconf-0.102/src/template.c 2006-06-19 20:54:35.0 +0200 @@ -354,7 +354,7 @@ free(orig_field); return NULL; } -cp = strstr(altlang, .UTF-8); +cp = strcasestr(altlang, .UTF-8); I am not sure that this is desirable, next time you will encounter utf8 instances, and maybe other names too (except that I cannot find another one ;)) I don't know of any such instances.. +/* Plain debconf supports undefined character sets, on the + form Description-nb_NO: , which is valid if the text is + ASCII (but debconf still uses that syntax regardless of + validity if the application does not specify a character + set). To avoid losing these fields, we simply read them + in as if they were UTF-8 fields, as valid ASCII is always + valid UTF-8 as well. Ditto, this is supported by debconf for compatibility reasons, but we should try hard to get rid of undefined encodings wherever possible. Getting rid of them by deleting them out of the debconf database when copying other info into there with debconf-copydb is undesirable. -- see shy jo signature.asc Description: Digital signature
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Sunday 11 June 2006 20:04, Steinar H. Gunderson wrote: I'm unable to reproduce this with 0.102 in a normal (ie. non-d-i) environment: I can still reproduce the problem during an installation though... configdb is here set up to be my normal debconf database (so I have some source data to test with), but I can't understand why this would work outside d-i but not from pkgsel... any ideas? I have a few very wild ideas, but no idea how valid they are. One idea is the encoding (installer is running with nl_NL.UTF8, although the pkgsel postinst sets and exports LANG=C). Another is busybox. A third is the way debconf-copydb is called within d-i; maybe broken handling if the target is target_configdb? The full call is: debconf-copydb -p \ ^(debian-installer/language|debian-installer/country| debian-installer/keymap|passwd/username)$ \ configdb target_configdb pgpQT26dwWyGX.pgp Description: PGP signature
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Thu, Jun 15, 2006 at 07:29:44PM +0200, Frans Pop wrote: I can still reproduce the problem during an installation though... Ugh. Could you provide an strace of it, or would that be too much of a hassle? One idea is the encoding (installer is running with nl_NL.UTF8, although the pkgsel postinst sets and exports LANG=C). I'm running with en_DK.UTF-8 myself, so I doubt it is the encoding. Another is busybox. How would this influence anything? A third is the way debconf-copydb is called within d-i; maybe broken handling if the target is target_configdb? I'm running with target_configdb myself, so I doubt the latter is the case, but yes, it appears very d-i-specific somehow... The full call is: debconf-copydb -p \ ^(debian-installer/language|debian-installer/country| debian-installer/keymap|passwd/username)$ \ configdb target_configdb trofast:~# grep Name: /target/var/cache/debconf/templates.dat Name: acpid/modules Name: acpid/noacpi Name: apache-common/confignotes Name: apache-common/logs Name: apache-common/old-logrotate-exists Name: passwd/username trofast:~# /usr/lib/cdebconf/debconf-copydb -p ^(debian-installer/language|debian-installer/country|debian-installer/keymap|passwd/username)$ configdb target_configdb trofast:~# grep Name: /target/var/cache/debconf/templates.dat Name: acpid/modules Name: acpid/noacpi Name: apache-common/confignotes Name: apache-common/logs Name: apache-common/old-logrotate-exists Name: passwd/username In other words, no big surprises here (my debconf database doesn't have any d-i keys). Do you have a copy of the source and target databases, as well as the cdebconf.conf used? It might be something specific about the data in the destination that makes cdebconf discard it... /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Thursday 15 June 2006 21:33, Steinar H. Gunderson wrote: Another is busybox. How would this influence anything? Told you they were _wild_ guesses ;-) Do you have a copy of the source and target databases, as well as the cdebconf.conf used? It might be something specific about the data in the destination that makes cdebconf discard it... The relevant files (hope the filenames speak for themselves) and an strace are available from: http://people.debian.org/~fjp/d-i/debconf-copydb.tgz (uploaded instead of attached because of size) If you want other files too, just ask. I have the testcase saved in vmware. Thanks for looking into this. pgpOC7tOeb1TY.pgp Description: PGP signature
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Mon, Apr 10, 2006 at 11:42:29PM +0200, Frans Pop wrote: When debconf-copydb is run from pkgsel's postinst script, it deletes the existing /var/cache/debconf/templates.dat in /target; after it has run only copied templates are present. This results in the problem that has been reported that tasksel is not translated. Commenting out the debconf-copydb statement solves this problem. I'm unable to reproduce this with 0.102 in a normal (ie. non-d-i) environment: trofast:~/nmu/cdebconf-0.102# rm /target/var/cache/debconf/* zsh: sure you want to delete all the files in /target/var/cache/debconf [yn]? y trofast:~# /usr/lib/cdebconf/debconf-copydb -p apache-common configdb target_configdb trofast:~# grep ^Name: /target/var/cache/debconf/templates.dat Name: apache-common/confignotes Name: apache-common/logs Name: apache-common/old-logrotate-exists trofast:~# /usr/lib/cdebconf/debconf-copydb -p acpi configdb target_configdb trofast:~# grep ^Name: /target/var/cache/debconf/templates.dat Name: acpid/modules Name: acpid/noacpi Name: apache-common/confignotes Name: apache-common/logs Name: apache-common/old-logrotate-exists configdb is here set up to be my normal debconf database (so I have some source data to test with), but I can't understand why this would work outside d-i but not from pkgsel... any ideas? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
Package: cdebconf Version: 0.97 Severity: serious When debconf-copydb is run from pkgsel's postinst script, it deletes the existing /var/cache/debconf/templates.dat in /target; after it has run only copied templates are present. This results in the problem that has been reported that tasksel is not translated. Commenting out the debconf-copydb statement solves this problem. Verified with Etch Beta 2. pgpQz7XGDU8PL.pgp Description: PGP signature
