FreeBSD needs fresh blood!

Even though I am known for being frantic and unstable, I've learned that posting questions to the mailing lists for PowerPC and UltraSPARC specific are ignored. I'm building packages for PowerPC and will upload them as soon as orca finishes building and I can use
Code: 
pkg_create -b $PACKAGE-NAME
Right now, kdeedu will not build on anything non x86.
PCI graphics aren't always readily recognized on a SB1000.
The video card functions have to be uncommented and set for PPC & SPARC64.
Believe me, two powerpc machines and my input/questions means menos do que merda.
 
sossego said:
Even though I am known for being frantic and unstable...
Click to expand...
Sounds like me at times.

I'd love to get involved with x11 and gecko but need to get my act together. Bought a house, selling the old one, starting with a new client for my business and people won't leave me alone; but I'd love to help. I'll get there eventually.
 
sossego said:
Even though I am known for being frantic and unstable, I've learned that posting questions to the mailing lists for PowerPC and UltraSPARC specific are ignored. I'm building packages for PowerPC and will upload them as soon as orca finishes building and I can use
Code: 
pkg_create -b $PACKAGE-NAME
Right now, kdeedu will not build on anything non x86.
PCI graphics aren't always readily recognized on a SB1000.
The video card functions have to be uncommented and set for PPC & SPARC64.
Believe me, two powerpc machines and my input/questions means menos do que merda.
Click to expand...

It's not that. The problem is that we cannot do anything with ppc or sparc64 if we don't have those systems.

You mentioned kdeedu. Well, I'm in kde@. I can't say if you wrote to us with questions or suggestions. If that was the case, I apologize. Since you seem to have patches or similar for this stuff, I invite you to mail them to us and/or other lists. We won't be able to test them, nor review them, but your input will be enough to let us apply the fixes.

You should also understand that, being few persons, persons with lives, we will of course miss something. But I guarantee to you that we try to find an answer for everybody, sooner or later.
 
A couple of years ago, you guys shamed me into becoming a ports maintainer. Now, just like the church, the labor union, the political party, and every other volunteer organization I've ever been involved with, you're wanting even more of my time. You won't be satisfied until you have it all, will you? ;)

But OK, OK, it's the worthiest of worthy causes. Let me see what I can do. I know a bit of C and C++ programming, and I've been meaning to delve deeper into gnome anyway...
 
ckester said:
A couple of years ago, you guys shamed me into becoming a ports maintainer. Now, just like the church, the labor union, the political party, and every other volunteer organization I've ever been involved with, you're wanting even more of my time. You won't be satisfied until you have it all, will you? ;)
Click to expand...

We won't be satisfied until we have all of your blood. ;)
 
UNIXgod said:
What do you need documented?
Click to expand...

You should ask to single maintainers. E.g.: if you are a Gnome user, drop a line to gnome@ mailing list. You shouldn't limit yourself to the lists in the topmost post, though: those are the ones which especially need horsepower for porting work. But documentation is something that most of the teams can benefit from.
 
Just a few things that could use work by people of varying skill levels:

Locate serious udev documentation (HAL haters, here you go, help get rid of it.)
There's a problem with some older Radeon cards, X300 and X1650 for example, and a patch in the new driver (start of thread). The problem is located, work out a fix.
Booting could be sped up (start of thread). Benchmark where the delays are in booting a kernel. For extra credit, figure out ways to make the device detection quicker or at least less conservative. For really extra credit, make some device detection (USB, maybe others) run in the background.
 
I would be very interested in joining a team maintaining KDE3.

How many would be interested in this?

Since I do not have a "gaming machine", I do not have interest in KDE4, but KDE3.5 (Or Trinity) *should* be maintained because it is one of the last usable full desktop environments for FreeBSD on "normal machines" such as a Thinkpad x61

I am quite proficient in C++, and am currently developing an alternative DE (OpenCDE) but I would like to learn more about the KDE3 build environment and help out :)

At least until OpenCDE is complete and there is an alternative to KDE3 for less powerful machines.
 
kpedersen said:
I would be very interested in joining a team maintaining KDE3.
Click to expand...

Then the best thing to do is to start contributing patches/updates to KDE 3 ports to kde@ (as someone already did), Maybe to start implementing some of Trinity new code (yes, you can ask for help, too). Also, on ports@ there was a thread ("KDE3?") talking about Trinity, so you might try to collect some fellows there.

And then... we'll see how things grow up.
 
Just for your info, guys: Im interested, but I have no (or almost no) experience with both FreeBSD ports and C/C++.

Probably I will try to compile Trinity in the next couple of days and will report problems to kde@ or somewhere.
 
sossego said:
Right now, kdeedu will not build on anything non x86.
Click to expand...

Right now, there isn't any open report for that in neither our bug tracking system nor in KDE's. Can you post the failing lines, kde* and qt* config options, and the exact architecture here?

If it's nothing obvious, I might try to qemu and hunt it down this weekend/next week.
 
Thanks for this post, I think I'm rather interested in joining gecko team as a tester (I have programmed a little before, but too little to be a programmer, so, only a tester), but during vacations, right now I have no time, I must study! ;)
 
You must log in or register to reply here.
Back
Top