gmane.linux.gentoo.documentation

Re: Clean-up of < at >link attribute

Joshua Saddler — 2012-04-08T16:34:39

On Thu, 5 Apr 2012 20:17:20 +0000
Sven Vermeulen <swift< at >gentoo.org> wrote:


awesome. 'bout time this was finalized. do it.

Clean-up of < at >link attribute

Sven Vermeulen — 2012-04-05T20:17:20

Guys,

Unless you're all screaming loud "No" or something else that's clear to
understand, I'll be removing the < at >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.

Re: Moving stuff to Gentoo Wiki?

Sven Vermeulen — 2012-03-27T19:37:08

I'm no Messiah, and I'm grumpy. Two things not in favor of that ;-)


Yes, we recently support the same version as on the Wiki.

Moving however does have its implications. Handling translations still needs
to be sought out/through, although I can imagine that most translation teams
also don't have the power of an entire army at their disposal to handle
translations. And especially not for wiki's.

Wkr,
Sven Vermeulen

Re: Moving stuff to Gentoo Wiki?

Paweł Hajdan, Jr. — 2012-03-27T19:21:39

Sounds good. For some reason people like wikis...

I generally prefer GDP, but it's obviously not possible to have 4 people
handle the same load as 20 people. By the way, I think that after your
return Sven the GDP can attract more contributors.


Would the licensing also allow eventually taking the wiki articles and
adding them to GDP?

Re: Moving stuff to Gentoo Wiki?

Aaron W. Swenson — 2012-03-27T19:10:41

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/27/2012 03:05 PM, Sven Vermeulen wrote:

I am for it.

Provided that some pages can be marked editable by developers only.

- - Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk9yELEACgkQVxOqA9G7/aAsMgD/RJNTcySQ1Di3HxhCDxtBxVGK
sljiZnhyF4yHtfDvrnIBAIhkAjhhKxfI7oesqFGG5pJXzloIqaqTjTNAa6zFYIrJ
=cLnM
-----END PGP SIGNATURE-----

Moving stuff to Gentoo Wiki?

Sven Vermeulen — 2012-03-27T19:05:49

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

Sven Vermeulen — 2012-03-12T18:32:29

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

Re: ARM manuals

Ivan Ferdous — 2012-03-01T18:12:12

unsubscribe

On Thu, Mar 1, 2012 at 11:34 AM, wireless <wireless< at >tampabay.rr.com> wrote:

Re: ARM manuals

wireless — 2012-03-01T16:34:14

The apr 1 info, may be the key parameter. I remember reading snippets
in several locations.... but nothing to recall now. I did not
really focus on the issue at the time, so it is completely
possible it was but a lark, I did not discern.....

Still, an interesting idea, some would think. I have taken
the path of setting up raid under Ubuntu, as suggested to me
by a few old gentoers. While visiting the Ubuntu offerings,
it surprises me to see so many (gentoo) familiar folks bouncing
around and using Ubuntu, for a wide variety of purposes.
Quite a lively and social bunch over there at Ubuntu, many
old friends.....


]
Yes you are correct. Also, I did find the Ubuntu installation media
(alternate.iso) for explicitly setting up RAID, as part of the
native Ubuntu installation docs and media.

Furthermore, Ubuntu on arm boards; documents intended for the rank and 
file users; very cool indeed.

I'm still looking for equivalents in Gentoo; maybe after grub-2
is stable on gentoo, we can get a singular document and matching 
installation media for installing RAID from scratch.....

Also note,native ARM support for netbooks, laptop and lite-workstations
is coming to many linux distros. I just hope Gentoo leads
rather than follows in that regard. Surely the talent
is in the dev_pool to make it work, it's the documentation
that is the real challenge, imho.

sincerely,
James

Re: ARM manuals

Sven Vermeulen — 2012-03-01T06:44:51

I wasn't aware of that. Do you have some info on this?


Publication isn't an issue. We also have http://wiki.gentoo.org where
you can quickly set up and publish documents.

Wkr,
  Sven Vermeulen

Re: RAID install document

Duncan — 2012-02-15T08:13:23

wireless posted on Tue, 14 Feb 2012 12:48:04 -0500 as excerpted:


There's no official gentoo grub2 docs at this point, and the existing doc 
(the link given in a grub2 postinstall einfo) is /seriously/ insufficient/
incomplete.  That's one of the big reasons grub2 is still hard-masked, 
not even ~arch yet.

If you can get your grub2 info elsewhere, however, or know it reasonably 
well from experience on other distributions, you'll know it's great for 
gpt even on BIOS systems.  (That's one of the bits missing in that grub2 
doc, BTW, it mentions EFI and mbr-bios but not gpt-bios.)  Of course, 
it's also great for md/raid.

