16 Jan
2014
16 Jan
'14
11:44 p.m.
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
17 Jan
17 Jan
1:34 a.m.
New subject: [trinity-devel] hal & 3.5.13-sru - future -> argument to bring hal in-house
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
--
David C. Rankin, J.D.,P.E.
4038
days inactive
4039
days old
1 comments
2 participants
participants (2)
-
Darrell Anderson -
David C. Rankin