Re: Staden on Ubuntu
[Lelanthran, your quoting is very hard to read - I tried to reformat your
mail so that it becomes clear who wrote what]
On Tue, 4 Nov 2008, Lelanthran Manickum wrote:
(crossposted to staden-devel, for some expert opinion on staden usage)
On Tue, Nov 4, 2008 at 12:20 PM, Andreas Tille <tillea@rki.de> wrote:
AT> On Tue, 4 Nov 2008, Lelanthran Manickum wrote:
AT> LM> I've debianised staden 1.7.0 and placed it here.
AT> Great - but you seem to have forgot to insert a link.
AT> LM> Unfortunately, I'm still working on a
AT> LM> few things:
AT> LM> 1. Generating the correct diff from the upstream package.
AT> What exactly do you mean by "generating the correct diff". If you are
AT> using dpkg-buildpackage, debuild or something like this the diff.gz and
AT> the *.dsc file which belong to the orig.tar.gz source will be generated
AT> automatically.
Am using debuild, but was unhappy about it (especially as the staden build
scripts/makefiles seem to touch a few of the binary files and caused debuild
to have an ascii text explosion on screen). I'd actually rather prefer to
keep the debian/ directory somewhere separate with the patches therein,
as then I can merely chuck the thing into a source control somewhere and
let others play around with it as well.
I do not really understand the general problem because every build
system finally calls dpkg-buildpackage (as debuild does) - at least to
my knowledge and the "ascii text explosion" (whatever this means) should
happen as well with other methods. But the strategy to keep patches
separately is fine and a good idea anyway.
But what I can find at
https://launchpad.net/%7Escubuntu-dev/+archive/+files/staden_1.7.0-0ubuntu26.tar.gz
(please ignore my ignorance - I have no idea how to access Ubuntu source
packages and thus I downloaded this file and the *.dsc) is in contrast
to what you wrote - everything is on one tarball - even the debian
directory which makes it a "native" package which staden is definitely
not. So I admit I did not really understand how you are actually building
the packages.
At the moment, the work I've done (changes, etc) are not in any source
control, and I am loathe to put it into bazaar on launchpad; I was thinking
about simply putting it onto sourceforge for now or,
Hmmm, putting a debian/ directory on Sourceforge seems to be not a
good idea.
if debian-med could
oblige with a walled-off area within their svn rep (so that I can't write elsewhere
within debian-med) I'd gladly put it there.
Well, there is no need (nor a chance IMHO) to create a sandbox in SVN for
you. There is a general trust that people will not disturb things that
massively. Several people are reading the commit changelogs - so the
danger that you harm anything is small. To access Debian Med SVN you need
at first to ask for an account at alioth.debian.org. Then we are able to
add you to the project.
AT> Or are you rather refering to the diffs you are creating in the debian/
AT> packaging directory by using tools like dpatch or quilt. In the Debian
AT> Med team we have a slight preference of quilt.
I have to say, having never used quilt but having fought somewhat with debuild,
I myself am inclined to try quilt :-)
Quilt and debuild are completely different pairs of showes. Quilt as well
as dpatch are just patch systems to maintain patches in the debian/ directory.
Debuild is a handy wrapper around dpkg-buildpackage as well as pdebuild
which uses pbuilder or svn-buildpackage if you are working in an SVN
repository. As I said: At some point you have to call dpkg-buildpackage
to finally build the package - you did not answered the question, how you are
doing this.
AT> LM> 2. Fixing AMD64 breakages.
AT> I'd suggest reporting these problems upstream. I have learned that
AT> upstream is quite responsive and is definitely interested in problems
AT> concerning AMD64.
The breakages I have are on launchpad - the build process does not use the
correct flags for AMD if AMD is detected. Since upstream for staden requires
the builder to manually edit files if they are building for AMD, upstream considers
this a partially solved problem. My changes to upstream sources in this regard
was to add in an automatic detection and change the flags. Unfortunately, this
hasn't worked (yet), but I am certainly very persistent and have no doubt that
I'd get this working sooner rather than later.
Ah, OK.
AT> LM> 3. Generating a seperate staden-doc package.
AT> This would be easy once you provide the URL to your work. We have
AT> a lot of examples you can follow. You might also consider using our
AT> common packaging SVN. If you check in your work we could easily add
AT> things you feel not able to do yourself. This has turned out quite
AT> effective in the past.
Thanks, this would be appreciated; who should I contact about this?
This mailing list is fine.
AT> LM> 4. Generating a .profile just for ubuntu so that the default
AT> LM> .profile is not needed.
AT> This seems to be a Staden specific .profile, right? I have to admit
AT> that I did not yet dived into Staden deeply enough to comment on this.
AT> If it is something about configuration it should be moved to
AT> /etc/staden/profile - but this is just a wild guess for the moment.
(Perhaps some staden experts can chime in here)
Or even /etc/staden.profile. However, currently the staden build process
uses a profile for building, and then copies that very same profile over
to the final destination to be used by the user. Without the profile, staden
apps refuse to run (not in path) and libraries cannot be found (library
path is different). Staden is different from most other *nix packages, in
that nothing goes into /usr/bin or /usr/lib, etc . Instead everything goes
into a 'staden' dir which has it's own 'bin', 'lib', etc.
In this case Debian policy demands /usr/lib/staden.
This is why the profile script has to be sourced before any staden program
is run - the script sets path and library search paths, etc that staden needs.
<snipped>
AT> If I remember right Staden needs io-lib and thus we tried to start with
AT> io-lib first. We tried to separate this lib (well a lib means it is useful
AT> for more than one application (not only Staden) and if I'm not missleaded
AT> there are other applications just do so) to enable more flexibility and
AT> avoid confusion between different versions of one lib in different
AT> applications.
AT> Moreover io-lib is a very bad name (I think upstream agreed to this). So
AT> we added at least 'staden-' as prefix and tried to add a patch which
AT>
AT> svn://svn.debian.org/svn/debian-med/trunk/packages/staden-io-lib/trunk/debian
I've checked this out - I'm not sure which version of io-lib I should patch with this,
but it looks good - neat and thorough :-)
I'm pretty sure Charles Plessy will comment on this.
AT> Once this is done we wanted to proceed with Staden. So far for a short
AT> explanation of our strategy. If you think you see a better way to
AT> get Staden packaged this is fine as well.
All humans think they have a better way, why should I be any different ;-)
Fine. As long as the result is compliant to Debian policy you are perfectly
free to go your way. ;-)
But to be serious, though, my intention behind the packaging was to first package
the large monolithic ball of code that is staden and make sure it works the
way the users expect it to.
I have no problem with this approach if it is helpful for our users. My
intend was just to explain the current status of our work on staden.
Thereafter, I intended to slowly strip out the libraries into packages of their own
(like IO-lib) and ensure that with each change staden is still working like it is
expected to.
Just go for it.
To accomplish this, I will need a test suite (even if I have to write it myself,
which I'd rather not) so that I can follow a cycle resembling this:
1. Build staden .deb
2. Generate test-results by running automated test-suite
3. Store test-results in source control
4. Make library independendent (remove it from staden) or make whatever other changes
I want to to either staden or .deb
5. Rebuild staden and libraries
6. Re-run test-suite and diff the results with the test-results from source control.
7. GOTO 4
For now, I just want to ensure that what I did works (it compiles, and seems to work,
but I need staden users to tell me this) before I start any ambitious plans.
I hope that some STaden users are hanging around here for testing ...
Finally, thank you all for bearing with me through my rather verbose ramblings, your
help and advice is very much appreciated, especially if it seems like I'm stumbling
about in the dark.
Well, as you might have noticed about Staden itself I'm also perfectly
stumbling in the dark. But I can be of help for technical Debian package
building issues. So please try to be a bit more verbose what you are
actually doing to obtain the binary from the source I've downloaded because
I'm a bit curious about your problem with debuild.
Kind regards
Andreas.
PS: Please try to use the usual quoting with '> ' in the beginning of each
quoted line. I'm sure your mail client will support this.
--
http://fam-tille.de
Reply to: