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

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

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

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

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

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

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

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

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

(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

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

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

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

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

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

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

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

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 -

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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