You are not logged in.

#1 2003-08-21 02:24:07

jlowell
Member
Registered: 2003-08-10
Posts: 270

X, Schmex II

For ther life of me I've never had such trouble getting XFree86 to work! I've installed and gotten it started with startx with five other distros in the last eighteen months but can't get it to work with Arch. Not getting X up and running is a big deal. I keep hitting font difficulties and don't know why. Is there something unique about the way Arch treats fonts in X that I'm missing?

Here's what I've done:

I've used the source package available in /usr/abs//X11/xfree86 and run makepkg -bc then installed with pacman -A xfree86. It went on fine. I've done a xf86config and configured properly. But I keep getting the same complaints about "can't open default font 'fixed'". Truthfully, its beginning to get a little irritating. Have I missed installing something? Have I missed configuring something? I'm just lost at this point and could really use some help.

jlowell

Offline

#2 2003-08-21 04:50:56

sarah31
Member
From: Middle of Canada
Registered: 2002-08-20
Posts: 2,975
Website

Re: X, Schmex II

do you have any fonts installed? freetype1 and 2 for example. is your xconfig set up properly with the path to these fonts?

some reference urls:
1

2


AKA uknowme

I am not your friend

Offline

#3 2003-08-21 16:24:39

jlowell
Member
Registered: 2003-08-10
Posts: 270

Re: X, Schmex II

Hi Sarah!

Well, a check for /etc/X11R6/lib/X11/fonts shows no directory so it certainly would be safe to say that at least to that extent there are no fonts installed! However, to make sure I didn't run into a font problem yet again I made sure to install both 1 and 2 truetype at the time I did the source build and install of xfree86. I know darn well they're installed but if you asked me where, I'd never be able to tell you. Frankly, it never occured to me that I'd need to know that as I've never before been required to know. The fonts just worked. Maybe you can give me some idea of where to look for the truetype fonts.

From what I assume to be happening here, the source package for xfree86 isn't getting the standard Xfonts on. I've suspected that the problem may have had to do with xfs not starting at boot but the latest version of xfree86 does not require that xfs be started then. The only thought that comes to me now is to try the binary package for xfree86 but I'd hate to be forced into doing that since I've made what I consider to be enough compromises in this direction with base system packages that wouldn't build from source, glibc being one example.

Gee, things seem to quiet down around here during the work week, eh?

Regards.

jlowell

Offline

#4 2003-08-22 10:07:02

Mork II
Member
From: Visby, Sweden
Registered: 2003-05-14
Posts: 87

Re: X, Schmex II

Try installing bitstream vera fonts (pacman -S ttf-bitstream-vera) and running fc-cache -fv as root. That should get you bitstream vera truetype fonts but i don't know if it's enough to get X on the road sad. Btw, if you modified your PKGBUILD before building that would be good to know.

For what it's worth I recommend using the binary package (if you don't have a desperate need for some optimizations). It is simple and works. The speed/footprint difference is not that great either. When I compare the speed of my current binary only Arch system to the from-source-with-O2-and-stuff-Crux system I had before I discovered Arch I can honestly say there is very little difference (the only noticable one beeing Mozilla launching a few seconds faster with -02). In my (limited) understanding most apps spend their time waiting for user input. Optimizing glibc, gcc and kernel will be useful, for others the gain is very marginal and definatly not enough to justify the time spent building them.

//Edit: It might also help if you took a look at ttmkftdir//

Offline

#5 2003-08-22 14:47:55

jlowell
Member
Registered: 2003-08-10
Posts: 270

Re: X, Schmex II

Hello Mork II,

Thanks for the idea. I'll try the approach you suggest to see if it helps and get back to you with the result. As to the PKGBUILD of XFree86 itself, I did nothing but run it with makepkg -bc after changing directories appropriately; there were no alterations made.

As you may not be aware, I've been working hard trying to install Arch entirely from source code. I've used makeworld to help with the tedium of doing the base packages and, while there has been a need to get proper urls for a number of them, in the main things have worked. There were a couple of bad builds and, to this point, I've reported one, but I'd been hopeful of eventually having a source Arch installation, soup-to-nuts. This business with X gives me some doubts, however, at least for now. And there were difficulties getting proper builds of two other "post X" packages, Fluxbox and Eterm. Naturally, I've had to take one thing at a time so those issues are yet to come. Maybe your suggestion can keep me on target.

Nice to hear from you.

jlowell

Offline

#6 2003-08-23 02:21:14

