Re: RFS: openjpeg

[Cyril Brulebois]

On 11/01/2008, Robin Cornelius wrote:
> I'm quite happy for the package to enter the pkg-phototools version
> control system if that is what the group would like and finalise any
> changes there.

I should have made it clear: that was a proposition. :)

> Currently I am hosting the package on my own (publicly accessible) svn
> server, but it makes more sense for these packages to move to alioth
> as they start to be finalised for/enter Debian.

Do you want me to take care of creating the git repository and injecting
your revisions there? According to a quick search on alioth, I guess
you're robinc-guest (so that I add you to the group).

> PS: I am not currently subscribed to pkg-phototools so please CC me or
> ensure a reply goes to debian-mentors (which i am subscribed).

Let me know once you're subscribed, we'll take care of everything on the
-devel list.

Cheers,

-- 
Cyril Brulebois


pgplf2QsOCHnb.pgp
Description: PGP signature

Re: RFS: openjpeg

[Robin Cornelius]

On Jan 11, 2008 1:02 PM, Cyril Brulebois
<[EMAIL PROTECTED]> wrote:
> On 11/01/2008, Robin Cornelius wrote:
> > Openjpeg is a JPEG2000 library and associated tools for the
> > encoding/decoding of jpegs that use the JPEG2000 format. It is a
> > required component of the secondlife viewer (#406335) but also has a
> > wider general use for image processing.

> 
> Do you know about pkg-phototools? It looks to me that openjpeg is quite
> a good candidate for inclusion there, so you might want to read more on
> http://pkg-phototools.alioth.debian.org/. Note that Bernd Zeimetz is a
> member of this team as well, and might be interested to review your
> package within the team, since he needs it for a gimp plugin.
> 
>

Hi Cyril,

I was not aware of the pkg-phototools group, but yes this seems an
appropriate location for openjpeg. I had previously seen
correspondence with Paul Hampson (who started this package) regarding
using openjpeg for a Gimp plugin and so i was aware there was general
interest.

I'm quite happy for the package to enter the pkg-phototools version
control system if that is what the group would like and finalise any
changes there. Currently I am hosting the package on my own (publicly
accessible) svn server, but it makes more sense for these packages to
move to alioth as they start to be finalised for/enter Debian.

PS: I am not currently subscribed to pkg-phototools so please CC me or
ensure a reply goes to debian-mentors (which i am subscribed).

Regards

Robin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: openjpeg

[Cyril Brulebois]

On 11/01/2008, Robin Cornelius wrote:
> Openjpeg is a JPEG2000 library and associated tools for the
> encoding/decoding of jpegs that use the JPEG2000 format. It is a
> required component of the secondlife viewer (#406335) but also has a
> wider general use for image processing.

Hi.


Do you know about pkg-phototools? It looks to me that openjpeg is quite
a good candidate for inclusion there, so you might want to read more on
http://pkg-phototools.alioth.debian.org/. Note that Bernd Zeimetz is a
member of this team as well, and might be interested to review your
package within the team, since he needs it for a gimp plugin.


Cheers,

-- 
Cyril Brulebois


pgprDW6xB3Ky6.pgp
Description: PGP signature

RFS: openjpeg

[Robin Cornelius]

Dear mentors,

I am looking for a sponsor for my package "openjpeg".

* Package name: openjpeg
  Version   : 1.3-1
  Upstream Author : OpenJPEG Team <[EMAIL PROTECTED]>
* URL   : http://www.openjpeg.org/
* License  : BSD
  Section   : libs

It builds these binary packages:
libopenjpeg-dbg - Debug symbols for libopenjpeg, a JPEG2000 library
libopenjpeg-dev - Development files for libopenjpeg, a JPEG2000 library
libopenjpeg2 - JPEG2000 image compression library
openjpeg-tools - JPEG2000 image compression codec tools

The package appears to be lintian clean.

This upload would close bug #413987
This upload would unblock one blocker on #406335

Openjpeg is a JPEG2000 library and associated tools for the
encoding/decoding of jpegs that use the JPEG2000 format. It is
a required component of the secondlife viewer (#406335) but also
has a wider general use for image processing.

The library and tools are written in C.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/o/openjpeg
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/o/openjpeg/openjpeg_1.3-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Robin Cornelius


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: openjpeg (Sponsor still needed)

[Paul TBBle Hampson]

On Wed, May 30, 2007 at 09:22:16PM +1000, Paul TBBle Hampson wrote:
> On Thu, Apr 26, 2007 at 07:54:40PM +0200, Bernd Zeimetz wrote:
>>> Package still at the above URL, version is now 1.1.1-4, and I am
>>> satisfied (to the best of my knowledge) that the packaging is in a fit
>>> state for upload, barring a dpkg-buildpackage -v 0 -sa to ensure the ITP
>>> bug is closed by the full-source upload.

>> are there any news on this? Having openjpeg in Debian would be appreciated.

> Nope.

I've just uploaded openjpeg 1.2 packaging. Soversion has bumped to 2.

http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=openjpeg

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpJkBgBeBNy3.pgp
Description: PGP signature

Re: RFS: openjpeg (Sponsor still needed)

[Paul TBBle Hampson]

On Thu, Apr 26, 2007 at 07:54:40PM +0200, Bernd Zeimetz wrote:
>> Package still at the above URL, version is now 1.1.1-4, and I am
>> satisfied (to the best of my knowledge) that the packaging is in a fit
>> state for upload, barring a dpkg-buildpackage -v 0 -sa to ensure the ITP
>> bug is closed by the full-source upload.

> are there any news on this? Having openjpeg in Debian would be appreciated.

Nope.

However, now that the second-life viewer is packaged, with only a
license issue keeping it from going from ITP to RFS, I'm pinning my
hopes on a DD being keen enough for slviewer to also sponsor its two
dependancies into the archive at the time.

(I did kind of hope the PHP team would sponsor xmlrpc-epi, but after
an initially-interested response from one of the team, I haven't
heard back from them, and I wasn't ever successful in convincing
pbuilder-uml to build php5 for me, so I don't know if it would even
work with PHP as I expect.)

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgp7sKjcLoSu3.pgp
Description: PGP signature

Re: RFS: openjpeg (Sponsor still needed)

[Bernd Zeimetz]

Heya,

> Package still at the above URL, version is now 1.1.1-4, and I am
> satisfied (to the best of my knowledge) that the packaging is in a fit
> state for upload, barring a dpkg-buildpackage -v 0 -sa to ensure the ITP
> bug is closed by the full-source upload.

are there any news on this? Having openjpeg in Debian would be appreciated.


Thanks,

Bernd

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: openjpeg

[Paul TBBle Hampson]

On Wed, Apr 04, 2007 at 08:01:19PM +0200, Michelle Konzack wrote:
> Hello Romain,

> Am 2007-03-21 14:25:24, schrieb Romain Beauxis:
>> More comments:
>> * You have lintian warnings about missing manpages. They are required so you 
>> may fix this.

> Ehm, a manpage for a executable is clear, but for a LIB?

This was in reference to the programs in openjpeg-tools

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpzKu3Cdpmhd.pgp
Description: PGP signature

Re: RFS: openjpeg

[Michelle Konzack]

Hello Romain,

Am 2007-03-21 14:25:24, schrieb Romain Beauxis:
> More comments:
> * You have lintian warnings about missing manpages. They are required so you 
> may fix this.

Ehm, a manpage for a executable is clear, but for a LIB?

Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: RFS: openjpeg (Sponsor still needed)

[Paul TBBle Hampson]

On Tue, Mar 20, 2007 at 02:17:06PM +1100, Paul TBBle Hampson wrote:
> Dear mentors,

> I am looking for a sponsor for my package "openjpeg".

> * Package name: openjpeg
   Version : 1.1.1-4
>   Upstream Author : OpenJPEG Team <[EMAIL PROTECTED]>
> * URL : http://www.openjpeg.org/
> * License : BSD (2-clause as per 
> http://www.openjpeg.org/BSDlicense.txt)
>   Section : libs

> It builds these binary packages:
> libopenjpeg-dev - JPEG 2000 image compression codec library development files
openjpeg-tools - JPEG 2000 image compression codec library shared objects
> libopenjpeg1 - JPEG 2000 image compression codec library shared objects
> libopenjpeg1-dbg - JPEG 2000 image compression codec library shared objects

> The upload would fix these bugs: 413987

> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/o/openjpeg
> - Source repository: deb-src http://mentors.debian.net/debian unstable main 
> contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/o/openjpeg/openjpeg_1.1.1-4.dsc

> It is a dependancy of the second-life viewer application, and Bernd Zeimetz
> intends to package a Gimp plugin that uses it to. [1]

> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413987;msg=10

(I've dequoted the differences from the original RFS)

Romain is no longer taking an interest in this package.

So I remain in need of a sponsor.

Package still at the above URL, version is now 1.1.1-4, and I am
satisfied (to the best of my knowledge) that the packaging is in a fit
state for upload, barring a dpkg-buildpackage -v 0 -sa to ensure the ITP
bug is closed by the full-source upload.

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpaoknGHcTho.pgp
Description: PGP signature

quilt, mq and guilt (was Re: RFS: openjpeg)

[Pierre THIERRY]

Scribit Paul TBBle Hampson dies 31/03/2007 hora 00:58:
> I'm going to have to have a look at quilt. I was under the impression
> that it was a rather complicated patch-management system, used for
> example by Andrew Morton for managing the -mm tree pre git.

quilt is just a must-know IMHO when you deal with patches. Although now
there are better alternatives, inspired by it. There are Mercurial
queues, which is quilt integrated in Mercurial, and its copy for git,
guilt. I never used guilt, but if quilt is a great tool, mq is a
wonderful one!

Not only can you manage efficiently a stack of patches (I even think
it's faster than quilt, and you don't have filenames nightmares as it's
not shell scripts), check wether they apply, refresh them when there's
fuzz, but you can let Mercurial make the book-keeping for you (like
knowing which files were modified, which you have to tell quilt manually
before doing it, for instance) and version control the patches and then,
as it's a DVCS and the version control is done in a separate repository,
it lets you publish your patches.

When working with mq on a project versioned with Mercurial, you can even
trivially prevent Mercurial from pulling upstream changes while you
still have your patches applied.

All in all, it's a real pleasure to use it.

Guilt is meant to provide the same features for git instead of
Mercurial.

Distributively,
Pierre
-- 
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A


signature.asc
Description: Digital signature

Re: RFS: openjpeg

[Damyan Ivanov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -=| Paul TBBle Hampson, 30.03.2007 17:58 |=-
> On Fri, Mar 30, 2007 at 12:06:26AM +0300, Damyan Ivanov wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
> 
>> - -=| Paul TBBle Hampson, 29.03.2007 19:37 |=-
>>> And
>>> although I haven't done it in a while, I don't recall dpatch-edit-patch
>>> being particularly fun to use on a non-applying patch...
> 
>> My experience exactly. This is why I use quilt instead :)
> 
> I'm going to have to have a look at quilt. I was under the impression
> that it was a rather complicated patch-management system, used for
> example by Andrew Morton for managing the -mm tree pre git.

It was used for this, yes. But still I don't think it is complicated. I
find it more natural than dpatch. I used to think like you, but once I
actually read the quilt manpage and tried it in action, I never looked
back at dpatch again. There is some learning curve, but it is surely not
as complicated as "used by -mm tree pre-git" would suggest.

That said, you are of course free to use whatever way of patch-handling
you feel comfortable with. It seems that some sponsors have preference
of how this is done, that's all.


dam
- --
Damyan Ivanov   Modular Software Systems
phone +359(2)928-2611, 929-3993  fax +359(2)920-0994
mobile +359(88)856-6067  JID [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGDSrIHqjlqpcl9jsRAoeRAKCs0btIm1PzKnfGSMVW7txL3VBMwwCgsYYR
TJarrAR8M26qRlkXKK3DhSQ=
=Zo3B
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: openjpeg

[Paul TBBle Hampson]

On Fri, Mar 30, 2007 at 12:06:26AM +0300, Damyan Ivanov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1

> - -=| Paul TBBle Hampson, 29.03.2007 19:37 |=-
>> And
>> although I haven't done it in a while, I don't recall dpatch-edit-patch
>> being particularly fun to use on a non-applying patch...

> My experience exactly. This is why I use quilt instead :)

I'm going to have to have a look at quilt. I was under the impression
that it was a rather complicated patch-management system, used for
example by Andrew Morton for managing the -mm tree pre git.

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgp4zDeK50hvv.pgp
Description: PGP signature

Re: RFS: openjpeg

[Paul TBBle Hampson]

On Fri, Mar 30, 2007 at 12:32:41AM +0200, Romain Beauxis wrote:
> Le jeudi 29 mars 2007 18:37, Paul TBBle Hampson a écrit :
>> Hmm. I don't actually blindly apply .diff.gz to new upstream versions. I
>> usually just copy the debian/ directory across from my old one, inspect
>> the .diff.gz for any changes outside the debian/ directory, and consider
>> whether they are still needed, and what form they should take.

> You have to keep in mind that you will not be the only one to work on your 
> package. You cannot assume that you'll maintain them forever, and even if it 
> would be the case, there may have NMUs, or security updates that will need 
> that another maintainer work on your package. 

And as I said before, I have seen the opinion expressed by DDs that
dpatch makes it harder to do exactly that.

And frankly, I can rely on every DD being able to handle the basic
Debian packaging system, I don't think I need to expect every DD to grok
dpatch, quilt or cdbs (Hell, _I_ don't grok cdbs) in order to make a
small change to my package, without good cause.

In short, I'm aiming for the lowest common denominator.

> According to this, everything that makes your package easier to understand 
> and 
> handle for an external maintainer is a good thing, and using patches that 
> explain what they do, one for each different purpose *is* a good packaging 
> practice.

I agree that it's a good packaging practice. I just don't agree that it
needs to be applied to every package.

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpEzK09Wy8Hi.pgp
Description: PGP signature

Re: RFS: openjpeg

[Romain Beauxis]

Le jeudi 29 mars 2007 18:37, Paul TBBle Hampson a écrit :
> Hmm. I don't actually blindly apply .diff.gz to new upstream versions. I
> usually just copy the debian/ directory across from my old one, inspect
> the .diff.gz for any changes outside the debian/ directory, and consider
> whether they are still needed, and what form they should take.

You have to keep in mind that you will not be the only one to work on your 
package. You cannot assume that you'll maintain them forever, and even if it 
would be the case, there may have NMUs, or security updates that will need 
that another maintainer work on your package. 
According to this, everything that makes your package easier to understand and 
handle for an external maintainer is a good thing, and using patches that 
explain what they do, one for each different purpose *is* a good packaging 
practice.


Romain
-- 
Everyone is crying out for peace, yes
None is crying out for justice
I don't want no peace
I want equal rights and justice

Re: RFS: openjpeg

[Damyan Ivanov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -=| Paul TBBle Hampson, 29.03.2007 19:37 |=-
> And
> although I haven't done it in a while, I don't recall dpatch-edit-patch
> being particularly fun to use on a non-applying patch...

My experience exactly. This is why I use quilt instead :)


dam
- --
Damyan Ivanov   Modular Software Systems
phone +359(2)928-2611, 929-3993  fax +359(2)920-0994
mobile +359(88)856-6067  JID [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGDCpSHqjlqpcl9jsRAoOjAJ9FBDt3pY6iQ1si5eFvy99/WsLOiwCfanbv
VwUGAcoBXrRsDMOkLrUk6IU=
=3BSr
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: openjpeg

[Paul TBBle Hampson]

On Thu, Mar 29, 2007 at 04:27:41PM +0200, Romain Beauxis wrote:
> Le jeudi 29 mars 2007 16:18, Paul TBBle Hampson a écrit :
>> And again, if I was going to keep the debian/ directory in an external
>> version-control system, dpatch would be the way to go.

>> Since I'm not going to, the Debian archive already has a system for
>> storing such trivial patches, in the .diff.gz.

>> Despite this, and because I'm obviously going to be overruled here again
>> no matter what I say, here's a version using dpatch. At least dpatch use
>> is _easy_ to revert later.

> Paul, we'll talk about this later, when you'll have to update your package to 
> a new upstream release, when the diff.gz may not apply cleanly and you'll end 
> up seperating what's for upstream sources to what's for debian/ in the 
> diff.gz and finally patching new upstream with a new patch... That is 
> precisely the work I advise you to do in the first place: extracting a 
> patch..

Hmm. I don't actually blindly apply .diff.gz to new upstream versions. I
usually just copy the debian/ directory across from my old one, inspect
the .diff.gz for any changes outside the debian/ directory, and consider
whether they are still needed, and what form they should take.

When dpatch is in the mix, it's the same procedure, except I need to
check each dpatch, rather than just running through the entire .diff.gz,
and I also need to keep in mind any relevant changes made by earlier
dpatches to the same files. And also not get confused by existing
dpatches that aren't in 00list. If you're unlucky, you need to reroll a
non-applying dpatch. If you're really unlucky, you then have to reroll
subsequent dependant (and possibly non-applying) dpatches too. And
although I haven't done it in a while, I don't recall dpatch-edit-patch
being particularly fun to use on a non-applying patch...

Either way, interdiff (via debdiff) then gives me a clue as to whether
I've missed anything, and the results are much much easier to use
without dpatch.

Seriously, interdiff + dpatch means you're diffing diff files, the
avoidance of which is the whole point of interdiff. Maybe some kind of
dpatch-specialised interdiff wrapper... Hmm, I might look into that.
I've also just realised that cowdancer integration would speed up
dpatch-edit-patch quite nicely.

In my experience, dpatch introduces more complication in the mix.

And that complication is not worth it for five lines of changes between
two Makefiles.

> Sorry for giving you the impression that I overruled your will, but seriously 
> we'll discuss this later and I'm really convinced that
>  you may not have the same opinion.

We've already established I've not the same opinion. I really don't
expect that it'll change at this stage, either. I've presented all
my positions on the topic, and the strongest arguement I've heard back
was Charles' observation about debian/ directories becoming browseable
at some point in the future.

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpOSZTQoG7nx.pgp
Description: PGP signature

Re: RFS: openjpeg

[Paul TBBle Hampson]

On Fri, Mar 30, 2007 at 12:09:12AM +0900, Charles Plessy wrote:
> Le Fri, Mar 30, 2007 at 12:18:23AM +1000, Paul TBBle Hampson a écrit :

>> Again, I question the idea that a dpatch is _easier_ to parse than the
>> .diff.gz.

> Actually, I am sorry to critisize general problems of diff.gz in a
> discussion about the particular one of your package, without having
> looked at it.

> It's just that sometimes I have a hard time finding useful information
> in the some diff.gz when they have a lot of autoconf gizmo in, or many
> manpages, xpm icons, desktop files, or any other "noise".

I find the trick with reading a .diff.gz is to ignore anything that's
in the debian directory, since that's all created (or at least, you
don't really care that much what's changed from upstream), so the
existent files are sufficient.

I also am used to skipping autoconf-generated files in the .diff.gz,
since the changes are never of actual interest, compared to the fact
that they have been changed.

That should trim the noise out almost entirely.

I don't know if this is actually true, deliberate, or just
co-incidental, but I believe it's the case that a .diff.gz has the
non-debian/ stuff, then the debian/ stuff.

> I agree that in the cases of trivial packages with a slim diff.gz, the
> discussion becomes quite academic.

Indeed, and as I've been saying, had the changes to the upstream tarball
been more than trivial, dpatch would have been the first thing I did.

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpkbXUrITjPE.pgp
Description: PGP signature

Re: RFS: openjpeg

[Charles Plessy]

Le Fri, Mar 30, 2007 at 12:18:23AM +1000, Paul TBBle Hampson a écrit :

> Again, I question the idea that a dpatch is _easier_ to parse than the
> .diff.gz.

Hi,

Actually, I am sorry to critisize general problems of diff.gz in a
discussion about the particular one of your package, without having
looked at it.

It's just that sometimes I have a hard time finding useful information
in the some diff.gz when they have a lot of autoconf gizmo in, or many
manpages, xpm icons, desktop files, or any other "noise".

I agree that in the cases of trivial packages with a slim diff.gz, the
discussion becomes quite academic.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: openjpeg

[Romain Beauxis]

Le jeudi 29 mars 2007 16:18, Paul TBBle Hampson a écrit :
> And again, if I was going to keep the debian/ directory in an external
> version-control system, dpatch would be the way to go.
>
> Since I'm not going to, the Debian archive already has a system for
> storing such trivial patches, in the .diff.gz.
>
> Despite this, and because I'm obviously going to be overruled here again
> no matter what I say, here's a version using dpatch. At least dpatch use
> is _easy_ to revert later.

Paul, we'll talk about this later, when you'll have to update your package to 
a new upstream release, when the diff.gz may not apply cleanly and you'll end 
up seperating what's for upstream sources to what's for debian/ in the 
diff.gz and finally patching new upstream with a new patch... That is 
precisely the work I advise you to do in the first place: extracting a 
patch..

Sorry for giving you the impression that I overruled your will, but seriously 
we'll discuss this later and I'm really convinced that
 you may not have the same opinion.

Now, let's look at the dpatched version :)

Romain

Re: RFS: openjpeg

[Paul TBBle Hampson]

On Thu, Mar 29, 2007 at 07:13:27PM +0900, Charles Plessy wrote:
> Le Thu, Mar 29, 2007 at 07:41:40PM +1000, Paul TBBle Hampson a écrit :
>> On Wed, Mar 28, 2007 at 04:54:52PM +0200, Romain Beauxis wrote:

> >> * Any other user/DD may then see precisly what changes you are doing to 
> >> upstream sources. You will also be able to seperate the changes that 
> >> perform 
> >> a different task.

>> Currently, any other user can see what I'm doing by looking at the
>> .diff.gz.

> just a "me too" word to say that I also feel more comfortable with
> clearly labelled patches debian/patches rather than having them in the
> diff.gz, which is not the easiest medium.

Indeed, I believe this is not uncommon, hence the wig-and-pen source
package format which, if I recall correctly, provides the upstream
tarball(s), a debian/ tarball, and the patches to apply to the upstream
source. Or something like that.

Again, I question the idea that a dpatch is _easier_ to parse than the
.diff.gz. Particularly, the .diff.gz shows all the changes to a given
file in one place, and consumes any intermediate stages, so you don't
have changes in an earlier patch breaking changes in a later patch and
requiring you to reroll all subsequent patches that touch that file.

And of course the contents of debian/patches is immaterial since the
file you have to be verifying before upload is the .diff.gz. So if
you're having trouble parsing it, dpatch won't solve it. (That's what
debdiff is for. Again, debdiff output is much easier to read if you're
not using dpatch. interdiff is hard enough to use without having to
then parse _two_ layers of diff.)

> In addition, in the future it may be more and more frequent to have
> the content of the debian directories browsable through a web
> interface to a revision system. In this case again, having things in
> debian/patches makes life easier to understand the purpose of the
> modifications.

And again, if I was going to keep the debian/ directory in an external
version-control system, dpatch would be the way to go.

Since I'm not going to, the Debian archive already has a system for
storing such trivial patches, in the .diff.gz.

Despite this, and because I'm obviously going to be overruled here again
no matter what I say, here's a version using dpatch. At least dpatch use
is _easy_ to revert later.

http://mentors.debian.net/debian/pool/main/o/openjpeg

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgp3CkrTv6YhH.pgp
Description: PGP signature

Re: RFS: openjpeg

[Charles Plessy]

Le Thu, Mar 29, 2007 at 07:41:40PM +1000, Paul TBBle Hampson a écrit :
> On Wed, Mar 28, 2007 at 04:54:52PM +0200, Romain Beauxis wrote:
> 
> > * Any other user/DD may then see precisly what changes you are doing to 
> > upstream sources. You will also be able to seperate the changes that 
> > perform 
> > a different task.
> 
> Currently, any other user can see what I'm doing by looking at the
> .diff.gz.

Hi all,

just a "me too" word to say that I also feel more comfortable with
clearly labelled patches debian/patches rather than having them in the
diff.gz, which is not the easiest medium.

In addition, in the future it may be more and more frequent to have
the content of the debian directories browsable through a web
interface to a revision system. In this case again, having things in
debian/patches makes life easier to understand the purpose of the
modifications.

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wako, Saitama, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: openjpeg

[Paul TBBle Hampson]

On Wed, Mar 28, 2007 at 04:54:52PM +0200, Romain Beauxis wrote:
> However, I see you have made significant changes to the makefile system, in 
> order to create a shared object with the correct name and to link dynamically 
> the utilities to the shared library, great ! 

These are not significant changes, they are trivial changes. A
significant change would be autotoolising the system.

> But, I would advise to put this as patch, and not let it stay into the 
> diff.gz. There are several reasons for that:
> * Upgrading the package to new upstream release will be much more easy, and 
> if 
> the patch fails you'll see where etc..

> * Any other user/DD may then see precisly what changes you are doing to 
> upstream sources. You will also be able to seperate the changes that perform 
> a different task.

Currently, any other user can see what I'm doing by looking at the
.diff.gz.

Under dpatch, they would have to notice in the .diff.gz that I'm using
dpatch, then look at both the double-diffed dpatch and the 00list file,
or _apply_ the .diff.gz and then look at the diff in debian/patches

I don't consider the above that onerous, but others have expressed the
opinion that it is so, and so I prefer to not require it when trivial.

> * You may submit the final patch upstream..

I suspect they don't want it. I doubt they've accidentally produced
staticly-built utilities, a stripped shared library, and a shared
object named as they have.

> In your precise case, I would strongly suggest sumbiting this to upstream 
> since it corrects two facts that are very important (shared object name) and 
> important (linking utilities to shared objects). 

Neither of these are global truths or neccessary outside Debian. The
shared object name is invisible to the system, ldconfig builds the
correct symlinks irrespective of the name. And static binaries are
much easier to run from the build directory without installing the whole
package. Which is handy if you don't care about libopenjpeg, but need
something to convert to or from JP2 files.

Interestingly, libblah-soversion.so appears to be how libtool creates
private libraries, and it looks like libtool 1.4 may have done that
with public libraries too.

I probably will suggest to them that they rename the default .so file
generated, but that'll be part of the same forum post that explains the
risks and perils of soversion mistakes like the 1.1 to 1.1.1 update.

> If only upstream would be using any suitable configure tool :)

autotools would almost certainly be too large for this project. Maybe if
they also rearranged the distribution to build everything together
cohesively, there would be some advantage to it. But for just the
library, written in what appears to be nice standrd C++ without any
other libraries needed, it's overkill.

> Then it is also a good training for a new packager to add patch support to 
> debian/rules. I don't think it will be very difficult for you..

*cough* Uh, I'm not a new packager, nor am I new to dpatch in
particular. As I mentioned before, dpatch is my preferred patching
infrastructure. That doesn't mean I feel it should be applied to
every upstream tarball.

I could accomplish the same thing with a little bit of effort in
the debian/rules file, but that would produce the (accurate, and
more relevant I feel) criticism that the build system used by
'make' is markedly different from that used by 'debian/rules binary'

> Sorry to ask for many corrections, but I feel important that this package, 
> and 
> others, have a good shape before upload..

I welcome and appreciate the feedback.

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpOed8Mj0EJW.pgp
Description: PGP signature

Re: RFS: openjpeg

[Romain Beauxis]

Le mercredi 28 mars 2007 14:44, Paul TBBle Hampson a écrit :
> On Wed, Mar 28, 2007 at 01:31:42PM +0200, Romain Beauxis wrote:
> > Le mercredi 28 mars 2007 12:46, Paul TBBle Hampson a écrit :
> >> OK, I've uploaded a new version, with changelog as follows:
> >
> >   Hi Paul !
> > Would you please post a link to it for such a lazy guy as me :)
>
> Ooops.
>
> http://mentors.debian.net/debian/pool/main/o/openjpeg

The package looks quite ok now..
You have done a great job in the copyright file, and all seems ok as for the 
required things. I can then consider uploading it.

However, I see you have made significant changes to the makefile system, in 
order to create a shared object with the correct name and to link dynamically 
the utilities to the shared library, great ! 
But, I would advise to put this as patch, and not let it stay into the 
diff.gz. There are several reasons for that:
* Upgrading the package to new upstream release will be much more easy, and if 
the patch fails you'll see where etc..
* Any other user/DD may then see precisly what changes you are doing to 
upstream sources. You will also be able to seperate the changes that perform 
a different task.
* You may submit the final patch upstream..

In your precise case, I would strongly suggest sumbiting this to upstream 
since it corrects two facts that are very important (shared object name) and 
important (linking utilities to shared objects). 

If only upstream would be using any suitable configure tool :)

Then it is also a good training for a new packager to add patch support to 
debian/rules. I don't think it will be very difficult for you..

Sorry to ask for many corrections, but I feel important that this package, and 
others, have a good shape before upload..


Romain

Re: RFS: openjpeg

[Paul TBBle Hampson]

On Wed, Mar 28, 2007 at 01:31:42PM +0200, Romain Beauxis wrote:
> Le mercredi 28 mars 2007 12:46, Paul TBBle Hampson a écrit :
>> OK, I've uploaded a new version, with changelog as follows:

>   Hi Paul !
> Would you please post a link to it for such a lazy guy as me :)

Ooops.

http://mentors.debian.net/debian/pool/main/o/openjpeg


-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpi7SQLIPTfv.pgp
Description: PGP signature

Re: RFS: openjpeg

[Romain Beauxis]

Le mercredi 28 mars 2007 12:46, Paul TBBle Hampson a écrit :
> OK, I've uploaded a new version, with changelog as follows:

Hi Paul !

Would you please post a link to it for such a lazy guy as me :)

Romain

Re: RFS: openjpeg

[Paul TBBle Hampson]

On Fri, Mar 23, 2007 at 12:33:41AM +1100, Paul TBBle Hampson wrote:
> On Wed, Mar 21, 2007 at 04:49:42PM +0100, Romain Beauxis wrote:
>> Le mercredi 21 mars 2007 16:32, Paul TBBle Hampson a écrit :
> >>> * debian/copyright: add licence section header between copyright part and
> >>> licence part.. Policy required it to be verbatim but you may still
> >>> seperate what is licence and what is copyright..

>>> OK. How do I describe the statement of copyright and license for the
>>> Debian packaging? It's both license and copyright.

>> Well.. As explained before, copyright lists the guys that have worked in the 
>> code, with statements like (c) 2007 Someone
>> Licence is the part that talks about rights granted on the code from the 
>> above 
>> copyright owners..
>> Simply add a Licence: line between copyright and the other part and its ok..
>> Also, now that we come to this point, have you checked all file headers ? I 
>> know it is a boring job, but it often gives you some very interesting 
>> results... upstream authors are not always consistent with the licence they 
>> give and some part of code they may take from other sources.. Given that you 
>> have read the REJECT FAQ, I guess you are aware of this point..

> Erk. The template in dh_make needs fixing then...

> Drat, I forgot to check the stuff I wasn't building. >_< There's a
> couple of copies of a four-clause BSD-licensed getopt.[ch], one
> attrubution-only type copyright in the jp3d library, and one 
> java file that may be "freely used or adapted".

OK, I've uploaded a new version, with changelog as follows:

 openjpeg (1.1.1-3) unstable; urgency=low
 .
   * Remove build-depend on autotools-dev, there's no autotools use here
   * Rename libopenjpeg-tools to openjpeg-tools
   * Correctly install libopenjpeg.so.1.0.0 rather than libopenjpeg-1.0.0.so
   * Make libopenjpeg1-dbg depend on the same-source version of libopenjpeg1
   * Create manpages for image_to_j2k, j2k_to_image and index_create
   * Update debian/copyright with full details of all contained licenses and
 copyrights
- Thanks again to Romain Beauxis for reviewing

I really think this one's ready... (Of course, I thought that about
the last two versions too...) ^_^

