BluOS controller app on Linux
Beantwortet
I'd just like to put in a plug for supporting the BluOS controller app on Linux. All of my home computers run Linux Mint 18.1, which is closely related to Ubuntu, and my work-at-home machine is running RedHat Enterprise Linux 7.6. I realize it's a niche market, but it's growing, and I bet it's pretty similar to MacOS under the covers.
-
@Josh Ellithorpe there are two different parts to create the Linux package for a new version:
1. Create the new patch: this is very much a manual process, quite difficult (if possible at all) to automate. I always start by trying to apply the previous patch, analyze why it does not apply, then manually try to adapt using a text editor. Indeed, if Bluos would accept the patch once, this part of the work would not be required anymore.2. Build the package: this is very accurately documented here: https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/blob/main/.gitlab-ci.yml#L16
0 -
@Ben Simon I follow this thread and had a few follow-ups:
There are two active packages that I know of, both of which host their work on open-source repositories:
- Fabrice's (conventional AppImage packaging): https://gitlab.com/fabrice.aeschbacher
- Mine (Nix packaging): https://github.com/shajra/bluos-nix
One thing you'll notice if you look at these projects is the degree to which we're not patching the code much to get things working. We luck out that Electron applications are so portable:
- Fabrice's patches: https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/tree/main/patches?ref_type=heads
- My patches (very similar): https://github.com/shajra/bluos-nix/blob/main/nix/linux.nix
Fabrice's approach involves patch application. Mine is a textual search/replace. The idea is that maybe I luck out a little more, rather than dealing with hunks that have moved. Still, it's not perfect, and I had to make slight changes when releasing 4.10, removing a hack needed for 4.8 (maybe useful for Fabrice when he gets around to this task).
Because I don't have the personal motivation, I haven't reproduced Fabrice's workflow. But that's not to say he's doing anything mysterious, and if you follow the code he's posted, you could very well get it built. Fabrice does the community a service by running scripts he's comfortable with and publishing built artifacts.
Because of the nature of Nix, my work is highly repeatable. However, it comes at the cost of installing Nix as a package manager, which most people probably aren't using for anything else. My repo has lots of embedded documentation to get you started if you're interested in that.
Of course, it would be great if Bluesound did indeed support Linux packaging. It would take some of the work out of figuring out the pinpoint hacks to get it repackaged. But I don't think either Fabrice or I are going through the Javascript code trying to figure out what features are where. We're just repackaging with the least effort we can muster. Most of the time, we do these updates, and the user experience remains indistinguishable, save for the version number bump. I'd rely on official release notes from Bluesound for more information.Hope this post helps.
0 -
There is a MR up now for 4.10.0. I figured I would help Fabrice out and get it building myself. =)
https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/merge_requests/1
If people are impatient there is an AppImage available on my fork, and the AUR is updated for Arch Linux.
https://gitlab.com/zquestz/bluos-controller-linux/-/packages/424155970 -
4.12.0 has been released, and while 4.10.0 was a pretty easy release, this release seems to have introduced some larger structural changes in the build.
I know a lot of people aren't using Nix, which is what I'm packaging for, but https://github.com/shajra/bluos-nix captures my packaging work. What's released on the main branch is for 4.10.0. I'm still sorting out what changes are needed for 4.12.0. I'll post here when I have that finished. Hopefully, that will help as a reference for other people packaging differently.1 -
I think it didn't end up so bad. I have 4.12.0 packaged for Nix:
https://github.com/shajra/bluos-nix
But if you just want to see what I did to get the build working, this commit has the most important patch:
https://github.com/shajra/bluos-nix/commit/d27b5bc294f9df364e355769681b78cdeba3238bThe main app code was moved to another location, a variable reference for the resource path got a little more complex, and the code to quit upon the last window closing was changed.
Hopefully that helps everyone! One day, we'll have official Linux support. Right? right?
0 -
This time I did not find the time, then I forgot... But Josh Ellithorpe kindly did the work, thank you for your MR, which I did only see today - sorry for that. This allows me to announce:
BluOS published a new version v4.10.0 of the controller, for which I just pushed the patch. To reproduce a build locally, follow the steps in the app-image build job [1].
Or you can download the AppImage built by the pipeline [2].
The Release Notes are quite thin [3][1] https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/blob/main/.gitlab-ci.yml#L16
[2] https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/packages
[3] https://support.bluos.net/hc/en-us/articles/18663655952279-Android-BluOS-Controller-App-4-10-0-and-previous-versions2 -
Whoa... I think if you mention Linux distributions by name or something, posts get flagged for approval. I don't know what's going on there. I removed this one paragraph from my post above, and it seems to have been posted. Anyway, I have 4.12.0 out.
0 -
I have opened a merge request for the 4.12.0 changes!
https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/merge_requests/2
You can also download it from my fork at https://gitlab.com/zquestz/bluos-controller-linux/-/packages0 -
Will there still be an appimage for 4.12.0?
0 -
It seems that my post about that was not published, not sure why. Let's have another try:
BluOS published a new version v4.12.0 of the controller. Thank to Josh Ellithorpe for providing the patch I merged. To reproduce a build locally, follow the steps in the app-image build job [1].
Or you can download the AppImage built by the pipeline [2].
The Release Notes are at [3][1] https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/blob/main/.gitlab-ci.yml#L14
[2] https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/packages
[3] https://support.bluos.net/hc/en-us/articles/35439594062743-Desktop-Windows-macOS-BluOS-Controller-App-4-12-00 -
Thank you guys for your excellent work. I was afraid it had become impossible to get a recent appimage for Linux, due to some developments on the Windows side. This after a scéance with GPT-5 asking why the windows .exe no longer works with WINE. So for us poor Linux users an appimage seems to be the only way now. I hope future versions of WINE can solve the problem.
Also, it seems the Bluesound forum moderator is a bit touchy lately when links and some terms appear in a comment, resulting in delays or loss of comments.
0 -
Thanks guys!
0 -
Looks like there was a minor release of v4.12.1, which I've packaged for Nix. I haven't really looked too hard for release notes to see if there are any observable differences.
https://github.com/shajra/bluos-nix
I know I'm probably the only one here using Nix packaging, but I'm posting to let people know about any build complexities I've noted (in this case, the lack of them). From my end, the same build for v4.12.0 continued to work for v4.12.1, however, I have a search/replace approach to my build, so I don't have to mess with hunks shifting to different line numbers or contexts.
0 -
Work for supporting v4.12.1 for Linux has been completed.
MR is at https://gitlab.com/fabrice.aeschbacher/bluos-controller-linux/-/merge_requests/3
Or you can download my appimage at:
https://gitlab.com/zquestz/bluos-controller-linux/-/package_files/245818399/download0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
194 Kommentare