Re: RFS: openjpeg
Le mercredi 21 mars 2007 09:44, Paul TBBle Hampson a écrit :
> On Wed, Mar 21, 2007 at 02:38:44AM +0100, Romain Beauxis wrote:
> > Le mardi 20 mars 2007 04:17, Paul TBBle Hampson a écrit :
> >> version=1.0.0
> >> major=1
> >
> > stuff does not seem right, and version is not the one provided..
>
> The soversion is 1.0.0 in the build I have here... What'd it come up
> with for you?
Hum...
Seems I was too spleepy :)
BTW, I don't get why you need to define the soversion in the debian/rules.
Isn't this supposed to be defined by upstream ?
Remenber that if defined in rules, you'll have to take care of this for each
upstream release... And a soversion is supposed to be carefully bumped when
making changes to the API/ABI, so you'll then have to do upstream's job on
this...
> The link is removed two lines later.
>
> > * debian/control: there is a typo in one description. Also, you should
> > rename libjpeg2000-utils to something like jpeg2000-utils since this
> > package does not provide any lib..
>
> Hmm. I was going off the example of libgd-utils and libjpeg-tools, as
> well as Junichi Uekawa's packaging guide, but I will take openjpeg-tools
> under consideration. (Assuming that's what you meant, not that I rename
> the entire thing to *jpeg2000*.)
Of course no :)
> > * debian/copyright: You repeated copyright for licence, these are
> > different sections.. Also download source should be a webpage or a ftp
> > site, but not the tarball.
>
> Strange. Policy requires a verbatim copy of the copyright and license,
> and that's verbatim from the website.
>
> I've fixed this by removing the "License" seperator and the first set of
> copyright statements, so it's now both verbatim and doesn't describe the
> copyright holder's list as the license.
No..
What I meant is that sentences like "copyright (c) 1492 Christopher Colombus"
are copyright statements, they don't have to be listed in the licence
section..
You should simply have removed these sentences from the licence section, not
remove the licence section... ;)
> As for the upstream URL, the copyright FAQ [1] states that should be the
> URL for the upstream source... That could be clearer, they obviously
> mean the _other_ "source". Fixed, thanks.
So you would have to update copyright file for each upstream release ? ;)
> > * In the diff.gz: your modifications to source should be kept as patch
> > and applied at build time. This way they'll remain into the debian/
> > directory. Also, you may check wether you could build the package without
> > those modifications...
>
> I'm not going to apply dpatch to something so trivial. The number of
> DD's who dislike dpatch is significant enough that I don't feel this
> package is changed enough to require it, and make someone else's life
> harder down the road for the sake of 6 changed lines.
>
> The package _builds_ without those changes, but isn't policy-compliant.
> (ie. the stuff in libopenjpeg-tools ends up statically linked, and the
> debug version of the library ends up stripped. The 'mv' change will go
> away, the preceeding change should be sufficient)
We'll speak on this later when it will be time for your to update to a newer
upstream version..
However, as for *my* point I will not sponsor without patch in any way, I
think all modifications on source related to the diff.gz are not a good
practice, to *my* point of course....
Also, I'm not yet convinced that you could not do it in another way that does
not require those changes.
> > And... You have a nice FTBFS for amd64:
> >> /usr/bin/ld: ./libopenjpeg/bio.o: relocation R_X86_64_32 against `a
> >> local symbol' can not be used when making a shared object; recompile
> >> with -fPIC ./libopenjpeg/bio.o: ne peut lire les symboles: Mauvaise
> >> valeur
> >
> > As written in the message, you have to pass the -fPIC option at build
> > time..
>
> The debian/rules file builds it firstly without -fPIC, as Debian policy
> requires that .a objects are build without it, and then rebuilds with
> -fPIC to generate the .so. I didn't realise it was going to fail to
> build in that instance...
Hum... If I read the message, I got "when making a shared object" so it seems
to mean that the -fPIC was indeed not passed to the compiler when building
*shared* object..
Could you explain me a litlle bit more the build system so that I could help
you more ?
Romain
Reply to: