Re: Use of hfsprogs in Ubuntu
Keeping these lists in the loop by Rogerio's request. I like keeping
people in the loop, but I don't want to send messages where they're
unwanted; send me a private mail if you think we should trim the CC: list.
On Fri, 27 Jun 2008, Rogério Brito wrote:
First of all, thank you very much for your reply. I'm sorry that I could
not reply earlier.
No trouble! Long-awaited replies are the Debian Way! (-;
On Jun 21 2008, Asheesh Laroia wrote:
I got this mail because I'm on debian-powerpc.
Nice. I still have a PPC notebook (a G3 notebook) and I am keeping it until
it dies and I obviously want it to be as useful as possible.
I no longer have PPC machines, but I used to and obviously still know
people who do (and can emulate the Free Darwin system in qemu-powerpc
if necessary) - I would like to help maintain hfsprogs.
That is great. I would think that this would make hfsprogs be much
better maintained if I can have some help and discussion.
I generally focus on Debian, but I believe Ubuntu is pretty great too
and am using it right now. If you'll help with the Ubuntu side I'd be
happy to more directly contribute to that too.
I don't have problems with Ubuntu (and, in fact, I'm using a Ubuntu
install at this exact moment to write you this e-mail, because I don't
have access to my Debian machine right now).
I hope that we can cooperate well between Ubuntu and Debian.
I think the best thing to do is
(a) realize that the Gentoo guys are not going to break up their patch
into smaller pieces,
(b) separate it out ourselves, and
(c) hopefully get upstream to accept it.
Yes, that's exactly the thing that I had in mind. In fact, breaking up the
patch is a minor problem. It is getting newer upstream versions to compile
and work (and seeing which patches are needed under Debian) that is the
Wow, that's... interesting.
Does upstream use CVS? If so, I honestly think we should use
git-cvsimport and create a git repository for upstream, and then figure
out exactly which upstream patches break the Debian/Gentoo patches.
I would like to clean up many things, like:
* the variable types that Apple uses in their code to standard types (this
can be accomplished just by a sed/perl/awk substitution).
I think if we can hurry that patch along into upstream, that'd be great.
Might they accept it?
* the potentially non-cleanliness of 64-bit.
That'd be surprising, since Apple OS X targets 64-bit as I recall.
* the potential problems with little/big-endian machines.
Again - they have little and big endian machines now.... So I'm
* the use of magic constants in their code.
Blah. Would they accept patches fixing this? (Do we want to practically
reverse-engineer these constants?)
* the use of some ioctl's to see if they differ in Darwin and Linux (and
other BSD systems that Debian might support).
That's just for start.
I have, BTW, just talked with some Apple guys and it seems that they are
open to receiving patches. They are not completely open in the sense that
they allow access to their CVS/SVN/whatever repository, even of those parts
that are Free. :-(
Okay, so upstream is just releasing tarballs, and not even read access to
their CVS/SVN/whatever tree? So be it.
I think that the nicest way to do this would be to use a revision
control tool like git-buildpackage. I'm very familiar with git as-is.
While I am a tiny bit familiar with git, I'm not familiar with the
*-buildpackage's that are available in Debian. So, I think that I will end
up learning things along the way.
I'm admittedly not familiar with git-buildpackage, just svn-buildpackage.
But what we're going to do be doing basically amounts to maintaining a
fork with the *hopes* of upstream taking some of our patches, and I think
git is a great tool for that. So hopefully it will make sense for the
debian/ directory too. (-:
My sponsor for hfsprogs just had a problem with hfsprogs running under
powerpc and she needs some help soon. BTW, it would be kind of you if
you included her in your reply (firstname.lastname@example.org).
Let's work together and see a good exchanging filesystem being better
supported under Linux!
Never insult an alligator until you've crossed the river.