date:20040107

official net install for 'testing' offline..

2004-01-07 Thread Allen Beye Riddell


how soon might the netinstsall cd images for 'testing' be online? the link
doesn't seem to work..

http://gluck.debian.org/cdimage/testing/netinst/

best,

abr

Making CD bootable

2004-01-07 Thread Clark Green









Hello,

 

I’ve
just run jigdo for the first time and the process was successful.

 

After
having burned the .iso image to a CD, I find it does not boot.  My BIOS boot
device settings are fine; other bootable CDs (.iso image of Knoppix, for
example) work just fine.

 

Is
there something I need to do to make the CD bootable?

 

Thanks
in advance!

Clark
Green

official net install for 'testing' offline..

2004-01-07 Thread Allen Beye Riddell


how soon might the netinstsall cd images for 'testing' be online? the link
doesn't seem to work..

http://gluck.debian.org/cdimage/testing/netinst/

best,

abr


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

Making CD bootable

2004-01-07 Thread Clark Green









Hello,

 

I’ve
just run jigdo for the first time and the process was successful.

 

After
having burned the .iso image to a CD, I find it does not boot.  My BIOS boot
device settings are fine; other bootable CDs (.iso image of Knoppix, for
example) work just fine.

 

Is
there something I need to do to make the CD bootable?

 

Thanks
in advance!

Clark
Green

Problem with a link in the translated version

2004-01-07 Thread Marcos Vinicius Lazarini

Hi,
I was trying to download the r2 updated version but the portuguese site 
has a problem, in the following page:
http://www.debian.org/CD/jigdo-cd/index.pt.html

here, the link to the .jigdo files
"Arquivos jigdo oficiais para a distribuição "stable" em CD: espelho em 
EUA , espelho na 
Europa "
points to r1, not r2.
http://us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/
not
http://us.cdimage.debian.org/jigdo-area/3.0_r2/jigdo/

I noticed that spanish and french have also the same problem.
Maybe its better to point the link to a parent directory to make this 
link imune to that sort of problem... and to make life simpler to the 
webpage matainer... :-)

Thanks for the wonderful work,
Marcos Lazarini

Problem with a link in the translated version

2004-01-07 Thread Marcos Vinicius Lazarini

Hi,

I was trying to download the r2 updated version but the portuguese site 
has a problem, in the following page:
http://www.debian.org/CD/jigdo-cd/index.pt.html

here, the link to the .jigdo files
"Arquivos jigdo oficiais para a distribuição "stable" em CD: espelho em 
EUA , espelho na 
Europa "
points to r1, not r2.
http://us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/
not
http://us.cdimage.debian.org/jigdo-area/3.0_r2/jigdo/

I noticed that spanish and french have also the same problem.

Maybe its better to point the link to a parent directory to make this 
link imune to that sort of problem... and to make life simpler to the 
webpage matainer... :-)

Thanks for the wonderful work,

Marcos Lazarini

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

Re: Future of debian-cd

2004-01-07 Thread Steve McIntyre

On Wed, Jan 07, 2004 at 11:20:58AM -0500, Joey Hess wrote:
>Raphael Hertzog wrote:
>> Here are the main critics that I have :
>
>Let me add my main problem:
>
>- Requires a full debian mirror to work.
>
>IMHO, it would be much better to follow the lead of how d-i builds its
>boot images, by using apt to download (u)debs. debian-cd would also need
>to use wget or something for the non-deb components, but it should be
>possible to use it with nothing but a network connection, and caching.

Something that Phil and I discussed a while ago - it should be
feasible to produce jigdo images of CDs directly from Packages,
Release and/or Sources files without needing any of the rest of the
mirror. With the patch I've made to mkisofs and some extra work in
jigdo itself, we should be able to drop production times for images
from multiple hours down to a few minutes...

Sound interesting? :-)

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/

signature.asc
Description: Digital signature

Re: Future of debian-cd

2004-01-07 Thread Steve McIntyre

On Wed, Jan 07, 2004 at 11:20:58AM -0500, Joey Hess wrote:
>Raphael Hertzog wrote:
>> Here are the main critics that I have :
>
>Let me add my main problem:
>
>- Requires a full debian mirror to work.
>
>IMHO, it would be much better to follow the lead of how d-i builds its
>boot images, by using apt to download (u)debs. debian-cd would also need
>to use wget or something for the non-deb components, but it should be
>possible to use it with nothing but a network connection, and caching.

Something that Phil and I discussed a while ago - it should be
feasible to produce jigdo images of CDs directly from Packages,
Release and/or Sources files without needing any of the rest of the
mirror. With the patch I've made to mkisofs and some extra work in
jigdo itself, we should be able to drop production times for images
from multiple hours down to a few minutes...

Sound interesting? :-)

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/

signature.asc
Description: Digital signature

Re: Future of debian-cd

2004-01-07 Thread Tollef Fog Heen

* Jan Kesten 

| Here is the perl way of opening a file, reading it and sorting the
| lines into a new file:

#! /usr/bin/perl -w

use strict;

my $file = shift;
open IN, "<$file" or die "Can't open $file: $!";
open OUT, ">$file.sorted" or die "Can't open $file.sorted: $!";

print OUT sort ;

This is fairly readable to me at least; yes, it's possible to write it
shorter, and it's possible to write it without strict, but it's a nice
safety net.

| And the python way looks like this:

[...]


| Some other thing is that python knows about classes :-) But I do not
| want to start a discussion about pro perl or python :-)

I don't think the python code here looks better at all.  It's possible
to write both readable and unreadable python or perl.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-

Re: Future of debian-cd

2004-01-07 Thread Hans Ginzel

On Wed, Jan 07, 2004 at 06:00:51PM +0100, Jan Kesten wrote:
> # Datei lesen
> open DATEI, "<$dateiname" or die "$dateiname laesst sich nicht oeffnen\n";

   Use the $! variable (man perlvar; perldoc perlvar; www.perldoc.com):
