On Thursday 25 October 2007, Frans Pop wrote:
> The prompt for CD changing works during pkgsel, but apparently not for a
> normal apt-install. During initial tests, installation of grub failed
> because CD2 was still mounted and I never got the prompt to change CDs.
> This is worked around by making sure CD1 is installed again, but if any
> packages from other CDs are needed for whatever reason _after_ pkgsel,
> the installation will hang for the same reason.
> I've not really looked yet at why this does not work.

It looks like this could be fixed by (conditionally) making apt-setup use
debconf-apt-progress.

> - if a CD change is needed to install a package _after_ pkgsel, this will
> fail because the CD is mounted in the D-I environment (the CD drive is
> locked)

With the above implemented, this could be worked around by making apt-setup
umount the CD in the D-I environment and making it reload the installation
CD again before exiting (just like pkgsel now does).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHIL0cgm/Kwh6ICoQRAhpbAJ4z420lawxFKKbipkQYbgmbiRCcBwCfcAuH
DmyWc+55QZG0Inxjcnvbwyk=
=7+TJ
-----END PGP SIGNATURE-----

Frans Pop wrote:
> On Thursday 25 October 2007, Frans Pop wrote:
> > The prompt for CD changing works during pkgsel, but apparently not for a
> > normal apt-install. During initial tests, installation of grub failed
> > because CD2 was still mounted and I never got the prompt to change CDs.
> > This is worked around by making sure CD1 is installed again, but if any
> > packages from other CDs are needed for whatever reason _after_ pkgsel,
> > the installation will hang for the same reason.
> > I've not really looked yet at why this does not work.
>
> It looks like this could be fixed by (conditionally) making apt-setup use
> debconf-apt-progress.
>
> > - if a CD change is needed to install a package _after_ pkgsel, this will
> > fail because the CD is mounted in the D-I environment (the CD drive is
> > locked)
>
> With the above implemented, this could be worked around by making apt-setup
> umount the CD in the D-I environment and making it reload the installation
> CD again before exiting (just like pkgsel now does).

ITYM apt-install, not apt-setup?

--
see shy jo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHINLId8HHehbQuO8RArv8AJwJL2JmATqNJMrSnoxhB/mKYJA8RgCfUdvn
mh7mewz1gaYCBB6F5tQBxdU=
=c+8y
-----END PGP SIGNATURE-----

Frans Pop wrote:
> When base-config was integrated into D-I, we had find a way to make tasksel
> install from CD images for hd-media installations. This was solved by bind
> mounting the CD into target and telling apt-cdrom not to mount/unmount CDs.
> In the patch for apt-setup this is reverted: apt-cdrom is allowed to mount
> CDs again. Note that base-installation is not changed in any way.
>
> For CD changing by apt-cdrom in /target to be possible, the installation CD
> has to be unmounted in the D-I environment. While it is unmounted, no udeb
> installations are possible.
> Both in apt-setup (after scanning additional CDs) and in pkgsel (after
> tasksel) the installation CD is mounted again so other installation steps
> do not break.

Is the hd-media iso unmounted and then remounted somehow?

> After the change to the 2nd CD in pkgsel, the progress bar starts at 0 again
> instead of continuing from its old position.

This sounds like it's probably an apt bug.

> The prompt for CD changing works during pkgsel, but apparently not for a
> normal apt-install. During initial tests, installation of grub failed
> because CD2 was still mounted and I never got the prompt to change CDs.
> This is worked around by making sure CD1 is installed again, but if any
> packages from other CDs are needed for whatever reason _after_ pkgsel, the
> installation will hang for the same reason.
> I've not really looked yet at why this does not work.

This is at least partly because only pkgsel uses debconf-apt-progress to
proxy debconf questions and media change requests through to cdebconf.

