Re: RFS: CLAM, C++ library for audio and music
A Diumenge 08 Març 2009 00:26:49, Neil Williams va escriure:
> On Fri, 6 Mar 2009 19:57:06 +0100
>
> > > The debian/ packaging can be in upstream RCS just not in the tarball(s)
> > > released by upstream. If the upstream build process cannot cope with
> > > ignoring certain directories, it may be a good idea to fix to solve
> > > the "inconvenience".
> >
> > If such simple solution is allowed, i will do that in release scripts.
> > Now we export, tarball, export debian inside, and build source package.
> > We should then, export, delete debian, tarball, reexport debian and build
> > source package. Not that hard.
>
> It does sound like more work than it should require.
Its an script who does all the steps.
http://clam-project.org/clam/CLAM/scripts/doDebianPackages.py
Doing what i suggested would be some steps like:
svn export http://clam-project.org/clam/CLAM clam-1.4.0
rm -rf clam-1.4.0/debian
tar cvfz ....
svn export http://clam-project.org/clam/CLAM/debian clam-1.4.0/debian
... and build the source package
Manually could be error prone but it is a script, let it work.
> The main problem
> would appear that you are exporting and tarballing the entire export.
> Isn't there a way your build can generate the tarball directly?
> I haven't had time to look at the actual package but things like
> autotools have calls like 'make dist' which ignore all the generated
> stuff and just do the right thing. debian/ would only be added to such
> a tarball if mentioned explicitly in one of the Makefiles so it is
> trivial to remove such a section.
For your information we are using scons instead of autotools and make as build
system.
> Exporting and tarballing will avoid .svn directories, etc., but (as the
> debian/ directory shows) will end up including files that really don't
> deserve to be in the upstream tarball. Most builds generate lots of
> temporary and other status files which you really don't want in the
> tarball because they encode data that is entirely specific to the build
> machine.
> You either need to be very careful with the equivalent of
> 'make clean' or sort out upstream to have a way of creating the tarball
> that only includes the critical files that do not change between
> builds and are not architecture-dependent or dependent on the
> configuration of one particular machine. A lot of debian packages spend
> a lot of time cleaning up after inadequate (or stale) upstream build
> configurations.
Such files are not included in the svn. CLAM is automatically built on commit
under several flavors of debian, ubuntu, fedora, macosx and windows, so, for
example, if we wrongly commit some platform dependant file we soon detect it
as svn conflicts. For us is safer to do an export.
> > Anyway, as the upstream release manager I was serious when I said that
> > this piece of software can be dropped from this binary release. The
> > plugin that comes with those helper binaries was an experimental GSoC
> > project that i just enabled on the last package revision but it was
> > disabled until then, just like other experimental ones also included in
> > source but not compiled.
>
> If dropped, ensure that the reasons are described in the changelog.
Ok. I hope i can get the programs descriptions shortly anyway.
> > > > So, what to do now? anything else? are the packages ready be uploaded
> > > > by an sponsor?
> > >
> > > Not by me.
>
> Let me just clarify that too - it's because I don't generally sponsor
> packages using C++ which in turn is because most of those are KDE apps
> and I don't use KDE (hate it with a passion). See
> http://people.debian.org/~codehelp/#lang
Well, in fact CLAM is just Qt not KDE but i guess the same applies. Your
choice.
> > Ok, but I would like to receive more feedback about any other issues in
> > the current revision of those packages. If those you say are the only
> > problems i will be pretty happy, I could build valid debian packages in
> > short. But taking a look back i guess there could be more issues. ;-)
> > What else are we doing wrong?
>
> Right now, I don't have time to review such a large package, especially
> one using C++. You may or may not be doing anything particularly wrong,
> it is just that sponsors are volunteers with other priorities and we do
> what we can but there are quite a lot of packages on mentors that never
> get a sponsor. Patience is the key - along with a few pings to this
> list once in a while.
Well, no problem. We are also volunteers so i understand. I hope we can find
an sponsor soon or someone that could take it a closer look to find more
issues. If we waited for five years since the first debianization, i guess we
can wait for some more time... a couple of hours? ;-)
Thanks a lot for your hints. They have been very helpfull.
Regards.
David.
--
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
http://www.iua.upf.edu/~dgarcia
Reply to: