appimage, flatpak, rpm or archlinux aur

[rezad1393]

I wanted to try this app but it doesn't have a x64 version of bianry for linux (not a deb one).

maybe a flatpak or an appimage would help users like me.

[qu1ck]

Flatpak is not viable for this app because of it's sandboxing behavior.

AUR package, rpm package, any other package is up to community to contribute because I don't use these systems regularly and can't invest the time to figure out all the packaging specifics of each one.

If someone wants to contribute, make sure you modify the build action to include the new artifact in the automatically generated releases.

But I will look into appimage as it seems that it should work and is at least useful for wide variety of distros.

[rezad1393]

I think flatpak is more work than appimage so.

it is just that for flatpak I just use a command to update all of them. but appimage is not easy to update.

btw I use that tremesof app and then added a folder with flatseal to access. so that sandbox is not that much of an issue.

[qu1ck]

Ok, so I tried appimage and if I build it on older ubuntu then it packages in buggy webkitgtk which does not render properly. If I build it on newer ubuntu then it is less buggy but will not work on anything with older libs which defeats the portability of the appimage. I suspect flatpak will have the same fate.

So, for now, self compile it is for linux users.

If anyone wants to experiment with appimage further, literally only change to enable it is to add "appimage" here

[rezad1393]

I am confused.

I thought appimage was almost self-contained. flatpak too.

so if I use new flatpak package on older os (like ubuntu 18) it would still work because it would take most of it libs and files from its own flatpak repo and not host.

maybe I am missing something.

[qu1ck]

No, it works with forward compatibility, even then, sometimes not. It almost never works in backwards direction. Appimage will not bundle your whole /usr/lib, it still relies on the fact that your client system will have compatible (which means same or newer) glibc, gtk and other core libs that make up the majority of GNU/Linux. Otherwise the image would be not 80mb but the size of half a linux distro.

Appimage instructions directly advise to build on the oldest possible linux you can support so that everything newer has a good chance to work because for the most part linux tries to maintain strict backward compatibility in core libs.

Unfortunately for TrguiNG even Ubuntu 20.02 which is not that old has buggy webkit so only viable appimage is from 22.04. Chances of it working on anything that is not quite recent are slim.

I'll still include appimage with next release, maybe it will be useful for some.

[rezad1393]

I think flatpak has more flexibility with respect to forward/backward versioning/compatibility.

[qu1ck]

I don't see how that is technically possible, you either pack literally every lib and get a 1gb bundle or you don't have backward compatibility, those are the choices.

Anyway, I added an appimage to the last release, it's built on ubuntu 22.

[rezad1393]

Anyway, I added an appimage to the last release, it's built on ubuntu 22.

thank you for the appimage.

but about that

get a 1gb bundle

you can search the internet and see you answer about flatpak size. like this: https://forums.linuxmint.com/viewtopic.php?t=275123

or this quote : "So how big are these runtimes? On a fresh machine, install KCalc from Flathub. You’re looking at a nearly 900 MB download to get your first runtime. For a calculator."

[qu1ck]

Great, so flatpak does indeed bring a whole new OS (sans a kernel) with an app. At least it's smart enough to reuse the runtime between apps when it can.

I looked more into building/publishing a flatpak and it's requirement for fully offline builds and lack of gnome 42 support which has libs needed for tauri introduces a whole host of issues. You can read more about it in https://github.com/tauri-apps/tauri/issues/3619 and linked issues/discussions. Some folks apparently found workarounds but I couldn't find any clear instructions.

Looks like this will have to wait until flatpak support is added to tauri (probably in tauri v2 which is currently in alpha).

[rezad1393]

I explain to myself flatpak as kinda like docker.

also having read this: https://theevilskeleton.gitlab.io/2022/05/16/response-to-flatpak-is-not-the-future.html#services I see this: "Most AppImage bundles need a big minimum requirement. They don’t bundle glibc or other core dependencies. Additionally, they might not even come with higher level dependencies bundled that would make an app actually functional without relying a lot on the host. Many of them will assume that some dependencies are already installed and have the right version on the host

This means that most AppImage bundles are not actually universal, and it gets harder to use them depending on the distribution you are using. If you are using a musl based distribution, the majority of AppImage bundles won’t work, because they need glibc. Likewise, if you use an immutable distribution, chances are they won’t come with many lower and higher level dependencies, because Flatpak already takes care of that. Flatpak is compatible in the majority of desktop cases. Even the Steam Deck uses Flatpak by default, because Flatpak ships with lower and higher level dependencies"

as that piece is written by a person defending flatpak model I would assume flatpak has more deps packages in its bundle (or its equivalent).

btw I use flatpak for some apps and it is useful.

for example steam game store. it has a lot of lib32 deps and I didnt want them installed on my PC so I used flatpak. steam itself is going toward containerization so it seems to work better and better with flatpak (and snap too maybe).

for a single app that usually doesnt need integration, flatpak may be too much and using an appimage for user is better.

a good thing about flatpak (that I like) is that app setting and data are in just one folder and unlike other linux apps-systems , they are not scattered everywhere on my home folder. kinda like android but even better.

I would recommend a appimage for users to download and test even if linux distributions later add this program, just so user can test this app before committing to installing it.

but for long term distribution, I actually prefer flatpak as it would give a universal experience for all linux dists. and it would make user life way easier.

if you are familiars with bottles app ( a wine env manager), its dev actually asked distro devs not to package its app in their repo and asks users to just use flatpak to install it. he says it makes his dev life way easier and I have to agree with him after reading its blog post. you can read it here: https://usebottles.com/blog/an-open-letter/

p.s. even steam deck uses flatpak as preferred way to install apps. "For those who don't RTFM (or the FAQ), it's stated that Steam OS 3.x supports using flatpaks as the preferred app install method"

[qu1ck]

I don't need more convincing that flatpak is useful and more universal. After doing the research about it I was already on the same page.

Currently it's just too hard to package a tauri app into flatpak bundle and write an offline build recipe that one can upload to flathub. Unless I find a (relatively) easy to follow recipe for tauri v1 we will have to wait until tauri v2 and native flatpak support.

[rezad1393]

oh. sorry about the rant.

hope you are successful with build later.

[qu1ck]

Note to self: this is a tauri project on flathub that I should be able to model flatpak build after. https://github.com/flathub/in.cinny.Cinny

[username227]

I have never done it, and I don't know if I can. But if nobody else is interested, I might be able to attempt to assist with the AUR. It would be interesting to learn the pkgbuild system. I already have an arch package that was created from your .deb which lists dependencies, etc. Of course, if anybody who has experience is interested in doing this, it would be better. but if not, I can try.

[username227]

PKGBUILD.txt

This is my first attempt. This file successfully built and created the package for Arch on my system. rezad, can you test this pkgbuild on your system? download it and remove the .txt extension, and then use the command makepkg. let me know what happens.

[qu1ck]

The app is now on flathub https://flathub.org/apps/org.openscopeproject.TrguiNG

[username227]

qu1ck - the one thing that won't work well is the desktop file. the app.desktop file in the src-tauri folder is pretty much blank. Is there any way you can incorporate the desktop file that we discussed here in place of the blank one to facilitate a more seamless desktop experience for the end user?

[qu1ck]

You can get full desktop file from here https://github.com/flathub/org.openscopeproject.TrguiNG/blob/master/org.openscopeproject.TrguiNG.desktop

Few notes on your pkgbuild:

• Get db-ip from releases page of this repo. Links from db-ip.com tend to die.
• binary should be executable install -Dm755
• License is AGPL-3.0

[username227]

OK, definitely do NOT use my PKGBUILD. it crashed my system. i'll try to figure out what's wrong.

[rezad1393]

OK, definitely do NOT use my PKGBUILD. it crashed my system. i'll try to figure out what's wrong.

in span of five hours. that escalated quickly.

[qu1ck]

Userspace program should not be able to crash your system. I doubt whatever caused your crash is directly caused by you misconfiguring the package, at best it just exposed a hidden problem that was already there.

[rezad1393]

Userspace program should not be able to crash your system. I doubt whatever caused your crash is directly caused by you misconfiguring the package, at best it just exposed a hidden problem that was already there.

yeah. like a graphic driver with amd

[username227]

PKGBUILD.txt

As a non-developer, this is a huge learning experience for me. It didn't mess the entire system up per se, but it did really mess up Cinnamon. I believe the problem was related to some missing "" around the install command parameters.

Anyway, this is my second version. I have changed the license, changed the source for the db as you suggested, and changed the permissions (which definitely were an issue). I have not yet worked on the .desktop file issue. That will be next. But this should be good for anybody who wants to test it on an arch-based system.

[username227]

PKGBUILD.txt

OK, here it is. a working package for Arch. I am now running this package instead of the manually cloned repository, saving me several GBs of space in my home directory. Download the pkgbuild file, take out the .txt extension, put it in a folder, and run:

makepkg sudo pacman -U trgui-ng-1.0.0-1-x86_64.pkg.tar.zst

I will try to see if I can figure out how to submit it to the AUR. I'm sure, being my first pkgbuild, that there'll be a hundred different opinions about ways that it could have been done better...but that's OK.

[username227]

The AUR is now operational. The package is here.

https://aur.archlinux.org/packages/trgui-ng.

[qu1ck]

Great, thanks for working on this. I gave it my vote :)

We should probably automate releases to update the AUR repo, there is a convenient github action for that https://github.com/marketplace/actions/publish-aur-package

Can you add me as maintainer on AUR? My username/email are same as on github.

[username227]

I think I did it. My pleasure. As I said, it was a great learning experience. i'll look into this automation next week unless you get to it first.

[qu1ck]

i'll look into this automation next week unless you get to it first.

No need, the action requires ssh key saved as secret in github, only I will be able to do that. That's also why I asked to be added as maintainer, so I could use my ssh key.

[username227]

I listed you as a maintainer in a commented line on the top of the pkgbuild. let me know if you want any changes to the format of your info (or you can also). Also, I successfully uninstalled the package i built manually and installed it directly from the aur using the yay command: yay -S trgui-ng

On a completely unrelated note - i didn't want to add a whole separate issue for this unless you want me to, but one feature request i'm wondering if it's feasible would be to add a torrent creator engine to the program. Possibly using dottorrent as a base, or something like that.

[qu1ck]

I listed you as a maintainer in a commented line on the top of the pkgbuild. let me know if you want any changes to the format of your info (or you can also).

That file will be autogenerated for each new version and it's not really intended to be viewed by humans anyway so it doesn't matter.

On a completely unrelated note - i didn't want to add a whole separate issue for this unless you want me to, but one feature request i'm wondering if it's feasible would be to add a torrent creator engine to the program. Possibly using dottorrent as a base, or something like that.

Have you clicked the button next to settings?

[username227]

I listed you as a maintainer in a commented line on the top of the pkgbuild. let me know if you want any changes to the format of your info (or you can also).

That file will be autogenerated for each new version and it's not really intended to be viewed by humans anyway so it doesn't matter.

On a completely unrelated note - i didn't want to add a whole separate issue for this unless you want me to, but one feature request i'm wondering if it's feasible would be to add a torrent creator engine to the program. Possibly using dottorrent as a base, or something like that.

Have you clicked the button next to settings?

LOL. Missed that.... :-)

[username227]

I listed you as a maintainer in a commented line on the top of the pkgbuild. let me know if you want any changes to the format of your info (or you can also).

That file will be autogenerated for each new version and it's not really intended to be viewed by humans anyway so it doesn't matter.

OK, makes sense. I was just following the archwiki for headers on the top.

[username227]

Perhaps i should figure out how to get the pkgbuild to clean up after itself - delete the git folder that's created to save over 2GB. No reason for a 17MB program to take up 2.2GB.

[username227]

FYI, I updated the pkgbuild in the aur with some technical fixes. it will now provide the latest release version, as opposed to the latest commit. If you'd like, I could possibly make a second one that provides the latest build as a -git package, development-type package. If you would apply the same type of automation to such a package, it perhaps could be updated automatically every time you apply a new commit.

