Released today. Reproducible: Always
I don't want to maintain this but I already have a raft of fixes lined up so I'll take this.
Created attachment 404686 [details, diff] i2p-0.9.20_fix-paths.patch Path patch from 0.9.18 doesn't fit to 0.9.20. Attaching updated one.
Created attachment 404688 [details, diff] i2p.initd-0.9.20.patch Shipped with 0.9.18 version from gentoo overlay start script fails to start operable daemon: console works OK, but other connections failes. Error message: Jun 6 13:22:34 tux i2p[9761]: Unable to write to the configured log file: /var/lib/i2p/.i2p/wrapper.log (Нет такого файла или каталога) Jun 6 13:22:34 tux i2p[9761]: Unable to write to the default log file: wrapper.log (Отказано в доступе) Accordingly to FHS nobody but package management system should write anywhere excepting /home, /var and /tmp, but oryginally i2p tries. And reasonably failes. Attaching patch for OpenRC init script. Probably, similiar fix should be performed in systems unit.
Created attachment 404690 [details, diff] i2p-0.9.20.ebuild.patch Attaching patch for update ebuild 0.9.18 to 0.9.20: Added systemd use flag to install systemd unit only on systemd installations, creation of temporary writable directories and removed ewarn message for non-existing directory.
I've checked: built with attached patches i2p-0.9.20 works fine. At the time when original 0.9.18 from tree — do not works. So, after bumping version 0.9.20 we should either update or remove 0.9.18.
Update: I've been given proxy-maintainer and aim to update i2p asap. Thanks to zlogene for this and his support. A draft ebuild should be posted relatively soon. There will be little changes, mostly an update for the version but also to fix the SunEC (discussed below) issues. Thanks to Sergey for posting patches, it is very helpful as a newer contributor. Currently, we are awaiting a more thorough investigation into an issue with SunEC and its ECDSA provider code. You can read more about this upstream: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2497 For some reason, the SunEC bug causes i2p to believe ECDSA support exists, yet Java fails with a KeyException when i2p tries to use it. I believe this is what Sergey was referring to when he said "other connection fails". i2p is dependent on ECDSA to be able to function.
(In reply to stanley - Security Padawan from comment #6) > Update: > > I've been given proxy-maintainer and aim to update i2p asap. Thanks to > zlogene for this and his support. > > A draft ebuild should be posted relatively soon. There will be little > changes, mostly an update for the version but also to fix the SunEC > (discussed below) issues. Thanks to Sergey for posting patches, it is very > helpful as a newer contributor. > > Currently, we are awaiting a more thorough investigation into an issue with > SunEC and its ECDSA provider code. You can read more about this upstream: > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2497 > > For some reason, the SunEC bug causes i2p to believe ECDSA support exists, > yet Java fails with a KeyException when i2p tries to use it. > > I believe this is what Sergey was referring to when he said "other > connection fails". i2p is dependent on ECDSA to be able to function. s/zlogene/zlg/. Sorry to both, but your names are kind of similar ;).
(In reply to stanley - Security Padawan from comment #6) > Update: > > I've been given proxy-maintainer and aim to update i2p asap. Thanks to > zlogene for this and his support. > > A draft ebuild should be posted relatively soon. There will be little > changes, mostly an update for the version but also to fix the SunEC > (discussed below) issues. Thanks to Sergey for posting patches, it is very > helpful as a newer contributor. > > Currently, we are awaiting a more thorough investigation into an issue with > SunEC and its ECDSA provider code. You can read more about this upstream: > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2497 > > For some reason, the SunEC bug causes i2p to believe ECDSA support exists, > yet Java fails with a KeyException when i2p tries to use it. > > I believe this is what Sergey was referring to when he said "other > connection fails". i2p is dependent on ECDSA to be able to function. Hey, great to see that you're already beginning work on this! I'm not sure if you were aware, but given our individual schedules and possible QA issues going forward, it's a bad idea for either of us (proxy or dev) to indicate a time on a fix or update, since we never know when something might crop up. What we think will take 5 minutes might take 5 hours, etc. You could post an updated patch and I may not have the time to commit it until the weekend or something, etc. My other concern is probably obvious to you and/or others, but I wanted to clarify: your ebuild updates should be attached as patches to the existing ebuilds. When I was a proxy-maint, I copied gentoo-x86 ebuilds from my local portage tree to an overlay, where I then hacked on them. When I suggested fixes, a quick `diff -aurN old_file new_file > foobar.patch` was attached to my comments. Sergey's set a good example in this bug. Again, it's probably obvious, but I wanted to be sure we're on the same page, and I forgot to cover it in our prior correspondence. :) I look forward to seeing your patches! I'll try to make some time to read about the bug so I'm kept in the loop wrt future patches.
(In reply to stanley - Security Padawan from comment #6) > I believe this is what Sergey was referring to when he said "other > connection fails". i2p is dependent on ECDSA to be able to function. No! You aren't right. I've quoted system's log: that issue was entirely infrastructural, doesn't match any cryptography at all, i2p tried to write in the distro-default directories, which are read-only for system-wide installation. BTW, suggested in my patch solution just works, but may be not perfect. And some related offtopic ☺ (In reply to Daniel Campbell from comment #8) > My other concern is probably obvious to you and/or others, but I wanted to > clarify: your ebuild updates should be attached as patches to the existing > ebuilds. When I was a proxy-maint, I copied gentoo-x86 ebuilds from my local > portage tree to an overlay, where I then hacked on them. When I suggested > fixes, a quick `diff -aurN old_file new_file > foobar.patch` was attached to > my comments. Sergey's set a good example in this bug. Again, it's probably > obvious, but I wanted to be sure we're on the same page, and I forgot to > cover it in our prior correspondence. :) What about proper documenting this case (when new version correctly builds with simply renamed ebuild in version bump bug you don't need to attach any file, when it's better to provide ebuild patch and when to attach a new ebuild file itself) in https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide ? For now this article just recommends to attach ebuild file, as an optional step. Recommendation to use patches for ebuilds is just a Bugzilla's Tradition.
(In reply to Sergey S. Starikoff from comment #9) > And some related offtopic ☺ > (In reply to Daniel Campbell from comment #8) > > My other concern is probably obvious to you and/or others, but I wanted to > > clarify: your ebuild updates should be attached as patches to the existing > > ebuilds. When I was a proxy-maint, I copied gentoo-x86 ebuilds from my local > > portage tree to an overlay, where I then hacked on them. When I suggested > > fixes, a quick `diff -aurN old_file new_file > foobar.patch` was attached to > > my comments. Sergey's set a good example in this bug. Again, it's probably > > obvious, but I wanted to be sure we're on the same page, and I forgot to > > cover it in our prior correspondence. :) > > What about proper documenting this case (when new version correctly builds > with simply renamed ebuild in version bump bug you don't need to attach any > file, when it's better to provide ebuild patch and when to attach a new > ebuild file itself) in > https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide ? > For now this article just recommends to attach ebuild file, as an optional > step. > Recommendation to use patches for ebuilds is just a Bugzilla's Tradition. That's a good point. If no edits to the ebuild are needed, then obviously a patch is also unneeded. Thanks for pointing out the wiki page. I'll talk to the wiki team tonight about consistency on that page and determine a concrete guideline.
Created attachment 407134 [details, diff] i2p-0.9.18.ebuild.patch I am struggling to find the time for this so I'll attach the many changes I have made in case you want to take it forward. The patch is against 0.9.18 but should equally apply to 0.9.20. Here's a list of the changes. * Remove some seemingly unneeded dependencies. * Add some missing dependencies. * SLOT the remaining Java dependencies. * Call java-pkg-2_pkg_setup, very important! * Remove or symlink over the bundled jars. * I normally prefer EANT_GENTOO_CLASSPATH over java-pkg_jar-from but in this case, build.xml expects to find the actual jar files. * More miscellaneous clean-up. I can't remember exactly where I was at with src_prepare. I'd commented out the jakarta-jstl line, possibly because it should now use tomcat-jstl or possibly because javac doesn't seem to need it, though build.xml still tries to install it. In truth, I hadn't fully figured out how this was going to work. As things stand, I think build.xml will use the symlinks to install copies of the unbundled jars to lib, which is better than the existing ebuild but still not great. What probably should happen is that symlinks should be present in the final installation to avoid the duplication. We can't pass these jars in the CLASSPATH like we normally do because it would lead to a situation like bug #453212. I'm not even sure it would work at all. The init script needs addressing too. Calling /usr/bin/java would actually be better than calling /etc/java-config-2/current-system-vm/bin/java. Ideally the ebuild would create a launcher using java-pkg_dolauncher as this brings it in line with other Java packages but the downside is that *all* the jars under lib would be added to the CLASSPATH, again falling foul of bug #453212. Perhaps some of these jars should be installed with doins rather than dojar and I wanted to address bug #453212 first to find the best approach but I've not had the time yet. Remember that this ebuild ships with several webapps beyond the core daemon and you should do your best to test that these also work as expected. If you want me to review any changes before they get committed, just let me know. Good luck!
Created attachment 407584 [details] build.log.Z (In reply to James Le Cuirot from comment #11) > Created attachment 407134 [details, diff] [details, diff] > i2p-0.9.18.ebuild.patch > This ebuild failes with error message: BUILD FAILED /var/tmp/portage/net-p2p/i2p-0.9.20-r1/work/i2p-0.9.20/build.xml:1305: Warning: Could not find file /var/tmp/portage/net-p2p/i2p-0.9.20-r1/work/i2p-0.9.20/apps/susidns/src/WEB-INF/lib/jstl.jar to copy. Attaching complete build log.
(In reply to Sergey S. Starikoff from comment #12) > This ebuild failes with error message: I didn't say I had it in a working state. ;) If I had then I probably would have committed it.
*** Bug 556426 has been marked as a duplicate of this bug. ***
0.9.21 is out
0.9.22 is out
(In reply to neko259 from comment #16) > 0.9.22 is out Works with simply renamed my version of 0.9.20 ebuild. P.S. What about proper rename of bug's title?
commit 8e3231f (HEAD, master) Author: Patrice Clement <monsieurp@gentoo.org> Date: Sat Oct 17 21:57:35 2015 +0000 net-p2p/i2p: Version bump. Remove dependency on dev-java/jakarta-jstl. Fixes bug 551050 and bug 551032. Package-Manager: portage-2.2.20.1 Signed-off-by: Patrice Clement <monsieurp@gentoo.org> create mode 100644 net-p2p/i2p/files/i2p-0.9.22_fix-paths.patch create mode 100644 net-p2p/i2p/i2p-0.9.22.ebuild
