m...@linux.it (Marco d'Itri) writes:
> On Feb 05, Simon Josefsson wrote:
>
>> 1) So what should be done now? Is 1.17 fine?
> I recommend that you remove the new symbol tag since it has no useful
> purpose.
Agreed, will do.
>> 2) What should have been done from the beginning? Increment the sha
On Feb 05, Simon Josefsson wrote:
> 1) So what should be done now? Is 1.17 fine?
I recommend that you remove the new symbol tag since it has no useful
purpose.
> 2) What should have been done from the beginning? Increment the shared
> library version?
No, you should not have added versioning b
m...@linux.it (Marco d'Itri) writes:
> On Feb 05, Simon Josefsson wrote:
>
>> I'm just looking for ideas on what do here. Are you suggesting that
>> libidn upstream should increment the shared library version to resolve
>> this?
> It's not, the solution would be to make the linker also emit unve
On Feb 05, Simon Josefsson wrote:
> I'm just looking for ideas on what do here. Are you suggesting that
> libidn upstream should increment the shared library version to resolve
> this?
It's not, the solution would be to make the linker also emit unversioned
symbols and have them appear as the de
m...@linux.it (Marco d'Itri) writes:
> On Feb 05, Simon Josefsson wrote:
>
>> >> > The problem is that this is not enough to make the built binaries work
>> >> > on stable again[1] because upstream gratuitously broke the ABI in 1.13
>> >> > by versioning the symbols and now it is too late to reve
On Feb 05, Simon Josefsson wrote:
> >> > The problem is that this is not enough to make the built binaries work
> >> > on stable again[1] because upstream gratuitously broke the ABI in 1.13
> >> > by versioning the symbols and now it is too late to revert the change.
> >> The symbols are the same
m...@linux.it (Marco d'Itri) writes:
> On Feb 05, Simon Josefsson wrote:
>
>> > The problem is that this is not enough to make the built binaries work
>> > on stable again[1] because upstream gratuitously broke the ABI in 1.13
>> > by versioning the symbols and now it is too late to revert the ch
On Feb 05, Simon Josefsson wrote:
> > The problem is that this is not enough to make the built binaries work
> > on stable again[1] because upstream gratuitously broke the ABI in 1.13
> > by versioning the symbols and now it is too late to revert the change.
> The symbols are the same, so the ABI
m...@linux.it (Marco d'Itri) writes:
> The problem is that this is not enough to make the built binaries work
> on stable again[1] because upstream gratuitously broke the ABI in 1.13
> by versioning the symbols and now it is too late to revert the change.
The symbols are the same, so the ABI shou
tags 561291 upstream
thanks
Debugging this further, I see that there is a upstream bug here. I've
explained the problem and proposed a solution at:
http://thread.gmane.org/gmane.comp.gnu.libidn.general/230
What do you think?
After a upstream release with that fix has been added, I propose to
u
On Jan 22, Simon Josefsson wrote:
> Btw, is the intention that libidn11.shlibs should be empty, or that the
> file should be removed? I couldn't really tell from the diff you
It must be removed.
> Oh, I see what you mean now. I get the build failure below when trying
> to build the archive wit
tags 561291 help
thanks
m...@linux.it (Marco d'Itri) writes:
> On Jan 21, Simon Josefsson wrote:
>
>> I have applied your libidn.symbols.diff patch to our repository, thanks!
>> (I did add a bunch of symbols that are exported by the library but was
>> not part of your libidn11.symbols file thoug
m...@linux.it (Marco d'Itri) writes:
> On Jan 21, Simon Josefsson wrote:
>
>> I have applied your libidn.symbols.diff patch to our repository, thanks!
>> (I did add a bunch of symbols that are exported by the library but was
>> not part of your libidn11.symbols file though.)
> Maybe you applied t
Btw, is the intention that libidn11.shlibs should be empty, or that the
file should be removed? I couldn't really tell from the diff you
provided. Building with an empty files provokes a warning from
pdebuild:
dpkg-source: warning: newly created empty file 'debian/libidn11.shlibs' will
not be r
On Jan 21, Simon Josefsson wrote:
> I have applied your libidn.symbols.diff patch to our repository, thanks!
> (I did add a bunch of symbols that are exported by the library but was
> not part of your libidn11.symbols file though.)
Maybe you applied the patch to a newer version? If I really had m
tags 561291 pending
thanks
I have applied your libidn.symbols.diff patch to our repository, thanks!
(I did add a bunch of symbols that are exported by the library but was
not part of your libidn11.symbols file though.)
I don't understand the purpose of the libidn.builddepends.diff change.
What er
tag 561291 patch
thanks
Here it is, along with another minor fix.
The problem is that this is not enough to make the built binaries work
on stable again[1] because upstream gratuitously broke the ABI in 1.13
by versioning the symbols and now it is too late to revert the change.
I suppose that th
On Tue, Dec 15, 2009 at 11:46:24PM +0100, Marco d'Itri wrote:
>Package: libidn11-dev
>Version: 1.15-2
>Severity: wishlist
>
>Lack of a .symbols file in the libidn package prevents at least one of
>my packages from being installable as is on oldstable.
>Please let me know if you need help and would
Package: libidn11-dev
Version: 1.15-2
Severity: wishlist
Lack of a .symbols file in the libidn package prevents at least one of
my packages from being installable as is on oldstable.
Please let me know if you need help and would rather get a complete
patch.
--
ciao,
Marco
signature.asc
Descrip
19 matches
Mail list logo
