[GUIDE] Building packages for the new firmware... someone tried it?

I’m testing but i need some time.

We can build last version with 64k page using http://www.imagemagick.org/script/install-source.php guide, but not debian packages, seems we have some qemu problem.

My suggestion is install non 64k page library, you can download easy “apt-get download libmagickcore-6.q16-2” & install manually “dpkg -i libmagickkcore-6.q16-2” now you can satisfice build package dependency and continue working, when you can build full package you are trying to build replace non 64k page libraries with 64k libs generated manually.

Regards.

That might satisfy dependency problems, but will php5-imagick work after doing that? I need that to work on my WDMC.

As for ‘when I can build full package’, when will that be? I asked for help here to figure out exactly ‘why I cannot’ and ‘how I can’ build full package of imagemagick(source jessie) into 64k memory size. Does that mean there’s nothing I can do here, those error messages I posted earlier cannot be resolved on my side, and I can only hope next version of imagemagick package will be compatible?

make[1]: Leaving directory `/root/php-imagick-3.1.2'
   dh_php5 -O--buildsystem=phppear
   dh_installdocs -O--buildsystem=phppear
   dh_installchangelogs -O--buildsystem=phppear
   dh_perl -O--buildsystem=phppear
   dh_phppear -O--buildsystem=phppear
   dh_link -O--buildsystem=phppear
   dh_compress -O--buildsystem=phppear
   dh_fixperms -O--buildsystem=phppear
   dh_strip -O--buildsystem=phppear
   dh_makeshlibs -O--buildsystem=phppear
   dh_shlibdeps -O--buildsystem=phppear
dpkg-shlibdeps: warning: debian/php5-imagick/usr/lib/php5/20131226/imagick.so contains an unresolvable reference to symbol zend_hash_get_current_data_ex: it's probably a plugin
dpkg-shlibdeps: warning: 77 other similar warnings have been skipped (use -v to see them all)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/php5-imagick/usr/lib/php5/20131226/imagick.so was not linked against libgomp.so.1 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/php5-imagick/usr/lib/php5/20131226/imagick.so was not linked against libpthread.so.0 (it uses none of the library's symbols)
   dh_installdeb -O--buildsystem=phppear
   dh_gencontrol -O--buildsystem=phppear
dpkg-gencontrol: warning: Depends field of package php5-imagick: unknown substitution variable ${php5:Depends}
dpkg-gencontrol: warning: package php5-imagick: unused substitution variable ${phppear:Debian-Depends}
dpkg-gencontrol: warning: package php5-imagick: unused substitution variable ${phppear:summary}
dpkg-gencontrol: warning: package php5-imagick: unused substitution variable ${phppear:description}
dpkg-gencontrol: warning: package php5-imagick: unused substitution variable ${phppear:channel}
   dh_md5sums -O--buildsystem=phppear
   dh_builddeb -O--buildsystem=phppear
dpkg-deb: building package `php5-imagick' in `../php5-imagick_3.1.2-1.1_armhf.deb'.
 dpkg-genchanges >../php-imagick_3.1.2-1.1_armhf.changes
dpkg-genchanges: not including original source code in upload
 dpkg-source --after-build php-imagick-3.1.2
dpkg-buildpackage: binary and diff upload (original source NOT included)

 compiled with some warnigs in wheezy enviroment.

Regards.

I already have php5-imagick compiled, those depedency problem logs I posted earlier were from when I tried to apply that .deb in my WDMC. I think we are drawing kind of parellel lines here, were there some points where I was not clear in what I need and what my problem is?

I needed php5-imagick working on my WDMC, so I compiled it and tried to install it on WDMC, faced those dependency problems, then I tried compiling needed packages, which failed. To successfully build those packages, and in case I face similar problems with other packages I might try to compile in the future, I wish to know what the problem is and how to solve it.

It seems that the short log I posted before doesn’t have any useful information on it, so I might have to watch the whole compiling process to catch any hint of problem - takes about 3 hours - and fix it. I’ll stop asking what specific error I’m facing since I can’t provide sufficient information for anyone to analyze.

As such, what might be of help for me right now is some random tips that helped in compiling packages that could not be compiled at the start. Or ways to make php5-imagick work without meeting dependency problems perfectly.

Which returns me to the last question - if I apt-get install libmagickcore and libmagickwand, will php5-imagick work?

