Here's a Mac build. The git commit versions are working in the About popup.

The Windows Installer configuration in Cura2Build was inconsistent between calling the executable Cura.exe and Cura2.exe, I synchronized the configuration to use Cura2.exe

Here's an updated Windows build. The Git hashes in the About window are now working.

The Windows build was already setup with a simple, potentially cross-platform path to version.json. If the Linux build is configured in such a way that it requires a more complicated, platform-specific path to version.json, it is the responsibility of CuraApplication.py to juggle those differences. The Windows distribution shouldn't need hacks to work around Linux issues.

@alexei: The version.json file is in the Cura application root, the same place it was when I first setup the version.json generation based on the specs Victor handed me (https://code.alephobjects.com/rCBbb9a2209b6f5a28a62306f9ed24d83dd2612a7bf.) The About hashes functionality on Windows worked then, and it looks like it was broke in this commit: https://code.alephobjects.com/rCT70e15dbfc8f99c48121a983c0b2f4ed6a1368f1e.

Here's a build using the devel branches.

Here's a build of the Windows version. I was able to run it and it seems to be working right except the git hashes aren't showing up in the splash screen.

Blocked by https://code.alephobjects.com/T761.

This task is currently blocked by a break in the latest version of the Cura repo. The Cura repo contains files with characters in their names that are not supported on Windows and crash git fetch. The unsupported characters are asterisks though the files may contain other unsupported characters as well. It looks like the files are material and cfg files.

I merged this into master.

With some of the commits over the last few weeks, T703 is no longer a blocker for this task. There's still some Debian-specific work I will need to do for this task now that I can compile and run Cura2 on Linux again. (Embedding the version.json file is needing slightly different code on each platform.)

I thought having the same variable for all of Ultimaker's tags was strange, especially since when I looked the tags on their different projects do not line up. This is a good change.

Okay, cool. I may have some questions about folder structure and where the installation should place files when I get to that part.

This is a busy week for me and I haven't had much time to work on the Python packaging. My understanding from the meeting Friday was the plan was to use Python 3.4 on Linux for now, and switch to Python packaging in the near future. Now Python 3.4 isn't an option and the Python packaging is more urgent.

@kakaroto: From the documentation it looks like all I need to do is add you as an auditor, so I added you as an auditor to the two commits. If there's more I need to do to start the review process let me know.

@alexei: For the present I have taken responsibility for Cura2Build and will push to its master branch. But in the case of the other two repositories, I am an external contractor pushing breaking changes to repositories that I am not responsible for. The fact that the repositories are already broken should reinforce the need for accountability, not remove it.

I pushed up fixes to Cura2Build master, Cura2 dev, and Uranium dev. The Cura2 and Uranium patches will need to be merged by someone as a sign-off.

@all: I was wrong about packaging the python interpreter for Linux; that will take more work than it is worth in this case.

I have this working on Windows.

The Cura2 repo also has merged upstream commits that require Python 3.5.

The plan is Python 3.4 for Debian. A commit from upstream was merged into Uranium. The code in that commit requires Python 3.5.

The way Ultimaker structured their application, cura-build is the head of the app. Even though one of their repos is named Cura, the Cura repo is not the head of the app. Cura is a small piece of the final product, while cura-build is the repo responsible for pulling all of the pieces together and generating the final product. cura-build is aware of every aspect of the program, and every aspect of that program affects the final version of the product. The Cura repo is only aware of some of the final product's dependencies, and could not logically manage the final product version.

I'm not directly working with the versioning so I'm fine with however the versioning is handled, but its worth asking, why would the version be stored in the Cura2 project?

@kakaroto: Over the weekend I had to debug some Windows seg faults and started using Python faulthandler, which helps give better seg fault stack traces. This would require modifications to Cura and a new build, so it wouldn't fix the immediate issue for this thread, and it still might not provide enough information to solve it, I'm just noting how to enable faulthandler for possible future use.

@alexei: For the Mac build to work right it will need the "mac-fix" branch of Cura2 merged into master. I'm okay modifying master on Cura2Build since that's been mostly where I've been living the past few months, but Cura2 is a repo I've only worked with a little and that really needs someone else overseeing master merges.

One of the reasons I was working off of a dev branch was so someone else could sign off on my changes and merge them into master, but I guess that's not essential in this case. Cura2Build dev is now merged into master.

@alexei: The updated README in Cura2Build has more detailed Mac setup instructions than it used to (currently in the dev branch).

@alexei: The updated README in Cura2Build has more detailed Windows setup instructions than it used to (currently in the dev branch).

Ran into a lot of problems that needed fixing. Looks like I got lucky when it was working before, but the problems are fixed now.

Sorry, my build installation was broken with the various 64 bit experiments and I had to fix some things and start the build from scratch. I'll upload it once its finished.

Here's the Mac version 2.2.1.

@kakaroto: Working on Cura2 for OSX this week has been my first experience working with OSX development. I don't know what more the user could do to gather debug information.

The Mac build is working now. It requires commits to Cura2Build (currently in the dev branch, that's where I've been working for a while) and commits to Cura2 (currently in a branch named "mac-fix").

It looks like the only part of Cura2 that needed linking to the C++ stdlib is Protobuf. I changed that to be static linked and it seems to be working. By working I mean I can compile and install it on x64 without copying the shared library into the deb package. I don't have a i386 install of Debian to fully test but can set that up if i386 build problems continue to surface.

I have experience dealing with C++ standard library deployment.

The Cura2 BuildBot process is succesfully building and uploading i386 and amd64 debian packages on my computer. Pushed up the new Cura2 directory to AOBuilds.

I changed the package name to cura2 and removed the epoch. I also changed the install directories to cura2.

When I temporarily remove /opt/cura/lib/python3/dist-packages/Arcus.so the program will immediately throw an error before any other logs, so to get far enough into the program for slicing, some part of the program must successfully find Arcus.so.

@nickthetait: I was accidentally looking at Arcus.a. Arcus.so is in the right place (I don't know why the process is packaging .a files.)

@nickthetait: Looks like Arcus.so is getting put in the wrong path. I'll figure out what's causing that.

So it looks like the first QT bug I mentioned really isn't normally critical but my debugging must have gotten my dev_env into a state that turned that bug into a critical error.

It seems if anything breaks during the menu QML loading you can get similar incomplete menu symptoms so they could be caused by a variety of different problems, but in that particular case it is probably the same QT bug because the error logs in that github issue list:

Here's the deb package. It's 113MB and looks like it uploaded okay. (I wasn't sure which version number to use.)

I'd forgotten about the git clones in dev_setup.sh. Initially I hadn't thought much of them because they could easily be altered by cmake but you probably don't often need to rebuild the whole project, So I guess putting live repos into an output folder is the answer to my first question. I can work with that.

@nickthetait: I get lots of similar error messages when I install and run the built package, but I don't get a segfault. The only major difference in code paths I can think of is my computer isn't connected to a printer. If that is the case I guess I'll need to visit soon to pick up a printer.

@kakaroto: I reviewed them briefly, though I'm still piecing together each of Cura2's components and their build requirements, so I will review those changes again soon once I have a more comprehensive understanding of the build process.