open DATEI, "<$dateiname" or die "Datei `$dateiname' laesst sich nicht oeffnen: 
$!\n";

> @zeilen =   or die "$dateiname ist nicht lesbar\n"
> close DATEI;

   close DATEI or warn "Cannot close file `$dateiname': $!\n";

> # sortieren

   You can sort just by reading:

@sorted_zeilen = sort  or die $!;

> -  SNIP 
>
> And the python way looks like this:
>
> # Datei lesen
> try:
> datei = open(dateiname, 'r')
> zeilen = datei.readlines()
> datei.close()
> except IOError:
> print dateiname, "ist nicht lesbar"
> sys.exit( 1 )

   That's not what is above in perl. I understand especially: you
are saying that Python has exceptions. But Perl also has! Read about
`eval' in man perlfunc or `perldoc -f eval'. The advantidge of using
"die" for each part of code is that you can give more precise error
message, even more if combined with the `$!' variable. Above Python code
would be almost ekvivalently rewritten into Perl:

eval {
open DATEI, "<$dateiname" or die $!;
@zeilen =  or die $!;
close DATEI;
}
die "Datei `$dateiname' ist nicht lesbar: [EMAIL PROTECTED]" if $@;

> Some other thing is that python knows about classes :-) But I do not

   Perl also knows about classes (perldoc -f bless; man perlboot,
perltoot, perlobj).

> want to start a discussion about pro perl or python :-)

   Nor want I, but be precise.

Best regards

Hans Ginzel

webpage missing

2004-01-07 Thread Royal




 
Not FoundThe requested URL /cdimage/testing/netinst/ was not found on 
this server.



Apache/1.3.26 Server at gluck.debian.org Port 
80

Re: Future of debian-cd

2004-01-07 Thread Raphael Hertzog

[ I cced [EMAIL PROTECTED] in my initial mail in order to have a paragraph
about debian-cd in DWN next week - no need to continue CCing them even
if my Mail-Followup-To included them ]

Le Wed, Jan 07, 2004 at 03:59:52PM +0100, Richard Atterer écrivait:
> I think the idea of using a Makefile at all wasn't that good in retrospect. 

In some aspects it was interesting, I liked to be able to avoid redoing
stuff which were already done when I corrected something by hand. But
that's it.

> Maybe it would be nicer to use "run-parts": A top-level script executes
> everything in a "stages" directory in alphabetical order. The individual
> stages could then have further directories of their own where
> substage-scripts for that stage of the process are stored. This would get 
> rid of all that "hook" ugliness...
> 
> There could be different top-level "stages" directories for the different 
> CD flavours, with symlinks to scripts which are identical between any two 
> of them. This has the advantage that you can fork code any time; instead of 
> linking from the sarge version to the woody version, just make a copy of 
> the script, then make changes/hacks which are woody-only.
> 
> Each top-level "stages" dir could also come with configuration files 
> preconfigured for that particular CD flavour.
> 
> Well, something like that... I don't know if the above would work. :)

It's exactly something like that that I had in mind when I spoke of
"profile" in my initial mail. And I have the same problem than you, it
looks like nice but I didn't took the time to see it it fits as well as
I hope.

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com
Earn money with free software: http://www.geniustrader.org

Re: Future of debian-cd

2004-01-07 Thread Tollef Fog Heen

* Jan Kesten 

| Here is the perl way of opening a file, reading it and sorting the
| lines into a new file:

#! /usr/bin/perl -w

use strict;

my $file = shift;
open IN, "<$file" or die "Can't open $file: $!";
open OUT, ">$file.sorted" or die "Can't open $file.sorted: $!";

print OUT sort ;

This is fairly readable to me at least; yes, it's possible to write it
shorter, and it's possible to write it without strict, but it's a nice
safety net.

| And the python way looks like this:

[...]


| Some other thing is that python knows about classes :-) But I do not
| want to start a discussion about pro perl or python :-)

I don't think the python code here looks better at all.  It's possible
to write both readable and unreadable python or perl.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: Future of debian-cd

2004-01-07 Thread Hans Ginzel

On Wed, Jan 07, 2004 at 06:00:51PM +0100, Jan Kesten wrote:
> # Datei lesen
> open DATEI, "<$dateiname" or die "$dateiname laesst sich nicht oeffnen\n";

   Use the $! variable (man perlvar; perldoc perlvar; www.perldoc.com):
open DATEI, "<$dateiname" or die "Datei `$dateiname' laesst sich nicht oeffnen: $!\n";

> @zeilen =   or die "$dateiname ist nicht lesbar\n"
> close DATEI;

   close DATEI or warn "Cannot close file `$dateiname': $!\n";

> # sortieren

   You can sort just by reading:

@sorted_zeilen = sort  or die $!;

> -  SNIP 
>
> And the python way looks like this:
>
> # Datei lesen
> try:
> datei = open(dateiname, 'r')
> zeilen = datei.readlines()
> datei.close()
> except IOError:
> print dateiname, "ist nicht lesbar"
> sys.exit( 1 )

   That's not what is above in perl. I understand especially: you
are saying that Python has exceptions. But Perl also has! Read about
`eval' in man perlfunc or `perldoc -f eval'. The advantidge of using
"die" for each part of code is that you can give more precise error
message, even more if combined with the `$!' variable. Above Python code
would be almost ekvivalently rewritten into Perl:

eval {
open DATEI, "<$dateiname" or die $!;
@zeilen =  or die $!;
close DATEI;
}
die "Datei `$dateiname' ist nicht lesbar: [EMAIL PROTECTED]" if $@;

> Some other thing is that python knows about classes :-) But I do not

   Perl also knows about classes (perldoc -f bless; man perlboot,
perltoot, perlobj).

> want to start a discussion about pro perl or python :-)

   Nor want I, but be precise.

Best regards

