Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-12-03 11:13 GMT+01:00 James Cowgill :
> On 03/12/16 00:41, Jaromír Mikeš wrote:
>> 2016-12-02 12:52 GMT+01:00 James Cowgill :
>>> d/changelog
 * Don't sign tags?
>>> Why? I believe it's multimedia team policy to sign all debian/ tags.
>>
>> I am not sure that it is multimedia team policy to sign tags ...
>> I have seen that others was removing this entry from gbp.conf file so
>> I did the same.
>> It just simplifies workflow a bit.
>
> https://wiki.debian.org/DebianMultimedia/DevelopPackaging#Workflow_guidelines
> "Tags should be created (and signed) by the uploading DD, in the case
> of the debian tags in the master branch, and by the person importing
> the upstream sources in the case of upstream tags."
>
> This is independent of having sign-tags in the package gbp.conf - I
> have it in my ~/.gbp.conf file instead. Why would you not want to sign
> your tags?

Ok I will sign a tags ;)
It was my misunderstanding.

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[James Cowgill]

Hi,

On 03/12/16 13:15, Jaromír Mikeš wrote:
> 2016-12-03 11:14 GMT+01:00 James Cowgill :
> Hi James,
> 
>> Also, you should use source only uploads. There is currently a useless
>> uninstallable gigedit package in experimental which a source only upload
>> would have prevented.
> 
> Can you explain me what is "source_only" upload?

The archive accepts source only (ie no .debs) uploads for all packages
to unstable/experimental which do not need to go though NEW. You can now
do 'dpkg-buildpackage -S' and upload that instead of uploading the debs
as well (obviously you should also check it does in fact build).

Advantages are:
- Don't have to upload any debs / dbysym packages
- No/reduced chance of packages built in a 'dirty' build environment
- Build logs are available online
- The buildds will wait for build dependencies to pass NEW

See:
https://lists.debian.org/debian-devel-announce/2014/08/msg2.html
https://lists.debian.org/debian-devel-announce/2015/08/msg7.html

> How can I fix it now?

You can't do anything now, but it's not a 'bug' as such - just advice :)

Thanks,
James



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-12-03 11:14 GMT+01:00 James Cowgill :

Hi James,

> Also, you should use source only uploads. There is currently a useless
> uninstallable gigedit package in experimental which a source only upload
> would have prevented.

Can you explain me what is "source_only" upload?
How can I fix it now?

best regards

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[James Cowgill]

On 03/12/16 00:41, Jaromír Mikeš wrote:
> 2016-12-02 12:52 GMT+01:00 James Cowgill :
>> d/changelog
>>> * Don't sign tags?
>> Why? I believe it's multimedia team policy to sign all debian/ tags.
> 
> I am not sure that it is multimedia team policy to sign tags ...
> I have seen that others was removing this entry from gbp.conf file so
> I did the same.
> It just simplifies workflow a bit.

https://wiki.debian.org/DebianMultimedia/DevelopPackaging#Workflow_guidelines
"Tags should be created (and signed) by the uploading DD, in the case
of the debian tags in the master branch, and by the person importing
the upstream sources in the case of upstream tags."

This is independent of having sign-tags in the package gbp.conf - I
have it in my ~/.gbp.conf file instead. Why would you not want to sign
your tags?

Thanks,
James



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-12-02 12:52 GMT+01:00 James Cowgill :
> On 01/12/16 23:48, Jaromír Mikeš wrote:

Hi,

>> Can you review also gigedit now and give me DM flag for it?
>
> d/patches
> Again, Makefile.in and configure are generated files so they should not
> need to be edited in the 01-makefiles.patch.

Done!

> d/control
>> libgig-dev (>= 4.0.0~)
> I think (>= 4.0.0) is enough here. You only need a ~ at the end if you
> need a dependency on a specific debian revision (for backports) or a
> pre-release upstream version.

Done!

> d/changelog
>> * Don't sign tags?
> Why? I believe it's multimedia team policy to sign all debian/ tags.

I am not sure that it is multimedia team policy to sign tags ...
I have seen that others was removing this entry from gbp.conf file so
I did the same.
It just simplifies workflow a bit.

> d/rules
>> override_dh_auto_test:
> Is this necessary anymore?

Fixed!

> Why do we need to ship the static or shared libraries? We could pass
> --disable-shared and then ship nothing in /usr/lib as everything will be
> compiled into /usr/bin/gigedit.

Done!

> I've given you the DM flag anyway - I trust you can fix these things.

Thank you!

best regards

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[James Cowgill]

Hi,

On 01/12/16 23:48, Jaromír Mikeš wrote:
> 2016-12-02 0:16 GMT+01:00 James Cowgill :
>> Uploaded!
> 
> Thank you James !!! Can you review also gigedit now and give me DM flag for 
> it?
> I think then I can upload it to experimental myself.

d/patches
Again, Makefile.in and configure are generated files so they should not
need to be edited in the 01-makefiles.patch.

d/control
> libgig-dev (>= 4.0.0~)
I think (>= 4.0.0) is enough here. You only need a ~ at the end if you
need a dependency on a specific debian revision (for backports) or a
pre-release upstream version.

d/changelog
> * Don't sign tags?
Why? I believe it's multimedia team policy to sign all debian/ tags.

d/rules
> override_dh_auto_test:
Is this necessary anymore?

Why do we need to ship the static or shared libraries? We could pass
--disable-shared and then ship nothing in /usr/lib as everything will be
compiled into /usr/bin/gigedit.

