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/
signature.asc
Description: Digital signature
