Packaging solutions for Modrinth app (see pinned)

[honest cedar]

This forum thread is for discussion of theseus#497 "Linux (and Darwin?) packaging solutions". Ping me if you want to add something to the issue - I'll edit accordingly.

added a note near the top about this thread

[dark needle]

How'd you get the contributor role lol

[valid plinth]

not relevant to the thread

[cold dove]

nix packaging for linux and darwin is basically complete, just needs a few little touchups. i have flatpak almost working, but as it stands it would only be able to be distributed through flathub - only the website. this is due to no flatpak build tools supporting pnpm’s lockfile format; it’s a similar case with nix, but there are a few diy methods already in nixpkgs i was able to use so not an issue there. for flatpak, networking needs to be enabled during the build but that’s a big nono

i might know of a way to get a script for it that is currently private, but that’ll take a bit. plus, hosting the files on the website is fine for now imo. it’s what you have to do for the deb and appimage already, so this is basically a direct upgrade

only other “issue” is that tauri (or what i’m hoping to be only the specific version of tauri being used) is using an old version of webkitgtk to build so…i need to compile all of webkitgtk for it to work, which causes my pc to oom

i’ll probably end up inflating my swap, but in the future it’d be cool to update that if possible just for build times

[honest cedar]

thank you for your help getchoo

[dark needle]

I'd be fine with only Flathub. That was my original idea before Devin expanded upon the suggestion

[cold dove]

flathub wouldn't accept it right now because of that issue with pnpm i mentioned though

[dark needle]

Ah

[cold dove]

but yeah when i'm able to get my hands on a tool for it (or make my own lmao), idk why it would be anywhere else tbh

[dark needle]

Though I'd rather see the Modrinth team handle the Flathub stuff if you give them the tools you used for it

But unofficial packages would still be by non-MR staff

@cold dove

[placid sand]

pnpm's lockfile creates a lot of tension, wouldn't it be easier to commit package-lock.json into the repo? you can still use pnpm for local development with pnpm import. package-lock.json seems to be the most well-supported one

that is, if you won't get that private script

also, in tauri v2 (already on dev branch) they will upgrade to libwebkit2gtk-4.1, so all of that will go away

[livid tiger]

there's no pnpm export tho is there, this would be a lot more annoying to develop with, we also use pnpm features like patching

[placid sand]

there's no pnpm export tho
Yes, that's the problem. pnpm export is exactly what is needed to build the flatpak

we also use pnpm features like patching
ok i see

[cold dove]

the version in the runtime is 4.2, so sadly doesn’t fix the problem

and yeah for offline builds, using another lockfile would be better (theseus actually used yarn not too long ago, and how its how i originally packaged it for nix…made it a lot easier too), but i’d rather not bother upstream especially if the issues can be worked around

which has already been done in the nix package and has been proven to be possible with flatpak so i wouldn’t worry about it

for other packaging systems that do allow networking (makepkg for example), it’s a non issue. we should focus more on proper metadata there, rather than offline builds

that also reminds me: it’d be cool to have svgs of the logo available so they can scale on linux desktops, and also a 256x256 one since linux also likes to use that

[placid sand]

$ flatpak run org.gnome.Platform//44
$ ldconfig -p | grep libwebkit2gtk
libwebkit2gtk-4.1.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so.0

im actually hearing about 4.2 version of libwebkit2gtk for the first time

[cold dove]

wait so why did that build error out

i might’ve confused it with 4.0/4.1 though, i’d have to check again

[placid sand]

tauri needs 4.0, gnome platform ships 4.1, but in v2 tauri will need 4.1, everything will be fine

[cold dove]

W then

[placid sand]

I have made a working flatpak, i can share the repo

you need to compile webkit2gtk with libsoup2 for it produce libwebkit2gtk-4.0.so

[rich shadow]

@cold dove we can switch to npm if it helps with flatpack

we don't use patching unless in knossos

thank you for your work on this!!

[honest cedar]

^^^^^^

[livid tiger]

I'd still recommend making an issue about adding support for pnpm lock files in that flatpak build tools thingy. pnpm is really great for developers and I keep seeing more and more projects use it, so not supporting it is kinda yikes

[cold dove]

i think a good middleground might be going back to yarn. it’s just as well supported for both nix and flatpak (along with other tools), while still being better than npm for devs like pnpm

pnpm still on top though

[livid tiger]

yarn is terrible

[rich shadow]

npm isnt that bad

its pnpm > npm > yarn

[placid sand]

actually, there is this https://github.com/flatpak/flatpak-builder-tools/issues/361

[rich shadow]

also can't you just use npm for the build?

[livid tiger]

legacy yarn is completely bugged and should not be really used

[rich shadow]

while still using pnpm for dev

[cold dove]

no since they have different lock files

flatpak and nix basically do offline builds by collecting the urls, hashes, and paths of packages in the lockfile before the build starts

so they need to have something that can grab all of those sources from the specific lockfile

[livid tiger]

is there a way to run npm installs which do update pJson and lock file, but do not actually install anything

if pnpm import isn't buggy and there's a way to do above, then it can be pretty easy

[cold dove]

i think it does that with the update command but idk

i don’t use node a lot lol, let alone npm

[cold dove]

no one uses yarn v3 though

[placid sand]

oh ok then

i thought it is the current version

[cold dove]

it is but you never see it

it’s really weird

[livid tiger]

npm install --package-lock-only !!!

it updates both pJson and lock file but doesn't install anything

and then pnpm import

[placid sand]

That will generate new package-lock from package.json, it won't respect dependency versions in pnpm-lock.yaml. dependency trees are so fragile, that those changes in minor version will probably break a lot of stuff. you will (probably) need to tweak it by hand to make it build with npm

[dark needle]

Sheesh lol, didn't know Flatpak was so complicated

[livid tiger]

what I'm trying to achieve here is that npm is used for building, but devs can use pnpm for the most part, this package-lock-only does indeed create package-lock.json at first, but then it just updates it iiuc, and then you just pnpm import the updated lock npm file

I'm not sure if pnpm import tries to match the tree in package-lock.json, it would be stupid if it doesn't

​
package.json, package-lock.json

• actual files responsible for preserving the dependency tree
• committed to the repo
• used for building (on CI)

pnpm-lock.yaml

• created locally using pnpm import
• stays on developer's machine

when you need to add or update the dependency you do npm install --package-lock-only [dep] && pnpm import && pnpm install (or npm update)

[rich shadow]

why not just use npm entirely then lol

[livid tiger]

to get the DX benefits of pnpm

[rich shadow]

if its used for building you don't get the benefit of the symlink stiuff

[livid tiger]

like file deduplication and faster installation times

[placid sand]

you would also need to change "beforeDevCommand" and "beforeBuildCommand" in tauri.conf.json

[livid tiger]

I meant building as CI

[cold dove]

it’s the only way to really guarantee safe builds

you should see nix though, it’s horrifying but also very clever and nice to use all at once

[livid tiger]

to be honest, this is probably not necessary, you can also just pnpm import && pnpm install on CI too when you want to, e.g. for caching

so if you do flatpak stuff, you just use package-lock.json, if you do development then you do pnpm import && pnpm install

[dark needle]

Huh

MC is on Flathub surprisingly, but iirc Devin says its an otdated version

[honest cedar]

It's unofficial

[dark needle]

Says its by Mojang

[honest cedar]

It hasn't received an update in around a year

[honest cedar]

The wrapper isn't

The launcher itself is, but the package is not maintained by Microsoft

[honest cedar]

Yeah, the launcher is, but the wrapper (package) is not maintained by them

This is the same for stuff like spotify iirc

[dark needle]

Why's it say its by them then

[valid plinth]

yeah guys I made it

[dark needle]

LMFAO.

[honest cedar]

They would have the Flatpak on the linux download page on the MC website if it were official

[livid tiger]

excuse me?

[dark needle]

They do have a .tar on the download area on the MC site, though

[honest cedar]

Yes, that's not related to the flatpak though

[dark needle]

Ik, just saying

Seems a bit pointless in posting an MC wrapper on Flathub, then not maintaining it

Not sure what they thought

[honest cedar]

Also, on the git repository:

[honest cedar]

It seems like the github repository has recieved commits in the past two months, just the Flathub package not getting updates for some reason

Anyways this is getting off topic from the thread

[dark needle]

True.

[next moat]

@honest cedar if there's only one universal mac app, why is there two download buttons? one for x86_64 and one for arm?

the downloads download the same thing ;-;

[cold dove]

👀

[honest cedar]

🎉

[cold dove]

now should i also upstream my nix packaging?

at the very least it'd be cool to have reproducible builds for mac

less to maintain too since it's like two hashes to update when lockfiles change vs literally remaking all of cargo.lock into a json file and updating flite, pnpm, etc in the flatpak

[dark needle]

So is this Flatpak stuff unofficial

Or will you give it to the Modrinth team

@cold dove

[cold dove]

i try to upstream anything i do, so yeah i've already made a pr lol
https://github.com/modrinth/theseus/pull/559

imo things like flatpak (which should be the primary distribution method), should always be in the hands of upstream since it's their project after all

distro specific stuff is more of a community thing since there are just wayyy too many and users of them probably know more about the little differences in packaging compared to other distros

[dark needle]

Ah

Jesus 7k lines lol

[cold dove]

yeah 7.5k of it is just the dumb json files flatpak requires you to make

[valid plinth]

separate PRs but yes

[cold dove]

made me miss nix since that can just download all of the deps automatically given the file

[valid plinth]

unless you've already put it in that one pr

[cold dove]

no i haven't yet lol

[valid plinth]

worth noting that while the code is GPLv3, none of the branding is

I'm not sure if you have to update the license info to account for that

[cold dove]

usually it just goes by source code license

i also don't know if flatpak even supports multiple lol

would you consider it redistributable though? or fully non-free?

[dark needle]

oof

[valid plinth]

well you can redistribute it freely mainly because we give you permission to as part of a distribution of the app

[cold dove]

ah cool, nix has a perfect license thing in the library for that lol

[valid plinth]

dammit, nix ||xkcd378||

[cyan palm]

I'll go ahead and create an AUR package now :)