I've given you the DM flag anyway - I trust you can fix these things.

Thanks,
James



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-12-02 0:16 GMT+01:00 James Cowgill :
> On 01/12/16 22:47, Jaromír Mikeš wrote:
>> 2016-12-01 19:44 GMT+01:00 James Cowgill :
>>> On 01/12/16 01:15, Jaromír Mikeš wrote:
 2016-12-01 0:43 GMT+01:00 James Cowgill :
> A gentle nudge to include symbol files for libgig7 and libakai0, though
> you can omit them for now if you want.

 As library is c++ I would rather avoid maintaining symbol files if the
 nudge is just gentle ;)
 I got quite a lot of work maintain them :(
>>>
>>> I think I confused this package with liblscp and was thinking this was
>>> written in C - you don't have to do the symbols files.
>>>
> Upstream bug:
> Numerous files contains é characters encoded using ISO-8859-1 instead of
> UTF-8. The akai programs which print these characters all show it as �
> on my machine.

 Forwarded upstream ...

 If all is fine I would like to ask you for uploading to experimental
 and proving me DM flag for latter maintaining.
 I guess package must go through NEW as there is new package libakai0.
>>>
>>> And libgig7.
>>>
>>> Can you update the changelog, then I'll upload it.
>>
>> Done ;)
>
> Uploaded!

Thank you James !!! Can you review also gigedit now and give me DM flag for it?
I think then I can upload it to experimental myself.

best regards

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[James Cowgill]

On 01/12/16 22:47, Jaromír Mikeš wrote:
> 2016-12-01 19:44 GMT+01:00 James Cowgill :
>> On 01/12/16 01:15, Jaromír Mikeš wrote:
>>> 2016-12-01 0:43 GMT+01:00 James Cowgill :
 A gentle nudge to include symbol files for libgig7 and libakai0, though
 you can omit them for now if you want.
>>>
>>> As library is c++ I would rather avoid maintaining symbol files if the
>>> nudge is just gentle ;)
>>> I got quite a lot of work maintain them :(
>>
>> I think I confused this package with liblscp and was thinking this was
>> written in C - you don't have to do the symbols files.
>>
 Upstream bug:
 Numerous files contains é characters encoded using ISO-8859-1 instead of
 UTF-8. The akai programs which print these characters all show it as �
 on my machine.
>>>
>>> Forwarded upstream ...
>>>
>>> If all is fine I would like to ask you for uploading to experimental
>>> and proving me DM flag for latter maintaining.
>>> I guess package must go through NEW as there is new package libakai0.
>>
>> And libgig7.
>>
>> Can you update the changelog, then I'll upload it.
> 
> Done ;)

Uploaded!

Thanks,
James



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-12-01 19:44 GMT+01:00 James Cowgill :
> On 01/12/16 01:15, Jaromír Mikeš wrote:
>> 2016-12-01 0:43 GMT+01:00 James Cowgill :
>>> A gentle nudge to include symbol files for libgig7 and libakai0, though
>>> you can omit them for now if you want.
>>
>> As library is c++ I would rather avoid maintaining symbol files if the
>> nudge is just gentle ;)
>> I got quite a lot of work maintain them :(
>
> I think I confused this package with liblscp and was thinking this was
> written in C - you don't have to do the symbols files.
>
>>> Upstream bug:
>>> Numerous files contains é characters encoded using ISO-8859-1 instead of
>>> UTF-8. The akai programs which print these characters all show it as �
>>> on my machine.
>>
>> Forwarded upstream ...
>>
>> If all is fine I would like to ask you for uploading to experimental
>> and proving me DM flag for latter maintaining.
>> I guess package must go through NEW as there is new package libakai0.
>
> And libgig7.
>
> Can you update the changelog, then I'll upload it.

Done ;)

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[James Cowgill]

On 01/12/16 01:15, Jaromír Mikeš wrote:
> 2016-12-01 0:43 GMT+01:00 James Cowgill :
>> A gentle nudge to include symbol files for libgig7 and libakai0, though
>> you can omit them for now if you want.
> 
> As library is c++ I would rather avoid maintaining symbol files if the
> nudge is just gentle ;)
> I got quite a lot of work maintain them :(

I think I confused this package with liblscp and was thinking this was
written in C - you don't have to do the symbols files.

>> Upstream bug:
>> Numerous files contains é characters encoded using ISO-8859-1 instead of
>> UTF-8. The akai programs which print these characters all show it as �
>> on my machine.
> 
> Forwarded upstream ...
> 
> If all is fine I would like to ask you for uploading to experimental
> and proving me DM flag for latter maintaining.
> I guess package must go through NEW as there is new package libakai0.

And libgig7.

Can you update the changelog, then I'll upload it.

Thanks,
James



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-12-01 0:43 GMT+01:00 James Cowgill :
> On 30/11/16 15:38, Jaromír Mikeš wrote:

>> can you please review libgig now if
>> it is ready for uploading to experimental?
>
> The Breaks/Replaces on libgig6 can be removed from both libgig7 and
> libakai0. It was only needed for libgig6v5 due to the g++5 transition.

Fixed!

> 01-Makefile.patch should not modify configure or Makefile.in.

Fixed!

> These files are LGPL-2.1+:
> src/Akai.cpp
> src/Akai.h
> src/tools/akaidump.cpp
> src/tools/akaiextract.cpp
>
> Most other files seem to be GPL-2+ and not GPL-2 ?

Fixed!

> A gentle nudge to include symbol files for libgig7 and libakai0, though
> you can omit them for now if you want.

As library is c++ I would rather avoid maintaining symbol files if the
nudge is just gentle ;)
I got quite a lot of work maintain them :(

> Upstream bug:
> Numerous files contains é characters encoded using ISO-8859-1 instead of
> UTF-8. The akai programs which print these characters all show it as �
> on my machine.

Forwarded upstream ...

If all is fine I would like to ask you for uploading to experimental
and proving me DM flag for latter maintaining.
I guess package must go through NEW as there is new package libakai0.

best regards

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[James Cowgill]

On 30/11/16 15:38, Jaromír Mikeš wrote:
> 2016-11-30 14:24 GMT+01:00 James Cowgill :
>> On 26/11/16 15:17, Jaromír Mikeš wrote:
>>> Quoting upstream answer
>>> --
>>> However my original suggestion for changing /usr/include/libgig to
>>> /usr/include/libgig4 might still make sense. Since all applications linking
>>> against libgig are calling pkg-config, they would still compile to that new
>>> headers location without any changes to those app's source code or configure
>>> scripts. Do your Debian friends over there have any profound reasons against
>>> this naming scheme (with the lib's major number included)?
>>
>> I have no profound reasons against it - it's just completely pointless
>> unless you change the library name as well (ie libgig.so -> libgig4.so).
>> Also, it's generally not a good idea to assume that _everyone_ is using
>> pkg-config.
>>
>>> But just to make this clear: libgig is also one of the libraries which was 
>>> and
>>> will change its API frequently becoming incompatible with previous versions.
>>> That's mainly because we decided that preserving backward compatibility for 
>>> a
>>> long time would mean to much work overhead for us, with probably no relevant
>>> advantage for users in practice.
>>
>> That's unfortunate, but since the library isn't used by many packages
>> it's probably not too bad.
> 
> thank you James for comments ... can you please review libgig now if
> it is ready for uploading to experimental?

The Breaks/Replaces on libgig6 can be removed from both libgig7 and
libakai0. It was only needed for libgig6v5 due to the g++5 transition.

01-Makefile.patch should not modify configure or Makefile.in.

These files are LGPL-2.1+:
src/Akai.cpp
src/Akai.h
src/tools/akaidump.cpp
src/tools/akaiextract.cpp

Most other files seem to be GPL-2+ and not GPL-2 ?

A gentle nudge to include symbol files for libgig7 and libakai0, though
you can omit them for now if you want.

Upstream bug:
Numerous files contains é characters encoded using ISO-8859-1 instead of
UTF-8. The akai programs which print these characters all show it as �
on my machine.

Thanks,
James



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

Hi,

2016-11-30 14:24 GMT+01:00 James Cowgill :
> On 26/11/16 15:17, Jaromír Mikeš wrote:
>> Quoting upstream answer
>> --
>> However my original suggestion for changing /usr/include/libgig to
>> /usr/include/libgig4 might still make sense. Since all applications linking
>> against libgig are calling pkg-config, they would still compile to that new
>> headers location without any changes to those app's source code or configure
>> scripts. Do your Debian friends over there have any profound reasons against
>> this naming scheme (with the lib's major number included)?
>
> I have no profound reasons against it - it's just completely pointless
> unless you change the library name as well (ie libgig.so -> libgig4.so).
> Also, it's generally not a good idea to assume that _everyone_ is using
> pkg-config.
>
>> But just to make this clear: libgig is also one of the libraries which was 
>> and
>> will change its API frequently becoming incompatible with previous versions.
>> That's mainly because we decided that preserving backward compatibility for a
>> long time would mean to much work overhead for us, with probably no relevant
>> advantage for users in practice.
>
> That's unfortunate, but since the library isn't used by many packages
> it's probably not too bad.

thank you James for comments ... can you please review libgig now if
it is ready for uploading to experimental?

best regards

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[James Cowgill]

Hi,

On 26/11/16 15:17, Jaromír Mikeš wrote:
> Quoting upstream answer
> --
> However my original suggestion for changing /usr/include/libgig to
> /usr/include/libgig4 might still make sense. Since all applications linking
> against libgig are calling pkg-config, they would still compile to that new
> headers location without any changes to those app's source code or configure
> scripts. Do your Debian friends over there have any profound reasons against
> this naming scheme (with the lib's major number included)?

I have no profound reasons against it - it's just completely pointless
unless you change the library name as well (ie libgig.so -> libgig4.so).
Also, it's generally not a good idea to assume that _everyone_ is using
pkg-config.

> But just to make this clear: libgig is also one of the libraries which was and
> will change its API frequently becoming incompatible with previous versions.
> That's mainly because we decided that preserving backward compatibility for a
> long time would mean to much work overhead for us, with probably no relevant
> advantage for users in practice.

That's unfortunate, but since the library isn't used by many packages
it's probably not too bad.

James



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-11-26 16:17 GMT+01:00 Jaromír Mikeš :
> 2016-11-26 13:33 GMT+01:00 James Cowgill :
>> On 26/11/16 01:44, Jaromír Mikeš wrote:
>>> 2016-11-25 17:36 GMT+01:00 James Cowgill :
>
 All headers in /usr/include/libgig, all references loose the 'libgig/'
 and -I/usr/include/libgig is added to the pkg-config file.
>
> Option 3 has been selected by upstream ...

Option 3 is selected by upstream and I have tuned our packaging accordingly.
qsampler 0.4.2 and gigedit 1.0.0 now build fine with libgig 4.0.0

best regards

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-11-26 13:33 GMT+01:00 James Cowgill :
> On 26/11/16 01:44, Jaromír Mikeš wrote:
>> 2016-11-25 17:36 GMT+01:00 James Cowgill :

>>> All headers in /usr/include/libgig, all references loose the 'libgig/'
>>> and -I/usr/include/libgig is added to the pkg-config file.

Option 3 has been selected by upstream ...

>> What would be best from debian point of view?
>>
>> /usr/include/libgig4/gig.h or /usr/include/libgig7/gig.h
>>
>> to reflect rather soname than release?
>
> Usually the header location does not change with the soname / ABI. Most
> libraries that do change the header path frequently do it because the
> API changes a lot (eg LLVM).
>
>> Or just /usr/include/gig.h and not allow two versions installed together?
>>
>> your opinion James?
>
> I think one of the 3 options I gave should be used, but I don't mind
> which one. Given that programs seem to be using headers without the
> 'libgig/' prefix already, the middle options seems the least desirable
> but if upstream wants to update all the headers for that option then it can.
>
> As to installing -dev packages together - upstream would also have to
> rename the libgig.so symlink as well as installing headers in a
> different place. I'm not sure it's worth it.

Quoting upstream answer
--
However my original suggestion for changing /usr/include/libgig to
/usr/include/libgig4 might still make sense. Since all applications linking
against libgig are calling pkg-config, they would still compile to that new
headers location without any changes to those app's source code or configure
scripts. Do your Debian friends over there have any profound reasons against
this naming scheme (with the lib's major number included)?

But just to make this clear: libgig is also one of the libraries which was and
will change its API frequently becoming incompatible with previous versions.
That's mainly because we decided that preserving backward compatibility for a
long time would mean to much work overhead for us, with probably no relevant
advantage for users in practice.
---

James can comment this please?

best regards

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[James Cowgill]

Hi,

On 26/11/16 01:44, Jaromír Mikeš wrote:
> 2016-11-25 17:36 GMT+01:00 James Cowgill :
>> OK I've had another look and I think I understand the confusion here:
>> upstream have decided to move the headers from /usr/include to
>> /usr/include/libgig without adjusting anything else to cope with that.
>>
>> Your method would work here, but I think you should ask upstream what
>> they want here since changing it later is a PITA. The options are:
>>
>> All headers in /usr/include, all references to them loose the 'libgig/'
>> prefix.
>>
>> All headers in /usr/include/libgig, all references must have a 'libgig/'
>> prefix (including the headers themselves).
>>
>> All headers in /usr/include/libgig, all references loose the 'libgig/'
>> and -I/usr/include/libgig is added to the pkg-config file.
> 
> Answer somehow came from upstream itself before posting to him ...
> as he reviewed my patch 05-fix-include-dir.patch
> 
>> as far as I remember the previous Debian maintainer of libgig, I think he 
>> said
>> the header files should be bundled in a subdirectory according to Debian
>> policies, and the the subdirectory name should reflect the library version
>> (i.e. /usr/include/libgig4/gig.h, etc.). The motivation was to be able to
>> install i.e. two different versions of the same library (i.e. in this case
>> i.e. libgig3-dev, libgig4-dev) which would otherwise cause a file conflict.
>> But obviously I am not up to date regarding latest Debian policies.
> 
> What would be best from debian point of view?
> 
> /usr/include/libgig4/gig.h or /usr/include/libgig7/gig.h
> 
> to reflect rather soname than release?

Usually the header location does not change with the soname / ABI. Most
libraries that do change the header path frequently do it because the
API changes a lot (eg LLVM).

> Or just /usr/include/gig.h and not allow two versions installed together?
> 
> your opinion James?

I think one of the 3 options I gave should be used, but I don't mind
which one. Given that programs seem to be using headers without the
'libgig/' prefix already, the middle options seems the least desirable
but if upstream wants to update all the headers for that option then it can.

As to installing -dev packages together - upstream would also have to
rename the libgig.so symlink as well as installing headers in a
different place. I'm not sure it's worth it.

Thanks,
James



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-11-25 17:36 GMT+01:00 James Cowgill :
> On 23/11/16 22:44, Jaromír Mikeš wrote:
>> 2016-11-23 23:14 GMT+01:00 James Cowgill :
>>> On 23/11/16 22:02, Jaromír Mikeš wrote:
 Ok ... fixed now :) libgig builds fine ...
 I also tried build qsampler ... it builds but will need some patch to
 fix search for libgig/SF.h ... quite should be easy
>>>
>>> If qsampler needs a patch, you've done something wrong. Moving the
>>> libraries should have had no affect on other packages (unless they are
>>> actually hard coding the lib path). Why have the headers changed?
>>
>> qsampler search for libgig/SF.h ... till now (with old libgig) it was
>> never found ( it wasn't exist) and qsampler was build without this
>> fuctionality
>> SF.h is new header provided by new libgig 4.0.0 ... and now all header
>> are moved from usr/include/libgig to usr/include/
>>
>> You still think I have done something wrong?
>
> OK I've had another look and I think I understand the confusion here:
> upstream have decided to move the headers from /usr/include to
> /usr/include/libgig without adjusting anything else to cope with that.
>
> Your method would work here, but I think you should ask upstream what
> they want here since changing it later is a PITA. The options are:
>
> All headers in /usr/include, all references to them loose the 'libgig/'
> prefix.
>
> All headers in /usr/include/libgig, all references must have a 'libgig/'
> prefix (including the headers themselves).
>
> All headers in /usr/include/libgig, all references loose the 'libgig/'
> and -I/usr/include/libgig is added to the pkg-config file.

Answer somehow came from upstream itself before posting to him ...
as he reviewed my patch 05-fix-include-dir.patch

> as far as I remember the previous Debian maintainer of libgig, I think he said
> the header files should be bundled in a subdirectory according to Debian
> policies, and the the subdirectory name should reflect the library version
> (i.e. /usr/include/libgig4/gig.h, etc.). The motivation was to be able to
> install i.e. two different versions of the same library (i.e. in this case
> i.e. libgig3-dev, libgig4-dev) which would otherwise cause a file conflict.
> But obviously I am not up to date regarding latest Debian policies.

What would be best from debian point of view?

/usr/include/libgig4/gig.h or /usr/include/libgig7/gig.h

to reflect rather soname than release?

Or just /usr/include/gig.h and not allow two versions installed together?

your opinion James?

best regards

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[James Cowgill]

On 23/11/16 22:44, Jaromír Mikeš wrote:
> 2016-11-23 23:14 GMT+01:00 James Cowgill :
>> On 23/11/16 22:02, Jaromír Mikeš wrote:
>>> Ok ... fixed now :) libgig builds fine ...
>>> I also tried build qsampler ... it builds but will need some patch to
>>> fix search for libgig/SF.h ... quite should be easy
>>
>> If qsampler needs a patch, you've done something wrong. Moving the
>> libraries should have had no affect on other packages (unless they are
>> actually hard coding the lib path). Why have the headers changed?
> 
> qsampler search for libgig/SF.h ... till now (with old libgig) it was
> never found ( it wasn't exist) and qsampler was build without this
> fuctionality
> SF.h is new header provided by new libgig 4.0.0 ... and now all header
> are moved from usr/include/libgig to usr/include/
> 
> You still think I have done something wrong?

OK I've had another look and I think I understand the confusion here:
upstream have decided to move the headers from /usr/include to
/usr/include/libgig without adjusting anything else to cope with that.

Your method would work here, but I think you should ask upstream what
they want here since changing it later is a PITA. The options are:

All headers in /usr/include, all references to them loose the 'libgig/'
prefix.

All headers in /usr/include/libgig, all references must have a 'libgig/'
prefix (including the headers themselves).

All headers in /usr/include/libgig, all references loose the 'libgig/'
and -I/usr/include/libgig is added to the pkg-config file.

Thanks,
James



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-11-23 23:14 GMT+01:00 James Cowgill :
> Hi
>
> On 23/11/16 22:02, Jaromír Mikeš wrote:
>> 2016-11-22 16:40 GMT+01:00 Jaromír Mikeš :
>>> 2016-11-22 15:30 GMT+01:00 James Cowgill :
 Hi,

 On 22/11/16 14:14, Jaromír Mikeš wrote:
> 2016-11-22 12:29 GMT+01:00 James Cowgill :
>>> 2016-11-21 19:43 GMT+01:00 Jaromír Mikeš :
>>> So what we can do?
>>
>> Since upstream have added /usr/lib/libgig to the ld.so path it seems
>> that they do want those libraries to be public after all.
>>
>> I suggest that you:
>> - split libakai into a separate library package
>> - move both libraries into /usr/lib/
>> - bash upstream until they do this properly :)
>
> Ok ... it looks like a plan ;)
> Should we have also 2 separate -dev packages gig and akai ?

 I think that would be OK as well, but it doesn't matter as much. Both
 libraries are "part of" libgig but it doesn't look like one depends on
 the other at all. They also have separate pkgconfig files so I expect
 upstream intends for them to be treated as completely separate libraries
 maybe.
>>>
>>> include dir contains akai SF RIFF gig korg DLS header ... lets keep
>>> them together in one dev package for now.
>>
>> Ok ... fixed now :) libgig builds fine ...
>> I also tried build qsampler ... it builds but will need some patch to
>> fix search for libgig/SF.h ... quite should be easy
>
> If qsampler needs a patch, you've done something wrong. Moving the
> libraries should have had no affect on other packages (unless they are
> actually hard coding the lib path). Why have the headers changed?

qsampler search for libgig/SF.h ... till now (with old libgig) it was
never found ( it wasn't exist) and qsampler was build without this
fuctionality
SF.h is new header provided by new libgig 4.0.0 ... and now all header
are moved from usr/include/libgig to usr/include/

You still think I have done something wrong?

best regards

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[James Cowgill]

Hi

On 23/11/16 22:02, Jaromír Mikeš wrote:
> 2016-11-22 16:40 GMT+01:00 Jaromír Mikeš :
>> 2016-11-22 15:30 GMT+01:00 James Cowgill :
>>> Hi,
>>>
>>> On 22/11/16 14:14, Jaromír Mikeš wrote:
 2016-11-22 12:29 GMT+01:00 James Cowgill :
>> 2016-11-21 19:43 GMT+01:00 Jaromír Mikeš :
>> So what we can do?
>
> Since upstream have added /usr/lib/libgig to the ld.so path it seems
> that they do want those libraries to be public after all.
>
> I suggest that you:
> - split libakai into a separate library package
> - move both libraries into /usr/lib/
> - bash upstream until they do this properly :)

 Ok ... it looks like a plan ;)
 Should we have also 2 separate -dev packages gig and akai ?
>>>
>>> I think that would be OK as well, but it doesn't matter as much. Both
>>> libraries are "part of" libgig but it doesn't look like one depends on
>>> the other at all. They also have separate pkgconfig files so I expect
>>> upstream intends for them to be treated as completely separate libraries
>>> maybe.
>>
>> include dir contains akai SF RIFF gig korg DLS header ... lets keep
>> them together in one dev package for now.
> 
> Ok ... fixed now :) libgig builds fine ...
> I also tried build qsampler ... it builds but will need some patch to
> fix search for libgig/SF.h ... quite should be easy

