Clean-up of @link attribute

Guys,

Unless you're all screaming loud "No" or something else that's clear to
understand, I'll be removing the @link attribute from all documents in
gentoo/xml/htdocs. After that, I'll update guide.dtd to remove the attribute
so that newly committed documents won't have it anymore either.

I was first contemplating of editing the XML-QA-Checker that gets triggered
on CVS commits so that new commits are "screened" for a while, but I thought
to myself - hey, we're a fast-moving distro, it's easier to just mass-commit
everything (and a nice sed command can auto-change the files for me as
well). 

Let's say, give feedback before tuesday april 10th?

Wkr,
	Sven Vermeulen

PS I'll mail it to gentoo-dev as well, since it'll also affect guides in
project pages.

Moving stuff to Gentoo Wiki?

Hi guys,

As the GDP isn't as large as it used to be (I think we have 2 to 4 active
participants/developers currently, coming from a 20+ situation) we might
want to consider moving documents we can't handle currently onto the Gentoo
Wiki. Most of us either don't know the technologies described in it too
well, or we need some help from the community...

License-wise, this should be okay, as there is a version-up clause in the
CC-BY-SA license most documents use. It would also allow us to focus on the
installation instructions and, who knows, have some input for the Gentoo
Wiki Knowledge base at http://wiki.gentoo.org/wiki/Knowledge_Base:Main_Page


Thoughts on this?

Wkr,
	Sven Vermeulen

Update dcumentation for separate /usr

Hi guys,

The udev package (version 181 and higher) will not support separate /usr
partitions without using an initramfs. Because of this, we will need to
update our documents to inform the users about this:
- inform them that using a separate /usr requires an initramfs
- tell them how to build their own initramfs

I've opened a tracker bug [1] so that we can track issues related with it,
as well as major changes that still need to be done (if any). It also allows
the udev maintainers to block on this bug before stabilizing.

Wkr,
	Sven Vermeulen

[1] https://bugs.gentoo.org/show_bug.cgi?id=407959

RAID install document

Hello,

I'm trying to build a simple (all) raid 1
workstation. Just boot/root/swap like
what is found in the handbook.
  Is this the best document to follow:

http://en.gentoo-wiki.com/wiki/RAID/Software

Since grub2 is now defacto and drive sizes
are routinely over 2T, I guess that Disk-labels
(UUIDs), fstab, gpt and grub2 should all be used
to 'future proof' installations?

There is only a snippet in the handbook
and it couches these and other related issues
around multilib.

Any better, more complete documents are keenly
appreciated.

James

Updated date in handbook

Hi guys,

Something else I noticed is that we sometimes get questions in #gentoo or
even #gentoo-doc about the "Updated" date of the Gentoo Handbook(s). Because
of how things work, the displayed date on the handbook pages is always the
one that is for the given file.

In case of the index page, this is a somewhat old(er) version as the index
page hardly changes. Yet that is the "Updated" version most people look at.

Would it be okay if I updated doc-struct.xsl so that for handbooks, the
updated version always matches the latest update?

Other possibilities are:
- On the index page, display the latest update, but on individual chapters,
  keep the current used date
- Don't touch anything and stop harassing me with your suggestions

	Sven Vermeulen

Portage per-package environment/behavior

Hi guys,

I noticed we don't describe in the handbook that Portage can have
per-package environment variables (like CFLAGS) through /etc/portage/env.
This can be even (ab?)used to execute steps before or after specific phases
(based on the EBUILD_PHASE information), something I use for updating IDS
systems (postinst/prerm phase).

But I'm not sure if and where in the handbook this can be positioned best.
The environment variable stuff could be placed in the section on
"Environment Variables", but is quite off from the rest of the content
(since the rest of that chapter has nothing really to do with Portage or
build environments).

"Configuring through Variables" is probably the best location (somewhere in
the beginning as we talk there about Build-specific Options), but I do feel
that this particular feature is already more targeting advanced users, where
the location in the handbook somewhat suggests this for more beginner-like
types.

Perhaps another section in "Working with Portage", called "Advanced Portage
Features" or so? This can then contain the per-package env information, but
also overriding profile information and perhaps others we don't talk about
yet.

Any ideas on this?

	Sven

Subject: Job Position: someone with a printer

Hi guys,

No, it's not a real vacancy. But we have a couple of bugreports about CUPS
or printing that could need a hand from someone who has at least some
knowledge in printing on Linux. I haven't had a printer in ages (more than a
decade ago) and don't really feel like learning about it without being able
to test things.

