Bits from the debian-cd team; more CD/DVDs being built regularly
Steve McIntyre
a quick summary is in order:
Daily builds
============
* "etch" businesscard for each arch *except* s390 (small image, no
packages - just contains d-i)
* "etch" netinst for each arch *except* s390 (slightly larger image,
d-i and the base system only)
* "sid" businesscard (as above)
* "sid" netinst (as above)
The "etch" and "sid" versions determine the version of d-i used in
each case. "etch" uses the last known-good d-i image from the archive
(aka etch RC1 at the moment). "sid" uses the latest build from the
porters for each architecture. Both sets are built often, triggered by
the mirror pulse (currently twice daily). Total build time for all of
these is approximately 45 minutes for 44 CDs.
Weekly builds
=============
* full CD sets for each arch and source
* full DVD sets for each arch and source
* (NEW) a KDE version of CD#1 for each arch
* (NEW) an XFCE version of CD#1 for each arch
* (NEW) a 3-arch netinst (amd64/i386/powerpc)
* (NEW) a 3-arch + source DVD#1 (amd64/i386/powerpc/source)
These builds are normally triggered by the first mirror pulse on a
Monday, UTC timezone. This build takes much longer, due to the sheer
size of the data sets involved, (approximately 15 hours for 293 CDs
and 41 DVDs in the last build). There is now quite some overlap
between these discs, too, which leads me on to:
Gnome vs. KDE vs. XFCE
======================
The KDE and XFCE variants of CD#1 are now being produced to give more
choice to people for initial installation. By default, CD#1 has always
meant to be enough to install a fully-functioning system, including a
desktop. On sarge, we (just about) managed to make all that fit,
including a choice of KDE or Gnome. However, since the sarge release
the size of the set of packages needed to cover each desktop *and* the
rest of the base system has grown substantially. We're now at the
point where that's just not possible any more. The default CD#1 will
now install a Gnome desktop, and there are replacement CDs that will
install KDE or XFCE instead. Download your own choice. Thanks to Joey
Hess for the work to make these happen.
Multi-arch
==========
Quick warning to avoid possible confusion: this is nothing to do with
the multi-arch binary support that people are working on. The new
multi-arch discs are designed to be convenient for people who
need/want to be able to install Debian onto multiple different types
of machine from a single disc.
To that end, there is now a combined amd64/i386/powerpc netinst that
is basically an amalgamation of the contents of the individual
netinsts for those arches. This is based on the "etch" d-i version as
described above.
There is also a combined amd64/i386/powerpc/source DVD which should
contain most of what people will commonly want to install on each of
those 3 arches, roughly equivalent to the contents of the first 3-4
CDs or so each. Binary-all package overlaps mean that there is space
on this disc for more packages than might be expected. Plus, sources
for all the binaries on the DVD will be included too. This DVD is
therefore probably the ideal choice of disc to sell or give away at
Expos.
In case it's not obvious, the 3 arches picked for these discs are
simply the most common end-user systems out there. There is scope for
producing more multi-arch discs, but the possible combinations are
*massive* :-).
To do
=====
I'm still expecting to add Live CDs to the list here before we
release. Otherwise, I think we're about set. If there's anything else
you'd like us to do or anything you'd like to ask about, please reply
to this mail - note the Reply-To to the debian-cd list.
Otherwise, please help us TEST these, especially the variants marked
as NEW above. Downloads are available in multiple formats (iso image,
jigdo, bittorrent) - look at
http://cdimage.debian.org/cdimage/daily-builds/
http://cdimage.debian.org/cdimage/weekly-builds/
for all your testing CD/DVD needs.
Cheers,
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"It's actually quite entertaining to watch ag129 prop his foot up on
the desk so he can get a better aim." [ seen in ucam.chat ]
Gustavo Franco
> (...)
>
> Gnome vs. KDE vs. XFCE
> ======================
>
> The KDE and XFCE variants of CD#1 are now being produced to give more
> choice to people for initial installation. By default, CD#1 has always
> meant to be enough to install a fully-functioning system, including a
> desktop. On sarge, we (just about) managed to make all that fit,
> including a choice of KDE or Gnome. However, since the sarge release
> the size of the set of packages needed to cover each desktop *and* the
> rest of the base system has grown substantially. We're now at the
> point where that's just not possible any more. The default CD#1 will
> now install a Gnome desktop, and there are replacement CDs that will
> install KDE or XFCE instead. Download your own choice. Thanks to Joey
> Hess for the work to make these happen.
Let me thanks the debian-desktop, debian-installer and tasksel team
too. Without them, that stuff would be useless.
I would like to clarify that debian-desktop (alioth, svn, mailing
list) is now a unit composed by pkg-gnome, pkg-kde and pkg-xfce and
tasksel members. Joey Hess (d-i and debian-cd) give us all the support
to make stuff happen.
Unfortunately, even the GNOME desktop environment doesn't fit on the
CD#1. You will need broadband connection to fetch some more packages
or use the full DVD#1 for your architecture. The bonus is that KDE
will be there too (full DVD #1). I'm not sure about the latest
statistics on KDE and XFCE alternative desktop CD#1. Joey, could you
give us that information? Btw, i would like to suggest add it
somewhere in the release notes "where's what" in terms of medias. I
can submit patches, after you feed me with info.
> Multi-arch
> ==========
>
> Quick warning to avoid possible confusion: this is nothing to do with
> the multi-arch binary support that people are working on. The new
> multi-arch discs are designed to be convenient for people who
> need/want to be able to install Debian onto multiple different types
> of machine from a single disc.
>
> To that end, there is now a combined amd64/i386/powerpc netinst that
> is basically an amalgamation of the contents of the individual
> netinsts for those arches. This is based on the "etch" d-i version as
> described above.
>
> There is also a combined amd64/i386/powerpc/source DVD which should
> contain most of what people will commonly want to install on each of
> those 3 arches, roughly equivalent to the contents of the first 3-4
> CDs or so each. Binary-all package overlaps mean that there is space
> on this disc for more packages than might be expected. Plus, sources
> for all the binaries on the DVD will be included too. This DVD is
> therefore probably the ideal choice of disc to sell or give away at
> Expos.
Does it contains desktop, kde-desktop, gnome-desktop and xfce-desktop?
I guess not, but who knows. ;)
> In case it's not obvious, the 3 arches picked for these discs are
> simply the most common end-user systems out there. There is scope for
> producing more multi-arch discs, but the possible combinations are
> *massive* :-).
I would like to suggest 'split' the 9 archs left in 3, something like:
- arm, mips, mipsel
- hppa, ia64, s390
- sparc, m68k, alpha
Is it possible? Do you think it will fit ? If yes, i can prepare
patches for debian-cd once i figure out all that pile of changes.
> To do
> =====
>
> I'm still expecting to add Live CDs to the list here before we
> release. Otherwise, I think we're about set. If there's anything else
> you'd like us to do or anything you'd like to ask about, please reply
> to this mail - note the Reply-To to the debian-cd list.
Do you plan to use the live-package to build the live cds or some new
code into debian-cd ? If you're going to pick live-package i submitted
a patch to Daniel that would permit use a tasksel based approach to
select packages, and not the fixed list as they actually do. I have no
feedback about that until now. It seems they were going to do a major
change in the code.
> (...)
regards,
-- stratus
--
To UNSUBSCRIBE, email to debian-c...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Adam Majer
> * (NEW) a 3-arch + source DVD#1 (amd64/i386/powerpc/source)
Wow! Thanks you very much. This is really some Damn Good Job (TM)!
I'm looking forward to the Live CD. Is it possible to have a Live DVD as
well?
Keep up the good work!
Thank you,
Adam
Frans Pop
> I would like to suggest 'split' the 9 archs left in 3, something like:
> - arm, mips, mipsel
> - hppa, ia64, s390
> - sparc, m68k, alpha
>
> Is it possible? Do you think it will fit ? If yes, i can prepare
> patches for debian-cd once i figure out all that pile of changes.
Please consider that every variant will need to be tested before any
release. As long as there are no volunteers who will commit to that, I
would be very reluctant to add extra variants, especially if they would
probably only be used by a very limited number of people.
Joey Hess
> Unfortunately, even the GNOME desktop environment doesn't fit on the
> CD#1.
True, but enough does fit to have a basically useable gnome desktop.
> You will need broadband connection to fetch some more packages
> or use the full DVD#1 for your architecture. The bonus is that KDE
> will be there too (full DVD #1). I'm not sure about the latest
> statistics on KDE and XFCE alternative desktop CD#1. Joey, could you
> give us that information?
All of kde doesn't fit on the kde CD, the key packages for the task do.
I expect that all of xfce will fit on its CD, but as its CD is currently
apparently broken and doesn't include much of anything, I'm not yet
sure.
> >those 3 arches, roughly equivalent to the contents of the first 3-4
> >CDs or so each. Binary-all package overlaps mean that there is space
> >on this disc for more packages than might be expected. Plus, sources
> >for all the binaries on the DVD will be included too. This DVD is
> >therefore probably the ideal choice of disc to sell or give away at
> >Expos.
>
> Does it contains desktop, kde-desktop, gnome-desktop and xfce-desktop?
> I guess not, but who knows. ;)
I don't know yet, it might since IIRC kde starts around CD 3 or 4 of the
regular CD set.
> I would like to suggest 'split' the 9 archs left in 3, something like:
> - arm, mips, mipsel
Not enough machines for these arches with CD drives to be useful, I think.
> - hppa, ia64, s390
AFAIK the use cases for s390 CDs are very limited and don't include
booting, so it's not needed.
--
see shy jo
Steve McIntyre
>
>Let me thanks the debian-desktop, debian-installer and tasksel team
>too. Without them, that stuff would be useless.
Yup, of course. :-)
>I would like to clarify that debian-desktop (alioth, svn, mailing
>list) is now a unit composed by pkg-gnome, pkg-kde and pkg-xfce and
>tasksel members. Joey Hess (d-i and debian-cd) give us all the support
>to make stuff happen.
>
>Unfortunately, even the GNOME desktop environment doesn't fit on the
>CD#1. You will need broadband connection to fetch some more packages
>or use the full DVD#1 for your architecture. The bonus is that KDE
>will be there too (full DVD #1). I'm not sure about the latest
>statistics on KDE and XFCE alternative desktop CD#1. Joey, could you
>give us that information? Btw, i would like to suggest add it
>somewhere in the release notes "where's what" in terms of medias. I
>can submit patches, after you feed me with info.
As Joey suggests, the key task packages from Gnome and KDE should each
fit on their respective versions of CD#1.
>>There is also a combined amd64/i386/powerpc/source DVD which should
>>contain most of what people will commonly want to install on each of
>>those 3 arches, roughly equivalent to the contents of the first 3-4
>>CDs or so each. Binary-all package overlaps mean that there is space
>>on this disc for more packages than might be expected. Plus, sources
>>for all the binaries on the DVD will be included too. This DVD is
>>therefore probably the ideal choice of disc to sell or give away at
>>Expos.
>
>Does it contains desktop, kde-desktop, gnome-desktop and xfce-desktop?
>I guess not, but who knows. ;)
I would hope so, yes. It'll also depend on popcon ordering as to
exactly what gets there.
>>In case it's not obvious, the 3 arches picked for these discs are
>>simply the most common end-user systems out there. There is scope for
>>producing more multi-arch discs, but the possible combinations are
>>*massive* :-).
>
>I would like to suggest 'split' the 9 archs left in 3, something like:
>- arm, mips, mipsel
>- hppa, ia64, s390
>- sparc, m68k, alpha
>
>Is it possible? Do you think it will fit ? If yes, i can prepare
>patches for debian-cd once i figure out all that pile of changes.
There is a problem that I didn't mention here specifically yet: many
of the arches clash in terms of how to make a CD bootable. Many expect
to find their own special metadata in sector 0 of the CD, and most of
them are completely incompatible. :-( We're actually quite lucky that
the common 3 arches are compatible.
The other thing is that the number of CD/DVD-bootable machines in the
other arches is really quite small, probably small enough not to be
worth bothering with the extra effort here for the multi-arch discs.
>>To do
>>=====
>>
>>I'm still expecting to add Live CDs to the list here before we
>>release. Otherwise, I think we're about set. If there's anything else
>>you'd like us to do or anything you'd like to ask about, please reply
>>to this mail - note the Reply-To to the debian-cd list.
>
>Do you plan to use the live-package to build the live cds or some new
>code into debian-cd ? If you're going to pick live-package i submitted
>a patch to Daniel that would permit use a tasksel based approach to
>select packages, and not the fixed list as they actually do. I have no
>feedback about that until now. It seems they were going to do a major
>change in the code.
Yep, I'm expecting to use live-package. I need to get playing with
that soon...
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"C++ ate my sanity" -- Jon Rabone
Gustavo Franco
> Gustavo Franco wrote:
> > Unfortunately, even the GNOME desktop environment doesn't fit on the
> > CD#1.
>
> True, but enough does fit to have a basically useable gnome desktop.
Right, but we need to make it clear for the users and the first line
of them are subscribed to -devel. ;)
> > You will need broadband connection to fetch some more packages
> > or use the full DVD#1 for your architecture. The bonus is that KDE
> > will be there too (full DVD #1). I'm not sure about the latest
> > statistics on KDE and XFCE alternative desktop CD#1. Joey, could you
> > give us that information?
>
> All of kde doesn't fit on the kde CD, the key packages for the task do.
> I expect that all of xfce will fit on its CD, but as its CD is currently
> apparently broken and doesn't include much of anything, I'm not yet
> sure.
Do you know what's broken in Xfce cd? Is it tasksel related? I hope not.
> > >those 3 arches, roughly equivalent to the contents of the first 3-4
> > >CDs or so each. Binary-all package overlaps mean that there is space
> > >on this disc for more packages than might be expected. Plus, sources
> > >for all the binaries on the DVD will be included too. This DVD is
> > >therefore probably the ideal choice of disc to sell or give away at
> > >Expos.
> >
> > Does it contains desktop, kde-desktop, gnome-desktop and xfce-desktop?
> > I guess not, but who knows. ;)
>
> I don't know yet, it might since IIRC kde starts around CD 3 or 4 of the
> regular CD set.
Sounds great, could you give me a link with the log or check it in the
next build please?
> > I would like to suggest 'split' the 9 archs left in 3, something like:
> > - arm, mips, mipsel
>
> Not enough machines for these arches with CD drives to be useful, I think.
You've a point.
> > - hppa, ia64, s390
>
> AFAIK the use cases for s390 CDs are very limited and don't include
> booting, so it's not needed.
I'm sure they're, so can't we go for a new multiarch containing hppa
and ia64 only or even i386, hppa and ia64 ?
Steve McIntyre
>> * (NEW) a 3-arch netinst (amd64/i386/powerpc)
>> * (NEW) a 3-arch + source DVD#1 (amd64/i386/powerpc/source)
>
>Wow! Thanks you very much. This is really some Damn Good Job (TM)!
>
>I'm looking forward to the Live CD. Is it possible to have a Live DVD as
>well?
I should imagine so, yes. More news as I get working on it... :-)
--
Steve McIntyre, Cambridge, UK. st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Gustavo Franco
> >>In case it's not obvious, the 3 arches picked for these discs are
> >>simply the most common end-user systems out there. There is scope for
> >>producing more multi-arch discs, but the possible combinations are
> >>*massive* :-).
> >
> >I would like to suggest 'split' the 9 archs left in 3, something like:
> >- arm, mips, mipsel
> >- hppa, ia64, s390
> >- sparc, m68k, alpha
> >
> >Is it possible? Do you think it will fit ? If yes, i can prepare
> >patches for debian-cd once i figure out all that pile of changes.
>
> There is a problem that I didn't mention here specifically yet: many
> of the arches clash in terms of how to make a CD bootable. Many expect
> to find their own special metadata in sector 0 of the CD, and most of
> them are completely incompatible. :-( We're actually quite lucky that
> the common 3 arches are compatible.
I thought about that but since you've not cited the technical limitation
i asked anyway. ;)
> The other thing is that the number of CD/DVD-bootable machines in the
> other arches is really quite small, probably small enough not to be
> worth bothering with the extra effort here for the multi-arch discs.
No problem.
> >> (...)
> >>I'm still expecting to add Live CDs to the list here before we
> >>release. Otherwise, I think we're about set. If there's anything else
> >>you'd like us to do or anything you'd like to ask about, please reply
> >>to this mail - note the Reply-To to the debian-cd list.
> >
> >Do you plan to use the live-package to build the live cds or some new
> >code into debian-cd ? If you're going to pick live-package i submitted
> >a patch to Daniel that would permit use a tasksel based approach to
> >select packages, and not the fixed list as they actually do. I have no
> >feedback about that until now. It seems they were going to do a major
> >change in the code.
>
> Yep, I'm expecting to use live-package. I need to get playing with
> that soon...
Sounds good. Please, let us be sure that the during a GNOME, KDE or
XFCE 'live session' the user will have the same or similar as possible
set of packages as installed by d-i (tasksel), as i told you, over the
current codebase there's a patch i submitted that is a step on this
direction. We just need to tweak it a bit and build at least a set
with 3 live desktop cd's (one for each desktop environment and i386),
IMHO. Thoughts?
The possibility of give to the users during a event the DVD#1
containing the 3 desktop environments and 1 live-cd containing the one
he prefers to use (if any) to play with the stuff and test the
hardware compatibility before install is exciting.
regards,
-- stratus
Joey Hess
> Do you know what's broken in Xfce cd? Is it tasksel related? I hope not.
Missing task file, it should be fixed in the next build.
> Sounds great, could you give me a link with the log or check it in the
> next build please?
I checked the log, the current muti dvd doesn't seem to have any desktop
packages on it, not even gnome-desktop-environment.
> I'm sure they're, so can't we go for a new multiarch containing hppa
> and ia64 only or even i386, hppa and ia64 ?
Hmm, keeping i386 on it is an interesting idea. Or it could have alpha,
hppa, and ia64, for the big/old/weird/64 bit iron multiarch cd. :-)
--
see shy jo
Josselin Mouette
> Gustavo Franco wrote:
> > Unfortunately, even the GNOME desktop environment doesn't fit on the
> > CD#1.
>
> True, but enough does fit to have a basically useable gnome desktop.
Are you talking of gnome-core or gnome-desktop-environment? gnome-core
is indeed really basic, but g-d-e already includes a complete desktop.
Not having "gnome" on a single CD is understandable given how much we've
bloated this metapackage.
--
Josselin Mouette /\./\
"Do you have any more insane proposals for me?"
Joey Hess
> Are you talking of gnome-core or gnome-desktop-environment? gnome-core
> is indeed really basic, but g-d-e already includes a complete desktop.
gnome-desktop-environment is the sole key package in the gnome-desktop
task, and nearly the only one from that task that currently fits on the
first CD (the key packages for the laptop, web-server, and most other
tasks except for kde and xfce also fit on the CD).
> Not having "gnome" on a single CD is understandable given how much we've
> bloated this metapackage.
Actually, we don't even include the gnome metapackage in the full
gnome-desktop task. gnome-office, gdm-themes and gnome-games-extra-data
are dependencies of gnome that are not included in that task (the rest
of its deps are listed).
--
see shy jo
Josselin Mouette
> > Not having "gnome" on a single CD is understandable given how much we've
> > bloated this metapackage.
>
> Actually, we don't even include the gnome metapackage in the full
> gnome-desktop task. gnome-office, gdm-themes and gnome-games-extra-data
> are dependencies of gnome that are not included in that task (the rest
> of its deps are listed).
It's somewhat a shame not to have gnome-office, or at least gimp,
inkscape and gnumeric, which are by many points superior to other
alternatives.
Joey Hess
> It's somewhat a shame not to have gnome-office, or at least gimp,
> inkscape and gnumeric, which are by many points superior to other
> alternatives.
We do have gimp in the desktop task. I'm willing to consider gnumeric
and inkscape. Actually I wouldn't really mind revisiting the dropping of
gnome-office, it was only done for space reasons at the time and because
OOo is included in the desktop task already.
--
see shy jo
Josselin Mouette
If space is not a problem any more, that would be nice. Planner and dia
may not be useful enough to justify inclusion - we should even move them
to Suggests, IMHO - but other applications are nice to have, even with
OOo already installed.
Thanks,
Frans Pop
> We do have gimp in the desktop task. I'm willing to consider gnumeric
> and inkscape. Actually I wouldn't really mind revisiting the dropping
> of gnome-office, it was only done for space reasons at the time and
> because OOo is included in the desktop task already.
/me is not happy with the fact that that would push KDE even further back
on normal CD sets.
/me is also not happy with the seemingly unlimited growth of the Gnome
desktop task which makes testing it in an emulator increasingly painful.
Count me out for testing desktop task installations if this continues.
Cheers,
FJP
Michael Stone
>We now have *lots* of CD and DVD types being built regularly
How 'bout up to date sarge amd64 cds?
Mike Stone
Joey Hess
> I checked the log, the current muti dvd doesn't seem to have any desktop
> packages on it, not even gnome-desktop-environment.
Wrong log as it turns out. The gnome task is there, in full, as are
almost all other tasks, except for a few of the last language tasks. The
kde task didn't make it on, being currently forced in priority lower
than all of these. Probably room for improvement in the ordering here.
--
see shy jo
Steve McIntyre
>On Wed, Dec 20, 2006 at 06:29:04PM +0000, Steve McIntyre wrote:
>>We now have *lots* of CD and DVD types being built regularly
>
>How 'bout up to date sarge amd64 cds?
Last I checked, we're still waiting on the amd64 sarge r4 point
release. I'll happily build new CDs as/when/if that's done, no
problem.
--
Steve McIntyre, Cambridge, UK. st...@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss
Steve Langasek
> > I'm sure they're, so can't we go for a new multiarch containing hppa
> > and ia64 only or even i386, hppa and ia64 ?
> Hmm, keeping i386 on it is an interesting idea. Or it could have alpha,
> hppa, and ia64, for the big/old/weird/64 bit iron multiarch cd. :-)
I was just thinking that alpha/hppa/ia64 would be an interesting "HP-themed"
multiarch CD. Sounds like this would be fun to work on. :) I have no idea
if the CD booting for these archs can coexist naturally, though.
(Does weird iron contain strange quarks in its nuclei?)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vor...@debian.org http://www.debian.org/
George Danchev
> We now have *lots* of CD and DVD types being built regularly, so maybe
> a quick summary is in order:
Thanks for your unprecedented support on that line!
> Weekly builds
> =============
>
> * full CD sets for each arch and source
> * full DVD sets for each arch and source
I'm a regular user of the weekly DVD set, by means of jigdo [1], which brings
the Debian mirror network infrastructure far beyond the internet connectivity
(into the field of machines which shouldn't be internetworked for any
reason). So, all I can say for now is just thanks for the quality, efficiency
and robustness of that service, it "just works".
> * (NEW) a KDE version of CD#1 for each arch
> * (NEW) an XFCE version of CD#1 for each arch
> * (NEW) a 3-arch netinst (amd64/i386/powerpc)
> * (NEW) a 3-arch + source DVD#1 (amd64/i386/powerpc/source)
I'll probably test these soon, and report back in case of any issues being
faced.
[1] This jigdo has Super Cow Powers!
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB
Joey Hess
> I built i386-xfce-CD-1 [0] using jigdo and didn't get very far due to
> missing kernel modules, which meant no support for the NIC.
Yes, it's known to be broken, should be fixed in next week's build.
> Something else I just noticed - the spashscreen right after starting
> "installgui" doesn't look right. (See second attachment.) The GUI after
> that, however, looks fabulous! BTW, it's evident from the screenshots that
> I'm doing this testing under VMware.
That's not a splashscreen, that's a transient mess that comes up
displaying whatever was previously in video memory before it
writes anything to the screen.
Your screenshot of the running installer, BTW, is not a GUI, that's the
text mode installer. Either the GUI installer failed to start and fell
back to this, or you didn't start it with installgui for that
screenshot.
--
see shy jo
Frans Pop
> I built i386-xfce-CD-1 [0] using jigdo and didn't get very far due to
> screenshot is attached. The kernel reported by uname is "2.6.18-3-486
> #1"
That is expected ATM. You'll have to wait for the release of D-I RC2 to be
able to build the KDE or xfce CDs without any tweaking (the 'official"
builds currently take the udebs from unstable for those two types of
images as they need an updated version of a particular udeb).
> Something else I just noticed - the spashscreen right after starting
> "installgui" doesn't look right. (See second attachment.) The GUI
> after that, however, looks fabulous! BTW, it's evident from the
> screenshots that I'm doing this testing under VMware.
That is not the splash screen, but rather a "normal" result of
modeswitching after you have started the actual boot.
Cheers,
FJP
tony mancill
> tony mancill wrote:
>> I built i386-xfce-CD-1 [0] using jigdo and didn't get very far due to
>> missing kernel modules, which meant no support for the NIC.
>
> Yes, it's known to be broken, should be fixed in next week's build.
Cool.
>> Something else I just noticed - the spashscreen right after starting
>> "installgui" doesn't look right. (See second attachment.) The GUI after
>> that, however, looks fabulous! BTW, it's evident from the screenshots that
>> I'm doing this testing under VMware.
>
> That's not a splashscreen, that's a transient mess that comes up
> displaying whatever was previously in video memory before it
> writes anything to the screen.
Ah, thanks for the clarification.
> Your screenshot of the running installer, BTW, is not a GUI, that's the
> text mode installer. Either the GUI installer failed to start and fell
> back to this, or you didn't start it with installgui for that
> screenshot.
Yes, it's the latter. I did some testing with installgui after I ran across
the modules problem using the default text-based installer.
XFCE has quickly supplanted both what I use and recommend to others when I
advocate switching to Linux (and I still prefer Debian to Xubuntu), so thank
you for your work on this. I'm looking forward to testing more next week.
Cheers,
tony
Joey Hess
> That is expected ATM. You'll have to wait for the release of D-I RC2 to be
> able to build the KDE or xfce CDs without any tweaking (the 'official"
> builds currently take the udebs from unstable for those two types of
> images as they need an updated version of a particular udeb).
I think that jigdo shoud still work for downloading them, not 100% sure
though.
> That is not the splash screen, but rather a "normal" result of
> modeswitching after you have started the actual boot.
I wonder if we could write a black screen to video memory first and
avoid this..
--
see shy jo
Frans Pop
> I think that jigdo shoud still work for downloading them, not 100% sure
> though.
Yes, AFAIK it should.
I just overlooked the "using jigdo" and interpreted "built" as "built
using debian-cd".
/me should read better before replying...
Marco Amadori
> I'm looking forward to the Live CD. Is it possible to have a Live DVD as
> well?
"live-package" just builds iso images and netboot tarballs, so yes, it can
produces DVDs.
Daniel Baumann tried a to produce and iso with "all" "aptitude tasks", and we
saw that a plain dvd can handle it; I think we just need to have a proper
package list or taskel list to fit it, the popcon one, maybe weighted by
hardware, or a "multiarch" dvd (This should requires some code in casper to
do it cleanly although for the impatients it can be done right now with the
LIVE_OFFSET param).
Do not ever think of a dual layer live DVD, it will be a more than 25 Gb root
filesystem! (Need to check if squashfs handles it :-) *)
* Obviously it does.
--
ESC:wq
Stephen Frazier
sitting around. I worked great. Thanks for providing it.
> * (NEW) a KDE version of CD#1 for each arch
--
Stephen Frazier
Information Technology Unit
Oklahoma Department of Corrections
3400 Martin Luther King
Oklahoma City, Ok, 73111-4298
Tel.: (405) 425-2549
Fax: (405) 425-2554
Pager: (405) 690-1828
email: stevef%doc.state.ok.us
Steve McIntyre
On Wed, Dec 20, 2006 at 06:15:23PM -0200, Gustavo Franco wrote:
>On 12/20/06, Steve McIntyre <st...@einval.com> wrote:
>>
>>Yep, I'm expecting to use live-package. I need to get playing with
>>that soon...
>
>Sounds good. Please, let us be sure that the during a GNOME, KDE or
>XFCE 'live session' the user will have the same or similar as possible
>set of packages as installed by d-i (tasksel), as i told you, over the
>current codebase there's a patch i submitted that is a step on this
>direction. We just need to tweak it a bit and build at least a set
>with 3 live desktop cd's (one for each desktop environment and i386),
>IMHO. Thoughts?
OK. That sounds fair enough (admittedly, from my viewpoint of zero
live-package experience). What do Daniel and the others think?
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Steve McIntyre
>On Wed, Dec 20, 2006 at 03:43:55PM -0500, Joey Hess wrote:
>> > I'm sure they're, so can't we go for a new multiarch containing hppa
>> > and ia64 only or even i386, hppa and ia64 ?
>
>> Hmm, keeping i386 on it is an interesting idea. Or it could have alpha,
>> hppa, and ia64, for the big/old/weird/64 bit iron multiarch cd. :-)
>
>I was just thinking that alpha/hppa/ia64 would be an interesting "HP-themed"
>multiarch CD. Sounds like this would be fun to work on. :) I have no idea
>if the CD booting for these archs can coexist naturally, though.
Bad news I'm afraid. I've worked through the mkisofs boot code again,
and I get:
alpha: Writing alpha boot descriptor at extent 0
arm: No boot sector
amd64: Writing el torito VD sector at extent 17
hppa: Writing hppa boot descriptor at extent 0
i386: Writing el torito VD sector at extent 17
ia64: Writing el torito VD sector at extent 17
m68k: Writing hfs descriptor at extent 0
mips: Writing mips boot descriptor at extent 0
mipsel: Writing mipsel boot descriptor at extent 0
powerpc: Writing hfs descriptor at extent 0
s390: No boot sector
sparc: Writing sun boot descriptor at extent 0
Writing genboot sector at extent 1
I'm looking further to see if it's at all possible to get (e.g.) hppa
and alpha to live in the same boot sector, but it's really not likely.
>(Does weird iron contain strange quarks in its nuclei?)
*grin*
--
Steve McIntyre, Cambridge, UK. st...@einval.com
Who needs computer imagery when you've got Brian Blessed?
Javier Fernández-Sanguino Peña
Package: debian-cd
Version: N/A; reported 2006-12-22
Priority: wishlist
I would really like to have debian-cd generate a 'documentation media' (DVD
or CD) which could be used to read documentation without having to install
the system. That documentation media would contain *both* the english and
available translations of, at least:
- The Release Notes
- The Installation Guide
- The Refence Guide
- The User Guide
- The Project History
- The FAQ
- The Securing Debian Manual
- The Reference Card
- The Quick Reference
- The APT Howto
Content could be extracted (in an automatic way) from both the website [1]
and/or from the Debian packages providing them [2].
Unfortunately, the ftp site (as used in the 'add-bin-doc' script) is not an
option because #172482 has not been considered and, consequently, the 'doc'
directory in the mirrors do not contain translations or DDP manuals which are
not provided (yet) in Debian packages.
Also, there are all the issues around 'byhand' processing. See, for example
where is doc-debian 3.1.4 (has been sitting in incoming for
byhand processing for a month).
By providing all that content in easily printable format it would make it
easier for users that do not have good broadband access and have not yet
installed Debian to go through or print those manuals before even starting
installation.
This could also fix the issue that, in past releases, official CD images have
_not_ provide content useful for non-English speakers in the /doc directory
(look at, for example, the FAQ)
Having all that content in one place makes it more easier for users to find
and take profit of (you'll see below that the document to package mapping is
not at all evident for a novice user).
Just my wishlist :)
Javier
[1] Some of these are available under http://www.debian.org/doc/manuals/, or, more
precisely, from /org/www.debian.org/www/doc/manuals , and the
release-specific info is at http://www.debian.org/releases/etch/
(/org/www.debian.org/www/releases/etch)
The Reference Card is at http://people.debian.org/~debacle/refcard/
[2] By extracing all of /usr/share/doc/${package} to the CD.
The FAQ = doc-debian
The Installation Guide = installation-guide-XXX
The Refence Guide = debian-reference-XX
The Quick Refence = quick-reference-XX
The Project History =
The APT HOWTO = apt-howto-XX
The Securing Debian Manual = harden-doc
Gunnar Wolf
> Bad news I'm afraid. I've worked through the mkisofs boot code again,
> and I get:
> I'm looking further to see if it's at all possible to get (e.g.) hppa
> and alpha to live in the same boot sector, but it's really not likely.
I might be stating the obvious, but the OpenBSD team (and I understand
it's Theo specifically who was responsable for this) spent a
nontrivial amount of time working how to make their CDs bootable in
every possible platform, with usually 3-4 architectures per
CD. Maybe (knowing their community is (even) more hostile than ours)
it's not an option to ask them for information on how they managed to
do this, but you could study a bit their ISO's layout.
Their ISOs are not freely redistributable, but if you are interested,
I can snail-mail you some older releases (~4 year old, IIRC) I have
around here.
Greetings,
--
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Steve McIntyre
>Steve McIntyre dijo [Fri, Dec 22, 2006 at 03:04:54PM +0000]:
>> Bad news I'm afraid. I've worked through the mkisofs boot code again,
>> and I get:
>> (...)
>> I'm looking further to see if it's at all possible to get (e.g.) hppa
>> and alpha to live in the same boot sector, but it's really not likely.
>
>I might be stating the obvious, but the OpenBSD team (and I understand
>it's Theo specifically who was responsable for this) spent a
>nontrivial amount of time working how to make their CDs bootable in
>every possible platform, with usually 3-4 architectures per
>CD. Maybe (knowing their community is (even) more hostile than ours)
>it's not an option to ask them for information on how they managed to
>do this, but you could study a bit their ISO's layout.
>
>Their ISOs are not freely redistributable, but if you are interested,
>I can snail-mail you some older releases (~4 year old, IIRC) I have
>around here.
Thanks, but there's no need to do that. Looking at their website I can
see that all their latest CD sets claim to be bootable on "i386,
amd64, macppc, sparc, and sparc64". I'm already doing 3 of those
arches, and I'm really not that bothered about sparc...
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"The problem with defending the purity of the English language is that
English is about as pure as a cribhouse whore. We don't just borrow words; on
occasion, English has pursued other languages down alleyways to beat them
unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Steve McIntyre
to discuss this further... ]
On Fri, Dec 22, 2006 at 03:04:54PM +0000, Steve McIntyre wrote:
>
>Bad news I'm afraid. I've worked through the mkisofs boot code again,
>and I get:
>
>alpha: Writing alpha boot descriptor at extent 0
>arm: No boot sector
>amd64: Writing el torito VD sector at extent 17
>hppa: Writing hppa boot descriptor at extent 0
>i386: Writing el torito VD sector at extent 17
>ia64: Writing el torito VD sector at extent 17
>m68k: Writing hfs descriptor at extent 0
>mips: Writing mips boot descriptor at extent 0
>mipsel: Writing mipsel boot descriptor at extent 0
>powerpc: Writing hfs descriptor at extent 0
>s390: No boot sector
>sparc: Writing sun boot descriptor at extent 0
> Writing genboot sector at extent 1
>
>I'm looking further to see if it's at all possible to get (e.g.) hppa
>and alpha to live in the same boot sector, but it's really not likely.
Within sector 0:
alpha
=====
bytes 000-<n> : ID string "Linux/Alpha aboot for ISO filesystem.". Looks
like that could be modified if necessary.
480-487 : length of the boot image
488-495 : location of the boot image
504-511 : checksum of the previous bytes in the boot sector
(otherwise blank)
hppa
====
bytes 000-008 : magic header
008-011 : location of kernel image
012-015 : length of kernel image
016-019 : location of ramdisk
020-023 : length of ramdisk
024-150 : boot command line
232-235 : location of kernel image
236-239 : length of kernel image
240-243 : location of boot loader image
244-247 : length of boot loader image
(otherwise blank)
m68k (first 6 sectors)
====
bytes 000-12288 - hfs map (no obvious way to co-exist)
mips
====
jealously scribbles all over the first 512 bytes
mipsel
======
bytes 000-008 : 0-padding
008-011 : magic header
012-015 : boot mode
016-019 : load address
020-023 : exec address
024-027 : boot file length
028-031 : boot file location
(otherwise blank - may contain other boot files, but we don't use it)
powerpc (first 12 sectors)
=======
bytes 000-24576 - hfs map (no obvious way to co-exist)
sparc
=====
bytes 000-127 : ASCII text for disk label (maybe possible to steal
some of the end)
128-267 : data for 8 sparc "partitions"
268-411 : padding
420-511 : "disk" params
So, options as I see it:
m68k, mips and powerpc will not live with anything else.
alpha/hppa: *may* work, but any display of the ID string on alpha will
look bad due to overloading with the hppa "magic"
bytes. Otherwise no overlap.
alpha/mipsel: *may* work, but any display of the ID string on alpha
will look bad due to overloading with the mipsel
metadata bytes. Otherwise no overlap.
alpha/sparc: clash, no-go
hppa/mipsel: clash, no-go
hppa/sparc: *may* work, but any display of the ID text on sparc will
look bad and depending on the sparc loader the hppa
metadata will confuse things - it will look like a sparc
disk partition
mipsel/sparc: *may* work, but any display of the ID text on sparc will
look bad
powerpc/m68k both use HFS data and a secondary volume descriptor. In
theory should co-exist with each other(as Apple have done in the
past), but I've no idea whether our stuff will work.
Plus: all of these options will require some gross hacking inside
mkisofs/genisoimage.
amd64/i386/ia64 all do El Torito boot; i386 and amd64 will both use
isolinux and therefore with some debian-cd hacking (already done) the
user can be given a choice of kernels. I know *nothing* about the
details of ia64 to know whether it can be made to co-exist with them
at all.
So, any combination of amd64 and i386 and (one, maybe two) of the
sector 0 arches should work together AFAICS.
If people are *really* interested in trying these out, I can put more
effort in. But as it stands I don't see enough of a chance of success
beyond what I've already done (amd64/i386/ppc) to spend time doing any
more...
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Wouter Verhelst
> m68k (first 6 sectors)
> ====
> bytes 000-12288 - hfs map (no obvious way to co-exist)
Are we actually doing some special magic with our m68k images currently?
If so, for what reason? Is it to boot the machine, or just so that it
looks good in MacOS?
If the former, we should probably stop that; there's no way an m68k mac
is going to boot Linux from CD-ROM without non-free bits until emile has
a free reimplementation of a CDROM driver for macs (yes, that would be
required).
Obviously, if we're only trying to make it look good under MacOS then
there's no reason to stop doing that :)
--
Fun will now commence
-- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Steve McIntyre
>On Sun, Dec 24, 2006 at 05:19:03AM +0000, Steve McIntyre wrote:
>> m68k (first 6 sectors)
>> ====
>> bytes 000-12288 - hfs map (no obvious way to co-exist)
>
>Are we actually doing some special magic with our m68k images currently?
>If so, for what reason? Is it to boot the machine, or just so that it
>looks good in MacOS?
>
>If the former, we should probably stop that; there's no way an m68k mac
>is going to boot Linux from CD-ROM without non-free bits until emile has
>a free reimplementation of a CDROM driver for macs (yes, that would be
>required).
>
>Obviously, if we're only trying to make it look good under MacOS then
>there's no reason to stop doing that :)
To be perfectly honest, I'm not 100% sure exactly what the boot-m68k
script does for mac. <pause>
Looking, I don't see anything useful in terms of booting. However,
using the HFS hybrid format will mean that (hopefully) whatever docs
etc. are shipped on the CD will be readable easily on the mac
too. Otherwise, AFAICS the m68k is set up to be bootable on amiga and
bvme6000.
If there's anything that should be changed here, please dive in... :-)
--
Steve McIntyre, Cambridge, UK. st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Gunnar Wolf
> >Their ISOs are not freely redistributable, but if you are interested,
> >I can snail-mail you some older releases (~4 year old, IIRC) I have
> >around here.
>
> operator
The software itself is free, but the way it is arranged to be
multi-bootable is not.
Greetings,
--
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Wouter Verhelst
> On Tue, Dec 26, 2006 at 06:21:45PM +0100, Wouter Verhelst wrote:
> >On Sun, Dec 24, 2006 at 05:19:03AM +0000, Steve McIntyre wrote:
> >> m68k (first 6 sectors)
> >> ====
> >> bytes 000-12288 - hfs map (no obvious way to co-exist)
> >
> >Are we actually doing some special magic with our m68k images currently?
> >If so, for what reason? Is it to boot the machine, or just so that it
> >looks good in MacOS?
> >
> >If the former, we should probably stop that; there's no way an m68k mac
> >is going to boot Linux from CD-ROM without non-free bits until emile has
> >a free reimplementation of a CDROM driver for macs (yes, that would be
> >required).
> >
> >Obviously, if we're only trying to make it look good under MacOS then
> >there's no reason to stop doing that :)
>
> To be perfectly honest, I'm not 100% sure exactly what the boot-m68k
> script does for mac. <pause>
>
> Looking, I don't see anything useful in terms of booting. However,
> using the HFS hybrid format will mean that (hopefully) whatever docs
> etc. are shipped on the CD will be readable easily on the mac
> too.
Yes, that's probably right; whenever I open a Debian/m68k CDROM under
MacOS, it looks (somewhat) proper.
> Otherwise, AFAICS the m68k is set up to be bootable on amiga and
> bvme6000.
>
> If there's anything that should be changed here, please dive in... :-)
No, the above seems correct. EMILE has support for CD booting, but that
requires some code from MacOS which AFAWK can't even be in non-free (let
alone on official Debian CD images).
--
<Lo-lan-do> Home is where you have to wash the dishes.
-- #debian-devel, Freenode, 2004-09-22
Thiemo Seufer
[snip]
> mips
> ====
> jealously scribbles all over the first 512 bytes
I figure that's a DVH "Disk Volume Header" as used on SGI machines.
> mipsel
> ======
> bytes 000-008 : 0-padding
> 008-011 : magic header
> 012-015 : boot mode
> 016-019 : load address
> 020-023 : exec address
> 024-027 : boot file length
> 028-031 : boot file location
Looks like an Ultrix boot record for a DECstation.
That's a list of boot file extents and their locations. For an ISO
we can assume contiguous files, so it makes no difference in that case.
> (otherwise blank - may contain other boot files, but we don't use it)
There's only a single boot file. As a sidenote, there are other
mips/mipsel system architectures with different firmware and disk
layout conventions. This makes even building a CD which boots on
all mips systems tricky.
Thiemo
Steve McIntyre
>Steve McIntyre wrote:
>[snip]
>> mips
>> ====
>> jealously scribbles all over the first 512 bytes
>
>I figure that's a DVH "Disk Volume Header" as used on SGI machines.
Yup, exactly. I borrowed the layout from your own genisovh
program... :-)
>> mipsel
>> ======
>> bytes 000-008 : 0-padding
>> 008-011 : magic header
>> 012-015 : boot mode
>> 016-019 : load address
>> 020-023 : exec address
>> 024-027 : boot file length
>> 028-031 : boot file location
>
>Looks like an Ultrix boot record for a DECstation.
>That's a list of boot file extents and their locations. For an ISO
>we can assume contiguous files, so it makes no difference in that case.
>
>> (otherwise blank - may contain other boot files, but we don't use it)
>
>There's only a single boot file. As a sidenote, there are other
>mips/mipsel system architectures with different firmware and disk
>layout conventions. This makes even building a CD which boots on
>all mips systems tricky.
Yeah... :-/
--
Steve McIntyre, Cambridge, UK. st...@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Joey Hess
actually working now.
http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-cd/debian-testing-i386-xfce-CD-1.iso
It won't install xdm though.. that will probably be fixed in time for
next week's build, along with hopefully a better selection of packages
on the CD.
--
see shy jo
Steve Langasek
> Within sector 0:
I just couldn't resist... :)
I've submitted bug #404986 against genisoimage which includes a patch that
lets hppa and alpha boot blocks coexist without clobbering one another.
Since the only conflict between these two blocks was a cosmetic one
(apparently the ID string from aboot is never displayed at all when booting
from SRM so it's hardly even that), this should work just fine.
So far, though, I've only tested it on alpha, not on hppa. If anyone would
care to give this a whirl and follow up to the bug report, that'd be nice.
I have a jigdo set at
http://people.debian.org/~vorlon/debian40-alpha-NETINST-1.jigdo and
http://people.debian.org/~vorlon/debian40-alpha-NETINST-1.template which is
an alpha netinst image, plus the kernel/initrd/bootloader for hppa; this
means it's not actually installable on hppa, but it should be bootable if
someone wants to give it a try and report back any results.
If this checks out and the patch is accepted, it should be trivial to tack
in ia64 or i386/amd64 as well, as long as space permits. :)
That's probably as many archs as it's realistic to squeeze onto a single
image. It would be interesting to know how OpenBSD got sparc and powerpc to
coexist though, since Steve's report says that powerpc wants all of the
first 12 sectors -- figuring that out might let us stretch this even farther
into the realm of the absurd ;)
Steve Langasek
> I have a jigdo set at
> http://people.debian.org/~vorlon/debian40-alpha-NETINST-1.jigdo and
> http://people.debian.org/~vorlon/debian40-alpha-NETINST-1.template which is
Correction: that's
http://people.debian.org/~vorlon/debian-40-alpha-NETINST-1.jigdo and
http://people.debian.org/~vorlon/debian-40-alpha-NETINST-1.template. Sorry
for the typo.
Ryan Bradetich
Matt Taggart pointed me to this thread and I tested the .iso image you provided via jigdo on my j6000. I was able to successfully boot the system and the Debian installer did start.
Thanks,
- Ryan
Steve Langasek
On Fri, Dec 29, 2006 at 08:26:33PM -0800, Ryan Bradetich wrote:
> Matt Taggart pointed me to this thread and I tested the .iso image you
> provided via jigdo on my j6000. I was able to successfully boot the system
> and the Debian installer did start.
Great, thanks for the feedback. Forwarding this on to the bug report.
Cheers,