If qsampler needs a patch, you've done something wrong. Moving the
libraries should have had no affect on other packages (unless they are
actually hard coding the lib path). Why have the headers changed?

James



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-11-22 16:40 GMT+01:00 Jaromír Mikeš :
> 2016-11-22 15:30 GMT+01:00 James Cowgill :
>> Hi,
>>
>> On 22/11/16 14:14, Jaromír Mikeš wrote:
>>> 2016-11-22 12:29 GMT+01:00 James Cowgill :
> 2016-11-21 19:43 GMT+01:00 Jaromír Mikeš :
> So what we can do?

 Since upstream have added /usr/lib/libgig to the ld.so path it seems
 that they do want those libraries to be public after all.

 I suggest that you:
 - split libakai into a separate library package
 - move both libraries into /usr/lib/
 - bash upstream until they do this properly :)
>>>
>>> Ok ... it looks like a plan ;)
>>> Should we have also 2 separate -dev packages gig and akai ?
>>
>> I think that would be OK as well, but it doesn't matter as much. Both
>> libraries are "part of" libgig but it doesn't look like one depends on
>> the other at all. They also have separate pkgconfig files so I expect
>> upstream intends for them to be treated as completely separate libraries
>> maybe.
>
> include dir contains akai SF RIFF gig korg DLS header ... lets keep
> them together in one dev package for now.
>