Bugs are:
  - #392743 "Implicit assumptions -> confusion when trying to use printer on
             a Win7 machine"
  - #327093 "Addition of 64-bit info to "Gentoo Samba3/CUPS HOWTO"

Wkr,
	Sven Vermeulen

Supporting CC-BY-SA 3.0 and later versions

Hi guys,                                                                                                                           

With http://wiki.gentoo.org having their documents as CC-BY-SA 3.0, I                                                              
thought it might be a good idea to work this out for our documents as well.                                                        
That would allow us to "tech-write" stuff that is on the wiki properly, but                                                        
also use the newer (and recommended) version.                                                                                      

Of course, that won't be done by just making <license /> refer to the 3.0 as                                                       
that will break our documents (legally, that is). Instead, I was considering                                                       
to add @version support to the license entity (in dtd and xsl), update the                                                         
supporting documents (xml-guide and the like) so that this can be done less                                                        
intrusively.                                                                                                                       

In other words, support "<license version='3.0' />" for documents that need                                                        
to be CC-BY-SA 3.0, or for new documents.                                                                                          

What's your take on this?                                                                                                          

Wkr,                                                                                                                               
        Sven Vermeulen

Corrections

documenting emerge-webrsync GPG verification

I've noticed excellent blog post
<http://blog.siphos.be/2011/07/emerge-webrsync-and-gpg-verification/>
but it seems it's still not part of official documentation (e.g.
<http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1>).

Please consider mentioning the steps from the blog post in the official
docs.

Fwd: Re: Arm Gentoo Handbook

On 10/05/2011 11:43 PM, Sven Vermeulen wrote:
> On Wed, Oct 05, 2011 at 02:46:54PM -0400, wireless wrote:
>> What currently links to the Gentoo handbook for ARM is
>> deprecated!
>> 
>> http://www.gentoo.org/doc/en/handbook/handbook-arm.xml?part=1&chap=5
>>
>>
>> 
Why not link to this doc?
>> http://dev.gentoo.org/~armin76/arm/trimslice/install.xml
>> 
>> Lots of new arm netbooks are here and no doubt many different 
>> offerings are on the way!
> 
> Raúl,
> 
> Apart from owning an Eepad Transformer, I know nothing of Gentoo
> Linux/ARM installations. Any thoughts on your part on how we can
> ensure that our documentation stays of high quality here?
> 
> Wkr, Sven Vermeulen
> 

Hi Sven,

Unfortunately i do not have any suggestion of how we could enhance our
documentation in this aspect.

ARM is very different from other, more common, architectures. If we
look at the handbook, we have some troubles at the beginning. Each SoC
has its own specific stuff regarding installation. For example, most
of the OMAP SoCs require an SD-card with specific partition layout.
Some devices have the kernel in the flash memory, some devices lack
flash memory(pandaboard f.ex), so the kernel+bootloader is in external
storage.

Every different SoC needs its own kernel and unfortunately most of the
devices aren't supported in the mainline kernel(yet).

If you look at the documentation i've done:
http://dev.gentoo.org/~armin76/arm/pandaboard/install.xml
http://dev.gentoo.org/~armin76/arm/sheevaplug/install.xml
http://dev.gentoo.org/~armin76/arm/tegra2/install.xml
http://dev.gentoo.org/~armin76/arm/trimslice/install.xml

you'll see that only some small parts are common among all of them.

And although the tegra250 dev kit and the trimslice use the same SoC
as your Transformer or the also famously known Toshiba AC100,
different procedures are required for all of them, and the kernel for
each device only supports said device.

These big differences makes one page per device the only option, IMHO.
I'm open to alternatives. In other distros, the use of
installers(ubuntu) or device/SoC-specific images(archlinuxarm) hide
this issue.

On our case, we do architecture-specific stage3s. armv7a is one
architecture, in the market there are different SoCs that are
compliant to such architecture: TI OMAP4, Freescale i.MX5, Nvidia
Tegra2, etc...
And those examples i just said use, for example, different serial
ports: OMAP4(ttyO2), i.MX5(ttymxc0) and Tegra2 uses the default ttyS0.

The current ARM handbook was written in 2004 or so, and was designed
for a device that is uncommon nowadays, old, and slow.

IMHO removing the current handbook and pointing to one page per device
handbooks would be the way to go.

Thanks