Unfortunatly, it's not currently possible to make apt-install use
debconf-apt-progress, because it needs --from and --to to tell it
where to advance the progress bar from. I think this could be avoided,
by modifiying debconf-apt-progress to have a --no-advance option that
avoids moving the progress bar. (It could still write progress messages
to the static bar, including apt's download time estimates.)

> - if a CD change is needed to install a package _after_ pkgsel, this will
> fail because the CD is mounted in the D-I environment (the CD drive is
> locked)

> It would be much better if anna or udpkg could detect that the CD is not
> mounted and ask for it to be mounted when needed and then automatically
> unmount it again after use so not to interfere with CD changing in /target.

I don't see a way to do this that's compatible with hd-media. We could
make d-i smart enough to loop mount the hd-media iso on demand, but if
it's unmounted after use, it won't be available to apt. Unless apt
could somehow be taught to loop mount it on demand ..

--
see shy jo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHINKdd8HHehbQuO8RAnk9AJ0XKqhajF1pLtcJSfbdhV IubW3VVQCgl68z
I6O7Y7fKqlQA22iHULtdFdA=
=6gcP
-----END PGP SIGNATURE-----

On Thursday 25 October 2007, Frans Pop wrote:
> On Thursday 25 October 2007, Frans Pop wrote:
> > The prompt for CD changing works during pkgsel, but apparently not for
> > a normal apt-install. During initial tests, installation of grub failed
> > because CD2 was still mounted and I never got the prompt to change CDs.
> > This is worked around by making sure CD1 is installed again, but if any
> > packages from other CDs are needed for whatever reason _after_ pkgsel,
> > the installation will hang for the same reason.
> > I've not really looked yet at why this does not work.
>
> It looks like this could be fixed by (conditionally) making apt-setup use
> debconf-apt-progress.
>
> > - if a CD change is needed to install a package _after_ pkgsel, this
> > will fail because the CD is mounted in the D-I environment (the CD
> > drive is locked)
>
> With the above implemented, this could be worked around by making
> apt-setup umount the CD in the D-I environment and making it reload the
> installation CD again before exiting (just like pkgsel now does).

The attached patch does both and works :-)
Tested by having grub-installer apt-install both grub and anacron (the
latter is on CD2).

The patch does introduce an inconsistency that will need to be resolved:
with multiple CDs in sources.list package installation will be interactive
(including any configuration questions) while in other cases the
installation will be non-interactive.

What's the reason we made apt-install non-interactive? Was it just that we
did not have the passthrough frontend at the time? If so, I guess we should
probably just make apt-install interactive in all cases.

Cheers,
FJP


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHINOFgm/Kwh6ICoQRAgxkAKDMrf/TROE1bC5y7aUfj10pbP3w1ACgyVCn
6ZpVTOTEF77IlToKe79Hehk=
=qdY8
-----END PGP SIGNATURE-----

Frans Pop wrote:
> What's the reason we made apt-install non-interactive? Was it just that we
> did not have the passthrough frontend at the time? If so, I guess we should
> probably just make apt-install interactive in all cases.

Both that we lacked working passthrough, and that none of these packages
have any business in asking questions at install time.

We should keep it consistent, and file bugs on any packages that ask
questions, even more aggressively than we file bugs on unncessary
questions from task packages.

> + in-target sh -c "$config debconf-apt-progress --logstderr -- apt-get -oAPT::Install-Recommends=false -y --no-remove install $packages" || ERRCODE=$?

This resets the progress bar to 0, advances it to 100, and then STOPs
it, which is not desirable if there is already a progress bar.. See my
other mail about that.

--
see shy jo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIN5Vd8HHehbQuO8RAm/AAJ9D2R/DPTLFyang+z5wwU2H+wdJHwCfc8Oz
BPevSuiJTR7V+ZRbWyopALo=
=+pUX
-----END PGP SIGNATURE-----

Joey Hess wrote:
> > + in-target sh -c "$config debconf-apt-progress --logstderr -- apt-get -o APT::Install-Recommends=false -y --no-remove install $packages" || ERRCODE=$?
>
> This resets the progress bar to 0, advances it to 100, and then STOPs
> it, which is not desirable if there is already a progress bar.. See my
> other mail about that.

The attached version of debconf-apt-progress should avoid this problem
if you pass it --no-progress.

I've tested it only outside d-i.

--
see shy jo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIOW9d8HHehbQuO8RAgSdAKDg2sLe5kjvef1gbK7t71 DNq0Uc/gCgiuwr
xcuc0h/FOgEH3ywVSyqP0/o=
=+vKS
-----END PGP SIGNATURE-----

On Thursday 25 October 2007, Joey Hess wrote:
> Joey Hess wrote:
> > > + in-target sh -c "$config debconf-apt-progress --logstderr --
> > > apt-get -o APT::Install-Recommends=false -y --no-remove install
> > > $packages" || ERRCODE=$?
> >
> > This resets the progress bar to 0, advances it to 100, and then STOPs
> > it, which is not desirable if there is already a progress bar.. See my
> > other mail about that.
>
> The attached version of debconf-apt-progress should avoid this problem
> if you pass it --no-progress.

Works fine inside D-I too.
One nitpick: should the new option be listed in the SYNOPSIS of the manpage?

Otherwise, please upload.

Thanks.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHIbYygm/Kwh6ICoQRAjYYAJ9DIIGycGF0YjCbl8lqfj3Pure7IgCgxM+Z
iCM76tgzKJo3ZIX4ZmgJBn0=
=22yB
-----END PGP SIGNATURE-----

On Thursday 25 October 2007, Joey Hess wrote:
> Frans Pop wrote:
> > What's the reason we made apt-install non-interactive? Was it just that
> > we did not have the passthrough frontend at the time? If so, I guess we
> > should probably just make apt-install interactive in all cases.
>
> Both that we lacked working passthrough, and that none of these packages
> have any business in asking questions at install time.

OK. Adapted apt-install to always use passthrough.

> We should keep it consistent, and file bugs on any packages that ask
> questions, even more aggressively than we file bugs on unncessary
> questions from task packages.

Only one question shows up: console-data "Policy for handling keymaps".
Luckily we know who we can blame for^W^Wask to fix that.

> > + in-target sh -c "$config debconf-apt-progress --logstderr -- apt-get
> > -o APT::Install-Recommends=false -y --no-remove install $packages" ||
> > ERRCODE=$?
>
> This resets the progress bar to 0, advances it to 100, and then STOPs
> it, which is not desirable if there is already a progress bar.. See my
> other mail about that.

Yep. To be honest I was surprised that it worked at all. I expected that
part to be a lot harder.
In my tests yesterday it wasn't really obvious, but when used during
base-installation it really hurts. But the updated debconf-apt-progress
works beautifully.

Attached an updated patch for di-utils.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHIbqAgm/Kwh6ICoQRAvf7AKDZXFJMX+qMs+l8zlGDI4vrHWXriACfTj5v
TVya6wxugStRhme7nmtpsrw=
=SaHF
-----END PGP SIGNATURE-----

Frans Pop wrote:
> Works fine inside D-I too.
> One nitpick: should the new option be listed in the SYNOPSIS of the manpage?

That's currently only listing the more important options.

> Otherwise, please upload.

Done.

--
see shy jo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIbsAd8HHehbQuO8RAlHfAJ0eVfo0LLBQ3tQZKjc0no J8tkcN4gCg6nzz
lc1sDnYYBRfsZfv8Z3JL3Kw=
=Q9BG
-----END PGP SIGNATURE-----

I wonder if you've considered the wrinkle of anna-install being run when
a CD other than the boot CD is in the drive? anna-install is rarely called
after base-installer, but it can happen.

Maybe cdrom-retreiver should store a volume ID of the CD and check that ID
and handling a media change.

--
see shy jo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIbx1d8HHehbQuO8RAk/8AJ91PHXXcXHg0r2QZBZJ+wbLb7KgqgCfQsTj
SnzTb/xiiXgtJxKZl+lks7I=
=avjN
-----END PGP SIGNATURE-----

Frans Pop wrote:
> +db_input high apt-setup/cdrom/set-first || true
> +db_go || exit 10
> +db_get apt-setup/cdrom/set-first

If this generator ran after the 50mirror generator it could check to see
if network sources were enabled in sources.list. If they are, and
a DVD is available, there's probably no reason to ask the question at high.
In the case of a full size CD I haven't figured out a good heuristic for
lowering the priority yet, but I'd like to find one. :-)

Hmm, another way to look at this is, there's code in the mirror
generator to ask if a mirror should be used. There's code in the cd
generator to ask if additional cds should be used. This is redundant,
the answer to either question implies the right default answer to the
other.

--
see shy jo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIcFDd8HHehbQuO8RAhHOAJ9Z4vqxBiUOJJRalVAAdG tj6s3bDwCfVRL7
r1+943bC9lzn/2DZjxTaZKg=
=kcPj
-----END PGP SIGNATURE-----

On Thursday 25 October 2007, Joey Hess wrote:
> > With the above implemented, this could be worked around by making
> > apt-setup umount the CD in the D-I environment and making it reload the
> > installation CD again before exiting (just like pkgsel now does).
>
> ITYM apt-install, not apt-setup?

Yes, of course.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHIcpVgm/Kwh6ICoQRAqj+AKC1C7eDnqeBOl2VSWRSrzYyQ22CZwCgvubj
eHzUJwNv4Gc+zHzWZyheses=
=HYre
-----END PGP SIGNATURE-----

On Thursday 25 October 2007, Joey Hess wrote:
> Frans Pop wrote:
> > For CD changing by apt-cdrom in /target to be possible, the
> > installation CD has to be unmounted in the D-I environment. While it is
> > unmounted, no udeb installations are possible.
> > Both in apt-setup (after scanning additional CDs) and in pkgsel (after
> > tasksel) the installation CD is mounted again so other installation
> > steps do not break.
>
> Is the hd-media iso unmounted and then remounted somehow?

No. The 41cdset generator detects when there is an hd-media install
('[ -d /hd-media ]') and will then just exit. This means the CD is never
unmounted, neither in the D-I environment, nor in the chroot.
So effectively nothing changes for hd-media installs.

> > After the change to the 2nd CD in pkgsel, the progress bar starts at 0
> > again instead of continuing from its old position.
>
> This sounds like it's probably an apt bug.

It could also be an issue in debconf-apt-progress. The syslog shows the
following. I also noticed that yesterday but ignored it as it did not
cause any real problems.

Oct 26 09:41:22 in-target: Unpacking cupsys-bsd (from .../cupsys-bsd_1.3.2-1_i386.deb) ...


Oct 26 09:41:23 kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
Oct 26 09:41:23 kernel: ISO 9660 Extensions: RRIP_1991A

Oct 26 09:41:47 in-target: Exiting subroutine via next at /usr/bin/debconf-apt-progress line 291, line 8342.
Oct 26 09:41:47 kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
Oct 26 09:41:47 kernel: ISO 9660 Extensions: RRIP_1991A

Oct 26 09:41:58 in-target: Exiting subroutine via next at /usr/bin/debconf-apt-progress line 291, line 8351.
Oct 26 09:41:58 kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
Oct 26 09:41:58 kernel: ISO 9660 Extensions: RRIP_1991A

Oct 26 09:42:14 in-target: Exiting subroutine via next at /usr/bin/debconf-apt-progress line 291, line 8360.
Oct 26 09:42:22 in-target: Exiting subroutine via next at /usr/bin/debconf-apt-progress line 291, line 8369.
Oct 26 09:42:22 kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
Oct 26 09:42:22 kernel: ISO 9660 Extensions: RRIP_1991A

Oct 26 09:42:48 in-target: ^MExtracting templates from packages: 29%
Oct 26 09:42:48 in-target: ^MExtracting templates from packages: 58%
Oct 26 09:42:48 in-target: ^MExtracting templates from packages: 87%
Oct 26 09:42:49 in-target: ^MExtracting templates from packages: 100%
Oct 26 09:42:49 in-target: Preconfiguring packages ...
Oct 26 09:42:49 debconf: Obsolete command TITLE Configuring foomatic-filters called
Oct 26 09:42:49 debconf: Obsolete command TITLE Foomatic Printer Filter Configuration called
Oct 26 09:42:50 debconf: Obsolete command TITLE Configuring cpufrequtils called
Oct 26 09:42:50 debconf: Obsolete command TITLE Configuring lapack3 called
Oct 26 09:42:50 debconf: Obsolete command TITLE Configuring printconf called
Oct 26 09:42:50 debconf: Obsolete command TITLE Debian Automatic Printer Configuration called
Oct 26 09:42:50 debconf: Obsolete command TITLE Configuring uswsusp called

Oct 26 09:42:50 in-target: Media Change: Please insert the disc labeled 'Debian GNU/Linux 4.0 _Lenny_ - Unofficial i386 CD Binary-2 20071023-20:03' in the
drive '/cdrom/' and press [Enter].
Oct 26 09:42:50 in-target: Media Change: Please insert the disc labeled 'Debian GNU/Linux 4.0 _Lenny_ - Unofficial i386 CD Binary-2 20071023-20:03' in the
drive '/cdrom/' and press [Enter].
Oct 26 09:42:50 in-target: Media Change: Please insert the disc labeled 'Debian GNU/Linux 4.0 _Lenny_ - Unofficial i386 CD Binary-2 20071023-20:03' in the
drive '/cdrom/' and press [Enter].
Oct 26 09:42:50 in-target: Media Change: Please insert the disc labeled 'Debian GNU/Linux 4.0 _Lenny_ - Unofficial i386 CD Binary-2 20071023-20:03' in the
drive '/cdrom/' and press [Enter].
Oct 26 09:42:52 in-target: Selecting previously deselected package foomatic-db.

> > - if a CD change is needed to install a package _after_ pkgsel, this
> > will fail because the CD is mounted in the D-I environment (the CD
> > drive is locked)
> >
> > It would be much better if anna or udpkg could detect that the CD is
> > not mounted and ask for it to be mounted when needed and then
> > automatically unmount it again after use so not to interfere with CD
> > changing in /target.
>
> I don't see a way to do this that's compatible with hd-media. We could
> make d-i smart enough to loop mount the hd-media iso on demand, but if
> it's unmounted after use, it won't be available to apt. Unless apt
> could somehow be taught to loop mount it on demand ..

Well, as I've explained above, the CD will not be unmounted for hd-media
installs, so hd-media will never find itself in the situation where the
CD would have to be remounted.
With my current implementation, anna/udpkg would only have to do a normal
mount for the D-I environment if it needs to install a udeb from CD and
finds no CD mounted.

I agree that solving the hd-media case would be quite difficult. That's
why I have made sure that it remains unaffected.
I also don't really see how to implement multi-cd support for hd-media.
You'd need a load of CD images on disk somewhere and then you'd need a
dialog that allows you to select the ones you want you use.
Even if you could teach apt how to loop mount on demand, you'd still
have the problem that the location of the images would be different and
possibly unavailable after the reboot. Best to just leave it unsupported...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHIc/7gm/Kwh6ICoQRArQHAJ41qvaGWQ2aouHze2MxZxx/y4eIMwCfQFke
v9saTe2tzV1Jdol0K4wR2tc=
=rJl+
-----END PGP SIGNATURE-----

On Friday 26 October 2007, Joey Hess wrote:
> I wonder if you've considered the wrinkle of anna-install being run when
> a CD other than the boot CD is in the drive? anna-install is rarely
> called after base-installer, but it can happen.

It _does_ happen. In the current flow grub-installer is the first component
to run os-prober which loads some new udebs (ntfs/qnx4-modules).

Another case where the installation CD must be loaded is when the 50mirror
generator is run because it checks files in /cdrom/.disk.

> Maybe cdrom-retreiver should store a volume ID of the CD and check that
> ID and handling a media change.

I do store the ID of the installation CD in the 41cdset generator.
That generator, pkgsel and apt-install all make sure that that original CD
is reloaded and mounted before they exit (using the new script
load-install-cd), so any anna-install call should never find itself with
the wrong CD in the drive.

Storing the ID could maybe be done in cdrom-retriever. OTOH, I currently
use 'apt-cdrom ident' to determine the ID and that is not available at that
early stage.

Of course, if we do want to implement a check in anna/udpkg that the correct
CD is available, this will have to be rethought.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHIdIwgm/Kwh6ICoQRAr+tAJ9QiJMzqknQpldupO7sk7nrUO0p7wCfX0Jl
gPrxoTE+enIyktUHA/vQYxw=
=32vF
-----END PGP SIGNATURE-----

On Friday 26 October 2007, Joey Hess wrote:
> Frans Pop wrote:
> > +db_input high apt-setup/cdrom/set-first || true
> > +db_go || exit 10
> > +db_get apt-setup/cdrom/set-first
>
> If this generator ran after the 50mirror generator it could check to see
> if network sources were enabled in sources.list. If they are, and
> a DVD is available, there's probably no reason to ask the question at
> high. In the case of a full size CD I haven't figured out a good
> heuristic for lowering the priority yet, but I'd like to find one. :-)
>
> Hmm, another way to look at this is, there's code in the mirror
> generator to ask if a mirror should be used. There's code in the cd
> generator to ask if additional cds should be used. This is redundant,
> the answer to either question implies the right default answer to the
> other.

My thought was that the user should first be allowed to load additional
CD/DVDs or not and based on that we _could_ change the defaults/priority
for using a mirror.

OTOH, as you've argued yourself in the past, having additional CDs available
does not guarantee that all packages you want for (l10n) tasks are
available. They could still be on a CD in the set _after_ the last one you
scanned, so having a mirror could still be useful.

I'm quite happy with the way things currently work.
I'd suggest the following:
- I'll take a last look at the templates I have now (using Christian's
comments)
- do a first commit and upload _without_ translations enabled
- this will make it relatively easy for others to actually try multi-CD
installs in practice and see how it works
- we can then tune the workflow and dialogs, and enable translations for
new/modified strings afterwards

One thing that we may want to add is to check whether a CD has already been
scanned (you can currently scan/add a CD multiple times; this is harmless)
and whether there are "gaps" in the set (CDs 1, 3 and 4 scanned, but CD 2
forgotten).

A simple check to add would be if the CD has actually been changed (that the
ID is not the same as the last one scanned), or even that a CD has not yet
been scanned. I'll probably add that.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHIdW2gm/Kwh6ICoQRAn/qAKCGrjJDkwL3uRdXuoPWSGfneU899QCgv9v9
VvzYJMKIxTOv+yc4MydJdpM=
=+u4S
-----END PGP SIGNATURE-----

Frans Pop wrote:
> My thought was that the user should first be allowed to load additional
> CD/DVDs or not and based on that we _could_ change the defaults/priority
> for using a mirror.
>
> OTOH, as you've argued yourself in the past, having additional CDs available
> does not guarantee that all packages you want for (l10n) tasks are
> available. They could still be on a CD in the set _after_ the last one you
> scanned, so having a mirror could still be useful.

Yes, and also, using a mirror is the more common case than wanting to
load a whole CD set. So I'd suggest turning that around and asking for a
mirror, and if none was used, raising the priority of the CD question.

--
see shy jo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIhyYd8HHehbQuO8RArHzAKCxTxqi+qs8cioxHwjRtn rLDeYRcACgylBb
RI2ssSg7NFO6KJeH0RJM2QQ=
=2Ptz
-----END PGP SIGNATURE-----

Quoting Frans Pop (elendil@planet.nl):

> > We should keep it consistent, and file bugs on any packages that ask
> > questions, even more aggressively than we file bugs on unncessary
> > questions from task packages.
>
> Only one question shows up: console-data "Policy for handling keymaps".
> Luckily we know who we can blame for^W^Wask to fix that.


Sigh. How can you explain that I happened to *see* this while I was
overreading some parts of that thread.

So, I guess I can expect a BR on console-data which I'm officially
*one of* the maintainers of....



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIg4H1OXtrMAUPS0RArV/AKCT8c1T7NWLbM54gWp2STNIxxpVhQCfShxx
ca4+rKILgTvNygYwG79VJlk=
=bk4Q
-----END PGP SIGNATURE-----