On 2016-12-13 20:19 +0000, Phil Endecott wrote:
> Wookey wrote:
> > Yes. ntopng-data is missing a
> > Multi-Arch=foreign
> > line in it's control file. Add one and rebuild it and you should be in business.
>
> Thanks for your optimism Wookey! Unfortunately there's more.
Yeah I did think about a) actually testing this theory and b) pointing
out that it might just immediately get you to the next problem :-) but
I was busy and a quick look at deps sugested that you had a fighting
chance :-)
> $ apt-get source ntopng-data
> $ nano debian/control (add Multi-Arch: foreign for ntopng-data)
> # apt-get build-dep --host-architecture armhf ntopng-data
> ...
> The following packages have unmet dependencies:
> builddeps:ntopng:armhf : Depends: coffeescript:armhf but it is not installable
> Depends: libpcap-dev:armhf but it is not installable
>
> Both coffeescript and libpcap-dev are architecture=all packages which
> should maybe/possibly/probably have Multi-Arch=foreign.
Right, and if one has access to an armhf machine, such a debian
porterbox, one can just build the modified ntopng package nativaly and
avoid the typical 'computing story of woe' below.
> But I suspect these are actually only needed to build the ntopng package
> (i.e. the binaries), not ntopng-data. I install some other build-deps
> and try:
>
> $ dpkg-buildpackage --build=all --jobs=3 --no-check-builddeps
>
> Confusingly, "build=all" here doesn't mean build everything! It is
> supposed to mean build the architecture=all packages. This doesn't
> work as I hope though; it starts by doing some ./configures which are
> clearly checking for architecture-specific things - including the missing
> arm64 luajit. It ends up with make recursively disappearing up its
> own backside.
Right, because that's building for arm64
> So it looks like I will have to patch coffeescript and libpcap-dev, and
> then build ntopng-data for armhf.
>
> $ apt-get source coffeescript
> $ nano debian/control (add Multi-Arch: foreign in 3 places)
> # apt-get build-dep coffeescript
> $ dpkg-buildpackage --jobs=3
> # dpkg -i coffeescript_1.10.0~dfsg-1_all.deb
>
> OK....
>
> $ dpkg -L libpcap-dev
> /.
> /usr
> /usr/share
> /usr/share/doc
> /usr/share/doc/libpcap-dev
> /usr/share/doc/libpcap-dev/changelog.Debian.gz
> /usr/share/doc/libpcap-dev/changelog.gz
> /usr/share/doc/libpcap-dev/copyright
>
> That should clearly be Multi-Arch=foreign - right? - so:
No because libpcap-dev depends on libpcap0.8-dev which is
arch-specific so when something depends on libpcap-dev it wants to get
the right architecture version of libpcap0.8-dev, so they should both
be MA:same and arch:any, as explained in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820829
> ........
> dpkg: error processing archive /tmp/apt-dpkg-install-B3DAh9/45-libcurl4-gnutls-dev_7.50.1-1_armhf.deb (--unpack):
> trying to overwrite shared '/usr/bin/curl-config', which is different from other instances of package libcurl4-gnutls-dev:armhf
>
> Comparing libcurl4-gnutls-dev_7.50.1-1_armhf.deb and libcurl4-gnutls-dev_7.50.1-1_arm64.deb,
> they both have /usr/bin/curl-config and those files do differ; they include
> architecture-specific paths:
>
> < if test "X${prefix}/lib/arm-linux-gnueabihf" != "X/usr/lib" -a "X${prefix}/lib/arm-linux-gnueabihf" != "X/usr/lib64"; then
> < CURLLIBDIR="-L${prefix}/lib/arm-linux-gnueabihf "
> ---
> > if test "X${prefix}/lib/aarch64-linux-gnu" != "X/usr/lib" -a "X${prefix}/lib/aarch64-linux-gnu" != "X/usr/lib64"; then
> > CURLLIBDIR="-L${prefix}/lib/aarch64-linux-gnu "
>
> How is multiarch supposed to cope with that?
Yes - those foo-config programs are a major pain for multiarch and cross-building.
You have hit https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731998
> OK! Try to build ntopng-data again, something like:
>
> $ dpkg-buildpackage --host-arch=armhf --target-arch=armhf --build=all --jobs=3
>
> I'm not at all sure about those architecture options. I'd be happy to
> either build using a "native" armhf compiler, or a "cross" arm64-hosted,
> armhf-target compiler. It seems most promising with just --host-arch-armhf,
> which seems to be cross-compiling; it gets this far:
>
> checking for arm-linux-gnueabihf-gcc... no
>
> Presumably this is because the build-deps assume build-essential, which
> doesn't include the cross-compiler. (Is there a "cross build essential"
> package?)
yes. install crossbuild-essential-armhf (which will get you suitable
binutils, gcc, pkgconfig and cross-config toolchain components)
> # apt-get install gcc-arm-linux-gnueabihf
> $ dpkg-buildpackage --host-arch=armhf --build=all --jobs=3
> ....
> checking for pcap_open_live in -lpcap... no
> Please install libpcap(-dev) (http://tcpdump.org)
>
> Of course I do now have libpcap-dev, which is architecture-all and
> has no content. The actual libpcap seems to be in the versioned
> libpcap0.8[-dev], of which I have only the arm64 version. libpcap-dev
> depends on this versioned package. So perhaps making libpcap-dev
> Mutli-Arch:foreign was wrong? I'll try installing the armhf versions:
It was, see above.
> # apt-get install libpcap0.8-dev:armhf libpcap0.8:armhf
> The following packages will be REMOVED:
> libpcap-dev libpcap0.8-dev
>
> So it has installed the armhf versions but removed the arm64 version
> of libpcap0.8-dev AND my patched libpcap-dev; as expected this isn't good:
>
> $ dpkg-buildpackage --host-arch=armhf --build=all --jobs=3
> ...
> dpkg-checkbuilddeps: error: Unmet build dependencies: libpcap-dev
>
> But I know that libpcap-dev only contains doc files, so it can't really
> depend on it:
heh, you are getting the hang of this :-)
> $ dpkg-buildpackage --host-arch=armhf --build=all --jobs=3 --no-check-builddeps
> ...
> checking libnetfilter_queue/libnetfilter_queue.h usability... no
> checking libnetfilter_queue/libnetfilter_queue.h presence... no
> checking for libnetfilter_queue/libnetfilter_queue.h... no
> checking for nfq_create_queue in -lnetfilter_queue... no
> checking for nfq_set_verdict2... no
> checking for nl_handle_alloc in -lnl... no
> ...
> checking for arm-linux-gnueabihf-mariadb_config... no
> checking for mariadb_config... no
> checking for arm-linux-gnueabihf-mysql_config... no
>
> I wonder if any of that matters?
having an armhf pkgconfig may help with some of this.
> Then:
>
> make[2]: *** No rule to make target '/src/lib/.libs/libndpi.a', needed by 'default'. Stop.
> I've no idea what that means.
>
> So it's half a day later and still no functioning ntopng. Let's try hacking it:
>
> # dpkg-deb --raw-extract ntopng-data_2.2+dfsg1-2_all.deb
> # nano ntopng-data*/DEBIAN/control (Add Multi-Arch: foreign)
> # dpkg-deb --build ntopng-data*
> # dpkg -i ntopng-data_2.2+dfsg1-2_all.deb
> # apt-get install ntopng:armhf
>
> OK!
>
> It's running!
>
> But I don't see anything when I point my browser at port 3000. I check syslog:
>
> Dec 13 20:09:40 panama systemd[1]: Starting ntopng - High-Speed Web-based Traffic Analysis and Flow Collection Tool...
> Dec 13 20:09:40 panama ntopng[11851]: 13/Dec/2016 20:09:40 [Prefs.cpp:796] Logging into /var/log/ntopng/ntopng.log
> Dec 13 20:09:40 panama ntopng[11851]: 13/Dec/2016 20:09:40 [Ntop.cpp:933] Setting local networks to 127.0.0.0/8
> Dec 13 20:09:40 panama ntopng[11851]: 13/Dec/2016 20:09:40 [Redis.cpp:106] Successfully connected to redis 127.0.0.1:6379@0
> Dec 13 20:09:41 panama ntopng[11851]: 13/Dec/2016 20:09:41 [Ntop.cpp:907] Parent process is exiting (this is normal)
> Dec 13 20:09:41 panama systemd[1]: ntopng.service: PID file /var/tmp/ntopng.pid not readable (yet?) after start: No such file or directory
> Dec 13 20:09:41 panama kernel: [2870182.074743] device eth0 entered promiscuous mode
> Dec 13 20:09:41 panama kernel: [2870182.174741] device eth0.1 entered promiscuous mode
> Dec 13 20:09:41 panama kernel: [2870182.274737] device eth0.2 entered promiscuous mode
> Dec 13 20:09:41 panama kernel: [2870182.374727] device lo entered promiscuous mode
> Dec 13 20:09:41 panama systemd[1]: Started ntopng - High-Speed Web-based Traffic Analysis and Flow Collection Tool.
> Dec 13 20:09:42 panama kernel: [2870182.971468] Unhandled fault: alignment fault (0x92000021) at 0x00000000add616f2
> Dec 13 20:09:42 panama kernel: [2870183.013226] Unhandled fault: alignment fault (0x92000021) at 0x00000000ac530776
> Dec 13 20:09:42 panama kernel: [2870183.018383] Unhandled fault: alignment fault (0x92000021) at 0x00000000ab91808a
> Dec 13 20:09:42 panama kernel: [2870183.104731] device eth0.1 left promiscuous mode
> Dec 13 20:09:42 panama kernel: [2870183.164730] device eth0.2 left promiscuous mode
> Dec 13 20:09:42 panama kernel: [2870183.164738] device eth0 left promiscuous mode
> Dec 13 20:09:42 panama kernel: [2870183.225120] device lo left promiscuous mode
> Dec 13 20:09:42 panama systemd[1]: ntopng.service: Main process exited, code=killed, status=7/BUS
>
>
> Aarrgghhhhhhhh.
Oooh, alignment faults. That's interesting. Having no idea what ntopng
does (I had assumed that it converted something to PNG format, but I
guess it's actually a next-gen ntop, which is apparently some network
analysis tool) I'm not sure whether this is a bug, or if it's simply
unreasonable to expect a non-native network analysis tool to
work. Worth reporting I think so someone can have a think about
whether it is just asking the kernel for packets in the 'wrong' way,
or something.
> (I'll file a bug about ntopng-data needed Multi-Arch: foreign. What do you think
> about the other packages I've mentioned? Then I'll wait until the arm64 luajit
> issue is fixed, and try again.)
That does seem the best plan under the circumstances.
I guess we should apply a bit more effort to all this long-tail
multi-arch breakage so that more things cross-build and
cross-install. There is ongoing work, but it's nearly all just Helmut.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Attachment:
signature.asc
Description: Digital signature