What I need to know is what dependencies modrinth requires at runtime, and what dependencies it requires at compile time (other than rustc/cargo)

[cold dove]

you can see them in the nix pr

everything inside of buildInputs in the file distribution/default.nix is for theseus. distribution/wrapper.nix contains dependencies for minecraft itself, and those are in preFixup iirc

you can also copy some of prism’s, since it’s going to be the same thing

wait i forgot there are already aur packages

but uh…yeah they’re very bad

i would recommend making a patch for them and emailing it to the maintainer or putting it in the comments. it seems like they need a lot of help

[cold dove]

this patch should (probably) work
edit: bad pkgbuild lol, haven't used arch in a bit. see the next one 🫠

oh and add git to makedepends, i forgor

[cold dove]

the last line for the desktop file is commented since it won't exist until #559 is merged

[shadow kite]

as I understand it, you are working on the flatpak. Do you test it publicly so it can already be used or do you only publish it when it's stable

[cold dove]

you can test it now by building it yourself from the pr i made in the app’s repo

[dark needle]

Glad packaging is being taken more seriously now

Thank god I made that Flatpak suggestion lol

[cyan palm]

does anyone here have an arm device?

need someone to test something out really quick

(unrelated to modrinth, just require someone to test something out)

[cold dove]

this probably isn’t the place for it then

[cyan palm]

right

[hazy stream]

Hi,
I'm trying to make Gentoo ebuild for theseus. Compiling works the resulting binaries do start. However the gui doesn't want to process past the Modrinth login screen. It just hangs.

Have you encountered such problem? Or may be if you have suggestion about a solution?

[cold dove]

i would check your dependencies against the nix package here
https://github.com/getchoo/theseus/blob/flake/distribution/default.nix

you will probably also want to include minecraft deps, which are listed here
https://github.com/getchoo/theseus/blob/flake/distribution/wrapper.nix

[hazy stream]

thanks, I will need to set all of thses as dependencies, but it looks like I have all of them.

is there a way to enable debug logs so I can see at what point exactly the process hangs.

Gentoo unstable is pretty much bleeding edge when it comes to packages versions so may be I have something too new

[cold dove]

cargo should be telling you most of them

the biggest issue is probably going to be webkit with the 4.0 abi, since tauri requires that but it's not really used all too often anymore

there are some others like libsoup and librsvg that are similar iirc

[dark needle]

Been a bit, anything new?

[cold dove]

oops just saw this
basically i tried to update the runtime for the flatpak to gnome 44, but it causes gha and even my own machine to oom; so with that and bigger dependencies like webkit needing to be bundled anyways, i’m sticking to gnome 42 for now. this weekend i’m going to try to work with some of the maintainers to get basic packaging guidelines going and hopefully everything will be good on my end. after that, bundled flatpaks should be able to be uploaded to the website and once offline builds are sorted out, then it’s to flathub

[dark needle]

Can’t you use Git actions or Jenkins to build everything?

[dark needle]

Didn’t know Flatpaks were so annoyingly hard to make, lol

[honest cedar]

They talked about how it causes GHA to OOM

So no

[dark needle]

My god, Flatpaks are impossible to build

[honest cedar]

Flatpaks aren’t hard to make in most cases

[dark needle]

Why does it OOM anything it’s built on then

[honest cedar]

Probably due to how complex theseus and it’s packages are

[dark needle]

Huh

Well, Getchoo might wanna make an issue about this if he/she can’t get it to build, since it seems nothing can build it without OOM-ing

[cold dove]

it’s nothing to do with the modrinth app or flatpak, it‘s because of webkit

if we were to use the gnome 44 runtime, we would need to compile it ourselves

[dark needle]

Why are you using 42 then?

42 and WebKit seems utterly useless if it can’t be used

[cold dove]

what?

i think you’re misunderstanding what i’m saying here. gnome’s runtime (which includes webkit and other dependencies for the app), has a fairly new version of webkit by default in version 44 of the runtime. modrinth app doesn’t like this - so if 44 were to be used, an older version of webkit needs to be compiled and bundled with it for everything to work. compiling webkit causes even gha to oom though, so instead we can use version 42 of the runtime, which has the exact dependencies modrinth app needs at the correct versions, without the need to compile extra stuff really

[dark needle]

Ah

Was mentioning you opening an issue about them updating the required stuff so you could use the stuff that wouldn’t OOM on you

[cold dove]

tauri v2 where webkit has been updated is still in alpha, so kinda pointless to atm

plus gnome 42's runtime "just works" anyways

[lavish relic]

hi, im this guy, even though my name has been misspelled for the millionth time
anybody mind telling how they are broken / what they depend on

because i have a classic case of works on my machine ™️

and ig i could link my question in #modrinth here
#modrinth message

[lavish relic]

according to this github comment/patch ive adjusted the dependencies for modrinth-app-bin for now

[honest cedar]

@cold dove would probably be able to explain what was missing better than I could

but yeah, i’ll update the issue

fixed 👍

[cold dove]

in the future, you should attempt to build aur packages following this guide, using aurutils, or the chroot option in paru. this is because makepkg has no sandboxing during builds and will use anything installed on your system regardless of it being a dependency of the package or not - which makes it much harder to track down these types of issues. not much you can do for runtime deps though sadly

[lavish relic]

ooh i havent seen this wiki article before

good to know (though yeah build deps dont really matter for things like -bin)

[lavish relic]

so i just wrote a shell line

for lib in $(readelf -d $(which modrinth-app) | grep NEEDED | awk -F " " '{ print $5 }'); do pacman -Qo /usr/lib/${lib:1:-1}; done | awk -F " " '{ print $5 }' | sort | uniq

which theoretically should output a list of packages that the binary directly depends on

[dark needle]

@cold dove @honest cedar Thought I'd ping since Gnome is mentioned a lot. Would be nice if there was a Gnome-like theme for the app, whenever this Flatpak issue gets figured out

[cold dove]

yeah this has about the same effect as using a sandbox, but i would still look through the nix packaging for the runtime deps. there are some missing here such as librsvg, dbus, freetype, libappindicator, and ofc mc's deps

[honest cedar]

This isn't related to the thread's topic at all, but yeah I might consider making an adwaita theme for Theseus

It was one of the first things I wanted to do when I saw the app

[cold dove]

im surprised you got anything out of that binary at all btw...most rust binaries will only really have linking info like this with ldd since a lot is statically compiled

    linux-vdso.so.1 (0x00007fff19755000)
    libc.so.6 => /nix/store/ibp4camsx1mlllwzh32yyqcq2r2xsy1a-glibc-2.37-8/lib/libc.so.6 (0x00007f7ae1fe5000)
    /nix/store/ibp4camsx1mlllwzh32yyqcq2r2xsy1a-glibc-2.37-8/lib/ld-linux-x86-64.so.2 => /nix/store/vq3sdi8l15rzfl5zvmwpafrzis4sm6xf-glibc-2.37-8/lib64/ld-linux-x86-64.so.2 (0x00007f7ae21cd000)

[cold dove]

also afaik tauri has no native support for theming

[honest cedar]

they couldn't implement custom css? sadge

[dark needle]

Ah, didn't know you planned on doing so, oops

[lavish relic]

dont we only care about dynamic links anyway, because static link are included in the binary? no need to depend on their dynamic versions
(excuse my compiled languages knowledge i use interpreted and bytecode languages)

[cold dove]

rust is a little weird with how it links to libraries. for some things like gtk, openssl, etc, they won't appear in ldd but still be required

plus other dependencies (like those for mc) won't be looked for at all in the build process, but will be called at runtime ofc

[lavish relic]

rust magic smh

[lavish relic]

on mc deps im a bit on edge, because technically they are not dependencies of modrinth app, they are not required at the runtime of the launcher, for example prism launchers package doesnt include those

(think steam including deps for all the games)

[cold dove]

prism does

i would know, i maintain them :p

some like xrandr are optional though

but frankly a minecraft launcher that can’t launch minecraft ootb isn’t too great imo

[lavish relic]

doesnt it just have like java and maybe glfw or whatever that funny graphics thing was

[cold dove]

it does, but it also has all of the x/gl libraries specified through the qt packages

prism gets all of those same packages because it’s dependent on those. the ones currently in the modrinth package just explicitly state it

[lavish relic]

i see, isnt it bad to depend on transitive dependencies though :D (also confusing)

[cold dove]

glfw, openal, and visualvm are also not applicable to modrinth-app btw - since it doesn’t really have the ability to use them. jre 17 and 8 could also be made (optional) dependencies as well, since some might prefer to have the jre managed by pacman rather than the app itself

[cold dove]

yes, which is why for the modrinth patch i made them explicit. it’s mainly based on the nix package we support upstream, which made it easy for us to pinpoint exact deps (you can see this in the flake pr for modrinth as well). i’ll probably backport these changes eventually to the prism packages, but for now i won’t try to fix what ain’t broke /lh

[lavish relic]

ugh solving this dependency tree really is a mess,
for example just depending on webkit2gtk resolves a lot because that depend on things like gtk3 and cairo which depend on things like libx11 librsvg

how do package maintainers with hundreds of packages cope with this

[cold dove]

generally packages of the same type have the same dependencies
so for example all minecraft launchers will have all the same dependencies - at least for minecraft. this is the case with prism and modrinth where i was able to just copy and paste some. things like this are also usually documented to make it easier

some tools can also make this easier by ensuring the environment your package runs and builds in only has the dependencies you listed

[honest cedar]

if it allows you to, could a moderator pin this message?

if it doesn’t let you then pin this one with a link

theseus#497 "Linux (and Darwin?) packaging solutions"

[honest cedar]

thanks braw 👍

[rich shadow]

https://github.com/modrinth/theseus/issues/497#issuecomment-1699730844

[dark needle]

@honest cedar @cold dove ^

[honest cedar]

.

[rich shadow]

oh yeah

yarn sucks

[cold dove]

thanks for letting us know! i left my response there already, but i also wanted to bring up the second task in #559. i was wondering if you and the other maintainers want to make a little readme or explain some of the stuff you all want so i can make a draft? seems to be about the only thing left on the pr side besides ensuring the bundled flatpaks can make it on the site :p

