eyedeekay
Debian builds are running, probably going to take a little more time but they should be done soon
R4SAS
debian?
R4SAS
aren't you will follow the same way as zzz had done?
eyedeekay
Ubuntu technically, launchpad to be specific
eyedeekay
Yes I'm following zzz's old instructions exactly
R4SAS
kk, I thought that you build debian somewhere else
eyedeekay
Debian step includes the launchpad step
R4SAS
btw, I thought that you implemented OpenBuildService support
R4SAS
I tried to understand it, but still no luck :D
R4SAS
requirement to place debian files in build repository is a bit strange
R4SAS
I hoped that it would be enough place something that will tell that "you can use debian stuff from source", but it doesn't
eyedeekay
no OBS support yet, but OBS does pique my interest, might be a good way to make other package types supportable
R4SAS
hmm... I need to update i2pd in OBS for OpenSUSE
R4SAS
need to remember how it was done there, half a year has already passed
eyedeekay
launchpad builds are freakin' interminable
dr|z3d
might be time to think about a project repo, idk, with its own buildbot.
dr|z3d
or even a Tor-browser type implementation, where a script to install I2P is the only thing that's in the repos, with a standard install thereafter. easier to maintain.
dr|z3d
zzz's expressed reservations in the past, because it's "not the debian way", but if it works for Tor, no reason it can't work for I2P.
R4SAS
own buildbot requires too much resources
R4SAS
not in Java way, but C++ app (i2pd like) must be compiled against bunch versions of every distribution
dr|z3d
we used to have a buildbot on the network a while back, jenkins.
R4SAS
I mean if you want to compile packages fast, you need a *bunch* of servers, where you will build them simultaneously
R4SAS
github can be used in this case btw
RN
jenkins was useful
dr|z3d
that's the thing about fast, the process is probably going to be faster even if you're compiling the packages in serial than putting the process in the hands of launchpad.
R4SAS
I have done bunch workflows already to test build wvwrywhere )))
R4SAS
everywhere*
dr|z3d
but sure, github, gitlab, both can be leveraged to build.
R4SAS
dr|z3d: nope
R4SAS
for our releases I build debian myself
R4SAS
I didn't take ubuntu packages to debian
dr|z3d
launchpad is a bottleneck is what I'm saying, especially when you're in a queue with an 8h lead time.
R4SAS
so armhf and arm64 targets are *pain in ass*
R4SAS
yup, that happens
R4SAS
but not always
dr|z3d
gitlab/github and docker images handles all the various permutations just fine.
R4SAS
not at all
R4SAS
don't forget that GHA and GL CI is x86_64 basicly
R4SAS
so building arnhf and arh64 with qemu takes much more time that native builders
R4SAS
than*
dr|z3d
it can be done, anyways, but sure, there's work involved in setting things up. don't forget github's army of 4rd party buildbots that are readily deployed.
dr|z3d
regardless, for java, a script that handles the initial installation and configuration and then updates in-console is something to consider. bypasses all the build bot stuff entirely.
dr|z3d
like I said, TorBrowser does it, very little actual maintenance required on the script end of things.
eyedeekay
Micah's launcher script mostly exists to shore up the shortcomings of the Tor Browser product when it comes to Linuxes, the Tor debian repos still contain a proper Tor router which is built the Debian way
dr|z3d
sure, if you know what you're doing, the Tor binary install trumps the Tor browser.
dr|z3d
but you're comparing apples to oranges in comparing Tor (not TorBrowser) with java i2p.
dr|z3d
TorBrowser can auto-update, Java I2P can auto-update, Tor binary *cannot* auto-update.
dr|z3d
Tor proposed an auto-update mechanism they were going to name "handy" many moons ago, but it never went anywhere.
eyedeekay
I'm not sure I totally agree in this one specific case, the other shortcoming of Tor Browser is the specific Firefox variant must be packaged and Firefox already requires special permission to be in Debian
dr|z3d
we don't care about the specifics of the TBB, that's besides the point. The point is they have a script which handles installation in the debian repo.
eyedeekay
We also lose systemd/init.d services
dr|z3d
well, yes and no. the i2prouter install method covers most of that.
eyedeekay
Plus if we're only targeting contrib like torbrowser-launcher then we may as well just do the whole dang thing with jpackage since it involves writing no code
dr|z3d
the only thing we'd need is a fairly simple script.
dr|z3d
jpackage I'm not familiar with, but that sounds like it would bundle everything.
eyedeekay
I'm not saying no for sure but I'm pretty skeptical
eyedeekay
Yeah it does
dr|z3d
that reintroduces complexity we're trying to remove :)
dr|z3d
script wgets the java installer, script asks a few questions like install location, service config, ram allocation, etc, script installs i2p. done. all further updates handled in-console.
dr|z3d
ongoing maintenance burden vs having to submit/build for a bunch of different OS's/platforms every release? virtually zero.
mesh
dr|z3d: I wouldn't trust a script to install java. That seems pretty iffy. Why wouldn't you tell the user to download java the normal Debian way?
mesh
then again the whole jpackage thing would bundle the whole JRE
dr|z3d
the script would do somethign along the lines of apt install openjdk-default-headless or whatever.
dr|z3d
(having first checked that java isn't already installed)
mesh
but that's a private internal thing. I am very, very wary of scripts that attempt to install Java in a "public" manner. That's classic malware behavior.
mesh
dr|z3d: I mean it's not as nice but I would just fail and print a message telling the user to install Java version $X. It lets the user choose which jdk she wants to use and keeps her in the loop
dr|z3d
the script could quite easily handle that, offering numbered options with the default jdk being the default. no need to bail out of the install.
dr|z3d
Please select a java version to install, or hit enter for the operating system default.
mesh
it could perhaps. I guess as long as it's very clear to the user what you're doing and she has control. It's usually not okay to do stuff like silently install jdks
eyedeekay
No need to do it at all, as far as zero-maintenance goes that's a simple entry in a control file
eyedeekay
We would never be able to get away without a control file anyway
eyedeekay
Depends: (default-jdk | etc)
dr|z3d
or Depends: openjdk* if you can wildcard that.
eyedeekay
I don't know all the operators, the only one I ever use is Or |
mesh
the problem I often run into is that there's different versions of java. The Oracle guys are basically right about the days of trusting one "global java install" for a machine are over. Hence jpackage
dr|z3d
but sure, I don't think there's any requirement to make the user choose a specific version on install. just check if a suitable java's installed, and if not, openjdk default.
mesh
though I also hate the idea of every application bundling their own version of the jre/jdk
eyedeekay
It's one of those everybody's right and nobody's happy situations. that's been going around.
dr|z3d
:)
dr|z3d
that's a polite way of saying "opinions are like assholes, everyone has one" :)
mesh
eyedeekay: well it's the unsolvable universal package manager problem. In a perfect world everything would be in a package like deb and your package would just ssay 'I depend on jdk-19"
mesh
in reality you have to write awful scripts that detect java, check the right version, if it's not installed, go download one of the literal 12 jdks out there, and then hide it in a place nobody will ever find -- unless there's a major security exploit like what happened with jdk 18
dr|z3d
no, you don't. no java, install default java via package manager.
mesh
installing java programs is still a big mess, 20 years after 1.0. It's kind of funny. We can land a rover on mars but we can't figure out how to distribute java programs
mesh
dr|z3d: I mean for something like i2p it might not be an issue but a lot of programs want to use a specific minimum version of java and a new version of java is released every 6 months
dr|z3d
we don't care.
mesh
if you just target java8 it's not a big deal tho. you can't use any of the new java features in your code but your code will probably run on most jdks
dr|z3d
no java installed means you're not using any of said apps on your system.
mesh
dr|z3d: yeah I'm talking about the case where java is installed but it's the wrong version
dr|z3d
installing java wouldn't be any different from how the .deb/repo install handles it now.
dr|z3d
it's nigh impossible to install i2p with the wrong version of java pre-installed. that would be covered by the depends clause, in any event. waste of time discussing hypothetical corner cases unlikely to ever occur.
mesh
dr|z3d: the debian approach is wrong. The debian guys think you can just install one jre in /usr/bin/java. It breaks down very quickly. In reality you want to install java in something like /usr/bin/jre/${vendor}/${version}/java ... and then maybe setup some symlinks
dr|z3d
java never gets installed directly to /usr/bin on debian, it's alyways symlinked.
mesh
the debian guys and the ubuntu guys don't really get the jdk. the idea of one program released by multiple vendors so quickly is just unimaginable to them
mesh
it looks like this problem isn't as bad before. you can use the debian control file to depend on a minimum version of java now. unix.stackexchange.com/questions/550060/set-minimal-jre-version-to-deb-package-dependency
RN
I've modified my subscriptions, but I don't recall what is default. Do we have just stats.i2p in there for address helper by default?
dr|z3d
RN: also notbob.i2p
dr|z3d
if you mean for jump links.
RN
ok. was notbob in there for 2.1.0?
dr|z3d
been there for a few versions now.
RN
we have a new user unable to load skank.i2p without using b32. Trying to figure out why.
dr|z3d
you'll only have the jump link providers that are set at install time.
dr|z3d
if user can't access skank.i2p directly, it's because it's not in his addressbook.
RN
and those include notbob. so that dashes my theory.
dr|z3d
notbob isn't included as a default subscription host.
dr|z3d
however, notbob.i2p is supplied with the default hosts list.
dr|z3d
so adding notbob.i2p/hosts.txt to susidns subscriptions, and then waiting until it successfully polls, is one way of sorting out said user's issues.
RN
gotcha
RN
thanks
dr|z3d
if you think skank.i2p should be in the default canon i2p hostlist, badger eyedeekay :)
RN
:)
RN
I think a working jump-link should be in default install
RN
that'll take a bit of discussion
dr|z3d
for new and recent installs, notbob's jump link is there. and another that polls notbob iirc, hottuna's.
dr|z3d
as mentioned, if the install is older or is using an older config dir, only the jump hosts available at the time of install will be available, they don't update post-install.
eyedeekay
Hey those look like 2 debian packages that have cleared launchpad to me, looks like I just copy focal to everything after focal and ubuntu is done...
RN
I think we have them sorted for now.
dr|z3d
\o/ eyedeekay