Gentoo i2p package is broken: shows "Network: SymmetricNAT" and won't load any eepsite saying "Website Not Found in Addressbook". While i2p installed manually from the .jar on the official website, on the same machine, on the same network, shows "Network: Firewalled" and loads eepsites just fine. Reproducible: Always Steps to Reproduce: 1.emerge net-vpn/i2p 2.configure browser (proxy http 127.0.0.1:4444) 3.see "Network: SymmetricNAT" 4.try to load any eepsite like notbob.i2p Actual Results: "Website Not Found in Addressbook" Expected Results: eepsite loading it complains about even built in addresses like notbob.i2p or i2p-projekt.i2p trying to connect to 127.0.0.1/6667 with hexchat I get "java.net.UnknownHostException: Could not resolve irc.postman.i2p"
I think we had someone mention an issue like this on IRC a few weeks ago but it wasn't really clear what was going on. It's a bit weird there's two different issues (the network bit *and* the address book; the previous user had mentioned address book but I don't recall if they mentioned anything else). Can you include emerge --info in an attachment too? Thanks.
Created attachment 868935 [details] emerge --info
(In reply to Sam James from comment #1) > I think we had someone mention an issue like this on IRC a few weeks ago but > it wasn't really clear what was going on. > > It's a bit weird there's two different issues (the network bit *and* the > address book; the previous user had mentioned address book but I don't > recall if they mentioned anything else). > > Can you include emerge --info in an attachment too? Thanks. Likely, that other person just didn't notice the network bit. I suspect the address book not working is simply the result of network not working - the address book never gets the chance to be downloaded initially.
tharvik, can you take a look please?
this is two separated issues from what I'm reading. The network issue isn't really one, i2p is just warning that it might not be able to participate as fully as in other network setup. Nothing much we can do to fix it. Maybe it The addressbook however is clearly problematic. It triggers when installing a fresh version of i2p: a migration of the install at /usr/share/i2p to the user directory at /var/lib/i2p takes place but miscopy the hosts.txt file, putting it in the config dir instead of the router dir. For a temporary workaround, you can manually import hosts.txt via the addressbook configuration in the browser and restart the router. I'll discuss with upstream on the best way to fix this.
I think it is one issue - the maintainer arbitrarily deciding to cut out pieces of code because "too much code drift" - see src_prepare in the ebuild. There is nothing to discuss with the upstream - there is no issue with the upstream version of i2p.
(In reply to wuss.puss from comment #6) > I think it is one issue - the maintainer arbitrarily deciding to cut out > pieces of code because "too much code drift" - see src_prepare in the > ebuild. > > There is nothing to discuss with the upstream - there is no issue with the > upstream version of i2p. Discussing with upstream does not mean it is an upstream bug, it means the maintainer in Gentoo wants to ask about how to best reconcile the two needs.
(In reply to wuss.puss from comment #6) > I think it is one issue - the maintainer arbitrarily deciding to cut out > pieces of code because "too much code drift" - see src_prepare in the > ebuild. > I don't think that's quite right. I think the comment is supposed to communicate that something is *not* being unbundled because the version inside of I2P is too different from the upstream version (too much drift). What _is_ mysterious though is that at a skim, it looks like lots of those things in the comment aren't actually excluded (?).
(In reply to Sam James from comment #7) > (In reply to wuss.puss from comment #6) > > There is nothing to discuss with the upstream - there is no issue with the > > upstream version of i2p. > > Discussing with upstream does not mean it is an upstream bug, it means the > maintainer in Gentoo wants to ask about how to best reconcile the two needs. Thanks Sam for the explanation. Before putting my own fixes that gets deployed to every Gentoo users, I want to have upstream confirmation on the best way to resolve an issue. After all, they have the best knowledge on how the code will evolve. In this specifice case, it is a bug with upstream, but triggered by our way of installing. You can follow up on the issue @ https://github.com/i2p/i2p.i2p/issues/69 (In reply to Sam James from comment #8) > (In reply to wuss.puss from comment #6) > > I think it is one issue - the maintainer arbitrarily deciding to cut out > > pieces of code because "too much code drift" - see src_prepare in the > > ebuild. > > > > I don't think that's quite right. I think the comment is supposed to > communicate that something is *not* being unbundled because the version > inside of I2P is too different from the upstream version (too much drift). Yep, that's the list of ~packages I wasn't able to unbundle. I agree, the comment is not obvious with non-maintainer of the package, I'll add a few words on a next release. > What _is_ mysterious though is that at a skim, it looks like lots of those > things in the comment aren't actually excluded (?). Hum, I looked at the list again and I think it is correct. FWIW most of the bundled packages are copied sources files, not jars, so java-pkg_clean doesn't remove theses. Which ones do you have in mind?
>Discussing with upstream does not mean it is an upstream bug, it means the maintainer in Gentoo wants to ask about how to best reconcile the two needs. The needs in question being the need of the users to have working software and the need of the maintainer to arbitrarily cut out some code?
(In reply to wuss.puss from comment #10) > >Discussing with upstream does not mean it is an upstream bug, it means the maintainer in Gentoo wants to ask about how to best reconcile the two needs. > > The needs in question being the need of the users to have working software > and the need of the maintainer to arbitrarily cut out some code? Again, not what happened. You can read the link upstream bug. Please leave it.
(That is: it has absolutely nothing to do with bundling or unbundling.)
(In reply to tharvik from comment #9) > (In reply to Sam James from comment #7) > > (In reply to wuss.puss from comment #6) > > > There is nothing to discuss with the upstream - there is no issue with the > > > upstream version of i2p. > > > > Discussing with upstream does not mean it is an upstream bug, it means the > > maintainer in Gentoo wants to ask about how to best reconcile the two needs. > Thanks Sam for the explanation. > > Before putting my own fixes that gets deployed to every Gentoo users, I want > to have upstream confirmation on the best way to resolve an issue. After > all, they have the best knowledge on how the code will evolve. > > In this specifice case, it is a bug with upstream, but triggered by our way > of installing. You can follow up on the issue @ > https://github.com/i2p/i2p.i2p/issues/69 > > [...] Could you make a PR to adjust to the other way of installing then? We've had a few people confused by it and I worry that'll continue. (I'm sure this is on your list, but if you could do a workaround for now, that'd be great.) > > > What _is_ mysterious though is that at a skim, it looks like lots of those > > things in the comment aren't actually excluded (?). > Hum, I looked at the list again and I think it is correct. FWIW most of the > bundled packages are copied sources files, not jars, so java-pkg_clean > doesn't remove theses. Which ones do you have in mind? Ah, I was confused by the comment vs the stuff being removed underneath. I was being silly.
(In reply to Sam James from comment #13) > (In reply to tharvik from comment #9) > > (In reply to Sam James from comment #7) > > > (In reply to wuss.puss from comment #6) > > > > There is nothing to discuss with the upstream - there is no issue with the > > > > upstream version of i2p. > > > > > > Discussing with upstream does not mean it is an upstream bug, it means the > > > maintainer in Gentoo wants to ask about how to best reconcile the two needs. > > Thanks Sam for the explanation. > > > > Before putting my own fixes that gets deployed to every Gentoo users, I want > > to have upstream confirmation on the best way to resolve an issue. After > > all, they have the best knowledge on how the code will evolve. > > > > In this specifice case, it is a bug with upstream, but triggered by our way > > of installing. You can follow up on the issue @ > > https://github.com/i2p/i2p.i2p/issues/69 > > > > [...] > > Could you make a PR to adjust to the other way of installing then? We've had > a few people confused by it and I worry that'll continue. > > (I'm sure this is on your list, but if you could do a workaround for now, > that'd be great.) I was hoping to fix it with the december release of I2P, but yeah, let's make a revbump for the time being. It is not a perfect process but works for "old" user dirs and fresh ones. Let's hope that it won't break too many setups. PR at https://github.com/gentoo/gentoo/pull/34311 (In reply to wuss.puss from comment #10) > >Discussing with upstream does not mean it is an upstream bug, it means the maintainer in Gentoo wants to ask about how to best reconcile the two needs. > > The needs in question being the need of the users to have working software > and the need of the maintainer to arbitrarily cut out some code? I'd happily review any PR you do to actually fix this issue.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ef4a3ca3e8264b38407ceea43760167e30ec081a commit ef4a3ca3e8264b38407ceea43760167e30ec081a Author: Valérian Rousset <tharvik@users.noreply.github.com> AuthorDate: 2023-12-16 14:05:32 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-05 14:12:03 +0000 net-vpn/i2p: revbump to fix separated user dirs Closes: https://bugs.gentoo.org/913176 Signed-off-by: Valérian Rousset <tharvik@users.noreply.github.com> Closes: https://github.com/gentoo/gentoo/pull/34311 Signed-off-by: Sam James <sam@gentoo.org> net-vpn/i2p/i2p-2.3.0-r1.ebuild | 291 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 291 insertions(+)