If libmagick* libraries are native code (C, C++, etc.) no, they won’t work if you install them via “apt-get install” or “apt-get download + dpkg -i” on the My Cloud, you have to rebuild them.

If they are written in interpreted languages or they are just made up of atchitecture-neutral artifacts, they will work.

The rule of thumb is: do those package file full names contain “armhf” architecture indication? If so, you have to rebuild them, otherwise if they are marked as “all” you actually don’t need to rebuild them.

Honestly, I didn’t follow your problem in much detail, but from what I have understood, the situation might be this.

WD My Cloud has a Debian Wheezy on it. So, only package versions taken from wheezy repositories are guaranteed to work. So, if you can build and install the libraries you need once taken from wheezy, you’re on the good path.

Taking packages from Jessie and install them on a Wheezy system is not guaranteed to work: even if you are able to build them, once you try to install you may have unsatisfied dependencies, because your packages might depend on newer versions of other packages that are not available on your Wheezy system. The solution is to build also those dependency packages, taken from Jessie, and hope that they will install correctly, because the same problem might occur in a recursive way. In the worst case, your package might require to upgrade the whole system (or a relevant amount of critical/base packages), with the following consequences:

  • the system might become unstable: let’s remember that Wheezy is the current stable Debian version, Jessie is still testing
  • the system might not work at all, because even if you had the skills to rebuild and install all the required dependencies, it’s hard to say whether the final result will actually work or not, since testing at Debian is performed on either Whezzy or Jessie and not on a hybrid set of mixed package versions

So, my suggestion is: build and install packages from wheezy. If the wheezy version of your package from wheezy is too old, you can either make do with it or, if you’ve nothing to lose, you may experimenti with rebuilding the package all of its dependencies from Jessie, but be prepared to have to revive your WD My Cloud if something goes really wrong.

To add more to this picture, consider that there are some packages that won’t build at all (from either wheezy or jessie suites) because there are problems with QEMU, which is the emulation layer that is used to build these ARM packages on a x86/x64 system (your PC, or virtual machine on your PC).  For these problems, which are usually revelead by “segmentation fault” errors at build time,  there’s currently no solution. An alternative would be to prepare a build environment directly on the WD My Cloud, but:

  • all the required build tools (compilers, etc.) must be built and installed prior for this to work, because of the 64k modification
  • it might take very loooong to build some packages on an ARM device (given that it often takes hours even on a real PC!)
  • the RAM on the device might be small to build some huge packages, unless you set up a lot of (slooooow) swap space

In short, it is a great hassle…

Hope this helps a bit to clarify the situation.

@Sarka,

Even though you successfully build php5-imagick, you’ll also have to build its dependencies, libmagickcore and libmagickwand. On top of that, there’s also dependencies for libmagickcore and libmagickwand.

Below are for wheezy builds:

root@Debian:/home/nazar# apt-cache depends php5-imagick
php5-imagick
  Depends: libc6
  Depends: libmagickcore5
  Depends: libmagickwand5
  Depends: <phpapi-20100525>
    libapache2-mod-php5
    libapache2-mod-php5filter
    libphp5-embed
    php5-cgi
    php5-cli
    php5-fpm
  Depends: php5-common
  Depends: ucf
  Recommends: ghostscript
  Recommends: ttf-dejavu-core

Currently I’m stuck at trying to run apache2 as fpm/fastcgi. mod_php5 seems to be overkilled for this small cloud. Got both build successfully but stuck at fpm dependencies. I end up running as cgi, slower but stable on load.

I try & see your compile problem, there are to mamy files in imagemagick

argument list too long

you can fix

nano /usr/bin/dh_md5sums

add -n 16 to xargs run only 16 md5sum in each instruction.

complex_doit("(cd $tmp >/dev/null ; $find | LC_ALL=C sort -z | xargs -r0 -n 16 md5sum > DEBIAN/md5sums) >/dev/null");

 i also add -n 16 in dh_fixperms

regards.

@Sarka,

I decided to try yesterday and successfully compiled Imagick. libgomp1 was problematic, it tries to build gcc4.9 which took the whole night despite compiling on ramdisk but ends up miserably. So I decide to skip and just install others debs. Then I tried to run the CLI “php --version” command many times, which at each, it displayed the modules which are missing and I added to the build list.

Some tips I discovered:

  1. A clean bootstrap helps if you run into deps issue. It might need to reinstall other deps allover again every time you start but this will ensure no deps issue.

  2. If the compile fails, search in the /root/source if the libraries “*.so” you need has been generated before segmentation error occurs. You could just probably copy and link them in the wdmycloud lib path.

  3. If the compile hangs, fire another terminal and do a “pstree -pa” to findout where it got stuck. Sometimes killing it with a sighup will let the process continues. And if sighup caused the build to fail, take note which process you did the sighup. Build again then immediately symlink the process to /bin/echo so it will return code 0 instead of failing. I had a few encounters with /usr/bin/doxygen. This did the trick.

  4. If you have rams to spare for ramdisk, mount the whole bootstrap to the tmpfs to speed things up. Depending on what you’re trying to build and housekeeping (cleanup the chrooted /root before starting), 2GB tmpfs is quite ok to hold the original bootstrap, new deps and a new source builds.

  5. Add parallel and job flags to the environment, then you can see all CPU cores being utilized e.g. from top/htop.

Debs:

find . -type f ! -path “excluded
./fftw3_3.3.4-1/libfftw3-double3_3.3.4-1_armhf.deb
./libxext6_1.3.1-2/libxext6_1.3.1-2+deb7u1_armhf.deb
./libonig2_5.9.5-2/libonig2_5.9.5-2_armhf.deb
./liblqr-1-0_0.4.2-2/liblqr-1-0_0.4.2-2_armhf.deb
./libmagickwand-6.q16-2_6.8.9.6-4_armhf.deb
./imagemagick-common_6.8.9.6-4_all.deb
./libmagickcore-6.q16-2_6.8.9.6-4_armhf.deb

<?php phpinfo();>:

Hello,

Great tuturial!

I must say I’m impressed how easy is to build packages with it. I was able to build some packages and so far it works great!

Now my next challenge is to use my WDMycloud to send data from my energy consumption monitor to the internet (xively site). My energy monitor is an “ENVIR Current Cost” and has an USB cable that allows to “talk serial” to an USB host, so why not using WDMycloud to do it?

I mean, WDMC a great piece of HW totally capable of doing it (the required processing load is minimum) and in my case, its placed right next to the ENVIR monitor. This way I avoid having a dedicated machine (raspberry pi, PC, or other) to do it.

From an high level point of view, the actions to make it happen would be:

  1. Implement the driver for the USB serial device, in my case PL2303 chipset. (need to compile it)

  2. Implement the software to read the XML data.  There are quite a few options around. Implementations in perl, python, etc… (Need to compile perl or python “serial talk” add-ons)

  3. (optional depending on action 2) Implement a script that sends information to xively. (Need to compile curl - done!)

I’m now facing some difficulties with step 1 because I cannot find the correct wheezy 64k driver for the PL2303 chipset. Mybe because it should be a kernel module?

I was able to build and install usbutils and I can see from lsusb command that the PL2303 doesn’t appear, so I guess the driver is not enabled by default and therefore I must have to compile it.

Any idea how to make this work?

Thanks,

Jabss

Hmm…imagemagick was compiled successfully at wheezy based, so I deemed that half done and focused on gcc-4.9 for libgomp1 since then.

For 1), I tried that but didn’t seem to work.

For 2) and 3), .so file for libgomp isn’t there. Compile seems to hang at certain point(It always stuck at same point). After seemingly done with configurations, it starts to build .deb files, and after making “gcj-4.9-source_4.9.1-17_all.deb”(after gcc-4.9-source_4.9.1-17_all.deb, gcj-4.9-jre-lib_4.9.1-17_all.deb, gcj-native-helper_1.7-52_armhf.deb), compilation just stops. I don’t know how to explain this, VMWare is working just fine but compilation stops right there and stayed that way for about 20 hours, after which compilation stops itself.

I’m not that good at handling linux so I don’t know how to “fire another terminal” on debian-7.6.0-amd64-netinst, same one linked on mauromol’s guide at page 2. Could you please explain a bit more on that?

Sarka wrote:

Hmm…imagemagick was compiled successfully at wheezy based, so I deemed that half done and focused on gcc-4.9 for libgomp1 since then.

For 1), I tried that but didn’t seem to work.

For 2) and 3), .so file for libgomp isn’t there. Compile seems to hang at certain point(It always stuck at same point). After seemingly done with configurations, it starts to build .deb files, and after making “gcj-4.9-source_4.9.1-17_all.deb”(after gcc-4.9-source_4.9.1-17_all.deb, gcj-4.9-jre-lib_4.9.1-17_all.deb, gcj-native-helper_1.7-52_armhf.deb), compilation just stops. I don’t know how to explain this, VMWare is working just fine but compilation stops right there and stayed that way for about 20 hours, after which compilation stops itself.

 

I’m not that good at handling linux so I don’t know how to “fire another terminal” on debian-7.6.0-amd64-netinst, same one linked on mauromol’s guide at page 2. Could you please explain a bit more on that?

“fire another terminal” I mean to open another gnome terminal (shift+ctrl+N) or a new terminal tab (shift+ctrl+T), then run “pstree -pa” to look for the hanging process. Take note of the last child pid then kill it with a sighup, “kill -1 PID”.

Can you try proceed installing the rest of the debs without libgomp (–force-all if required), then try running a phpinfo script see if you can see the module? Or from the wdmycloud shell try “php --version” see if it complains about any missing *.so (those are the ones you need to build). You could probably also test your site.

Edited : If you’re already reached the *.deb creation part, you should be able to find the *.so:

find ./root/gcc-4.9* -type f -name "*libgomp*so*";

./root/gcc-4.9-4.9.1/build/prev-arm-linux-gnueabihf/libgomp/.libs/libgomp.so.1.0.0

Copy over to your cloud /usr/lib/arm-linux-gnueabihf/libgomp.so.1.0.0.

And create a symlink libgomp.so.1 in the same path which points to it:

cd /usr/lib/arm-linux-gnueabihf/;

ln -s libgomp.so.1.0.0 libgomp.so.1;

Sarka wrote:> I’m not that good at handling linux so I don’t know how to “fire another terminal” on debian-7.6.0-amd64-netinst, same one linked on mauromol’s guide at page 2. Could you please explain a bit more on that?

If you’ve used that image, you won’t have any GUI, so to fire up a new terminal you have to hit Ctrl+Alt+F1, F2, F3, F4, etc…

If you’re using a virtual machine, you might need to send such a key combination to the virtual machine in order to avoid it to be taken by the host system.

    Thanks everyone for the info in this thread.  I built and installed several 64k packages on MyCloud.  Most packages are working out of the box.  For the record, here is a guide for locate and aria which required some minor tweaks.

    locate did not work out of the box as it ran out of disk space trying to put tmp files and the database on the rootfs.  To work around I created

mkdir /shares/system/locate  
mkdir /shares/system/tmp

I modified the text file /usr/bin/updatedb to create tmp files in /shares/system/tmp.  These lines already exist.  The only need is to change the directories.

177 # The database file to build.
178 : ${LOCATE_DB=/shares/system/locate/locatedb}
179 
180 # Directory to hold intermediate files.
181 if test -d /var/tmp; then
182 : ${TMPDIR=/shares/system/tmp}
183 elif test -d /shares/system/tmp; then
184 : ${TMPDIR=/shares/system/tmp}

First, run updatedb.  Then link the file in rootfs to the new one created by updatedb. 

rm /var/cache/locate/locatedb
ln -s /shares/system/locate/locatedb /var/cache/locate/locatedb

For Aria it was necessary to install libc-ares2_1.9.1-3_armhf.deb first, then aria2_1.15.1-1_armhf.deb.  The Aria web ui files from https://github.com/ziahamza/webui-aria2 can go here:

unzip master.zip /var/www/htdocs

 Aria also needed a config file called /root/.aria2/aria2.conf with contents such as this:

continue
dir=/shares/yourdirectory/aria
file-allocation=none
log-level=warn
max-connection-per-server=4
min-split-size=5M

Run aria in daemon mode and control it from a browser on the network.

aria2c -D --enable-rpc --rpc-listen-all

Hello, I am trying to build de amule-daemon package to use it in my cloud.

First I built the package “wakeonlan”, very simple, to probe if I can build packages and works fine.

I follow the procedure and I obtain the next list of deb files:

