probably just sf.net's svn acting up. it sometimes throws weird errors that 
resolve itself after a time. i guess they get fixed on their servers. who knows.

anyway. what is it you are doing when it errs out? a complete checkout? what 
commands are you running? can you give some context?

..ede

On 14.08.2020 20:48, Eric wrote:
> Hi,
>
> I'm encountering a problem during the local migration (ra_serf: The server 
> sent a truncated HTTP response body) when I try to do it from revision 859 to 
> revision 6242.
>
> I tried to exclude the 'docs' folder to reduce the size of it, without much 
> success (still the same error after an hour or two during the migration 
> process).
>
> Could one of you try these two commands (as indicated here: 
> https://stackoverflow.com/questions/27267742/why-do-i-get-svn-e120106-ra-serf-the-server-sent-a-truncated-http-response-b)
> svn cleanup
> svn up
>
> Thanks in advance.
> Eric
>
> On 14/08/2020 11:12, Giuseppe Aruta wrote:
>> openjump-gis ok for me too
>>
>> 2020-08-14 12:03 GMT+02:00, edgar.sol...@web.de <edgar.sol...@web.de>:
>>> oj-devs
>>> oj-developers
>>> oj-team
>>> or jump instead of oj
>>>
>>> so many possibilieits ..ede:))
>>>
>>> On 14.08.2020 11:53, Giuseppe Aruta wrote:
>>>> jump-pilot
>>>> or
>>>> openjump-pilot
>>>> or
>>>> openjump2
>>>>
>>>> 2020-08-14 11:50 GMT+02:00, Eric <eric.openj...@thefactory.io>:
>>>>> Hi,
>>>>>
>>>>> The GitHub support team answered me this morning, stating that the
>>>>> ownership transfer of the 'openjump' username or organisation is not
>>>>> possible at the moment:
>>>>>
>>>>>> While I'd love to help, I'm afraid we won't be able to release that
>>>>>> username for you today as it's not dormant (not all activity on GitHub
>>>>>> is public) or available for release under our name-squatting policy
>>>>>> (https://docs.github.com/en/github/site-policy/github-username-policy).
>>>>>> Sorry I don't have better news to share with you on this.
>>>>>>
>>>>>> Though it may not apply here, it's worth mentioning that we have a
>>>>>> trademark policy that could allow you to obtain a username that's
>>>>>> already been claimed. If the username you're interested in is a
>>>>>> trademark you hold, I'd recommend taking a look at that policy for
>>>>>> more information about potentially filing a violation report:
>>>>>>
>>>>>> https://docs.github.com/github/site-policy/github-trademark-policy
>>>>> I just created an organisation named 'openjump-gis' for the time being
>>>>> (hyphens are allowed), according to the title of the openjump.org index
>>>>> page and as it gives an idea of what the project is about. The following
>>>>> options are also available at the moment:
>>>>> - open-jump,
>>>>> - openjumpgis
>>>>> - openjump-project / openjumpproject
>>>>> - oj-gis / ojgis
>>>>> - jump-pilot / jumppilot
>>>>> - openjump-pilot / openjumppilot
>>>>> - geopenjump
>>>>>
>>>>> Note that openjump is available on GitLab for the moment, if you wish to
>>>>> create a mirror repository there.
>>>>>
>>>>> It's always possible to rename an organisation later on (see
>>>>> https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-an-organization).
>>>>> This process automatically updates everything from link redirection to
>>>>> commit attribution.
>>>>>
>>>>> I already added Ede (edeso) and Michaël (mukoki) as owners of this
>>>>> organisation.
>>>>>
>>>>> I also just created an 'openjump-migration' repository as previously
>>>>> discussed and I am now tuning the settings of both the organisation and
>>>>> the repository.
>>>>>
>>>>> Feel free to modify the content / info / settings about these.
>>>>>
>>>>> I should be able to push a first working version for next Monday, maybe
>>>>> before but as schools reopened on Wednesday here in Scotland (children
>>>>> don't attend it on a daily basis during this first week), I can't
>>>>> promise anything.
>>>>>
>>>>> Eric
>>>>>
>>>>> On 12/08/2020 13:38, edgar.sol...@web.de wrote:
>>>>>> no worries. i'm pretty sure we are not fixed on that name. for years we
>>>>>> have been known as /jump-pilot/ (anybody know why?) and it worked as
>>>>>> well.
>>>>>> how about you work with a private repo in the mean time and we'll deal
>>>>>> with name and organisation when we are ready to branch which is not
>>>>>> going
>>>>>> to be tomorrow ;)
>>>>>>
>>>>>> ..ede
>>>>>>
>>>>>> On 12.08.2020 13:19, Eric wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Thanks to all of you.
>>>>>>>
>>>>>>> According to your answers, I'm in the process of creating a GitHub
>>>>>>> organisation named 'openjump', containing a public repository named
>>>>>>> 'openjump-migration'. The current problem is that someone created an
>>>>>>> account or an organisation with this name last April
>>>>>>> (https://github.com/openjump), but with no activity since then. I just
>>>>>>> contacted the GitHub support team to see if it was possible to have a
>>>>>>> transfer of ownership for this name -- so, of course, with the
>>>>>>> agreement
>>>>>>> of the current owner), as it isn't allowed to directly contact the
>>>>>>> owner
>>>>>>> for obvious reasons.
>>>>>>>
>>>>>>> Apart from that, everything is ready.
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>> On 12/08/2020 10:06, edgar.sol...@web.de wrote:
>>>>>>>> yup indenting is clearly broken in this reply, maybe better not reply
>>>>>>>> inline with that client Mike ;).. ede
>>>>>>>>
>>>>>>>> On 12.08.2020 09:17, Michaud Michael wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>     >>> On 07.08.2020 20:55, Eric wrote:
>>>>>>>>>     >>>> Then I checked which OJ lib dependencies rely on JTS and it
>>>>>>>>> seems that
>>>>>>>>> there is only deegree 2,
>>>>>>>>>     >>>> without considering here the plethora of extensions/plugins.
>>>>>>>>>     >>> which is the main obstacle. the only clean solution i see is
>>>>>>>>> to
>>>>>>>>> branch out
>>>>>>>>> a new OJ 2.x that initially will break compatibility to all external
>>>>>>>>> plugins.
>>>>>>>>> that's the bad news.
>>>>>>>>>     >>> the good news is that this forces us to retouch pretty much
>>>>>>>>> all
>>>>>>>>> of them and
>>>>>>>>> during this effort we might eventually come up with a working plugin
>>>>>>>>> manager
>>>>>>>>> after all.
>>>>>>>>>     >> Less than a day of work should be required (if not less) to
>>>>>>>>> update all the
>>>>>>>>> plugins which do not rely on a dependency which relies itself on JTS.
>>>>>>>>> I'm going
>>>>>>>>> to test it, to see if it's the case.
>>>>>>>>>     >> I tried with my plugins and I just needed a couple of seconds
>>>>>>>>> to
>>>>>>>>> do it.
>>>>>>>>>
>>>>>>>>> again. we don't have sources for all extensions in OJ Plus at hand or
>>>>>>>>> setup to
>>>>>>>>> build at all. the challenge won't be the modding but the finding and
>>>>>>>>> setting up
>>>>>>>>> plugin repos.
>>>>>>>>>
>>>>>>>>> I wasn't aware of this situation. All of a sudden, it seems to be
>>>>>>>>> another challenge to migrate all the plugins...
>>>>>>>>>
>>>>>>>>> Could we decide to norrow openjump-plus to extensions hosted by the
>>>>>>>>> project
>>>>>>>>> only, and revide the idea of a plugin manager (could be a student
>>>>>>>>> project ?).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> there is a critical bug opening JMP project files which should be
>>>>>>>>> fixed
>>>>>>>>> before
>>>>>>>>> we branch
>>>>>>>>> https://sourceforge.net/p/jump-pilot/bugs/496/
>>>>>>>>>
>>>>>>>>> The idea here is to test the migration based on the OJ 1.15 release,
>>>>>>>>> to
>>>>>>>>> know if it works and to see what could be improved during the final
>>>>>>>>> migration. Nothing definitive.
>>>>>>>>>
>>>>>>>>> We'll try to fix this bug before the definitive migration.
>>>>>>>>>
>>>>>>>>> Any format preference for this document? MD (Markdown) or RST
>>>>>>>>> (reStructuredText)? Both are easily and directly readable from GitHub
>>>>>>>>> /
>>>>>>>>> GitLab. I would probably suggest Markdown as it's slightly more
>>>>>>>>> common
>>>>>>>>> and because we don't need the specificities of RST at this stage.
>>>>>>>>>
>>>>>>>>> I also suggest markdown for the same reasons
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     >> - (Bonus) Upgrading the Log4j dependency to v2 and therefore
>>>>>>>>> removing the
>>>>>>>>> current security issue in link with it.
>>>>>>>>>
>>>>>>>>> the reason that this was not done before is that some extensions were
>>>>>>>>> compiled
>>>>>>>>> against it. as we are doing a clean break anyway i am not opposed
>>>>>>>>> anymore. note:
>>>>>>>>> we have our "own" com.vividsolutions.jump.workbench.Logger which is
>>>>>>>>> supposed to
>>>>>>>>> be the one stop solution for extension but internally uses Log4J
>>>>>>>>> again.
>>>>>>>>>
>>>>>>>>> What I could do is, once JTS and the OJ code have been updated on the
>>>>>>>>> master branch, to create another branch (based on the latter) to test
>>>>>>>>> a
>>>>>>>>> Log4j update. What do you think?
>>>>>>>>>
>>>>>>>>> It is good for me,
>>>>>>>>>
>>>>>>>>>     >> Open discussion:
>>>>>>>>>     >> - Preliminary remark: I don't want at any point of this
>>>>>>>>> process,
>>>>>>>>> acting as
>>>>>>>>> if I was taking this project under my umbrella/name. As I wrote to
>>>>>>>>> Michaël,
>>>>>>>>> you're the drivers/guardians of this project, I'm just a passenger.
>>>>>>>>> Therefore,
>>>>>>>>> just let me know what you prefer, the way you want to do things, and
>>>>>>>>> I'll act
>>>>>>>>> accordingly. Thanks,
>>>>>>>>>
>>>>>>>>> thanks for contributing your time and effort!
>>>>>>>>>
>>>>>>>>> It's the least I can do after having used OJ for years.
>>>>>>>>>
>>>>>>>>> I this migration to github and jts 1.17 succeeds, it will be a major
>>>>>>>>> step in the
>>>>>>>>> evolution of the project, thanks for your effort,
>>>>>>>>>
>>>>>>>>>     >> - Would you prefer an open or a private repository? Why do I
>>>>>>>>> consider the
>>>>>>>>> private option here? To avoid any confusion with the current OpenJUMP
>>>>>>>>> repository
>>>>>>>>> on sourceforge and to avoid some possible premature forks,
>>>>>>>>>
>>>>>>>>> we can easily add notes in the Readme pointing out the provisional
>>>>>>>>> status of the
>>>>>>>>> OJ2 development. anyone wanting to fork still i have no objections.
>>>>>>>>> after all
>>>>>>>>> it's not called open source for nothing ;)
>>>>>>>>>
>>>>>>>>> I'm waiting some other answers (from Peppe, Michaël, etc.) on that.
>>>>>>>>> If
>>>>>>>>> none, I'll create a public repository.
>>>>>>>>>
>>>>>>>>> I would say let's be open from the start, but I like the following
>>>>>>>>> proposition
>>>>>>>>> to have an openjump/openjump-test project first (or maybe
>>>>>>>>> openjump/openjump-migration), the time to fix main problems before we
>>>>>>>>> create a
>>>>>>>>> more official openjump/openjump (to avoid to send a bad image of a
>>>>>>>>> project with
>>>>>>>>> plenty of inconsistencies).
>>>>>>>>>
>>>>>>>>>     >> - Where do I need to create this project? In my personal
>>>>>>>>> account,
>>>>>>>>> or an
>>>>>>>>> OpenJUMP organisation is created, and the project takes place there
>>>>>>>>> (I
>>>>>>>>> would
>>>>>>>>> personally prefer this option, in link with my preliminary remark)?
>>>>>>>>> If
>>>>>>>>> an
>>>>>>>>> OpenJUMP organisation is created, do you want to create it yourself
>>>>>>>>> or
>>>>>>>>> is it OK
>>>>>>>>> if I create it?
>>>>>>>>>
>>>>>>>>> is "organisation" something like a team definition provided by
>>>>>>>>> github/-lab ?
>>>>>>>>>
>>>>>>>>> Yes indeed. The term "organisation" is used by GitHub, and the terms
>>>>>>>>> "group" and "subgroup" are used by GitLab:
>>>>>>>>> - (GitHub) https://github.blog/2010-06-29-introducing-organizations/
>>>>>>>>> - (GitLab) https://docs.gitlab.com/ee/user/group/
>>>>>>>>>
>>>>>>>>> An Organisation and a Group can contain several projects. It is quite
>>>>>>>>> useful to easily link related projects. In the OJ context, one
>>>>>>>>> project
>>>>>>>>> could be the OJ core, another one the default plugins, another the
>>>>>>>>> PLUS
>>>>>>>>> plugins, etc. (or a different project for each plugin).
>>>>>>>>>
>>>>>>>>> Even if there is no real convention (afaik), organisations and groups
>>>>>>>>> are often written in lower case with hyphens if necessary. For
>>>>>>>>> example:
>>>>>>>>> - https://github.com/geotools/geotools
>>>>>>>>> - https://github.com/locationtech/jts
>>>>>>>>>
>>>>>>>>> So for OpenJUMP I would suggest:
>>>>>>>>> - openjump for the organisation / group,
>>>>>>>>> - openjump for the main code,
>>>>>>>>> - openjump-test for the temporary project we are talking about here,
>>>>>>>>> to
>>>>>>>>> avoid any confusion.
>>>>>>>>>
>>>>>>>>> Let me know if you agree with this naming, and what to do, i.e. do
>>>>>>>>> you
>>>>>>>>> want that I create this organisation / group or if you prefer doing
>>>>>>>>> it?
>>>>>>>>> If you let me do it, I'll transfer immediately the ownership to all
>>>>>>>>> of
>>>>>>>>> you.
>>>>>>>>>
>>>>>>>>> It is OK for me (consider openjump-migration as an alternative to
>>>>>>>>> openjump-test). Maybe we could also consider the name openjump2 to
>>>>>>>>> underline the
>>>>>>>>> potential compatibility problems users may encounter if they use
>>>>>>>>> external
>>>>>>>>> plugins. We'll also have to decide about some conventions for
>>>>>>>>> projects
>>>>>>>>> of the
>>>>>>>>> same organisation hosting extensions : I would suggest to always
>>>>>>>>> include the
>>>>>>>>> word plugin (or extension) in th eproject name, except for special
>>>>>>>>> cases like
>>>>>>>>> sextante if we clone the code in openjump/.
>>>>>>>>>
>>>>>>>>>     >> - Have you already got some GitHub/GitLab accounts that I could
>>>>>>>>> use to let
>>>>>>>>> you access the project as administrators?
>>>>>>>>>
>>>>>>>>> sure, https://github.com/edeso
>>>>>>>>>
>>>>>>>>> and https://github.com/mukoki
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>>     >> So if I sum up the questions:
>>>>>>>>>     >> - Github vs Gitlab,
>>>>>>>>>     >> - Open vs private repository (just for the period of this
>>>>>>>>> test),
>>>>>>>>>     >> - Where? Personal account vs OpenJUMP organisation,
>>>>>>>>>     >> - GitHub/GitLab accounts for administration.
>>>>>>>>>
>>>>>>>>> for preliminary testing on your side feel free to use whichever
>>>>>>>>> service
>>>>>>>>> private/public shouldn't matter. for an eventual fork actually used
>>>>>>>>> as
>>>>>>>>> basis for
>>>>>>>>> OJ2 development let's still talk about details. i'm (and probably the
>>>>>>>>> others as
>>>>>>>>> well) not very familiar with setting up projects on either
>>>>>>>>> github/-lab.
>>>>>>>>>
>>>>>>>>> If you're happy with a public one, it's probably better as we'll
>>>>>>>>> benefit
>>>>>>>>> from better CI/CD tools. This should allow us to test the current OJ
>>>>>>>>> builds, maybe to try different ones if necessary or at least to adapt
>>>>>>>>> the current process within the context of GitHub/GitLab, as it
>>>>>>>>> appeared
>>>>>>>>> to be a crucial aspect of the migration.
>>>>>>>>>
>>>>>>>>> This is really a test to see the feasibility (Git migration, JTS
>>>>>>>>> update,
>>>>>>>>> OJ code update consequently, builds, plugins update, etc.) -- based
>>>>>>>>> on
>>>>>>>>> the current OJ 1.15 release for now --, to document the different
>>>>>>>>> undertaken steps in order to be able to reproduce them if needed and
>>>>>>>>> when decided (for example to create OJ 2.x).
>>>>>>>>>
>>>>>>>>>     >> About Ede's b2 point: I tested OJ with a Java 11 environment
>>>>>>>>> both
>>>>>>>>> with
>>>>>>>>> OpenJDK and an Oracle one. It works with both, as far as I tested it.
>>>>>>>>> I
>>>>>>>>> didn't
>>>>>>>>> try with Java 14. I prefer using OpenJDK as there is no commercial
>>>>>>>>> restriction
>>>>>>>>> with it.
>>>>>>>>>     >>
>>>>>>>>>
>>>>>>>>> agreed, we should strive to be openjdk compatible exactly because of
>>>>>>>>> the
>>>>>>>>> restrictions that Oracle introduced on their java runtime.
>>>>>>>>>
>>>>>>>>>     >> Please let me know what you prefer and I'll act accordingly.
>>>>>>>>>
>>>>>>>>> up to you, risking that licensing might not be possible, you may work
>>>>>>>>> out a
>>>>>>>>> proper conversion routine to a git service of your choice. using your
>>>>>>>>> documentation we may then using OJ 1.15.1/1.16 as a base for OJ2
>>>>>>>>> development
>>>>>>>>> when/if the licensing is cleared up.
>>>>>>>>>
>>>>>>>>> maybe you can shed a light which you think would be the better choice
>>>>>>>>> (github/-lab)?
>>>>>>>>>
>>>>>>>>> As a lot of other GIS related projects are already on GitHub, such as
>>>>>>>>> JTS, GeoTools, GeoNode, etc., it seems that it would be a good place
>>>>>>>>> to
>>>>>>>>> start with. Some projects like GEOS are directly hosted by OSGeo,
>>>>>>>>> then
>>>>>>>>> mirrored on GitHub and GitLab, and thus benefiting from different
>>>>>>>>> CI/CD
>>>>>>>>> tools.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Quick summary about the current options:
>>>>>>>>> - choice of GitHub,
>>>>>>>>> - creation of an openjump (lowercase) organisation in GitHub --
>>>>>>>>> question: who does this creation? if you let me do it, I transfer the
>>>>>>>>> co-ownership to Ede, Michaël and Peppe (others?) as soon as I know
>>>>>>>>> their
>>>>>>>>> individual GitHub accounts (already known for Ede). This organisation
>>>>>>>>> has a link to the OpenJUMP website, to the OJ mailing list
>>>>>>>>> (jump-pilot-devel@lists.sourceforge.net)
>>>>>>>>> - creation of a openjump-test (lowercase) repository within this
>>>>>>>>> organisation,
>>>>>>>>> - this repository is a public one,
>>>>>>>>> - migration of the OJ core (1.15 release -- revision 6242) containing
>>>>>>>>> the trunk, tags and branches to the openjump-test repository -- being
>>>>>>>>> aware that there is a critical bug reported here:
>>>>>>>>> https://sourceforge.net/p/jump-pilot/bugs/496/,
>>>>>>>>> - this migration uses <sfnetusername>@users.sourceforge.net for the
>>>>>>>>> authors (i.e. all committers), and keeps the history since the first
>>>>>>>>> available SVN revision (using the logs, it seems to be the 859),
>>>>>>>>> - update of JTS (version 1.17) including the update of related OJ
>>>>>>>>> code
>>>>>>>>> (solving the two classes mentioned in my previous message), the
>>>>>>>>> update
>>>>>>>>> of pom.xml, the removal of deegree-core 2 / deejump code (basically
>>>>>>>>> WFS
>>>>>>>>> related code), the creation of a README.md or .rst to clearly state
>>>>>>>>> that
>>>>>>>>> this a migration/update test and a link to the current releases /
>>>>>>>>> code,
>>>>>>>>> the creation of a documentation / report about this migration at the
>>>>>>>>> root of the repository named MIGRATION.md,
>>>>>>>>> - later, creation of another branch to test if it's possible to use
>>>>>>>>> Log4j v2.
>>>>>>>>>
>>>>>>>>> Ede, Michaël and Peppe, could you let me know if you agree or/and
>>>>>>>>> disagree about one or several aspects of this list.
>>>>>>>>>
>>>>>>>>> Once all your answers are received and a compromised reached, I'll
>>>>>>>>> proceed accordingly.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Eric
>>>>>>>>>
>>>>>>>>> so far.. thanks! ede
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Jump-pilot-devel mailing list
>>>>>>>>> Jump-pilot-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Jump-pilot-devel mailing list
>>>>>>>>> Jump-pilot-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Jump-pilot-devel mailing list
>>>>>>>>> Jump-pilot-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Jump-pilot-devel mailing list
>>>>>>>> Jump-pilot-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Jump-pilot-devel mailing list
>>>>>>> Jump-pilot-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>>>
>>>>>> _______________________________________________
>>>>>> Jump-pilot-devel mailing list
>>>>>> Jump-pilot-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Jump-pilot-devel mailing list
>>>>> Jump-pilot-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>>
>>>>
>>>> _______________________________________________
>>>> Jump-pilot-devel mailing list
>>>> Jump-pilot-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>
>>>
>>>
>>> _______________________________________________
>>> Jump-pilot-devel mailing list
>>> Jump-pilot-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>
>>
>> _______________________________________________
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
>
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel



_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Reply via email to