jlowell
Member
Registered: 2003-08-10
Posts: 270

Re: X, Schmex II

Mork II,

Well, I did pacman -S tts-bitsstream-vera followed by fc-cache -fv and the directory /usr/X11R6/lib/X11/fonts plus sub-directories were created. I edited /etc/X11/XF86Config to include the font path to the TTF directory and ran startx. Sad to say, no soap.  sad

Truthfully, I'm not sure where this leaves me. If I'm forced to go with binaries all the time the very thing that attracted me to Arch in the first place - the possibility of rebuilding the base system plus xfree86, Fluxbox, Eterm, gkrellm and Mozilla from source - is out the window. That would be a real disappointment, there's a fine community and spirit here. It would seem to me that by dint of the normal operation of things, most of the problems with the base packages can be fixed with little effort, i.e. changing a url or making and submitting a new package where code for a version in the base system no longer exists. But there are some, glibc among them, that will require skills well beyond those that I may be able to bring to the table, however. Now I know that XFree86 has problems and that neither Eterm nor Fluxbox will compile, so I guess it's crunch time for Arch and me. The source packages are there and are readily accessable, it's just that too many of them just don't work. sad

Thank you for your suggestion.

Very best regards.

jlowell

Offline

#7 2003-08-23 04:34:15

sarah31
Member
From: Middle of Canada
Registered: 2002-08-20
Posts: 2,975
Website

Re: X, Schmex II

well i think alot of your problems may come with the order that you are building things. makeworld is fine to use but it does not build packages in order that they should. it simply goes through building packages in the order they are alphabetically. as far as i am concerned building and installing base in that order is not going to work. kernel gcc and glibc need to be built and installed out of their alphbetical order. from what i remember makeworld does not solve dependencies while building which can cause all sorts of issues, possibly what is causing the problems with your xfree. without a working xfree things like Eterm and fluxbox will not build with Eterm you must have the dependencies solved (ie libast) or it will not build. i know there is nothing wrong with the build because i have built it several times without issue.

when you built xfree did you remember to build and install the dependencies first?

makeworld imho is not the tool it is supposed to be yet.

finally i don't know what sort of flags you are recompiling with but remember that soemthings will just not work as well or at all with certain flags (-O3 for example is more trouble than it is worth). you really have to determine if all the work you will be doing will make the effort worth while. so few applications have significant benefit even optimised to the hilt. this is exactly why i gave up on gentoo very quickly. it was not a smart system.

as for packages that have incorrect builds or mistakes. that is what the bug tracker or maintainer tag is for in the build. we developers are not into having "broken" packages. often we may not even realize that packages are broken. some things like symlink may appear fine on our systems and the app works but are in fact symlinks that only we can use. some of these issues are easy to fix other require hours of investigation. we will often respond within minutes or hours in fixing a package so that it works for all. i have found numerous projects have recently changed their url to their source and this is only discovered if someone rebuilds the package or when we are working on them ourselves. bug ttracker or emails. it is the same for any distro. any problems not reported run the risk of never being worked on.


AKA uknowme

I am not your friend

Offline

#8 2003-08-23 18:08:14

jlowell
Member
Registered: 2003-08-10
Posts: 270

Re: X, Schmex II

Hello Sarah!

I appreciate having benefit of your extensive comments on what I've tried to accomplish here with Arch over the last couple of weeks. They inspire a response or two:

well i think alot of your problems may come with the order that you are building things. makeworld is fine to use but it does not build packages in order that they should. it simply goes through building packages in the order they are alphabetically. as far as i am concerned building and installing base in that order is not going to work. kernel gcc and glibc need to be built and installed out of their alphbetical order. from what i remember makeworld does not solve dependencies while building which can cause all sorts of issues, possibly what is causing the problems with your xfree.

You may be right about the order of package build complicating things when using  makeworld but if you are, the complications can have nothing to do with dependencies. I used makeworld -bc when I did the base system rebuild and, unless I missing something, those options deal with dependencies in an entirely acceptable way. None of the breakdowns I experienced were reported as dependency issues. I'd followed gyroplast's suggested command sequence to the letter.

without a working xfree things like Eterm and fluxbox will not build with Eterm you must have the dependencies solved (ie libast) or it will not build. i know there is nothing wrong with the build because i have built it several times without issue.

Now I knew, of course, that successful builds of Eterm and Fluxbox presupposed a build of XFree86. And that's the way I proceeded: XFree86, Fluxbox, Eterm. In these cases I used makepkg -bc from the appropriate working directory, not makeworld -bc. The builds were processed individually.