I don't know about the status of gentoo gpt documentation, but gptfdisk 
is a great fdisk for gpt, and it has very good documentation on its 
homepage.  I'm a great booster of both gpt and gptfdisk aka gdisk for a 
number of reasons, including that gpt does away with the primary/logical 
partition hassle, that it is *FAR* more reliable due to checksumming and 
the second partition copy, the gpt-labels (as opposed to filesystem 
labels, FWIW I use both but would prefer gpt labels as soon as mount, 
etc, learns to work with them), and the dedicated BIOS and EFI system 
partitions.

It's worth noting that upgrading to grub2 was hugely easier for me 
because I was already using gpt and had set aside a dedicated BIOS 
partition (also an EFI partition, for the day I upgrade systems again).

The caveat with grub2 here was the absolutely ridiculous number of calls 
to grub2-probe that the default grub2-mkconfig script has with apparently 
no caching, each one taking ~10 seconds on my multi-disk system, with the 
total script therefore taking something like five minutes to run (based 
on a bit of profiling I did, the script other than the grub2-probe calls 
takes well under 10 seconds, so it's nearly all due to the repeated grub2-
probe calls), more than a kernel build from clean!

As a result, I INSTALL_MASKED grub2-mkconfig and /etc/grub.d so they'd 
have absolutely no chance of being run as they don't appear on the 
system, then learned manual grub.cfg configuration and setup my own 
configuration by hand.  That's the only practical solution for anyone who 
upgrades their kernel at all frequently (I build from linus-mainline 
git), at least for systems with multiple drives and mounts to be probed.  
As such and because the drive scanning order remains relatively stable 
here (and the parameter can be changed in grub "live" if I need to), I 
chose to stick with the relatively simple device names (not labels) for 
grub2.

Here, I use md 0.90 metadata and no initr*.  I don't autodetect, however, 
as I have multiple md/raid devices and I only want the one containing the 
rootfs autoassembled, with userspace assembling the others I want 
activated, later.  Instead, I build in a kernel command line that 
includes and md= parameter and disable autodetect.  I'm not entirely sure 
if that could be done with 1.x metadata or not, since I'm feeding it the 
devices to assemble into the raid instead of using autodetect.

For /boot, depending on the number of spindles you're running, you may 
wish to split it down the middle /boot and a backup /boot, or setup 
independent /boot partitions on each one (if only 2-3 spindles).  That 
way, you can upgrade grub or install new kernels on one (presumably the 
working /boot not the backup(s)), without risking damage to the others 
until you've tested booting the first upgraded one.  Once it is known to 
boot the upgrade correctly, you can update the others.  For people like 
me that test git kernels, that also allows me to only install them to the 
normal /boot.  I only update the backup(s) when a release kernel comes 
out and I've tested it on the working /boot, then deleted all the pre-
release versions once the release is tested to boot.

That also allows you, if you so choose, to follow the official gentoo 
documentation a bit closer, installing grub-legacy first, to one /boot, 
then unmasking and installing grub2 to a second, to experiment with, 
switching in BIOS which one boots while testing, before replacing the 
documented grub-legacy that was installed to the first one only after 
you're comfortable with how grub2 is working and setup on the others.

Talking about which... the below link is the official quick-start 
installation guide for gentoo on lvm2 on md/raid.  I'm not personally 
much for lvm2 -- the additional layer was too much for me to understand 
well enough to be confident I could manage a proper recovery if I needed 
to and it's no longer all that necessary since md/raid devices can be 
partitioned like any normal block device these days -- but if you're 
running a desktop such as gnome or kde and want the automounting to work 
well, you'll still want to configure the device-mapper kernel options and 
need to install the lvm2 package, which contains the device-mapper 
userspace needed by udisks for automount handling, etc.  You'd just not 
create the lvm2 volumes (and could wait until it's pulled in as a udisks 
dependency to merge lvm2 if desired).

Of course, this still documents grub-legacy, but as I mentioned, you can 
either split up your /boot and install grub-legacy first, following the 
official documentation reasonably closely, then install grub2 later, when 
you have time to experiment with it, or ignore the grub bit too, and do 
the grub2 thing right off, if you're comfortable enough with it already 
that you can handle the lack of gentoo specific documentation for it.

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

That's likely more than I should have written for the documentation list, 
but it's topical in that it does represent the state of things, I guess.

Meanwhile, feel free to ignore the "list replies preferred" bit in the sig 
and contact me directly, if you've more questions, since it should be 
quite apparent by now that I have quite some interest and some experience 
in this area.  If you do contact me directly, please mention whether 
amd64/x86/whatever (amd64/nomultilib, here), whether you're targeting 
stable or ~arch and how comfortable you are with unmasking stuff like 
grub2, etc, and reading other documentation, the number of spindles 
you're raiding and metadata version, the desktop you'll be installing if 
any and whether you care about the automount stuff (fwiw I'm a kde guy, 
and have udisks and lvm2 installed as dependencies but don't have device-
mapper on in the kernel as I don't particularly care for automounting), 
whether you're running an initr* (I don't and know little about them), 
etc, as that could well save a few rounds of email-ping-pong. =:^)

RAID install document

wireless — 2012-02-14T17:48:04

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

Re: Portage per-package environment/behavior

Sven Vermeulen — 2012-01-03T17:33:42

I'll bring it through -dev just to be sure.

Regarding #gentoo suggestions, a quick grep in my logs shows it being
mentinoed about twice a week, mostly by users (there aren't that many
developers on it) but also a few developers (amongst some in the qa team).

Of course, that's not considering the context of the discussion - it may be
very well a specific scenario there.

Wkr,
Sven Vermeulen

Re: Portage per-package environment/behavior

Joshua Saddler — 2012-01-02T18:54:20

On Sun, 1 Jan 2012 08:59:25 +0000
Sven Vermeulen <swift< at >gentoo.org> wrote:


and who's suggesting it on #gentoo? users? devs? we need to talk to
the portage team and anyone else that would have to troubleshoot
build fixes caused by (ab)using it. if we get the okay from them,
then something like your proposed text should be added to the
handbook.

Re: Portage per-package environment/behavior

Duncan — 2012-01-01T09:30:57

Joshua Saddler posted on Sat, 31 Dec 2011 19:13:59 -0800 as excerpted:


You are correct that it used to be that way, but isn't that what emerge
--info <pkg>  was designed to fix and why portage's error messages are  
far more specific now about both that and various log files that should 
be posted than they used to be?

Re: Portage per-package environment/behavior

Sven Vermeulen — 2012-01-01T08:59:25

I disagree. It is actively being suggested on #gentoo, and we already
document features that could (or even will) result in RESO:WONTFIX, like
using ~arch (both for a small set of packages as well as the entire system).

I would rather have a <warn> in place then that sais it will hinder support
during bug reports and might result in RESO:WONTFIX unless the user removes
the specific settings and rebuilds with the system ones.

Not documenting is, in my opinion, a lesser solution than documenting and
saying why it is bad.

Wkr,
Sven Vermeulen

Re: Portage per-package environment/behavior

Joshua Saddler — 2012-01-01T03:13:59

On Wed, 28 Dec 2011 11:14:49 +0100
Sven Vermeulen <sven.vermeulen< at >siphos.be> wrote:


per-package cflags has never been an officially supported portage
feature. in fact, it's mostly been an env hack that users have been
actively discouraged from using. they can expect to see bugs closed
RESO WONTFIX when per-package cflag monkeying has been detected. as
such, we shouldn't be documenting how to do it.

Re: Portage per-package environment/behavior

Duncan — 2011-12-31T23:41:47

Sven Vermeulen posted on Sat, 31 Dec 2011 20:16:35 +0000 as excerpted:


Good.

I thought about suggesting a postsync.d mention too, but decided that it 
might be old/stale cruft related to the ed catmur scripts that I used to 
run that seem to be the basis of some of these recent portage extensions 
(like /etc/portage/patches, and this one too, IIRC) as I didn't see 
anything in the portage (5) manpage about it.

So unless the portage docs for postsync.d are there and I just missed 
them, you/I/we might want to ask the portage folks about including the 
documentation in the portage manpage as well.

Re: Re: Updated date in handbook

Sven Vermeulen — 2011-12-31T21:28:25

I didn't hear any other complaints against this, so I went ahead with this
suggestion.

Wkr,
Sven Vermeulen

Re: Portage per-package environment/behavior

Sven Vermeulen — 2011-12-31T20:16:35

Bug #396549 is used for tracking. I also added a section in it about
/etc/portage/postsync.d.

Wkr,
Sven Vermeulen

Re: Re: Portage per-package environment/behavior

Sven Vermeulen — 2011-12-30T12:29:06

It's due to the prototype (actually, the numbering will only be correct the
moment the chapter is integrated in the handbook) because the URL points to
the file itself (rather than using the "handbook.xml?part=3&chap=5"
approach.

Wkr,
Sven Vermeulen