On Wed, Mar 21, 2007 at 12:01:50PM +0100, Romain Beauxis wrote:
> 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
> 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...
(a) it came with the dh_make template.
(b) now that I've gone over the rules file again, it means that I only
need to change one or two places when upstream bumps theirs, and if I
forget to, it'll fail noisily.
I suspect I'll have to do upstream's job anyway. I'm pretty sure the 1.1
-> 1.1.1 change should have bumped the soname (One of the structures
which contains arrays has had them grow from MAX_PATH bytes to 4096 bytes and
added an enum halfway through the structure)
I'll have to email them about that...
Old library, new code: all arrays after the enum are in the wrong spot: bad
New library, old code: reads random byte from array as enum value: bad
Yeah, looks like an ABI bump to me. Beh. I don't even want to think
about their handling of the JPWL stuff. The structures gain elements
at the end based on a #define the user code is expected to define before
including. It's not enabled for now, but once it is, it'll have to stay
enabled or it's ABI-bump (and Debian-specific ABI bump at that!) time.
> >> * 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... ;)
I removed the heading of the license section. The license itself is
still there, and now matches the upstream verbatim. The various FAQs on
the matter (and Policy, although it's not exactly explicit here) as well
as the couple of random packages I pulled up to check all seem to work
the way I've got it now.
>> 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 ? ;)
Yeah. I'd have to anyway, in case any new contributors or copyright
holders came on board. (As happened between 1.1 and 1.1.1, since one
contributor's copyright now includes 2007.)
> >> * 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....
Indeed, I tend to agree. Certainly my larger packages use dpatch by
preference. I just feel in this case I'd be adding more baggage than
I'm removing by adding even the lightweight dpatch into the mix.
(eg. slviewer will use dpatch. xmlrpc-epi doesn't, but I was planning to
until I saw how much of the PHP changes weren't relevant. It'll also
almost certainly never change, it's not been updated upstream for years,
and even the PHP version was last updated to build on gcc 4 I believe.
I'm happy to add dpatch to xmlrpc-epi. But for this, it's too much.)
> Also, I'm not yet convinced that you could not do it in another way that does
> not require those changes.
OK. I _have_ to remove -s from gcc call. See FTP-Master Reject FAQ, and
lintian complains. (I actually spent about a half-hour before I noticed
that, looking for the mystery 'strip' call, and blaming dh_strip for
breaking things. I even tried commenting out dh_strip... ^_^)
Changing the dependancy from .a to .so is indeed surpurfluous to the
build, since I'm making sure the library is there in the process, but
I want people to be able to take my extracted package, "make", and get
a result that roughly approximates mine.
The change from cp to mv has been removed in -2, that was only to
satisfy my own sense of symmetry, but it did help me catch the static
linking of the utils, which I'd overlooked initially. (Punishment for
running Makefiles I haven't read)
> >> 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..
That's true, but it was a shared object I was subsequently throwing
away, since it'd been built without -fPIC. Policy said that I couldn't
include shared objects without -fPIC, it didn't mention that I couldn't
build them at all. (And it prolly shouldn't. I need an AMD64 machine to
pbuilder on...)
> Could you explain me a litlle bit more the build system so that I could help
> you more ?
In the -1 upload's build-stamp rule:
# Build the .a file
$(MAKE) COMPILERFLAGS="$(CFLAGS)"
mv dist dist.static
$(MAKE) clean
# Build the .so file
$(MAKE) COMPILERFLAGS="$(CFLAGS) -fPIC"
rm dist/libopenjpeg.a
mv dist.static/libopenjpeg.a dist/
This builds the library without -fPIC, moves the .a file aside, and
cleans the tree.
It then builds the library with -fPIC, puts back the non-PIC .a, and
proceeds on with a PIC .so and a non-PIC .a, as per Debian policy.
However, AMD64 refuses to even _build_ a .so without -fPIC (which I did
not realise until you gave me the FTBFS) so I changed it to the below
in the -2 upload's build-stamp rule:
# Build the .a file without -fPIC
$(MAKE) COMPILERFLAGS="$(CFLAGS)" libopenjpeg.a
mv libopenjpeg.a libopenjpeg.a.nopic
$(MAKE) clean
# Build the .so file with -fPIC
$(MAKE) COMPILERFLAGS="$(CFLAGS) -fPIC" libopenjpeg-$(version).so
mv libopenjpeg.a.nopic libopenjpeg.a
This builds the .a file without -fPIC, moves the .a file aside, and
cleans the tree.
It then builds the .so file with -fPIC, puts back the non-PIC .a, and
proceeds on with a PIC .so and a non-PIC .a, as per Debian policy.
For reference, lintian would (and did, when I got it wrong earlier) pick
up the bad .so file if it'd actually survived the build, even on an arch
(like i386 and PowerPC, the two arches I build-test on) where it allows
me to build a non-PIC .so.
(You can also see here a use of the version variable set at the top
of the rules too. ^_^)
--
-----------------------------------------------------------
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
Paul.Hampson@Pobox.Com
Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
-- Kristian Wilson, Nintendo, Inc, 1989
License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------
Attachment:
pgpmMA7XK2hHC.pgp
Description: PGP signature