Now it's not only Lintian-clean, but doesn't even have any warnings.

The copyright file is just over a third of the .diff.gz. Bleh...

Obviously, I'm still open to any further comments. ^_^

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpbAbJKtvLxO.pgp
Description: PGP signature

Re: RFS: openjpeg

[Paul TBBle Hampson]

On Wed, Mar 21, 2007 at 04:49:42PM +0100, Romain Beauxis wrote:
> Le mercredi 21 mars 2007 16:32, Paul TBBle Hampson a écrit :
> >> * debian/copyright: add licence section header between copyright part and
> >> licence part.. Policy required it to be verbatim but you may still
> >> seperate what is licence and what is copyright..

>> OK. How do I describe the statement of copyright and license for the
>> Debian packaging? It's both license and copyright.

> Well.. As explained before, copyright lists the guys that have worked in the 
> code, with statements like (c) 2007 Someone
> Licence is the part that talks about rights granted on the code from the 
> above 
> copyright owners..
> Simply add a Licence: line between copyright and the other part and its ok..
> Also, now that we come to this point, have you checked all file headers ? I 
> know it is a boring job, but it often gives you some very interesting 
> results... upstream authors are not always consistent with the licence they 
> give and some part of code they may take from other sources.. Given that you 
> have read the REJECT FAQ, I guess you are aware of this point..

Erk. The template in dh_make needs fixing then...

Drat, I forgot to check the stuff I wasn't building. >_< There's a
couple of copies of a four-clause BSD-licensed getopt.[ch], one
attrubution-only type copyright in the jp3d library, and one 
java file that may be "freely used or adapted".

I guess the question is, to reroll without the getopt stuff, or email
upstream and try and explain the issue to them, as well as the issue
with the sonames. And the jpwl header stuff. And by email I apparently
mean 'sourceforge forum'. I've got a bad feeling about this...

> >> * debian/control: still you define a libopenjpeg-tools, and still the
> >> typo...

>> Wait, which typo are you talking about? I fixed the short description,
>> and there's a bunch of 'r's in the long description of libopenjpeg1 in
>> my local copy, dunno if they made it to the upload. (My laptop keyboard
>> seems to occasionally insert a whole bunch of 'r's in vim... >_<)

> Yes I mean those r :)

OK, fixed.

>> I've renamed libopenjpeg-tools to openjepg-tools, but I remain convinced
>> that this is needlessly inconsistent with libjpeg and libjasper's usage,
>> and the libpkg guide.

> Well, those utilities seem to be usefull outside of the library usage.
> Take the user point of view, would you understand the a libopenjpeg-utils in 
> fact contains utilities that have a more general usage than only for testing 
> the library or whatever is library specific ?
> Other formulation would be : why do you think this package name has to be 
> libopenjpeg specific ? 

The position I'm in is that if I want to see what came with a library,
I'll look for it by package name, so if it starts with 'lib' it'll be
in the output of an apt-cache search near the library itself.

The short description tells me they're tools for the JPEG 2000 image
compression codec, rather than being something library-specific like
a *-config (which would be in -dev instead) and the long description
even tells me what the tools are and what they do.

If I want to find a tool to do something, I'd search on keywords, not
names, and find it no matter what it's called.

Mind you, in contrast to the below, the upstream project name is
openjpeg, not libopenjpeg...

Anyway, I've made the change, and I can appreciate both sides of the
discussion. I'm not thrilled by the change, as I was of the
understanding that without a clear style guide or policy position, such
choices were at the descretion of the maintainer.

> I can think of mpeg3-utils for instance...

Given that there's no such thing as mpeg3, that's an awful example. ^_^

libmpeg3 is the name of the project, and mpeg3-utils has managed to
lose the 'lib', so it doesn't look like it belongs to that project,
while instead looking like it is a tool to manipulate data according to
an imaginary MPEG standard.

And the short description claims it's a library, too, since it seems to
share the short description with libmpeg3-1

_I'd_ have pulled this up as an example of why I think openjpeg-tools is
the wrong name, were I trying to argue that.

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpROv9CucNzO.pgp
Description: PGP signature

Re: RFS: openjpeg

[Romain Beauxis]

Le mercredi 21 mars 2007 16:32, Paul TBBle Hampson a écrit :
> > * debian/copyright: add licence section header between copyright part and
> > licence part.. Policy required it to be verbatim but you may still
> > seperate what is licence and what is copyright..
>
> OK. How do I describe the statement of copyright and license for the
> Debian packaging? It's both license and copyright.

Well.. As explained before, copyright lists the guys that have worked in the 
code, with statements like (c) 2007 Someone
Licence is the part that talks about rights granted on the code from the above 
copyright owners..
Simply add a Licence: line between copyright and the other part and its ok..
Also, now that we come to this point, have you checked all file headers ? I 
know it is a boring job, but it often gives you some very interesting 
results... upstream authors are not always consistent with the licence they 
give and some part of code they may take from other sources.. Given that you 
have read the REJECT FAQ, I guess you are aware of this point..

> > * debian/control: still you define a libopenjpeg-tools, and still the
> > typo...
>
> Wait, which typo are you talking about? I fixed the short description,
> and there's a bunch of 'r's in the long description of libopenjpeg1 in
> my local copy, dunno if they made it to the upload. (My laptop keyboard
> seems to occasionally insert a whole bunch of 'r's in vim... >_<)

Yes I mean those r :)

> I've renamed libopenjpeg-tools to openjepg-tools, but I remain convinced
> that this is needlessly inconsistent with libjpeg and libjasper's usage,
> and the libpkg guide.

Well, those utilities seem to be usefull outside of the library usage.
Take the user point of view, would you understand the a libopenjpeg-utils in 
fact contains utilities that have a more general usage than only for testing 
the library or whatever is library specific ?
Other formulation would be : why do you think this package name has to be 
libopenjpeg specific ? 

I can think of mpeg3-utils for instance...



Romain

Re: RFS: openjpeg

[Paul TBBle Hampson]

On Wed, Mar 21, 2007 at 02:25:24PM +0100, Romain Beauxis wrote:
> Le mercredi 21 mars 2007 13:46, Paul TBBle Hampson a écrit :
> >> Anyway, do you have a link to the new package, I'll try to have a deeper
> >> review on this..

>> http://mentors.debian.net/debian/pool/main/o/openjpeg/

> More comments:
> * You have lintian warnings about missing manpages. They are required so you 
> may fix this.

Yeah, I discovered help2man today, (from FTP Master REJECT FAQ of all
things) I'll use that for my next run.

Bleh. help2man's not even vaugely correct. I'll try txt2man instead.

> * debian/copyright: add licence section header between copyright part and 
> licence part.. Policy required it to be verbatim but you may still seperate 
> what is licence and what is copyright..

OK. How do I describe the statement of copyright and license for the
Debian packaging? It's both license and copyright.

> * debian/control: still you define a libopenjpeg-tools, and still the typo... 

Wait, which typo are you talking about? I fixed the short description,
and there's a bunch of 'r's in the long description of libopenjpeg1 in
my local copy, dunno if they made it to the upload. (My laptop keyboard
seems to occasionally insert a whole bunch of 'r's in vim... >_<)

I've renamed libopenjpeg-tools to openjepg-tools, but I remain convinced
that this is needlessly inconsistent with libjpeg and libjasper's usage,
and the libpkg guide.

> Seems you have added autotool-dev to the build-dep.. Why is this needed if 
> autotools are not used ??

Whoops. That was supposed to be added to libxmlrpc-epi... I must have
done that on Tuesday, that changelog entry was there when I started
applying your comments tonight.

Removed, thanks.

> * libopenjpeg1: libopenjpeg-1.0.0.so is not the right way to name a shared 
> object I fear, it should be libsoname.so.soversion. And it seems that 
> upstream is doing this wrong naming...

I can't believe I've missed that _every_ time. >_< I must submit a
lintian test for that one.

Fixed, thanks.

Although I hope there's nothing which depends on that particular
whackyness of naming that would cause problems here... The ldconfig
symlinks should take care of all that, I expect.

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpkszpHdJgvb.pgp
Description: PGP signature

Re: RFS: openjpeg

[Bernd Zeimetz]

Hi,
> build them at all. (And it prolly shouldn't. I need an AMD64 machine to
> pbuilder on...)
>   
builds well with pbuilder on amd64. Didn't have the time to test the
packages, though.


Cheers,

Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: openjpeg

[Romain Beauxis]

Le mercredi 21 mars 2007 13:46, Paul TBBle Hampson a écrit :
> > Anyway, do you have a link to the new package, I'll try to have a deeper
> > review on this..
>
> http://mentors.debian.net/debian/pool/main/o/openjpeg/

More comments:
* You have lintian warnings about missing manpages. They are required so you 
may fix this.
* debian/copyright: add licence section header between copyright part and 
licence part.. Policy required it to be verbatim but you may still seperate 
what is licence and what is copyright..
* debian/control: still you define a libopenjpeg-tools, and still the typo... 
Seems you have added autotool-dev to the build-dep.. Why is this needed if 
autotools are not used ??
* libopenjpeg1: libopenjpeg-1.0.0.so is not the right way to name a shared 
object I fear, it should be libsoname.so.soversion. And it seems that 
upstream is doing this wrong naming...
* Compliation was on my i386 machine I don't know if the FTBFS was fixed...

I fear that you may have a lot of trouble packaging and maintaining this since 
upstream does not seem to do a great building job..
Anyway, let's fix these first.
Please could you also have a deeper look before sending another link for 
review, it wastes my time and enthousiasm...



Romain

Re: RFS: openjpeg

[Paul TBBle Hampson]

On Wed, Mar 21, 2007 at 01:18:25PM +0100, Romain Beauxis wrote:
> I had forgot how painfull it is to build a library without 
> configure/libtool...
> configure/libtool is a pain in the ass for sure, but coming on those subjects 
> it simply and magicaly handle all those hard stuff alone..

Yeah. xmlrpc-epi uses libtool, and I didn't even have to think
about -fPIC. ^_^

> Anyway, do you have a link to the new package, I'll try to have a deeper 
> review on this..

http://mentors.debian.net/debian/pool/main/o/openjpeg/

> You may also contact upstream an try to explain them that if they want their 
> project to be easily portable (think of this mess ported to macosX, sunOS 
> etc...), they really should consider using a good building system, especially 
> autoconf which is very well oriented toward portability...

They provide a Makefile.osx and a .dsp file. Sadly, the included viewer
is currently Windows-only...

This isn't too bad, I've fought things harder for -fPIC. (libtool 1.4
used to get this really really badly wrong when building modules. In
fact, I never solved that one.)

The actual library is so small, it's barely worth autotoolising.

Hmm. The Makefile.osx uses libtool... It can't be _that_ easy...

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpUTUrN9oKvB.pgp
Description: PGP signature

Re: RFS: openjpeg

[Romain Beauxis]

Le mercredi 21 mars 2007 13:04, Paul TBBle Hampson a écrit :
> (You can also see here a use of the version variable set at the top
> of the rules too. ^_^)

Yes..
I had forgot how painfull it is to build a library without 
configure/libtool...
configure/libtool is a pain in the ass for sure, but coming on those subjects 
it simply and magicaly handle all those hard stuff alone..

Anyway, do you have a link to the new package, I'll try to have a deeper 
review on this..
You may also contact upstream an try to explain them that if they want their 
project to be easily portable (think of this mess ported to macosX, sunOS 
etc...), they really should consider using a good building system, especially 
autoconf which is very well oriented toward portability...


Romain

Re: RFS: openjpeg

[Paul TBBle Hampson]

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

Re: RFS: openjpeg

[Romain Beauxis]

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

Re: RFS: openjpeg

[Paul TBBle Hampson]

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 :
>>   Dear mentors,

>   Hi !

>> I am looking for a sponsor for my package "openjpeg".

> Some basic comments:
> * debian/rules: you should remove uneeded call to dh_ stuff. Also the

Fixed, thanks. Thanks.

> ## shared library versions, option 1
>> 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?

>> ln -s libopenjpeg-${version}.so dist/libopenjpeg.so
> This does not seem right too...

Uh, that's so that the included binaries link against the shared-object.

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*.)

Fixed the cut and paste oversight, thanks.

> * 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.

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.

[1] http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html

> * 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)

> 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...

I've changed it so it doesn't _try_ to build the .so file the first time
'round.

New package will be uploaded once it's out of pbuilder.

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpCPSojWA7ol.pgp
Description: PGP signature

Re: RFS: openjpeg

[Romain Beauxis]

Le mardi 20 mars 2007 04:17, Paul TBBle Hampson a écrit :
>   Dear mentors,

Hi !

> I am looking for a sponsor for my package "openjpeg".

Some basic comments:
* debian/rules: you should remove uneeded call to dh_ stuff. Also the
> # shared library versions, option 1
> version=1.0.0
> major=1
stuff does not seem right, and version is not the one provided..
> ln -s libopenjpeg-${version}.so dist/libopenjpeg.so
This does not seem right too...
* 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..
* 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.
* 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... 

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..

With the above issue, I think you did not check all the requirement for 
packaging a library.. -fPIC is required for instance.. You should first find 
some documentation like at this place:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
(first gogole result, so may not be the better...)

This was not a deep review, there may be other mistakes..

Romain
-- 
In the beginning, there was but one concept,
And that's the concept of I.
Then arose Apollyon, the Devil
- Satan! Satan! -
claiming that it's you and I.
And from that day on,
There was trouble in the world

RFS: openjpeg

[Paul TBBle Hampson]

Dear mentors,

I am looking for a sponsor for my package "openjpeg".

* Package name: openjpeg
  Version : 1.1.1-1
  Upstream Author : OpenJPEG Team <[EMAIL PROTECTED]>
* URL : http://www.openjpeg.org/
* License : BSD (2-clause as per http://www.openjpeg.org/BSDlicense.txt)
  Section : libs

It builds these binary packages:
libopenjpeg-dev - JPEG 2000 image compression codec library development files
libopenjpeg-tools - JPEG 2000 image compression codec library shared objects
libopenjpeg1 - JPEG 2000 image compression codec library shared objects
libopenjpeg1-dbg - JPEG 2000 image compression codec library shared objects

The package is lintian clean.

The upload would fix these bugs: 413987

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/o/openjpeg
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/o/openjpeg/openjpeg_1.1.1-1.dsc

I would be glad if someone uploaded this package for me.

It is a dependancy of the second-life viewer application, and Bernd Zeimetz
intends to package a Gimp plugin that uses it to. [1]

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413987;msg=10

-- 
---
Paul "TBBle" Hampson, B.Sc, LPI, MCSE
On-hiatus Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

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/
---


pgpQm4T2UC32f.pgp
Description: PGP signature