Jackass! 2005.2 Support Group

Message

96140 · Post by **96140** » Thu Sep 29, 2005 4:28 pm

carpman wrote:Hello, done a couple of installs with P3 and Amd build and get warning such as:
Code: Select all
Calculating dependencies   * Please upgrade your package (gentoo-sources-2.4.20-r33) to use toolchain-funcs.eclass
QA Notice: sed in global scope: sys-kernel/gentoo-sources-2.4.20-r33
 ...done!
Got one simular with grub emerge.

Using Gentoo 2005.01 live cd.

It's pretty common. It just means that the maintainers wrote crappy, incorrect ebuilds for those packages. They shouldn't affect compilation. Read about the exact same issue on this page of the Development thread. As soon as you do "emerge --sync", the messages should disappear.

Bob P · Post by **Bob P** » Thu Sep 29, 2005 9:10 pm

yes, that problem should disappear as soon as you emerge --sync. ultimately, that problem is caused by an idiosyncracy of some of the ebuilds in the portage snapshot.

is that error message something that is universal, or uniquely associated with your attempts to emerge a kernel? if its kernel-related, i'm going to cop-out and say that i can't help much as kernel selections are totally unrelated to jackass.

StarmanJones · Post by **StarmanJones** » Thu Sep 29, 2005 9:31 pm

Hi Bob P,

where can I get jackass! 2005.1 ? Your website seems to be down.

Bob P · Post by **Bob P** » Thu Sep 29, 2005 9:36 pm

StarmanJones wrote:Hi Bob P,

where can I get jackass! 2005.1 ? Your website seems to be down.

you have to wait for the web server to come back online.

96140 · Post by **96140** » Thu Sep 29, 2005 9:45 pm

Bob P wrote:yis that error message something that is universal, or uniquely associated with your attempts to emerge a kernel? if its kernel-related, i'm going to cop-out and say that i can't help much as kernel selections are totally unrelated to jackass.

Bob, it's universal. It's the problem of that particular Portage snapshot--I've seen it in every stage I tested for 2005.1. If you save any of your PMs, you might find the ones we sent each other regarding the first time these errors popped up, back when I was the only other tester.

The list of affected ebuilds includes:
* grub
* vixie-cron
* dhcpcd
* hotplug
* coldplug
* pciutils
* acpid
* freetype

There are many more; I'm still finding my notes from the testing process. All the above packages will give the same error message, and they'll also fail to compile with FEATURES="strict" because of files not listed in the manifest.

Though the packages themselves are quite good, the ebuilds for that particular Portage snapshot were not so hot.

Bob P · Post by **Bob P** » Thu Sep 29, 2005 10:26 pm

nightmorph wrote:Though the packages themselves are quite good, the ebuilds for that particular Portage snapshot were not so hot.

i've been saying that for a long time -- gentoo portage is full of shitty ebuilds, and the maintainers need to get their butts in gear.

now as far as portage snapshots go... that was a problem with all of the portage snapshots that were available at the time. i'm not sure if its still a problem, but i don't think that its worth rebuilding to fix the problem when a simple "emerge --sync" will take care of things.

96140 · Post by **96140** » Thu Sep 29, 2005 10:31 pm

Bob P wrote:
nightmorph wrote:Though the packages themselves are quite good, the ebuilds for that particular Portage snapshot were not so hot.
i've been saying that for a long time -- gentoo portage is full of shitty ebuilds, and the maintainers need to get their butts in gear.

now as far as portage snapshots go... that was a problem with all of the portage snapshots that were available at the time. i'm not sure if its still a problem, but i don't think that its worth rebuilding to fix the problem when a simple "emerge --sync" will take care of things.

Just in time for the upcoming BugDay . . .

I agree. Rebuilding serves no purpose, especially since users are almost guaranteed to re-sync sometime shortly after installing.

Bob P · Post by **Bob P** » Thu Sep 29, 2005 11:18 pm

StarmanJones wrote:where can I get jackass! 2005.1 ? Your website seems to be down.

the failure was caused by a 10/100 ethernet switch that died without warning. as a result, the entire backbone of my LAN is dead.

i'm desperately in need of a replacement 12-port 10/100 switch.

until i can find another one, users should be advised that the server will experience frequent downtime.