oh also this needs a bit of attention. it blocks offline building as a whole, which in turn breaks both flatpak and nix builds currently

they'll need to be rebased after to update the checksums and everything, but that's pretty easy

[dark needle]

Huh, this didn't take as long as I thought it would

Thought it would've been like, 6-8 months or something with the Gnome 42/44 issues

@cold dove Btw, didn't you still have build issues, or did that get fixed somehow

[cold dove]

i went back to the gnome 42 runtime so it doesn't need to really compile anything

makes build times pretty normal and 42 is a good fit with it's versioning

it'll work and it's still used by other projects, but it's really not best practice since it isn't supported anymore

[dark needle]

Thought it OOMed everything

[cold dove]

nix and other formats shouldn't have this issue though with their bigger (pre-built) repositories

gnome 44 did because of webkit

[dark needle]

Ah

My bad, thought it was 42 that did

[cold dove]

oh yeah speaking of nix, the maintainers should probably make a cache at some point

it's basically a free pre built repository you can get by approving a github app and adding a secret to gha

works really well for people who want to use dev builds, and it would make it easier to use in general

[dark needle]

Well, hopefully this Flatpak stuf'll get sorted at some point

[cold dove]

we can also publish that on flakehub later on (flathub but for nix basically)

[dark needle]

Huh, never heard of that before lol

@honest cedar Btw ^

Could publish your stuff there

[honest cedar]

i don't really have any flakes to publish there though?

i have my personal flake for my system and that's about it

[dark needle]

Thought you had nix configs and such

[honest cedar]

.

[dark needle]

Ah

[cold dove]

you can publish your system configs on there

pretty much anything that's a flake

[honest cedar]

i'm aware, i just don't really see the need to do so in my case lol

[cold dove]

it's supposed to be a general place so you can find them, so apps, overlays, libraries, frameworks, configs, tools, random nix projects, and even nixpkgs itself can go on there

[cold dove]

ah makes sense

[haughty parrot]

modrinth having better linux support will make it extra more relevant than curseforge (even if it already was)

[dark needle]

Agreed

I plan on moving to Fedora at either the end of this year, or or sometime early next year

Not 100% sure yet

[south spoke]

I've been starting to use Linux more and it turns out that the official download links arent particularly good

Actually you know what i probably shouldnt complain about this here

According to this comment, the current compiled Debian packages aren't very great right now because they don't include proper dependency info and leave out some important stuff.

Ah, it was noted already lmao

[dark needle]

This is why I made the initial Flatpak suggestion, but @honest cedar expanded upon it. Now we have this thread

[south spoke]

this is just annoying lol, and i did end up asking for help in #1151680646989762643 but now that i look into it, yeah

wish these dependencies were expanded upon in the issue

i might toss it into the thread

[dark needle]

.

[south spoke]

thats not exactly what im getting at though

im noting the fact that there needs to be some sort of list somewhere of these dependency issues

so that if something, like flatpak or just a revised debian package, comes along, it should have that

[cold dove]

the nix pr is the best example atm

there's also the patch for the aur

[dark needle]

And Flatpak? No idea what is going on with packaging formats at this point, this thread has been kinda dead for awhile

[south spoke]

it would also be really important to note that there would probably have to be linux only features

like using discrete gpu

although now that im looking into how prism does it i think you can just. do it manually lmao

[cold dove]

flatpak is bad for getting examples of dependencies imo since (ideally) most dependencies are not explicitly listed but are instead included in the runtime

[dark needle]

Ah

No idea what is going on with packaging formats at this point, this thread has been kinda dead for awhile

[cold dove]

my prs are basically done, just waiting on the maintainers

i did notice the cargo.lock issue was fixed now though

but the issue was never closed or linked

[dark needle]

So gtk44 now?

[cold dove]

no, tauri wasn’t updated

[dark needle]

Ah

[cold dove]

only building offline at all was (which tbh i have no idea how that wasn’t caught in ci)

[hasty wyvern]

Well, some of them are still listed because you end up sharing runtimes and whatnot. But yeah a lot of stuff gets bundled

[honest cedar]

Packaging solutions for Modrinth app (see pinned)

@cold dove I wonder if including scoop and winget in this issue would be a good idea

I use both quite often

[cold dove]

yeah i think those could be looked into

winget is easy to automate and i have experience with both so why not

i wouldn’t consider it a major priority right now though since tbh it’s a bigger niche than linux support in general

[honest cedar]

yeah, i’ll note that in the issue

[dark needle]

Has anything been going on lately?

[haughty marsh]

made a comment on GH regarding scoop packaging, still not entirely sure if it's correct or not but I'm pretty sure it is?

[dark needle]

scoop?

Dfuq

[haughty marsh]

https://scoop.sh

[dark needle]

Winget exists

[livid tiger]

scoop is designed for CLIs

however there exist buckets for other software

[haughty marsh]

like the included extras

[honest cedar]

What’s wrong with scoop lol

[dark needle]

WinGet s also usable via CLI afaik

[honest cedar]

Winget is a cli tool, but it’s not perfect

I far prefer scoop

[dark needle]

Ah.

[honest cedar]

And while scoop is designed for installing CLI tools, it works for other stuff aswell

All winget really does is grab an installer from the internet and silently run it

Scoop does it in a similar way, but it installs applications to it’s directory in the user home, and tries to prevent things like path pollution

There’s many buckets for different software and it’s quite easy to package with it

[dark needle]

buckets?

(ik what these are, i'm not dumb lol, just not in scoop's term)

[honest cedar]

Scoop package repos are called buckets

[dark needle]

Huh

[honest cedar]

Like any other package manager repo

[dark needle]

Ah

[honest cedar]

@cold dove think you said you had experience with Scoop, what should I improve on my package? Or do you think it would be ready to be PRed into the nonportable bucket?
This is one of my first packages so it's a little rough, but it does seem to work perfectly on my end.

{
    "version": "0.5.4",
    "homepage": "https://modrinth.com/app",
    "description": "A unique, open source Minecraft launcher that allows you to play your favorite mods, and keep them up to date, all in one neat little package.",
    "license": "GPL-3.0-or-later",
    "architecture": {
        "64bit": {
            "url": "https://launcher-files.modrinth.com/versions/0.5.4/windows/Modrinth%20App_0.5.4_x64_en-US.msi#/setup.msi_",
            "hash": "1e76d65929976fe4f9e0b45487b4f559be1760c70510e94ef336deb068c3b950"
        }
    },
    "installer": {
        "script": "Start-Process msiexec -ArgumentList @('/i', \"`\"$dir\\setup.msi_`\"\", '/qn', '/norestart') -Wait -Verb RunAs"
    },
    "checkver": {
        "url": "https://launcher-files.modrinth.com/versions/latest/windows/Modrinth%20App",
        "regex": "href=\"[^\"]+/versions/([\\d.]+)/windows/Modrinth%20App"
    },
    "autoupdate": {
        "url": "https://launcher-files.modrinth.com/versions/$version/windows/Modrinth%20App_$version_x64_en-US.msi#/setup.msi_"
    },
    "uninstaller": {
        "script": "Start-Process msiexec -ArgumentList @('/x', \"`\"$dir\\setup.msi_`\"\", '/qn', '/norestart') -Wait -Verb RunAs"
    }
}

It does install and uninstall fine, but I'm not sure if I got the autoupdate part correct

[livid tiger]

can we bother moderinth staffers to make it portable, like it's probably not that hard, just use . (or whatever user passes with argument like --workingDir) instead of %AppData%

🐸

[honest cedar]

I’ve now added my scoop package to the issue

lmk if it should be improved (maybe make a PR?) it probably can be

[cold dove]

the installer/uninstaller thing shouldn't be needed, just the url

for autoupdate you will need to also have the url nested under architecture.64bit like you do at the top of the file

and in checkver you should use "github": "https://github.com/modrinth/theseus" since tags are published now

[honest cedar]

how do i make it so that it runs as admin then?

since the modrinth app installer requires elevated perms

[honest cedar]

ok so i added this:

    "shortcuts": [
        [
            "PFiles\\Modrinth App\\Modrinth App.exe",
            "Modrinth App"
        ]
    ],

and now it installs perfectly fine

here's what i have now

{
    "version": "0.5.4",
    "homepage": "https://modrinth.com/app",
    "description": "A unique, open source Minecraft launcher that allows you to play your favorite mods, and keep them up to date, all in one neat little package.",
    "license": "GPL-3.0-only",
    "architecture": {
        "64bit": {
            "url": "https://launcher-files.modrinth.com/versions/0.5.4/windows/Modrinth%20App_0.5.4_x64_en-US.msi",
            "hash": "1e76d65929976fe4f9e0b45487b4f559be1760c70510e94ef336deb068c3b950"
        }
    },
    "shortcuts": [
        [
            "PFiles\\Modrinth App\\Modrinth App.exe",
            "Modrinth App"
        ]
    ],
    "checkver": {
        "github": "https://github.com/modrinth/theseus"
    },
    "autoupdate": {
        "architecture": {
            "64bit": {
                "url": "https://launcher-files.modrinth.com/versions/$version/windows/Modrinth%20App_$version_x64_en-US.msi"
            }
        }
    }
}

[honest cedar]

i've pushed this new manifest to my bucket

it seems to work fine on my end but if someone could test it that'd be great lol

is there a way I could somehow stop the app's updater from running?

[cold dove]

@rich shadow hey sorry for the ping but i've been meaning to bring this up for a bit and i know you were interested in this

recently i've noticed way longer build times for the app, getting to the point where the ci i use for building the app on nix (which lets people easily install it for mac/linux without compiling) appears to just OOM. you can see a log here for an example where the build times out after 120 mins

going through my logs, it seems like this was introduced sometime between the merging of #445 in 5f0d44a and the merging of #703 in 1e8852b (or in dates, between 08/06 and 09/12). here is a log for earlier 5f0d44a commit where the build phase was only 8m, and here is a log for the later 1e8852b commit where the build phase shot up to 1h12m. build times even on my personal machine are also nearing the one hour mark