amule-gnome-support_2.3.1-9_all.deb
amule-common_2.3.1-9_all.deb
plasma-widget-amule_2.3.1-9_armhf.deb
amule-daemon_2.3.1-9_armhf.deb
amule-utils-gui_2.3.1-9_armhf.deb
amule-utils_2.3.1-9_armhf.deb
amule_2.3.1-9_armhf.deb

When I try to install in my cloud with dpkg, I obtained, as you said, the next error several times.

dpkg: dependency problems prevent configuration of amule-daemon:
amule-daemon depends on libcrypto++9; however:
Package libcrypto++9 is not installed.
amule-daemon depends on libupnp6 (>= 1:1.6.13); however:
Package libupnp6 is not installed.
amule-daemon depends on libwxbase2.8-0 (>= 2.8.12.1); however:
Package libwxbase2.8-0 is not installed.

The complete list of not installed packages is: 

Package gconf2 is not installed.
Package libcrypto++9 is not installed.
Package libgeoip1 is not installed.
Package libkdecore5 is not installed.
Package libplasma3 is not installed.
Package libqt4-dbus is not installed.
Package libqtcore4 is not installed.
Package libqtgui4 is not installed.
Package libupnp6 is not installed.
Package libwxbase2.8-0 is not installed.
Package libwxgtk2.8-0 is not installed.

Then I tried again to obtaind the deb files for this packages.

Several of then was ok but, in other cases, i got a error:

make[1]: Entering directory /root/qt4-x11-4.8.2+dfsg' [! -f Makefile] || /usr/bin/make confclean distclean make[2]: Entering directory /root/qt4-x11-4.8.2+dfsg’
/root/qt4-x11-4.8.2+dfsg/bin/qmake-qt4 -spec mkspecs/linux-g++ -o Makefile projects.pro
make[2]: /root/qt4-x11-4.8.2+dfsg/bin/qmake-qt4: Command not found
make[2]: *** [Makefile] Error 127
make[2]: Leaving directory /root/qt4-x11-4.8.2+dfsg' make[1]: \*\*\* [override\_dh\_auto\_clean] Error 2 make[1]: Leaving directory /root/qt4-x11-4.8.2+dfsg’
make: *** [clean] Error 2
dpkg-buildpackage: error: debian/rules clean gave error exit status 2
Build command ‘cd qt4-x11-4.8.2+dfsg && dpkg-buildpackage -b -uc’ failed.
E: Child process failed

Can you help my to resolve the error.? what information you need?

Thanks and sorry by my english

It’s useless to build GUI packages like amule-gnome-support or amule-utils-gui. Amule won’t run in a GUI inside the MyCloud unit, but only as a headless daemon.

The only package you need to build is amule-daemon and its dependencies (amule-common, if I remember well, plus third party dependencies). Then amule will be run as a daemon and you’ll be able to control it through its web interface…

mauromol, thanks for your comment.

I generated and used the packages that are related with amule-daemon

amule-common_2.3.1-9_all.deb
amule-daemon_2.3.1-9_armhf.deb
amule-utils_2.3.1-9_armhf.deb
libcrypto++9_5.6.1-6_armhf.deb
libupnp6_1.6.17-1.2_armhf.deb
libwxbase2.8-0_2.8.12.1-12_armhf.deb

 and all works fine.

Just curious. Why this change from 4k to 64k? Why did they made this change?

Maybe to optimize the system for the (limited) hardware of the My Cloud, but there may be also a commercial reason (more expensive units are offered with ready-to-use packages to download and install).

Anyone wiling to build “flexget” for FW 4.x ?

Thanks

Hi, I am obtaining the .deb of several applications, amule, mc, … with the last firmware, 04.01.02-417, to confirm it is posible, before its aplication.

I use a new virtual machine and I have obtained good results with 64k-wheezy, but when I work with the 64k-jessie I obtain this error

debian_output_dir=debian_output_dir
umount2: Invalid argument
umount: /root/wdmc-build/64k-jessie/build/proc: not mounted
umount2: Invalid argument
umount: /root/wdmc-build/64k-jessie/build/dev/pts: not mounted
umount2: Invalid argument
umount: /root/wdmc-build/64k-jessie/build/dev: not mounted
chroot: failed to run command `/bin/bash': No such file or directory

in the instruction

./setup.sh bootstrap/jessie-bootstrap_5.14.14_armhf.tar.gz build

Please, can you help me?