Bugzilla Bug 260403

We have just moved the autobuild stages and installcd ISOs under
/release/${arch}/autobuilds/ on the mirrors. At this point, we should probably
update the handbook to reflect the autobuilds as an option.

Also, I have changed the name of the "x86" stages to i486 to more accurately
reflect what they are, since they use CHOST=i486-pc-linux-gnu and have for a
while now.

There are no autobuilds for MIPS and IA64. AMD64 seems to be the only autobuild
to contain minimal livecds. 

x86 has now two stage files: 486 and 686 (which one should we encourage people
to use and why?).

Update from infra (robbat2), with exact information on autobuilds:

isos: alpha, amd64, ia64, sparc, x86, hppa (pending)
stages: alpha, amd64, arm, hppa, ia64, ppc, sh, sparc, s390 (pending), x86

(In reply to comment #0)
> We have just moved the autobuild stages and installcd ISOs under
> /release/${arch}/autobuilds/ on the mirrors. At this point, we should probably
> update the handbook to reflect the autobuilds as an option.

Indeed.
Can we please have 1 or 2 symlinks under the autobuild dir?
latest or preferably latest-iso & lastest-stage since it seems both are not
systematically released together.
Think of it this way: paths have to be hardcoded.

(In reply to comment #1)
> x86 has now two stage files: 486 and 686 (which one should we encourage people
> to use and why?).

It's already explained. s/x86/i486/

The stages and ISOs are built/uploaded at the same time. However, the ISO build
is a bit more fragile than the stages. For any given arch, if the stages build
but the ISOs don't, we still upload the stages. They're more important to be
updated than the ISO.

The s/x86/i486/ change came from bug 256074.

(In reply to comment #4)
> The stages and ISOs are built/uploaded at the same time. However, the ISO build
> is a bit more fragile than the stages. For any given arch, if the stages build
> but the ISOs don't, we still upload the stages. They're more important to be
> updated than the ISO.

I understand why it is so.
We need 2 symlinks to the respective dirs then.

> The s/x86/i486/ change came from bug 256074.

This was not a question, but a reply to comment #1
The handbook already mentions x86 or i686 and explains how to choose.
We just need to s/x86/i486/ in the relevant section

(In reply to comment #4)
> The stages and ISOs are built/uploaded at the same time. However, the ISO build
> is a bit more fragile than the stages. For any given arch, if the stages build
> but the ISOs don't, we still upload the stages. They're more important to be
> updated than the ISO.

agaffney, could you please add a command to your build bot that creates these
symlinks? Users are starting to get confused and we'd like to properly link to
autobuilds from "Get Gentoo!" etc.

I'm not sure if this is something that we should attempt to tackle on the build
or mirror side (or at all). Robbat2, thoughts?

Hi, I have been pinging people in irc to get this moving again.

Would a symlink like below be acceptable to the docs-team for handbook
purposes?

/releases/x86/autobuilds/current/ -> 
                 /releases/x86/autobuilds/2009mmdd/

The only problem I see is that a new directory does *not* guarantee both iso
and stages on platforms where we produce both. If the iso fails for the week
then the stages still get pushed live.

Maybe this would work better (comment #5):

/releases/x86/autobuilds/current-iso. ->
                 /releases/x86/autobuilds/2009mmdd/
/releases/x86/autobuilds/current-stages. ->
                 /releases/x86/autobuilds/2009mmdd/

However this introduces more complexity for a really simple thing. Can we go
with option #1 and a footnote saying "if a iso does not exist, please try a
previous week" keep it simple.

The symlinks are now updated and auto-built.

/releases/$ARCH/current points to the LATEST directory in that arch with an
.iso file.

It's built/updated at :35 every hour.

There will NOT be a symlink to the tarball, because there's too many options (3
for PPC, 2 for x86, 3 for arm, 2 for hppa, 2 for s390, 2 for sh4, etc).

Okay, I did the x86 quickinstall handbook. It's all set for the autobuilds.
Next up are the main handbooks.

We still don't yet have a networkless media release. I don't even know what, if
anything, Releng has planned for that, now that the GLI is dead. I'd still like
to put /2008.0/ in the "archives/deprecated" section of index.xml, with the
appropriate warnings throughout the guide.

That may be premature, seeing as there's no replacement for the old networkless
CDs. However, given that they were declared officially deprecated and
unsupported by Releng, I'm unsure that we should continue to place them so
prominently in our index.

Some time ago I asked for feedback on a restructuring proposal[1], perhaps it
could be simplified to /handbook/ and /handbook/offline/ or nonet/ or
networkless/ or something similar. Since Releng really only tracks the latest
media release or three, perhaps we should do the same and not bother to have
versioned handbooks. We'd just keep each networked/networkless handbook updated
as need be, no need to archive anything.

In the mean time, before I proceed any further with updating the current
/handbook/ and 2008.0/ documents, we need some discussion on the gentoo-doc
list.[2]

[1]http://archives.gentoo.org/gentoo-doc/msg_4db815c5379134f5047b268361977b3d.xml
[2]
http://archives.gentoo.org/gentoo-doc/msg_c4890371d5df178f53908e03bcdd7171.xml

2008.0 books have been marked obsolete.
It's always been my opinion that they were useless anyway.
All the doc they need is 'Boot CD, follow on-screen instruction. If it fails,
file a bug for the release team'. Done.

Now, can we all forget abouth them?

*** Bug 276541 has been marked as a duplicate of this bug. ***

*** Bug 276283 has been marked as a duplicate of this bug. ***

The amd64 handbook really needs to be updated to use the autobuild stages. It
currently says to use the 2008 stages, but they are so old they make it
difficult to update the system. I just did a fresh install and started to use
the stage the handbook recommended until I realized how old it was. A new user
wouldn't know that. I think many of the problems you see in the Installing
Gentoo forum are caused by the ancient stages people are using.

*** Bug 283886 has been marked as a duplicate of this bug. ***

Quoteth the Handbook: Most PC users should use the stage3-i686-2008.0.tar.bz2
stage3 archive.

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=5

This is resulting in more and more users having major issues installing -
notably the version of Portage in that stage doesn't support EAPI-2.

The official install documentation really should not result in a broken
install!

nightmorph have updated the x86 and amd64 handbooks with autobuild relevant
info.

See here:

-
http://archives.gentoo.org/gentoo-doc/msg_749b36d6e9d0e25cf80259009a650639.xml
-
http://archives.gentoo.org/gentoo-doc-cvs/msg_815bb260aff3dfd25c2c475066f318b3.xml

The bloking bugs #273354 , #234310 , #279889 , #280541 , #289119 are also
fixed.

(In reply to comment #17)
> The bloking bugs #273354 , #234310 , #279889 , #280541 , #289119 are also
> fixed.
> 

Not entirely. Just x86/am64, which means most of our arches are still not done.
Let's leave those bugs open until they're all done. I intend to finish the
other handbooks over the next two days.

Hi,

I used the "Gentoo Linux x86 with Software Raid and LVM2 Quick Install Guide"
for an installation here in our network and I ran into a little problem that is
not documentated in the wiki now.

http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml

On above page you will find a section beginning with "Then create the RAID
device nodes and devices: ". In this case you should create new mdraid devices,
but what is when you already have md devices exists ???

In that case you need the --assemble option for the mdadm command to starting
the raid devices.

mdadm --assemble /dev/md0 /dev/sda1 /sdb1
.
.

Can you please add the restart steps for people who forget to set the "root"
password ;) or something else ???

regards
j0inty