Conversation
|
Cool thanks. Is there a roadmap or even vague ETA on when the next version of SyncPlay will land with this fix? Even if it's just another RC. The reason I ask is because packages for my system make a distinction between git-sourced and version-releases, and I was intending to package the version release primarily, since I'm not sure how you guys treat the master branch (i.e. if it's much less stable, prone to breaking, etc.). |
|
We try to keep the master branch relatively stable. There are a few bugs which I expect we'll want to fix before releasing the next RC - how long it'll take depends on how much time people have. Could you just package your own fork? |
|
It's hardly a pressing matter enough to package my fork; I was merely curious, not pressuring. I think what I'll do for now is package a git-sourced version (which like I said is normal in this system) and when the next RC is released I'll create a package for that as well. |
|
So far I have created an archlinux package sourced from git, syncplay-git, meaning it'll always get the latest source and build from that. Once the next version is released that incorporates these changes, I'll create a release-version of the package, so that ultimately there will be two: syncplay and syncplay-git. |
|
Now that RC4 was released I've published a package for syncplay (i.e. non-git sourced). |
This is just an idea I guess, but I tested it and it works both with regular
sudo make installas well as the package that I created. Fixes #28There's now a marker in the client and server that is just
# libpathwhich gets substituted in the makefile with sed tosite.addsitedirwith the path to the syncplay module files, effectively adding the syncplay module files inwhatever/libto the files that python searches for during animport.So yeah, I tested it and it works fine on its own (i.e. regular
sudo make install). All I do on my own end with the arch package is yet again run sed to replace python with python2 in the client and the server. This is expected/common in arch packages for python programs.I tried to change as little as possible. I had to add
${PREFIX}to each of the path variables because the arch package needs some way to specify the prefix at which to install the stuff. This is otherwise empty (if the user doesn't specify it) so it should be of no consequence to anyone else.A last minor note is that I do the replacement with sed after the file has been copied to its installation, to preserve a pristine copy in the source directory.
EDIT: Forgot to mention that I also
mkdir -psome directories that hadn't been before. I suppose they weren'tmkdir -p'd before because these directories are normally present, but the packaging system on arch does the installation within a chroot environment, where these directories don't exist, so themkdir -pis necessary and of course of no consequence to anyone else if they already do exist.