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

My Cloud OS 3 Personal & Network Attached Storage My Cloud
21

NOTE: as of now, I have successfully used the above steps to compile many packages for 4k-wheezy, 64k-wheezy and 4k-jessie. I don’t think I’ve tried 64k-jessie, but if compilation succeeds for 4k I see no reason for which it shouldn’t for 64k.

Many of those packages have also been installed and run successful on 4k (in fact, I’m currently using firmware 3.x in my My Cloud).

ISSUES SO FAR:

 

  • iotop builds and runs successful, but exits immediately because the kernel in the My Cloud has been compiled without the flags needed by iotop; a kernel ricompilation would be needed: since we have the source by WD, in principle it should be possible to do…
  • transmission-daemon can be successfully compiled from wheezy suite (version 2.52), but not from jessie (version 2.82): configuration fails and, in the output, I see three segmentation faults of qemu which are likely to be the cause; I’m trying to build qemu 2.1.0-rc3 from source (Debian provides 2.0 at most) to see if this can be fixed… otherwise an alternative approach must be taken to get a newer Transmission: try to build it in the My Cloud itself (would require to build and install on the device all the development tools) or cross-compile from original source as Nazar did
1 Like
22

Ok I followed your steps trying to build transmission 64K wheezy with updated g++ package 4.7 on Debian 7.0.6 64bit, 1st round the bootstrap was missing dpkg-dev so I chroot build and install it.

