Now that I've gotten Arch setup pretty much in the way I'd hoped on three machines, I've started rebuilding all the packages from source according to new optimizations specified in /etc/makepkg.conf. In the past I've used makeworld for this task but since it is not sufficiently configurable at this point to process anything but fixed groups of packages, I've had to go at it one package at a time. At this juncture I've processed about half of the 110 or so packages on this particular computer. I have a couple of questions I'd now like to raise to experienced Arch hands:
1. A previous attempt to build glibc 2.3.2-2 from source produced an err.log report thusly:
glibc requires kernel headers in /usr/src/linux/include
Not understanding the full meaning of this report at the time, I submitted a bug only to learn from the developer that "you need kernel source". I'm afraid I'm not clear on just what I have to do with these directions. How do I integrate this requirement for kernel source into a source rebuild of glibc using makepkg -bci ?
2. To this point, of the roughly 50 packages I've rebuilt only three have had the wheels come off: aspell, with a rather nasty looking check-string error; bison, which wouldn't download (possibly wrong url); and groff, which won't provide the source code owing to a GNU security issue of some kind. Additionally, the bash rebuild encroached upon my ~/.bashrc but, because I'm aliasing startx='startx -- -br', it gave itself away the first time I accessed run level 5. I consider these results a pretty decent commentary on the condition of abs. Would you agree?
3. I've been given to believe that the use of Eterm requires a good bit more of system memory than would be the case with aterm or xterm. Would the use aterm instead of Eterm for the specific purpose of compiling packages represent anything meaningful in the way of a performance boost? My guess would be that it would not be noticable. Your thoughts.
well as far as the kernel source, what I would do is: go to /var/abs/kernels/kernel or whatever, and start building the kernel. if you don't actually want to rebuild it then stop it once the source is unpacked & configured with a CTRL-C. Then symlink from the /var/abs/kernels/kernel/src/linux-<ver> to /usr/src/linux or move it there so that it will be found.
as far as those 3 packages, I don't think it really says much about abs -- all it means is a couple of packages might need updating, sounds like mostly just updating the url for the sources (nothing can really be done about the GNU security breach). Anyways just post bug-reports using the bugtracker off the main arch page, I'd say.
Thanks for your reply!
About the glibc rebuild, I must confess I'm a little surprized by what would seem to be necessary to get things straightened out in this case. First, I was struck by the fact that the thing died with an error of this kind at all. The package's build script couldn't have been written in such a way as to contemplate these kernel header requirements? It should be necessary with Arch to start and then interrupt a rebuild of the kernel in order to do a source rebuild of glibc? I've done rebuilds of glibc in other distros and they just finish up. There has to be a simpler answer to this problem.
In any case I appreciate having benefit of your ideas.
not sure why your glibc will not build i had no issues building one on my i586 last night. i have an extensive /usr/src/linux/include directory which is what i belive you need for building glibc. this should have been installed with your kernel package. as for groff ... this is an issue that i am sure the package maintainer of groff is not even aware of but when gnu found their server compromised earlier this year groff 1.19 was one of those packages that they feared could have been possibly compromised (along with 1.18.1 which went up around that time as well). as a result 1.19 is under review (as is 1.18.1) , there fore th only available package for groff right now that is "recent" is 1.18. a bug report should be submitted to see if the maintainer will revert to the previous known secure release.
bison...well again i downloaded and built it just fine.
if you really think abs is a disaster then you should be submitting bug reports. when you maintain over one hundred packages and work on various other stuff problems with build and PKGBUILD can go unoticed for a spell especially when package are not developed and released very quickly. that is not an excuse but reality. while fighting with a build of openoffice and trying to work my way through incoming packages i have not been paying attention to my other packages, which when i last checked were up to date too my knowledge and all PKGBUILDs worked.
i also dis a sweep of my package list for new releases. i found several. of course not knowing i had any other issue i did not tackle those at that time. little did i know that both the nvidia-driver, mozilla, and audacity had small issues with their PKGBUILDs. why did i not know this? because the last time i did build them they worked and there was no reason to "fix" them because i did not know of any errors. feed back came and they were fixed. now i can assume again that those build *should* work because i did not do anything special on my system to build them.
i am currently trying to makeworld what i can as well but i know that there are packages that i will have to take a closer look at. at that time i will contact the maintainers for advice or with fixes. (for example bzip2 which i cannot download at this time because the redhat source ftp server seems to be sick).
sorry to get defensive but i think i speak for many people here when i say that the "condition" of abs is not bad. with nearly a thousand packages ver y few builds at any one time are disfunctional. and because the PKGBUILDs are not working does not necessarily mean the packages are. furhter broken PKGBUILDs are not a sign of neglect on the behalf of the developer. we do try our best to make sure every user can rebuild packages for themselves otherwise arch would not offer abs at all.
I am not your friend
Frankly, more than a little puzzled by the following, Sarah:
if you really think abs is a disaster then you should be submitting bug reports.
sorry to get defensive but i think i speak for many people here when i say that the "condition" of abs is not bad
Had you taken the time to read my initial post in this thread carefully? It wouldn't seem so. I've set out the relevant portion for you below:
I consider these results a pretty decent commentary on the condition of abs. Would you agree?
Now that's a compliment not a criticism, Sarah, so there's no need to circle the wagons. While I very much appreciate the portion of your reply that was addressed to my specific concerns, I think I'd appreciate even more having the sense of my remarks interpreted accurately here. Since I didn't come here with the purpose of pointing fingers, I'll expect not having to endure any more of the self-justifying next time, eh?
I read that sentence and took it the good way first. Though, I can understand how it might have been interpreted poorly. Hope no one's nose it bent out of shape
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
sad thing is that i am not the only one that read your comment on the "condition of abs" as negative. it is also too bad that you took offense to my explanation of why myself and other developers may not always not have "accurate" PKGBUILDs. None of us can deveote ourselves 24/7 to arch but we do do very well for the time we can devote to it and it can be frustrating volunteering so much time and getting criticised for what we do put in.
sorry i took your comment in a negative light. what is typed cannot always be easy deciphered as positive or negative. in this case you intended negtive plus negative to equal positive and read it the other way. Yes i did read your comments carefully in fact i read them and the rest several times before responding.
I am not your friend
You know, truthfully, this is becoming a little annoying. If coming to this message board is going to require treading carefully around your delicate sensibilities I'll just have to find a way of managing without you. I came here to use and get help with Arch Linux, not to offer therapy for someone's tattered self esteem.
I had planned to submit a very positive review of Arch to DistroWatch in a week or so. I also had recently offered Judd Vinet a portion of my time to help with the testing of source packages which he had welcomed. This experience gives me a lot to think about.