[pythonian4000]

Yes, the iPod extension uses the outdated API and so while updating the max version number lets it install fine, it just sits there and does nothing

I have just received an iPod Touch 4G and my first week's experience with iTunes has left me with great loathing, so I have decided to make the iPod extension my summer project. I am currently messing around trying to port the old Songbird build system to get the latest libgpod to compile in Windows (amid University exams!) which will help for ordinary iPods (shuffles etc) though Windows support will be troublesome for the iOS devices (libgpod uses libimobiledevice for this support, which uses usbmuxd, which uses the Linux kernel --> much hacking required!)

GNU/Linux will be much easier from the libgpod perspective, although the system libgpod won't be used as there are some Songbird patches that have been applied to make things easier on our end. From what I have seen so far though it seems that at least some of the Songbird patches are now in the main trunk, so it *may* be possible to get the rest included - once I have worked out what patches are still patches, I will go have a chat with the libgpod guys about it.

The other big thing to do, of course, is to port the extension itself to the new API. I will start on that sometime in mid-November after the end of Uni, but there is a LOT of code to work through and understand, so that will take some time! (It doesn't help that I am spread across three islands and part of a subcontinent for a month and a half over Christmas ).

[Hakon]

Ok, gues I used an older trunk version then.

[gat]

Nightingale C.O.S. was supposed to be released last month.

That did not happen.
Stevo is still committing updates to the SVN account at sf.net/ngale.
In the meanwhile, Songbird has released yet another contributed build for G.N.U./Linux filled with binary blob-age. I believe that, especially since 1.9.3 doesn't have a contributed build for x86_64, the first release should be based on 1.8.0.

A .spec file for RPM & a control file for DEB should probably be made and posted on the getnightingale.* web-site because these are probably likely to get tested as they build packages and make them install-able on an easily removable manner for those who use only package managers.

The sooner that a 1.8.0 release is released, if 1.8.0 is chosen, the more exposure and testing will be ready for other future releases (1.9.3). I would suggest that if possible whatever type of installer be it sh, Mozilla style, or whatever that an alpha is released soon. The first release does not have to be a final release. Maybe a forum thread for all bugs of the pre-final releases so that the forum doesn't get crowed if the desired bugzilla (whatever bug support) is not ready.

[pythonian4000]

(02-18-2011, 04:01 PM)gat Wrote: Nightingale C.O.S. was supposed to be released last month.

That did not happen.
Stevo is still committing updates to the SVN account at sf.net/ngale.
In the meanwhile, Songbird has released yet another contributed build for G.N.U./Linux filled with binary blob-age. I believe that, especially since 1.9.3 doesn't have a contributed build for x86_64, the first release should be based on 1.8.0.

A .spec file for RPM & a control file for DEB should probably be made and posted on the getnightingale.* web-site because these are probably likely to get tested as they build packages and make them install-able on an easily removable manner for those who use only package managers.

The sooner that a 1.8.0 release is released, if 1.8.0 is chosen, the more exposure and testing will be ready for other future releases (1.9.3). I would suggest that if possible whatever type of installer be it sh, Mozilla style, or whatever that an alpha is released soon. The first release does not have to be a final release. Maybe a forum thread for all bugs of the pre-final releases so that the forum doesn't get crowed if the desired bugzilla (whatever bug support) is not ready.

The SVN repo is taken straight from Songbird's 1.8 release branch, so that will be the version that is initially released. As for an actual release, stevo has been working on trying to remove the dependence on inbuild dependencies (P.N.I.) so that it relies (hopefully) solely on external libraries that the user has installed. This is actually a lot of work, as the vendor dependencies are not well documented and Songbird patched many of them to suit their needs, but there has been progress.

Meanwhile, I am spending a lot of my spare time currently trying to get a build system up and running (I only have Continuous Integration testing working at present), which will then at least give us something to work with. I am planning on including packaging in this as well, so that rather than a .tar.gz file we will have RPMs and DEBs and whatever else we can find support for.

Oh, and the other thing that is required to happen before we can release ANYTHING is that re-branding has to be complete - this is a requirement of the Songbird license. I don't know if that extends to the default feather, but certainly the now-decided logo and all relevant strings etc. need changing, which stevo is also working on.

[gat]

Good
&
Good.

As for the branding, LibreOffice had pre-releases that "may" not have had complete/correct re-branding. Is this not an option for us/for our licence? (This release statement is no longer, since LibreOffice had its first official release.)

[pythonian4000]

(03-17-2011, 03:04 PM)gat Wrote: Good
&
Good.

As for the branding, LibreOffice had pre-releases that "may" not have had complete/correct re-branding. Is this not an option for us/for our licence? (This release statement is no longer, since LibreOffice had its first official release.)

See this thread about the initial builds coming out of the Nightingale BuildBot I am working on.

[GeekShadow]

So about development I see the project going nowhere :/
I'm working on the feather right now, but I can't reach stevo, even on IRC where he is online...

If I'm correct we are building from 1.8.1, but we should build from 1.9.3 or even the trunk since there are significant speed improvements + gecko 1.9.2 base.

Again, I can't deal with setting up repo and building stuff, but I would be happy to work on add-ons and feather.

Also we really need more people !

[freaktechnik]

I would help if there would be precise tasks. But since stevo just has a generalbuglist ("fix bugs" etc.) I don't know what to do. the other side is, that I haven't really looked into the songbird code yet.

[pythonian4000]

I agree that 1.9.3 has significant speed improvements, but FWIR the reason for starting with 1.8.1 was due to that being the last version that ran decently on GNU/Linux systems. Though I haven't tested the newer ones yet. The other main issue is that due to it being an SVN repo there is no room for direct contribution without commit rights (though eventually any and all patches should be submitted via the tracker rather than being directly pushed to the repo, for the sake of testing and verification - but again, this needs a wider base of people to support it, rather than everyone depending on stevo.

[GeekShadow]

me I guess ?