Edit: Note to Jackass! users: Please DO NOT bombard me with e-mails about the status of the server!

southpaw · Post by **southpaw** » Fri Sep 30, 2005 4:01 am

Hey Bob,
I just thought I would let you know that I managed to do an install by grabbing a P3 tarball lastnight while using the Jackass! 2005.0 disc and everything went smooth as silk

. Btw, I like the ASCII jackass you added to the terminal upon reboot, nice touch

.

Bob P · Post by **Bob P** » Sat Oct 01, 2005 6:56 pm

from another thread, where the user should have posted to this one:

biosoutput wrote:[/b]I just found out about Jackass, i did a stage 3 on my mmx 200 does anyone know where to download it,

The mirros don't have it on the Jackass Project site thanks..

the Jackass! Support Thread would be a good place to ask this sort of question. if youi posted your question there, then the people who are responsible for Jackass! would be aware of your question. i, for example, would have seen your post a week ago if you had posted it there.

if you ask for support by starting your own threads, you are guaranteed not to get a response from me, because i do not read other threads in the forum. i found this thread purely by accident.

slycordinator wrote:
biosoutput wrote:thanks again, when i go the tarballs for mmx it puts me back in the donate page, now for the p4 it starts to download, any ideas check it out

to see if i'm on the right track wow that was a fast reply.
Try scrolling down and reading the entire page.

edit:
Since you can't be bothered to read it, the page tells you that the tarballs for legacy processors aren't available. And I assume it asks for donations simply because even though the tarballs for mmx are used by almost no one it still takes just as long to build as the others (the ones that lots of people use).

sly is right. i'm phasing out the architectures that nobody bothers to use because its a waste of my time to build them. the page that he referenced very clearly spells that out. it does appear that you didn't bother to take the time to read it.

right now Pentium Classic, Pentium MMX, Pentium Pro and Pentium 2 are on the chopping block because it takes an incredibly long time to build and test these arches while an insignificant number of people use them. it just doesn't make sense to commit weeks of time on the part of a developer and a large group of testers to build something that never gets used.

i realize that there are a few people out there who do use some of the antiquated architectures. these people, though few and far between, are the ones that would have to commit the largest amount of time to performing a Stage 1/3 install and are the people who benefit the most from Jackass! for reasons that are unclear, they are also the people who support the project the least.

these antiquated-architecture tarballs are slated for elimination from the project in the next release. in this release they remain available to people who support the project by buying a CD. i am continuing to make them available in this fashion solely for the purpose of giving the users of the soon-to-be-extinct architectures an opportunity to change my mind about discontinuing the builds. the ONLY chance that these architectures have of being in future editions of Jackass! is if people demonstrate that they are worthy of support. if people support them, then i will build them for the next release. if people do not support them, they will become extinct. its as simple as that.

as a user who's loooking for these downloads, you're left with a decision of whether or not you value the Pentium-MMX version of Jackass! enough to support it. if everyone took your approach and said "I want it but I'm not willing to pay for it" then there would be a clear signal that my current impression on the value of these tarballs is correct, and that building those arches for people who don't value them is really nothing more than a waste of my time. its all up to you.

Bob P · Post by **Bob P** » Sat Oct 01, 2005 7:22 pm

Tarball Frequency distribution, September, 2005:

Code: Select all

Athlon-XP:  42%
Pentium 3:  32%
Pentium 4:  26%

96140 · Post by **96140** » Thu Oct 06, 2005 5:43 pm

You know, I don't think we need to have glibc ~x86 in /etc/portage/package.keywords anymore.

IIRC, it was in there because 2.3.5-r1 was needed to support the other toolchain components. However, within the last few days, glibc-2.3.5-r2 was marked ~x86. I'm currently building it right now, and I just noticed that today, glibc-2.3.5-r2 was finally marked x86--it's gone stable.

More than likely, Jackass! users can avoid the (very relatively) frequent updates to glibc ~x86 by removing it from package.keywords--new versions of glibc take a long time to be marked stable on x86. Because even with a fast Jackass!-provided toolchain, for every update to it the subsequent "emerge -e system && emerge -e system && emerge -e world && emerge -e world" still takes a long time.