when you built xfree did you remember to build and install the dependencies first?

Yes, as I mentioned above I used makepkg -bc when building XFree86.

finally i don't know what sort of flags you are recompiling with but remember that soemthings will just not work as well or at all with certain flags (-O3 for example is more trouble than it is worth).

My compiler flags are not particularly enterprizing. I've used -O2, not -O3, with Arch so as not to challenge it.

as for packages that have incorrect builds or mistakes. that is what the bug tracker or maintainer tag is for in the build. we developers are not into having "broken" packages. often we may not even realize that packages are broken. some things like symlink may appear fine on our systems and the app works but are in fact symlinks that only we can use. some of these issues are easy to fix other require hours of investigation. we will often respond within minutes or hours in fixing a package so that it works for all. i have found numerous projects have recently changed their url to their source and this is only discovered if someone rebuilds the package or when we are working on them ourselves. bug ttracker or emails. it is the same for any distro. any problems not reported run the risk of never being worked on.

I've reported four of the packages as bugs as of a couple of days ago, and I'm sure that the Arch developers are hardly happy to hear about problems. You are right about incorrect urls, that was the case with two if not three of the packages. In one case, it is doubtful that source code is even available any more for the package version being requested, the author seems to have by-passed the version our PKGBUILD requests. So there's a need for an update in some and a new version in another. Additionally, there were some, perhaps three, that were not making code available at all at the moment for reasons unexplained at their website. But beyond these minor annoyances there were also some significant build failures, glibc specifically, and as far as I've gotten with them, glibc is the only one I've had time to investigate and report.

So it would seem to me anyway that there are many repairs to make before makeworld has even a chance of being successful doing a base system rebuild. As to its fundamental operation, it appeared to perform flawlessly, however. As for the problem at hand, XFree86, short of using the binary, I'm out of ideas.

Summing up, and in no way wishing to appear patronizing, I continue to regard Arch as a distro with real potential for the approach I wish to bring to it and for the purposes I have for it. The mechanisms are all in place to perform a source rebuild of the base packages and to add XFree86 and follow-up source packages. But as has become all too clear, there are problems with some of the source packages that need attention. I don't think its enough to say that the performance gains lost by using binaries are insignificant. Why offer source packages at all in that case?

Regards.

jlowell

Offline

#9 2003-08-23 20:55:06

sarah31
Member
From: Middle of Canada
Registered: 2002-08-20
Posts: 2,975
Website

Re: X, Schmex II

ok lets deall with the "bugs" reported for the base system. first it is reported that the url for bin86 is in correct. here is the current PKGBUILD:

