I have had this machine running for about a month now, so I have rebooted a few times. That solved my problem though. Thanks a lot for responding so promptly Mark. On 6/21/07, Mark Rosenstand <mark@borkware.net> wrote:

On Thu, 2007-06-21 at 18:08 -0400, voltaic wrote:

...

Hello everyone,

I just recently installed CRUX 2.3 on one of my machines, and noticed that Xorg does not "see" the TrueType font Bitstream Vera. When I say it doesn't see it I mean the output of xlsfonts does not list that font ( i.e. -bitstream-bitstream vera sans mono-bold-r-normal--30--75-75--*-iso8859-1 and others).

On a different machine with CRUX 2.2 the font worked fine, but that was with Xorg 6.9. I have been looking around google a lot, but I'm not getting anywhere. My configuration is as follows:

- The package xorg-font-bitstream-vera is installed. - I verified that the files for that font exist in /usr/lib/X11/fonts/TTF/. - I also verified that "freetype" is installed, and loaded in the "modules" section of my xorg.conf. - The correct font directory is also included in xorg.conf (FontPath "/usr/lib/X11/fonts/TTF/").

Am I missing something?

Individual applications such as Abiword or Firefox can use Bitstream Vera fine. The problem is specific to applications such as xosd that depend upon Xorg's access to the fonts.

Any help would be greatly appreciated.

Have you run mkfontdir/mkfontscale on said directories?

Due to pkgutils' lack of support for scriptlets this has to be run by hand (but is worked around by adding another bootscript in CRUX 2.3, so if you haven't rebooted after installing X, this could be why.)

Fixing this properly by adding post-install scriptlet support to pkgutils shouldn't be too much work, but I estimate that most CRUX'ers don't want that feature. IMHO, it should either be done properly or not at all; using a boot script to do package scriptlets is just too broken.

On Thursday 21 June 2007 10:41:02 pm Chris Pemberton wrote:

I looked at /etc/rc.fix and I read it as follows:

For (every directory in /usr/lib/X11/fonts/) { if (fonts.dir is missing) { run mkfontdir; run mkfontscale; } {

So adding more fonts to an *existing* directory in /usr/lib/X11/fonts/ will *not* trigger mkfontdir and mkfontscale..

On the flip side, if a *new* directory is added in /usr/lib/X11/fonts/, then mkfontdir and mkfontscale will run in that directory.

The mkfontdir man page says the first line in fonts.dir is the number of fonts in that directory. So, could we simply check to see if the number of fonts in the directory has changed, and if so, run mkfontdir and mkfontscale?

Or even better, we could compare the mtime of the font directory with the mtime of the fonts.dir file. If a font is added/removed from the directory without running mkfontdir, the mtime of the directory will be newer than the fonts.dir file: if [ -d /usr/lib/X11/fonts ]; then for i in `/bin/ls -d /usr/lib/X11/fonts/*`; do if [ 0"`stat -c %Y $i/fonts.dir 2>/dev/null`" -lt 0"`stat -c %Y $i`" ]; then mkfontdir $i &> /dev/null mkfontscale $i &> /dev/null fi done fi This will work even if you add and remove fonts without changing the number of fonts at the end (as opposed to the first line solution). I don't even have this script in my system, because I haven't updated my "rc" package in ages (too many customizations), neither the "filesystem" package, because it just looks scary. I don't mind updating glibc though ;) If we are going to update the "rc" package, may I propose some enhacements: Transforming the SERVICES array to a list. I mean: -SERVICES=(net crond) +SERVICES="net crond" Then we could change the interpreter from /bin/bash to /bin/sh in every rc script, and make /bin/sh a symlink to /bin/mksh. mksh is faster and requires less memory than bash. I think bash should only be used for interactive shells, or only if really needed. If we are making mksh the default /bin/sh, we should also change the interpreter in ldd to bash, since that really requires bash. These changes are one of the first things I do whenever I install a new system. There are no drawbacks, only benefits: faster shellscripts, fewer memory usage, and most important, it will make arnuld happy ;) -- Alan Mizrahi

On Fri, 22 Jun 2007 12:48:05 +0200 treach <treachster@gmail.com> wrote:

On a sidenote to this, I'd like to mention something I though of recently, however, irc gave no real feedback, so here I go again.

First of all prtcreate really does the wrong thing when it creates templates for a new Pkgfile, since it sets source=(), rather than source="". This is a two character fix to the script, and causes no problems at all AFAIK.

The second thing I'd like to suggest is that prtverify starts to issue a warning on Pkgfiles containing source=().

These are small, simple and non-intrusive steps towards getting rid of bashisms, and should been ideally be seen as first babysteps towards getting the ports system more, ahem, portable. :) hello treach,

I think this is a good way to explain opinions and give reasons about them. Like I said yesterday, I think it can be a good idea. I can not see much problems, and like you said, more benefits with portability. I hope we can read more opinions/explanations/problems about this topic from some core maintainers.

As for what shell to use, I'd like to point to dash, already in use by debian/ubuntu, which seems to be more strictly POSIX compliant. I'll leave the question of which one of these are the better to smarter people than me, but I'd like to hear some responses to this - including from the people actually in charge. :>

regards treach _______________________________________________ CRUX mailing list CRUX@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux

Greetings. Learning day by day. pitillo.