[dedalus]

Hello,

Very glad to be here...

Just wanted to offer my services here at Nightingale. I'm a professional c++ developer working in high performance server-side applications on a linux platform. I use the stl, the posix api, pthreads and c++11 (c++0x) on a daily basis. I'm more than comfortable in c and using make, as well as various versions of g++.

I also use python on a daily basis as well, although admittedly at quite a high level.

My interest in Nightingale is primarily because I was disappointed in the lack of support for linux in Songbird and for a good extendable media player for linux in general. I'm looking for a good project to dedicate my time to.

Let me know if you have any suggestions on how I can help. Or where I can begin...

[ilikenwf]

We want you! This can go two ways:

You can just fork the code and do whatever you want with it and put in pull requests as you'd like...we have an issues tracker on github...

Or

You can hop in the IRC and forums and we can suggest things, help get you accustomed to the codebase, etc...there's plenty to be done!

[dedalus]

Great! I'll see if I can't hop on irc tonight (EST) and talk to some people.

So I've read the "Git Repo Descriptions/Explanations" post, but I'm still not completely sure which branch I should be looking at. Where should general non-urgent fixes go? master? nightingale-1.11?

I'm able to build and run nightingale-1.11, but ran into a few compilation issues in master.

[rsjtdrjgfuzkfg]

Thanks for your interest. As ilikenwf pointed out you're more than welcome here.

(03-08-2012, 09:57 PM)dedalus Wrote: Great! I'll see if I can't hop on irc tonight (EST) and talk to some people.

So I've read the "Git Repo Descriptions/Explanations" post, but I'm still not completely sure which branch I should be looking at. Where should general non-urgent fixes go? master? nightingale-1.11?

I'm able to build and run nightingale-1.11, but ran into a few compilation issues in master.

The master branch does not build yet, it is for Nightingale 1.12 that will be based on Gecko 6 or later. The update is going on there.
For the current release we're using nightingale-1.11, as you can guess Nightingale 1.11.x resides in that. We also have sb-trunk-oldxul, which is kept in sync with the current Songbird trunk. sb-trunk-oldxul and nightingale-1.11 are kept in sync with cherry picking our changes (those that do affect not only 1.11, or course).

Besides the issues tracked in the issue tracker at github, we need help at master: getting it to build with the new gecko. I'm not into the status there, refer to ilikenwf (who might be online as he is near your timezone) for more information.

[ilikenwf]

I'm on the CST timezone, he's 3 hours ahead of me...

On master, you can see the majority of the changes we're having to do, module by module (well, when the compiler complains) if you look at the git logs. Otherwise, Mook and I can help you with that.

For working on the current player, I'd suggest you use sb-trunk-oldxul, as anything done in it can be cherry picked into both master and nightingale-1.11 ...it also builds...while it doesn't have many differences from the 1.11 branch, it is the "bleeding edge" branch at the moment since master doesn't work (yet).

Otherwise, we ought to talk with you sometime about some of the buildsystem on master - at the moment, we have to package the ancient make-jars.pl and preprocessor.pl scripts with our newer xulrunner builds, but these scripts have actually been replaced by python scripts and/or deprecated in recent history (see the ngale-deps/oldscripts directory on master).

The Nightingale/Songbird buildsystem uses these and looks for them, and when I tried in the past getting the buildsystem to use the new python based versions (ok, I just gave it the path of the new ones and crossed my fingers), the build breaks. I think that aspect of our buildsystem is actually python, as well...

Except for the python and perl in the xulrunner deps, here's a list of the python and perl within the nightingale tree...if you ever want to poke around with any of them.

Code:

./tools/scripts/aes.py
./tools/scripts/generate-nsis-manifest.py
./tools/scripts/make-macpkg-manifest.py
./tools/scripts/find-extension-config.py
./build/make-buildinfo.py

We have quite a bit of perl, too:

Code:

./tools/scripts/extract.pl
./tools/scripts/dbperflog2pglog.pl
./tools/scripts/libgen/libgen.pl
./tools/scripts/expand-jar-mn.pl
./tools/scripts/generate-update-snippet.pl
./tools/tracemalloc/fix-macosx-stack.pl
./build/autoconf/uniq.pl
./components/property/src/sbStandardProperties.pl

[ilikenwf]

...also forgot to mention, we've got people clamoring for an iPod extension. We have the opensource one from ...well, it's old...and then there's also the idea out there that we just build a new one around libgpod...

If you were bored, you could look into that too...

[dedalus]

This all sounds really good and I'm anxious to dig in. I'm gonna poke around the code a bit to get a general feel for it, then I'd be happy to jump on getting master built.

Here's the first stupid (hopefully won't be too many) stupid question I have: what's the correct way to enable a debug build that prints the logs?

I've tried just setting "ac_add_options --enable-debug" in nightingale.config and running make -f nightingale.mk. In addition, I also tried that setting with "debug" set as the release in build.sh and running build.sh. Each time it fails to find the mozilla-1.9.2/debug directory. And if I hack it past that, it fails to find xulrunner-1.9.2/debug directory since only the release versions exist. So obviously I'm doing something wrong.

Otherwise I can build the sb-trunk-oldxul branch without and problem... I just can't add --enable-debug. My primary motivation is to see the trace/debug logs to assist in tracing through the execution path.

Any ideas?

[ilikenwf]

For the debug builds, you actually need to build the xulrunner dep with debug builds enabled...it takes twice as long because it builds xulrunner twice (the build system is the one SB used, and is kinda bad right now)...but if you do that, it should work.

The tags on the deps correspond with the version you're wanting to build, by the way...xul 1.9.2 is so old that I had to build it under a Debian 6 VM, as debian has more "stable" (old...lol) gcc versions and libs. I ended up using gcc 4.4.

[dedalus]

Gotcha. I'll give it a shot.

[ilikenwf]

4 hours later...lol...

Well, on modern processors it's not so bad but it still takes a while.