at first i thought this was maybe something i was doing in nix, but it seems like this is just what happens when the rust crates aren't cached. this is even reproducible in your ci under the same commit (and i'm assuming future commits as well, but they are cached now so i can't tell) as shown here

im really hoping to get this fixed since these long build times make it very hard for packagers to distribute binary releases, test their changes, etc. in sandboxed environments - which is where most modern packages are built, like nix in this case but also flatpak and even traditional package formats like rpm

[rich shadow]

I believe build times are long due to a tauri bug

[severe rock]

that's...... vague. I mean rust build times being long is no surprise but I believe this is unusually long for a project this size
do you have a link to the tauri issue or sth?

[rich shadow]

yes don’t have it on me but check thesuzerain’s gh he has an issue in their repo with a minimum repro example

[cold dove]

i’m guessing this is it
https://github.com/tauri-apps/tauri/issues/7073

the only problem is that this was reported back in may, a good 4 months before anything like this really had an effect on the app

[rich shadow]

it's because we fixed it internally by restructuring a bunch of methods

but then some pr added something causing the bug again

and we decided it was more effort than its worth to not cause the bug

[round peak]

Is the flatpak in development ? Do you guys need any help ?

[shut lava]

Why no rpm for Fedora/OpenSUS/RHEL?

[valid plinth]

It's on the issue

[cold dove]

i’ll probably make one eventually since it’s the system im most familiar with

im just waiting - and think others probably should too - until packaging is merged upstream so no weird breaking changes need to be made based on upstreams practices and recommendations

plus the two formats being up streamed (flatpak & nix) give compatibility to all linux distros and even macos, so they’re a bit more important rn

[cold dove]

small update: nix builds for intel macs are now cached!

this means you can run nix run --accept-flake-config github:getchoo/nix-exprs#modrinth-app and be able to use the app without compiling

and besides making things a bit easier for people, this also allows me to keep testing this packaging on my pretty old macbook air (thanks github actions :p)

i plan on making PR in nixpkgs soon as well, but hopefully not before https://github.com/modrinth/theseus/pull/561 is merged lol

[pulsar mortar]

heyo!

I am building the modrinth app on my system to investigate wayland support, and noticed a weird thing. Is this the right place to ask about building?

essentially, I noticed that the build I produce on my system is completely different than the distributed AppImages, for the same exact version

[lavish relic]

how different is 'completely different'

[pulsar mortar]

the binary sizes are different: 79MB for the downloaded version, and 97 for the locally built

and the downloaded version does not run

instead it fails launching with (modrinth-app:198831): GLib-GIO-ERROR **: 17:33:19.576: Settings schema 'org.gnome.settings-daemon.plugins.xsettings does not contain a key named 'antialiasing'

https://github.com/modrinth/theseus/issues/941

I don't seem to be the only user with issues

[cold dove]

this could be the result of a ton of different things, like what flags you're using, the toolchain, dependencies, etc. the app doesn't have reproducible builds atm, so things like this are pretty expected

[cold dove]

this is probably a dependency issue. the only good way around it is to build the app yourself with your system's libraries

[lavish relic]

am i the only one that gets slightly annoyed that even though a new version gets released (v0.6.3) there is no git tag or release of it...

i depend on that to get a notification of a new update and pkgbuild depends on it to fetch the source for the correct version

[cold dove]

it’s been mentioned before #modrinth message

the team seemed to be doing better with it, but i noticed the bump from the auth pr as well and i’m not really sure if that’s meant to be a stable release and it wasn’t tagged, or if we’re still waiting on an official 0.6.3

[valid plinth]

@rich shadow

[lavish relic]

i think its pretty "official" when the download on the website is 0.6.3

[cold dove]

it is?

[valid plinth]

I'd create a tag if I knew which commit 0.6.3 uses but I don't know for certain which commit

[pulsar mortar]

this is quite annoying as AppImages are supposed to be a "build once, run everywher" type package

and it also means the official modrinth download is broken for hundreds of users currently

but I didn't know modrinth didn't have reproducible builds yet, my bad

Is it possible to know what configuration is used currently to build the offical AppImage?

[cold dove]

it got bumped here. i wouldn't mind having the latest commit (ef8b525) just being the tag though since that's only change after the initial bump and it's a bug fix

[cold dove]

sadly they aren't though, and they never really will be. flatpak is much better system for that

[cold dove]

that's why this thread exists :p

[valid plinth]

can someone test if CF profile importing works haha

[cold dove]

you would have to look into the generally horrific black box that is tauri-action
i wouldn't recommend it though since their packaging support isn't great as is, and it will also never install the deps required to play mc either

[cold dove]

i was about to, only to realize you meant the launcher profile thing and i have never used that in my life

[pulsar mortar]

true lol, i'll take a look but the general vibe i get from the situation is "appimages bad and we're waiting on tauri support for flatpak to get better" which is fair

[pulsar mortar]

thanks!

oman, ok i caught up with the situation and draft PR. Oh well, time to wait.

[cold dove]

yeah this is a good way to describe the state of supporting multiple distros

there is a fully working nix pr though that is currently (or at least last i checked) based against latest master

which should let you build the app really easily on any distro - plus it’s reproducible :p

[rich shadow]

it's the ;atest one

[valid plinth]

created a tag for it

[dark needle]

@cold dove @honest cedar

Sorry for the pings, this thread's been pretty dead for a while

[cold dove]

i would use any of tauri's upstream package generation honestly

it doesn't fit the app well and will require manual editing anyways

[shadow kite]

Is there any flatpak progress?

[cold dove]

it's basically done for now. just waiting on the team to setup a way for it to be distributed on the site and hopefully get some general packaging guidelines in order

[rich shadow]

pr?

[cold dove]

https://github.com/modrinth/theseus/pull/559

[rich shadow]

can flatpak be made into aur packages as well? or is that separate?

Is distribution/cargo-theseus-sources.json autogenerated? how do we keep it up to date?

[cold dove]

no, flatpak is its own format

but it is compatible with arch still

[cold dove]

yes, you use this script whenever cargo.lock is updated

[rich shadow]

is there a way to autonate it? why not just generate it during the action

[cold dove]

i could make a workflow that would update it when the path is changed, but i wouldn’t recommend only generating it during the build workflow since then it would be a pain to build it outside of ci

[strange cedar]

ooo yes this is really exciting. Looking forward to it!

Didn't think it would be remotely possible so soon due to the aforemention tauri conflicts

[cold dove]

the only issue with tauri conflicts is that we're using an outdated runtime, since tauri is also using a pretty outdated version of webkit on linux

[dark needle]

Couldn't you PR a more updated version?

Might be a pain but asking in case

[cold dove]

they’re already doing it in tauri 2.0

[dark needle]

Ah

[cold dove]

update: i think i might have found a way to get the app on flathub without rolling my own pnpm lockfile parser...it's just bad

ideally we would want to build from source, but since we need to do that offline (flathub rule) and know the hashes of the pnpm deps ahead of time (not currently supported), that isn't an option

but we could use already compiled binaries as sources, like the vesktop package does here
this is bad practice for basically any linux repo, but they probably did it for the same reason as us: lack of pnpm support

we would still be locked to an outdated runtime because of the issues with tauri mentioned before, but this could still fill the gap between the working binary of the appimage and proper packaging to actually make it work

the only issue is that this wouldn't really work for in-tree builds since there wouldn't be an appimage ahead of time to source
for that though, we could just use the current pr and not have any issues since we're ofc not limited by flathub's rules

[cold dove]

a benefit of this would be dropping the sources file here, since again, no limit on network access during builds (even though it's sorta bad practice again, but honestly cargo's own lockfile is enough and this whole process with flatpak is super annoying)

[dark needle]

You could give them some feedback about the issues

[cold dove]

im saying that our dev builds would be using a bad practice

but that it's mostly fine since we already have solid lockfiles anyways

and could have safer/reproducible dev builds anyways with nix. the dev build flatpaks would just be a way to make sure nothing broke in that runtime

[cold dove]

i have a working manfiest with this now

[cold dove]

this was also implemented

[dark needle]

@cold dove https://www.youtube.com/watch?v=kYqYpbMY9vE

[cold dove]

yeah i saw that, seems like a good way to make discovery better on flathub

i'll make sure to keep it in mind when i make the final pr

[round peak]

the video is such clickbait

literally no one else complained about the new guidelines (and most of them are optional! )

[shadow kite]

I actually think the guidelines are good. it helps the developers to ensure that the software is well received and doesn't flop.

[dark needle]

Ah whoops, sorry for the ping then

[marble coyote]

Just curious, anyone have an update on some what of a timeline on when the flathub deployment will be ready? If not, is there anything I can do to help? I'm currently trying to get this installed in Fedora and have been STRUGGLING and the AppImage creates a bunch of problems for me. Theseus works GREAT on Arch with an install from the AUR. Currently struggling to compile it from source with the horrible documentation provided for the app on the topic.

[cold dove]

a flatpak can be built on the PR branch right now. im waiting for the maintainers here to give feedback on it though, since some of the stuff should be upstreamed (desktop file for example) and i’d rather not have to go back and try to sync them up by getting it on flathub first

[dark needle]

Well, its been taking ages apparently

[worn schooner]

I am quite motivated to package the modrinth app in Nixpkgs. Primarily, its a rust project. Therefore the packaging workflow is very similar to any other app using rust. The relevant design decision when packaging is whether to package it as a flake or in the repos. Both has benefits and issues.

• Packaging as a flake: The flake can live in any 3rd party repo or directly in the repo of theseus. A flake can be rapidly tested as well as updated. However it'd put the package for nix essentially into the domain of modrinth staff, not nixpkgs staff. This means people on the modrinth side would have to have access to the flake and know enough to keep it maintained. Further, flakes are limited in their install process to relatively advanced nix users, the default way of installing packages can not yet make use of flakes on nixos
• Packaging in the repos: Responsible for the package would be nixos staff (to which i have quite good connections through the local hackerspace). This means pushing an update to that repo will take about a week or two, as the new version (and associated source checksum) needs to be updated in the repo and go through the various layers of CI/CD. However, this packaging variant takes all responsibility out of modrinths hands, not being a further burden on development power. The installation process would also be significantly easier for users.
  I'd be happy with any of the two, with a tendency to package as a repo package instead of a flake. That said, as nix is essentially source-derived, the compilation workflow to build the package is essentially the same on both which means i can start working on this without yet knowing the final form of packaging.

[worn schooner]

oh ffs i can't even upload screenshots

[worn schooner]

Alright, compilation and dependency hell is done. Is there a test suite that i should be running?

as far as i can tell the cli version works with this, however the gui version doesn't find some required stuff. I'll definitely need to make a couple changes but i count this as progress

that said, my methodology for testing might be significantly flawed. The way i test, cinny-desktop (also a tauri app) doesn't work for similar reasons. so i'll have a look with different testing methodology and see if that fixes things.

[worn schooner]

progress: those errors are gone, its now missing index.html (which is a little funny). Seems i forgot to have it copy some files to the built binaries

[honest cedar]

To upload screenshots you need to have the Active role which you automatically get from talking for a bit

It’s to prevent spam since this server has been getting a lot recently

[worn schooner]

ok turns out pnpm on nix is really painful

[worn schooner]

Update: the app is running including its frontend, only problems now is a) all the assets are messed up and b) stuff like featured modpacks don't load

oh ffs automod even deletes links to screenshots

[worn schooner]

now that i can post screenshots: Apart from apparently glib-networking this works

oh and i need to figure out the mess in the bar, as well as icons. but that shouldn't be THAT bad.

i had some help from a nice person in the nixpkgs matrix channel after i got stuck on pnpm, the current package definition if anyone is interested can be found at https://paste.lily.flowers/even-more-theseus. Though i will for sure need to do some of my own tweaking now too, for stuff like desktop shortcut and the top bar. I'll put updates in here as they happen, but this is progress

[lavish relic]

is it just me or is that url not loading

[worn schooner]

there, fixed the networking

[worn schooner]

update: desktop entry exists too now. Next up is figuring out the doubled top bar.

As to double window bar: can anyone confirm the same happening on other distribution methods, or is that issue nix-specific?

[lavish relic]

probably something with your window manager(?) i dont have it but thats just because i dont have top bar on any windows

[worn schooner]

running kwin wayland

but theseus is running through xwayland, i should probably check kwin on x11

[lavish relic]

sounds like a plan

[worn schooner]

Oh god

Could not determine the accessibility bus address
No provider of eglCreateImage found.  Requires one of:
    EGL 15

it doesn't even work on x11

setting WEBKIT_DISABLE_COMPOSITING_MODE=1 env var fixes that however. And then doesn't have the title bar issues on x11. Will check on wayland again

ok, title bar issues remain when running through xwayland, but on x11 everything is fine. I'll set that env var and call it good i guess

this isn't a huge issue afterall

[worn schooner]

https://github.com/tauri-apps/tauri/issues/6562
seems to be a tauri issue. Oh well.

[cold dove]

this has already been done, but shouldn't be pr'd yet

we're still waiting on upstream to have proper packaging guidelines (see here ) and preferably a mirror of this flake

but now that i think about it, considering there's been no real activity on them

ig i could move mine to nixpkgs

i know there's been complaints here at least

[worn schooner]

And that works???? The nix build is sandboxed, pnpm shouldn't be able to pull dependencies like that!

if it works i wouldn't complain but it looks weird

the dependencies also look a bit... off

hold on

[cold dove]

look at how it works

[cold dove]

they're not

this has been working for months

[worn schooner]

https://git.grimmauld.de/Grimmauld/grimm-nixos-laptop/src/branch/main/modules/theseus-modrinth.nix
that was what i did. Essentially remapping the tooling from pnpm (because that is very annoying with dependency pulling) to yarn, then using the yarn prefetch tool to get dependencies. And the dependencies in that flake are missing glib-networking which means it wouldn't have access to the interent at runtime

[cold dove]

And the dependencies in that flake are missing glib-networking
look at the flake more, it's not missing

it's separated into a proper wrapper along with minecraft's other dependencies

[worn schooner]

ah, interesting. Alright then.

but interesting how you managed to get pnpm to download dependencies at build time, it really shouldn't work like that. I tried.

[cold dove]

that's what the recursive output hash is for

it's similar to fetchFromGitHub or fetchYarnDeps

i already use it in other packages i maintain, like vesktop

[worn schooner]

wait you are the vesktop guy? I looked at that package and couldn't make sense of it XD

interesting

[cold dove]

yeah lmao

[worn schooner]

And that approach runs through ofborg/hydra?

[cold dove]

yes

[worn schooner]

i mean, if it works, i guess i can't complain

[cold dove]

it's nothing too special honestly, it's what used in the background for tools like fetchFromGitHub

[worn schooner]

you see, hexa is one of the members at my local hackerspace, and you wouldn't believe the curses you get to hear if ofborg breaks

[cold dove]

me and some friends plan on eventually making an actual function for it, similar to what's there for other node package managers

modrinth app won't be able to be built on hydra though anyways

but still follows the rules; no ifd or anything, perfectly reproducible

[worn schooner]

does that include lily foster by any chance?

afaik she too was planning to implement pnpm tooling

[cold dove]

i don't know a lily foster, no

[worn schooner]

you are in the nix matrix channel, so is she. Hold on.

and maybe should have looked at PRs too, but figured noone was working on it after a quick discord search didn't give any meaningful results... oh well

[cold dove]

all good lol

[worn schooner]

also man this means i will again not be contributing to nixpkgs... first k900 tells me kio-audiocd is already packaged on the plasma6 version (that i needed on plasma 5 and packaged for myself), now you come along and pull that flake out of some PR that i made a package for.... ONE DAY it will happen

[cold dove]

i mean hey you're always welcome to improve what i have

https://github.com/NixOS/nixpkgs/pull/289149

flatpak coming soon i guess

[cold dove]

@valid plinth @rich shadow is there anywhere you guys have uploaded screenshots of the app? they're required for some of the metainfo on flathub, and it seems like i can't use any local files :/

[rich shadow]

I would call it Modrinth App

[rich shadow]

You can use the one on the app homepage

Or take your own as well

[cold dove]

that was the plan, but that have to be from a url

i could host my own obviously but i just thought that was a bit odd

[honest cedar]

Couldn't you use the cdn url then https://cdn-raw.modrinth.com/app-landing/app-screenshot.webp

[cold dove]

especially when something like this should honestly be upstreamed in the first place since it's applicable to basically every distro

[cold dove]

i tried my look with that one, but sadly

i think the spec might only accept pngs and jpegs lmao

[honest cedar]

then uh

hm

couldn't you put it in the github repo with your PR and then make it point to that image in the flatpak?

or would that have rate limits or whatever

[cold dove]

probably, you just aren't really meant to do that

[honest cedar]

oh fair

[cold dove]

like i guarntee i'm already going to have comments about the metainfo file itself not being upstream

that's why i made that the prs in the repo first, but yeah at this point it'd probably be best to just get something working on flathub

[cold dove]

welp, compiled webkit. modrinth on the latest gnome runtime is now a thing

it's up
https://github.com/flathub/flathub/pull/4950

@honest cedar @dark needle figure you both might be the ones immediately interested :p

[honest cedar]

oh neat, i'll add it to the issue

thank you for your work on this stuff :>

[cold dove]

anytime, i like messing with it :)

regarding testing, flathub's buildbot should pick this up automatically or when someone manually runs it (i'm not exactly sure what they do) and then anyone can just run a command

[cold dove]

oh yeah almost forgot: could you add the nixpkgs pr to the issue too? should be in the latest comment for the thread

[honest cedar]

ooh, sure thing

added

[cold dove]

looks like it's on winget too
https://github.com/microsoft/winget-pkgs/tree/master/manifests/m/Modrinth/ModrinthApp

[honest cedar]

added that too

[dark needle]

That should only say Modrinth App

[dark needle]

vesktop? lol

[honest cedar]

Discord client mod

[dark needle]

Neat

[dark needle]

Huh, never heard of it

[honest cedar]

Sent in dms

[dark needle]

Already a lot of comments on there

[dark needle]

@cold dove PR has the Awaiting Changes label

[cold dove]

yep im aware

[cold dove]

here's the built flatpak if anyone wants to test it. should work fine
after you download it, you can try to open it in gnome software or discover to install it, or run these commands

# assuming you downloaded it to ~/Downloads/modrinthApp-0.6.3.flatpak
flatpak install ~/Downloads/modrinthApp-0.6.3.flatpak
flatpak run com.modrinth.ModrinthApp

[worn schooner]

huh last time i local-built and tested a flatpak i needed to set up a "local repo" kinda like mavenLocal and such for "publishing"? Did flatpak make that easier or did i just do it in a very roundabout way that time?

[cold dove]

thats what’s recommended to build and test a flatpak. this is just a bundle

[dark needle]

Will tthis auto-update to use the one on Flathub once you post it?

[cold dove]

no, bundles will never update by themselves

[strange cedar]

Been using this, it's been working great for me, absolutely 0 issues experienced thus far.

[cold dove]

good to hear! thanks for trying it out :)

[dark needle]

Ah, oof

[dark needle]

I'd try it on my Deck but I'm not exactly too comfy with that

By the end of the year I may be getting a hardware upgrade and will be dualbooting Linux, and by then I'll def be trying if its out by then

[strange cedar]

iirc you can't use it on deck gamescope, can give it a go tho myself

[strange cedar]

Correction: Apparently it... works? I'm very confused.

It's having trouble with images for some reason, I'm going to mess with flatseal. But the flatpak is loading the same in gamescope than it is in the desktop.

[strange cedar]

Yep, the flatpak completely works in gamescope. Flatseal permissions did nothing, I just had to click continue really fast on the main page and it worked lol.

[dark needle]

@cold dove ^

[shadow kite]

its perfect, also has built-in linux audio screenshare functions

[shadow kite]

the website of the modrinth launcher says that the launcher (game not opened) only uses 250 mb ram. with this flatpak it's 900 for me. is that normal?

[livid tiger]

yea

seems like webkit thing

on windows it uses about 350-400 MB

the modrinth root process however only uses 26, everything else is edge webview...

[shadow kite]

okay thanks

