In D1119#37060, @JoshStrobl wrote:

Closing due to lack of response.

In R3876:61d5eb45af223c0e79bed888a58eafc60451faba#28159, @tristan957 wrote:

Thank you Ben. Been looking forward to this moment for so long :). Now the one of the earliest tasks on Phabricator can be closed :)

@joebonrichie @kyrios123 Thanks for your help!

As per review comments:
Modify build to use github source
Moved some commands to 'install' section
Kept 5 octal file permissions as per @sunnyflunk's suggestion

Updated to version 1.7.1
Revised dependencies as per review comments

Hey @padraig the LibreOffice failure is normal as it was built against the older version of boost. When boost 1.65 is included into the stable repo LibreOffice will get rebuilt against the newer version. I'll continue to look at it, have been a little under the gun at work at the moment. Once we get the local build down I think it'll fall into place.

Thanks @joebonrichie building now and so far working a treat!

Yeah so the issue I was having was that I dont think I configured the local build properly as per https://solus-project.com/articles/packaging/local-repository/en/ as if boost 1.65 was included then libboost_python3.so should be in either /usr/lib or /usr/lib64 (/usr/lib is typically a symlink to /usr/lib64, so that shouldnt matter). I was talking to @Justin about this issue, hopefully he is enjoying is holiday atm so if we are still stuck we can bug him later ;)

Hey guys,

The current version of boost in the repo doesnt yet support python3. So you will need to do a local build of the pending update D7. I've uploaded the package.yml for you. Once you build it pop the eopkg files in /var/lib/solbuild/local/ and it should build against the 1.65 version, I am having a couple of issues with that though so let me know how you go.

In D1067#18274, @EP01 wrote:

Apologies for that @DataDrake and @doc-E-brown. As I said it's just a personal preference, and a similar convention is followed in R2642. I haven't been able to find a conclusive answer from PEPs or other distros on whether executables ending in a number should be treated differently; at least it's not as bad as Arch who have autopep8-python2 for their python2 version. Again, sorry for the extra work @doc-E-brown!

Sorry guys! I must have stuffed up something with arc, it created this diff rather than push the changes to the existing diff I was working on D1067

Renamed Python3 script autopep8-3 to autopep83

In D1118#17428, @JoshStrobl wrote:

Why did you replace it rather than just updating it?

See D1119 for this task

Replaced with D1119

Hey @padraig Ive been able to get it to link against libboost 1.62 for Python 3, but not the latest 1.65. I have not been able to link libboost_coroutine against 1.62 as it seems Boost.Coroutine has been moved to Boost.Coroutine2. I have uploaded my config.log to hastebin, I'm going to have a look through the graph-tool Docker image to see if there are any hints there.

@Justin , the package.yml I sent you was only for Python2 as I was just trying to debug the fact that I couldnt build it at all. To build Python 3 as well will actually require running the build twice for the separate versions. I was wondering if this is a bit much for a single package build, and if we cannot stop the memory leaks whether Python 2 & 3 should be packaged separately.... thoughts?

Reordered build dependencies
Removed explicit requirement of pkgconfig(python) as is in base image
Renamed autopep83 to autopep8-3 for Python 3

Updated as per review comments:
Changed MIT License to just MIT
Changed source from pypi to github location to allow for removal of networking

Yeah autopep8 can be installed via pip and pip3. I was wondering about whether it would be accepted as a package myself. I did a quick check on IRC, had a look around at some other packages, and saw a couple of similar packages like pycodestyle https://dev.solus-project.com/D1006 that also are pip installable. If nothing else thanks to @kyrios123 I was able to get familiar with the patch process ;)

Here is a patch for python-autopep8, it covers both Python 2 & 3. Using the slightly newer version 1.3.2.

@padraig I have the same issue with the RAM, even using make on its own to ensure no parallel processes. @Justin has also tried his 32GB RAM machine and the build process capped it out too.

Hey All,

Docker seems like a good way to go. I'll give it a try and will report back.

As a researcher in machine learning I'd love to switch to Solus full time as my sole distro. CUDA support would enable that.