Hans Ginzel

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

webpage missing

2004-01-07 Thread Royal




 
Not FoundThe requested URL /cdimage/testing/netinst/ was not found on 
this server.



Apache/1.3.26 Server at gluck.debian.org Port 
80

Re: Future of debian-cd

2004-01-07 Thread Raphael Hertzog

[ I cced [EMAIL PROTECTED] in my initial mail in order to have a paragraph
about debian-cd in DWN next week - no need to continue CCing them even
if my Mail-Followup-To included them ]

Le Wed, Jan 07, 2004 at 03:59:52PM +0100, Richard Atterer écrivait:
> I think the idea of using a Makefile at all wasn't that good in retrospect. 

In some aspects it was interesting, I liked to be able to avoid redoing
stuff which were already done when I corrected something by hand. But
that's it.

> Maybe it would be nicer to use "run-parts": A top-level script executes
> everything in a "stages" directory in alphabetical order. The individual
> stages could then have further directories of their own where
> substage-scripts for that stage of the process are stored. This would get 
> rid of all that "hook" ugliness...
> 
> There could be different top-level "stages" directories for the different 
> CD flavours, with symlinks to scripts which are identical between any two 
> of them. This has the advantage that you can fork code any time; instead of 
> linking from the sarge version to the woody version, just make a copy of 
> the script, then make changes/hacks which are woody-only.
> 
> Each top-level "stages" dir could also come with configuration files 
> preconfigured for that particular CD flavour.
> 
> Well, something like that... I don't know if the above would work. :)

It's exactly something like that that I had in mind when I spoke of
"profile" in my initial mail. And I have the same problem than you, it
looks like nice but I didn't took the time to see it it fits as well as
I hope.

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com
Earn money with free software: http://www.geniustrader.org


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

Re[2]: Future of debian-cd

2004-01-07 Thread Jan Kesten

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

bid> Well, I always had my doubts about Python. Of course, I have done
bid> next to nothing with Python and quite some code in Perl, so quite
bid> different experiences ;)

bid> Of course Perl has other problems like readability of code and
bid> soon compatibility problems when they switch from 5 to 6.

That's why I prefered python ;-) It's very easy to read and
understand: Look here... some thing I found on a website - it is in
german but I think it doesn't matter if I do not translate it:

Here is the perl way of opening a file, reading it and sorting the
lines into a new file:

-  SNIP 
#!/usr/bin/perl -w

# Dateiname ermitteln
$dateiname = shift;

# Datei lesen
open DATEI, "<$dateiname"  or
  die "$dateiname laesst sich nicht oeffnen\n"
@zeilen =   or
  die "$dateiname ist nicht lesbar\n"
close DATEI;

# sortieren
@zeilen = sort @zeilen;
$dateiname .= '.sortiert';

# Datei schreiben
open DATEI, ">$dateiname"  or
   die "$dateiname laesst sich nicht oeffnen\n"
print DATEI @zeilen  or
  die "$dateiname ist nicht schreibbar\n"
close DATEI  or  die "$dateiname ist nicht schreibbar\n"
-  SNIP 

And the python way looks like this:

-  SNIP 
#!/usr/bin/python
import sys

# Dateiname ermitteln
dateiname = sys.argv[ 1 ]

# Datei lesen
try:
datei = open( dateiname, 'r' )
zeilen = datei.readlines()
datei.close()
except IOError:
print dateiname, "ist nicht lesbar"
sys.exit( 1 )

# Datei sortieren
zeilen.sort()
dateiname = dateiname + '.sortiert'

# Datei schreiben
try:
datei = open( dateiname, 'w' )
datei.writelines( zeilen )
datei.close()
except IOError:
print dateiname, "ist nicht schreibbar"
-  SNIP 

Some other thing is that python knows about classes :-) But I do not
want to start a discussion about pro perl or python :-)

Cheers,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (MingW32)
Comment: Benutzt PGP! Fragen? [EMAIL PROTECTED]

iD8DBQE//DtFvvmCkIIgH8QRAu8RAJoCCmI1b7l0I61JhxfITE7fs3UWNwCeKJJD
2VdRCbn8f8ABcuzSewy7L/8=
=Mg3n
-END PGP SIGNATURE-

Re[2]: Future of debian-cd

2004-01-07 Thread Jan Kesten

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi all!

bid> Since debian-cd is no longer available to the public, it is very
bid> difficult to test currently. Maybe someone could provide a
bid> current .deb package for testing or unstable, so people can
bid> actually try out the most recent version.

But why isn't it? I used it for a long time to provide most recent
testing and unstable images of debian here - still the old one works,
but for how long? Is there any way to get access to the cvs version by
now?

bid> DVD worked fine for 3.0r1/i386 (large ISO9660), I don't know
bid> about other architectures and I could not check this for 3.0r2
bid> yet.

I got working DVD here too, and also for 3.0r2. By the way, are there
any "official" ones right now? Last year (long ago :-) we talked about
the images and resulting jigdo templates here - they were/are very
big..

bid> Are the "maintainers" of the "testing" and "unstable" CDs/DVD
bid> images still using debian-cd or something else ?

For my part I use debian-cd - like written above an old version, in
fact the last one I got from cvs before the compromise of debian's
servers. Since then, every time I tried to logon to cvs.d.o I got a
"connection refused" after logging in as an anonymous user.

>> - how do you think we should proceed ? should I start from a
>> completely new repository and import only what I want to keep ?
>> should we work in a branch of the actual repository ?

I would say, starting a new repository would be the best case, since I
think a (more or less) new debian-cd script will be in many cases
differernt form the actual one.

bid> For me, it was a bit difficult to follow all the source code and
bid> understand about including and excluding packages. Maybe a
bid> central documentation file for people who want to help modify or
bid> extend debian-cd would be great. While bash is not the best
bid> programming language, I can't think of a more suitable one; maybe
bid> Perl.

Thanks Bernd! That would be my idea - the old one is very bad
documentated right, and it took me a long time to understand what it
does. So I also agree to do it now in script language - perl or python
would be glad. If I had to decide I would prefer python, it's easier
to maintain and read for "beginners" (and I have done a lot of work in
python but just some snippets of perl in the past, so this is my point
of view).

Cheers,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (MingW32)
Comment: Benutzt PGP! Fragen? [EMAIL PROTECTED]

iD8DBQE//BmSvvmCkIIgH8QRAiNgAJ9SoMNG/tuQdX/YdrQK/rVI3zqgXwCgwlEW
4KpZ46gjBqN589TLBU3ueas=
=tjpK
-END PGP SIGNATURE-

Re: Future of debian-cd

2004-01-07 Thread Joey Hess

Raphael Hertzog wrote:
> Here are the main critics that I have :

Let me add my main problem:

- Requires a full debian mirror to work.

IMHO, it would be much better to follow the lead of how d-i builds its
boot images, by using apt to download (u)debs. debian-cd would also need
to use wget or something for the non-deb components, but it should be
possible to use it with nothing but a network connection, and caching.

-- 
see shy jo


signature.asc
Description: Digital signature

Re[2]: Future of debian-cd

2004-01-07 Thread Jan Kesten

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

bid> Well, I always had my doubts about Python. Of course, I have done
bid> next to nothing with Python and quite some code in Perl, so quite
bid> different experiences ;)

bid> Of course Perl has other problems like readability of code and
bid> soon compatibility problems when they switch from 5 to 6.

That's why I prefered python ;-) It's very easy to read and
understand: Look here... some thing I found on a website - it is in
german but I think it doesn't matter if I do not translate it:

Here is the perl way of opening a file, reading it and sorting the
lines into a new file:

-  SNIP 
#!/usr/bin/perl -w

# Dateiname ermitteln
$dateiname = shift;

# Datei lesen
open DATEI, "<$dateiname"  or
  die "$dateiname laesst sich nicht oeffnen\n"
@zeilen =   or
  die "$dateiname ist nicht lesbar\n"
close DATEI;

# sortieren
@zeilen = sort @zeilen;
$dateiname .= '.sortiert';

# Datei schreiben
open DATEI, ">$dateiname"  or
   die "$dateiname laesst sich nicht oeffnen\n"
print DATEI @zeilen  or
  die "$dateiname ist nicht schreibbar\n"
close DATEI  or  die "$dateiname ist nicht schreibbar\n"
-  SNIP 

And the python way looks like this:

-  SNIP 
#!/usr/bin/python
import sys

# Dateiname ermitteln
dateiname = sys.argv[ 1 ]

# Datei lesen
try:
datei = open( dateiname, 'r' )
zeilen = datei.readlines()
datei.close()
except IOError:
print dateiname, "ist nicht lesbar"
sys.exit( 1 )

# Datei sortieren
zeilen.sort()
dateiname = dateiname + '.sortiert'

# Datei schreiben
try:
datei = open( dateiname, 'w' )
datei.writelines( zeilen )
datei.close()
except IOError:
print dateiname, "ist nicht schreibbar"
-  SNIP 

Some other thing is that python knows about classes :-) But I do not
want to start a discussion about pro perl or python :-)

Cheers,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (MingW32)
Comment: Benutzt PGP! Fragen? [EMAIL PROTECTED]

iD8DBQE//DtFvvmCkIIgH8QRAu8RAJoCCmI1b7l0I61JhxfITE7fs3UWNwCeKJJD
2VdRCbn8f8ABcuzSewy7L/8=
=Mg3n
-END PGP SIGNATURE-


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

Re[2]: Future of debian-cd

2004-01-07 Thread Jan Kesten

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi all!

bid> Since debian-cd is no longer available to the public, it is very
bid> difficult to test currently. Maybe someone could provide a
bid> current .deb package for testing or unstable, so people can
bid> actually try out the most recent version.

But why isn't it? I used it for a long time to provide most recent
testing and unstable images of debian here - still the old one works,
but for how long? Is there any way to get access to the cvs version by
now?

bid> DVD worked fine for 3.0r1/i386 (large ISO9660), I don't know
bid> about other architectures and I could not check this for 3.0r2
bid> yet.

I got working DVD here too, and also for 3.0r2. By the way, are there
any "official" ones right now? Last year (long ago :-) we talked about
the images and resulting jigdo templates here - they were/are very
big..

bid> Are the "maintainers" of the "testing" and "unstable" CDs/DVD
bid> images still using debian-cd or something else ?

For my part I use debian-cd - like written above an old version, in
fact the last one I got from cvs before the compromise of debian's
servers. Since then, every time I tried to logon to cvs.d.o I got a
"connection refused" after logging in as an anonymous user.

>> - how do you think we should proceed ? should I start from a
>> completely new repository and import only what I want to keep ?
>> should we work in a branch of the actual repository ?

I would say, starting a new repository would be the best case, since I
think a (more or less) new debian-cd script will be in many cases
differernt form the actual one.

bid> For me, it was a bit difficult to follow all the source code and
bid> understand about including and excluding packages. Maybe a
bid> central documentation file for people who want to help modify or
bid> extend debian-cd would be great. While bash is not the best
bid> programming language, I can't think of a more suitable one; maybe
bid> Perl.

Thanks Bernd! That would be my idea - the old one is very bad
documentated right, and it took me a long time to understand what it
does. So I also agree to do it now in script language - perl or python
would be glad. If I had to decide I would prefer python, it's easier
to maintain and read for "beginners" (and I have done a lot of work in
python but just some snippets of perl in the past, so this is my point
of view).

Cheers,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (MingW32)
Comment: Benutzt PGP! Fragen? [EMAIL PROTECTED]

iD8DBQE//BmSvvmCkIIgH8QRAiNgAJ9SoMNG/tuQdX/YdrQK/rVI3zqgXwCgwlEW
4KpZ46gjBqN589TLBU3ueas=
=tjpK
-END PGP SIGNATURE-


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

Re: Future of debian-cd

2004-01-07 Thread Joey Hess

Raphael Hertzog wrote:
> Here are the main critics that I have :

Let me add my main problem:

- Requires a full debian mirror to work.

IMHO, it would be much better to follow the lead of how d-i builds its
boot images, by using apt to download (u)debs. debian-cd would also need
to use wget or something for the non-deb components, but it should be
possible to use it with nothing but a network connection, and caching.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Future of debian-cd

2004-01-07 Thread Richard Atterer

On Wed, Jan 07, 2004 at 02:16:39PM +0100, Raphael Hertzog wrote:
> - complicated shell code in Makefile is ugly, it was supposed to
>   not need to be modified, and in fact many parts of the Makefile
>   were modified for various purposes

I think the idea of using a Makefile at all wasn't that good in retrospect. 
Maybe it would be nicer to use "run-parts": A top-level script executes
everything in a "stages" directory in alphabetical order. The individual
stages could then have further directories of their own where
substage-scripts for that stage of the process are stored. This would get 
rid of all that "hook" ugliness...

There could be different top-level "stages" directories for the different 
CD flavours, with symlinks to scripts which are identical between any two 
of them. This has the advantage that you can fork code any time; instead of 
linking from the sarge version to the woody version, just make a copy of 
the script, then make changes/hacks which are woody-only.

Each top-level "stages" dir could also come with configuration files 
preconfigured for that particular CD flavour.

Well, something like that... I don't know if the above would work. :)

> - we have too many imbricated options which do not make sense to many
>   of us, it's time to see if we shouldn't get rid of some of them
>   (or at least hide them somewhere deeper than CONF.sh)

Yeah, CONF.sh has become far too big. It might make sense to split stuff up 
into several config files - after all, if e.g. you don't want to generate 
.jigdo files, you don't even need to look at the related options.

> - how do you think we should proceed ? should I start from a completely
>   new repository and import only what I want to keep ? should we work in
>   a branch of the actual repository ?

IMHO the kind soul who tackles this should start from scratch. :-7

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

Re: Future of debian-cd

2004-01-07 Thread Richard Atterer

On Wed, Jan 07, 2004 at 02:16:39PM +0100, Raphael Hertzog wrote:
> - complicated shell code in Makefile is ugly, it was supposed to
>   not need to be modified, and in fact many parts of the Makefile
>   were modified for various purposes

I think the idea of using a Makefile at all wasn't that good in retrospect. 
Maybe it would be nicer to use "run-parts": A top-level script executes
everything in a "stages" directory in alphabetical order. The individual
stages could then have further directories of their own where
substage-scripts for that stage of the process are stored. This would get 
rid of all that "hook" ugliness...

There could be different top-level "stages" directories for the different 
CD flavours, with symlinks to scripts which are identical between any two 
of them. This has the advantage that you can fork code any time; instead of 
linking from the sarge version to the woody version, just make a copy of 
the script, then make changes/hacks which are woody-only.

Each top-level "stages" dir could also come with configuration files 
preconfigured for that particular CD flavour.

Well, something like that... I don't know if the above would work. :)

> - we have too many imbricated options which do not make sense to many
>   of us, it's time to see if we shouldn't get rid of some of them
>   (or at least hide them somewhere deeper than CONF.sh)

Yeah, CONF.sh has become far too big. It might make sense to split stuff up 
into several config files - after all, if e.g. you don't want to generate 
.jigdo files, you don't even need to look at the related options.

> - how do you think we should proceed ? should I start from a completely
>   new repository and import only what I want to keep ? should we work in
>   a branch of the actual repository ?

IMHO the kind soul who tackles this should start from scratch. :-7

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer |  GnuPG key:
  | \/¯|  http://atterer.net  |  0x888354F7
  ¯ '` ¯

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

dead links

2004-01-07 Thread Mirko Kohns

Hi Everyone! We have a 350 maschine cluster running debian woody. We want to 
upgrade to testing .. but not with apt-get dist-upgrade. We want a new fresh 
installation. But All links to the gluck.debian.org server seem to be broken?
Can you help?

http://gluck.debian.org/cdimage/testing/netinst/

Greetings, MIRKO

Broken link on net CD page

2004-01-07 Thread James Tappin

On the network install page (http://www.debian.org/CD/netinst/) the link
to "Lord Sutch's" minicd is out of date. It appears that the correct URL
is:
ftp://mirrors.xmission.com/debian-minicd

Best regards,
James Tappin

-- 
++---+-+
| James Tappin   | School of Physics & Astronomy |  O__|
| [EMAIL PROTECTED] | University of Birmingham  | --  \/` |
| Ph: 0121-414-6462. Fax: 0121-414-3722  | |
++-+

dead links

2004-01-07 Thread Mirko Kohns

Hi Everyone! We have a 350 maschine cluster running debian woody. We want to 
upgrade to testing .. but not with apt-get dist-upgrade. We want a new fresh 
installation. But All links to the gluck.debian.org server seem to be broken?
Can you help?

http://gluck.debian.org/cdimage/testing/netinst/

Greetings, MIRKO


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

Broken link on net CD page

2004-01-07 Thread James Tappin

On the network install page (http://www.debian.org/CD/netinst/) the link
to "Lord Sutch's" minicd is out of date. It appears that the correct URL
is:
ftp://mirrors.xmission.com/debian-minicd

Best regards,
James Tappin

-- 
++---+-+
| James Tappin   | School of Physics & Astronomy |  O__|
| [EMAIL PROTECTED] | University of Birmingham  | --  \/` |
| Ph: 0121-414-6462. Fax: 0121-414-3722  | |
++-+


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

Re: Future of debian-cd

2004-01-07 Thread bernd

> Now, I'd like to hear from you :
> - what are your (constructive) critics against debian-cd ?

Since debian-cd is no longer available to the public, it is very difficult
to test currently. Maybe someone could provide a current .deb package for
testing or unstable, so people can actually try out the most recent version.

> - what design ideas do you have for a possible rewrite ?
> - what do you think of what i've written above ?

DVD worked fine for 3.0r1/i386 (large ISO9660), I don't know about other 
architectures and I could not check this for 3.0r2 yet.
Are the "maintainers" of the "testing" and "unstable" CDs/DVD images
still using debian-cd or something else ?

> - how do you think we should proceed ? should I start from a completely
>   new repository and import only what I want to keep ? should we work in
>   a branch of the actual repository ?

For me, it was a bit difficult to follow all the source code and understand
about including and excluding packages. Maybe a central documentation file
for people who want to help modify or extend debian-cd would be great.
While bash is not the best programming language, I can't think of a more
suitable one; maybe Perl.

Regards
Bernd Hentig

Future of debian-cd

2004-01-07 Thread Raphael Hertzog

Hello everyone,

many of you already noticed that debian-cd is a bit complicated.
And it tends to get worse since we keep doing small modifications
everywhere without a global logic.

Thus I think that debian-cd needs to be partially rewritten.

Here are the main critics that I have :
- complicated shell code in Makefile is ugly, it was supposed to
  not need to be modified, and in fact many parts of the Makefile
  were modified for various purposes
- you can't reasonnably build potato cd with current debian-cd because
  of those "infrastructural change" to a CD (inclusion of udeb for
  example) which were not expected at the time of my initial rewrite
  of debian-cd. I still managed to keep most of the compatibility
  but at the cost of more code complexity.
- we have too many imbricated options which do not make sense to many
  of us, it's time to see if we shouldn't get rid of some of them
  (or at least hide them somewhere deeper than CONF.sh)
- the official support of businesscard cd/netinst cd/dvd is not good, most
  people are not able to build such CD with debian-cd because they don't
  know how the magic combination of parameters.
- it's too much of black magick to know the good size parameters to give

In a new design, I would like to have :
- a MEDIA_TYPE input variable that would tell me :
  1 - businesscard CD
  2 - netinst CD
  3 - usual CD
  4 - DVD
  The size would be taken from a default value (if not overriden).
- a system of profile that would describe how to build a particular kind
  of ISO
- a system of profile for debian-installer, so that we can easily
  customize the udebs used by the debian installer

The new design should still reuse most of the existing code, not
everything needs to be thrown. In fact I think that most should be kept
but cleaned from the cruft and reorganized in a different way.

Now, I'd like to hear from you :
- what are your (constructive) critics against debian-cd ?
- what design ideas do you have for a possible rewrite ?
- what do you think of what i've written above ?
- how do you think we should proceed ? should I start from a completely
  new repository and import only what I want to keep ? should we work in
  a branch of the actual repository ?

BTW, as you may have noticed I have less & less time for debian-cd, and
I'd like to have some help in the long term to help me maintain it. With
a (partial) rewrite, it would be the perfect time for someone to step up
and get familiar with the code ...

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com
Earn money with free software: http://www.geniustrader.org

Re: Future of debian-cd

2004-01-07 Thread bernd

> Now, I'd like to hear from you :
> - what are your (constructive) critics against debian-cd ?

Since debian-cd is no longer available to the public, it is very difficult
to test currently. Maybe someone could provide a current .deb package for
testing or unstable, so people can actually try out the most recent version.

> - what design ideas do you have for a possible rewrite ?
> - what do you think of what i've written above ?

DVD worked fine for 3.0r1/i386 (large ISO9660), I don't know about other 
architectures and I could not check this for 3.0r2 yet.
Are the "maintainers" of the "testing" and "unstable" CDs/DVD images
still using debian-cd or something else ?

> - how do you think we should proceed ? should I start from a completely
>   new repository and import only what I want to keep ? should we work in
>   a branch of the actual repository ?

For me, it was a bit difficult to follow all the source code and understand
about including and excluding packages. Maybe a central documentation file
for people who want to help modify or extend debian-cd would be great.
While bash is not the best programming language, I can't think of a more
suitable one; maybe Perl.

Regards
Bernd Hentig


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

Future of debian-cd

2004-01-07 Thread Raphael Hertzog

Hello everyone,

many of you already noticed that debian-cd is a bit complicated.
And it tends to get worse since we keep doing small modifications
everywhere without a global logic.

Thus I think that debian-cd needs to be partially rewritten.

Here are the main critics that I have :
- complicated shell code in Makefile is ugly, it was supposed to
  not need to be modified, and in fact many parts of the Makefile
  were modified for various purposes
- you can't reasonnably build potato cd with current debian-cd because
  of those "infrastructural change" to a CD (inclusion of udeb for
  example) which were not expected at the time of my initial rewrite
  of debian-cd. I still managed to keep most of the compatibility
  but at the cost of more code complexity.
- we have too many imbricated options which do not make sense to many
  of us, it's time to see if we shouldn't get rid of some of them
  (or at least hide them somewhere deeper than CONF.sh)
- the official support of businesscard cd/netinst cd/dvd is not good, most
  people are not able to build such CD with debian-cd because they don't
  know how the magic combination of parameters.
- it's too much of black magick to know the good size parameters to give

In a new design, I would like to have :
- a MEDIA_TYPE input variable that would tell me :
  1 - businesscard CD
  2 - netinst CD
  3 - usual CD
  4 - DVD
  The size would be taken from a default value (if not overriden).
- a system of profile that would describe how to build a particular kind
  of ISO
- a system of profile for debian-installer, so that we can easily
  customize the udebs used by the debian installer

The new design should still reuse most of the existing code, not
everything needs to be thrown. In fact I think that most should be kept
but cleaned from the cruft and reorganized in a different way.

Now, I'd like to hear from you :
- what are your (constructive) critics against debian-cd ?
- what design ideas do you have for a possible rewrite ?
- what do you think of what i've written above ?
- how do you think we should proceed ? should I start from a completely
  new repository and import only what I want to keep ? should we work in
  a branch of the actual repository ?

BTW, as you may have noticed I have less & less time for debian-cd, and
I'd like to have some help in the long term to help me maintain it. With
a (partial) rewrite, it would be the perfect time for someone to step up
and get familiar with the code ...

Cheers,
-- 
Raphaël Hertzog -+- http://www.ouaza.com
Formation Linux et logiciel libre : http://www.logidee.com
Earn money with free software: http://www.geniustrader.org


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

Re: r1-NON-US in r2 dir?

2004-01-07 Thread Bart Schouten

It's long finished :) Figuring out how to do it faster would have taken me
more time ;).

-- 
I dedicate my life to life

On Wed, 7 Jan 2004, Mark Syms wrote:

> Don't forget that you can use the existing ISO as a source of packages
> by mounting it as a loopback filesystem. This may save you some download
> time.
> 
> On Tue, 2004-01-06 at 23:25, Bart Schouten wrote:
> > Thank you.
> > 
> > The output was:
> > 
> > [Jigdo]
> > Version=1.1
> > Generator=jigdo-file/0.6.8
> > 
> > [Image]
> > Filename=debian-30r1-i386-binary-1_NONUS.iso
> > Template=http://us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/i386/woody-i386-1_NONUS.template
> > Template-MD5Sum=--2ZBbMUi2Uw5NYh-hqeOw
> > ShortInfo='Debian GNU/Linux 3.0 r1 "Woody" - Official i386 Binary-1_NONUS 
> > CD'
> > Info='Generated on Thu, 19 Dec 2002 00:33:19 +'
> > 
> > 
> > So it was an r1 jigdo file. That explains.
> > Also, in reply to Steve McIntyre, the md5sum is that of the r1 iso.
> > 
> > I will try to download it again.
> > 
> > Greetz, 
> > 
> > bart
> > -- 
> > I dedicate my life to life
> > 
> > On Tue, 6 Jan 2004, George Danchev wrote:
> > 
> > > On Tuesday 06 January 2004 20:14, [EMAIL PROTECTED] wrote:
> > > > Hi,
> > > >
> > > > I just used jigdo to download
> > > > http://non-us.cdimage.debian.org/jigdo-area/3.0_r2/jigdo/i386/woody-i386-1_
> > > >NONUS.jigdo which is as you can see in the 3.0_r2 directory, but the
> > > > resulting file was  debian-30r1-i386-binary-1_NONUS.iso
> > > >
> > > > What have I downloaded, exactly? (Or how can I find out?).
> > > 
> > > # zless woody-i386-1_NONUS.jigdo
> > > 
> > > and take a look at section [Image]
> > > Filename= ..
> > > 
> > > I downloaded this 
> > > http://non-us.cdimage.debian.org/jigdo-area/3.0_r2/jigdo/
> > > i386/woody-i386-1_NONUS.jigdo  and the filename is:
> > > 
> > > Filename=debian-30r2-i386-binary-1_NONUS.iso
> > > 
> > > btw, the Template= should be done as Relative, not as an Absolute Path... 
> > > but 
> > > this is not related to your issue.
> > > 
> > > 
> > 
> > 
> > 
> > 
>

Re: r1-NON-US in r2 dir?

2004-01-07 Thread Bart Schouten

It's long finished :) Figuring out how to do it faster would have taken me
more time ;).

-- 
I dedicate my life to life

On Wed, 7 Jan 2004, Mark Syms wrote:

> Don't forget that you can use the existing ISO as a source of packages
> by mounting it as a loopback filesystem. This may save you some download
> time.
> 
> On Tue, 2004-01-06 at 23:25, Bart Schouten wrote:
> > Thank you.
> > 
> > The output was:
> > 
> > [Jigdo]
> > Version=1.1
> > Generator=jigdo-file/0.6.8
> > 
> > [Image]
> > Filename=debian-30r1-i386-binary-1_NONUS.iso
> > Template=http://us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/i386/woody-i386-1_NONUS.template
> > Template-MD5Sum=--2ZBbMUi2Uw5NYh-hqeOw
> > ShortInfo='Debian GNU/Linux 3.0 r1 "Woody" - Official i386 Binary-1_NONUS 
> > CD'
> > Info='Generated on Thu, 19 Dec 2002 00:33:19 +'
> > 
> > 
> > So it was an r1 jigdo file. That explains.
> > Also, in reply to Steve McIntyre, the md5sum is that of the r1 iso.
> > 
> > I will try to download it again.
> > 
> > Greetz, 
> > 
> > bart
> > -- 
> > I dedicate my life to life
> > 
> > On Tue, 6 Jan 2004, George Danchev wrote:
> > 
> > > On Tuesday 06 January 2004 20:14, [EMAIL PROTECTED] wrote:
> > > > Hi,
> > > >
> > > > I just used jigdo to download
> > > > http://non-us.cdimage.debian.org/jigdo-area/3.0_r2/jigdo/i386/woody-i386-1_
> > > >NONUS.jigdo which is as you can see in the 3.0_r2 directory, but the
> > > > resulting file was  debian-30r1-i386-binary-1_NONUS.iso
> > > >
> > > > What have I downloaded, exactly? (Or how can I find out?).
> > > 
> > > # zless woody-i386-1_NONUS.jigdo
> > > 
> > > and take a look at section [Image]
> > > Filename= ..
> > > 
> > > I downloaded this http://non-us.cdimage.debian.org/jigdo-area/3.0_r2/jigdo/
> > > i386/woody-i386-1_NONUS.jigdo  and the filename is:
> > > 
> > > Filename=debian-30r2-i386-binary-1_NONUS.iso
> > > 
> > > btw, the Template= should be done as Relative, not as an Absolute Path... but 
> > > this is not related to your issue.
> > > 
> > > 
> > 
> > 
> > 
> > 
> 


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

