Bug#238301: After installer has run many debconf questions are not seeded

2004-09-30 Thread Colin Watson
On Wed, Sep 29, 2004 at 07:13:56PM -0400, Joey Hess wrote:
 Colin Watson wrote:
  That's possible ... suggestions for naming of the common class? I'd been
  thinking the new classes were small enough not to matter too much.
  
  Maybe some magic could go into Debconf::Element::Noninteractive.
 
 Yes, it seems to me most noninteractive elemenets could just derive from
 that class though making it work may be too much work/code.

OK, let's try this, moving the common show() code into
Debconf::Element::Noninteractive:

  http://patches.ubuntulinux.org/patches/debconf.238301.v2.diff

Tested with debootstrap, same changes. I'll probably put this version
into Ubuntu for now at least.

  /var/cache/debconf/config.dat diff attached (for Ubuntu rather than
  Debian, but hey); /etc is identical except for a popularity-contest
  configuration file that has the output of uuidgen in it.
 
 I guess the couple of Value sets are harmless, since it's just taking
 the default value from the templates.

Right, I think so too.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#238301: After installer has run many debconf questions are not seeded

2004-09-30 Thread Joey Hess
Colin Watson wrote:
 OK, let's try this, moving the common show() code into
 Debconf::Element::Noninteractive:
 
   http://patches.ubuntulinux.org/patches/debconf.238301.v2.diff
 
 Tested with debootstrap, same changes. I'll probably put this version
 into Ubuntu for now at least.

Feel free to merge that into debconf svn. As to whether it should go to
the sarge branch.. well, I suppose you could ask Steve. :-)

-- 
see shy jo


signature.asc
Description: Digital signature


Bug#238301: After installer has run many debconf questions are not seeded

2004-09-29 Thread Colin Watson
On Thu, Jul 29, 2004 at 02:32:58PM -0400, Joey Hess wrote:
 Mark Brown wrote:
  I've found some more instances of this problem.  I managed to catch a
  diff of the config files before and after the upgrade, though I didn't
  remember to rerun the upgrade or cache the entire database:
 
 Now I understand. This is because debootstrap installs packages using
 the noninteractive frontend which does not set questions to seen as the
 user has indeed not seen them. It's true that this could lead to some
 questions that have already set and presumably working values being asked
 on upgrade. 
 
 I don't know of a good way to avoid this at this time; debconf's
 handling of the seen flag for the noninteractive frontend is basically
 correct; debootstrap's use of the noninteractive frontend is correct,
 and there's no way d-i can go back after the fact and mark questions as
 seen.

This patch implements a DEBCONF_NONINTERACTIVE_SEEN environment variable
that debootstrap can set to make the noninteractive frontend behave a
little differently, without risking breaking other uses of the
noninteractive frontend. What do you think?

  http://patches.ubuntulinux.org/patches/debconf.238301.diff

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#238301: After installer has run many debconf questions are not seeded

2004-09-29 Thread Joey Hess
Colin Watson wrote:
 This patch implements a DEBCONF_NONINTERACTIVE_SEEN environment variable
 that debootstrap can set to make the noninteractive frontend behave a
 little differently, without risking breaking other uses of the
 noninteractive frontend. What do you think?

This looks reasonable, I think you could have avoided the duplication of
near-identical new classes.

I guess you've tested it and verified it has no other effects to a
debcootrstrapped system?

-- 
see shy jo


signature.asc
Description: Digital signature


Bug#238301: After installer has run many debconf questions are not seeded

2004-09-29 Thread Colin Watson
On Wed, Sep 29, 2004 at 06:25:06PM -0400, Joey Hess wrote:
 Colin Watson wrote:
  This patch implements a DEBCONF_NONINTERACTIVE_SEEN environment variable
  that debootstrap can set to make the noninteractive frontend behave a
  little differently, without risking breaking other uses of the
  noninteractive frontend. What do you think?
 
 This looks reasonable, I think you could have avoided the duplication of
 near-identical new classes.

That's possible ... suggestions for naming of the common class? I'd been
thinking the new classes were small enough not to matter too much.

