Does not install on Ubuntu linux 24.04 (with workaround) #133
Comments
|
Hey @KlfJoat, Ah, thanks for that great writeup! You're the first person I'm aware of that has used the Linux version at all. Personally, I'm not running any Linux installs at the moment so I wasn't aware of this. I probably don't need the It probably doesn't even need to be pinned anyway, just any version of I haven't had much time to look at October lately but I'll spin up my VM sometime and have a look at this |
|
Hi, Same issue, however workaround as given does not work. Get the following error when running: I was able to run it by following the process referred to here: bambulab/BambuStudio#3973 (comment) (you have to add those statements to the sources, apt update, apt --fix-broken install (or if you don't have a broken october install you can just install it at that point), then remove those entries from the sources list again to make sure terrible things don't happen). As the original reporter mentioned I think it could probably solved relatively easily with some more liberal linking. Anyway, apart from that small issue, it works great. Thanks for the software, @marcus-crane. |
|
@reality Adding an old repository like mentioned in that comment can mess up your dpkg database beyond all reasonable attempts to fix it. I would highly recommend against that being the first thing that people try. Installing the new version of the dependency, then forcing only October to ignore its dependency list, is the best option.
|
|
sure, but like i said in my comment, your workaround doesn't work for me - that is actually why i sought another solution. |
|
Heya, No promises as always since I can't predict the future but I'll see if I can make the linking for libwebkit2gtk a bit less strict this weekend. As far as Wails (the underlying framework), it seems that the approach some other projects have taken is to just distribute two copies of their projects: one for 4.0 and another for 4.1 which seems kind of wonky. Wails itself seems to mostly push this issue to the packagers (which I suppose is me in this case) and is looking to lean on AppImage and the like. I guess I'm learning the hard way why Snap/Flatpak/AppImage are a thing. Personally I don't really like any of them since they always have something wonky about them in my (fairly limited) experience. |
|
Heya, I've had a look around and I think I understand the constraints a lot better now. That said, I haven't had to fiddle with static/dynamic linking stuff in Linux. Given that, I'm building out a mental model of what's going on at the same time as trying to understand a possible fix so you'll have to let me know if I'm misinterpreting anything here. As a tl;dr, it seems the only real options here are:
The rest of this post is just elaborating my understanding of the problem in detail for any interested readers and/or other Wails devs who have probably run into this problem. Feel free to skip the rest if you're not particularly interested. So, there's a couple issues here tangled together as far as I can tell:
Dynamic vs static linkingIf I compile a fresh build of October locally, I can use
As you can see, some of these links are done at the version level so for example, if you had As a workaround, you could symlink Now, even if the APIs between those two dependency versions were identical (or changes were only adding new functionality, not changing anything existing), there's no guarantee that the ABI for that library hasn't changed. I can't really speak to ABI stuff since I've only been vaguely aware of the term without really reading about it until now. With all that said, actually trying to produce a fully statically linked application for something that depends on GTK doesn't actually seem to be supported. Even if I were to attempt it, I'm not actually sure that it would functionally work. It seems that the conventional solution here is to package up everything using Flatpak/AppImage/Snap which solves the dependency issue by stuffing the final build in a container. I'd probably provide those versions for convenience (and the currently unreleased v3 of Wails seems to make this easier than ever) but they're a bit of an apples to oranges comparison for people who like "installing" apps via deb. Wails hard pinning vs loosening up dependenciesWails currently supports building against webkit2gtk 4.0 vs 4.1 by way of using build tags. You can see how this is structured here by way of CGO declarations building certain files based on the installed version of libwebkit2gtk at build time. From the referenced PR, you can see that there are actually different implementations of the asset server based on what version of libwebkit2gtk exists with functionality being slightly different as a result. While I'm sure unpinning Out of date depends in debThis one I can actually influence and it should be updated to either assert a recent version of webkit2gtk (ie; 4.0||4.1) or match whatever build tag is used. Actually removing it or modifying it won't change the reality of the application being dynamically linked to a specific version but it'll still assert for the user that they have webkit2gtk installed since October would just crash if they didn't have it installed (rather than prompting them to install it like Windows 10 with webview2 for example) Another thing mentioned was the requirement for Anyway, for now, I'll just generate a second I don't think it'd ever be possible to have a single binary/package that supports all webkit2gtk versions (due to dynamic linking) but I do wonder how other non-Wails projects solve this stuff as far as webkit2gtk dependencies. Footnotes
|
|
Anyway, just to be a bit more explicit, I'm gonna go for a walk after hurting my brain parsing through all the above but I'll try and generate some builds later today + add some docs around which versions to use. It'll work as a stop gap to unblock support for newer Ubuntu versions but it does seem a bit like one of those issues where you just have to pick the least worst choice since they all come with tradeoffs |
|
I've got some bits of the release pipeline to fix up still but I've generated two versions of the Linux deb package available in this prerelease: https://github.com/marcus-crane/october/releases/tag/v1.10.1-beta2 The non-webkit2gtk4.0 version should work for you. I'm not entirely sold on the naming scheme for the releases but it'll do for now |
Hi,
I love your tool here.
When I tried following your instructions, I ran into a dependency problem.
To start with,
apt install ./filenameusually works on Ubuntu to install.debs.Okay, dependency problem. So I used
dpkg -iin case it was a soft dependency.So, that didn't work. Unable to find the dependencies. So I checked and sure enough, hard dependencies on specific versions.
$ dpkg --info ./october_1.10.0_amd64.deb new Debian package, version 2.0. size 5332528 bytes: control archive=311 bytes. 278 bytes, 9 lines control Package: october Version: 1.10.0 Section: base Priority: optional Architecture: amd64 Depends: libgtk-3-dev, libwebkit2gtk-4.0-dev Maintainer: Marcus Crane <[email protected]> Homepage: https://october.utf9k.net Description: A tool for syncing your Kobo highlights with Readwise $So I typed this in and tabbed it out to get bash-completion to tell me what versions of
libwebkit2are available on Ubuntu 24.04.FIX ABORTED INSTALL
So I first removed the aborted install...
WORKAROUND INSTALL
Then I installed v4.1 of the dependency and installed October, ignoring dependencies using
--force-depends...SUGGESTION
I'm not sure if Wallis requires
-devpackages to just run an application--that's unusual, but not unheard of. As a longtime linux admin (admittedly, not a programmer), I would suggest three things (pick and choose between them).-dev-packages and not just the main package. My host haslibwebkit2gtk-4.0-37available, but not a4.0-devavailable.libwebkit2gtk-4.0-37&libwebkit2gtk-4.1-0available. Maybe a spec likeDepends: libwebkit2gtk-4.0|libwebkit2gtk-4.1? (ref1, ref2)libwebkit2gtk-4.1, at the very least, itself depends onlibgtk-3in Debian. So you might be able to skip that dependency.The text was updated successfully, but these errors were encountered: