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.

Hah! Very nice, I approve. (I thought while writing that maybe hidden in some unrelated thread isn't the best place for them, but looks like you solved that.) Feel free to clean them up or whatever. There are probably dozens of such little tips/headache avoiders floating around, keep threads like this coming._________________Website - All sorts of nonsense (some of it actually Linux related)

Hopefully this will be enough of Python to let you "emerge python" again.
---
Another in same thread from desultory: (more recent)
If the python interpreter is actually nonfunctional, as opposed to some mishap with configuration or selection, try the following.

Download the package from the tinderbox repository which matches the architecture of the system. Place that file in $PKGDIR on that system. Then unpack that package directly under /, tar xvjf $PKGDIR/python-2.4.4-r6.tbz2 should do it, though $PKGDIR will likely need to be manually expanded as it is not typically present in the environment. Next ln -s /usr/bin/python2.4 /usr/bin/python. Finally, emerge -K dev-lang/python.

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.

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: Enhancement
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.

Last edited by steveL on Sun Aug 02, 2015 11:08 am; edited 1 time in total

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

Honestly though, I hope it doesn't come down to that. I hope new council/trustees whatever do better, than what has been happening. But something just seem to be in grid lock (in other words the people making the decisions don't seem to care). Like I said though, I hope that a fork isn't the solution.

Quote:

I like your blogs and the ideas xenoterracide

Thanks, hopefully enough like them to actually implement them._________________I don't hang out here anymore, try asking on http://unix.stackexchange.com/ if you want my help.

edit: See this post below for package.env method which is much better.

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.

Code:

DEBUG_PKGS='sys-libs/glibc some-other/thing'
if hasq "$CATEGORY/$PN" $DEBUG_PKGS; then
pre_pkg_setup() {
local x
for x in installsources splitdebug ; do
if ! hasq "$x" $FEATURES; then
elog "bashrc is adding $x to FEATURES for $PN"
FEATURES+=" $x"
fi
done

Many thanks to zmedico for this, and ofc for the excellent package manager that we know and love, which has built every Gentoo system out there ;-)

Bear in mind the earlier post on the first page; I'd use this for supporting libs/apps, and add -g3 -ggdb for stuff we actually follow. wrt splitting, it's not an issue for stuff compiled via gcc (including C++, Fortran..) but would be for any other compilation system afaik. If you're on 32-bit, you'll want to strip -fomit-frame-pointer (it doesn't have any effect on 64-bit aiui) as in the previous post.

Last edited by steveL on Sat Mar 08, 2014 7:07 pm; edited 1 time in total

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.

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.)

I knocked the above up while I was updating my udev initscript after the last udev upgrade. I wanted udev to start as soon after localmount as possible, and to do that I needed to inspect the dependency tree. Here are some examples:

Code:

$ idepend xdm
/etc/init.d/xdm: depend
need localmount xdm-setup

# this should start as early as possible
# we can't do 'before *' as that breaks it
# (#139824) Start after ypbind and autofs for network authentication
# (#145219 #180163) Could use lirc mouse as input device
# (#70689 comment #92) Start after consolefont to avoid display corruption
# (#291269) Start after quota, since some dm need readable home
# (#390609) gdm-3 will fail when dbus is not running
# (#366753) starting keymaps after X causes problems
after bootmisc consolefont modules netmount
after readahead-list ypbind autofs openvpn gpm lircmd
after quota keymaps
before alsasound

Note that these take standard shell parameters, so you can check multiple initscripts at a time, eg idepend xdm udev and istart /usr/local/etc/init.d/web*.

They also take globs if you quote them so the shell doesn't expand them as files in the current directory. For example ireload 'sys*' here shows me here that out of sysctl, sysfs and syslog-ng, only the last has a reload function, which is ofc what we'd expect, and what that function does. So the last example above would be better handled by putting the directory in the INIT_D_DIR variable at the top and using: istart 'web*' instead.

edit: oopsquote"$1" in _ishow()
change expansion and use a for to handle no parm case correctly
no += in POSIX sh; make the conditions more obvious
try to keep true return

Last edited by steveL on Tue Jan 26, 2016 10:18 pm; edited 4 times in total

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.)

I would suggest using kde-open or xdg-open. These programs would trigger the prefered editor, so you can change the editor without changing any scripts. Actually, they open the application that is specified for the file's type. And since ebuilds appear as "text/plain" files, it should open your default editor.
kde-open is part of kde-base/kioclient and xdg-open belongs to x11-misc/xdg-utils (which is a dependency of kdelibs).

I personally have an alias "open" that maps to kde-open. Hence, I can open folders from terminal via "open /etc/", edit files "open file.txt", view images "open image.jpg"…

I would suggest using kde-open or xdg-open. These programs would trigger the preferred editor, so you can change the editor without changing any scripts. Actually, they open the application that is specified for the file's type. And since ebuilds appear as "text/plain" files, it should open your default editor.
kde-open is part of kde-base/kioclient and xdg-open belongs to x11-misc/xdg-utils (which is a dependency of kdelibs).

Thanks, Swoon, that was excellent advice: I never knew about xdg-open, and it is perfect: no need to worry about backgrounding as it returns pretty quickly after forking off the editor. Plus it's not tied to a DE :-)

I modded to detect whether under X: it's practically at the stage I can use it in update directly :-) [I'll just change it to use PORTDIR, but I don't want the bashrc function to do any kind of lookup for it.] So thanks again, in that respect.

Quote:

I personally have an alias "open" that maps to kde-open. Hence, I can open folders from terminal via "open /etc/", edit files "open file.txt", view images "open image.jpg"…

That sounds handy. I'd want to alias xopen=xdg-open personally, since I'd rather make it explicit that it's tied to X. (I'm a little bit uneasy about clash with open(2) as well, which has a very different semantic. A command like wait has pretty much the same meaning as wait(2).) Any reason you prefer kde-open to xdg-open?

In contrast to the earlier bashrc post, I now use this to add heavier debug info (-g3 -ggdb) to specific packages, and occasionally to turn off default (which uses -g) eg for libreoffice and firefox. I originally used the heavier settings by default, and used to get massive disk bloat with firefox such that it'd run out of space on a 15G partition. (I don't actually use libreoffice any more, but it did too.) No doubt this is to do with -lto (istr it adds it) and asking for all possible debug info; in any event now it takes less than 2G :)

# no -g: apps which take a lot of memory and/or time
dev-libs/boost no-debug.conf
dev-qt/qtwebkit no-debug.conf
kde-base/pykde4 no-debug.conf
www-client/firefox no-debug.conf

# -g3 -ggdb:
# devel.conf

As you can see I'm not bothering with full debug info for anything: I leave it to add for recompiling specific packages, should I want that, and I'll use it for software we develop when we put it in ebuild form.
By default we have enough debug info for backtraces. /etc/portage/make.conf:

I'm not interested in arguing about the flags, but you'd take out the -falign-* ones for a standard setup. They get stripped for packages like gcc and glibc, so we only end up with:
"-O2 -pipe -g -march=native".
I left them in to show how things change with flags you might have, vs debug ones.

--
I like this, however, I also prefer for traffic for my local machine to be seen as local traffic, usually. It depends on the circumstance, but I've had issues in the past with firewall rules and servers. Still it's not hard to move a line or name for your host.

I wouldn't prefer IPv6 for localhost, especially on a LAN where many hosts may not even run it. Maybe that's foolish if you are running a dual-stack on your host. However this is designed to be copied.

So swap the first two lines if you do want to prefer IPv6 for local routing.