[dark needle]

Why Discord can't fix their shit is beyond me

[worn schooner]

Solution: use matrix where there is no TOS restrictions on clients, just ends up being less garbage

[dark needle]

Matrix isn't for the avarage user lol

[worn schooner]

psst, we just don't tell that to the average user :P

[dark needle]

They'll quickly find out

[strange cedar]

aren't matrix clients historically really buggy?

perhaps that's a dated view though

[worn schooner]

curl? curl has almost no bugs, and you can easily curl to the api url :P

(jokes aside, i only used curl on the raw api a couple times, back when i set up my selfhost homeserver. The clients are still buggy, but at least reliability issues and api response times improved since i self host)

[acoustic gyro]

I am an arch user theres a build package for the modrinth on aur page
I tried to use that to build the modrinth from base but came into a problem, the build gets stuck at 746/749 and takes up all the ram
In using the app Image version, I am unable to login, it isnt launching the login page
not even in the browser

OS - Garuda Linux(Arch Based)(Latest)

[cold dove]

i would recommend trying out this flatpak

[acoustic gyro]

ok

one suggestion

add it to the main website as well
under linux section
with be much more considered

[cold dove]

it will be on flathub eventually, this is sorta like a beta for now

i do hope to get it on the site eventually too though (or just a link to the flathub page), but honestly haven’t had a lot of contact from the maintainers on this in a bit

[lavish relic]

the -bin package works much better idfk whats wrong with the build process in the from source one

[worn schooner]

you could always try just throwing more ram at it (well, swap if you don't have any more)

[cold dove]

ive had some weird build issues too over time

but not anything recently

github runners can build it just fine, and so can i with a 5600x and 16gb of ram

[marble coyote]

I too have it installed with the AUR in Arch. That part of the compile process just takes a VERY long time. Try installing the AUR again and just give it about 10 minutes or so and it will eventually get past that point. Trust me, I've installed it on several systems that way and I know for a fact that it works if you wait.

[shadow kite]

How long does something like this normally take until it has been merged?

[cold dove]

depends on how much time the maintainers have. it can be a few weeks, months - there's no telling really

this does remind me though: @rich shadow is there any way the app screenshot on the website could get a png or jpeg version? screenshots are required here, and i can't really go forward without one from a first party source and the webp isn't supported 🫠

[gleaming trench]

we can probably add them to the cdn

which screenshots do you use?

all of them on https://modrinth.app ?

there's just two right

[cold dove]

i thought there was only the one?

but yeah any nice screenshots you have would be welcome. flathub requires at least one but they do prefer more

[gleaming trench]

there's also this one

[dark needle]

@cold dove Hope Flathub stuff's been ok, been a min since this thread was active

[cold dove]

waiting on the screenshots to be uploaded

[dark needle]

Not sure ehy you can't just upload them manually

[gleaming trench]

sorry! forgot to do this.

here you go:
https://cdn-raw.modrinth.com/app-landing/app-screenshot.png
https://cdn-raw.modrinth.com/app-landing/cobblemon-launcher.png

suppose it's a little odd having macos screenshots on the linux distribution but ¯_(ツ)_/¯

[shadow kite]

Will the flatpak be verified

[shadow kite]

Lets say its just a theme

[cold dove]

awesome, thanks!

[cold dove]

i would hope so personally

most of this will be upstreamed anyways, and i plan on redoing a few PRs so

[honest cedar]

#1138510665947041876 message

without one from a first party source and the webp isn't supported

[dark needle]

Ah.

[strange cedar]

If y'all are in need of linux-specific screenshots then here you go lol

[livid tiger]

apparently on flatpak screenshots should be from the creators of the app (?)

which is very weird but okay..

[honest cedar]

yup - it must be from a first party source #1138510665947041876 message

flathub limitation in specific though, not flatpak

[dark needle]

Kinda dumb imo

[cold dove]

considering you need to use a link and not local files for screenshots, it kinda makes sense to me

their screenshots (or copies on the way back machine) are the most likely to stay up

anyways, looks like webkitgtk just got bumped a few days ago and i finally have time to build it this morning. should be the last time i really need to test anything so, hopefully all goes well and the PR will be merged soon

[dark needle]

@cold dove Approved? https://github.com/getchoo/flathub/tree/modrinth-app

Oh, wait

Gahh GitHub you are dumb

[honest cedar]

wdym?

[dark needle]

Got a notif about the Modrinth app flathub thing, thought it was added

[honest cedar]

that was probably the commit that getchoo pushed around 6 hours ago

to their branch on the fork

[dark needle]

Yep, it was

My bad lol

At least its close to being merged

[honest cedar]

i hope so

[dark needle]

^

[shadow kite]

is this still up to date? i can't wait ;))

[dark needle]

God what's the hold up on Flathub's end?

This is taking ages

@cold dove

Also asked them and they forgot apparently?

Not sure wth's been going on

[shadow kite]

It can happen that something is overlooked, the main thing is that it is being finally worked on now

[dark needle]

True

A lot of people would prefer a Flatpak over a Deb or AppImage, though

[shadow kite]

From what I have heard, the flatpak is based on the appimage. So am I right that it should update automatically if it automatically downloads the appimage from the latest repo?

[dark needle]

A Flatpak will download the newer version of itself

AppImages are very different iirc

[cold dove]

this isn’t people’s full time job, and the app isn’t the only package trying to get accepted. that simple really

[cold dove]

and yes unlike appimage, flatpak can be updated without manually going and downloading it. most software centers will support or this, or you can use flatpak update

[dark needle]

I'm aware, thought I'd ask since its been a hot min though

[shadow kite]

I fully agree with you, and it's better to have long check times than no checks at all like with snap where everything is simply let through.

[shadow kite]

but does the maintainer of the flatpak have to update it manually or can the flathub bot always automatically convert the latest appimage to the flatpak. sorry if this is a stupid question.

[cold dove]

the flathub bot should be able to most of the time. unlike some other launchers (prism for example), the app doesn't really need any native libraries aside from those required by tauri and what's in the runtime

but depending on the release, there may be some manual changes required like adding new dependencies

[shadow kite]

okay thanks

also thanks for your work, i actually only have flatpaks and i love the modrinth launcher

[dark needle]

Flatpaks are not AppImages

[cold dove]

in this case though, the appimage is used as a source

converting isn’t how i’d describe it though. the manifest itself is what does that, and the bot just updates the link it uses

[dark needle]

Ah

[round peak]

Arent flatpaks supposed to built from sources? repackaging the appimage doesnt make sense to me

Going through the manifest, I don't exactly like what it is doing. Do we need to have components like flite and webkitgtk ?

the package size will be huge. are these supposed to be independent layers and shared with other programs ?

[round peak]

now I am super confused. GnomeSDK should provide webkitGTK, why is it being built from source in the manifest ?

[shadow kite]

Tauri (used by modrinth) relies on an outdated webkit version. That's why it still has to be built. And at the moment it would be too much work to build the flatpak from source and it would be easier with the app image. But from what I've heard it's a plan for the future

@round peak

[round peak]

but the manifest uses webkitgtk 2.44.0 and is the same version in Gnome Platform

[shadow kite]

Okay, I don't understand that either. I think it is simply shared with other apps. But I'm not sure

[dark needle]

Huh

[round peak]

nvm I was wrong. there is a difference. Gnome Platform 42 provides webkit2gtk-4.1 and not 4.0 which is what tauri uses

[round peak]

the best way for now seems to be to build a deb package from source and then convert that to flatpak

https://github.com/tauri-apps/tauri-docs/pull/1760
https://github.com/flathub/in.cinny.Cinny/blob/master/in.cinny.Cinny.yml

[cold dove]

they are, but modrinth uses pnpm which isn’t supported for offline builds (required by flathub) in flatpak. this isn’t an issue for now though, as the app itself doesn’t support aarch64-linux and that’s the only real benefit you’d get from building from source (minus maybe some supply chain security? but frankly i trust modrinth’s binaries, and the app downloads more at runtime anyways)

[cold dove]

it does provide webkitgtk…but not the one we need. currently, there are 3 different supported abis for webkitgtk: 4.0 (built against libsoup2), 4.1 (built against libsoup3), and 6.0 (built against gtk4). as of gnome 43’s runtime (could also be 42 or 44? i don’t remember exactly), abi 4.0 is considered deprecated and no longer shipped with it

[round peak]

Yeah I figured that part out. why tf is webkit versioning so bad

[cold dove]

the only other option would be to pull in an older runtime, but that would probably have the sane bigger download size or more as the current setup

[cold dove]

welcome to linux userland’s abi stability! (almost everything is annoying and complex)

[round peak]

nah current method is better. compile webkitgtk from source till now. Tauri v2 which is in beta right now supports newer webkit

[cold dove]

this isn’t an issue in most actual distros though, as they’ll usually ship the 4.0 abi still

nixpkgs is an example here, since frankly a lot of packages still use it

[round peak]

doesnt matter. flatpak runtimes are independent of distros

[cold dove]

but yeah tauri v2 will be great for the app tbh

[cold dove]

i know, im just talking about in other distros packagings

flatpak is the only place you need to bundle webkitgtk, since unlike the runtimes, distros ship newer and older webkitgtk

[round peak]

but frankly i trust modrinth’s binaries, and the app downloads more at runtime anyways)
but that can be intercepted/infected which is why building from source is considered safer

[cold dove]

it is, but i gave the example of the binaries being downloaded at runtime for a reason

we can’t build those from source and still need to trust them; i don’t think it’s a stretch to trust the app’s binary itself at that point

this isn’t ideal though ofc, and i will hopefully have the time to work on a way to support pnpm in flatpak, but as of now it doesn’t really effect users

[round peak]

ideally you would want to disable them in a flatpak situation. the remote fetch thing but for first build this is fine

[cold dove]

and if you are concerned about things being compiled from source, i think nix would be a better option in general

especially since it can build from source currently and you can also reproduce the binaries distributed, unlike flatpak

[cold dove]

we can’t. you wouldn’t be able to download minecraft for example

[round peak]

oh you meant minecraft binaries and other stuff. I though the launcher code itself was being updated (expo style)

