steveL's favourite tips

[steveL]

Lovely set of tips from bssteph, which I'm quoting directly (not put in quotes as it makes it harder to read):

Random incomplete tips for the budding Gentoo user:
* Use a breakbox if you can early on, when you're still getting your Gentoo legs. Put it on something you don't care about too much and go nuts. Even if it isn't your only Gentoo box, have that be the one where you try out an overlay, or switching to ~arch, or whatever.
* Don't plow through big updates. My "rule" is as follows: less than a month, unless the package list is huge, emerge -uDN world is safe. Otherwise, do things in parts, if the system is working fine. emerge -uDN cups, make sure that works, make sure everything works with the new glibc, and then (and ONLY then) move on to KDE or the next thing with 20 or so packages to upgrade. It saves a lot of headache, leaves a system with a better chance of being usable after each step, and makes determining what broke much easier.
* NEVER plow through dispatch-conf (or whatever you use to update your config files). If you can't spend time on each config file immediately after an update, making sure you merge the configs correctly, leave it be and don't reboot/restart any related services until you can get to the configs. NEVER reboot with a dispatch-conf run pending.
* Pay attention to every new package and changed USE flag in an emerge -pvuDN world. A new package here means new deps, obviously. Find out if the deps are optional, see if you should perhaps be using a different (new) package to replace that USE flag that just went away. Trust emerge, but never blindly accept it.
* Clean out your world file every now and then, removing packages that are deps of other packages in world, unless you remember wanting that specific package. (That is, unless you were writing code that used it, you probably don't need libpng in your world file, you only want USE="png".) This can clear up funny problems or point you to better alternatives, especially with virtuals. (Example: I had a FAM library in my world file (I don't even remember the name of it) and it would occasionally spin and take 100% CPU in KDE. One day I did some cleaning and let emerge install gamin, which was the default choice for FAM, which turned out to work much better.)
* Use --depclean. Even if you always --pretend it, just do it to get a sense of things. You may not run the --depclean, but you may still identify some packages you can remove. Look for stuff you don't use anymore when poking around in your world file (or the bold items in emerge output, these days).
* Run one of those cruft scripts, or write your own, for older boxes, but by all means, only if you're perfectly comfortable with it. Verify its output before removing anything.
* Look at /var/log/messages every now and again.

If those points worry you or seem wholly unacceptable, this may not be the distro for you. Sorry. It's a tough thing to say, especially without offending, but in my experience, not being mindful of things like the above will just lead to worse problems later.

[bssteph]

[steveL]

Great post from delta407 on reinstalling python if you're unfortunate enough to lose it (written *ages* ago and still working in Dec 2007 apparently!):
You might be able to reinstall Python using this:

[steveL]

PORTAGE_BINHOST="http://tinderbox.dev.gentoo.org/default-linux/<arch>"
PKGDIR="/path/to/store"
in make.conf; You can browse from: http://tinderbox.dev.gentoo.org/

PORTAGE_BINHOST="http://packages.gentooexperimental.org/packages/<arch-setup>" is another good one, usually more up to date as Patrick does tinderbox runs.

If you do use these, consider donating some money to help the people who provide the binhosts, or they'll get shut down if they use too much resource. For gentoo, it's solar who runs it: I'm sure any help can just go to Gentoo itself, and for gentooexperimental, it's bonsaikitten who you can find in #gentoo-chat on irc.freenode.org.

You can use update with -g or -G for nice support for binhosts over the web. You can also put binHost=1 or binOnly=1 in /etc/update to do this on every run.

edit: no more html url for dev.gentoo.org
edit2: new gentooexperimental address. 3: browse url

[steveL]

From this post by Coldwind:
You can look through your package.keywords and spot those that annoy you, then you look if they work fine and have been for at least 30 days in ~arch. If those requisites are met, then file a stabilisation bug. That's an easy way to contribute to make stable tree better ;-)
this applies to anybody who is capable of checking the ChangeLog to see how much time was the ebuild in the tree, search bugzilla for related bugs, and file a bug.

A template bug is something like this:
Product: Gentoo Linux
Severity: Enhacement
Summary: Stabilize foo/bar-1.0
Description:
foo/bar-1.0 is in the tree for X time and works fine on amd64.
emerge --info:
<Paste emerge --info output here>

..or something like that. If the maintainer thinks it's fine to stabilize, he'll CC ATs and they'll stabilize the package, if not, the bug will stay open or closed with LATER.

If bug is closed or ATs are not CC'ed, DON'T TAKE IT AS AN OFFENSE, probably there's a reason for not stabilizing the package yet.

[steveL]

Here's a one line fn to search for a package in any overlay (blame xenoterracide ;), stick it in .bashrc. NB you need to emerge html2text first.

[XenoTerraCide]

it's all my fault
_________________
I don't hang out here anymore, try asking on http://unix.stackexchange.com/ if you want my help.

[steveL]

Hehe, yup :)

I like your blogs and the ideas xenoterracide, but don't agree with forking Gentoo. Yeah there are some people in it I can't stand, and I think they do a grave disservice to everyone else, most especially the people who provide the software, but I don't care about them. Hopefully they'll leave me alone (and my /ignore list includes all of them;) and it'd be doing the other 99.99% a disservice to tar them with the same brush.

Hopefully things'll get better once the new Trustees sort out the Foundation, the officers and the finances. I don't really expect them to make much of an impact on the social side (which is under their remit and always has been) until they get that done, and I wouldn't want them to shirk it in any way.

In any event I can just go offline for a bit when I get fed up of the trolls: life's too short to let other people spoil the fun ;P

[XenoTerraCide]

[steveL]

Something like this is how we do phase hooks; this is in bashrc, but you can do similar stuff in an /etc/portage/env/cat/pkg file by just using the function and not the surrounding if.

[steveL]

Running a cronjob as a service which isn't allowed to login will give pam errors. Casshan shows how to use the apache user's crontab:

[steveL]

Make sure you set FEATURES="buildpkg" in make.conf. Portage will then build a binpkg every time it compiles a package, so you can roll-back to any version of anything ever installed on your system (til you eclean the binpkg, or otherwise delete it.) If you do that, you'll never again have a problem you can't recover from using what you've already built.

PKGDIR is the base directory where portage will save packages it builds, (see man make.conf), which defaults to /usr/portage/packages. The packages will be in category sub-directories underneath that.

I use: PKGDIR="/var/pkg" in /etc/portage/make.conf since /var is the namespace for this sort of thing (the directory is root:root, not portage here, as I don't want users to be able to write to it.) So my packages are in directories like /var/pkg/sys-apps.

Obviously you have to make the directory (as root) first:

[steveL]

Here's what I use to inspect initscript dependencies.
It's my /root/.bashrc but you can stick it into /etc/bash/bashrc or your own ~/.bashrc ofc. I wrote it to be POSIX-sh compliant, so it should work in busybox too (apart from the first line, which is nothing to do with the functions, but just testing that the shell is interactive: a case construct would be used in POSIX sh.)

[steveL]

I use this function to quickly look up ebuilds that have come up when I'm running update; sometimes you want to review the actual ebuild itself. It uses the wonderful eix command to find the ebuild that emerge would install, if I don't give a full version. (This is needed because we might not have the package installed, and even if we do, we really want to check whichever version is current, for our configuration.)

[Swoon]

[steveL]