Pages

2014-08-16

URxvt, Slackware, Crux = problems

Some of the following is obviously about the same thing as in this post - Compton and Nvidia not getting along. But - not all.

I installed rxvt-unicode (exec: urxvt) as fun and games and novelty to my new Crux 3.1 (Crux home, my Crux install blah: 3.0 -1, 2, 3 and 3.1) and Slackware 14.1 (and my blah). The outcome was somewhat different in those distros.

But first, what it is this urxvt?
In essence, a terminal born from xrvt, with unicode support. And do a simple search 'rxvt+unicode'. At least two pagefuls give extremely relevant tutorials and stuff. Go.
But, just to mention:
- its' conf is in .Xdefaults (or in .Xresources if going more modern)
- it has transparency in two ways. And colors up to 256.
- it's UTF-8, of course,
- tabs and perl-extensions are configurable, among other things.

- It had lag at bottom of terminal (new-line) in both Crux and Slackware. It didn't wrap lines at all in Slackware.
- Doh.

# CRUX
Only problem: new line at the edge of terminal bottom - a lag of 1-2 seconds.
What I have: Nvidia binary driver 331.xx and compiled comtpon-master 20140729.
Problem was solved with remade compton start-line in Openbox autostart:
compton --backend glx --vsync opengl-swc --glx-no-rebind --glx-no-stencil --glx-swap-method 3 --unredir-if-possible --paint-on-overlay --shadow-exclude "! name~=''" --config ~/.compton.conf &
Magical part here is '--glx-swap-method 3'. Other is fluff what I think makes my screen look better. There is also option '--backend xr_glx_hybrid' - BUT, that gave me horrible desktop flickering.

# Slackware (and Salix), Nvidia 319.xx and the same Compton as in Crux
Additionally to lag, there was no line-wrap at all (commmand doesn't brake to next line, but acguires '>' and continues from last char...And then also kinda copies whole text to line above of last command. Very bloody confusing and obviously very wrong.
- Compton conf didn't do a thing,
- Compiling everything with Crux defs - no result,
- Copying other terminal-related confs from Crux - no result.
- Means, nothing I tried worked.

So, in Slackware, I ended up installing xfce4-terminal (deps: libxfcegui4, libxfce4util), and - lag disappeared just like that.

# Ah, yes - when digging in confs - as a bonus, I cracked the mystery of 'different looking man-pages for different users' in Crux. Has to have: export PAGER="most" in all .bashrc files. :)

# General notes about urxvt:
If dealing with .Xdefaults (.Xresources)
- might stick in Xft.dpi: 96 there too, it probably makes the console look a little less hairy.
And those -
Xft.hinting:1
Xft.hintstyle:hintfull


- OB autostart - urxvt in daemon mode goes like that: urxvtd -q -o -f &

- browse all possible settings:
urxvt --help 2>&1| sed -n '/:  /s/^ */! URxvt*/gp'

- Transparencies:
# True:
URxvt.depth: 32
URxvt.background: [90]#000000
# native transpency
URxvt*.transparent: true
! URxvt*.shading: 0 to 99 darkens, 101 to 200 lightens
URxvt*.shading: 110

- Scrollbar. Have to define it, have to place it etc:
# scrollbar style - rxvt (default), plain (most compact), next, or xterm
URxvt.scrollstyle: rxvt
# and so on, look it up.


- what icon you want to see in window corner:
URxvt*iconFile: /home/myname/.icons/mytheme/apps/terminal.png

- tabs. Perl-extension thing. Has to be compiled in.
URxvt.perl-ext-common: default,tabbed
URxvt.tabbed.tabbar-fg: 2
URxvt.tabbed.tabbar-bg: 0
URxvt.tabbed.tab-fg: 3
URxvt.tabbed.tab-bg: 0
URxvt.tabbed.new-button: true


# rxvt-unicode is not bad terminal. BUT, if using real Nvidia driver  + Compton + too-new-xorg, it might not be worth the hassle. There are other terminals available - with no config-wrestling.

# PS! Compton + more new Nvidia driver = more likely there are lag-problems... I just downgraded newest 340 to 331 in Crux - as 340 bloody lagged with everything.

2014-08-10

Icon cache refresh

Sometimes I play with icons - change them or create new ones. And most excitedly, the folder they are in gets broken/unknown icon pics into it after that.
That means - icon-cache needs to be refreshed. Many distros have a script for that which runs on startup. Or something similar - on one way or another, depends on distro and desktop environment.
But if not, one needs to update cache manually.
Basic and primitive way to do this is gtk-update-icon-cache command. That same app is used also by a lot of nice frontends. The command, in terminal, looks like that, in foolproof way:
gtk-update-icon-cache -f -t /path to your icondir - dir where index.theme is
'-f' means force overwrite old cache despite of it state, '-t' means don't worry if there is no index.theme  file.
Dandy. Yeah, but quite frequently not so - and what you get is:
gtk-update-icon-cache: The generated cache was invalid.
You also see that miscreated file starts with '.' - and it's useless as cache.
I happened to have exactly that sad outcome when trying to refresh my icon-theme cache. After exceptionally frustrating googling, I found that - in my case:
- Only thing that mattered (of multiple web-hints), was spaces in icon names. Not existence of icon-size folders, or of index.theme... or something else...
That means, of course, only that I didn't have other possible problems ... if there are more.

Anyway, I got my very big collected icon-theme validated after I removed all spaces from filenames, and nothing else (well, I also checked if my index.theme was correct. It was).

The script below (Thanks to Michael, stackoverflow) looks also to subdirs so, in idea you can run it from /icons or ~/.icons and get every spacy filename switched.
I did it in slow way - as I wanted to know where problems were. I created test-folder and copy/pasted iconfolders to there one by one, and tried to make cache again. Of course, it's easier to change the script to have 'echo' to show which files were changed... in case you are fluent in bash. I'm not, I am outright moron in it. So I did it mechanically, and found that 3 of 12 folders had 'space-problems'.
And here is the script that fixed it:

#! /bin/sh
# Script what finds spaces in filenames and replaces them with _
# to get gtk-update-icon-cache to validate.

# Change this folder according to needs
cd /home/homeros/.icons/test/mimetypes

find . -depth -name '* *' \
| while IFS= read -r f ; \
do mv -i "$f" "$(dirname "$f")/$(basename "$f"|tr ' ' _)" ; \
done
That was that.

2014-08-07

Announcment


As it's obvious, my posting has been somewhat lacking after May.
There are quite simple reasons for that: I seem have reached the last strech of my Linux adventures.
-- I have found two Linux distros I like and keep - Slackware and Crux,
- and so I have lost motivation for more digging around.
-- Also, I do not like at all how modern Linux development turns more and more toward way-of-Windows - sensless bloat, binary blobs, forced unification, idiotic GUI-changes... etc,
- and that means: I am going to try some Bsd's in future (if some of them happen to install this time), but probably not any new Linux distros.

... Might write about some interesting problem (related to those two 'keeper' distros), though.

Crux 3.1, install and so on

# Install is mostly the same as 3.0
- There were slight differences in installable apps - some of them important, see release notes. Also, see Handbook - surprisingly enough, it is corrected for new release (simply, such kind of care is not so common).
So, let's note here some diffrences from 3.0 install:
- fstab (but you still have to fill it out, mostly)
- kernel pre-made conf is more complite/generally-usable.
- network has been split to lo and net scripts, AND those files are already functional.

# Later stuff
. See this and this of Crux 3.0 - a lot went the same way.
What differs:
- prt-get sysup. One update was xorg-server. Dependency 'libepoxy' was not noted and compile failed (but I think it's already fixed). Also, after update xorg-server needs drivers reinstalled (I picked libevdev, evdev, vesa, libva and got X started ok).
- Kernel, as a cautionary tale: Despite I was very eagle-eyed when in kernels' make menuconfig, I still missed my sound driver somehow... doh.
So I thought that I create it as a module. Downloaded alsa-driver (and alsa firmware) packages for make&kmod ... and spent an hour with googling/fixing 'configure' (version.h in wrong folder). And then - it still erred (some ioctl stuff) when 'making'. Fuck. So I went and recompiled the kernel. Took me less than 5 minutes... One reboot, alsactl init and sound appeared. What a waste of time - but superbly educational. Maybe.
- dbus is not installed out of box. Now, I didn't have that problem in 3.0 - which might simply mean that I got it at early stages as dependency... Whatever - it needs to be installed now.
- xdotool. Used Pkgfile this time... and got libxdo also installed.
- man: This time, it worked for root OK, BUT, still not for user (error was different of 3.0). prt-get depinst most - and man started up, colors and all ... for a user, BUT not for root. Strange.
- jdk - version in Pkgfile is wrong, fix it.
- gegl (for gimp), footprint mismatch = delete footprint. And Gimp installed without whining despite threatening text in readme. Check URL in Gimps' Pkgfile - at some point of time it is/was incorrect.
- qpdfview, qbittorrent. Neither could make package (bsdtar: *: Cannot stat: No such file or directory). I couldn't find any reasonable lead for fixing that... As I didn't have such a message with any other (NOT-QT) apps, I tend to guess that it had something to do with QT. But finally, I went for simple 'make' and they installed with no fuss.
- fbreader. Missing libpng15.so.15 , ln -s from ver 16 helped.
About libpng - this new one craps pointless wrong-srgb warning messages to everywhere. Very bloody annoying.
- smplayer not recognising mplayer version-and-stuff. It started but didn't play a thing, no video, no audio. I reinstalled mplayer, installed docutils... did something ... and smplayer started to function. Oh good - but, I really don't know what that was about.

That's it for now. I'm sure there will be more. I haven't finished with apps, and I also have some unresolved errors... like 'cannot ioremap fb base' (nvidiafb) at startup...

All-in-all, I am a bit dissappointed - not sure if more in myself or in nature of Crux. Means, I hoped it goes easier second time around. It didn't.
Summary: My level of Linux plus Crux means that it will remain as my second distro after Slackware. I simply don't have multitude of hours to spade-work in google-piles. The perspective of continuous fixing of results of updates makes me ...depressed.
But - as I really like Cruxs' ideas and choices - it's a keeper without question.