Maybe some magic could go into Debconf::Element::Noninteractive.

 I guess you've tested it and verified it has no other effects to a
 debcootrstrapped system?

/var/cache/debconf/config.dat diff attached (for Ubuntu rather than
Debian, but hey); /etc is identical except for a popularity-contest
configuration file that has the output of uuidgen in it.

-- 
Colin Watson   [EMAIL PROTECTED]
--- /home/cjwatson/warty-chroot-1/var/cache/debconf/config.dat  2004-09-29 
15:38:40.440025160 +0100
+++ /home/cjwatson/warty-chroot-2/var/cache/debconf/config.dat  2004-09-29 
17:01:29.619595040 +0100
@@ -314,6 +314,7 @@
 Template: console-data/keymap/policy
 Value: Don't touch keymap
 Owners: console-common, console-data
+Flags: seen
 
 Name: console-data/keymap/powerpcadb
 Template: console-data/keymap/powerpcadb
@@ -897,6 +898,7 @@
 
 Name: dash/sh
 Template: dash/sh
+Value: false
 Owners: dash
 
 Name: debconf/frontend
@@ -931,10 +933,12 @@
 
 Name: discover/manage_cdrom_devices
 Template: discover/manage_cdrom_devices
+Value: true
 Owners: discover1
 
 Name: hotplug/ignore_pci_class_display
 Template: hotplug/ignore_pci_class_display
+Value: true
 Owners: hotplug
 
 Name: hotplug/net_agent_policy
@@ -944,6 +948,7 @@
 
 Name: hotplug/static_module_list
 Template: hotplug/static_module_list
+Value: 
 Owners: hotplug
 Variables:
  usbmodules = 
@@ -983,6 +988,7 @@
 
 Name: locales/locales_to_be_generated
 Template: locales/locales_to_be_generated
+Value: 
 Owners: locales
 Variables:
  locales = aa_DJ ISO-8859-1, aa_ER UTF-8, [EMAIL PROTECTED] UTF-8, aa_ET UTF-8, af_ZA 
ISO-8859-1, am_ET UTF-8, an_ES ISO-8859-15, ar_AE ISO-8859-6, ar_AE.UTF-8 UTF-8, ar_BH 
ISO-8859-6, ar_BH.UTF-8 UTF-8, ar_DZ ISO-8859-6, ar_DZ.UTF-8 UTF-8, ar_EG ISO-8859-6, 
ar_EG.UTF-8 UTF-8, ar_IN UTF-8, ar_IQ ISO-8859-6, ar_IQ.UTF-8 UTF-8, ar_JO ISO-8859-6, 
ar_JO.UTF-8 UTF-8, ar_KW ISO-8859-6, ar_KW.UTF-8 UTF-8, ar_LB ISO-8859-6, ar_LB.UTF-8 
UTF-8, ar_LY ISO-8859-6, ar_LY.UTF-8 UTF-8, ar_MA ISO-8859-6, ar_MA.UTF-8 UTF-8, ar_OM 
ISO-8859-6, ar_OM.UTF-8 UTF-8, ar_QA ISO-8859-6, ar_QA.UTF-8 UTF-8, ar_SA ISO-8859-6, 
ar_SA.UTF-8 UTF-8, ar_SD ISO-8859-6, ar_SD.UTF-8 UTF-8, ar_SY ISO-8859-6, ar_SY.UTF-8 
UTF-8, ar_TN ISO-8859-6, ar_TN.UTF-8 UTF-8, ar_YE ISO-8859-6, ar_YE.UTF-8 UTF-8, 
az_AZ.UTF-8 UTF-8, be_BY CP1251, be_BY.UTF-8 UTF-8, bg_BG CP1251, bg_BG.UTF-8 UTF-8, 
bn_BD UTF-8, bn_IN UTF-8, br_FR ISO-8859-1, [EMAIL PROTECTED] ISO-8859-15, bs_BA 
ISO-8859-2, byn_ER UTF-8, ca_ES ISO-8859-1, ca_ES.UTF-8 UTF-8, [EMAIL PROTECTED] 
UTF-8, [EMAIL PROTECTED] ISO-8859-15, cs_CZ ISO-8859-2, cs_CZ.UTF-8 UTF-8, cy_GB 
ISO-8859-14, cy_GB.UTF-8 UTF-8, da_DK ISO-8859-1, da_DK.ISO-8859-15 ISO-8859-15, 
da_DK.UTF-8 UTF-8, de_AT ISO-8859-1, de_AT.UTF-8 UTF-8, [EMAIL PROTECTED] UTF-8, 
[EMAIL PROTECTED] ISO-8859-15, de_BE ISO-8859-1, de_BE.UTF-8 UTF-8, [EMAIL PROTECTED] 
UTF-8, [EMAIL PROTECTED] ISO-8859-15, de_CH ISO-8859-1, de_CH.UTF-8 UTF-8, de_DE 
ISO-8859-1, de_DE.UTF-8 UTF-8, [EMAIL PROTECTED] UTF-8, [EMAIL PROTECTED] ISO-8859-15, 
de_LU ISO-8859-1, de_LU.UTF-8 UTF-8, [EMAIL PROTECTED] UTF-8, [EMAIL PROTECTED] 
ISO-8859-15, el_GR ISO-8859-7, el_GR.UTF-8 UTF-8, en_AU ISO-8859-1, en_AU.UTF-8 UTF-8, 
en_BW ISO-8859-1, en_BW.UTF-8 UTF-8, en_CA ISO-8859-1, en_CA.UTF-8 UTF-8, en_DK 
ISO-8859-1, en_DK.UTF-8 UTF-8, en_GB ISO-8859-1, en_GB.ISO-8859-15 ISO-8859-15, 
en_GB.UTF-8 UTF-8, en_HK ISO-8859-1, en_HK.UTF-8 UTF-8, en_IE ISO-8859-1, en_IE.UTF-8 
UTF-8, [EMAIL PROTECTED] UTF-8, [EMAIL PROTECTED] ISO-8859-15, en_IN UTF-8, en_NZ 
ISO-8859-1, en_NZ.UTF-8 UTF-8, en_PH ISO-8859-1, en_PH.UTF-8 UTF-8, en_SG ISO-8859-1, 
en_SG.UTF-8 UTF-8, en_US ISO-8859-1, en_US.ISO-8859-15 ISO-8859-15, en_US.UTF-8 UTF-8, 
en_ZA ISO-8859-1, en_ZA.UTF-8 UTF-8, en_ZW ISO-8859-1, en_ZW.UTF-8 UTF-8, es_AR 
ISO-8859-1, es_AR.UTF-8 UTF-8, es_BO ISO-8859-1, es_BO.UTF-8 UTF-8, es_CL ISO-8859-1, 
es_CL.UTF-8 UTF-8, es_CO ISO-8859-1, es_CO.UTF-8 UTF-8, es_CR ISO-8859-1, es_CR.UTF-8 
UTF-8, es_DO ISO-8859-1, es_DO.UTF-8 UTF-8, es_EC ISO-8859-1, es_EC.UTF-8 UTF-8, es_ES 
ISO-8859-1, es_ES.UTF-8 UTF-8, [EMAIL PROTECTED] UTF-8, [EMAIL PROTECTED] ISO-8859-15, 
es_GT ISO-8859-1, es_GT.UTF-8 UTF-8, es_HN ISO-8859-1, es_HN.UTF-8 UTF-8, es_MX 
ISO-8859-1, es_MX.UTF-8 UTF-8, es_NI ISO-8859-1, es_NI.UTF-8 UTF-8, es_PA ISO-8859-1, 
es_PA.UTF-8 UTF-8, es_PE ISO-8859-1, es_PE.UTF-8 UTF-8, es_PR 

Bug#238301: After installer has run many debconf questions are not seeded

2004-09-29 Thread Joey Hess
Colin Watson wrote:
 That's possible ... suggestions for naming of the common class? I'd been
 thinking the new classes were small enough not to matter too much.
 
 Maybe some magic could go into Debconf::Element::Noninteractive.

Yes, it seems to me most noninteractive elemenets could just derive from
that class though making it work may be too much work/code.

 /var/cache/debconf/config.dat diff attached (for Ubuntu rather than
 Debian, but hey); /etc is identical except for a popularity-contest
 configuration file that has the output of uuidgen in it.

I guess the couple of Value sets are harmless, since it's just taking
the default value from the templates.

-- 
see shy jo


signature.asc
Description: Digital signature


Bug#238301: After installer has run many debconf questions are not seeded

2004-07-30 Thread Mark Brown
On Thu, Jul 29, 2004 at 02:32:58PM -0400, Joey Hess wrote:

 I don't know of a good way to avoid this at this time; debconf's
 handling of the seen flag for the noninteractive frontend is basically
 correct; debootstrap's use of the noninteractive frontend is correct,
 and there's no way d-i can go back after the fact and mark questions as
 seen.

Perhaps it would help if when changing an option that would change what
you see Debconf should offer to rerun config scripts so that being
prompted for unseen options happens then (when you know why) rather than
randomly later?  It's pretty gross but it's fairly non-invasive and I
guess some people might find it useful.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#238301: After installer has run many debconf questions are not seeded

2004-07-29 Thread Joey Hess
Mark Brown wrote:
 I've found some more instances of this problem.  I managed to catch a
 diff of the config files before and after the upgrade, though I didn't
 remember to rerun the upgrade or cache the entire database:

Now I understand. This is because debootstrap installs packages using
the noninteractive frontend which does not set questions to seen as the
user has indeed not seen them. It's true that this could lead to some
questions that have already set and presumably working values being asked
on upgrade. 

I don't know of a good way to avoid this at this time; debconf's
handling of the seen flag for the noninteractive frontend is basically
correct; debootstrap's use of the noninteractive frontend is correct,
and there's no way d-i can go back after the fact and mark questions as
seen.

-- 
see shy jo


signature.asc
Description: Digital signature


Bug#238301: After installer has run many debconf questions are not seeded

2004-07-25 Thread Mark Brown
On Tue, Mar 16, 2004 at 10:56:22PM -0500, Joey Hess wrote:
 Mark Brown wrote:

  It seems to be happening an awful lot - I'd suggest including some kind
  of automated reinstall of all the packages in the testing of the
  installer (next time I do an install I'll probably give this a whirl).

 I can't imagine how it could happen at all without some great care being
 taken to make debconf behave in a way it truely does not want to, or a
 debconf behavior I am not anticipating. Can you provide an example of a
 debconf database before the upgrade, plus the upgrade with
 DEBCONF_DEBUG='.*' ?

I've found some more instances of this problem.  I managed to catch a
diff of the config files before and after the upgrade, though I didn't
remember to rerun the upgrade or cache the entire database:

--- config.dat-old  2004-07-23 20:09:40.0 +0100
+++ config.dat  2004-07-25 21:43:15.207208392 +0100
@@ -3,6 +3,12 @@
 Value: true
 Owners: adduser
 
+Name: alsa-base/alsactl_store_on_shutdown
+Template: alsa-base/alsactl_store_on_shutdown
+Value: autosave always
+Owners: alsa-base
+Flags: seen
+
 Name: anacron/jobs_in_crontab
 Template: anacron/jobs_in_crontab
 Owners: anacron
@@ -1060,11 +1066,13 @@
 Template: debconf/frontend
 Value: Dialog
 Owners: debconf
+Flags: seen
 
 Name: debconf/priority
 Template: debconf/priority
-Value: medium
+Value: low
 Owners: d-i, debconf
+Flags: seen
 
 Name: debian-installer/country
 Template: debian-installer/country
@@ -1085,6 +1093,7 @@
 Template: debsums/apt-autogen
 Value: true
 Owners: debsums
+Flags: seen
 
 Name: dictionaries-common/default-ispell
 Template: dictionaries-common/default-ispell
@@ -1423,6 +1432,7 @@
 Template: mozilla/locale_auto
 Value: true
 Owners: mozilla-browser
+Flags: seen
 
 Name: mozilla/prefs_note
 Template: mozilla/prefs_note

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#238301: After installer has run many debconf questions are not seeded

2004-03-17 Thread Mark Brown
On Tue, Mar 16, 2004 at 10:56:22PM -0500, Joey Hess wrote:

 I can't imagine how it could happen at all without some great care being
 taken to make debconf behave in a way it truely does not want to, or a
 debconf behavior I am not anticipating. Can you provide an example of a
 debconf database before the upgrade, plus the upgrade with
 DEBCONF_DEBUG='.*' ?

I'll try to find another machine to do an install on but I don't know
when that'll be.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#238301: After installer has run many debconf questions are not seeded

2004-03-16 Thread Mark Brown
Package: debian-installer
Version: As of 20040412
Severity: normal

During the installer run many packages (for example, setserial) appear
to get installed without their debconf configuration scripts being run.
This means that when the packages get upgraded they prompt for
configuration.

While this is probably mostly OK for a stable release since upgrades are
infrequent I can see this creating problems with security updates and
point releases as well which is probably undesirable.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Kernel: Linux 2.4.22-powerpc
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#238301: After installer has run many debconf questions are not seeded

2004-03-16 Thread Joey Hess
Mark Brown wrote:
 During the installer run many packages (for example, setserial) appear
 to get installed without their debconf configuration scripts being run.
 This means that when the packages get upgraded they prompt for
 configuration.

Incorrect, they are installed in the normal way but with the
noninteractive debconf frontend. The config scripts run. Any package
that behaves as you describe when installed this way is broken; this is
doubly true for packages in the base system which have all been
installed in this way since before the release of woody.

Please clone and/or reassign this bug to the broken packages.

-- 
see shy jo


signature.asc
Description: Digital signature


Bug#238301: After installer has run many debconf questions are not seeded

2004-03-16 Thread Mark Brown
clone 238301 -1
reassign -1 setserial
thanks

On Tue, Mar 16, 2004 at 01:14:19PM -0500, Joey Hess wrote:
 Mark Brown wrote:
  During the installer run many packages (for example, setserial) appear
  to get installed without their debconf configuration scripts being run.
  This means that when the packages get upgraded they prompt for
  configuration.

 Incorrect, they are installed in the normal way but with the
 noninteractive debconf frontend. The config scripts run. Any package
 that behaves as you describe when installed this way is broken; this is

setserial is one of the packages I remember doing this to me on upgrade
- it prompted me for autosave-types.

-- 
You grabbed my hand and we fell into it, like a daydream - or a fever.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Processed: Re: Bug#238301: After installer has run many debconf questions are not seeded

2004-03-16 Thread Debian Bug Tracking System
Processing commands for [EMAIL PROTECTED]:

 clone 238301 -1
Bug#238301: After installer has run many debconf questions are not seeded
Bug 238301 cloned as bug 238390.

 reassign -1 setserial
Bug#238390: After installer has run many debconf questions are not seeded
Bug reassigned from package `debian-installer' to `setserial'.

 thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#238301: After installer has run many debconf questions are not seeded

2004-03-16 Thread Joey Hess
Mark Brown wrote:
 On Tue, Mar 16, 2004 at 01:14:19PM -0500, Joey Hess wrote:
  Mark Brown wrote:
 
   During the installer run many packages (for example, setserial) appear
   to get installed without their debconf configuration scripts being run.
   This means that when the packages get upgraded they prompt for
   configuration.
 
  Incorrect, they are installed in the normal way but with the
  noninteractive debconf frontend. The config scripts run. Any package
  that behaves as you describe when installed this way is broken; this is
 
 It seems to be happening an awful lot - I'd suggest including some kind
 of automated reinstall of all the packages in the testing of the
 installer (next time I do an install I'll probably give this a whirl).

I can't imagine how it could happen at all without some great care being
taken to make debconf behave in a way it truely does not want to, or a
debconf behavior I am not anticipating. Can you provide an example of a
debconf database before the upgrade, plus the upgrade with
DEBCONF_DEBUG='.*' ?

-- 
see shy jo


signature.asc
Description: Digital signature