View previous topic :: View next topic |
Author |
Message |
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Mon Jun 23, 2014 2:03 am Post subject: command output |
|
|
to view in a pager.
Code: | lspci -k > ~/lspci.out | to save to a file in homedir.
Code: | lspci -k | wgetpaste -r | to get a pastebin url others can look at, usually on IRC.
I prefer sprunge for pasting, though you need curl installed to use it quickly from the command-line, and wget comes in the stage. Still, sh is quick :)
You put this function in: ~/.bashrc then: sprunge *.c or: cmd.. | sprunge
Code: | sprunge() {
if [ $# -eq 0 ] || { [ $# -eq 1 ] && [ x- = "x$1" ]; }; then
curl -F 'sprunge=<-' http://sprunge.us
else
local f
for f; do
[ -f "$f" ] || continue
echo "Paste of: $f"
curl -F 'sprunge=<-' http://sprunge.us < "$f"
done
fi
} |
It's written to be POSIX sh-compatible, hence the use of [ instead of [[ |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sun Jun 29, 2014 3:17 am Post subject: Switching to eudev |
|
|
Nice little howto from Tractor Girl (as usual quoting directly):
Udev is part of systemd. For now it can be used separately without systemd but its current situation is somewhat blurry and causes constant confusion and problems.
To handle that, gentoo devs created a udev fork: eudev. Eudev is and will be completely independent from systemd.
So if you don't need/want to use systemd and don't want to be bother with crazy stuff on every udev update, you should switch to eudev:
Code: | # to keep sane net-names:
echo 'sys-fs/eudev -rule-generator' >> /etc/portage/package.use
emerge -avC udev
emerge -av eudev
dispatch-conf # or etc-update etc.
/etc/init.d/udev --nodeps restart
# if you use insane net-names, eg during transition, run this:
# rc-update add udev-postmount default |
optionally:
Code: | emerge -av @preserved-rebuild |
==
You may need to remove virtual/udev after removing sys-fs/udev, as "program666" mentioned in the next post ("This fixed everything." ;)
For that I'd use: Code: | emerge -cq virtual/udev | since other apps will depend on it in the tree. (You may well not need to, since the upgrade path is supposed to be working now.)
If you get the error: You're missing a /dev/fd symlink to /proc/self/fd when emerging eudev, then run: Code: | ln -sf /proc/self/fd /dev/fd |
Don't worry nothing will be broken so long as you don't reboot or crash in-between removing udev and emerging eudev. The virtual will be reinstalled as soon as you emerge something that needs it (world will do); it'll be satisfied by eudev.
Don't forget to run dispatch-conf (or w/e you use to etc-update.) I've put it in immediately after above, but you may need to run it after restart (I haven't switched yet. Will do soon:) Just be sure you've checked it to your satisfaction, before reboot.
edit: /dev/fd symlink to /proc/self/fd; run dispatch-conf after installing eudev, explanation.
USE: -rule-generator, no need for postmount
Last edited by steveL on Thu Oct 23, 2014 12:35 am; edited 6 times in total |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Sun Jun 29, 2014 9:11 am Post subject: Re: Switching to eudev |
|
|
steveL wrote: | The virtual will be reinstalled as soon as you emerge something; it'll be satisfied by eudev. |
Although most gentoo users will know, one should perhaps point out that you do not have to worry if the virtual is not reinstalled. There are many reason why this might not happen (e.g.: nothing depends on it, the emerged package does not depend on it, etc.) Nothing bad happens if a virtual is not installed. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Tue Jul 22, 2014 4:04 pm Post subject: Using git from cli |
|
|
Just my git setup, in case I need to recover it sometime.
I use the command-line (F12 for yakuake which rocks) for most things, and kdiff3 as my git difftool. Normally I view the history with gitview, especially before I push as it shows it in a different context. I'm lazy so I do this via sh aliases instead of git ones (these are from my ~/.bashrc file):
Code: | alias status='git status'
alias branch='git branch'
alias vbranch='git branch -lvv'
alias co='git checkout'
alias add='git add'
alias unadd='git reset HEAD'
alias gdiff='git diff'
alias staged='git diff --staged'
alias vdiff='git difftool -y'
alias vstaged='git difftool -y --staged'
alias ddiff='git difftool -d --no-symlinks'
alias commit='git commit'
alias merge='git merge --ff-only'
alias pull='git remote update -p; git merge --ff-only @{u}'
alias lol='git log --oneline --graph --decorate --all'
alias view='gitview --all 2>/dev/null &' |
and this is my ~/.gitconfig; I'm including it all (apart from [user]) as the colour stuff and ps viewer is useful, and you might get some ideas for other things. Really you just need to run Code: | git config --global diff.tool kdiff3 | to make the aliases using git difftool above work. You very likely don't want pack.threads setting: I find it useful as I'm on an old core2-duo.
Code: | [core]
excludesfile = $HOME/.gitignore
abbrev = 12
[pack]
threads = 0
[diff]
tool = kdiff3
[difftool]
# prompt = 0
# default = current - push to same name, upstream @{u}, simple @{u} if same name, never
# simple is new default in 2.0; 1.x+ was: matching = all branches with same name
[push]
default = simple
# only allow linear pull (= fetch + merge.)
# NOTE merge of branches (ie: annotated tags) normally:
# default: ff = true # attempt to ff, merge if not, ie:
# git merge --no-ff # fork.
# manual setting forces reflection.
[merge]
ff = only
[branch]
# track (git pull merges from starting branch) if branching from:
# true = remote, always = local + remote, false
# writes: merge = refs/heads/foo for branch: foo
autosetupmerge = false
# use: git push --set-upstream origin foobar
# rebase when merging, from remote (= . for local) ie upstream
# if tracking: branch -t local, git clone/fetch new remote
# never, local, remote, always
autosetuprebase = local
# for local tracking branches, to push back to server:
# git config branch.foo.pushremote origin
[rerere]
enabled = true # store resolved rebase steps even when aborted
[alias]
unadd = reset HEAD
up = "!git remote update -p; git merge --ff-only @{u}"
# show postscript diffs via util, mark as binary
# http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
[diff "ps"]
textconv = ps2ascii
binary = true
# see https://github.com/grosser/dotfiles/blob/master/gitconfig
[color]
ui = auto
branch = auto
diff = auto
status = auto
[color "branch"]
current = green
local = blue
remote = yellow
#normal status has added/changed = green untracked/deleted/conflic = red -> more colors
[color "status"]
added = green
changed = yellow
untracked = cyan
[color "diff"]
whitespace = cyan
[pager]
color = true |
Also, you likely don't want the branch stuff, but I quite like forcing merges to ff-only, as it means by default everything is linear, and true merges only happen when I explicitly git merge --no-ff (which I haven't had to do yet, as it's only small-team projects.) It's important for pulls, which are defined as fetch followed by merge; hence the git up alias from the web, which I just run directly via pull in terminal. The lol (log one-liner) alias is handy too; I got it from someone in the #git channel on IRC chat.freenode.net, which I highly recommend.
Similarly, the abbrev = 12 set with Code: | git config --global core.abbrev 12 | I find useful for pushing specific commits, selected from the branch history in lol, eg: Code: | git push origin $SHA_ID:master | In such cases I feel more confident with more hex digits.
kdiff3 works really well; typically I just use vdiff somefile to review what I've been working on before, which shows me the whole file, instead of the standard coloured diff in terminal, which I use more before committing stuff I've just written. git diff --staged (staged or vstaged alias) really helps to review the commit before you move on to the next one; you can still tweak it after view, and commit --amend.
Also, I always use add -p to make better commits, in preference to rebasing after the event, which i find trickier to reason about; and anyway I'd like to avoid rebasing as a work habit. There's no real benefit to spending time editing, moving and squashing commits to "package" feature changes ime. Just do those on a separate rebased branch if it matters, and use the vcs to record your actual workflow, as it's about the work and the results, not presentation of a manufactured history. Smaller commits may be interrelated, with other commits in-between, but because they're smaller, they're easier to review, if someone really does care.
And if not, whom are we packaging it for anyway? Posterity? lul. They're more likely to be looking at the actual code, and git blame if it matters, and from what I've read people tend to be more interested in how code was actually written, when looking historically; which let's face it, isn't going to be a factor for most of our code. ;)
edit: git config --global
edit: Sometimes I'm tired, and forget the basics, especially for commands I don't use often.
Setting up a new repo (if you use a different email address eg: for FLOSS projects vs work), check: Code: | git config --get user.email | and set with: Code: | git config --add user.email nick@example.com | though usually I just edit the config to put in settings as above, from another repo config file.
git config -l to see what's happening (note that later settings are from your local repo config), then review the .git/config (where .git may be a --separate-git-dir.)
Last edited by steveL on Wed Dec 09, 2015 4:09 am; edited 2 times in total |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Mon Sep 08, 2014 11:57 pm Post subject: vmlinuz and initrd.img |
|
|
A user in #gentoo, coming from another OS, wanted to know: where the vmlinuz and initrd.img files on a Gentoo minimal install .iso (amd64) are:
iamben wrote: | in isolinux/gentoo (kernel) and isolinux/gentoo.igz (initramfs)
See isolinux.cfg for what kernel parameters are passed. |
Latter is in reference to "Could not find the root block device in ." during boot.
May seem obvious, but could help someone down the road; iamben is always on the ball, ofc. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Thu Sep 18, 2014 1:49 pm Post subject: vm.swappiness |
|
|
Great tip from Yamakuzure (direct quoting, as usual):
Code: | $ grep -A 1 -B 1 vm.swap /etc/sysctl.conf
# Reduce swappiness from server like 60 to 32GB RAM notebook 0
vm.swappiness=0
vm.vfs_cache_pressure=50 |
Note: swappiness=0 does not mean that swap is disabled.
A value of 0 instructs the kernel not to initiate swap until the amount of free and file-backed pages is less than the high water mark in a zone.
Current memory state: |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Wed Sep 24, 2014 5:53 pm Post subject: Switching to MATE |
|
|
Gnome3 crapfest getting you down? Tired of trying to keep it off your machine and still retain some semblance of a Unix? Fed up of an interface that is nowhere near as useful as Gnome2?
Tony0945 writes:
If you search the forum, you will find several threads on converting to Mate with masks posted. I participated in several of those threads, but on the final machine that I converted, I just removed all the gnome use flags, changed profile from Gnome to plain Desktop (very important), emerge'd -C anything from gnome, --depclean, then unmasked and emerge'd Mate which brought several things back. I don't know if I can really recommend that approach, but it was simple. If you have a lot of customization in Gnome, I'd look for more expert advice than mine.
If you don't need remote login, I recommend SLiM, http://wiki.gentoo.org/wiki/SLiM. That will give you the chance to choose your desktop at each login.
Personally, I've gone back to vanilla XDM as I run only Mate now and sometimes do remote login with XDMCP.
==
wrt "expert advice": try #gentoo and #gentoo-desktop as well as #mate on IRC: chat.freenode.net (in addition to the forums.) |
|
Back to top |
|
|
depontius Advocate
Joined: 05 May 2004 Posts: 3522
|
Posted: Wed Sep 24, 2014 7:28 pm Post subject: Re: Switching to MATE |
|
|
steveL wrote: |
Personally, I've gone back to vanilla XDM as I run only Mate now and sometimes do remote login with XDMCP.
|
I'm still using some carefully masked GNOME libraries, because...
gnucash pulls in some GNOME bits'n'pieces.
I like gthumb for my photos, as does my wife.
I currently need gdm:
1 - It does autologin for my wife on her machine, making it appliance-like for a better W.A.F.
2 - It manages to allow remote X connections - too many display managers imply "-nolisten tcp" with no easy way to change.
3 - On occasion I actually do use XDCMP.
4 - I like reboot/shutdown controls on the login screen.
From what I can tell, gdm is the only one that does all 4 - I'd be happy to have something else and get rid of as much GNOME as I can. I have in the past had a tk hack that added reboot/shutdown buttons to xdm, but lost them somewhere along the way, nor am I sure how to do XDCMP with xdm.
If you've got a tip for this, I'm all ears. _________________ .sigs waste space and bandwidth |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat Sep 27, 2014 7:02 pm Post subject: |
|
|
@depontius: I don't use GNOME so can't advise; was hoping tony0945 might respond. I recommend starting a new topic for it in Desktop Environments. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Wed Jan 07, 2015 2:19 am Post subject: Using PARTUUID to specify root device |
|
|
From Donahue and NeddySeagoon in this topic:
To specify the root device on the kernel command-line use
where foo is a PARTUUID from which gives output like: Code: | /dev/sdc1: LABEL="OCZ128" UUID="f7bd2bec-3688-4336-8c63-e6921ae5e3bf" TYPE="reiserfs"
PARTLABEL="OCZ128" PARTUUID="89bc9633-fbc9-4a90-8a67-e058cb655d95" | without quotes, so the above would give a kernel-parm of: Code: | root=PARTUUID=89bc9633-fbc9-4a90-8a67-e058cb655d95 |
This works with MSDOS Partition tables too.
==
PARTUUID is preferable because it's kernel-level, and doesn't require any interaction with the filesystem, so it's more robust.
Unless you have specific esoteric needs, in which case you know about it, I'd recommend this.
Though I'd also recommend building in the drivers for your rootfs (ext4 handles ext2/3 partitions as well), and motherboard PCI and hard-disk controllers, to the kernel unconditionally when you install. This usually means you can simply specify /dev/sda and sdb etc.
But if you have races at bring-up, consider PARTUUID before you look at label-based solutions. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sun Feb 15, 2015 1:15 pm Post subject: Getting steam to use alsa |
|
|
And more broadly SDL; info from Naib, not quoting/edited a bit, as usual:
Since steam uses SDL, it will by default use pulse.
You can override that with SDL_AUDIODRIVER=alsa
The steam runtime ships with libpulse, but does not require pulse to run.
==
So you might put in /etc/bash/bashrc for the system: Code: | export SDL_AUDIODRIVER=alsa |
Though I think you'd be better off if you add a new file in /etc/profile.d/:
Code: | mkdir -p /etc/profile.d
echo 'export SDL_AUDIODRIVER=alsa' > /etc/profile.d/sdl-alsa.sh |
Those are read by /etc/profile (a shell-script) at the bottom.
Another option is to use /etc/env.d/: Code: | echo 'SDL_AUDIODRIVER=alsa' > /etc/env.d/99sdl-alsa |
And run env-update (or reboot.)
Though that's more distro-level; profile.d is better for local-admin, imo.
You might want to use the above if you're running a centralised setup, though. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Sun Feb 15, 2015 2:33 pm Post subject: Re: Getting steam to use alsa |
|
|
steveL wrote: | Another option is to use /etc/env.d/ |
/etc/env.d is usually not CONFIG_PROTECT'ed. I would even go one level highter /etc/portage/env/media-libs/libsdl wrote: | post_src_install() {
einfo "local additions to /etc/env.d"
echo 'SDL_MOUSE_RELATIVE=0' >50sdlmouse || die
echo 'SDL_AUDIODRIVER=alsa' >50sdlsound || die
doenvd 50sdlmouse 50sdlsound || die
} | and then reemerge libsdl. (I added SDL_MOUSE_RELATIVE=0, because I realized that most sdl games behave strange without this) |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sun Feb 15, 2015 4:51 pm Post subject: Re: Getting steam to use alsa |
|
|
mv wrote: | /etc/env.d is usually not CONFIG_PROTECT'ed. I would even go one level higher.. |
Yeah I was just thinking it should be done as part of ebuild.
Didn't realise we could put bash function def'ns in portage/env (though it makes sense in bash terms, I thought that was read by python shlex, which only supported variables, so we had to use bashrc instead.) nice :)
Quote: | and then reemerge libsdl. I added SDL_MOUSE_RELATIVE=0, because I realized that most sdl games behave strange without this |
Ah good one, thanks. I think I might just shove that in an overlay (we can select env for overlay in same way as on system, on newer portage. I'd still like the same for bashrc.) If needs be, I'll patch the ebuild, just so I don't have to bother about separate files. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Wed Apr 01, 2015 7:59 pm Post subject: Debugging under EFI |
|
|
Nice tip from Ant P on viewing crash logs under EFI:
Enable pstore and efivars pstore backend in the kernel, then next time it hangs you can reboot, mount /sys/fs/pstore and get the dmesg log from when it crashed |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Wed Apr 01, 2015 8:07 pm Post subject: Stages 1 and 2 in a chroot |
|
|
Lovely set of instructions from NeddySeagoon:
You can make a i586 hardened tarball from an i686 one. You need a i686 host to do it though.
Your [i3/core2 etc] should do nicely. The process is just like a stage1 install, except you will do it in a directory.
On your i686 host, make a directory called /home/<me>/hardened-i586
Untar the hardened i686 tarball here.
Do the chroot preparation steps but do not chroot yet.
If the host is gentoo, bind mount /usr/portage at /home/<me>/hardened-i586/usr/portage because there is no point in getting another copy of the portage tree and more distfiles.
Take care to put the i586 /usr/portage/packages at say, /usr/portage/packages-i586, since you don't want to overwrite /usr/portage/packages for the host.
In make.conf (in the chroot: ie /home/<me>/hardened-i586/etc/portage/make.conf) change the CHOST to be correct for a i586
Set CFLAGS for your [target machine=runtime CHOST in the root]. You MUST NOT use -march=native
Set any USE flags to your taste to save rebuilds later.
run emerge --sync to ensure your tree is up to date.
Now you can get into the chroot.
Check make.conf - this is a good time to discover that you have edited make.conf on the host :)
Execute the script /usr/portage/scripts/bootstrap.sh
This will build the toolchain for your new CHOST. This is actually the stage1 from a stage1 install.
You need to run this in one go as it can't be resumed.
Select your compiler - it should have i586 in its name now.
Run to rebuild all of the system set packages using your new CFLAGS.
This is the step that corresponds with stage2
Once that completes you have a hardened-i586 in the location where you started with a i686 tarball.
If you wish, you can build more packages now.
When you are done, exit the chroot, umount all the external things mounted inside /home/<me>/hardened-i586, then tar it up. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Tue Aug 18, 2015 11:34 am Post subject: package.* directories [Tweaking your install] |
|
|
Taken from dufeu's excellent post; as usual not quoted (+ minor edits) for readability.
==
The 'need' is a place to define custom additions/exceptions for portage values reflected in but not limited to:- package.use
- package.mask
- package.keywords
- package.unmask
- package.license
By default, new installations have all of these custom portage variable lists, as files under /etc/portage/
You have the option of creating any or all of these as directories instead and moving the files themselves to their corresponding directories, eg: Code: | cd /etc/portage
mv package.use use && mkdir package.use
cp -p use package.use/base | You can use w/e file name you like instead of 'base': they're read in (ASCII) alphabetical ordering, so earlier is likely better if you're adding overrides.
When you set your portage variable lists under directories, all the files in each directory will be processed for additions/exceptions for each category {use, mask, unmask, keyword etc.}
Now why would you want to do this?
There are two very good reasons for moving from single category list files to list directories.- 'emerge' has had the ability now for a while to recommend and automatically update your custom portage value lists. When you set it up to do that, it will include a lot of 'comment' information telling you what it did.
- You'll also find that the older your gentoo installation gets, the more custom additions/exceptions portage values you'll accumulate because of personal desires and on-going package changes.
It gets very old very fast scrolling through pages and pages of 'package.use' and 'package.mask' trying to figure out what you did or to untangle deprecated values.
[ed: Although you should regularly review and remove any cruft, especially versioned atoms which no longer apply.]
I've converted all my value list files to directories. To make this whole issue very clear, here is an example of what one of my new installs looks like: Code: | # ls -l /etc/portage/package.use/
total 56
-rw-r--r-- 1 root root 75 Mar 15 07:59 calibre
-rw-r--r-- 1 root root 33 Mar 14 14:06 fs
-rw-r--r-- 1 root root 33 Feb 22 13:06 iputils
-rw-r--r-- 1 root root 59 Jun 7 07:28 kde
-rw-r--r-- 1 root root 112 Mar 15 18:45 lxqt
-rw-r--r-- 1 root root 505 May 12 15:07 media
-rw-r--r-- 1 root root 188 Mar 24 06:29 misc
-rw-r--r-- 1 root root 166 Apr 8 17:43 network
-rw-r--r-- 1 root root 23 Apr 6 10:02 office
-rw-r--r-- 1 root root 38 Mar 24 06:04 qt
-rw-r--r-- 1 root root 82 Jun 30 06:31 samba
-rw-r--r-- 1 root root 24 Mar 13 13:31 system
-rw-r--r-- 1 root root 206 Apr 6 09:24 temp
-rw-r--r-- 1 root root 217 Mar 14 23:20 tools |
Code: | # cat /etc/portage/package.use/calibre
>=dev-qt/qtwebkit-5.4.1 printsupport
>=dev-lang/python-2.7.9-r2:2.7 sqlite |
Code: | # cat /etc/portage/package.use/office
media-gfx/nomac opencv |
Code: | # cat /etc/portage/package.use/samba
net-fs/samba aio client syslog winbind
>=app-crypt/heimdal-1.5.3-r2 -ssl -threads |
Code: | # cat /etc/portage/package.use/temp
# =gnome-base/librsvg-2.40.9 -tools
# =dev-java/icedtea-bin-7.2.5.3 -cups -X -nsplugin
# =media-libs/libjpeg-turbo-1.4.0 -java
# =net-libs/glib-networking-2.42.1 -libproxy
# =dev-vcs/subversion-1.8.11 -kde |
Code: | # cat /etc/portage/package.use/tools
dev-util/cmake -qt5
>=dev-libs/libpcre-8.36 pcre16
sys-apps/hwloc plugins
app-arch/p7zip rar
>=dev-vcs/subversion-1.8.11 -dso
x11-terms/qterminal -qt4
x11-libs/qtermwidget -qt4
app-portage/layman bazaar cvs mercurial |
As you can see, my 'use' values are organized and grouped as makes sense to me. I use the 'temp' list as a placeholder for values I need temporarily in order to do things like complete an 'emerge @world', or I find a package which is borked in some way and I have to wait until it's either fixed by upstream or perhaps for some gentoo-dev package-maintenance love. ;)
Using explicit value lists or directories is your choice and you can mix and match them as makes sense for you. Generally, I make 'package.use', 'package.mask', 'package.keywords' and 'package.unmask' be directories. The rest remain lists.
I hope this gives you a better understanding and context regarding your options here. :)
Note that when you add to a file, eg:
Code: | # echo 'kde-apps/kde4-l10n minimal' >> /etc/portage/package.use |
you MUST use two right-angled bracket symbols to add to your list and not overwrite it!
On my systems which follow the example above, I executed this: Code: | # echo 'kde-apps/kde4-l10n minimal' >> /etc/portage/package.use/kde |
==
As stated, you don't have to switch to directories, but it helps with overlays which ship files for such directories, and crossdev requires it. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Wed Dec 16, 2015 6:14 pm Post subject: Gentoo releng keys (pre-install) |
|
|
I recently ran out of inodes on /usr/portage so needed to reinitialise the tree after I'd reformatted.
(It was originally built with -b 1024 -N 200000 several years ago, but it turns out we get more inodes, and more filesystem blocks with the defaults.)
This post is an amalgamation of the wiki pages on initialising webrsync and the handbook instructions in case I need to do this again (we've done similar in installer.)
Thanks to mira(bilos) for more detailed info wrt gpg.
The issue here is that you can't emerge anything, including app-crypt/gentoo-keys, until you have the portage tree; again, exactly like installation time.
Firstly I had to find where the releng pages moved to, and then I was curious because the key id didn't match anything on that page (there used to be a key of 0x239C75C4 according to the script)
Code: | $ md5sum -c portage-20151215.tar.xz.md5sum
portage-20151215.tar.xz: OK
$ gpg --verify portage-20151215.tar.xz.gpgsig portage-20151215.tar.xz
gpg: Signature made Wed 16 Dec 2015 00:57:34 GMT using RSA key ID C9189250
gpg: Can't check signature: No public key |
So anyhow let's proceed with pulling the gpg key, id as per-the page and the wiki articles.
I found that subkeys.pgp.net was unresponsive, though I could ping it, whereas keys.gnupg.net mentioned in the GPG wiki article had quick ping times and responded instantaneously:
Code: | # mkdir /etc/portage/gpg
# chmod 0700 /etc/portage/gpg
# gpg --homedir /etc/portage/gpg --keyserver keys.gnupg.net --recv-keys 0xDB6B8C1F96D8BF6D
gpg: requesting key 96D8BF6D from hkp server keys.gnupg.net
gpg: /etc/portage/gpg/trustdb.gpg: trustdb created
gpg: key 96D8BF6D: public key "Gentoo Portage Snapshot Signing Key (Automated Signing Key)" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1) |
The other aspect is that you do not need to fully nor ultimately trust the key to verify the signature.
The webrsync page shows the user ultimately trusting it (5), and the handbook uses full (4); I started with the minimal level of trust to check (3 for marginal.)
You can always pass --trusted-key to those gpg invocations that need it, should that come up, ideally with GNUPGHOME set (default: ~/.gnupg) implying no need to trust(db) at all.
You can see the subkey C9189250 comes in here for automated use:
Code: | # gpg --homedir /etc/portage/gpg --edit-key 0xDB6B8C1F96D8BF6D trust
gpg (GnuPG) X.Y.Z; Copyright (C) 2XXX Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
pub 4096R/96D8BF6D created: 2011-11-25 expires: 2016-07-01 usage: C
trust: unknown validity: unknown
sub 4096R/C9189250 created: 2011-11-25 expires: 2016-07-01 usage: S
[ unknown] (1). Gentoo Portage Snapshot Signing Key (Automated Signing Key)
pub 4096R/96D8BF6D created: 2011-11-25 expires: 2016-07-01 usage: C
trust: unknown validity: unknown
sub 4096R/C9189250 created: 2011-11-25 expires: 2016-07-01 usage: S
[ unknown] (1). Gentoo Portage Snapshot Signing Key (Automated Signing Key)
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision? 3
pub 4096R/96D8BF6D created: 2011-11-25 expires: 2016-07-01 usage: C
trust: marginal validity: unknown
sub 4096R/C9189250 created: 2011-11-25 expires: 2016-07-01 usage: S
[ unknown] (1). Gentoo Portage Snapshot Signing Key (Automated Signing Key)
Please note that the shown key validity is not necessarily correct
unless you restart the program.
gpg> save
Key not changed so no update needed. | You can just 'quit' if you used the trust parm.
So a quick check to verify the import:
Code: | # gpg --homedir /etc/portage/gpg --list-keys
gpg: checking the trustdb
gpg: no ultimately trusted keys found
/etc/portage/gpg/pubring.gpg
------------------------------
pub 4096R/96D8BF6D 2011-11-25 [expires: 2016-07-01]
uid Gentoo Portage Snapshot Signing Key (Automated Signing Key)
sub 4096R/C9189250 2011-11-25 [expires: 2016-07-01] |
And finally we can verify the signature on the tarball:
Code: | # gpg --homedir /etc/portage/gpg --verify portage-20151215.tar.xz.gpgsig portage-20151215.tar.xz
gpg: Signature made Wed 16 Dec 2015 00:57:34 GMT using RSA key ID C9189250
gpg: Good signature from "Gentoo Portage Snapshot Signing Key (Automated Signing Key)"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: DCD0 5B71 EAB9 4199 527F 44AC DB6B 8C1F 96D8 BF6D
Subkey fingerprint: E1D6 ABB6 3BFC FB4B A02F DF1C EC59 0EEA C918 9250
# echo $?
0 | The cmd exit status, which is what we'd use in scripts, shows it worked with the warning.
And finally, to wrap up this use-case: Code: | # tar -xvJf portage-20151215.tar.xz -C /usr |
I imagine we'd want the "Gentoo-keys Team Signing key" as ultimately trusted in a setup using /etc/portage/gpg, with the signing key fully-trusted, as the trustdb is local to the $GNUPGHOME; but then we'd use app-crypt/gentoo-keys once we've actually got a signed tree snapshot verified and untarred, which means keys under /var/lib/gentoo/gkeys: Code: | gpg --homedir /var/lib/gentoo/gkeys/keyrings/gentoo/release --with-fingerprint --list-keys | per the wiki.
Still, something to bear in mind if you don't like the keys being silently updated whenever the package is, which I'd guess is the reason not to put them under /etc (dispatch-conf on key changes.)
If you know better (about anything) holler, as ever.
I have a feeling this is about to be obsoleted wrt sync-via-git, but key-import is still needed to verify the stage3[1], and once I'm updated to newer portage, I think I'll try the webrsync module, for which the above approach seems to be correct initialisation.
[1] 0xBB572E0E2D182910 "Automated Weekly Release Key": Code: | pub 4096R/2D182910 2009-08-25 [expires: 2017-08-25] |
|
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Mon Dec 21, 2015 12:55 am Post subject: copy git tags |
|
|
More bashrc git-fu; I didn't get any feedback with a better way to do this in #git. If you know one, feel free to share.
The issue is we want to preserve the original committer timestamp, to keep ordering. Given that, we might as well preserve the identity, though ofc we cannot sign any tags as them.
A couple of util functions first. Note this is written to work in sh, and it only copies the first line of any message.
~/.bashrc: | # Public-domain, or where not recognised:
# MIT/BSD-2 (C) 2015 Steven J. Long.
err() {
printf '!! %s\n' "$*" >&2
}
warn() {
printf '! %s\n' "$*" >&2
}
# cp_tag 0.14 fubar-0.14
cp_tag(){
[ -n "$1" ] && [ -n "$2" ] || return
[ "$1" = "$2" ] && return 2
local tag cid oid tstamp user email data
cid=$(git describe --long "tags/$1") || { err "cp_tag '$1': not found"; return 100; }
tag=$(git describe --long "tags/$2" 2>/dev/null) && { "cp_tag $*: dupe tag: '$tag'"; return 2; }
case $cid in
"$1"-0-g*) cid=${cid#"$1"-0-g}
;; *) err "cp_tag '$1': not a defined tag?${cid:+ [$cid]}"; return 120
esac
data=$(git_tagdata "$1") || { err 'cp_tag: unexpected tag format?'; return 123; }
{ IFS=' ' read -r oid tstamp email user
read -r; msg=$REPLY
} << EOF
$data
EOF
case $oid in
"$cid"*):
;; *) err "cp_tag $1: git error? cid '$cid' does not match object: '$oid'"; return 120
esac
# git commit-tree strips '<', '>' (and '\n')
if GIT_COMMITTER_NAME="$user" GIT_COMMITTER_EMAIL="$email" \
GIT_COMMITTER_DATE="$tstamp" git tag "$2" "$oid" ${msg:+-m "$msg"} \
&& tag=$(git describe --long "tags/$2"); then
case $tag in # described wrt existing tag $1 in testing
"$1-0-g$cid"|"$2-0-g$cid") return 0
esac
err "cp_tag $1 $2: git error? new tag $2: does not match cid: '$cid'"
warn ": git describe --long tags/$2 => $tag"
else
err "cp_tag: unable to tag '$2'"
fi
return 120
}
git_tagdata(){
git cat-file -p "tags/$1" | awk '/^object / && cid == "" { cid = $2 }
# tagger user blah name <email.addr> ts tz
/^tagger / && NF > 4 { if (cid == "") exit
tz = $NF; ts = $(NF - 1); email = $(NF - 2)
u = $2
for (i = 3; i < NF - 2; ++i)
u = u " " $i
printf("%s\t%s %s\t%s\t%s\n", cid, ts, tz, email, u)
do {
if (0 >= getline) {
$0 = ""
break
}
} while (! NF)
print (/^----/? "": $0)
f = 1
exit
}
END { exit(!f) }'
}
mv_tag(){
cp_tag "$1" "$2" && git tag -d "$1"
}
# eed "$file" '/^funcname/-2;/^}/+1p'
eed() { local f; f=$1; shift; printf '%s\n' H "$@" | ed -s "$f"; }
# SCNR ;) |
|
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat Feb 20, 2016 2:56 pm Post subject: Clean up tmux sessions after update |
|
|
<Griz64> the bot was down and when i tried to get in, i found tmux had been updated and it was a bit of a chore.
Code: | $ pgrep tmux
3179
$ /proc/3179/exe attach |
You can attach to the old binary, kill the bot, exit the shell nicely and start the "New & Improved" version, then restart the bot. |
|
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
|
|