machinekit / machinekit

http://machinekit.io
Other
409 stars 181 forks source link

Building-from-source on Wheezy: I'm suddenly in dependency hell #614

Closed RunningLight closed 9 years ago

RunningLight commented 9 years ago

Ok, so I've moved to the issues log from the email thread of the same title where I reported a real kerfuffle occurs when I invoke sudo scripts/apt-installbuilddeps while following along http://machinekit.io/docs/building-from-source

[all systems update'd and upgrade'd and machinekit sources pulled today]

@zultron, you suggested

Ok, I wasn't looking at installbuilddeps.out carefully enough.

At least one problem is it doesn't like the libzmq3 | libzmq4, and is trying to install both. Can you see what happens when you remove the | libzmq4 (...) from debian/rules?

Also, if you attach another log, can you run the command as bash -x scripts/apt-installbuilddeps? That'll be easier to follow along with.

I'm seeing different things on a Wheezy-amd64 VM and on a Wheezy-arm on my CuBox-i4Pro.

Wheezy-amd64

As reported in my email, everything seemed to be going swimmingly as I step through the Building-from-source instructions up to the moment I invoke sudo debian/apt-installbuilddeps at which point all hell breaks loose. Following your suggestion, I edited debian/control (surely you didn't mean rules) to remove the alternate | libzmq4 (...) choice. This time sudo/apt-installbuilddeps fared better. It didn't throw all those Conflicts with statements I spoke of before, but it still failed.

I have pasted the output of this command to https://gist.github.com/RunningLight/abda3ca6993fa199b25a

Look down at line 217.

Remarks:

On this system, the clashes occur when I try to

sudo apt-get install libczmq-dev python-zmq libjansson-dev libwebsockets-dev libxenomai-dev lsb-release

Some interesting stuff happening here. It seems that apt-get is drawing packages like python-zmq (14.4.0-1 Debian:8.0/stable armhf]), apparently because the wheezy image I got has enabled wheezy-updates in /etc/apt/sources.list. Again, I'm running into a problem regarding libzmq. I'm still examining my wheezy-arm situation; will report more later.

Aside: I can understand that in your Buildbot environment you don't see these issues, but I'm flabbergasted that I am the only person reporting them since others are posting about their builds.

RunningLight commented 9 years ago

A followup

Wheezy-arm (on a Scaleway C1 host---4 Cores, 2GB RAM, 50GB SSD---pretty cool!).

Using the Debian 7.8 image provided by Scaleway, I obtained the same results (e.g., before and after editing debian/control) as I did with the Wheezy-amd64, so there is at least a little sanity in this universe. I can use this system to suss out what is so cockamamie about my CuBox-i4Pro Debian configuration.

zultron commented 9 years ago

On 05/05/2015 05:07 PM, Kent Reed wrote:

I have pasted the output of this command to https://gist.github.com/RunningLight/abda3ca6993fa199b25a

Look down at line 217.

  • |apt-get| is drawing the |libzmq3| and |libzmq3-dev| packages from |wheezy-backports|

Yes, that's what's going on, conflicts with backports packages. It doesn't help that the script is stripping the versions from the packages, or it wouldn't try to install libzmq3=3.2.3+dfsg-2~bpo70+1.

A script based on mk-build-deps or apt-get build-dep would know how to deal with these things.

  • I don't know |bash -x| and neither does debian bash. Is this problem this a Fedora-ism :)
 jman@d7-64-xenomai:~$ lsb_release  -c
 Codename:       wheezy
 jman@d7-64-xenomai:~$ bash -xc 'echo foo'
 + echo foo
 foo

What was your command line?

Some interesting stuff happening here. It seems that |apt-get| is drawing packages like |python-zmq (14.4.0-1 Debian:8.0/stable armhf])|, apparently because the wheezy image I got has enabled |wheezy-updates| in |/etc/apt/sources.list|. Again, I'm running into a problem regarding libzmq. I'm still examining my wheezy-arm situation; will report more later.

I'm thoroughly confused....

Aside: I can understand that in your Buildbot environment you don't see these issues, but I'm flabbergasted that I am the only person reporting them since others are posting about their builds.

Could be because you're the only one who's run that script (& reported errors) since #594 was merged eight days ago. Most devs probably haven't restarted from scratch since then.

RunningLight commented 9 years ago

@zultron

A script based on mk-build-deps or apt-get build-dep would know how to deal with these things.

Well, last October we were discussing exactly such approaches (https://github.com/machinekit/machinekit.github.io/issues/25) but the discussion petered out after scripts/apt-installbuilddeps surfaced. Time for me to revisit (and, I suppose, to move this discussion there once you've convinced me debian/control is right).

$ bash -xc 'echo foo'

Ah, -xc ...now the fog begins to lift. I took you literally before and couldn't get anything intelligible. Trying to reach enlightenment using bash --help and man bash didn't help.

I'm thoroughly confused....

Don't worry about it. I'm learning the hard way that the Wheezy/armhf images floating around the Internet are to be treated with great caution, no matter how good they sound in the HowTos. I should be able to turn this experience into a FAQ of our own.

The Scaleway image seems to have a pretty pure rootfs.

RunningLight commented 9 years ago

OK, I now seem to have a reliable set of instructions for building from source which works on Wheezy-amd64 and on Wheezy-arm. By going to build-dep in place of apt-installbuilddeps and adding deb-src http://deb.dovetail-automata.com wheezy main to the apt sources, I've gotten clean builds of fresh clones of the machinekit repo in virgin installs of both systems. No change to debian/control was necessary. I'm closing this issue and posting to machinekit/machinekit.github.io#25 where you can tell me what I've overlooked :) Next stop, of course, is to check on Jessie.

My original Wheezy-arm problems stemmed from a reference to stable instead of wheezy in the /etc/apt/sources.listfile which I inherited with the pre-built image. My bad; I shoulda checked!

FYI - make -j4 finishes in 43m25s on a quad-core Cubox-i4Pro (running off a 32GB SanDisk Ultra microSDHC UHS-I uSD) and in 34m25s on a quad-core Scaleway C1 host (running off whatever their SSD is).

jpmoniz commented 9 years ago

Can you shed some more light on what exactly you did? I tried building a clean VM today and I am getting the same dep issue.

http://pastebin.com/6Q2hFdkC

zultron commented 9 years ago

For the most part, the usual instructions should work, with a couple of issues:

jpmoniz commented 9 years ago

@zultron

Ok so asking the obvious question. Should the build instructions be changed to reflect this?

jpmoniz commented 9 years ago

@zultron

https://github.com/machinekit/machinekit.github.io/pull/45

jpmoniz commented 9 years ago

Closing issue. Built twice with no issues.