public inbox for nncp-devel@lists.stargrave.org
Atom feed
* Tarballs availability over IPFS
@ 2026-02-19 21:22 Sergey Matveev
2026-02-19 23:14 ` John Goerzen
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Sergey Matveev @ 2026-02-19 21:22 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 6906 bytes --]
Greetings!
www.nncpgo.org is hosted on two servers in Russia: physical one at my
home (with additional VPS to get IPv6 connectivity) in Moscow region,
virtual one somewhere in St.Petersburg. Three different ASes involved
in all that connectivity.
Several years ago some foreign networks started to reject/ban traffic
to/from Russian networks. Hetzner and other German ones come to mind
first as an example. Cloudflare and OVH were also known to partially
block access to their networks too.
Couple of months ago network connectivity problems appeared on Russian's
side to several big cloud/CDN providers, disrupting overall connectivity
even more.
Recently I discovered that https://nncp.mirrors.quux.org/ mirror is
not accessible via any of my links I got. It is hosted on Canadian OVH.
Sometimes no TCP connection can be made, sometimes it is stuck after
a several KiBs. At least sometimes I could get small .meta4 files to
check if that site is updated. Waiting for reply from John, but I doubt
we got connectivity between our nodes for ssh+rsync-ing the website
(maybe even email is not exchanged between us?).
I am aware only of Western-located websites capable of hosting free
software projects (SourceForge, GitHub, similar ones). Because of
obvious reasons (of being under sanctions) there is no legal possibility
to use any of those services for hosting the tarballs/website. People
were suddenly banned (for example on GitHub) even just for visiting the
sanctioned regions.
Some Russian-based hosting companies still have data-centres at least in
Europe. Maybe that would be helpful, but I highly doubt, because they
still use their own ASes with Russian-related IP subnets. Maybe that
will bypass Russian-located curtain, but not the much earlier appeared
ones from the opposite sides.
I was thinking about additional alternative paths of getting NNCP
tarballs. Nearly all of decentralised filesharing solutions or anonymous
(at least pretending to be so) networks work pretty badly in practice.
For many years I tried from time to time building and using Tor
(actually it worked fine, no building issues), I2P (with OpenJDK was
always unusable; i2pd tend to work for a while, but soon any of the
published resources were not responding), RetroShare (have never
succeeded in building it), Freenet (tend to ate resources and soon stop
responding at all), YaCy (same as Freenet or I2P -- unusable because of
OpenJDK, I guess). GNUnet is only developer friendly and hardly was used
by any considerable amount of people. Maybe they work better on
GNU/Linux, but I tried building under FreeBSD solely.
One notable exception was Yggdrasil overlay network. Comparing to its
predecessor -- cjdns, which tended to segfault occasionally when
connected Hyperboria network, Yggdrasil is pretty stable and reliable,
as I can see for several years of its non-heavy usage. NNCP's Metalink4
.meta4 files contained y-reachable links (y.www.nncpgo.org) a long time
ago because of that.
I also considered BitTorrent for tarballs distribution. But that will
anyway need at least an initial connectivity between seeder and a
leecher, which are in practice will be easily in netsplit locations. And
frankly I just discovered that one of my computers behind NAT is not
able to get my own torrent from my own hosted tracker/seeder. Maybe
because it is BitTorrent v2 torrent and whatever hash-issues with the
tracker/DHT. Could not investigate that for considerable amount of time.
Tried three different clients, checked IPv4's NAT port forwarding, IPv6
firewall rules, still failed. Even BitTorrent, an old known technology
(although developing from time to time), is not so trivial to make work
and debug sometimes :-)
I had bad experience with IPFS nearly since its initial creation. Either
it downloads some binaries during building attempt -- removed immediately
after that unacceptable behaviour. Or it just does not build for unknown
reasons. Or it just does not build because its (or its dependencies)
code contains only *_linux.go files, failing to build under FreeBSD. Or
it segfaults/panics during ordinary operations. Or it became just stuck
and unable to share "hello world" file. I checked its progress once per
couple of years and every time it disappointed me.
Recently I recalled it and decided to examine again. It (kubo, reference
implementation on Go) builds fine (actually I had to fix the single
bash-script, because I do not have bash), without downloading something
without my permission and works without unexpected panics. Currently
have no claims to its workability. Although its DHT bootstrap nodes are
located in OVH and DigitalOcean networks, it was able too bootstrap.
So I will try to publish NNCP's tarballs additionally via IPFS. I
understand that NNCP itself can be used (by cooperation) through
additional intermediate hops to reach nncp.mirrors.quux.org mirror, but
all of the (thoughts) written above also applies to my other projects too.
% curl -s http://www.nncpgo.org/download/nncp-8.13.0.tar.xz.meta4 | perl -ne 'print if /(url|<file)/'
<file name="nncp-8.13.0.tar.xz">
<url priority="1" location="ru">http://www.nncpgo.org/download/nncp-8.13.0.tar.xz</url>
<url priority="1" location="ca">https://nncp.mirrors.quux.org/download/nncp-8.13.0.tar.xz</url>
<url priority="2" location="ru">https://www.nncpgo.org/download/nncp-8.13.0.tar.xz</url>
<url location="ru">http://y.www.nncpgo.org/download/nncp-8.13.0.tar.xz</url>
<url>ipfs://bafykbzaced7hi62ftqz4laqcqlty356l5x2etioe5omkpsmud5xcw357qfsbk/nncp-8.13.0.tar.xz</url>
<file name="nncp-8.13.0.tar.xz.asc">
<url priority="1" location="ru">http://www.nncpgo.org/download/nncp-8.13.0.tar.xz.asc</url>
<url priority="1" location="ca">https://nncp.mirrors.quux.org/download/nncp-8.13.0.tar.xz.asc</url>
<url priority="2" location="ru">https://www.nncpgo.org/download/nncp-8.13.0.tar.xz.asc</url>
<url location="ru">http://y.www.nncpgo.org/download/nncp-8.13.0.tar.xz.asc</url>
<url>ipfs://bafykbzaced7hi62ftqz4laqcqlty356l5x2etioe5omkpsmud5xcw357qfsbk/nncp-8.13.0.tar.xz.asc</url>
<file name="nncp-8.13.0.tar.xz.sig">
<url priority="1" location="ru">http://www.nncpgo.org/download/nncp-8.13.0.tar.xz.sig</url>
<url priority="1" location="ca">https://nncp.mirrors.quux.org/download/nncp-8.13.0.tar.xz.sig</url>
<url priority="2" location="ru">https://www.nncpgo.org/download/nncp-8.13.0.tar.xz.sig</url>
<url location="ru">http://y.www.nncpgo.org/download/nncp-8.13.0.tar.xz.sig</url>
<url>ipfs://bafykbzaced7hi62ftqz4laqcqlty356l5x2etioe5omkpsmud5xcw357qfsbk/nncp-8.13.0.tar.xz.sig</url>
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tarballs availability over IPFS
2026-02-19 21:22 Tarballs availability over IPFS Sergey Matveev
@ 2026-02-19 23:14 ` John Goerzen
2026-02-20 16:10 ` Sergey Matveev
2026-02-20 10:47 ` Marek Küthe
2026-04-17 10:26 ` Sergey Matveev
2 siblings, 1 reply; 6+ messages in thread
From: John Goerzen @ 2026-02-19 23:14 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
Hi Sergey,
Sorry for the slow response here!
I've done some experimentation, and initially it looked like IPv4
connectivity was broken... but as I was digging into it, IPv6
connectivity worked, and then so did IPv4, so I'm puzzled.
I also discovered that a known_hosts file had reverted to a previous
version, and no longer had the record for master.git.stargrave.org.
I fixed that and had a successful sync!
I'm noticing that the direct links to the downloads in the Tarballs.html
page are gone. That does make it more difficult for people, since meta4
software isn't common and opening it up to manually extract a URL isn't
necessarily an easy thing for people. It would probably be good to have
the tar links again.
- John
On Fri, Feb 20 2026, Sergey Matveev wrote:
> Greetings!
>
> www.nncpgo.org is hosted on two servers in Russia: physical one at my
> home (with additional VPS to get IPv6 connectivity) in Moscow region,
> virtual one somewhere in St.Petersburg. Three different ASes involved
> in all that connectivity.
>
> Several years ago some foreign networks started to reject/ban traffic
> to/from Russian networks. Hetzner and other German ones come to mind
> first as an example. Cloudflare and OVH were also known to partially
> block access to their networks too.
>
> Couple of months ago network connectivity problems appeared on Russian's
> side to several big cloud/CDN providers, disrupting overall connectivity
> even more.
>
> Recently I discovered that https://nncp.mirrors.quux.org/ mirror is
> not accessible via any of my links I got. It is hosted on Canadian OVH.
> Sometimes no TCP connection can be made, sometimes it is stuck after
> a several KiBs. At least sometimes I could get small .meta4 files to
> check if that site is updated. Waiting for reply from John, but I doubt
> we got connectivity between our nodes for ssh+rsync-ing the website
> (maybe even email is not exchanged between us?).
>
> I am aware only of Western-located websites capable of hosting free
> software projects (SourceForge, GitHub, similar ones). Because of
> obvious reasons (of being under sanctions) there is no legal possibility
> to use any of those services for hosting the tarballs/website. People
> were suddenly banned (for example on GitHub) even just for visiting the
> sanctioned regions.
>
> Some Russian-based hosting companies still have data-centres at least in
> Europe. Maybe that would be helpful, but I highly doubt, because they
> still use their own ASes with Russian-related IP subnets. Maybe that
> will bypass Russian-located curtain, but not the much earlier appeared
> ones from the opposite sides.
>
> I was thinking about additional alternative paths of getting NNCP
> tarballs. Nearly all of decentralised filesharing solutions or anonymous
> (at least pretending to be so) networks work pretty badly in practice.
>
> For many years I tried from time to time building and using Tor
> (actually it worked fine, no building issues), I2P (with OpenJDK was
> always unusable; i2pd tend to work for a while, but soon any of the
> published resources were not responding), RetroShare (have never
> succeeded in building it), Freenet (tend to ate resources and soon stop
> responding at all), YaCy (same as Freenet or I2P -- unusable because of
> OpenJDK, I guess). GNUnet is only developer friendly and hardly was used
> by any considerable amount of people. Maybe they work better on
> GNU/Linux, but I tried building under FreeBSD solely.
>
> One notable exception was Yggdrasil overlay network. Comparing to its
> predecessor -- cjdns, which tended to segfault occasionally when
> connected Hyperboria network, Yggdrasil is pretty stable and reliable,
> as I can see for several years of its non-heavy usage. NNCP's Metalink4
> .meta4 files contained y-reachable links (y.www.nncpgo.org) a long time
> ago because of that.
>
> I also considered BitTorrent for tarballs distribution. But that will
> anyway need at least an initial connectivity between seeder and a
> leecher, which are in practice will be easily in netsplit locations. And
> frankly I just discovered that one of my computers behind NAT is not
> able to get my own torrent from my own hosted tracker/seeder. Maybe
> because it is BitTorrent v2 torrent and whatever hash-issues with the
> tracker/DHT. Could not investigate that for considerable amount of time.
> Tried three different clients, checked IPv4's NAT port forwarding, IPv6
> firewall rules, still failed. Even BitTorrent, an old known technology
> (although developing from time to time), is not so trivial to make work
> and debug sometimes :-)
>
> I had bad experience with IPFS nearly since its initial creation. Either
> it downloads some binaries during building attempt -- removed immediately
> after that unacceptable behaviour. Or it just does not build for unknown
> reasons. Or it just does not build because its (or its dependencies)
> code contains only *_linux.go files, failing to build under FreeBSD. Or
> it segfaults/panics during ordinary operations. Or it became just stuck
> and unable to share "hello world" file. I checked its progress once per
> couple of years and every time it disappointed me.
>
> Recently I recalled it and decided to examine again. It (kubo, reference
> implementation on Go) builds fine (actually I had to fix the single
> bash-script, because I do not have bash), without downloading something
> without my permission and works without unexpected panics. Currently
> have no claims to its workability. Although its DHT bootstrap nodes are
> located in OVH and DigitalOcean networks, it was able too bootstrap.
>
> So I will try to publish NNCP's tarballs additionally via IPFS. I
> understand that NNCP itself can be used (by cooperation) through
> additional intermediate hops to reach nncp.mirrors.quux.org mirror, but
> all of the (thoughts) written above also applies to my other projects too.
>
> % curl -s http://www.nncpgo.org/download/nncp-8.13.0.tar.xz.meta4 | perl -ne 'print if /(url|<file)/'
> <file name="nncp-8.13.0.tar.xz">
> <url priority="1" location="ru">http://www.nncpgo.org/download/nncp-8.13.0.tar.xz</url>
> <url priority="1" location="ca">https://nncp.mirrors.quux.org/download/nncp-8.13.0.tar.xz</url>
> <url priority="2" location="ru">https://www.nncpgo.org/download/nncp-8.13.0.tar.xz</url>
> <url location="ru">http://y.www.nncpgo.org/download/nncp-8.13.0.tar.xz</url>
> <url>ipfs://bafykbzaced7hi62ftqz4laqcqlty356l5x2etioe5omkpsmud5xcw357qfsbk/nncp-8.13.0.tar.xz</url>
> <file name="nncp-8.13.0.tar.xz.asc">
> <url priority="1" location="ru">http://www.nncpgo.org/download/nncp-8.13.0.tar.xz.asc</url>
> <url priority="1" location="ca">https://nncp.mirrors.quux.org/download/nncp-8.13.0.tar.xz.asc</url>
> <url priority="2" location="ru">https://www.nncpgo.org/download/nncp-8.13.0.tar.xz.asc</url>
> <url location="ru">http://y.www.nncpgo.org/download/nncp-8.13.0.tar.xz.asc</url>
> <url>ipfs://bafykbzaced7hi62ftqz4laqcqlty356l5x2etioe5omkpsmud5xcw357qfsbk/nncp-8.13.0.tar.xz.asc</url>
> <file name="nncp-8.13.0.tar.xz.sig">
> <url priority="1" location="ru">http://www.nncpgo.org/download/nncp-8.13.0.tar.xz.sig</url>
> <url priority="1" location="ca">https://nncp.mirrors.quux.org/download/nncp-8.13.0.tar.xz.sig</url>
> <url priority="2" location="ru">https://www.nncpgo.org/download/nncp-8.13.0.tar.xz.sig</url>
> <url location="ru">http://y.www.nncpgo.org/download/nncp-8.13.0.tar.xz.sig</url>
> <url>ipfs://bafykbzaced7hi62ftqz4laqcqlty356l5x2etioe5omkpsmud5xcw357qfsbk/nncp-8.13.0.tar.xz.sig</url>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tarballs availability over IPFS
2026-02-19 21:22 Tarballs availability over IPFS Sergey Matveev
2026-02-19 23:14 ` John Goerzen
@ 2026-02-20 10:47 ` Marek Küthe
2026-02-20 18:08 ` Sergey Matveev
2026-04-17 10:26 ` Sergey Matveev
2 siblings, 1 reply; 6+ messages in thread
From: Marek Küthe @ 2026-02-20 10:47 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]
On Fri, 20 Feb 2026 00:22:35 +0300
Sergey Matveev <stargrave@stargrave•org> wrote:
> Several years ago some foreign networks started to reject/ban traffic
> to/from Russian networks. Hetzner and other German ones come to mind
> first as an example. Cloudflare and OVH were also known to partially
> block access to their networks too.
Do you have any further information on this? Is there a list of
providers who do this? For my own projects, I would like to avoid
hosting providers that artificially restrict connectivity.
> I am aware only of Western-located websites capable of hosting free
> software projects (SourceForge, GitHub, similar ones). Because of
> obvious reasons (of being under sanctions) there is no legal possibility
> to use any of those services for hosting the tarballs/website. People
> were suddenly banned (for example on GitHub) even just for visiting the
> sanctioned regions.
Have you tried Codeberg (https://codeberg.org/)? It is run by a
non-profit association in Germany. I would be surprised if they banned
someone without reason (at least for me, nationality is not a reason in
the FLOSS community).
> One notable exception was Yggdrasil overlay network. Comparing to its
> predecessor -- cjdns, which tended to segfault occasionally when
> connected Hyperboria network, Yggdrasil is pretty stable and reliable,
> as I can see for several years of its non-heavy usage. NNCP's Metalink4
> .meta4 files contained y-reachable links (y.www.nncpgo.org) a long time
> ago because of that.
I didn't know that the NNCP website is also available via Yggdrasil.
Maybe you could add it to the internal services so that it's easier to
find?
https://yggdrasil-network.github.io/services.html
--
Marek Küthe
m.k@mk16•de
er/ihm he/him
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tarballs availability over IPFS
2026-02-19 23:14 ` John Goerzen
@ 2026-02-20 16:10 ` Sergey Matveev
0 siblings, 0 replies; 6+ messages in thread
From: Sergey Matveev @ 2026-02-20 16:10 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]
Remark: my initial message was mistakenly sent to previously existed .ru
domain, and John replied to me and that non-existing domain. That is why
I manually resent his message to the list. My bad. Still left .ru domain
in my mail configuration :-)
*** John Goerzen [2026-02-19 17:14]:
>Sorry for the slow response here!
No hurry!
>I fixed that and had a successful sync!
Great! I really hoped that at least SSH will be working between our
hosts, which would be more than enough. All those DPIs bring much
uncertainties. Glad that your mirror stays more than useful because of
that! Thanks you!
>I'm noticing that the direct links to the downloads in the Tarballs.html
>page are gone. That does make it more difficult for people, since meta4
>software isn't common and opening it up to manually extract a URL isn't
>necessarily an easy thing for people. It would probably be good to have
>the tar links again.
I assumed that user will display those XML .meta4 files and manually
will be able to choose preferred way of downloading. Definitely there is
not much software capable of using those metalinks directly.
Well, if the lack of (single) direct link is so noticeable, then... ok,
returned it back. Was not completely sure about that idea too.
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tarballs availability over IPFS
2026-02-20 10:47 ` Marek Küthe
@ 2026-02-20 18:08 ` Sergey Matveev
0 siblings, 0 replies; 6+ messages in thread
From: Sergey Matveev @ 2026-02-20 18:08 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 3697 bytes --]
Greetings, Marek!
*** Marek Küthe [2026-02-20 10:47]:
>Do you have any further information on this? Is there a list of
>providers who do this? For my own projects, I would like to avoid
>hosting providers that artificially restrict connectivity.
No, did not note those events. I remember that for example GNU Guix
project quickly became unavailable in 2022:
https://lists.gnu.org/archive/html/help-guix/2022-03/msg00004.html
issues.guix.gnu.org is still not available at all, having its IP in
ASN: 210482, City: Frankfurt am Main, Region: Hesse Country: Germany.
lists.gnu.org was unavailable for a long time (something like two
years), but now works fine.
No more details I can remember, but often heard from other
maillists/blogs that their upstream (trunk) networks blocked (some)
foreign networks. I am subscribed to 500-600 feeds and keep
metainformation where they are located (what CDN/cloud provider), so
when either of sites is unavailable, I look at their IP addresses,
traceroutes and similar things. But I kept no detailed statistics/logs.
Some of them work occasionally. Some of the sites moved to different
locations. Now it more unclear, in case of unavailability, to tell who
is responsible for that, because so many hops and participants involved.
>Have you tried Codeberg (https://codeberg.org/)? It is run by a
>non-profit association in Germany. I would be surprised if they banned
>someone without reason (at least for me, nationality is not a reason in
>the FLOSS community).
Have not tried, no. Actually I do not remember when last time I used any
source code hosting facility, as everything is hosted on my servers. But
connectivity issues of Splinternet forced me to revive memories about
those services.
I can remember no official bans related directly to nationality, but of
sanctions. Legally it is easier not to deal with a person who possibly
has any connections to sanctioned entities. I remember that FSF clearly
stated that it had to comply with sanctions lists. And it is also
non-profit organisation, like Codeberg. I *assume* that it also had to
comply with German laws, which automatically means complying with EU
sanction-relation ones. But I do not all those differences in laws and
regulations, just an assumption.
Tried to register on it, but it tells that I have got to run their
JS-application to proceed further. Well... maybe some day I will try
again. In general I do not have JS-capable browser and refuse to run
some unknown downloaded software. Only exception I remember is to use
separate machine with LiveCD only to use my domain name registrar's
web-interface, as there is absolutely no choice among them, and at least
it is required once per year to prolong them. But I am disappointed that
Codeberg requires that (because of Forgejo underneath?) :-(
>I didn't know that the NNCP website is also available via Yggdrasil.
>Maybe you could add it to the internal services so that it's easier to
>find?
>https://yggdrasil-network.github.io/services.html
In that case that single site has to have a separate IP address. My
Yggdrasil node uses single main IP address on which my ordinary clearnet
HTTP server listens. It has to get Host-header to understand what site
it must serve. All my y.www.nncpgo.org, y.www.stargrave.org,
y.www.cypherpunks.su sites has the same Yggdrasil entrypoint.
Well, why not? Will differentiate them indeed. I have got 54
services/domains shared on that single IP address, that was the main
reason I was lazy to deal with that :-)
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Tarballs availability over IPFS
2026-02-19 21:22 Tarballs availability over IPFS Sergey Matveev
2026-02-19 23:14 ` John Goerzen
2026-02-20 10:47 ` Marek Küthe
@ 2026-04-17 10:26 ` Sergey Matveev
2 siblings, 0 replies; 6+ messages in thread
From: Sergey Matveev @ 2026-04-17 10:26 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 982 bytes --]
Greetings!
Unfortunately I became disappointed with ipfs (again), because of its
relaying abilities. Shame on me, because I had to check that feature
before trying to use in practice.
I setup an isolated Jail environment with three nodes, where two of them
have restricted connectivity because of firewall. And after dozens of
configuration file changes I still was not able to relay the data
through the intermediate node. According to ipfs/libp2p's documentation
it should solve exactly that problem.
And also it leads to consumption of much (tens of gigabytes) "inactive"
memory on my FreeBSD. Seems that this is because of LevelDB, where
mmap-ed pages are copied from ZFS ARC and cached in that "inactive"
memory. And there is no other storage alternative for non-/blocks.
Making it very resource heavy.
So, getting rid of ipfs installation.
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-04-17 10:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-02-19 21:22 Tarballs availability over IPFS Sergey Matveev
2026-02-19 23:14 ` John Goerzen
2026-02-20 16:10 ` Sergey Matveev
2026-02-20 10:47 ` Marek Küthe
2026-02-20 18:08 ` Sergey Matveev
2026-04-17 10:26 ` Sergey Matveev