The 2nd round the make failed at “make[4]: Entering directory `/root/transmission-2.52/third-party/dht’” with lots of these errors: dht.c:2893:49: error: invalid conversion from ‘void*’ to ‘const unsigned char*’ [-fpermissive].

Reverted back to gcc 4.6, same error.

23

Updates, my bad, I already messed up the binutils:

So the vital point is the qemu like you mentioned.

To summarize your guide, these are the required parts to successfully build the packages on host Debian 7.6.0 64bit:

  1. Update the host once:

    sudo su
    echo “deb Index of /debian wheezy-backports main contrib non-free” >>/etc/apt/sources.list
    apt-get update
    apt-get -t wheezy-backports install qemu-user-staticapt-get install binfmt-support

 2. Get the WD GPL source and extract to working dir if haven’t done so:

wget http://download.wdc.com/gpl/gpl-source-sequoia-04.00.00-607.zip
unzip gpl-source-sequoia-04.00.00-607.zip packages/build_tools/debian/*

 3. Fix WD bootstrap once! cd to the package dir, replace qemu that was provided by WD:

cd packages/build_tools/debian/
cp -f /usr/bin/qemu-arm-static qemu/`dpkg --print-architecture`/

 4. Run the build command (watch out for timeout/gateway errors which will result in failure at the end, retry if some dependencies failed to download):

./build-armhf-package.sh --pagesize=64k transmission wheezy

Results:

OUTPUT debs can be found here:       
build/root/transmission-cli_2.52-3+nmu2_armhf.deb
build/root/transmission-dbg_2.52-3+nmu2_armhf.deb
build/root/transmission-daemon_2.52-3+nmu2_armhf.deb
build/root/transmission-gtk_2.52-3+nmu2_armhf.deb
build/root/transmission_2.52-3+nmu2_all.deb
build/root/transmission-qt_2.52-3+nmu2_armhf.deb
build/root/transmission-common_2.52-3+nmu2_all.deb

1 Like
24

Hi Nazar,

I don’t understand, I just repeated the steps one by one to compile the package named “transmission-daemon” for 64-wheezy using G++ 4.7 and I had no issue at all…

Also, it’s strange that you had to install dpkg-dev manually: when you launch the build script, it invokes apt-get to install all the packages required for building. It’s all automatic. Are you sure your etc/apt/sources.list in the chrooted subsystem is ok?

Ok, I see now you’ve fixed your problem. However, are you able to compile libcurl3-gnutls? I can’t

Also, compiling transmission-daemon fails in 4k-jessie, again for a configuration error :frowning: It’s the opposite situation of libcurl3-gnutls.

I’m starting to think that transmission will need the use of packages coming from mixed sources… I’ll keep on experiment.

25

You’re right about the dpkg-dev, I scrolled way up and noticed it failed to get the package, gateway timeout :frowning:

Anyway I’ve updated the summary and removed dpkg-dev. Only qemu needs to be replaced.

I cleared the build dir to simulate a new instance, it’s working now.

I haven’t tried 4k nor jessie nor other packages yet, it’s 5am here haha. But it has been a great breakthrough so far! Great work!

26

I’ve managed to fix the build problem I had with libcurl3-gnutls from wheezy (it was my fault, I messed with the update-alternatives of gcc). So, now I have all the needed packages for Transmission 2.52 built from wheezy: I installed it and run successful!

Still I can’t build Transmission 2.82 from jessie. I think that Nazar’s solution is still valid if someone needs a recent version.

27

Today I tried java and mysql, can’t seems to build the latest jdk/jre 7 only older builds, segmentation fault :frowning:

-rw-r–r-- 1 root root 138772 Jul 27 23:00 build/root/java-common_0.47_all.deb

-rw-r–r-- 1 root root   629082 Jul 27 08:57 build/root/libmysqlclient18_5.5.38-0+wheezy1_armhf.deb
-rw-r–r-- 1 root root   898130 Jul 27 08:58 build/root/libmysqlclient-dev_5.5.38-0+wheezy1_armhf.deb
-rw-r–r-- 1 root root  2974872 Jul 27 08:58 build/root/libmysqld-dev_5.5.38-0+wheezy1_armhf.deb
-rw-r–r-- 1 root root  2973778 Jul 27 08:57 build/root/libmysqld-pic_5.5.38-0+wheezy1_armhf.deb
-rw-r–r-- 1 root root    76726 Jul 27 08:54 build/root/mysql-client_5.5.38-0+wheezy1_all.deb
-rw-r–r-- 1 root root  1456064 Jul 27 08:58 build/root/mysql-client-5.5_5.5.38-0+wheezy1_armhf.deb
-rw-r–r-- 1 root root    78566 Jul 27 08:54 build/root/mysql-common_5.5.38-0+wheezy1_all.deb
-rw-r–r-- 1 root root    76850 Jul 27 08:54 build/root/mysql-server_5.5.38-0+wheezy1_all.deb
-rw-r–r-- 1 root root  1740732 Jul 27 08:59 build/root/mysql-server-5.5_5.5.38-0+wheezy1_armhf.deb
-rw-r–r-- 1 root root  3495408 Jul 27 08:59 build/root/mysql-server-core-5.5_5.5.38-0+wheezy1_armhf.deb
-rw-r–r-- 1 root root 23062170 Jul 27 09:01 build/root/mysql-source-5.5_5.5.38-0+wheezy1_armhf.deb
-rw-r–r-- 1 root root  4290934 Jul 27 09:01 build/root/mysql-testsuite-5.5_5.5.38-0+wheezy1_armhf.deb.deb

28

Nazar78 wrote:

Today I tried java and mysql, can’t seems to build the latest jdk/jre 7 only older builds, segmentation fault :frowning:

What does segfault? QEMU?

I tried to compile QEMU 2.1.0_rc3 from official sources. Compilaion succeded, but the final qemu-arm executable (which is not qemu-arm-static…) does not work… I mean, if I try to replace qemu-arm-static in the chrooted system with the file I get from compilation, chroot fails. The Debian package must be doing something to obtain the qemu-user-static package, but that goes beyond my knowledge. I even tried to download the Debian 2.0.0 source package, replace the sources there with the one coming from the official 2.1.0-rc3 tar.bz2 file and run the Debian compilation, but it fails :frowning:

We might try to ask for assistance to QEMU developers…

1 Like
29

Thanks! It compiled flawlessly for me!

30

Hi, everyone.

Command

./build-armhf-package.sh --pagesize=64k transmission wheezy

give me

mainwin.cc:276:1: internal compiler error: Segmentation fault

Who can help me.

Thanks!

31

pkomissarov wrote:

Hi, everyone.

Command

./build-armhf-package.sh --pagesize=64k transmission wheezy

give me

mainwin.cc:276:1: internal compiler error: Segmentation fault

Who can help me.

Thanks!

Hi pkomissarov, read the previous posts here and my guide, I think I’ve explained it well the cause and the fix.

32

Thanks  mauromol,

I built htop for gpl-source-sequoia-03.04.01-230a.zip, your instructions worked a treat (4k jessie).

I’m still on the 3.4 firmware as version 4.0 is so diseased at the moment its not worth the effort.

As a bonus, htop looks cool.

33
  • iotop builds and runs successful, but exits immediately because the kernel in the My Cloud has been compiled without the flags needed by iotop; a kernel ricompilation would be needed: since we have the source by WD, in principle it should be possible to do…

In theory, yes, and I have been able to compile/build the 3.4 kernel which turned out to be not so bad. Had to install 32bit libs for the build tools, and dev ncursors to get the make menuconfig to go. However, building iptables into the kernel or .ko modules still escapes me … what ever I do, doesnt seem to make much difference in the build… then again I’ve never built a kernel before so its probably me :slight_smile:

But without a dev/test environment its a guaranteed bricking activity so testing the kernel becomes a point of contention unless you’re willing to sacrifice a my cloud and have a quick drive rebuild procedure when things have gone pear shaped.

1 Like
34

Nazar78 wrote:

 

Results:

OUTPUT debs can be found here:       
build/root/transmission-cli_2.52-3+nmu2_armhf.deb
build/root/transmission-dbg_2.52-3+nmu2_armhf.deb
build/root/transmission-daemon_2.52-3+nmu2_armhf.deb
build/root/transmission-gtk_2.52-3+nmu2_armhf.deb
build/root/transmission_2.52-3+nmu2_all.deb
build/root/transmission-qt_2.52-3+nmu2_armhf.deb
build/root/transmission-common_2.52-3+nmu2_all.deb

Hi

This is transmission version2.52. What do I need to change in the compilation config in order to compile version2.82, like the one in the old 3.0 firmware? My torrent sources seem to have problem downloading using verion 2.52.

Thanks

35

First of all I really doubt that your downloading problem is due to the Transmission version.

Anyway, to compile Transmission 2.82 you have to follow my guide and build the “transmission-daemon” package either in the 4k-jessie scenario (if you have 3.x firmware) or in the 64k-jessie one (if you have 4.x firmware).

The problem, however, is that the build environment crashes when compiling Transmission from sources from jessie suite, because of a problem with the QEMU emulator, as I mentioned  earlier. At least this is what happens to me.

I still have to investigate further, however as of now the only way to build a Transmission version newer than 2.52 is to compile from source as Nazar described in another post on this forum.

36

I’ve learned that we still need to mix methods to sometimes successfully produce the result, running the build script doesn’t always work. At times we may need to chroot to the build dir to make changes to the bootstrap, also cross-compile if something breaks.

Took me quite sometime to finally have mysql server running without breaking WD’s Dashboard/WebDav:

1. Upgraded to Apache2 2.4.10 to fix some of PHP5’s mod load issues.

2. Upgraded to PHP5 5.6.0 just to get php5-mysql and have it working.

  1. Installed MySQL Server/Client 5.5.38, this was perfect once Apache2 and PHP5 configured correctly.

Think I’ve lost track of this build due to too many changes to the bootstrap. But if anyone needs the debs, let me know…

773×546 44.9 KB

37

Hi mauromol,

    I have followed your protocol for 64k-wheezy and it has worked great for a number of packages, but now I think I have run in to a problem case. I wonder if you might evaluate?

root@debian:~/wdmc-build/64k-wheezy# ./build.sh libstdc++6

 The build process progresses well until

dpkg-checkbuilddeps: Build conflicts: binutils-gold
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
Build command 'cd gcc-4.7-4.7.2 && dpkg-buildpackage -b -uc' failed.
E: Child process failed

 I suspect the problem stems from existence of the binutils that is already in place in the build directory, but you would be a better judge of that.

Thanks for any insights.

38

 

1. Upgraded to Apache2 2.4.10 to fix some of PHP5’s mod load issues.

2. Upgraded to PHP5 5.6.0 just to get php5-mysql and have it working.

  1. Installed MySQL Server/Client 5.5.38, this was perfect once Apache2 and PHP5 configured correctly.

 

Think I’ve lost track of this build due to too many changes to the bootstrap. But if anyone needs the debs, let me know…

 

Do you remember at least some of the changes you needed to do to the bootstrap?

By the way, I still think it’s a good idea to provide a list of links of pre-built packages, so that people do not have to rebuild all of them by themselves… what do you think? We may create a new topic for this. However, where do we put the built packages? I think a common web space would be a good idea… or the use of torrents instead. if we use our private Dropboxes the risk that links expire or are blocked is very high.

39

cbarrett wrote:

Hi mauromol,

    I have followed your protocol for 64k-wheezy and it has worked great for a number of packages, but now I think I have run in to a problem case. I wonder if you might evaluate?

 

root@debian:~/wdmc-build/64k-wheezy# ./build.sh libstdc++6

I’m not a guru, but I know libstdc++ is a foundamental core library… I fear that even if you succeed at compiling it, installing on the My Cloud may break something. Why do you need to rebuild it? Are you sure you need?

I agree with you that the conflict might be in the binutils package, but if I remember well a patched binutils is needed for 64k-wheezy to build packages… Maybe rebuilding binutils itself before libstdc++ would make the trick, but, once again, I don’t know if this is going to work once you install packages on the My Cloud…

40

mauromol wrote:

 

1. Upgraded to Apache2 2.4.10 to fix some of PHP5’s mod load issues.

2. Upgraded to PHP5 5.6.0 just to get php5-mysql and have it working.

  1. Installed MySQL Server/Client 5.5.38, this was perfect once Apache2 and PHP5 configured correctly.

 

Think I’ve lost track of this build due to too many changes to the bootstrap. But if anyone needs the debs, let me know…

 

Do you remember at least some of the changes you needed to do to the bootstrap?

 

By the way, I still think it’s a good idea to provide a list of links of pre-built packages, so that people do not have to rebuild all of them by themselves… what do you think? We may create a new topic for this. However, where do we put the built packages? I think a common web space would be a good idea… or the use of torrents instead. if we use our private Dropboxes the risk that links expire or are blocked is very high.

The changes were mostly missing or conflicting dependencies. I can’t really recall because I was doing few builds at one go (left trying to get jre working). Think this should be easily replicated by building on a fresh bootstrap.

Despite package security concerns, a common web space is good, for the ease of wget right into the build box path. But we need someone committed to administer this. Like updating the main thread with the links to the guides and packages. Another is I’m not sure if Mods are happy with this, could end up thread getting closed and all the effort down with it…