Re: r1-NON-US in r2 dir?

2004-01-07 Thread Mark Syms

Don't forget that you can use the existing ISO as a source of packages
by mounting it as a loopback filesystem. This may save you some download
time.

On Tue, 2004-01-06 at 23:25, Bart Schouten wrote:
> Thank you.
> 
> The output was:
> 
> [Jigdo]
> Version=1.1
> Generator=jigdo-file/0.6.8
> 
> [Image]
> Filename=debian-30r1-i386-binary-1_NONUS.iso
> Template=http://us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/i386/woody-i386-1_NONUS.template
> Template-MD5Sum=--2ZBbMUi2Uw5NYh-hqeOw
> ShortInfo='Debian GNU/Linux 3.0 r1 "Woody" - Official i386 Binary-1_NONUS 
> CD'
> Info='Generated on Thu, 19 Dec 2002 00:33:19 +'
> 
> 
> So it was an r1 jigdo file. That explains.
> Also, in reply to Steve McIntyre, the md5sum is that of the r1 iso.
> 
> I will try to download it again.
> 
> Greetz, 
> 
> bart
> -- 
> I dedicate my life to life
> 
> On Tue, 6 Jan 2004, George Danchev wrote:
> 
> > On Tuesday 06 January 2004 20:14, [EMAIL PROTECTED] wrote:
> > > Hi,
> > >
> > > I just used jigdo to download
> > > http://non-us.cdimage.debian.org/jigdo-area/3.0_r2/jigdo/i386/woody-i386-1_
> > >NONUS.jigdo which is as you can see in the 3.0_r2 directory, but the
> > > resulting file was  debian-30r1-i386-binary-1_NONUS.iso
> > >
> > > What have I downloaded, exactly? (Or how can I find out?).
> > 
> > # zless woody-i386-1_NONUS.jigdo
> > 
> > and take a look at section [Image]
> > Filename= ..
> > 
> > I downloaded this http://non-us.cdimage.debian.org/jigdo-area/3.0_r2/jigdo/
> > i386/woody-i386-1_NONUS.jigdo  and the filename is:
> > 
> > Filename=debian-30r2-i386-binary-1_NONUS.iso
> > 
> > btw, the Template= should be done as Relative, not as an Absolute Path... 
> > but 
> > this is not related to your issue.
> > 
> > 
> 
> 
> 
>

Re: r1-NON-US in r2 dir?

2004-01-07 Thread Mark Syms

Don't forget that you can use the existing ISO as a source of packages
by mounting it as a loopback filesystem. This may save you some download
time.

On Tue, 2004-01-06 at 23:25, Bart Schouten wrote:
> Thank you.
> 
> The output was:
> 
> [Jigdo]
> Version=1.1
> Generator=jigdo-file/0.6.8
> 
> [Image]
> Filename=debian-30r1-i386-binary-1_NONUS.iso
> Template=http://us.cdimage.debian.org/jigdo-area/3.0_r1/jigdo/i386/woody-i386-1_NONUS.template
> Template-MD5Sum=--2ZBbMUi2Uw5NYh-hqeOw
> ShortInfo='Debian GNU/Linux 3.0 r1 "Woody" - Official i386 Binary-1_NONUS 
> CD'
> Info='Generated on Thu, 19 Dec 2002 00:33:19 +'
> 
> 
> So it was an r1 jigdo file. That explains.
> Also, in reply to Steve McIntyre, the md5sum is that of the r1 iso.
> 
> I will try to download it again.
> 
> Greetz, 
> 
> bart
> -- 
> I dedicate my life to life
> 
> On Tue, 6 Jan 2004, George Danchev wrote:
> 
> > On Tuesday 06 January 2004 20:14, [EMAIL PROTECTED] wrote:
> > > Hi,
> > >
> > > I just used jigdo to download
> > > http://non-us.cdimage.debian.org/jigdo-area/3.0_r2/jigdo/i386/woody-i386-1_
> > >NONUS.jigdo which is as you can see in the 3.0_r2 directory, but the
> > > resulting file was  debian-30r1-i386-binary-1_NONUS.iso
> > >
> > > What have I downloaded, exactly? (Or how can I find out?).
> > 
> > # zless woody-i386-1_NONUS.jigdo
> > 
> > and take a look at section [Image]
> > Filename= ..
> > 
> > I downloaded this http://non-us.cdimage.debian.org/jigdo-area/3.0_r2/jigdo/
> > i386/woody-i386-1_NONUS.jigdo  and the filename is:
> > 
> > Filename=debian-30r2-i386-binary-1_NONUS.iso
> > 
> > btw, the Template= should be done as Relative, not as an Absolute Path... but 
> > this is not related to your issue.
> > 
> > 
> 
> 
> 
> 


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

Another way to burn debian CDs under Windows

2004-01-07 Thread William Poetra Yoga Hadisoeseno

Hi, I'm not a member of this list, but I see in the FAQ that other ways of
burning debian CD's uder Windows should be reported. Well, I have been using
Daemon-Tools (NOT DJ Bernstein's Unix daemontools, it's the Windows one which
gives us virtual CD/DVD-ROM drives, get it from http://www.daemon-tools.cc/)
and CloneCD (note that CloneCD has been discontinued by Elaborate Bytes AG, get
it from http://www.clonecd.net/ instead).

First, mount the image you want to burn to a virtual drive.
Then, fire up CloneCD.
Click "Copy CD".
Choose the drive on which the image is mounted as the source, and the CD/DVD-RW
drive which contains the blank CD.
Follow the instructions, and you get a working Debian CD.

P.S. I haven't tried the DVD method actually, but I have tried to burn CDs of
other GNU/Linux distros without failure.


__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

37 matches

Mail list logo