pkgname=bin86
pkgver=0.16.11
pkgrel=1
pkgdesc="A complete 8086 assembler and loader"
url="http://www.cix.co.uk/~mayday"
depends=('glibc')
source=(http://www.cix.co.uk/~mayday/dev86/$pkgname-$pkgver.tar.gz)

build() {
  cd $startdir/src/$pkgname-$pkgver
  make PREFIX=/usr || return 1
  mkdir -p $startdir/pkg/usr/bin $startdir/pkg/usr/man/man1
  make PREFIX=$startdir/pkg/usr install
}

the url for the source is correct but f you visit the bin86 homepage you will note that a new version is out 0.16.12. bin86 developers remove old source version once the new one is uploaded. so this is not really a bug so much as the fact that bin86 has not bee upgraded. change the version to 0.16.12 and the source url works.

dhcpcd, here is the build as it currently stands:

pkgname=dhcpcd
pkgver=1.3.22pl4
pkgrel=1
pkgdesc="A DHCP client daemon"
url="http://www.phystech.com/download/dhcpcd.html"
depends=('glibc')
source=(ftp://ftp.phystech.com/pub/$pkgname-1.3.22-pl1.tar.gz)

build() {
  cd $startdir/src/$pkgname-1.3.22-pl1
  ./configure --prefix=/usr
  make || return 1
  make DESTDIR=$startdir/pkg install
}

a little bit of inattentiveness for the upgrading of this package. note the versioning in the version number is pl4 and the source line and "cd" line in the PKGBUILD read pl1. change the 1 to a 4 and all builds fine. this is a bug with the PKGBUILD.

groff is a devel version and is not available at the posted url in th PKGBUILD. my guess again is that it was just missed. correct url is:

ftp://groff.ffii.org/pub/groff/$pkgname-$pkgver.tar.gz

glibc built without issue for me so unfortunately i don't know what to say in that regard.

as for offering source. we don't we offer our builds to rebuild if one desire and makeworld is one of the tools to mass rebuild. it will ALWAYS be a un reliable tool, imho, because as the package trees grow and packages are developed there is no telling whether the abs database will be able to stay 100% current 24/7. we do try our best to stay current with trackers and checks but still it is very hard. i had an email sent to me that gthumb is out of date yet all of my indicators show it is not so i went to the homepage and it is indeed upgraded. to go to the home url for almost a hundred packages (or more for some people) is just not something that can be done except on rare occasions. we rely on our users to point out these errors and be patient while we correct them (you have pointed out the errors but int the case of the PKGBUILD corrections they cannot be fixed until apeiro returns from his few days off).

PKGBUILDs are there for the impaitent and for users to help out. but make no mistake arch is not a source distro and we make no illusions to that.

xfree86....i just do not know i have offered a few suggestions but i think this is something that you will have to look into. or provide more information to the maintainer of xfree86. there are LOTS of hits on your error on google.com/linux.


AKA uknowme

I am not your friend

Offline

#10 2003-08-23 22:45:31

jlowell
Member
Registered: 2003-08-10
Posts: 270

Re: X, Schmex II

Hi again, Sarah!

but make no mistake arch is not a source distro and we make no illusions to that.

While I think that Arch has striven not to develop undue expectations of this kind, the possibility of it's offering full source capabilty has already been realized with such tools as makeworld. Seeing it in action, I don't share your pessimism about it. For it to reach its full potential some kind of linkage would need to be provided between the build and install phases, admittedly, but that's all. You've got a real winner here that simply needs some sprucing up and it would do all one might reasonably expect of a source distro and probably do it as well if not better than at least three distros currently holding themselves out as "source-based". 

as the package trees grow and packages are developed there is no telling whether the abs database will be able to stay 100% current 24/7. we do try our best to stay current with trackers and checks but still it is very hard.

That's really what you mean when you say Arch isn't a source distro, isn't it? It's a question of how much time the developers have to keep abs current. Their not being able to do that 24/7 is easy enough to understand. But let it never be said that Lowell didn't put his money where his mouth was: If you're looking for someone to help with the daily tracking of packages so as to help the developers achieve de jure source-based status, you've found him. I'd be willing to give a project like that a reasonable amount of time and I'll bet others here would be willing to volunteer as well if asked. As for apiero's taking a vacation, what do you mean, "vacation".  big_smile

Let me know what you think.

jlowell

Offline

#11 2003-08-23 23:01:38

sarah31
Member
From: Middle of Canada
Registered: 2002-08-20
Posts: 2,975
Website

Re: X, Schmex II

vacation as in away for a few days not reachable.

if you want the task of tracker then by all means go ahead and email apeiro about it. but i can tell youit is VERY VERY hard staying on top of over 84 packages (what i currently maintain and i have maintained almost 500 at other times).

further note about makeworld/sourcebased-distros. i used makeworld a while back and i liked it but the idea of turning the focus of a functioning binary distro to a source-based distro does not appeal to me i don't like source based distros i came to arch because i don't like source based distros. further i personally think changing arch from a functioning precompiled binary distro to a  source based distro wastes the purpose of abs, pacman, and trying to get anything done outside of keeping builds working, keeping makeworld working, changing all docs to inform both binary and source users, etc. that would effectively stall development of arch linux and turn the focus away from what it really is...a precompiled binary distro that has some features that allow users to changit into more of what they may want (optimization wise).

if it was a source based distro or even pretended to be one there would be scripts present that would allow you to upgrade from source packages that need upgrading. nothing is stopping uers from developing code to interface with pacman in that manner. when you think of the work that you need to do to keep your arch running in a source base fashion you wil realize that arch is indeed not a source based distro.

edit:

further to your issues...did you upgrade gcc, glibc, and the kernel first then recompile bash then do a makeworld? did you have the most recent abs directory? i just wonder because i had zero issues with glibc and it has not even been upograded to use the new gcc 3.3.1. i really believe that your issues lie not in what you have done but what may not have been done. building and installing order canbe very important and i don't think makeworld is really set up to take this into account.


AKA uknowme

I am not your friend

Offline

#12 2003-08-23 23:24:13

Xentac
Forum Fellow
From: Victoria, BC
Registered: 2003-01-17
Posts: 1,797
Website

Re: X, Schmex II

If installing dependancies is the problem, you might want to look at passing -i to makeworld.  That installs packages after they are built.  That way the things that depend on those packages will actually have the files present.


I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal

Offline

#13 2003-08-24 00:02:11

jlowell
Member
Registered: 2003-08-10
Posts: 270

Re: X, Schmex II

Hi Sarah,

further note about makeworld/sourcebased-distros. i used makeworld a while back and i liked it but the idea of turning the focus of a functioning binary distro to a source-based distro does not appeal to me i don't like source based distros i came to arch because i don't like source based distros. further i personally think changing arch from a functioning precompiled binary distro to a source based distro wastes the purpose of abs, pacman, and trying to get anything done outside of keeping builds working, keeping makeworld working, changing all docs to inform both binary and source users, etc. that would effectively stall development of arch linux and turn the focus away from what it really is...a precompiled binary distro that has some features that allow users to changit into more of what they may want (optimization wise).

Well, Sarah, we simply cannot have the soon-to-be-announced Director of Source Operations here at Arch expressing sentiments like these in public now can we. In the circumstances, I'm afraid we'll be compelled to withdraw our recent offer.  big_smile

Seriously, no one's suggesting that a fundamental change be made in Arch's philosophy, Sarah. What's being proposed here is that the potential already built into Arch be brought to full realization. It already is a quasi-source disto. And as I'd mentioned, I and I'll bet some others here too, would be willing to make time available to assist the developers in making Arch's source capability more than considerable. Think about it.

jlowell

Offline

#14 2003-08-24 00:33:59

jlowell
Member
Registered: 2003-08-10
Posts: 270

Re: X, Schmex II

Xentac,

Interesting comment. I'd been told originally that the recompiled packages needed to be sent to a newly created directory, say /home/sourcepackages, and that pacman would do the installing. See
below:

jlowell
Regular


Joined: 09 Aug 2003
Posts: 39

Posted: Sun Aug 10, 2003 7:36 pm    Post subject:   

--------------------------------------------------------------------------------

OK, Gyroplast, so I'm feeling adventurous. 

Let's say, as root, I use this series of commands given what you know about where I am already,

mkdir /home/sourcepackages
cd /usr/abs
makeworld -bc /home/sourcepackages base

and makeworld stores the packages in /home/sourcepackages. What command do I run next to install them properly, something like makeworld -i /home/sourcepackages?

jlowell

Last edited by jlowell on Sun Aug 10, 2003 7:44 pm; edited 1 time in total

Back to top       


Gyroplast
Developer


Joined: 03 Sep 2002
Posts: 160
Location: NRW / Germany
Posted: Sun Aug 10, 2003 7:42 pm    Post subject:   

--------------------------------------------------------------------------------

Wellwell, once you end up with your truckload of packages in /home/sourcepackages you'd simply run pacman -Up /home/sourcepackages/*.pkg.tar.gz to install (or rather update) all the packages. Missing dependencies should not occur since you used the -b option for makeworld.

Yeah, that's basically it. Don't expect any gotchas. 

Good luck,
Dennis
_________________
"That's the problem with good advice. Nobody wants to hear it."
-- Dogbert

Back to top

         

Your saying that the packages can be installed directly after being made without using pacman? As you can see, that had been my first suspicion. What would be the correct command sequence to carry out a rebuild, then, Xentac?

jlowell

Offline

#15 2003-08-24 04:30:23

rls
Member
From: contracosta, california
Registered: 2003-08-20
Posts: 60

Re: X, Schmex II

Being a newbie, perhaps I have missed some important concepts in this discussion. Although instructive,  many of the technical points went by me.

Stepping back a moment for the big (Linux) picture, isn't Linux-From-Scratch the distro, if you can call it a distro, for the ulimate control in building a Linux system. At the other end of the spectrum there are SuSE and Red Hat where "everthing" is done for you, a la Microsoft Windows.

Aren't all other distros are somewhere in the middle of the spectrum, following the law of the greater the control the greater the knowledge and effort required?

Actually the ultimate control distro would be the one in which you wrote the source code for everything - kernel and other system's programs as well as all the apps. You would certainly know what was going on, if, at the end, you hadn't forgotten what you had done at the beginning.

Regards, Rick


"Es gibt nichts mehr praktish als theorie" L. Boltzmann

Offline

Board footer

Powered by FluxBB