Ok ... fixed now :) libgig builds fine ...
I also tried build qsampler ... it builds but will need some patch to
fix search for libgig/SF.h ... quite should be easy
gigedit builds fine ...

Can someone review and upload libgig to experimental now pls?
James?

best regards

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-11-22 15:30 GMT+01:00 James Cowgill :
> Hi,
>
> On 22/11/16 14:14, Jaromír Mikeš wrote:
>> 2016-11-22 12:29 GMT+01:00 James Cowgill :
 2016-11-21 19:43 GMT+01:00 Jaromír Mikeš :
 So what we can do?
>>>
>>> Since upstream have added /usr/lib/libgig to the ld.so path it seems
>>> that they do want those libraries to be public after all.
>>>
>>> I suggest that you:
>>> - split libakai into a separate library package
>>> - move both libraries into /usr/lib/
>>> - bash upstream until they do this properly :)
>>
>> Ok ... it looks like a plan ;)
>> Should we have also 2 separate -dev packages gig and akai ?
>
> I think that would be OK as well, but it doesn't matter as much. Both
> libraries are "part of" libgig but it doesn't look like one depends on
> the other at all. They also have separate pkgconfig files so I expect
> upstream intends for them to be treated as completely separate libraries
> maybe.

include dir contains akai SF RIFF gig korg DLS header ... lets keep
them together in one dev package for now.

dh_shlibdeps
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/libakai/usr/lib/*/libakai.so.*/libakai.so.0.0.0 was not linked
against libuuid.so.1 (it uses none of the library's symbols)
dpkg-shlibdeps: error: couldn't find library libakai.so.0 needed by
debian/gigtools/usr/bin/akaidump (ELF format: 'elf64-x86-64'; RPATH:
'/usr/lib/x86_64-linux-gnu/libgig')
dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
debian/gigtools/usr/bin/sf2extract (ELF format: 'elf64-x86-64'; RPATH:
'/usr/lib/x86_64-linux-gnu/libgig')
dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
debian/gigtools/usr/bin/gigdump (ELF format: 'elf64-x86-64'; RPATH:
'/usr/lib/x86_64-linux-gnu/libgig')
dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
debian/gigtools/usr/bin/gigextract (ELF format: 'elf64-x86-64'; RPATH:
'/usr/lib/x86_64-linux-gnu/libgig')
dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
debian/gigtools/usr/bin/korgdump (ELF format: 'elf64-x86-64'; RPATH:
'/usr/lib/x86_64-linux-gnu/libgig')
dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
debian/gigtools/usr/bin/rifftree (ELF format: 'elf64-x86-64'; RPATH:
'/usr/lib/x86_64-linux-gnu/libgig')
dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
debian/gigtools/usr/bin/dlsdump (ELF format: 'elf64-x86-64'; RPATH:
'/usr/lib/x86_64-linux-gnu/libgig')
dpkg-shlibdeps: error: couldn't find library libakai.so.0 needed by
debian/gigtools/usr/bin/akaiextract (ELF format: 'elf64-x86-64';
RPATH: '/usr/lib/x86_64-linux-gnu/libgig')
dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
debian/gigtools/usr/bin/korg2gig (ELF format: 'elf64-x86-64'; RPATH:
'/usr/lib/x86_64-linux-gnu/libgig')
dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
debian/gigtools/usr/bin/sf2dump (ELF format: 'elf64-x86-64'; RPATH:
'/usr/lib/x86_64-linux-gnu/libgig')
dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
debian/gigtools/usr/bin/gig2mono (ELF format: 'elf64-x86-64'; RPATH:
'/usr/lib/x86_64-linux-gnu/libgig')
dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
debian/gigtools/usr/bin/gigmerge (ELF format: 'elf64-x86-64'; RPATH:
'/usr/lib/x86_64-linux-gnu/libgig')
dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
debian/gigtools/usr/bin/gig2stereo (ELF format: 'elf64-x86-64'; RPATH:
'/usr/lib/x86_64-linux-gnu/libgig')
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/gigtools/usr/bin/akaidump debian/gigtools/usr/bin/sf2extract
debian/gigtools/usr/bin/gigdump debian/gigtools/usr/bin/gigextract
debian/gigtools/usr/bin/korgdump debian/gigtools/usr/bin/rifftree
debian/gigtools/usr/bin/dlsdump debian/gigtools/usr/bin/akaiextract
debian/gigtools/usr/bin/korg2gig debian/gigtools/usr/bin/sf2dump
debian/gigtools/usr/bin/gig2mono debian/gigtools/usr/bin/gigmerge
debian/gigtools/usr/bin/gig2stereo were not linked against
libuuid.so.1 (they use none of the library's symbols)
dpkg-shlibdeps: error: cannot continue due to the errors listed above

Looks like rpath must be fixed ... I also tried by patch but didn't succeeded :(

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[James Cowgill]

Hi,

On 22/11/16 14:14, Jaromír Mikeš wrote:
> 2016-11-22 12:29 GMT+01:00 James Cowgill :
>>> 2016-11-21 19:43 GMT+01:00 Jaromír Mikeš :
>>> So what we can do?
>>
>> Since upstream have added /usr/lib/libgig to the ld.so path it seems
>> that they do want those libraries to be public after all.
>>
>> I suggest that you:
>> - split libakai into a separate library package
>> - move both libraries into /usr/lib/
>> - bash upstream until they do this properly :)
> 
> Ok ... it looks like a plan ;)
> Should we have also 2 separate -dev packages gig and akai ?

I think that would be OK as well, but it doesn't matter as much. Both
libraries are "part of" libgig but it doesn't look like one depends on
the other at all. They also have separate pkgconfig files so I expect
upstream intends for them to be treated as completely separate libraries
maybe.

James



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-11-22 12:29 GMT+01:00 James Cowgill :
> Hi,
>
> On 21/11/16 20:42, Jaromír Mikeš wrote:
>> 2016-11-21 19:43 GMT+01:00 Jaromír Mikeš :
>>> I've contacted upstream ... let's see what's happend
>>
>> Here we go ... answer from upstream ...
>> -
>> Wrong revision. This is the correct one of the actual changes you are
>> interested in here:
>>
>> http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision=2572
>
> I still think upstream is wrong here but whatever.
>
>> In this revision several things happened. First of all, it added AKAI support
>> to libgig. Since the AKAI source files were based on libakai, which in turn
>> was and is released under LGPL, while the rest of libgig is released under 
>> GPL
>> terms, I had to split those libgig parts into separate .so files, to avoid 
>> any
>> license confusions.
>
> Good so far...
>
>> Having a 2nd .so file built though, this triggered issues with the Debian
>> packaging scripts as far as I can remember. So I was forced to move the .so
>> files from /usr/lib to a common subdirectory /usr/lib/libgig.
>
> Oh no...
>
>> And by the way, the Debian packaging scripts coming with the libgig upstream
>> version build, install, and behave just fine on Debian! :-)
>>
>> As you might see in the Debian packaging scripts coming with the libgig
>> upstream version there are postinst and postrm rules which ensure that
>> /usr/lib/libgig is added / removed to /etc/ld.so.conf.
>
> This is probably the worst part - why on earth is libgig messing with
> the ld.so config ?! It seems to me that upstream don't really know what
> they're doing with this.
>
>> So what we can do?
>
> Since upstream have added /usr/lib/libgig to the ld.so path it seems
> that they do want those libraries to be public after all.
>
> I suggest that you:
> - split libakai into a separate library package
> - move both libraries into /usr/lib/
> - bash upstream until they do this properly :)

Ok ... it looks like a plan ;)
Should we have also 2 separate -dev packages gig and akai ?

best regards

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[James Cowgill]

Hi,

On 21/11/16 20:42, Jaromír Mikeš wrote:
> 2016-11-21 19:43 GMT+01:00 Jaromír Mikeš :
>> I've contacted upstream ... let's see what's happend
> 
> Here we go ... answer from upstream ...
> -
> Wrong revision. This is the correct one of the actual changes you are
> interested in here:
> 
> http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision=2572

I still think upstream is wrong here but whatever.

> In this revision several things happened. First of all, it added AKAI support
> to libgig. Since the AKAI source files were based on libakai, which in turn
> was and is released under LGPL, while the rest of libgig is released under GPL
> terms, I had to split those libgig parts into separate .so files, to avoid any
> license confusions.

Good so far...

> Having a 2nd .so file built though, this triggered issues with the Debian
> packaging scripts as far as I can remember. So I was forced to move the .so
> files from /usr/lib to a common subdirectory /usr/lib/libgig.

Oh no...

> And by the way, the Debian packaging scripts coming with the libgig upstream
> version build, install, and behave just fine on Debian! :-)
> 
> As you might see in the Debian packaging scripts coming with the libgig
> upstream version there are postinst and postrm rules which ensure that
> /usr/lib/libgig is added / removed to /etc/ld.so.conf.

This is probably the worst part - why on earth is libgig messing with
the ld.so config ?! It seems to me that upstream don't really know what
they're doing with this.

