Hi Flo,
I apologize for the very long delay. Thank you for preparing an NMU. Due
to my private situation I'm unable to continue maintaining this package.
Therefore, where is no reason to delay the upload any longer.
Cheers,
Sefan
Am 13.02.22 um 08:25 schrieb Florian Ernst:
Dear
Owner: stef.ahl...@t-online.de
Hi,
thank you for reporting this bug. This is a known upstream bug
(https://github.com/euroelessar/jreen/issues/40).
I'll adopt the fedora patch to fix it.
Kind regards,
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
+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 <stef.ahl...@t-online.de> Fri, 11 Dec 2015 09:00:00 +0100
+
libechonest (2.3.1-0.2) unstable;
Hello,
> which, besides a date from the future, lacks a vital line:
> * Drop bogus libechonest2.1 (Closes: #807507)
>
> Thus, I'm hereby closing this manually.
>
> 2.3.1-0.1 does break its users, but fortunately there's only one such
user,
> clementine. I've just requested a rebuild of it
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
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
But in short: transitiong from the old SONAME to the
> new
> SONAME is done via rebuilds of the rev deps, not via the old library package
> pulling in the new one.
Oh ok, now I understand it! Thank you for your hint! I'll fix it.
Kindly regards,
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
regards,
Stefan Ahlers
Hi,
libechonest2.3.1 provides libechonest.so.2.3 and so clementine has to be
rebuild against libechonest2.3, after rebuilding, clementine will work
correctly.
Kind regards,
Stefan Ahlers
Hi,
> You need to drop libechonest2.1 from the package. An empty libechonest2.1
> depending on libechonest2.3 is wrong.
libechonest2.1 is a transitional dummy package
(https://wiki.debian.org/Renaming_a_Package). And so it should be correct that
this package is empty.
Regards,
Stefan Ahlers
12 matches
Mail list logo
