steveL's favourite tips

[steveL]

I'm just collecting stuff I've learnt from others here, so it's all in one place in case I lose all my data and hopefully it'll be of use to others.
Top tip so far:
If you have a problem with software in portage file a bug with a patch to add whatever it is that's missing. Be aware of bugzilla ettiquette -- it's not a place for discussion unless it's technical and specific to the bug. If you're unhappy with how you're dealt with, discuss it on the project mailing-list if you don't feel able to file a userrel or devrel bug.
Per package C-FLAGS
Speeding up portage sync - see below.
Rough Guide to Kernel Building
Cleaning out logfiles
from the same thread as:
Getting portage messages for an emerge
Daemonizing azureus - example initscript

Resuming an Install
Fix Networking
Xorg Modelines
Sneakernet
IDE Kernel Config (Written for Intel Chipset < ICH6 but easy to expand)

X for 3d cards: ATI needs DRI loaded, nvidia needs DRI unloaded. (correct me if any of this seems wrong)

How to use dep? (The man page is hard when you're tired) Top 3 thanks to mark_alec on IRC
dep -w, --pruneworld
dep -u, --usedesc for PKG
dep -e, --versions and status of PKG
-t, --tree-depends and -T, --reverse-tree of PKG
-U, --iuse list pkgs which declare a USE flag
- kudos to ecatmur for the script.

kernel-config
<stick-guy> to search for CONFIG_NET_WIRELESS, press / and then type NET_WIRELESS in the resulting dialog

to check whether you have a module:
lsmod = loaded modules, modprobe -l = all built modules
- just add `|grep mod*' to find it if you have a specific module in mind.

euse -i USEFLAG is your friend!

mount -t smbfs -o lfs allows large files (irc)

Install order/ toolchain update/ emerge -e replacement?:
glibc - gcc -> kernel -> xorg -> kde -> java -> world
I know binutils needs to be in there too; I usually try to do it first and then after gcc as it doesn't take long.

For archive: no name, took it down a while ago, sorry:
Let's assume you want to write /usr/local into a file under /mnt/archive:
find /usr/local -print | cpio -H tar -ov | bzip2 > /mnt/archive/usr_local.tar.bz2
To list the contents of your archive:
cat /mnt/archive/usr_local.tar.bz2 | bunzip2 | cpio -itv
To extract the archive, you can use
cat /mnt/archive/usr_local.tar.bz2 | bunzip2 | cpio -imdv
Now, Let's assume your /usr/local/ contains the file /usr/local/bin/myscript. You can extract just this file by
cat /mnt/archive/usr_local.tar.bz2 | bunzip2 | cpio -imdv /usr/local/bin/myscript
or even extract all of your scripts that start with "my":
cat /mnt/archive/usr_local.tar.bz2 | bunzip2 | cpio -imdv '/usr/local/bin/my*'

As far as I remember, there are some older versions of cpio, in which the "-H tar" didn't preserve the modification time correctly. I usually prefer option "-c" or "-H crc", which are, however, not compatible with tar.
cpio has many other interesting options, so it's worth having a look into the manual pages.

for ebuild dev:
E_IUSE=${E_IUSE// X } - deletes every X with whitespace around it.
E_IUSE=${E_IUSE#X } - deletes X if there is one at the beginning
E_IUSE=${E_IUSE% X} - deletes X if there is one at the end

Adding patches to an ebuild: (I didn't take the author's name down, so sorry whoever you are.
ebuild /usr/portage/pkg-category/some-package/some-package-1.0 unpack
cd /var/tmp/portage/pkg-category/some-package/work/...
patch -p1 < ~/my-patch-for-some-package
cd
ebuild /usr/portage/pkg-category/some-package/some-package-1.0 merge

You can also use the post_src_unpack() user hook and the profile.bashrc in the
base profile for this. E.g.:

# mkdir -p /etc/portage/env/$category
# cat << END > /etc/portage/env/$category/$name
post_src_unpack() {
epatch foo.patch
}
END
uberpinguin:
you need to edit the ebuild and use 'epatch' to apply the patch. once you've got the ebuild tweaked, you'll have to 'ebuild EBUILD digest' to fix the checksums. I'd recommend creating an overlay to put your modded ebuild in, though.
read the man page for patch and look at the first couple lines of the patch to see what '-p' level to use; apply the patch; ebuild EBUILD digest to fix the checksums; try emerging it

edit: Found this documentation on ebuild patching, ty masterdriverz.

Breaking old ebuilds with eclass changes is a QA violation (antarus i think)

edits: added uberpinguin's stuff, more posts that i had linked wrong (thanks amne), took out pgrep replacement. added kernel config tip. added cleaning out logfiles, fixed sneakernet link, tidied

[Fukai]

[steveL]

Nice one Fukai.

[steveL]

First, emerge gentoolkit if you don't have it (you should!)

# Check for security updates:
glsa-check -l affected

# Check which packages will be emerged :
glsa-check -p affected

# Apply security updates:
glsa-check -f affected

Thanks lefou!

[steveL]

Having device nodes for stuff udev doesn't handle:
<Kyuu> ..a tarballed udev tree which can be set in /etc/conf.d/rc
<MvG> RC_DEVICE_TARBALL="yes"
from rc file:
# Set to "yes" if you want to save /dev to a tarball on shutdown
# and restore it on startup. This is useful if you have a lot of
# custom device nodes that udev does not handle/know about.
<MvG> You create the device node manually, and next time you reboot it's recreated from the tarball.

[steveL]

awk 'sub(/-[0-9].*/, "")' is the current recommendation for a pipe/ file of pkg names
[${x%-[0-9]*} if $x has the atom (I haven't tried this yet, but I trust xmb on #bash)

[nanafunk]

Don't trust xmb.

[lefou]

[steveL]

[nanafunk]

2 functions from my ~/.bashrc, hopefully some use to someone.

pc -- package count, number of packages installed
pl -- package list, list of packages installed

[steveL]

Excellent! Thanks nanafunk.

[steveL]

[steveL]

This is an excellent tip from zmedico for speeding up portage cache updates- by not doing them! Seems the metadata kept in /var/cache/edb is pretty similar to the metadata which is rsynced (slightly different format) and portage can be set just to use the rsynced version. Perfect!

All you do is:

[steveL]

Transferring system:
from uberpinguin:
I have had excellent results from booting off a livecd, and 'tar -vcpj /mnt/gentoo/ --file=/remote/volume'. Never had trouble with the restore.

boot from a livecd, mount your root filesystem in /mnt/gentoo/ and 'tar -xvcjpf /remote/volume/archive.tar.bz2 /mnt/gentoo/'

[N-S]

Link to Sneakernet is broken. It goes to the Xorg modelines page.
_________________
___________________
There is No Substitute!

[steveL]

[steveL]

[steveL]

TriffidHunter: ..when you don't put INPUT_DEVICES="mouse keyboard" in your make.conf before emerging xorg.. add that, then emerge -avt1 xf86-input-{mouse,keyboard}

intel hd audio: if (kernel alsa) the modem driver (Intel/SiS/nVidia/AMD MC97 Modem) is enabled i cannot use my soundcard either (renihs)
zgrep SND_INTEL8X0M /proc/config.gz (zlin) good tip for checking whether your kernel has a setting.

[steveL]

[steveL]

Another NeddySeagoon post, this one on setting up IDE and DMA for hard disk and cdroms. Change the chipset line at the bottom to match yours.

[steveL]

This is really simple, but there's one small gotcha, which is you need a repo_name file in profiles subdir, or portage will complain that the PORTDIR directory structure is invalid.
In make.conf:
PORTDIR_OVERLAY="/usr/local/portage"
and then:
mkdir -p /usr/local/portage/profiles
echo myName > /usr/local/portage/profiles/repo_name

Remember the directory structure should mirror the one under /usr/portage. So, for example, an apache ebuild you've patched would go in directory /usr/local/portage/www-servers/apache.

Before you can use it, you have to cd to the overlay ebuild directory and run:
repoman manifest

This will download any sources you need, but not any patches etc: they live in the files subdir under the ebuild directory. It's easiest just to try emerging the ebuild (-av will tell you it's coming from the right overlay; it'll show '::myName' after the version) and cp any files needed from the portage tree.

You can also add licenses which are not in the main tree under licenses subdir, and patch eclasses (if you have to-- better for writing your own) in ofc, the eclass directory.

Overlays are selected in the order they're listed in PORTDIR_OVERLAY so your local one will be picked over layman, if the above line is before the source of layman.conf, and the ebuild is the newest best-visible. That one is always picked, irrespective of which overlay it's in; the ordering only comes into play for equal versions of the same best-visible. (best-visible is the latest one according to your profile and any masking/ keyword settings.)

[steveL]

To get anything you emerge with FEATURES=debug emerge blah to also have the proper CFLAGS etc for a debug build, use this in /etc/portage/bashrc:

[steveL]

[steveL]

Nice post which gives a good summary of how to setup Gentoo in production. update handles binpkgs nicely ofc :)

[steveL]

Great post on making an updated install stage. I've been building chroots for the last couple of months while working on update and am thinking to write a script to replicate my current setup from a stage3. I've built loads of chroots, especially since I started using a binhost, and have started a script which takes care of the base build based on user menu selection.
Anyhow, I'll add stuff to this post, so far we have:

• Hostname, and configs
  We can copy from existing system, or the config file dir. And the user should be able to edit any config file from a selection and revert changes in case of problems. Eg making sure the CFLAGS are correct (for a single-user reinstall) is important, as are any base USE settings.
  
  
• Update system then emerge -e world
  First run of system and world we can do -X, imo. It's better to build it up slowly, get the machine booting and see.
  
  
• umount /dev /proc from the chroot and then tar the installation:
  

  Code:

  cd / && tar -cvjp ./ -f $(date +%Y%m%d)-baseline.tar.bz2

  
  Gives a base stage. It would be fun to play with that in a vm as well.