A good idea? Yea/Nay?

I've never liked running with any ~unstable branch package enabled, except when absolutely necessary. As of right now, the only packages in /etc/portage/package.keywords that are still in the unstable Portage tree are libstdc++-v3-3.3.6 and gcc-3.4.4-r1. Every other package, even though it's keyworded ~x86, has actually been moved out of ~unstable and into stable. In fact, there are no ~unstable ebuilds for those packages; if you've updated your Jackass! system within the last few days, then you're using toolchain components that are stable.

So, given all that

, is there any need to keep the packages besides gcc and libstdc++-v3 in package.keywords? Of course, the obvious potential problem is that a new revision of gcc-3.4.4 comes out, or 4.x is marked ~x86, and it depends on an ~unstable toolchain package. However, I think this is unlikely, as there is no other ~unstable toolchain package waiting in the wings. There's a couple that are hardmasked/unstable, but they are unlikely to move to ~x86 for a long, long time, if at all.

ocbMaurice · Post by **ocbMaurice** » Fri Oct 07, 2005 11:27 pm

I'm one of the desperate users still using old Pentium 1/2 hardware. It's sad to hear that the jackass project will no longer provide downloads for these archs, as it greatly reduced the time to setup gentoo on such "old" hardware. How different will the "legacy i686" builds be compared to the true Pentium 2 builds?

Someone already suggested to provide the downloads via torrent. Alternatively I would suggest to use edonkey or any other p2p app that has a non graphical version for linux. Hope you consider this idea. I would also provide a few KB/s to help distributing the files I use.

thxs, Maurice

p.s. Currently none of the download links work !

Bob P · Post by **Bob P** » Sat Oct 08, 2005 1:34 am

i think you're missing the point in a few respects --

1. the legacy 686 builds include the pentium pro and pentium 2 builds. the legacy 586 builds include the pentium classic and mmx builds. this is spelled out very clearly on the website.

2. the reason that these arches are being discontinued is because almost nobody uses them, and nobody supports them -- most interestingly, the people who are not supporting them are the people who demand the most -- these are the self-procliamed "desperate people" who are stuck with the antiquated architectures and benefit the most from the expense of my time.

i am growing rather bored to continually read posts from people that don't support the project, yet insist upon complaining about my decision to allocate my time wisely by discontinuing architectures that are not being utilized. simply speaking, its a waste of my time to build arches that people don't use, so the arches are being dicontinued.

people who complain about this decision but do not support the project are telling me two things:

the fact that they want the jackass tarballs because they don't want to go through the trouble of a Stage 1/3 install means that they value their time. the fact that they expect me to build something for them that they are not willing to build for themselves means that they don't value my time.

if you want something that i am not offering you're just going to have to build it yourself. this won't be at all hard for you to do, as i've completely documented how you can do it.

3. if you are having a problem with a mirror, you need to contact the mirror host directly.

Bob P · Post by **Bob P** » Sat Oct 08, 2005 1:52 am

i'm glad to see that some of the packages are being marked stable. if this continues, maybe i can stop working on the Stage 1/3 threads and the Jackass! toolkit, and these packages will find their way into a standard Gentoo tarball.

the testing branch toolkit components are listed in the Jackass! config files because those toolkit components were in the testing branch at the time that Jackass! was built.

if some of the toolkit components are in the stable branch when the next Jackass! build comes out, i'll make sure that the next set of Jackass! configuration files will be updated accordingly.

i have to admit, i havent' given any thought to updating the Jackass! configuration files in between releases. maybe this information would be most helpful in a thread where people are actively building toolkits... maybe one of the Stage 1/3 threads?

l1ltw1st · Post by **l1ltw1st** » Sat Oct 08, 2005 4:30 am

Hopefully this is the correct place, I need a little help on a decision

I used Stage 1 on 3 to install gentoo on an AMD64 3800+ X2, I installed x86_64 and the quake3 server it was built for is not working properly at all. Server feels like it is on a dial-up connection with severe spikes and lag. Same setup and pipe on another server that is also Stage 1 on 3 (cele 700) is smooth as silk.

I want to use a 32 bit version as we feel Quake4 is going to run into the same issue, no linux 64 bit support. Which would be the best version of Jackass to install on the AMD64? I know most use AMD-XP, but the X2 core has SSE3 now...

Truly sorry if this is the wrong thread for this question... TIA for the help.

Bob P · Post by **Bob P** » Sat Oct 08, 2005 3:46 pm

If you're familiar with the Stage 1/3 install, then you know that neither the Stage 1/3 install nor Jackass! is supported on AMD64.

Stage 1/3 Support Thread wrote: AMD64 - Unsupported: http://forums.gentoo.org/viewtopic-t-31 ... t-427.html

on 4/27/05 Sith_Happens wrote:Let me also point out that those who are installing on the AMD64 architecture can follow Jorge's advice if they wish, he seems right on the money (although I'm unsure about the vesa-tng part), but remember that installations on AMD64 architectures or any other non-x86 architectures are not supported by this how-to. If you run into problems, create a new topic, don't post to this support thread. Also, in the future please refrain from telling people to deviate/modify the guide. I know you didn't mean to cause trouble, but this kind of advice will only cause confusion, and hence more work for those of us providing support for this install meathod. Muchas Gracias.

I guess I'm obliged to preface my answer with the caveat that from an official perspective, AMD64 installations remain unsupported for both Jackass! and the Stage 1/3 install. This is primarily because GCC 3.4.x is already stable on AMD64 and because I don't have an AMD64 box in the Jackass! development lab.

with that said, i'd agree with most people that the Athlon-XP tarball would be a good one to use. Not having an AMD64 box, I have never tried using the P4 tarball on an AMD64, but if newer versions of the chip use later variants of SSE, that would be worth looking into. Sorry I don't have a more definitive answer. Since you're blazing the trail, It looks like you'll have to do some experimenting and report back to us.

Bob P · Post by **Bob P** » Sat Oct 08, 2005 6:40 pm

architecture flag information that helps to answer your question:

http://www.ip97.com/gcc/i386-and-x86_00 ... tions.html

96140 · Post by **96140** » Sat Oct 08, 2005 7:26 pm

Bob P wrote:maybe this information would be most helpful in a thread where people are actively building toolkits... maybe one of the Stage 1/3 threads?

Done. I posted it in the main thread (not support) for Stage 1/3 2005.0, as I don't think you've done a 2005.1 guide yet.

Bob P · Post by **Bob P** » Sat Oct 08, 2005 9:44 pm

yeah, i sidestepped doing a 2005.1 version of the Guide because there wasn't any real change between 2005.0 and 2005.1 (other than the tarball permission issues).

codergeek42 · Post by **codergeek42** » Sun Oct 09, 2005 3:34 am

Just curious, Bob: Will you producing Gentoo/hardened Jackass builds?

Bob P · Post by **Bob P** » Sun Oct 09, 2005 12:04 pm

i haven't thought about it. there's always been that problem with hardened & GCC 3.4.x. has the situation improved recently?

Bob P · Post by **Bob P** » Sun Oct 09, 2005 12:12 pm

NEW MIRROR!

Thanks to Morten Pedersen for setting up a new Official Jackass! Mirror!

Morten's mirror is located in Oslo, Norway. His website is located at www.mojope.com. He's our first European mirror for Jackass!

On behalf of all of the Jackass! users I'd like to thank Morten for his contribution to the project.

vipernicus · Post by **vipernicus** » Mon Oct 10, 2005 8:03 pm

There's been talking and tests in CFLAGS Central recently, and it's been proven that -momit-leaf-frame-pointer, when used in conjuction with -fomit-frame-pointer only disables leaf-frame-pointers .

Bob P · Post by **Bob P** » Mon Oct 10, 2005 10:53 pm

vipernicus wrote:There's been talking and tests in CFLAGS Central recently, and it's been proven that -momit-leaf-frame-pointer, when used in conjuction with -fomit-frame-pointer only disables leaf-frame-pointers .

link?

...

interestingly, what has been anecdotally reported in the CFLAGS Central thread as occurring with GCC 3.4.4 is NOT what is supposed to happen.

at this point it remains unclear to me whether this discrepancy between the documentation and the observed behavior is due to a newly implemented change that is not yet reflected in the docs, or due to an upstream bug that needs to be corrected. it will be interesting to see how this situation is resolved.