staden-devel Mailing List for Staden Package

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

[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 <ti...@rk...> 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

2004	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec
2005	Jan	Feb	Mar	Apr	May	Jun (2)	Jul	Aug	Sep	Oct	Nov	Dec
2007	Jan	Feb	Mar	Apr	May (2)	Jun (4)	Jul (1)	Aug (1)	Sep	Oct (2)	Nov (5)	Dec (2)
2008	Jan (7)	Feb (2)	Mar (3)	Apr (2)	May	Jun (3)	Jul	Aug	Sep (4)	Oct (3)	Nov (3)	Dec (1)
2009	Jan	Feb (4)	Mar	Apr (3)	May (3)	Jun (8)	Jul (2)	Aug (2)	Sep (3)	Oct (3)	Nov (1)	Dec (6)
2010	Jan	Feb	Mar	Apr	May (1)	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2013	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug (1)	Sep	Oct (1)	Nov	Dec
2014	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec
2015	Jan (1)	Feb (2)	Mar (4)	Apr (5)	May (2)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

staden-devel Mailing List for Staden Package

staden-devel — Staden Package developers chat.