Re: How to be with SINA that has non-free dependency
Hi Elmar,
On Thu, Jun 13, 2019 at 11:24:03AM -0600, Elmar Pruesse wrote:
>
> Run:
>
> make bin/arb_pt_server
Works.
> and
>
> make lib/arb_tcp.dat
This target does not exist.
I needed to keep some more files from the original arb tarball in lib/
(which was removed totally in the former libarb tarball - if you get
the convinience files on people.d.o make sure you also fetch the new
tarball if you want to build from source)
> That should do it. I think you have all files required.
Now since there is also lib/arb_tcp_org.dat, yes.
> I'd make it a sepearate package, something like arb-pt-server, with
>
>
> arb-pt-server.install:
>
> bin/arb_pt_server usr/bin
>
> lib/arb_tcp.dat /etc/arb
>
>
> arb-pt-server.links:
>
> etc/arb/arb_tcp.dat usr/lib/${DEB_HOST_MULTIARCH}/arb
Do you think this link is only needed inside the arb-pt-server package
or is it better in libarb package? (I implemented the latter in the
latest packages.)
> > For the moment for me the take away message from the paragraph above
> > is that we need arb_tcp.dat from the original arb tarball. Anything
> > else?
>
> For backround: the "pt server" is a sequence search engine. It's very fast,
> but a memory hog. It was implemented as a daemon so that multiple users can
> share the index (which used to take hours to load). Not really common any
> more, but back in the day when 32MB was a ton of memory that was different.
>
>
> If you can package the arb_pt_server binary as above, the tests for SINA
> should run fine.
>
> If you cannot, you could just delete the file "SINA/tests/accuracy.tests"
> and then run "make check-filtered P=^tests" instead of "make check".
>
> The accuracy.tests file contains integration tests checking overall accuracy
> with the PT server. There is a second file that does the same tests with the
> internal engine. So not running it is fine. The check-filtered call avoids
> running the unit tests, calling only the integration tests on the fully
> built binary. That should be fine for packaging - you don't need to have
> 100% code coverage, you need to know that the build isn't broken.
>
> I would prefer the solution with tested arb_pt_server support. If I was to
> add a "no pt server support" flag to SINA it would have to disable the
> support as well, not just the tests. I can do that, it's going to be quite a
> bit of work though.
Since I'd prefer as much as possible tests I added the package.
Regarding SINA packaging: Do you think a Recommends: arb-pt-server or a
Suggests would be appropriate?
> > Thanks a lot for your contribution which is very motivating
> Thanks! :) I'm sorry that help from "upstream" is required. For good
> software, that should not be necessary.
> W.r.t. the build log - this is where it failed first:
>
> > configure:14608: checking arbdb.h usability
> > configure:14608: g++ -c -g -O2
> > -fdebug-prefix-map=/build/sina-1.6.0+dfsg=. -fstack-protector-strong
> > -Wformat -Werror=format-security -g -O2
> > -fdebug-prefix-map=/build/sina-1.6.0+dfsg=. -fstack-protector-strong
> > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
> > -DNDEBUG -I/usr/lib/x86_64-linux-gnu/arb/INCLUDE -I/usr/include/glib-2.0
> > -I/usr/lib/x86_64-linux-gnu/glib-2.0/include conftest.cpp >&5
> > conftest.cpp:63:10: fatal error: arbdb.h: No such file or directory
> > #include <arbdb.h>
> > ^~~~~~~~~
>
> Check that /usr/lib/x86_64-linux-gnu/arb/INCLUDE/arbdb.h exists. Perhaps I
> messed up the patch for libarb-dev. INCLUDE should point to
> /usr/include/arb.
The explanation was simple - the Build-Dependency libarb-dev was missing.
That's solved now but I get errors like
...
/usr/include/c++/8/bits/shared_ptr.h:359:59: required from ‘std::shared_ptr<_Tp>::shared_ptr(std::_Sp_alloc_shared_tag<_Tp>, _Args&& ...) [with _Alloc = std::allocator<sina::terminal_sink<spdlog::details::console_stderr, spdlog::details::console_mutex> >; _Args = {}; _Tp = sina::terminal_sink<spdlog::details::console_stderr, spdlog::details::console_mutex>]’
/usr/include/c++/8/bits/shared_ptr.h:705:14: required from ‘std::shared_ptr<_Tp> std::allocate_shared(const _Alloc&, _Args&& ...) [with _Tp = sina::terminal_sink<spdlog::details::console_stderr, spdlog::details::console_mutex>; _Alloc = std::allocator<sina::terminal_sink<spdlog::details::console_stderr, spdlog::details::console_mutex> >; _Args = {}]’
/usr/include/c++/8/bits/shared_ptr.h:721:39: required from ‘std::shared_ptr<_Tp> std::make_shared(_Args&& ...) [with _Tp = sina::terminal_sink<spdlog::details::console_stderr, spdlog::details::console_mutex>; _Args = {}]’
src/log.cpp:231:68: required from here
src/progress.h:401:71: error: ‘bool spdlog::sinks::ansicolor_sink<spdlog::details::console_stderr, spdlog::details::console_mutex>::should_do_colors_’ is private within this context
terminal_sink() : super(), sigwinch_mixin(super::should_do_colors_) {
^
In file included from /usr/include/spdlog/details/registry.h:22,
from /usr/include/spdlog/spdlog.h:13,
from src/log.h:33,
from src/log.cpp:29:
/usr/include/spdlog/sinks/ansicolor_sink.h:149:10: note: declared private here
bool should_do_colors_;
^~~~~~~~~~~~~~~~~
In file included from src/log.cpp:61:
src/progress.h:402:9: error: ‘bool spdlog::sinks::ansicolor_sink<spdlog::details::console_stderr, spdlog::details::console_mutex>::should_do_colors_’ is private within this context
if (super::should_do_colors_) {
^~
In file included from /usr/include/spdlog/details/registry.h:22,
from /usr/include/spdlog/spdlog.h:13,
from src/log.h:33,
from src/log.cpp:29:
/usr/include/spdlog/sinks/ansicolor_sink.h:149:10: note: declared private here
bool should_do_colors_;
^~~~~~~~~~~~~~~~~
In file included from src/log.cpp:61:
src/progress.h: In instantiation of ‘void sina::terminal_sink<TargetStream, ConsoleMutex>::log(const spdlog::details::log_msg&) [with TargetStream = spdlog::details::console_stderr; ConsoleMutex = spdlog::details::console_mutex]’:
src/progress.h:408:10: required from here
src/progress.h:409:13: error: ‘bool spdlog::sinks::ansicolor_sink<spdlog::details::console_stderr, spdlog::details::console_mutex>::should_do_colors_’ is private within this context
if (not super::should_do_colors_) {
^~~~~~~~~
In file included from /usr/include/spdlog/details/registry.h:22,
from /usr/include/spdlog/spdlog.h:13,
from src/log.h:33,
from src/log.cpp:29:
/usr/include/spdlog/sinks/ansicolor_sink.h:149:10: note: declared private here
bool should_do_colors_;
^~~~~~~~~~~~~~~~~
In file included from src/log.cpp:61:
src/progress.h:421:34: error: ‘spdlog::sinks::ansicolor_sink<spdlog::details::console_stderr, spdlog::details::console_mutex>::mutex_t& spdlog::sinks::ansicolor_sink<spdlog::details::console_stderr, spdlog::details::console_mutex>::mutex_’ is private within this context
std::lock_guard<mutex_t> lock(super::mutex_);
^~~~
In file included from /usr/include/spdlog/details/registry.h:22,
from /usr/include/spdlog/spdlog.h:13,
from src/log.h:33,
from src/log.cpp:29:
/usr/include/spdlog/sinks/ansicolor_sink.h:147:14: note: declared private here
mutex_t &mutex_;
^~~~~~
...
when using the Debian packaged spdlog (version 1.3.1). In the packaging
we have removed the spdlog code copy (as per Debian policy) and try to
link against the Debian packaged version. In several other projects I
realised problems with this approach and it seems spdlog is a moving
target. Do you think you can adapt SINA to latest spdlog or should we
rather stick to the code copy?
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: