View previous topic :: View next topic |
Author |
Message |
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Mon Dec 17, 2007 8:02 am Post subject: |
|
|
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. |
|
Back to top |
|
|
bssteph l33t
Joined: 26 Feb 2003 Posts: 652 Location: Wisconsin
|
Posted: Tue Dec 18, 2007 12:50 am Post subject: |
|
|
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. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Mon Dec 31, 2007 1:42 am Post subject: Reinstalling python |
|
|
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:
Code: | # cd
# tar xzf /usr/portage/distfiles/Python-2.2.1.tgz
# cd Python-2.2.1
# ./configure --with-fpectl --infodir=/usr/share/info/ --mandir=/usr/share/man
# make
# make install prefix=/usr
# rm /usr/bin/python 2>/dev/null
# ln -s /usr/bin/python2 /usr/bin/python |
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.
edit: more up to date packages for amd64 and for x86 are on Patrick's tinderbox.
Last edited by steveL on Fri Sep 19, 2014 1:28 pm; edited 1 time in total |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat Jan 12, 2008 8:29 am Post subject: Using a binhost |
|
|
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
Last edited by steveL on Sun Dec 23, 2012 6:26 pm; edited 4 times in total |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sun Feb 03, 2008 8:53 pm Post subject: How to get a package stabilised |
|
|
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 |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Thu Apr 17, 2008 10:29 am Post subject: |
|
|
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.
Code: | search() { [[ $1 && $1 != *[[:space:]]* ]] && curl -s "http://gentoo.zapto.org/packages/search?description=$1" | html2text -nobs|awk '/results for query/ { i=1 }; (i && $1 != "[Home]") { print }'; } |
Note that it requires network connectivity and thanks to zapto :)
Last edited by steveL on Thu Apr 17, 2008 11:11 am; edited 1 time in total |
|
Back to top |
|
|
XenoTerraCide Veteran
Joined: 18 Jan 2004 Posts: 1418 Location: MI, USA
|
Posted: Thu Apr 17, 2008 10:33 am Post subject: |
|
|
it's all my fault _________________ I don't hang out here anymore, try asking on http://unix.stackexchange.com/ if you want my help. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Thu Apr 17, 2008 11:40 am Post subject: |
|
|
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 |
|
Back to top |
|
|
XenoTerraCide Veteran
Joined: 18 Jan 2004 Posts: 1418 Location: MI, USA
|
Posted: Thu Apr 17, 2008 11:59 am Post subject: |
|
|
Quote: | but don't agree with forking Gentoo |
The nice thing is, you don't have to .
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. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sun Aug 24, 2008 4:20 am Post subject: DEBUG build: the old method |
|
|
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
if ! hasq -ggdb $CFLAGS; then
elog 'bashrc is adding "-ggdb" to CFLAGS for '"$PN"
CFLAGS="$CFLAGS -ggdb"
fi
}
fi
unset DEBUG_PKGS
|
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 |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat Sep 06, 2008 1:36 am Post subject: Getting cron jobs to run as a service |
|
|
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:
Code: | crontab -u apache -e |
|
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Wed Oct 17, 2012 5:53 pm Post subject: FEATURES="buildpkg" / PKGDIR |
|
|
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:
or:
Code: | mkdir -p /usr/portage/packages |
You can also drop packages from binhosts, or set a binhost as above, in the category sub-directory under PKGDIR, should you need to download one to recover with (eg if your backup is bad too.) eg:
Code: | emerge -K =sys-apps/gawk-4.0.2 |
See man emerge for --usepkgonly option.
edit: gawk version
Last edited by steveL on Thu Sep 11, 2014 7:06 pm; edited 1 time in total |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sun Oct 21, 2012 10:32 pm Post subject: Inspecting initscript dependencies |
|
|
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.)
Code: | [[ $- = *i* ]] || return
## init.d functions
# you can add other directories (space-separated) in here
readonly INIT_D_DIR='/etc/init.d'
# show a function from initscript/s (and/or glob/s eg 's*')
ifunc(){
local d f r s=$1 fn="^[[:blank:]]*$1"'\(\)' br='[[:blank:]]*\{'
shift
for d in $INIT_D_DIR; do
for g; do
for f in "$d/"$g; do
[ -f "$f" ] || continue
r=$(sed -En "/$fn($br)?/,/^}/{/^}/q;/$fn$br/n;/$fn/{N;n;};p}" "$f")
[ "$r" ] && printf '%s\n%s\n' "$f: $s" "$r"
done
done
done
}
# convenience wrappers for the common funcs
idepend(){
ifunc depend "$@"
}
istart(){
ifunc start "$@"
}
istop(){
ifunc stop "$@"
}
ireload(){
ifunc reload "$@"
}
icheckconfig(){
ifunc checkconfig "$@"
}
# show the functions defined by an initscript/glob, or all if no args
ishow(){
local d f
for d in $INIT_D_DIR; do
if [ "$*" ]; then
for f; do
[ "$f" ] && _ishow "$d/$f"
done
else
_ishow "$d"/*
fi
done
}
_ishow(){
local f
for f; do
[ -e "$f" ] || continue
grep -H '^[[:blank:]]*[[:alpha:]_][[:alnum:]_]*()' "$f" | {
curr= p=
while IFS=' :' read -r fname func _; do
if [ "$fname" != "$curr" ]; then
[ -n "$curr" ] && echo "${curr##*/}:$p"
curr=$fname p=
fi
p="$p ${func%%'()'*}"
done
[ -n "$curr" ] && echo "${curr##*/}:$p"
} || : # POSIX. zsh: true or: emulate sh; NULLCMD=:
done
} |
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
# Start before X
use consolekit dbus xfs |
To see what functions are in an initscript, use ishow:
Code: | $ ishow xdm
xdm: depend setup_dm vtstatic start stop |
And ifunc to see what a script-specific function does:
Code: | $ ifunc vtstatic xdm
/etc/init.d/xdm: vtstatic
if [ -e /etc/inittab ] ; then
grep -Eq "^[^#]+.*\<tty$1\>" /etc/inittab
elif [ -e /etc/ttys ] ; then
grep -q "^ttyv$(($1 - 1))" /etc/ttys
else
return 1
fi |
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: oops quote "$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 |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sun Oct 21, 2012 10:43 pm Post subject: Viewing an ebuild by name |
|
|
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.)
Code: | # vebuild pkgname | cat/pkg | cat/pkg-version
vebuild() {
local f c=${1%/*} p=${1#*/} cp=${1%%-[0-9]*}
if [[ $p != "${cp#*/}" ]] && [[ $1 != "$cp" ]]; then
f=/usr/portage/$cp/$p.ebuild
[[ -f $f ]] && {
echo "$f">&2
if [[ $DISPLAY ]]; then
xdg-open "$f"
elif [[ $EDITOR ]]; then
$EDITOR "$f"
fi
return 0
}
fi
[[ ${FUNCNAME[1]} = $FUNCNAME ]] && return 1
local a=$(eix -e --format '<bestversion:NAMEVERSION>' "$1")
[[ $a ]] && $FUNCNAME "$a"
}
|
edit: Thanks to Swoon for the lovely xdg-open command which makes the above use your preferred gui editor.
Last edited by steveL on Sat Oct 27, 2012 6:01 pm; edited 1 time in total |
|
Back to top |
|
|
Swoon n00b
Joined: 21 Jun 2003 Posts: 10 Location: Germany
|
Posted: Thu Oct 25, 2012 7:29 pm Post subject: Re: Viewing an ebuild by name |
|
|
steveL wrote: | Code: |
...
kwrite "$f" &
... |
|
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"… |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat Oct 27, 2012 6:11 pm Post subject: Re: Viewing an ebuild by name |
|
|
Swoon wrote: | 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? |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Sat Jul 06, 2013 12:01 pm Post subject: Re: Viewing an ebuild by name |
|
|
Sorry for digging up, but I can't resist:
Swoon wrote: | I would suggest using kde-open or xdg-open. |
Even better: Use zsh with
Code: | autoload -Uz zsh-mime-setup
zstyle ":mime:*" current-shell true
zsh-mime-setup |
Then just enter /path/to/*.txt and have your mime-configured editor started in background with the file... |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat Mar 08, 2014 6:57 pm Post subject: Using package.env for per-package CFLAGS |
|
|
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 :)
current /etc/portage/package.env:
Code: | ## default is: -g -fno-asynchronous-unwind-tables -feliminate-unused-debug-types
# with: FEATURES="splitdebug compressdebug"
# 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:
Code: | CFLAGS="-O2 -pipe -g -march=native -falign-jumps=1 -falign-loops=1 -falign-labels=1 \
-fno-asynchronous-unwind-tables -feliminate-unused-debug-types"
CXXFLAGS="$CFLAGS"
FFLAGS="$CFLAGS"
FCFLAGS="$FFLAGS"
# default: -Wl,-O1 -Wl,--as-needed
LDFLAGS="$LDFLAGS -Wl,--sort-common -Wl,--hash-style=gnu -Wl,-z,relro -Wl,-z,now -Wl,-z,combreloc" |
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.
Here's the actual files:
/etc/portage/env/no-debug.conf
Code: | CFLAGS="-O2 -pipe -march=native -falign-jumps=1 -falign-loops=1 -falign-labels=1"
CXXFLAGS=$CFLAGS
FFLAGS=$CFLAGS
FCFLAGS=$FFLAGS
FEATURES="-splitdebug -compressdebug" |
/etc/portage/env/devel.conf
Code: | CFLAGS="-O2 -pipe -g3 -ggdb -march=native -falign-jumps=1 -falign-loops=1 -falign-labels=1 \
-fno-asynchronous-unwind-tables -feliminate-unused-debug-types"
CXXFLAGS=$CFLAGS
FFLAGS=$CFLAGS
FCFLAGS=$FFLAGS
FEATURES=nostrip |
Note that you can use more than one .conf per package in package.env: it's a space-separated list.
edit: add FEATURES=nostrip to debug.conf
debug.conf -> devel.conf; FEATURES="-splitdebug -compressdebug" to nodebug.conf
Last edited by steveL on Thu May 04, 2017 3:23 am; edited 2 times in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54631 Location: 56N 3W
|
Posted: Sat Mar 08, 2014 7:05 pm Post subject: |
|
|
/me checks in.
New lessons are always welcome _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat Mar 08, 2014 7:13 pm Post subject: |
|
|
Hey Neddy, good to see you :)
We actually crossed posts in another topic as well: I wrote the above up for that, then realised I hadn't put the same info in here, and there you are mentioning exactly the same thing. Hehe.
See you online soon,
igli. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Tue Jun 10, 2014 2:53 pm Post subject: Bridged VM network access |
|
|
Nice succinct setup from schorsch_76:
Code: |
#################################################
# the bridge br0 contains eth0 and tap0
# tap0: virtual machine
# tap1: VPN
# eth0: Network
#################################################
config_eth0="null"
tuntap_tap0="tap"
config_tap0="null"
tunctl_tap0="-t tap0 -u me"
config_br0="192.168.178.19/24"
routes_br0="default via 192.168.178.1"
brctl_br0="setfd 0 sethello 10 stp off"
bridge_br0="eth0 tap0"
depend_br0() {
need net.eth0
need net.tap0
}
| [again not quoting, for clarity]:
In the bridge setup, only the bridge interface has an IP address.
The important thing to remember is, that the tap device and eth0 are in the same bridge, and only the br0 has the IP address.
The tap devices get assigned to the QEMU/kvm VMs. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Tue Jun 10, 2014 3:44 pm Post subject: How to migrate a checked-out subversion repo |
|
|
From a post by Joseph Koshy on the elftoolchain-developers list.
==
You can run svn switch to migrate a checked-out SVN source tree:
Code: | cd /ROOT/OF/YOUR/SVN/CHECKOUT
old=http://elftoolchain.svn.sourceforge.net/svnroot/elftoolchain
new=https://svn.code.sf.net/p/elftoolchain/code/trunk
svn switch --relocate "$old" "$new" elftoolchain-code
|
Developers would need to use a svn+ssh:// URL (and https old for sf):
Code: | old=https://elftoolchain.svn.sourceforge.net/svnroot/elftoolchain
new=svn+ssh://YOURLOGIN@svn.code.sf.net/p/elftoolchain/code/
svn --username YOURLOGIN switch --relocate "$old" "$new"
|
For git-svn users, the 'git-svn-relocate' script may be used to relocate a git-svn repository:
Code: | git-svn-relocate "$old" "$new" |
|
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Wed Jun 18, 2014 3:44 am Post subject: Setting your hostname |
|
|
Great info on setting your hostname by khayyam:
You need to edit /etc/hosts and add the hostname ... eg:
Code: | 127.0.0.1 myhost.lan myhost localhost
::1 myhost.lan myhost localhost |
where myhost is whatever you have set in /etc/conf.d/hostname.
The first entry after 127.0.0.1 will be taken as the FQDN:
Code: | # grep '^127' /etc/hosts
127.0.0.1 myhost.lan myhost localhost
# hostname
myhost
# hostname -f
myhost.lan
|
So the order should follow the above schema.
--
I'm always forgetting to do this when I install, and it's good to show the IPv6 format as well. (Although many people are on an IP4 lan, behind a NAT router.)
krinn made the point, that it's better to set hostname on the interface instead of localhost, like so:
Code: | 127.0.0.1 localhost
::1 localhost
192.168.0.4 beleg.yourdomain beleg
192.168.0.6 faramir.yourdomain faramir
192.168.0.8 hurin.yourdomain hurin
192.168.0.12 aka.yourdomain aka
192.168.0.10 cirdan.yourdomain cirdan
192.168.0.100 router.yourdomain router
|
..so you can easy share all hostnames to your computers in one line [awkified]:
Code: | awk '$1 ~ /^192\.168\.0\./ { print $1 }' /etc/hosts | xargs -I {} echo scp /etc/hosts {}:/etc
| (remove echo to actually run the command.)
--
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. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Fri Jun 20, 2014 5:08 pm Post subject: Update packages by installed filename |
|
|
Great tip from desultory:
emerge -1 /path/to/something/ selects all packages which installed files into that directory as a set to be rebuilt.
It operates analogously given names of individual installed files. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|