Re: [PATCH] support live image installing mode selection

[Christian Perrier]

Quoting Otavio Salvador ([EMAIL PROTECTED]):

> > _Description: Installation mode:
> >  Please select the installation mode to be used.
> >  .
> >  By choosing 'normal', the installed system will be a regular system
> >  running from disk while 'live' will continue by running a system
> >  without any physical installation on disk.
> 
> The 'live' isn't to run without installation but continue to run from
> ram, not from the disk. It loads it from disk, instead of CD-ROM. 


Hmmm, I'm quite in the dark here..:-)...Which probably means that
other translators will also be in the dark.

In short, I actually fail to understand what do these two modes,
exactly...probably because I don't know enough live-installer itself.

Could you maybe reformulate the template by using the organisation I
propose but using the correct words wrt what does exactly both
choices.




signature.asc
Description: Digital signature

Re: Kernel panic installing Etch

[Frans Pop]

On Tuesday 04 March 2008, Juan Seet wrote:
> Hello, I downloaded netinst for AMD64, I tried to install it and I get
> the following message:
> Code: 89 d5 81 e5 ff 00 00 00 75 70 48 c1 ea 08 48 8d b3 18 10 00
> console shuts up ...
> <0>Kernel panic - not syncing: Aiee, killing interrupt handler!

Looks like the Etch kernel does not correctly support your hardware.
Suggest you either try the Lenny installer [2], or the /unofficial/ 
installer from Kenshi Muto for Etch [2] that has a more recent kernel.

You may also be able to work around the issue by passing some kernel 
parameters (e.g. acpi=noirq), but using a more recent kernel is probably a 
better option.

Cheers,
FJP

P.S. Next time, please file a full installation report [3].

[1] http://www.debian.org/devel/debian-installer/
[2] http://kmuto.jp/debian/d-i/
[3] http://www.debian.org/devel/debian-installer/report-template


signature.asc
Description: This is a digitally signed message part.

Re: cannot set a size to lvm partition (size 0 is invalid)

[Frans Pop]

On Tuesday 04 March 2008, Lukasz Szybalski wrote:
> I set the raid 5 partition as a lvm group and not I am trying to
> create lvm partition for my home at 1450GB. I keep getting the error
> that partition size 0 cannot be created.

Could you please file a bug report against partman-lvm for this issue?

> Here is a syslog.
> I don't know why but when I want to create lvm volume:
> 1497303MB is my initial setting.
> I can just hit enter to 1497303MB and it will take it.
>
> But if I pick 1457303MB I get an error.

That's certainly strange. Could possibly have to do with rounding functions.

> What is going on with these numbers. syslog tells  me that 1.36 TB is
> only available? Shouldn't that be 1.4xx TB?

There is some confusion inside partman and between partman and other tools 
about how disk sizes are presented. Disk capacity is usually given as a 
power of 10, while other sizes are in multiples of bytes (power of 2).
So 40MB can be either 40.000.000 bytes or 41.943.040 (40*1024*1024).

> Can somebody explain why I cannot create my 1.45 tb and rest as swap
> partitions?

A solution could be to create the swap first at the required size.

> Also why sys log tells me I have 1.36 even do other 
> screens tell me that my lvm group holds 1.5tb?

See above.

> I tried both. installgui and install when setting these up.

That should not make any difference.


Could you run a new installation and, before partman is started, add a 
line 'set -x' near the top of /lib/partman/definitions.sh?
That will give a huge amount of debugging output in the syslog, but should 
tell us exactly where the error comes from when you reproduce it.

Please attach the syslog (gzipped) to your bug report.

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.

Re: r51742 - trunk/packages/partman/partman-partitioning/debian

[Frans Pop]

On Thursday 06 March 2008, Joey Hess wrote:
>* Add missing sourcing of debconf confmodule in init.d/unsupported.
>  In my tests, this broke installation on mips in qemu when using a
>  blank disk image.

Sorry about that one.
I think this is one of the first real issues from the restructuring I did. 
Still not bad :-P


signature.asc
Description: This is a digitally signed message part.

partman-partitioning_57_i386.changes ACCEPTED

[Debian Installer]

Accepted:
partman-partitioning_57.dsc
  to pool/main/p/partman-partitioning/partman-partitioning_57.dsc
partman-partitioning_57.tar.gz
  to pool/main/p/partman-partitioning/partman-partitioning_57.tar.gz
partman-partitioning_57_i386.udeb
  to pool/main/p/partman-partitioning/partman-partitioning_57_i386.udeb


Override entries for your package:
partman-partitioning_57.dsc - source debian-installer
partman-partitioning_57_i386.udeb - optional debian-installer

Announcing to [EMAIL PROTECTED]


Thank you for your contribution to Debian.


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

Re: Netcfg NULL pointer dereference in custom debian-eeepc d-i

[Frans Pop]

On Wednesday 05 March 2008, Glenn wrote:
> The build appears to have gone well, and I can boot and start the
> installer. When the installer gets to configuring the network, netcfg
> oopses the kernel with a null pointer dereference. If I switch to vt2
> before doing any tasks then I can bring up ath0, set an essid and wep
> key and get a dhcp lease. I tried bringing up both cards before getting
> to the configuring network stage but it still oopses with netcfg.
> However, if the ethernet cable is plugged in during configuration, then
> I can chose either ethernet or the wireless card and from there on all
> seems to work fine. The oops is below but may have some errors as its
> hand typed.

Looks like you've caught a cornercase bug here.
The problem is that ATM we don't really have someone who actively works on 
netcfg, so I would not hold my breath waiting for someone to dive into 
this.

If you have the skills to debug this yourself (or know someone involved in 
Debian Eeepc who does) you're very welcome to work on this yourself.

One thing that could possibly help to narrow this down somewhat could be to 
run an strace on netcfg. There is an strace udeb that can be included in an 
image.

Could you please file a proper bug report against netcfg for this? That will 
help us track the issue.

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.

Re: [RFR] Installation Guide - update of apt-setup section for multiple CDs

[Frans Pop]