[qu1ck]

I just added automation to update AUR repo when new version is released. We'll see how well it works when next release happens, I tested it as far as I could without pushing bogus updates to the actual repo.

If you'd like, I could possibly make a second one that provides the latest build as a -git package, development-type package

I don't know if there is user demand for this, if you want to add it - go for it. But it should not require automation, probably just remove sha sums checking (if it is allowed) and use "latest" instead of tag in the dbip url. It should just work.

[username227]

I just added automation to update AUR repo when new version is released. We'll see how well it works when next release happens, I tested it as far as I could without pushing bogus updates to the actual repo.

If you'd like, I could possibly make a second one that provides the latest build as a -git package, development-type package

I don't know if there is user demand for this, if you want to add it - go for it. But it should not require automation, probably just remove sha sums checking (if it is allowed) and use "latest" instead of tag in the dbip url. It should just work.

Right, removing the sha sums would not work, but it wouldn't affect anything, because the only differences would be in the git repository, (not the download of the dbip or the desktop file) and the git repository's sha sum is "SKIP". In order to get the latest, we just take away the version number completely from the source command and it will automatically clone the latest master. [in the main package, the package has a relative version number in the sources command; when you bump to 1.1.0, for example, that line in the sources command doesn't need to be changed; only the pkgver field needs to be changed.]

However, we would need to change the pkgbuild slightly so that it would trigger an update. In this case, I believe we would change pkgrel field from 1 to 2, and then to 3 for however many commits there are. However, you may be right about the demand, and even if we decide to do this, we should probably ensure first that the automation is working properly in the main package.

[qu1ck]

No, pkgrel is for packaging version only, when software itself changes the version should be updated. That's how version in dev builds works too, it looks like x.x.x-y-g<githash> where y is number of commits since x.x.x tag. That whole string should go into pkgver, but with hyphens replaced with underscores.

[qu1ck]

Just published v1.1.0, the AUR update job seems to work correctly. @username227 can you verify that build still works on arch?

[username227]

Just tested. Worked like a charm. Great job!

[qu1ck]

Great, so now this issue is just about rpm. Any fedora aficionados who would like to pitch in?

[username227]

I just added npm as a depencency and changed the pkgrel to 2. Please update on your end if necessary.

[qu1ck]

It is not needed at runtime and you already have node which ships with npm in makedepends so the change is redundant.

[username227]

nodejs has npm as an optdepends, not makedepends

[qu1ck]

Ok, then add it to makedepends, not depends.

[username227]

yes, that's what I did since you confirmed it's not needed at runtime, which I suspected. Thanks!

[username227]

error log The latest update did not update through the AUR. Attaching copy of error in the build.

[qu1ck]

Honestly I can't help much with debugging that build failure because I don't have arch. It complains about being unable to link something from libdbus even though the lib seems to be there.

Possible reasons I can think of:

• dbus is not listed as dependency in the build script. Not sure why it worked before but it should be listed.
• Updated gcc on your system changed behavior of symbol resolution, they planned to make explicit dependency listing mandatory so probably it needs -ldbus-1 flag or something like that but rust build system or dbus-rs build script doesn't provide it for some reason

What does pkg-config --libs dbus-1 print on your system?

[username227]

What does pkg-config --libs dbus-1 print on your system?

it outputs: -ldbus-1

[qu1ck]

As it should, so the lib is there and build system knows how to find it, I'm not sure why it is not on linker the command line. But absolutely nothing in the app code changed between v1.1 and 1.2, not even lib versions. So it must be rust version, gcc version or some other change. It compiles fine for me on debian 12 with latest rustc.

[username227]

The program compiles just fine when I do it manually. Only the script doesn't work. The only differences I can tell in the script are that it has "npm ci" instead of "npm install", but changing that didn't make a difference. The other difference is the place where we are downloading the mmdb file from. When I do it manually, i am using your wget command on github, but in the script we downloaded it from somewhere else.