All, what is the consensus? Will you need hal and if so, would you help update it if Tim set it up here?
Me personally? No. :)
How many Trinity users are still using HAL based distros? Does Trinity build on those older releases?
The oldest Slackware release upon which I can build Trinity is 13.1, which is HAL based. Trinity won't build on older releases for other reasons but HAL is not one of those reasons.
Rather than supporting a full blown HAL git branch, how about just uploading upstream patches? Nothing more. For example, we don't have a wv2 branch, but we do need knowledge where to find wv2 patches. Likewise for HAL.
Right now we already have a git module called thirdparty. The only submodule now is libreoffice. Add appropriate submodules as needed: wv2, HAL, etc. Add the necessary patches there.
Post a wiki article with links to the thirdparty patches.
Darrell
On 01/16/2014 05:44 PM, Darrell Anderson wrote:
Me personally? No. :)
How many Trinity users are still using HAL based distros? Does Trinity build on those older releases?
The oldest Slackware release upon which I can build Trinity is 13.1, which is HAL based. Trinity won't build on older releases for other reasons but HAL is not one of those reasons.
3.5.13 will build on anything, R14??
Rather than supporting a full blown HAL git branch, how about just uploading upstream patches? Nothing more. For example, we don't have a wv2 branch, but we do need knowledge where to find wv2 patches. Likewise for HAL.
The issue with hal is a bit more complicated. While the tarball hasn't been updated since 0.5.14, there have been a number of changes to the git repository and a number of branches created dealing with suspend/resume issues, etc. I don't really have much confidence that the old 0.5.14 tarball contains any of the fixes presently in the git tree. That's why I thought it might take a bit more than getting a collection of patches together. The other issue is the main hal.patch is almost as large as the 0.5.14 tarball at present. I know for one, relying on a 1 meg years old patch is dicey at best.
Right now we already have a git module called thirdparty. The only submodule now is libreoffice. Add appropriate submodules as needed: wv2, HAL, etc. Add the necessary patches there.
This is a good idea and I think it will work for hal once it is cleaned up. The thirdparty directory would make an ideal place for patchsets for external sources. (name is kind of wonky, but works) Something like the following containing the current patchsets for each package:
thirdparty apetag hal hal-info libkarma libnjb libutempter mt-daapd musepack-tools wv2 xmedcon
What I would also like to see is 1 generic patch in each directory that is the culmination of all current patches that are generic to the code for each app. Not 7 or 10 individual patches per app. The 'wv2-tde.patch', etc.. could serve as the naming convention for the combined patchsets, with a standard 'patch Np# -i filename' install requirement.
Post a wiki article with links to the thirdparty patches.
+1
-
Darrell Anderson -
David C. Rankin