IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2023/03/14
@eyedeekay
&eche|on
&kytv
&zzz
+RN
+RN_
+T3s|4
+acetone
+dr|z3d
+hk
+orignal
+postman
+weko
+wodencafe
An0nm0n
Arch
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest21357
Irc2PGuest21881
Irc2PGuest32033
Leopold_
Nausicaa
Onn4l7h
Onn4|7h
Over1
R4SAS
Sisyphus
Sleepy
Soni
T3s|4_
aargh2
anon2
b3t4f4c3
bak83
boonst
cancername
cumlord
dr4wd3
eyedeekay_bnc
hagen_
khb
not_bob_afk
plap
poriori
profetikla
r3med1tz-
rapidash
shiver_
solidx66
tr
u5657
uop23ip
w8rabbit
x74a6
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 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