zzz
zlatinb, what do you think of a jpackaged i2psnark for the .ru crowd?
zlatinb
I was about to post on the forum, but basically yes, for java haters a jpackaged i2psnark is great
zlatinb
for linux users there's already a docker image with i2psnark standalone
zzz
I assume the target audience is mostly windows?
zlatinb
not in the seedbox case... here is a monster docker-compose.yml which launches i2pd, i2psnark and muwire in 3 separate containers: github.com/zlatinb/muwire/wiki/Docker
zlatinb
ypopovych/i2psnark:latest
zzz
maybe acetone knows
zzz
I presume you're talking about it in a ru channel
zlatinb
in the #dev chanel on ilita yes
zlatinb
but yes, generally they're not fans of java :)
zlatinb
so a jpackaged i2psnark in an appimage for example would make a lot of sense
acetone
zzz: bit not understand a question
zzz
I kinda missed the seedbox part of it
zlatinb
acetone: jpackaged = no java required
acetone
zlatinb: woopwoop!
zlatinb
well seedbox is a very different use case, we should look at the two separately
zzz
acetone, was wondering about what platform people are using i2psnark-standalone on now. windows or linux
acetone
zlatinb: linux
acetone
like a VPS or Raspberry
zzz
the Russian translation in i2psnark looks 100% complete, very nice.
acetone
zlatinb: yep, russian i18n is very nice
zzz
thanks to val
acetone
zzz:*
zzz
I guess we could also do a debian package if people wanted it
zlatinb
jpackage can generate a .deb
zlatinb
eyedeekay has looked into it more than I have but yes .deb and .rpm are supported out of the box
zzz
I don't think we'd want to do it that way, if you're on debian then you really want to get the JRE updates separately, not bundle the JRE
zzz
ditto jetty and all our other dependencies
zlatinb
idk, there's pros and cons, like if the user explicitly does not want to install a jre
zzz
thats not the debian way
zzz
if you wanted an all-in-one pkg you'd do it as a Ubuntu snap
zlatinb
mmm jpackage + appimage is the least amount of effort imho and it works on many linux distros
zlatinb
also I've already done most of the legwork in the muwire-pkg project
acetone
zlatinb: I using jvm on my server and install it only for I2PSnark. Not critical for me
zlatinb
acetone: yes but what about those Hate java (with capital H ))
acetone
yep, it's mostly classic holywar
zzz
I think I'm back where I started, that jpackages for linux don't make a lot of sense
zzz
or, at least, it's a narrow use case
zlatinb
it is designed mostly for upstream packaging where developer == packager
zlatinb
8% of the MuWire downloads this month are the Linux AppImage
zlatinb
I'm just trying to minimize the amount of work required for whoever will be doing the packaging
zlatinb
but if you're happy with the Debian way go for it by all means :)
eyedeekay
Re: the deb generated by jpackage I'm pretty much with zzz, there are only a few use cases.
eyedeekay
I can only think of 2 really good ones:
eyedeekay
1) It's really easy to produce a dev build with a jpackaged router, way easier than figuring out how to build a .deb locally
eyedeekay
2) It's a very convenient shortcut to a Snap package to generate a jpackage deb then install it during the Snap build.
eyedeekay
IMO people who want a .deb really prefer some kind of uniform package management, and often one want just a single one.
eyedeekay
People get really annoyed when you suggest that the best way to get a package is to install the Snap or the Docker Image or whatever awesome convenient packagy thing somebody prefers. Which is understandable.
eyedeekay
So for them, having a .deb of a dev build is about integrating with the way they already manage the rest of their system.
eyedeekay
In *general* jpackages for Linux though, I'm not quite so sure.
eyedeekay
Blinded message
eyedeekay
i2p.firefox branch "preconfigured-portables" has some unfinished work on that idea
eyedeekay
I don't know how to make a real AppImage but I do know how to mutate a Snap to turn it into an AppImage
zlatinb
it's very easy, look in muwire-pkg project on gitlab
eyedeekay
So you just build the directory and run the $APPIMAGE_BINARY on it? That is easy
zlatinb
yeah that's it
eyedeekay
Nice
eyedeekay
And it figures out what command it runs from AppRun
zlatinb
from the .desktop file, the AppRun I copy-pasted from ... appimagetool itself :)
zlatinb
and it's funny cause even though it references x86 libraries, it works fine on aarch64
eyedeekay
OK that's all sensible enough, easier than a Snap too