[cold dove]

oh no it’s just regular stuff you’d download. there is no internal updater or anything

[round peak]

cool. then no problems with the impl

tauri v2 might get a flatpak build target directly (which was the main reason for the webkit update)

its in beta right now and from what prospector told me, modrinth is using 1.2 and port might be far

[cold dove]

frankly i’d ignore most of their auto generated packages

they’re just plain bad and hard to adapt to situations like this where the packaging isn’t just for tauri but also minecraft

[dark needle]

You should probably let them know

Also, seems images are bugged

[livid tiger]

because they used discord cdn to embed these images in onboarding

[dark needle]

@rich shadow Guess its time to switch em' out then ^

[livid tiger]

ya don't have to ping geo, we are very much aware of this

[honest cedar]

why didn't they just host it somewhere or bundle with the app 😭

[gleaming trench]

was probably a placeholder in development and got forgotten about

[honest cedar]

ah

[shadow kite]

https://github.com/flathub/flathub/pull/4950 I have been using the test build for 3 days with no problems, why is nothing happening?

[dark needle]

Ask Geo to fix the image issues lol

#1138510665947041876 message

[cold dove]

it would be accepted regardless

just wait on the maintainers to review it. its only 3 days, and you already have a build after all

[cold dove]

@rich shadow would you still accept a pr switching to npm? i know i said it wouldn't be a blocker before, but it looks like something to do with rollup and pnpm is now blocking builds even on nix; meanwhile, npm is fine

i think i might also be able to fix some issues with the autogenerated deb from tauri now that we've updated

namely the missing dependencies and the pretty rough desktop file i've needed to replace in downstream packagings
https://tauri.app/v1/api/config#debconfig

this + using the npm registry over github where possible should allow for offline builds basically anywhere

[rich shadow]

yeah just ping me!

[cold dove]

thanks :)

[cold dove]

pr is up

[dark needle]

More image-related issues in the Flathub pr

[cold dove]

please don’t ping me for every new comment

[dark needle]

New test build on the PR if anyone wants to try it

[shadow kite]

What‘s the difference to the older one

[cold dove]

v0.7.1 has been pushed to the flathub and nixpkgs PRs

i might have some time to build it locally again, but hopefully one of the maintainers will trigger a build for us lol

https://buildbot.flathub.org/#/builders/6/builds/116886

[pulsar mortar]

Hell yeah! congrats

[cold dove]

ain’t no way???

@rich shadow
https://flathub.org/apps/com.modrinth.ModrinthApp

[livid tiger]

phew, it's not 0.7.1

😭

0.7.1 has a broken auth and a lot of people experience issues with it so yeah, even though 0.6.3 doesn't support 1.20.5 (requires workaround), it at least can allow more people to sign in to your account and most sign in issues are fixable

[shadow kite]

It is…

Just not displayed on flathub right

[shadow kite]

I also have the auth problem (with the flatpak)

is there a chance that the flatpak will be verified

[livid tiger]

oh no

[gleaming trench]

is there something we can do to help get it verified

[shadow kite]

as I understand it, you can either verify it with Github or you can do it on the Modrinth website https://docs.flathub.org/docs/for-app-authors/verification.

[gleaming trench]

ah, I guess we would need to transfer ownership

[livid tiger]

I think it would be better if it remained a community effort by people who know what they're doing, but somehow show that we totally approve it

[gleaming trench]

we can probably request manual verification by contacting the flathub admins

though I guess would we want it verified if we're not in control of it?

dunno

[livid tiger]

no, that would be a false verification then, cuz we haven't verified anything

[shadow kite]

maybe someone could add getchoo to the team as i think the flatpak is a very important part and the majority of linux users will use the flatpak. an official badge is really important from a marketing point of view.

[livid tiger]

I think we can just add link to website like ‘community distributions’ section?

[shadow kite]

However, many users who simply access the app via flathub would not see this and the large Unverified warning area could put people off

[livid tiger]

not sure what we can do about it, we don't want to mislead people that this is some official distribution

[shadow kite]

I completely understand your point

[cold dove]

i forgot that flatpaks don't have actual version logic

lol

since i didn't add the changelog from the release it just

says 0.6.3

amazing

[cold dove]

Verification is a process by which Flathub can confirm that an app is published by its original developer or a third party approved by the developer
this is linux. if packages had to be actually official to get verified, basically no apps would be

if anyone on the team is interested though, i'd be up to make this official

i would honestly recommend it in my experiences with prism. flathub is going to be the way most people use this, especially with the state of the deb package (which i need to get to rebasing that PR) and the appimage

i can get the hesitation, though. scrump and i actually maintain a few packages ourselves on the aur for example, but don't call if official

mainly because anyone can always just adopt the package one day if we drop it as packages are namespaced

[livid tiger]

https://github.com/modrinth/theseus/issues/1153

where should we direct people to report issues with flatpak package?

[cold dove]

depends on the issue

if it's a packaging one, https://github.com/flathub/com.modrinth.ModrinthApp
if it's an upstream issue, probably nowhere

in this case (and probably most outside of something in a log saying there's a dependency missing, etc) it is an upstream issue. tauri likes to use it's own CSD by default and doesn't seem to let compositors know it is, so they also apply their own server side decorations

but you can disable this in the app after https://github.com/modrinth/theseus/pull/541 i believe

[dark needle]

@gleaming trench When this is more polished, mind announcing that a Flatpak version is a thing? (And update the site to link to Flathub)

[cold dove]

the flatpak is polished? these are all issues from upstream

[dark needle]

Ah

Thought it was just the Flatpak that had these issues

Also a few PRs are open on there already

[cold dove]

i actually haven't seen any issues opened that are flatpak specific

[dark needle]

Ah

[livid tiger]

I just don't see this being reported for non-flatpak, does it happen in our normal distributions too?

[cold dove]

there's 2. one of them doesn't do anything and the other just enables discord rpc lmao

[cold dove]

yes, look at the pr i linked

[dark needle]

Adds Game Mode support

Seems needed for Steam Deck users lol

[gleaming trench]

we can probably include a mention of it in our 0.8 release announcement

[livid tiger]

the pr was old ago, and I think it was related to a feature request and double title bar bug on windows, but not linux

[dark needle]

Hope you figure out the Verify thing too, no rush though

[cold dove]

it adds the cli so someone can use it as a wrapper command. this isn't really functionality in the launcher, and i honestly might wait to add it

since iirc geo was going to add actual gamemode support

[dark needle]

Ah

[cold dove]

Not a real problem just annoying as i use a tiling window manager
i don't think they were on windows

[dark needle]

And fixes other stuff

[cold dove]

but yeah this is a pretty common issue with some apps

[livid tiger]

I think it's about that they had titlebar in app though they didn't want it, because they use tiling manager that doesn't have any title bars, not about double titlebar

[dark needle]

Very glad to see the app on Flathub

https://tenor.com/view/despicable-me-minions-cheering-hooray-happy-gif-9482103050132489277

Took a while, but it should make Modrinth and the App more widely used

[cold dove]

this issue extends to compositors like kwin that will force decorations on apps that don’t properly report client side decorations, though

the only reason they didn’t have two title bars is because they weren’t enabled by the compositor

this issue also doesn’t happen on gnome for example, which has the same behavior (never forcing a server side decoration)

[dark needle]

Also, why does Flathub link the Windows repos when Linux issues should probably be on the Flathub one

Organizing things would be nice imo

[gleaming trench]

what windows repos?

[cold dove]

the windows repo…?

[dark needle]

On Modrinth's git

[gleaming trench]

that's where you'd report an issue with the app

[dark needle]

https://github.com/modrinth/theseus/issues

[cold dove]

that isn’t a windows repo

[livid tiger]

lol

[cold dove]

that’s just the main repo

[dark needle]

Ugh I can't think today lol

[cold dove]

and organizing what? the flathub page?

[gleaming trench]

i think it's pretty unlikely for an issue someone encounters to be an issue with packaging

[cold dove]

yeah especially right now since i’m not even building from source

[gleaming trench]

and if it is and they know enough to be able to tell, they will probably know how to find the flathub repo

[cold dove]

it’s literally just the appimage binary

in the future though there probably will be some reporting weird ogl issues, though

since flatpak sometimes falls out of sync with their system drivers

i think prism has a tag for it

[dark needle]

I don't think an AppImage or Deb are needed now that Flathub's a thing tbh

[cold dove]

once the deb is fixed with my pr i wouldn’t see a problem

they’re autogenerated

[dark needle]

I mean, yeah Debian does require a bit of manual work since they don't include Flatpak nor the repo

So yes the Deb would help in that regard

But vanilla Debian isn't THAT famous

Most distros include Flatpak and/or have both set up for you

So 75% of me doesn't really see a point in anything else

[cold dove]

…it isn’t only for vanilla debian though?

it works for anything debian or ubuntu based

which is a vast majority of distros

i wouldn’t say it should be the main platform, but again it’s auto generated

[dark needle]

Ubuntu also doesn't use Flatpak

[cold dove]

removing it as an option completely wouldn’t really benefit anyone

[dark needle]

As I said,

And that includes anything based on Debian

[cold dove]

besides ubuntu and debian itself, two of the most popular distros

and countless derivatives that also don’t use it

[dark needle]

Zorin and Mint are Ubuntu based, and they have Flatpak/hub set up

[cold dove]

those aren’t every debian/ubuntu deriv

that’s two of them

[dark needle]

Ik lol

Examples though

Btw, doubt this'll happen but I wouldn't be surprised if a Snap version of the app becomes a thing lol, but Ik you wouldn't be doing that due to.. well. You know. Snap sucks

[cold dove]

yeah we even dropped our snap in prism

we didn’t want to maintain it, neither did any contributors

[dark needle]

Good lol

[cold dove]

the only reason we do have one is because one day a canonical employee decided to pick it up again

[dark needle]

Flathub ftw

[dark needle]

Cool

Though ngl I've started to kinda fear Ubuntu stuff as of late

Snaps + Poor app store handling + Malware

[cold dove]

i just dislike that the backend is closed source

the malware and stuff is something that could (and has) happened to any linux repo

ubuntu just got the short end of the stick since they’re the most popular by a long shot

[dark needle]

I dislike the whole thing, why Ubuntu needed to reinvent the wheel when Flathub exists I don't get

[dark needle]

Not really, they refuse to moderate it properly

[cold dove]

you overestimate other repos

the aur for example has basically none

and any given repo is not actually auditing the code of their packages

[dark needle]

Well, Flathub does iirc

[cold dove]

they don’t

no repo does

[dark needle]

Huh, didn't know that

[cold dove]

it would take way too much time with how many packages you’re dealing with

and even if they did, it’s not going to be every update

i mean im a packager for a lot of distros. i know im not reviewing the individual diffs for every commit in a new release

[dark needle]

Well, with how big Flathub is, a malware package would get reported and removed pretty fast I hope

[cold dove]

usually that is the case since the people making this stuff are dumb

but sometimes it’s not so obvious

the whole xz situation is a good example. we really only uncovered that by chance and it was indeed shipped to many users

[dark needle]

Ik, but its far better then what Snapd is

[cold dove]

it’s not

there’s nothing differentiating them here

[dark needle]

Even the Google Play Store or MS/Windows Store has the issue afaik

App stores need to stop being in full Open-arms Bear Hug Mode lol

Getting as much junk onto them asap

Seems Apple's app store is the only one that doesn't have the issue due to how overly strict it is

I think

[livid tiger]

#github-issues message

[cold dove]

again, not a packaging issue

best it could be is many a different version of webkitgtk?

but yeah i’ve been able to get double borders on the appimage

[gleaming trench]

well it's weird if the same person has it work with appimage but not flatpak

[cold dove]

and i've had it not work with either

could be a kwin issue, missing flatpak dependency, a lot of things

regardless though, enabling native decorations should fix this

[dark needle]

When do you plan on verifying the app on Flathub?

Or does Geo have to ask someone

[gleaming trench]

I don't think we will

unless we end up taking over maintenance of it which we don't plan to atm

[dark needle]

Well, didn't Getchoo say you could do it via GitHub?

[gleaming trench]

if we don't actually own the flathub project we aren't gonna say it's official

and we don't wanna have to maintain it

so we don't wanna own it

[cold dove]

i only said they could approve third parties or maintain it themselves

[dark needle]

Well, could approve that Getchoo's maintaining it

[dark needle]

Ah

[shadow kite]

I would still say that flathub is more secure. All those crypto apps that don't even display anything without an internet connection would never have gotten through the upload process on flathub. But yes, every repo is affected by something like xz.

[shadow kite]

Yes, but the aur does not claim that it is safe as snap claims. Arch even warns against the aur Security

[lavish relic]

hey for the aur package i added WEBKIT_DISABLE_DMABUF_RENDERER=1 to the env because of some webkit2gtk bug (https://gitlab.archlinux.org/archlinux/packaging/packages/webkit2gtk/-/issues/1)
without it the app doesnt work at all
but opening the logs of an instance freezes the app, is this because of the env variable or some other known bug in 0.7.1?

(also thanks for whatever automod thing deleting messages with "masked links" without any mention, i like typing messages twice)

[dark needle]

Why host it then

[honest cedar]

i mentioned this on the issue thread yesterday but i've updated the issue with hopefully latest information

please let me know if i missed anything

i'm kind of treating it as like an unofficial download page for linux users that tells you how packaging is going for specific package types and where to get finished packages easily yk

[rich shadow]

which issue?

[lavish relic]

#497 (?)

[honest cedar]

pinned msg

the one i initially made this discord thread for

[shadow kite]

Flathub has also updated the main page. This is a good way to discover new apps. But one condition is verification (the chance is higher that it is displayed if it is verified). If you verify the Modrinth package, you might get more downloads out of it.

[gleaming trench]

what exactly is verification supposed to mean?

we are glad that it exists and it's made fully with permission and all, but we don't currently plan to maintain this package first-party

I assume unless Modrinth is controlling it ourselves it should probably not be verified, correct?

[shadow kite]

Verified does not have to mean that it is official from modrinth.

"Verification is a process by which Flathub can confirm that an app is published by its original developer or a third party approved by the developer". ^1

With a verified flatpak, you can instill much more trust in your users.

^1: https://docs.flathub.org/docs/for-app-authors/verification#what-is-verification

[livid tiger]

the problem is, it's extremely misleading

had they a different label for the latter situation, that would be understandable

but right now it looks like verification implies that the project is fully reviewed by the original developer, which would be a complete lie in modrinth's case

[cold dove]

this is 100% purposeful and it’s pretty funny

because if they actually required the developers to maintain verified flatpak’s, there’d barely be any

but now stuff like discord can be “verified” even though discord themselves have never made a contribution

[livid tiger]

what's the point of it then

[gleaming trench]

I feel like there should be a label for like "supported/done with permission" versus "official"

like to indicate that it is done fully with the permission of the maintainers and we encourage it

or instead, there should be a way to make it somehow community verified

like if a large number of community members approve of it

i dunno. I guess I have no idea what "verified" is supposed to even indicate

[livid tiger]

nothing, seems to be a completely meaningless status on flatpak according to getchoo

[gleaming trench]

like Modrinth approves of getchoo publishing this for us, but we don't necessarily endorse it. like if getchoo decided to somehow sneak malware into it or not keep it up-to-date and functional, we take no responsibility for it

but we'd be happy to consider it an approved third-party mirror

Verification is a process by which Flathub can confirm that an app is published by its original developer or a third party approved by the developer.

I guess it just means we're okay with it being published?

in which case I guess it can be verified?

[livid tiger]

this is very vague

this can also mean like video games where company hires another company to do the port

[gleaming trench]

how common is verification for third-party stuff on here

to me it comes across like non-verified stuff are like, borderline sketchy because they're done without approval by the company that owns the software and they may issue a takedown notice at any time

are the flathub people friendly, I might just shoot them an email

or do they have a discord perchance

seems not

[livid tiger]

I'm just worried that if it's verified that people assume that we actually maintain it, and given that there's our issue section linked it, it would be quite annoying if people were reporting issues without testing that it's flatpak related first like we already had

like verified badge says nothing but that the package is verified via domain

just absolutely meaningless and misleading thing

[gleaming trench]

hmm there is a big lack of transparency on Flathub about who is making these packages

I mean ultimately I guess they're all approved and verified by Flathub (that PR process seemed a bit intense) but there's nothing on the page other than (Unverified) that indicates who is maintaining these packages

[livid tiger]

man why linux stuff is so.. linux

[dark needle]

^

[dark needle]

Well, having it Verified and saying that Getchoo maintains it would still be better then nothing imo

[gleaming trench]

it doesn't say who maintains it though

[dark needle]

in the 'by Modrinth' section, just say 'by Modrinth (Maintained by Getchoo)'

Might work I think

[cold dove]

get as closed to verified as a linux package can

since yeah, usually third parties approved by a developer are trustworthy

but flathub honestly has a big issue with labels in general

they will actually give a yellow warning box for any app that has network access

[gleaming trench]

is it possible for us to have a Modrinth-owned account have ownership of the package on flathub but still have you as the maintainer?

[gleaming trench]

wtf kind of app doesn't use network lol

[cold dove]

we are also "potentially unsafe" as we can check notes access files and the device!

[gleaming trench]

lol

can potentially access some specific files

[cold dove]

i'll admit using x11 is actually an issue, though. we just can't get around it since it's required for mc

[gleaming trench]

in other words, does something

[cold dove]

yep

[cold dove]

but the way flathub works is pretty silly

basically flathub will always be the owner of the repo, they just invite collaborators and give them commit access

i guess that commit access could be transferred to a modrinth owned account and you guys could approve PRs from me and others?

but at that point you would just be maintaining it

[gleaming trench]

yeah

[cold dove]

alternatively you could just hit accept to anything i PR/approve, which would kinda make it pointless

[gleaming trench]

i guess basically as long as flathub is in control it shouldn't really matter if we verify it

[cold dove]

well i can still commit anything i want

i wouldn't say their ownership is a big safeguard

[gleaming trench]

yeah but we'd at least be able to get them to revert/take it down pretty easily I suppose

i dunno

[cold dove]

the main benefit is just that regardless of you guys verifying it or not, you could easily report anything i do later on

yeah

[gleaming trench]

yeah I mean that's the main thing is the thing we're verifying is more our trust in flathub to do their thing than anything

[cold dove]

it's up to you though, really. i get it either way
at prism we don't even officially endorse packages myself and other maintainers have full control over lol

and honestly? i don't think the app needs the advertisement from flathub

[gleaming trench]

i feel like Modrinth app on Linux is sorta already a niche of a niche

i think most Linux users would rather use something like Prism and most people aren't Linux users to begin with

[cold dove]

anyone who is on linux and playing mc who would have an interest in it probably already knows about it. flathub isn't exactly a big marketing platform

[cold dove]

100% lmao

[livid tiger]

tauri on Linux also seems to far from the best solutions out there

#1235504301191729232 message

[cold dove]

yeah...webkitgtk is something

it's funny because really they could've just used chromium and it would be a lot better

webkitgtk was a pretty arbitrary choice since linux (because it's linux) doesn't actually have a "standard" webview

this also gets worse with distribution to distribution packaging

as some distros just have the worse versions imaginable, or just none at all (flatpak!)

nixpkgs is the only place i've seen it run well on all cards and desktops

[livid tiger]

is there a way to use chromium as webview on Linux? like I remember oss build of vscode using shared electron, but idk if chromium can be used that way

but yeah would've been a much better choice if possible

[cold dove]

libcef can i believe

[livid tiger]

doesn't seem like CEF is any of the repos unlike webkit

so you'd have to bundle it like electron which is like against the spirit of tauri where it should use the thingy on the system

also @gleaming trench flatpak apparently has a forum https://discourse.flathub.org/ might want to ask about the verification process there

[shadow kite]

Or you can ask at their matrix

[cold dove]

there’s a few who ship but not many

[cold dove]

and i mean…tauri is already a rust project, so it’s not like they aren’t already vendoring deps already

and for linux, the main distribution method is going to be an appimage (bundles everything) or a package that can add it as a dependency