> So what we can do?

Since upstream have added /usr/lib/libgig to the ld.so path it seems
that they do want those libraries to be public after all.

I suggest that you:
- split libakai into a separate library package
- move both libraries into /usr/lib/
- bash upstream until they do this properly :)

Thanks,
James



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-11-21 19:43 GMT+01:00 Jaromír Mikeš :
> 2016-11-21 15:17 GMT+01:00 James Cowgill :
>> Hi,
>>
>> On 21/11/16 13:48, Jaromír Mikeš wrote:
>>> Hi,
>>>
>>> I am trying build locally qsampler 4.2.0 gigedit 1.0.0 against libgig 4.0.0
>>> I guess there is something wrong with libgig ... can somebody advise
>>> where to start with fix?
>>>
>>> qsampler
>>> --
>>> dh_strip
>>>dh_makeshlibs
>>>dh_shlibdeps
>>> dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
>>> debian/qsampler/usr/bin/qsampler (ELF format: 'elf64-x86-64'; RPATH:
>>> '')
>>
>> https://anonscm.debian.org/cgit/pkg-multimedia/libgig.git/tree/debian/libgig7.install
>>
>> libgig.so.7 is not installed in the default library search path so dpkg
>> cannot find it. If you try to run this version of qsampler, it will
>> almost certainly fail with a ld.so error.
>>
>> If libgig is now a private library, then arguably no applications
>> should be using it. If not it should be installed in the system library
>> path. Perhaps you should ask upstream why they changed the install path?
>>
>> This commit did the change:
>> http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/Makefile.am?r1=2543=2571
>>
>> lib_LTLIBRARIES -> pkglib_LTLIBRARIES
>
> Thank you James.
>
> I've contacted upstream ... let's see what's happend

Here we go ... answer from upstream ...
-
Wrong revision. This is the correct one of the actual changes you are
interested in here:

http://svn.linuxsampler.org/cgi-bin/viewvc.cgi?view=revision=2572

In this revision several things happened. First of all, it added AKAI support
to libgig. Since the AKAI source files were based on libakai, which in turn
was and is released under LGPL, while the rest of libgig is released under GPL
terms, I had to split those libgig parts into separate .so files, to avoid any
license confusions.

Having a 2nd .so file built though, this triggered issues with the Debian
packaging scripts as far as I can remember. So I was forced to move the .so
files from /usr/lib to a common subdirectory /usr/lib/libgig.

And by the way, the Debian packaging scripts coming with the libgig upstream
version build, install, and behave just fine on Debian! :-)

As you might see in the Debian packaging scripts coming with the libgig
upstream version there are postinst and postrm rules which ensure that
/usr/lib/libgig is added / removed to /etc/ld.so.conf.

Best regards,
Christian Schoenebeck
--

So what we can do?

best regards

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[Jaromír Mikeš]

2016-11-21 15:17 GMT+01:00 James Cowgill :
> Hi,
>
> On 21/11/16 13:48, Jaromír Mikeš wrote:
>> Hi,
>>
>> I am trying build locally qsampler 4.2.0 gigedit 1.0.0 against libgig 4.0.0
>> I guess there is something wrong with libgig ... can somebody advise
>> where to start with fix?
>>
>> qsampler
>> --
>> dh_strip
>>dh_makeshlibs
>>dh_shlibdeps
>> dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
>> debian/qsampler/usr/bin/qsampler (ELF format: 'elf64-x86-64'; RPATH:
>> '')
>
> https://anonscm.debian.org/cgit/pkg-multimedia/libgig.git/tree/debian/libgig7.install
>
> libgig.so.7 is not installed in the default library search path so dpkg
> cannot find it. If you try to run this version of qsampler, it will
> almost certainly fail with a ld.so error.
>
> If libgig is now a private library, then arguably no applications
> should be using it. If not it should be installed in the system library
> path. Perhaps you should ask upstream why they changed the install path?
>
> This commit did the change:
> http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/Makefile.am?r1=2543=2571
>
> lib_LTLIBRARIES -> pkglib_LTLIBRARIES

Thank you James.

I've contacted upstream ... let's see what's happend

mira

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Re: libgig 4.0.0 qsampler 4.2.0 gigedit 1.0.0

[James Cowgill]

Hi,

On 21/11/16 13:48, Jaromír Mikeš wrote:
> Hi,
> 
> I am trying build locally qsampler 4.2.0 gigedit 1.0.0 against libgig 4.0.0
> I guess there is something wrong with libgig ... can somebody advise
> where to start with fix?
> 
> qsampler
> --
> dh_strip
>dh_makeshlibs
>dh_shlibdeps
> dpkg-shlibdeps: error: couldn't find library libgig.so.7 needed by
> debian/qsampler/usr/bin/qsampler (ELF format: 'elf64-x86-64'; RPATH:
> '')

https://anonscm.debian.org/cgit/pkg-multimedia/libgig.git/tree/debian/libgig7.install

libgig.so.7 is not installed in the default library search path so dpkg
cannot find it. If you try to run this version of qsampler, it will
almost certainly fail with a ld.so error.

If libgig is now a private library, then arguably no applications
should be using it. If not it should be installed in the system library
path. Perhaps you should ask upstream why they changed the install path?

This commit did the change:
http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/libgig/trunk/src/Makefile.am?r1=2543=2571

lib_LTLIBRARIES -> pkglib_LTLIBRARIES

James



signature.asc
Description: OpenPGP digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers