Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[John Paul Adrian Glaubitz]

On 12/14/2015 08:19 AM, Stefan Ahlers wrote:
> What should we do now? A new build only to fix the sh4 symbols or shell
> we fix it for the next release?

sh4 is one of my pet architectures. I will have a look and report back
later. I still need to set up the four more additional buildds to
speed up the build process similar to m68k. Hopefully I can do that
today, I still had to spend lots of time into getting ghc fixed
on sparc64 :).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[Stefan Ahlers]

Hi,

I'm a little bit confused about the sh4 build of libechonest. It failed
because there appears a new symbol:

 (c++)"QDebug::operator<<(QByteArray const&)@Base" 2.3.1-0.3

on all  architectures there is the following Symbol:

 (c++)"QDebug::operator<<(QString const&)@Base" 2.3.1

Why does sh4 uses QString and QByteArray for this method and why only in
the Qt5 build?

What should we do now? A new build only to fix the sh4 symbols or shell
we fix it for the next release?

Stefan

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[Stefan Ahlers]

Hi Adrian,

> If you like, you can send me a debdiff with your changes and I can
> quickly review it and test-build it on one of the buildds.

here is a new version of the debdiff. I have included the differences of
armhf and armel architechture into the libechonest2.3.symbol file.
I hope I have not make a mistake, again.

Cheers,
Stefan
diff -Nru libechonest-2.3.1/debian/changelog libechonest-2.3.1/debian/changelog
--- libechonest-2.3.1/debian/changelog  2015-12-10 12:43:21.0 +0100
+++ libechonest-2.3.1/debian/changelog  2015-12-11 10:20:47.0 +0100
@@ -1,9 +1,17 @@
+libechonest (2.3.1-0.3) unstable; urgency=low
+
+  * Non-maintainer upload, with maintainer permission.
+  * Fix symbols again.
+  * Drop bogus libechonest2.1 (Closes: #807507)
+
+ -- Stefan Ahlers   Fri, 11 Dec 2015 09:00:00 +0100
+
 libechonest (2.3.1-0.2) unstable; urgency=low
 
   * Non-maintainer upload, with maintainer permission.
   * Fix symbols.
 
- -- Stefan Ahlers   Thu, 26 Dec 2015 12:00:00 +0100
+ -- Stefan Ahlers   Thu, 10 Dec 2015 12:00:00 +0100
 
 libechonest (2.3.1-0.1) unstable; urgency=low
 
@@ -21,7 +29,7 @@
   * Set myself as the new maintainer with permission of Lisandro the original
 maintainer.
   * Update package repository location.
-
+ 
  -- Thomas Pierson   Sun, 11 Oct 2015 22:43:01 +0200
 
 libechonest (2.1.0-2) unstable; urgency=low
diff -Nru libechonest-2.3.1/debian/libechonest2.3.symbols 
libechonest-2.3.1/debian/libechonest2.3.symbols
--- libechonest-2.3.1/debian/libechonest2.3.symbols 2015-12-10 
11:40:27.0 +0100
+++ libechonest-2.3.1/debian/libechonest2.3.symbols 2015-12-11 
10:15:08.0 +0100
@@ -39,38 +39,57 @@
  _ZN8Echonest11CatalogSongD1Ev@Base 2.1.0
  _ZN8Echonest11CatalogSongD2Ev@Base 2.1.0
  _ZN8Echonest11CatalogSongaSERKS0_@Base 2.1.0
- _ZN8Echonest12AudioSummary10setValenceEd@Base 2.3.0
- _ZN8Echonest12AudioSummary11setDurationEd@Base 2.1.0
- _ZN8Echonest12AudioSummary11setLivenessEd@Base 2.3.0 
- _ZN8Echonest12AudioSummary11setLoudnessEd@Base 2.1.0
+ (arch=!armhf !armel)_ZN8Echonest12AudioSummary10setValenceEd@Base 2.3.0
+ (arch=!armhf !armel)_ZN8Echonest12AudioSummary11setDurationEd@Base 2.1.0
+ (arch=!armhf !armel)_ZN8Echonest12AudioSummary11setLivenessEd@Base 2.3.0 
+ (arch=!armhf !armel)_ZN8Echonest12AudioSummary11setLoudnessEd@Base 2.1.0
+ (arch=armhf armel)_ZN8Echonest12AudioSummary10setValenceEf@Base 2.3.0
+ (arch=armhf armel)_ZN8Echonest12AudioSummary11setDurationEf@Base 2.1.0
+ (arch=armhf armel)_ZN8Echonest12AudioSummary11setLivenessEf@Base 2.3.0 
+ (arch=armhf armel)_ZN8Echonest12AudioSummary11setLoudnessEf@Base 2.1.0
  _ZN8Echonest12AudioSummary11setSectionsERK7QVectorINS_10AudioChunkEE@Base 
2.1.0
  _ZN8Echonest12AudioSummary11setSegmentsERK7QVectorINS_7SegmentEE@Base 2.1.0
  _ZN8Echonest12AudioSummary12setSampleMD5ERK7QString@Base 2.1.0
- _ZN8Echonest12AudioSummary12setTimestampEd@Base 2.1.0
+ (arch=!armhf !armel)_ZN8Echonest12AudioSummary12setTimestampEd@Base 2.1.0
+ (arch=armhf armel)_ZN8Echonest12AudioSummary12setTimestampEf@Base 2.1.0
+ _ZN8Echonest12AudioSummary12setTimestampEf@Base 2.1.0
  _ZN8Echonest12AudioSummary13setNumSamplesEx@Base 2.1.0
- _ZN8Echonest12AudioSummary13setSampleRateEd@Base 2.1.0
+ (arch=!armhf !armel)_ZN8Echonest12AudioSummary13setSampleRateEd@Base 2.1.0
+ (arch=armhf armel)_ZN8Echonest12AudioSummary13setSampleRateEf@Base 2.1.0
  _ZN8Echonest12AudioSummary14setAnalysisUrlERK4QUrl@Base 2.1.0
- _ZN8Echonest12AudioSummary14setEndOfFadeInEd@Base 2.1.0
- _ZN8Echonest12AudioSummary14setSpeechinessEd@Base 2.3.0 
- _ZN8Echonest12AudioSummary15setAcousticnessEd@Base 2.3.0 
- _ZN8Echonest12AudioSummary15setAnalysisTimeEd@Base 2.1.0
- _ZN8Echonest12AudioSummary15setDanceabilityEd@Base 2.1.0
- _ZN8Echonest12AudioSummary16setKeyConfidenceEd@Base 2.1.0
+ (arch=!armhf !armel)_ZN8Echonest12AudioSummary14setEndOfFadeInEd@Base 2.1.0
+ (arch=!armhf !armel)_ZN8Echonest12AudioSummary14setSpeechinessEd@Base 2.3.0 
+ (arch=!armhf !armel)_ZN8Echonest12AudioSummary15setAcousticnessEd@Base 2.3.0 
+ (arch=!armhf !armel)_ZN8Echonest12AudioSummary15setAnalysisTimeEd@Base 2.1.0
+ (arch=!armhf !armel)_ZN8Echonest12AudioSummary15setDanceabilityEd@Base 2.1.0
+ (arch=!armhf !armel)_ZN8Echonest12AudioSummary16setKeyConfidenceEd@Base 2.1.0
+ (arch=armhf armel)_ZN8Echonest12AudioSummary14setEndOfFadeInEf@Base 2.1.0
+ (arch=armhf armel)_ZN8Echonest12AudioSummary14setSpeechinessEf@Base 2.3.0 
+ (arch=armhf armel)_ZN8Echonest12AudioSummary15setAcousticnessEf@Base 2.3.0 
+ (arch=armhf armel)_ZN8Echonest12AudioSummary15setAnalysisTimeEf@Base 2.1.0
+ (arch=armhf armel)_ZN8Echonest12AudioSummary15setDanceabilityEf@Base 2.1.0
+ (arch=armhf armel)_ZN8Echonest12AudioSummary16setKeyConfidenceEf@Base 2.1.0
  _ZN8Echonest12AudioSummary16setTimeSignatureEi@Base 2.1.0
  _ZN8Echonest12AudioSummary17parseFullAnalysisEP13QNetworkReply@Base 2.1.0
  

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[Stefan Ahlers]

Hi,

first of all, thank you for your help, both of you! I also learned a lot
from this experience.

> e.g. a symbol was leftover in symbols file:
> + _ZN8Echonest12AudioSummary12setTimestampEf@Base 2.1.0
> and was preventing amd64 and i386 builds to succeed.

You are right, it seems that I have forgotten this line to exclude for
the other architecture, sorry. But now it looks good for me, too!

The package on mentors.debian.net should be up to date, now. (Hopefully :-))

Stefan

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[John Paul Adrian Glaubitz]

(Sorry for the slightly asynchronous reply, I got interrupted)

On 12/11/2015 03:01 PM, Gianfranco Costamagna wrote:
> this is *exactly* the reason for trying all yesterday evening to get it 
> working :)
> (pbuilder now fails under qemu and arm*, probably because of the new 
> aptitude, so I had to push on DebOMatic my builds)

Use sbuild instead. It's much more flexible anyway and easier to
set up and also what we use on the official buildds (and the
buildds in debian-ports).

I have stopped pbuilder long time ago, too unflexible and too
slow. sbuild with eatmydata, ccache and btrfs-snapshots is
extremely fast. Just using eatmydata cut my build times in
half for smaller packages.

>> If you are sure that the symbol files for all architectures are
>> fixed, please go ahead and upload. I can take care of the ports
>> architectures in case something breaks.
> 
> 
> I guess also the ports should be good.

Yeah, you got the build logs as a reference, so it shouldn't
be too difficult.

> (I don't want to steal your upload, but I spent all yesterday looking at this 
> package, and I'm learning a lot from this experience :) )

Don't worry. It's not important for me to do it myself, especially
when others can learn from this experience. I have done such fixes
endless times, I don't find them entertaining anymore ;-).

Just make sure everything is fixed properly to avoid additional
uploads.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[Stefan Ahlers]

Hi,

> anyway, I still get issues with armhf and armel, but this time they seem to 
> be related
> to one symbols wrong copy-pasted on line 249
> _ZN8Echonest4Term9setWeightEf@Base instead of 
> _ZN8Echonest4Term12setFrequencyEf@Base

Hmm, it looks like I'm too unconsecrated. Fixed.
> and something on the qt5 package.
Ok, this was a copy and paste error, too. armhf was listed for the wrong
symbols. Done.

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[Gianfranco Costamagna]

Hi again,

>Btw, Stefan noticed that armel and armhf seem to have completely
>different symbol tables as the types for many of the function
>symbols are changed from double to float.
>
>Did you verify that?


this is *exactly* the reason for trying all yesterday evening to get it working 
:)
(pbuilder now fails under qemu and arm*, probably because of the new aptitude, 
so I had to push on DebOMatic my builds)

I could try a porterbox next time...

>If you are sure that the symbol files for all architectures are
>fixed, please go ahead and upload. I can take care of the ports
>architectures in case something breaks.


I guess also the ports should be good.


I think we are good now, lets see!

(I don't want to steal your upload, but I spent all yesterday looking at this 
package, and I'm learning a lot from this experience :) )

cheers!

G.

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[Gianfranco Costamagna]

I'm looking at it soon.

I already have a look yesterday, but I had issues with some arm platforms.

Now I should have time to finish it.

cheers,

G.





Il Venerdì 11 Dicembre 2015 10:27, Stefan Ahlers  ha 
scritto:
Hi Adrian,

> If you like, you can send me a debdiff with your changes and I can
> quickly review it and test-build it on one of the buildds.

here is a new version of the debdiff. I have included the differences of
armhf and armel architechture into the libechonest2.3.symbol file.
I hope I have not make a mistake, again.

Cheers,
Stefan

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[John Paul Adrian Glaubitz]

On 12/11/2015 02:36 PM, Gianfranco Costamagna wrote:
> I'm looking at it soon.

You don't have to. Stefan has already made a proposed change which
I will testbuild later today or tomorrow. I'm just still at work :).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[John Paul Adrian Glaubitz]

On 12/11/2015 02:56 PM, Gianfranco Costamagna wrote:
> I have a build ongoing right now in amd64 i386 arm64 armel armhf powerpc.

Sounds good.

> the builds seems fine, at least I had to tweak a little bit the symbols and 
> change something in changelog

Ok, good.

> e.g. a symbol was leftover in symbols file:
> + _ZN8Echonest12AudioSummary12setTimestampEf@Base 2.1.0
> and was preventing amd64 and i386 builds to succeed.

Btw, Stefan noticed that armel and armhf seem to have completely
different symbol tables as the types for many of the function
symbols are changed from double to float.

Did you verify that?

> as you wish, if you want to sponsor please look at this debdiff, otherwise I 
> can sponsor in a few minutes, because it seems good now.

If you are sure that the symbol files for all architectures are
fixed, please go ahead and upload. I can take care of the ports
architectures in case something breaks.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[Gianfranco Costamagna]

Hi,

>You are right, it seems that I have forgotten this line to exclude for
>the other architecture, sorry. But now it looks good for me, too!


nope, the lines was already splitted, just just forgot to delete it.
now you have twice that symbol.

anyway, I still get issues with armhf and armel, but this time they seem to be 
related
to one symbols wrong copy-pasted on line 249
_ZN8Echonest4Term9setWeightEf@Base instead of 
_ZN8Echonest4Term12setFrequencyEf@Base

and something on the qt5 package.


- (arch=alpha amd64 arm64 armhf kfreebsd-amd64 mips64el ppc64 ppc64el s390x 
sparc64)_ZThn16_N8Echonest11CatalogSongD0Ev@Base 2.1.0
- (arch=alpha amd64 arm64 armhf kfreebsd-amd64 mips64el ppc64 ppc64el s390x 
sparc64)_ZThn16_N8Echonest11CatalogSongD1Ev@Base 2.1.0
- (arch=alpha amd64 arm64 armhf kfreebsd-amd64 mips64el ppc64 ppc64el s390x 
sparc64)_ZThn16_N8Echonest13CatalogArtistD0Ev@Base 2.1.0
- (arch=alpha amd64 arm64 armhf kfreebsd-amd64 mips64el ppc64 ppc64el s390x 
sparc64)_ZThn16_N8Echonest13CatalogArtistD1Ev@Base 2.1.0
- (arch=alpha amd64 arm64 armhf kfreebsd-amd64 mips64el ppc64 ppc64el s390x 
sparc64)_ZThn16_NK8Echonest11CatalogSong4typeEv@Base 2.1.0
- (arch=alpha amd64 arm64 armhf kfreebsd-amd64 mips64el ppc64 ppc64el s390x 
sparc64)_ZThn16_NK8Echonest13CatalogArtist4typeEv@Base 2.1.0
- (arch=!alpha !amd64 !arm64 !armhf !kfreebsd-amd64 !mips64el !ppc64 !ppc64el 
!s390x !sparc64)_ZThn8_N8Echonest11CatalogSongD0Ev@Base 2.1.0
- (arch=!alpha !amd64 !arm64 !armhf !kfreebsd-amd64 !mips64el !ppc64 !ppc64el 
!s390x !sparc64)_ZThn8_N8Echonest11CatalogSongD1Ev@Base 2.1.0
- (arch=!alpha !amd64 !arm64 !armhf !kfreebsd-amd64 !mips64el !ppc64 !ppc64el 
!s390x !sparc64)_ZThn8_N8Echonest13CatalogArtistD0Ev@Base 2.1.0
- (arch=!alpha !amd64 !arm64 !armhf !kfreebsd-amd64 !mips64el !ppc64 !ppc64el 
!s390x !sparc64)_ZThn8_N8Echonest13CatalogArtistD1Ev@Base 2.1.0
- (arch=!alpha !amd64 !arm64 !armhf !kfreebsd-amd64 !mips64el !ppc64 !ppc64el 
!s390x !sparc64)_ZThn8_NK8Echonest11CatalogSong4typeEv@Base 2.1.0
- (arch=!alpha !amd64 !arm64 !armhf !kfreebsd-amd64 !mips64el !ppc64 !ppc64el 
!s390x !sparc64)_ZThn8_NK8Echonest13CatalogArtist4typeEv@Base 2.1.0
+#MISSING: 2.3.1-0.3# (arch=alpha amd64 arm64 armhf kfreebsd-amd64 mips64el 
ppc64 ppc64el s390x sparc64)_ZThn16_N8Echonest11CatalogSongD0Ev@Base 2.1.0
+#MISSING: 2.3.1-0.3# (arch=alpha amd64 arm64 armhf kfreebsd-amd64 mips64el 
ppc64 ppc64el s390x sparc64)_ZThn16_N8Echonest11CatalogSongD1Ev@Base 2.1.0
+#MISSING: 2.3.1-0.3# (arch=alpha amd64 arm64 armhf kfreebsd-amd64 mips64el 
ppc64 ppc64el s390x sparc64)_ZThn16_N8Echonest13CatalogArtistD0Ev@Base 2.1.0
+#MISSING: 2.3.1-0.3# (arch=alpha amd64 arm64 armhf kfreebsd-amd64 mips64el 
ppc64 ppc64el s390x sparc64)_ZThn16_N8Echonest13CatalogArtistD1Ev@Base 2.1.0
+#MISSING: 2.3.1-0.3# (arch=alpha amd64 arm64 armhf kfreebsd-amd64 mips64el 
ppc64 ppc64el s390x sparc64)_ZThn16_NK8Echonest11CatalogSong4typeEv@Base 2.1.0
+#MISSING: 2.3.1-0.3# (arch=alpha amd64 arm64 armhf kfreebsd-amd64 mips64el 
ppc64 ppc64el s390x sparc64)_ZThn16_NK8Echonest13CatalogArtist4typeEv@Base 2.1.0
+ _ZThn8_N8Echonest11CatalogSongD0Ev@Base 2.1.0
+ _ZThn8_N8Echonest11CatalogSongD1Ev@Base 2.1.0
+ _ZThn8_N8Echonest13CatalogArtistD0Ev@Base 2.1.0
+ _ZThn8_N8Echonest13CatalogArtistD1Ev@Base 2.1.0
+ _ZThn8_NK8Echonest11CatalogSong4typeEv@Base 2.1.0
+ _ZThn8_NK8Echonest13CatalogArtist4typeEv@Base 2.1.0




I'll be back soon.

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[Gianfranco Costamagna]

I have a build ongoing right now in amd64 i386 arm64 armel armhf powerpc.

the builds seems fine, at least I had to tweak a little bit the symbols and 
change something in changelog

e.g. a symbol was leftover in symbols file:
+ _ZN8Echonest12AudioSummary12setTimestampEf@Base 2.1.0
and was preventing amd64 and i386 builds to succeed.

as you wish, if you want to sponsor please look at this debdiff, otherwise I 
can sponsor in a few minutes, because it seems good now.

cheers,

G.




Il Venerdì 11 Dicembre 2015 14:39, John Paul Adrian Glaubitz 
 ha scritto:
On 12/11/2015 02:36 PM, Gianfranco Costamagna wrote:
> I'm looking at it soon.

You don't have to. Stefan has already made a proposed change which
I will testbuild later today or tomorrow. I'm just still at work :).

Adrian

-- 
.''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


-- 
To unsubscribe, send mail to 807589-unsubscr...@bugs.debian.org.


debdiff
Description: Binary data

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[Stefan Ahlers]

Hi Adrian,

thank you for your fast reply!
> In any case, the common method that I have been using so far was to use
> a common symbols file but specify the architecture list with "arch=amd64
> arm64" and so on. This has been supported for a long time already
> and works with all currently deployed versions of dpkg.

I'm trying your solution. Thank yourfor your help and that you
investigate the problem with arch-bits=

Cheers,
Stefan

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[John Paul Adrian Glaubitz]

Hi Stefan!

On 12/10/2015 06:09 PM, Stefan Ahlers wrote:
>> In any case, the common method that I have been using so far was to use
>> a common symbols file but specify the architecture list with "arch=amd64
>> arm64" and so on. This has been supported for a long time already
>> and works with all currently deployed versions of dpkg.
> 
> I'm trying your solution. Thank yourfor your help and that you
> investigate the problem with arch-bits=

No problem.

If you like, you can send me a debdiff with your changes and I can
quickly review it and test-build it on one of the buildds.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[John Paul Adrian Glaubitz]

Hi Stefan!

On 12/10/2015 05:35 PM, Stefan Ahlers wrote:
> my NMU was unsuccessful and I would be really happy if you could help me.

Sure, I'm happy to help.

> The problem is that there are symbols, which are different on 32bit and
> 64bit based architectures. And so I'm looking for a way to handle this
> in one single file instead of one file per architectures.
> 
> In the man page of dpgk-gensymbols,  I found a option called
> (arch-bits=32) and (arch-bits=64) but it looks like
> 
>  (arch-bits=32)_ZThn8_N8Echonest11CatalogSongD0Ev@Base 2.1.0
>  (arch-bits=64)_ZThn16_N8Echonest11CatalogSongD0Ev@Base 2.1.0
> 
> does not work. What's wrong? Is there any better solution?

That's interesting. I haven't heard of arch-bits= before but according
to the manpage of dpkg-gensymbols, it's also a very new feature
supported since dpkg_1.18.0 and according to the logs, the buildds
are actually using 1.18.3 in their chroots. However, outside the
chroots, the installed version of dpkg is most likely 1.17.26
which is the version found in stable (since the buildds are running
stable in most cases).

I will need to test arch-bits= to figure out under which circumstances
it fails. It might be the case that dpkg-gensymbols is actually called
outside the chroot which means it's going to be the stable version
instead of the unstable version of dpkg which understands arch-bits=.

I will try sbuilding your package on a build host running stable
and on one running unstable, however both in an unstable chroot
and see if that makes a difference.

In any case, the common method that I have been using so far was to use
a common symbols file but specify the architecture list with "arch=amd64
arm64" and so on. This has been supported for a long time already
and works with all currently deployed versions of dpkg.

Cheers,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[John Paul Adrian Glaubitz]

Source: libechonest
Version: 2.3.1-0.2
Severity: serious

Hello!

libechonest currently fails to build from source on *all* architectures
due to mismatched symbols file(s) after an unsuccessful NMU to fix
these files.

Please use the logs provided by the buildds [1] to fix the symbols for ALL
architectures, even on older architectures like m68k or sh4.

If you need assistance updating the symbol files for these architectures,
please let me know and I will help as I am an active porter for most
Debian Ports architectures.

Cheers,

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[Stefan Ahlers]

Hi Adrian,

my NMU was unsuccessful and I would be really happy if you could help me.

The problem is that there are symbols, which are different on 32bit and
64bit based architectures. And so I'm looking for a way to handle this
in one single file instead of one file per architectures.

In the man page of dpgk-gensymbols,  I found a option called
(arch-bits=32) and (arch-bits=64) but it looks like

 (arch-bits=32)_ZThn8_N8Echonest11CatalogSongD0Ev@Base 2.1.0
 (arch-bits=64)_ZThn16_N8Echonest11CatalogSongD0Ev@Base 2.1.0

does not work. What's wrong? Is there any better solution?

Kindly regards,
Stefan Ahlers