On Wednesday 05 March 2008, Jens Seidel wrote:
> > +The amount of data that will be downloaded if you do select a mirror
> > thus
>
> Drop "do"?

Adding "do" here adds emphasis. Note that "do" would be required if the 
sentence were negative ("... if you do not select ..."), so it is 
definitely not wrong.

Other comments covered in my reply to Phil's mail.

Thanks,
FJP


signature.asc
Description: This is a digitally signed message part.

Processing of partman-partitioning_57_i386.changes

[Archive Administrator]

partman-partitioning_57_i386.changes uploaded successfully to localhost
along with the files:
  partman-partitioning_57.dsc
  partman-partitioning_57.tar.gz
  partman-partitioning_57_i386.udeb

Greetings,

Your Debian queue daemon


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

Re: [manual] Update of section on apt-setup

[Frans Pop]

On Thursday 01 November 2007, Holger Wansing wrote:
> To be precise, there is one more criteria for the amount of
> downloaded data: if you use an old full cd or dvd image.
> Using an old image, leads to a high possibility, that packages
> have been updated due to security updates in the meantime (since
> the cd was created).
> All this packages are old on the cd and may be downloaded from
> the internet mirror if security mirror is configured.

I have included this aspect in the new version of the apt-setup section.

Thanks Holger.


signature.asc
Description: This is a digitally signed message part.

Re: [RFR] Installation Guide - update of apt-setup section for multiple CDs

[Frans Pop]

On Thursday 06 March 2008, Philip Hands wrote:
> > > If you are installing from a full CD or a DVD that is part of a
> > > larger
> >
> > I would drop the "a" infront of DVD or "full" altogeher.
>
> I'd rather say that you should drop the full here, since the "is part of
> a larger set" implies a full CD anyway, so how about:
>
>   If you are installing from a CD or DVD that is part of a larger set

Well, we do normally use full to refer to the these images (see e.g. the D-I 
page. Basically we have:
- businesscard CD
- netinst CD
- full CD (where full is meant as "not incomplete")
- DVD (is indeed technically also a full image as it is not incomplete, but
  the prefix is not needed to distinguish it as with CDs)

I repeated "a" because that does make clear that "full" does not refer to 
the DVD. But I agree that set implies that we're talking about full CDs, so 
it could be dropped.

> >> +currently in the drive. Note that only CDs or DVDs that belong to the
> >> +same set should be scanned.
> >
> > Really? I should avoid mixing a weekly snapshot of the first 5 CDs with
> > older onces of the remaining CDs? Wouldn't it be possible that a
> > missing dependency can be resolved on an older disc?
>
> No -- dependencies are always satisfied on earlier disks, and while
> having some older ones tagged on the end might work, it might cause
> upset when things on the earlier disks have been upgraded such that they
> no longer satisfy later dependencies on the later disks.
>
> Also, if things on the earlier disks have grown, then some packages will
> have fallen off the end of the last new disk you have, but still be
> missing on the old one that you might have thought follows it.

Yes. Mixing sets is in general a bad idea, unless you know what you're doing 
or also have a network mirror selected. I don't think we want to suggest to 
people to do that in the manual though.

> I think you have a point here -- how about:
>
>   One advantage of adding a network mirror is that updates that have
>   occurred since the CD/DVS set was made, and are part of a newer point
>   release, will become available for installation, thus extending the
>   life of your CD/DVD set without compromising the security or stability
>   of the installed system.

Right. Used with a few minor modifications.

> Other than that, I'm afraid I'd tend to disagree with most of the other
> points you made (although well done for putting the effort in).  You
> appear to be applying grammatical rules in a way that, while perhaps
> strictly correct, doesn't end up sounding like natural English (of
> course, being English, the only grammar I was ever taught at school was
> in Latin & French, so perhaps I'm not qualified to comment on English
> grammar ;-)

I have made a few other changes based on Jens' comments.

Thanks to you both for the review.


signature.asc
Description: This is a digitally signed message part.

Re: Section about win32-loader in d-i manual

[Frans Pop]

On Wednesday 05 March 2008, Holger Wansing wrote:
> recently there was added a chapter to the manual about the
> win32-loader. There is a paragraph which is a bit curious IMHO.

Thanks. I've mostly applied your patch and made a few additional changes to 
the text.

> At the end of that chapter is a blank line in the source.
> If it is intended to create a real blank line there,
> there are some paragraph tags () missing.

Agreed.


signature.asc
Description: This is a digitally signed message part.

Re: Patch to tidy up wget use, and add return=4 when 404's are seen

[Frans Pop]

On Thursday 06 March 2008, Philip Hands wrote:
> For the retries, I'd have thought that that was related to
> interactiveness, so we could perhaps check one of the existing ways of
> indicating that you're trying to do a mostly non-interactive install,
> and only do the retries if that's the case -- for the extreme case of a
> fully automated install I'd much rather it takes ages and retries
> several times, if it works, than see that a network outage broke the
> install.  Whereas, a normal newbie install should definitely whine about
> a broken network as soon as it's noticed.

Not sure about that. We generally try to avoid really different behavior for 
different types of installs (at least for different priorities) because to 
first thing you do when debugging issues is to lower the priority to gain 
more control.

> Any suggestions on which flag(s) to check to decide the number of retries?

If you're referring to your interactiveness suggestion, I'd think that 
debfonf/priority=critical is the only thing you could use.

I'd propose to leave that until (much) later. Let's first just get a good 
basic framework implemented and tested.


signature.asc
Description: This is a digitally signed message part.

Re: [RFC] Column alignment in debconf {multi,}selects, take 2

[Frans Pop]

On Wednesday 05 March 2008, Jérémy Bobbio wrote:
> Well, after some hard work, it's implemented. :)

Congratulations!

> At some point, I was wondering if it would not be better just to drop
> the whole directive idea and push '\t' forward again, but I have
> actually an use-case for another directive related to "align" support:
> ${!RIGHT_ALIGN}.  As you can see on the attached screenshot, partman's
> choose_partition would be a little bit better if partition sizes were
> right aligned.  Work stills need to be done, though.

I guess that screenshot is with columns implemented, but not yet with the 
right alignment, right?

One thing to keep in mind for implementing columns in partman's main screen 
is that currently the content of columns may differ for different types of 
partition tables. I noticed that myself on my sparc box when I had one disk 
with msdos disklabel and another with sparc disklabel. May even still have 
a screenshot of that around somewhere.
They can also differ (I think) for things like LVM and RAID.
Life is never easy :-/

Something to keep in mind for right aligning a column is to preserve correct 
support for RTL scripts (e.g. Hebrew).

> The attached patch is broken into 11 different commits:

As usual I don't have any real comments on the C code, although I agree that 
it does look fairly clean to my layman's eye.

>  * Add support for the "align" capability to the text frontend
>  * Add support for the "align" capability to the newt frontend
>  * Use the "align" capability for language selection

Looking at these three patches I feel there is still room for improvement 
for the columns implementation.

Take the localechooser patch:
  $translation = $name .
 (" " x (22 - length($name))).
-   "- $translation";
+   "\${!TAB}- $translation";

What you do here is to keep the old spaces based alignment and add the tab 
separator. IMO for really consistent tabs support this should be changed 
to:
  $translation = $name .
-(" " x (22 - length($name))).
-   "- $translation";
+   "\${!TAB}- $translation";
or even:
- $translation = $name .
-(" " x (22 - length($name))).
-   "- $translation";
+ $translation = $name\${!TAB}-\${!TAB}$translation";

This would of course mean that the patches for the text and newt frontends 
would need to do the actual alignment themselves by adding spaces based on 
the width or the actual strings.

In the current implementation adding a tab for the column for these 
frontends is probably even wrong because you also leave the spaces: the tab 
adds extra space.
Also, tabs are possibly not the best option for alignment as their effect 
very much depends on the starting column. I would think that padding with 
spaces would be easier to implement.

Anyway, great progress.

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.

Re: Patch to tidy up wget use, and add return=4 when 404's are seen

[Philip Hands]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Frans Pop wrote:
> On Wednesday 05 March 2008, Philip Hands wrote:
>> The reason I need this is in preseeding scripts, where one can then
>> write code that says:
> 
> Right, that seems like a valid use case.

Glad you liked it :-)

>> If what you're really saying is that you don't understand it, that's OK,
> 
> Yes, that is what I'm saying: I'm unable to judge the impact/risks myself.
> 
>> I've obviously not been clear enough in the README -- Perhaps you could
>> tell which bit's not sufficiently explained and I'll try again.
> 
> No, that's not the problem. The problem is my lack of background here.
> The code is a bit over my head and just "looks" a bit fragile to me. It's on 
> a somewhat lower technical level than what we usually do in shell script 
> and that makes me a bit uncomfortable.
> 
> If others can ack your code, then it would be perfectly fine with me.
>
> Another possible solution could be to have an option to quickly fall back to 
> a simpler version if we see breakage. For example: do this change in two 
> stages: first stage would be to move existing fetch_url functions to 
> di-utils, second stage to implement wget404. That way we could revert the 
> second stage if needed with less risk of conflicts, without needing to 
> change/upload multiple components and without having to change 
> dependencies.
> The two stages would only have to be separate commits, there would not have 
> to be time between them.

Yeah, that should be no problem -- If I take out all the echos and the
sed, I think you get exactly what's needed for the 404-free version of
wget404 (if you know what I mean) -- I'll take a look tomorrow.

...
> What I'm a bit worried about here is seeing huge pauses from a user PoV on 
> wget failures because of all the retries acting as a multiplier of wget's 
> internal timeouts...

Yeah, especially since it'll perhaps be trying as many as 5 times as
often -- very good point.

> I'd really like to hear Joey's take on this. He's probably the best judge to 
> decide between keeping what was implemented or changing to what was 
> intended.

Agreed.

...
> The main problem here of course is that it is almost impossible to trace a 
> report of an installation problem to the use of wget -c. It would certainly 
> not be something that would pop into my mind if a user reported that his 
> installation failed because file X failed to download or was corrupted.

Yeah, good point -- and during testing this I did note that wget will
cheerfully slap the second half of a different file onto a previous
download if you do something like:

  wget url_for_short_file /tmp/foo
...
  wget -c url_for_longer_file /tmp/foo

which is why I put the rm into preseed_fetch (as I have no idea if
people might be relying on preseed_fetch's ability to overwrite the
destination file)

> Again, I find it really hard to judge the risks and pros and cons here.

Likewise -- part of my motivation in discussing this patch was to tease
out what was actually intended in the first place, as it's not
completely clear given things like the not-a-loop loop.

> Maybe it's better to keep things simple. If the user really has a flaky 
> network connection, maybe it's even better to have him notice that early in 
> the installation rather than during debootstrap or tasksel. I have no idea 
> what e.g. debootstrap does when it comes to retrying.
> 
> [/me checks debootstrap's code]
> Hmmm. This is illuminating. debootstrap's functions library has this in the 
> just_get function (wgetprogress calls wget):
> if wgetprogress -O "$dest" "$from"; then
> return 0
> elif [ -s "$dest" ]; then
> local iters=0
> while [ "$iters" -lt 3 ]; do
> warning RETRYING "Retrying failed download of %s" "$from"
> if wgetprogress -c -O "$dest" "$from"; then break; fi
> iters="$(($iters + 1))"
> done
> else
> rm -f "$dest"
> return 1
>fi
> 
> Guess it would make a lot of sense to emulate that. Note that it does not do 
> any full retries, but only a repeated continuation retry.
> 
> Care to take a closer look at that yourself too?

Will do.

One thing I've not really got my head around yet is how wgetprogress
actually communicates with the progress bar stuff -- it did occur to me
that we could perhaps use wgetprogress in fetch-url and then use
fetch-url in debootstrap, but I've not managed to work out if that would
then give us the ability to have progress bars for when downloading
preseeding stuff, or simply break in that situation.  (and I've
definitely _not_ worked out what would need to be done in the way of
insane redirects ;-)

> What I'm starting to think is that maybe we should have two retry loops: one 
> default continuation retry loop as in debootstrap, and an optional full 
> retry loop (if a -r option is passed) that does the full retry, probably 
> only twice.
>
> I'm thinking that net

Re: Patch to tidy up wget use, and add return=4 when 404's are seen

[Frans Pop]

On Thursday 06 March 2008, Frans Pop wrote:
> What I'm starting to think is that maybe we should have two retry loops:
> one default continuation retry loop as in debootstrap, and an optional
> full retry loop (if a -r option is passed) that does the full retry,
> probably only twice.
> I'm thinking that net-retriever probably should /not/ use that -r option
> (which would match current actual behavior), but maybe it would be useful
> in other cases.

Or maybe use a switch to toggle between "continuation" and "full" retries. 
Continuation retries probably make sense for larger files (Packages comes 
to mind) for which the integrity can be checked (md5sum).
Given the caveats in the wget manpage for -c, it may be safer to not do 
continuation retries at all, but just do a full retry in other cases (like 
fetching preseed files).


signature.asc
Description: This is a digitally signed message part.

Re: Patch to tidy up wget use, and add return=4 when 404's are seen

[Frans Pop]

On Wednesday 05 March 2008, Philip Hands wrote:
> The reason I need this is in preseeding scripts, where one can then
> write code that says:

Right, that seems like a valid use case.

> If what you're really saying is that you don't understand it, that's OK,

Yes, that is what I'm saying: I'm unable to judge the impact/risks myself.

> I've obviously not been clear enough in the README -- Perhaps you could
> tell which bit's not sufficiently explained and I'll try again.

No, that's not the problem. The problem is my lack of background here.
The code is a bit over my head and just "looks" a bit fragile to me. It's on 
a somewhat lower technical level than what we usually do in shell script 
and that makes me a bit uncomfortable.

If others can ack your code, then it would be perfectly fine with me.

Another possible solution could be to have an option to quickly fall back to 
a simpler version if we see breakage. For example: do this change in two 
stages: first stage would be to move existing fetch_url functions to 
di-utils, second stage to implement wget404. That way we could revert the 
second stage if needed with less risk of conflicts, without needing to 
change/upload multiple components and without having to change 
dependencies.
The two stages would only have to be separate commits, there would not have 
to be time between them.

> > So basically you now first try a restart and if that fails a new full
> > download and that three times, while in the old code we only did the
> > full retry.
>
> Well, sort-of -- in the old code, this was only used for preseed_fetch
> which did as you say.  In the new code, preseed_fetch wipes out the
> target file before we get here (I'm not sure if that's really needed,
> but it preserves the old behaviour most closely) and then does the
> retries.
>
> On the other hand, the code that's no longer needed in net-retriever
> used to look like it was trying to do the above but actually implemented:
>
>   If the file does not exist, try one wget and return with the result.
>
>   If it does exist, try a wget -c.
>   If that fails, try a wget and return with it's result.

Hmm. I see what you mean. The old code in net-retriever has a retry loop, 
but then always jumps out of the loop on a failure instead of doing any 
retries.

> Perhaps that's what was intended, given that the continuation branch
> seems to imply that there are loops at a higher level deciding to retry
> the download via net-retriever (presumably anna is willing to retry
> net-retriever?).

Looking at the code there is an option to retry in anna, but it's only done 
if the user tells the installer to do so (by choosing retry or e.g. after 
selecting another mirror).

What I'm a bit worried about here is seeing huge pauses from a user PoV on 
wget failures because of all the retries acting as a multiplier of wget's 
internal timeouts...

I'd really like to hear Joey's take on this. He's probably the best judge to 
decide between keeping what was implemented or changing to what was 
intended.

> So, perhaps we need a -c option for fetch-url to indicate that it should
> use wget -c, and have that option specified when calling fetch-url from
> net-retriever -- I certainly don't see it being particularly useful in
> preseeding most of the time, although for people who start grabbing
> things like custom kernels using preseed_fetch it might prove helpful to
> have a continuation retry.

Problem with that is that it would just shift the problem to D-I developers 
having to choose whether -c is appropriate for some usage of fetch-url.

Same goes for a -r (retry) option that I considered while writing this to 
allow to enable or disable the retry loop.

> > I'm not sure if that is wise, given the many caveats listed in the wget
> > manpage for the -c option...
>
> Me neither, but that's how it is in net-retriever, and I'd have thought
> that trying to change that as little as possible makes sense, given that
> it's pretty vital to the install.

Right. I overlooked that.

The retry option from anna does mitigate the caveats a bit: if there was a 
problem _because_ of a continuation, it will mostly be detected (ms5sum of 
package does not match) and the user will be asked if he wants to retry.

The same is not true for other uses of wget, so using -c might be more of a 
problem there, though the risk is probably not huge.

The main problem here of course is that it is almost impossible to trace a 
report of an installation problem to the use of wget -c. It would certainly 
not be something that would pop into my mind if a user reported that his 
installation failed because file X failed to download or was corrupted.

Again, I find it really hard to judge the risks and pros and cons here.

Maybe it's better to keep things simple. If the user really has a flaky 
network connection, maybe it's even better to have him notice that early in 
the installation rather than during debootstrap or tasksel. I have no idea 
what

etch-support 0.02 MIGRATED to testing

[Debian testing watch]

FYI: The status of the etch-support source package
in Debian's testing distribution has changed.

  Previous version: 0.01
  Current version:  0.02

-- 
This email is automatically generated; [EMAIL PROTECTED] is responsible.
See http://people.debian.org/~henning/trille/ for more information.


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

Re: [RFR] Installation Guide - update of apt-setup section for multiple CDs

[Philip Hands]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jens Seidel wrote:
...
> > If you are installing from a full CD or a DVD that is part of a larger
>
> I would drop the "a" infront of DVD or "full" altogeher.
...

I'd rather say that you should drop the full here, since the "is part of
a larger set" implies a full CD anyway, so how about:

  If you are installing from a CD or DVD that is part of a larger set

...
>> +currently in the drive. Note that only CDs or DVDs that belong to the
>> +same set should be scanned.
> 
> Really? I should avoid mixing a weekly snapshot of the first 5 CDs with
> older onces of the remaining CDs? Wouldn't it be possible that a missing
> dependency can be resolved on an older disc?

No -- dependencies are always satisfied on earlier disks, and while
having some older ones tagged on the end might work, it might cause
upset when things on the earlier disks have been upgraded such that they
no longer satisfy later dependencies on the later disks.

Also, if things on the earlier disks have grown, then some packages will
have fallen off the end of the last new disk you have, but still be
missing on the old one that you might have thought follows it.

...
>> +using a network mirror is not required, but is still strongly recommended
>> +because a single CD contains only a fairly limited number of packages.
>   
>> +of a network mirror is optional. One advantage of adding a network mirror is
>> +that it will make updates of packages in point releases of the distribution
> 
> Please check grammar "in point releases"??? Is just a "available"
> missing.?
> 
>> +available for installation.

I think you have a point here -- how about:

  One advantage of adding a network mirror is that updates that have
  occurred since the CD/DVS set was made, and are part of a newer point
  release, will become available for installation, thus extending the
  life of your CD/DVD set without compromising the security or stability
  of the installed system.

Other than that, I'm afraid I'd tend to disagree with most of the other
points you made (although well done for putting the effort in).  You
appear to be applying grammatical rules in a way that, while perhaps
strictly correct, doesn't end up sounding like natural English (of
course, being English, the only grammar I was ever taught at school was
in Latin & French, so perhaps I'm not qualified to comment on English
grammar ;-)

