Hacker News Reader

> Searching for the error brought results about a wrong version

One of the bullet points from the Meson website:

> * fun!

So if I understand correctly, this modern build tool created to replace all the extant time-wasting build tools got memorialized in Debian in a half-baked state where it's not compatible with future versions.

Also-- the fact that you had to leave the hardened bank vault of apt through the screen door of pip... to install a thing to build other things to run on your system.

I love it.

> If so, why is it I so seldom can can get anything written for GJS, or Node, or a Python program not my own, to install and run without a three-hour yak shave?

... is the question that explains why Electron exists. Every comment on HN about its size, memory usage, and insecurity doubles as a critique of all the problems you just hit with a Linux system.

Electron: "Memory and disk space is cheap enough, but your time will never be."

I don't like Electron — I've brought some of my problems on myself by my love of using minimally-capable old hardware — but this is by far the best statement of the argument for it I've ever heard.

I propose on building native tools that have all relevant libraries statically linked. Yeah, executable will grow in size, but it's the best of both world : portability, speed and not using javascript.

It's worth mentioning in this context that the thing making Foliate difficult to build and run on older platforms is the fact that it's written in modern Javascript (and therefore needs a modern version of gjs): https://github.com/johnfactotum/foliate/issues/45

Hi, author of Foliate here. It sounds like you're using something like Ubuntu 16.04 or similar? Foliate currently requires GJS >= 1.52 and Meson >= 0.40.

There's an open issue here on supporting older systems: https://github.com/johnfactotum/foliate/issues/45

why don't you make a configure script that detects and warns about these requirements?

I'm using Debian 9.8 Stretch, released in February.

> released in February.

Yeah, that's not how Debian stable works.

It's when the point release was done[0]. Obviously not everything was new then. I'm assuming most people who package applications for Linux have an understanding of how Debian works.

[0]: https://www.debian.org/News/2019/20190216

> Obviously not everything was new then.

Nothing was! Debian stable doesn't update packages (not even minor releases or bugfixes). They only backport security fixes or very critical bugfixes.

Debian 9 was freezed on 2017-02-05. You'll have the version of every package from this date, point release don't change that.

We're not disagreeing — please stop trying to raise an argument where there is none!

My only reason for giving the point release date was to say that it's a supported release. You're reading a lot more into my tiny comment than I ever put into it.

> it's a supported release.

Calling it "supported" in the context of the ability to build arbitrary software is misleading. It's supported by Debian for the particular packages included in Debian's package repositories - nothing less, nothing more.

Hi,

I've using Linux as my primary desktop at work and home for going on 25 years.

If you want to use newer software you should pick a distribution that is geared for that.

Debian stable is for people that DON'T want new software or even to try new software.

You are at odds with your choices.

Either switch to Testing, Unstable or pick an Ubuntu strategy ie Long term or every 6 months.

Of these choices Ubuntu is actually more conservative then Testing or Unstable as it walks forward in a predictable time based manner.

Good luck.

That's one perspective, and it has merit. Others tell me, "You should use a stable release and build software you need from scratch — that way, you get the best of both worlds!" In either case, it seems like writing new software using bleeding-edge versions of libraries and tools is not really necessary; if you hang back a couple releases, it makes matters much easier. Backward compatibility is much easier to achieve than forward.

(I don't have enough experience with GJS and WebkitGtk to know if slightly older versions would have been workable here, though I believe that approach to be valid in most cases.)

A library from 1 to 6 to 18 months ago is not "bleeding edge" in any way shape or form.

You are making software reactionary arguments for people doing a lot of work to support you touristing their software from an ancient, long out of date software distribution (which is what people that use Debian Stable want).

If you are going to make bug reports or even comments you really would be better to state you are on Debian Stable from the beginning, it's actually rude to make people think you are on a reasonably supportable distro without warning.

Flatpak is probably your best choice to encourage people to be even able to support your distribution choice going forward. The sandbox also has some attendant benefits that will bear more fruit in the future.

> In either case, it seems like writing new software using bleeding-edge versions of libraries and tools is not really necessary; if you hang back a couple releases, it makes matters much easier.

I believe this is precisely what Foliate does. It depends on meson 0.40 (released Apr 2017) and gjs 0.52 (released Mar 2018). Sixteen months old dependencies can hardly be considered bleeding-edge.

You are clearly right, and I assumed wrongly.

This is exactly what Flatpak solves.

https://flathub.org/apps/details/com.github.johnfactotum.Fol...

But then you can't make changes to the app! You're stuck with a read-only copy.

You can build your own Flatpaks from source, too. In fact that's probably how a lot of development is done these days around GNOME and its wider community when using Gnome Builder. You make a change, and Gnome Builder builds a Flatpak and runs it for you so you can test it.

Yes, I finally installed it via Flatpak. What a fun adventure! First, I had to install Flatpak with apt. Then, I downloaded the Foliate .flatpakref. I installed it with `flatpack install com.github.johnfactotum.Foliate.flatpakref`, which worked the first time!

No, it didn't. Of course, Flatpak let me know that my user account didn't have the ability to configure the remote repositories the Foliate flatpakref specified. I could have searched for the right way to do it, but installing as root seemed to work, and it runs fine as a regular user, too!

But, of course, it doesn't. It doesn't have the ability to open files from most folders. I see by searching that you set sandbox permissions in an application manifest file, but I'm not sure I'm that attached to doing any more of this.

Installing it via "flatpak install foliate" didn't work? Downloading the .flatpakref seems like an unnecessary step to me but I'm on a different distro (openSUSE Tumbleweed).

edit: I can also open files from anywhere on my PC. Could it be that the flatpak on Debian Stretch is not correctly configured?

I'm pretty sure your edit nails it: flatpak on my moldy Debian doesn't work correctly as a non-root user, and the alternative of running it as root and then running the application as a normal user was neither intended nor foreseen.

I did finally install Debian testing, and it looks like the flatpak problems are resolved, but I decided not to bother installing foliate because of the nearly 700MB of dependencies it wanted over my rural satellite connection. C'est la vie.

I went ahead and burned the data: for Science! After the dependencies were all downloaded, it works correctly and completely. It's a fairly nice ebook reader application, and it only took three days and replacing my operating system to get it.

After cloning the project, all you should have to do is to ./src/main.js and the shebang should take care of the rest (running gjs, node, python etc).

Why complicate things? build-steps are the root of all evil.