- User Since
- Mar 31 2017, 7:26 AM (132 w, 3 d)
Tue, Oct 1
The Mac slave is updated with macOS 10.12.6 and Xcode 9.2.
I'm seeing this ticket after whitelisting notifications. The current status is that I produce a not truly 64-bit of Cura since not all dependencies are 32-bit, the build installs but behaves badly and doesn't print. I'm trying to nail down all dependencies to 64-bit and I'm getting close, last two weeks I didn't have that much time to spend on this, but this week and next I'm full focused on getting this running.
@alexei Ok then we can upgrade the slave OS to Mojave. I'll get on it right away and let you know when ready.
@alexei this means that we have to upgrade the slave to later MacOS release. Does this mean that all future versions of Cuba will need Qt 5.12 or later? Cause I’m worried about reverse compatibility.
Oct 6 2017
Sep 29 2017
Ok. Will do that.
The errors about missing python package (objc): I've looked up in the code and there is only one place where this import is used - it is in Uranium in a part of the code that prevents the computer to go to sleep. So far these two errors (T1192 and T1034) does not seem to be related (except that 1192 may have blocked the testing of 1034). On first glance this error seems unrelated to the inability to print.
I've added the missing file (lulzbot_debug.def.json) to the final build for Mac OSX. The file was removed in the final step while the script "setup_osx.py.in" was filtering out DEBUG files (the file contains "debug" in the name). This is now fixed.
Sep 28 2017
@Yahuba this was fixed after 2.6.34. So should be available on latest automated builds.
I can replicate this as well, but I can't find any reason why this is occurring. @tranter can we have Elena maybe to look into this?
Fixed. I've added the package "serial" in the python3 packages when building Cura2 for Mac. @Yahuba can you please verify?
Added option to sign the build with the Apple Developer Id key. The codesign can be triggered by specifying -DAPPLE_ID_CERT_NAME="Mac Developer: [developer name here]" when invoking CMake. @alexei can you configure this on buildbot master?
Fixed. I've added the version.json file to the Mac build (generated dmg). @Yahuba can you please verify?
I've tested on Xenial and Zesty. Xenial carries libicu55 and Zesty libicu57 (from official repositories). So when the package is build on Xenial, the executable is linked to libicu55, and when build on Zesty it is linked to libicu57. This is fine if you install the packages appropriately. If you build on Xenial and install it on Zesty, there would be a library version mismatch (same happens if you build on Zesty and install on Xenial). I don't think this is something we can fix easily. @alexei you can use the docker build and build different versions for xenial and for zesty respectively?
Tested, works from version 2.6.33.
Jul 6 2017
@alexei Aleph Objects needs to register here: https://developer.apple.com/programs/ and then I need to be granted access there or receive the keys and certs so that I can use them to sign the software.
Jun 30 2017
Jun 21 2017
Jun 20 2017
Jun 19 2017
Jun 16 2017
Latest Cura2 windows build as of this morning:
Jun 12 2017
Here is an updated build with Cura and Uranium with USB support from the devel branch:
@alexei Please find a Cura 2.6 32 bit Windows build here: https://drive.google.com/open?id=0B9CTS78rllNYUThoTTliSVFZZVE. I've tested installing and running it on Windows 7, 8 and 10 and just by doing simple smoke tests it seems responsive and doesn't crash. It would be great if someone can test it out and get some feedback, I'll start implementing the changes to CmakeLists and the readme in the meantime.
Jun 1 2017
Apr 21 2017
@alexei as reported via Jabber, the buildbot agent was reporting as being connected to master, after restarting the agent builds started triggering so everything should be fine now.
Apr 10 2017
@alexei It's done. Please give it a try.
Apr 6 2017
@alexei We have Clang version 8.1.0:
Apr 1 2017
The Windows slave is setup and connected to the buildbot master at am.alephobjects.com. 32-bit Windows builds are supported as per the instructions on the Cura2build page
I followed the instructions on the cura2build page and I got the following build error:
[ 71%] Built target Cura-PostProcessing Running py2app Traceback (most recent call last): File "setup_osx.py", line 15, in <module> import UM ImportError: No module named 'UM' make: *** [build_app] Error 1 make: *** [CMakeFiles/build_app.dir/all] Error 2 make: *** [all] Error 2
I can see that in setup_osx.py there is an append to the PATH with sys.path.append('inst/lib/python3/dist-packages'), however looking at the contents there is only Arcus.so there and nothing else. Since I'm quite new and I don't know how the whole build is structured, one thing that I found odd is that the UM module is placed in ./inst/lib/python2.7/site-packages/UM, I thought that python3 is necessary for building Uranium and the overall Cura 2? Is this handled by the build scripts or I have to build Cura 2 in a python3 virtualenv?