Finally, one change I spotted:

> In most cases you are better of getting
   ^^
   off

Cheers, Phil.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHzyYOYgOKS92bmRARAmd9AKClFVW0a6iT9o5v5hMRvinoIAHpFwCffSi6
AJC1yT98zEOFooYDMpUi3eE=
=yELI
-END PGP SIGNATURE-


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

Re: Patch to tidy up wget use, and add return=4 when 404's are seen

[Philip Hands]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Frans Pop wrote:
> I'm still not sure whether this qualifies as a simplification or not :-/

I'd say it's a simplification in that it takes the tangly wget code from
a couple of places and makes sure there only needs to be one copy -- it
would be nice to work out a way of also moving the wgetprogress code in
here so that a) it doesn't need to be elsewhere, and b) we get progress
bars on all wget downloads, but I was leaving that as a phase 2 project.

I also see the potential for other methods (like nfs for the kickseed
udeb) to be done via fetch-url, which would make the kickseed code
simpler, and provide nfs support wherever we currently have http
support, so the potential for simplification is significantly larger
than demonstrated by this initial patch.

and from the other mail:
> Also, where is the change that actually tests for a return value of 4?
> Or, in other words, how hard do we really need this?

The reason I need this is in preseeding scripts, where one can then
write code that says:

  grab the class file for class X, then if it exists also grab the
  local override file for class X -- if either download fails, halt
  with an error, but if the local file doesn't exist, don't worry

I'm sure there are cases where similar code might be written within d-i
as well, but didn't want to start looking for such cases until we had a
decent patch sorted out.

> Cheers,
> FJP
> 
> On Saturday 01 March 2008, Philip Hands wrote:
>> +++ packages/debian-installer-utils/debian/rules 2008-02-29
>> 21:48:43.0 + @@ -40,13 +40,14 @@
> [...]
>> +dh_link -p di-utils /usr/lib/fetch-url/http /usr/lib/fetch-url/ftp
> 
> Looks like without leading / is preferred.

Fair enough.

>> +++ packages/debian-installer-utils/fetch-url-methods/http   2008-03-01
>> 13:42:40.0 + @@ -0,0 +1,38 @@
>> +protocol_fetch() {
>> +local url="$1"
>> +local file="$2"
>> +
>> +wget404() {
>> +# wrapper for wget that returns 4 for 404 errors while preserving
>> STDERR & STDOUT
>> +# see README.wget404 in the debian-installer-utils udeb source for more
>> info about this
> 
> Second comment can be shortened to:
>see also README.wget404 in debian-installer-utils source package

True.

> 
>> +local RETVAL=$( {  
>> +echo 1
>> +wget "$@" 2>&1 >&3 && echo %OK%
>> +echo %EOF%
>> +} | ( sed -ne '1{h;d};/server returned error
>> 404/{p;s/.*/4/;h;d};/^%OK%$/{s/.*/0/;h;d};$!p;$x;$w /dev/fd/4' >&2 ) 4>&1
>> +) 3>&1
>> +echo "wget404 returns $RETVAL" >> /tmp/fetch-url.log
>> +return $RETVAL
>> +}
> 
> /me somewhat wonders how robust this is and whether it is safe on all 
> architectures and also for other kernels...
> Especially the writing to /dev/fd/4 scares me.

Erm, why?  simply because you don't see to many people using new file
handles in shell?  I'm assuming that you're not saying that we have
architectures where only 3 file handles are available.

Is busybox really so flakey as to have different sed behaviour on
different archs?  That's a little scary if true.  Do you have some examples?

If what you're really saying is that you don't understand it, that's OK,
I've obviously not been clear enough in the README -- Perhaps you could
tell which bit's not sufficiently explained and I'll try again.

>> +# use the proxy for wgets (should speed things up)
>> +if db_get mirror/$proto/proxy; then
>> +export ${proto}_proxy="$RET"
>> +fi
>> +
>> +for i in 1 2 3; do
>> +if [ -e "$file" ]; then
>> +# busybox wget can sometimes become confused
>> +# while resuming, so if it fails, restart
>> +if wget404 -q -c "$url" -O "$file"; then
>> +return 0
>> +fi
>> +fi
>> +
>> +wget404 -q "$url" -O "$file"
>> +local RET=$?
> 
> So basically you now first try a restart and if that fails a new full 
> download and that three times, while in the old code we only did the full 
> retry.

Well, sort-of -- in the old code, this was only used for preseed_fetch
which did as you say.  In the new code, preseed_fetch wipes out the
target file before we get here (I'm not sure if that's really needed,
but it preserves the old behaviour most closely) and then does the retries.

On the other hand, the code that's no longer needed in net-retriever
used to look like it was trying to do the above but actually implemented:

  If the file does not exist, try one wget and return with the result.

  If it does exist, try a wget -c.
  If that fails, try a wget and return with it's result.

Perhaps that's what was intended, given that the continuation branch
seems to imply that there are loops at a higher level deciding to retry
the download via net-retriever (pre

Re: Section about win32-loader in d-i manual

[Otavio Salvador]

Holger Wansing <[EMAIL PROTECTED]> writes:

> --- en/boot-installer/x86.xml 2008-03-04 20:35:57.0 +0100
> +++ en/boot-installer/x86-workingcopy.xml 2008-03-05 21:18:28.0 
> +0100
> @@ -202,11 +202,14 @@
>  
>  
>  
> -If the medium is a CD-ROM or DVD-ROM, when you insert it and a 
> pre-installation program
> -should be launched automatically.  In case Windows doesn't start it, or you 
> are using
> +If the medium is a CD-ROM or DVD-ROM, a pre-installation program
> +should be launched automatically when you insert the disc.
> +In case Windows doesn't start it, or you are using
>  a USB Memory Stick medium, you can run it manually by accessing the device 
> and
>  executing setup.exe.
> +
>  
> +
>  When the program is started, it will ask a few preliminary questions and 
> prepare the
>  system to start the installer.
>  

For me, it looks fine. I'm not a good English speaker and then would
like that someone else commit on it but it does clarify the paragraph.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


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

Re: [RFR] Release Announce draft at wiki

[Jérémy Bobbio]

On Tue, Mar 04, 2008 at 11:07:55PM +, Miguel Figueiredo wrote:
> A Tuesday 04 March 2008 17:44:22, Jérémy Bobbio escreveu:
> > On Mon, Mar 03, 2008 at 08:06:56PM +0100, Frans Pop wrote:
> > > On Wednesday 13 February 2008, Otavio Salvador wrote:
> 
> [...]
> 
> > I strongly disagree.  It took me more than a full day to produce this
> > "changelog" after reviewing more than 1400 entries spread in more than
> > 140 packages.  We create d-i as easily extensible, easily preseedable,
> > and yet we should not give an easy way to know what have happened
> > between major releases?
> 
> [...]
> 
> Do you have a list of those changelogs that you can share?
> That would be an help to identify new functional features and improvements.

I hope I have sucessfully done the work for the status of the installer
on early febuary.  To extract the relevant information from the packages
maintained in the debian-installer repository, use the "viewchanges"
script in the "scripts" directory.

As other packages producing udebs that are not maintained by the
debian-installer team should also be looked at, browsing
packages.debian.org for the debian-installer section is also one way to
do it.

> The content of the Release Announcement should be focused on the d-i itself 
> or 
> on the whole 'lenny'?

We are currently speaking about the release announcement for d-i beta1,
so it is focused on d-i itself.  AFAIK, the release team will coordinate
the writing of the release notes for the "whole Lenny"; d-i release
announcements should help them doing so.

Cheers,
-- 
Jérémy Bobbio.''`. 
[EMAIL PROTECTED]: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Section about win32-loader in d-i manual

[Holger Wansing]

Hello,

recently there was added a chapter to the manual about the
win32-loader. There is a paragraph which is a bit curious IMHO.


And:

At the end of that chapter is a blank line in the source.
If it is intended to create a real blank line there, 
there are some paragraph tags () missing.


My proposal for this is attached as diff.


-- 
Kind regards
Holger

==
Created with Sylpheed 2.3.0
under THE NEW DEBIAN GNU/LINUX 4.0 »Etch«
http://counter.li.org/,  Registered LinuxUser #311290
Try out OpenGL 3D-Desktop Beryl! www.beryl-project.org
=


--- en/boot-installer/x86.xml	2008-03-04 20:35:57.0 +0100
+++ en/boot-installer/x86-workingcopy.xml	2008-03-05 21:18:28.0 +0100
@@ -202,11 +202,14 @@
 
 
 
-If the medium is a CD-ROM or DVD-ROM, when you insert it and a pre-installation program
-should be launched automatically.  In case Windows doesn't start it, or you are using
+If the medium is a CD-ROM or DVD-ROM, a pre-installation program
+should be launched automatically when you insert the disc.
+In case Windows doesn't start it, or you are using
 a USB Memory Stick medium, you can run it manually by accessing the device and
 executing setup.exe.
+
 
+
 When the program is started, it will ask a few preliminary questions and prepare the
 system to start the installer.
 

win32-loader_0.6.4_amd64.changes ACCEPTED

[Debian Installer]

Accepted:
win32-loader_0.6.4.dsc
  to pool/main/w/win32-loader/win32-loader_0.6.4.dsc
win32-loader_0.6.4.tar.gz
  to pool/main/w/win32-loader/win32-loader_0.6.4.tar.gz
win32-loader_0.6.4_all.deb
  to pool/main/w/win32-loader/win32-loader_0.6.4_all.deb


Override entries for your package:
win32-loader_0.6.4.dsc - source utils
win32-loader_0.6.4_all.deb - extra utils

Announcing to [EMAIL PROTECTED]


Thank you for your contribution to Debian.


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

Processing of win32-loader_0.6.4_amd64.changes

[Archive Administrator]

win32-loader_0.6.4_amd64.changes uploaded successfully to localhost
along with the files:
  win32-loader_0.6.4.dsc
  win32-loader_0.6.4.tar.gz
  win32-loader_0.6.4_all.deb

Greetings,

Your Debian queue daemon


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

Re: [PATCH] support live image installing mode selection

[Otavio Salvador]

Christian Perrier <[EMAIL PROTECTED]> writes:

> Quoting Otavio Salvador ([EMAIL PROTECTED]):
>
>
>> +Template: live-installer/mode
>> +Type: select
>> +Default: normal
>> +# :sl3:
>> +__Choices: normal, live
>> +# :sl3:
>> +_Description: Select the installation mode:
>> + Please select the installation mode to be used. This affects how the
>> + resulting system will look:
>> + .
>> +  - normal: just as a installed system;
>> +  - live: still run as a live system;
>> +
>
>
> _Description: Installation mode:
>  Please select the installation mode to be used.
>  .
>  By choosing 'normal', the installed system will be a regular system
>  running from disk while 'live' will continue by running a system
>  without any physical installation on disk.

The 'live' isn't to run without installation but continue to run from
ram, not from the disk. It loads it from disk, instead of CD-ROM. 

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


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

Bug#469533: fails to boot etch netboot/gtk images

[Robert Millan]

Package: loadlin
Version: 1.6c.really1.6c-1.1
Severity: important

When you attempt boot using loadlin and:

  
http://ftp.nl.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/gtk/debian-installer/i386/linux
  
http://ftp.nl.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/gtk/debian-installer/i386/initrd.gz

with standard boot params (initrd=initrd.gz video=vesa:ywrap,mtrr vga=788), it
hangs with a black screen after switching to graphical mode.

I only tried on qemu, but I expect it'd be the same on real hw.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.18-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages loadlin depends on:
ii  libc6 2.7-9  GNU C Library: Shared libraries

loadlin recommends no packages.

-- no debconf information



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

Re: [PATCH] support live image installing mode selection

[Christian Perrier]

Quoting Otavio Salvador ([EMAIL PROTECTED]):


> +Template: live-installer/mode
> +Type: select
> +Default: normal
> +# :sl3:
> +__Choices: normal, live
> +# :sl3:
> +_Description: Select the installation mode:
> + Please select the installation mode to be used. This affects how the
> + resulting system will look:
> + .
> +  - normal: just as a installed system;
> +  - live: still run as a live system;
> +


_Description: Installation mode:
 Please select the installation mode to be used.
 .
 By choosing 'normal', the installed system will be a regular system
 running from disk while 'live' will continue by running a system
 without any physical installation on disk.


But that needs comments by others, probably.




signature.asc
Description: Digital signature

Cursos a iniciar brevemente

[Fordual - Centro de Formação]

Se não conseguir visualizar esta mensagem, clique aqui 



Fordual - Cursos a iniciar brevemente

 

Formação Pedagógica Inicial de Formadores - 26 Março 2008

Formação Pedegagógica Continua de Formadores - 24 Março 2008

Projecto em Energias Renováveis - 29 Março 2008

 
Ao abrigo do DL 67/98 de 26 de Out., o utilizador poderá aceder aos seus dados, 
rectificar ou cancelar os mesmos, conforme o disposto nos artigos 10º e 11º. 
Caso prefira não receber informação adicional por e-mail, remova o seu endereço 
respondendo a este email com o assunto REMOVER.

Netcfg NULL pointer dereference in custom debian-eeepc d-i

[Glenn]

Hi,
   I am try to build a custom d-i for debian-eeepc that has the atheros 
wireless and ethernet modules included. Process used is from the 
following wiki pages.


http://wiki.debian.org/DebianEeePC/HowTo/CustomInstaller
http://wiki.debian.org/DebianInstaller/Modify/CustomKernel

The build appears to have gone well, and I can boot and start the 
installer. When the installer gets to configuring the network, netcfg 
oopses the kernel with a null pointer dereference. If I switch to vt2 
before doing any tasks then I can bring up ath0, set an essid and wep 
key and get a dhcp lease. I tried bringing up both cards before getting 
to the configuring network stage but it still oopses with netcfg. 
However, if the ethernet cable is plugged in during configuration, then 
I can chose either ethernet or the wireless card and from there on all 
seems to work fine. The oops is below but may have some errors as its 
hand typed.


BUG: unable to handle kernel NULL pointer dereference at virtual address 


printing eip:
e010aa85
*pde = 
Oops: 0002 [#1]
Modules linked in: rsrc_nonstatic pcmcia_core vga16fb vgastate 
usb_storage thermal processor fan
sd_mod ahci ata_piix libata scsi_mod wlan_scan_sta ath_rate_sample rtc 
psmouse generic ide_core

ehci_hcd uhci_hcd ath_pci wlan ath_hal(P) atl2 usbcore evdev
CPU:   0
EIP:0060:[]   Tainted: P VL1
EFLAGS:  00010046  (2.6.22-3-486 #1)
EIP is at zz067d2f41+0x4c/0x131 [ath_hal]
eax: c14f81c8  ebx: 0246  ecx: 000c edx: 
esi: deeec3f34  edi:   fs:   gs: 0033  ss: 0068
Process netcfg (pid: 3235, ti=deec2000 task=decfc030 task.ti=deec2000)
Stack: c151f120 0246 deec3f34 fff 0001 e011a279 c14f8000 

  0001  deec3ed8 c151e3c0 e00ed5d8 c14f8000 

  0001  deec3ed8 c14f8000  000 
deec

Call Trace:
[] zz016d9d41+0x37/0x43 [ath_hal]
[] ath_ioctl+0x1aa/0x26d [ath_pci]
[] ath_ioctl+0x0/0x26d [ath_pci]
[] dev_ifsioc+0x37f/0x39a
[] dev_ioctl+0x37c/0x3d6
[] sock_alloc_inode+0x20/0x4e
[] do_filp_open+0x2a/0x3e
[] sock_ioctl+0x19f/0x1be
[] sock_ioctl+0x0/0x1be
[] do_ioctl+0x19/0x4c
[] vfs_ioctl+0x1f4/0x20b
[] sys_ioctl+0x4c/0x65
[] syscall_call+0x7/0xb
[] skb_icv_walk+0x7c/0x1d7
===
Code: 00 83 f8 1d 66 90 0f 84 9a 00 00 00 83 f8 1e 8d b4 26 00 00 00 00 
0f 85 e7
00 00 00 e9 a2 00 00 00 8d 85 c8 01 00 00 8b 54 24 28 <89> 02 8b 44 24 
2c c7 00

10 00 00 00 b8 01 00 00 00 e9 c7 00 00
EIP: [] zz067d2f41+0x4c/0x131 [ath_hal] SS:ESP 0068:deec3e64

Debian installer version is svn 51717 built today, using a standard 
2.6.23-3-486 kernel from lenny with the atl2 and madwifi modules 
compiled. Built on a sid machine. Please CC me as I am not subscribed to 
the list.


Thanks

Glenn


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

Re: unblock for few packages that builds udeb

[Philipp Kern]

On Wed, Mar 05, 2008 at 02:32:03PM +0100, Frans Pop wrote:
> Note that I did not include hdparm in my list of "problem" packages, so that 
> can be hinted as well:
> unblock hdparm/8.3-1

Done.

Kind regards,
Philipp Kern
-- 
 .''`.  Philipp Kern Debian Developer
: :' :  http://philkern.de   Debian Release Assistant
`. `'   xmpp:[EMAIL PROTECTED]
  `-finger pkern/[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: unblock for few packages that builds udeb

[Frans Pop]

On Wednesday 05 March 2008, Otavio Salvador wrote:
> RM team, please apply only win32-loader one. Others I ask again after
> images be done.

Note that I did not include hdparm in my list of "problem" packages, so that 
can be hinted as well:

unblock hdparm/8.3-1


signature.asc
Description: This is a digitally signed message part.

Re: unblock for few packages that builds udeb

[Philipp Kern]

On Wed, Mar 05, 2008 at 09:42:31AM -0300, Otavio Salvador wrote:
> RM team, please apply only win32-loader one. Others I ask again after
> images be done.

win32-loader unblocked.

Cheers,
Philipp Kern
-- 
 .''`.  Philipp Kern Debian Developer
: :' :  http://philkern.de   Debian Release Assistant
`. `'   xmpp:[EMAIL PROTECTED]   Ubuntu MOTU
  `-finger pkern/[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: unblock for few packages that builds udeb

[Otavio Salvador]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Frans Pop <[EMAIL PROTECTED]> writes:

> On Wednesday 05 March 2008, Otavio Salvador wrote:
>> unblock gtk+2.0/2.12.8-1
>> unblock win32-loader/0.6.3
>> unblock openssl/0.9.8g-7
>> unblock ttf-sil-abyssinica/1.0-4
>
> IMO these would be better left until after the D-I release as they have 
> udebs that are included in D-I initrds and the D-I images for beta1 have 
> already been built.
>
> Unless of course you are planning another D-I upload, but I'm not aware of 
> any reason for one.

Ok however win32-loader should go. It was used since it's a
build-depends of installer and hence this would put d-i on sync with
the archive packages in lenny. Rest can be delayed.

It wouldn't change anything for d-i since those were already on the
initrd but how left archive and initrd out of sync.

RM team, please apply only win32-loader one. Others I ask again after
images be done.

- -- 
O T A V I OS A L V A D O R
- -
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
- -
"Microsoft sells you Windows ... Linux gives
 you the whole house."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iD8DBQFHzpU1LqiZQEml+FURAkxbAJ9sr7rsxkD5WoGdn//mwKWSa7DhPgCfRv6m
k+31TIpimmCT7vaPXGJELJo=
=e2H9
-END PGP SIGNATURE-


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

Re: [RFR] Installation Guide - update of apt-setup section for multiple CDs

[Jens Seidel]

On Wed, Mar 05, 2008 at 03:27:02AM +0100, Frans Pop wrote:
> I've updated the section in the installation guide about configuring apt to 
> describe that it is now possible to scan multiple CDs.
> 
> I'd welcome comments on the new text before I commit the changes.

My comments are maybe a little bit too verbose, so ignore anything you
do not like ...

> +If you are installing from a full CD or a DVD that is part of a larger

I would drop the "a" infront of DVD or "full" altogeher. What does
"full" stand for? A non netinst or business version of the installer?
You know that it is possible to burn such an image also on a DVD, in
this case "full" should also apply to DVD. But maybe I understand "full"
wrong.

> +set, the installer will ask if you want to scan additional CDs or DVDs.
> +If you have additional CDs or DVDs available, you probably want to do
> +this so the installer can use the packages included on them.

> +them is not required. If you also do not use a network mirror (as explained
> +in the next section), it can mean that not all packages belonging to the
> +tasks you select in the next step of the installation can be installed.

you WILL select?

> +Packages are included on CDs in the order of their popularity. This means

Above you write "CDs or DVDs" here you mention only CDs.

> +that for most uses only the first CDs in a set are needed and that only

Plural of CD was intended? Maybe "first few CDs" to avoid confusion with
"first CD" ...

> +very few people actually use any of the packages included on the last CDs
> +in a set.

> +If you do scan multiple CDs or DVDs, the installer will prompt you to

Drop "do" or replace with "will"?

> +exchange them when it needs packages from another CD/DVD than the one

CD/DVD is used beside "CD or DVD" from above ...

> +currently in the drive. Note that only CDs or DVDs that belong to the
> +same set should be scanned.

Really? I should avoid mixing a weekly snapshot of the first 5 CDs with
older onces of the remaining CDs? Wouldn't it be possible that a missing
dependency can be resolved on an older disc?

> +If you are installing from a full CD or using a full CD image (not DVD),

"not DVD" refers only to the image? Otherwise remember that it is indeed
possible to burn a CD image on a DVD (lack of empty CDs ...).

> +using a network mirror is not required, but is still strongly recommended
> +because a single CD contains only a fairly limited number of packages.
  
> +of a network mirror is optional. One advantage of adding a network mirror is
> +that it will make updates of packages in point releases of the distribution

Please check grammar "in point releases"??? Is just a "available"
missing.?

> +available for installation.
  
> +In summary: selecting a network mirror is generally a good idea, except

s/selecting/Selecting/ ???

> +if you do not have a good Internet connection. If the current version of
> +a package is available on the CD/DVD, the installer will always use that.

s,the CD/DVD,a CD/DVD,

> +The amount of data that will be downloaded if you do select a mirror thus

Drop "do"?

> +depends on
  
> +which of those packages are present on the CDs or DVDs you have scanned, and
  
> +whether any updated versions of packages included on the CDs or DVDs are

Plural of "version" after "any" is OK?

> +available from a mirror (either a regular package mirror, or a mirror for
> +security or volatile updates).
  
Jens


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