Hi,
Short top posting answer. I have the following work items:
1. Ask on Salsa for an ecere-team group
2. Make you owner of that team (what is your Salsa login?)
3. Migrate the current ecere to that team
4. Remove me from ownership of this Salsa team since I do
not want to be involved more
Than you take over.
Kind regards
Andreas.
Am Thu, Jul 17, 2025 at 06:10:14AM +0000 schrieb jer...@ecere.com:
> Thanks Andreas for the quick reply.
>
> > In case you consider ecere an own ecosystem (libecere etc.) with a
> > couple of packages we might ask for a separate team there.
>
> I would definitely vote for a separate team, as Ecere is definitely an
> ecosystem (and quite a large one I would say, with potential to grow
> significantly, despite the relatively still small number of users and
> contributors).
>
> The current (old) Debian packaging currently already has 9 packages:
> - ecere-dev (the eC compiling tools, epj2make cross-platform build system,
> API Documention Editer and Viewer, the eC bindings generator, and Ecere IDE)
> - ecere-extras (a large collection of loose useful eC source modules)
> - ecere-samples (a large collection of sample eC programs including various
> games like Chess, 3D model viewer, communication utilities)
> - libecc0 (the eC transpiler library)
> - libecere0 (the eC Runtime Library, 2D/3D graphics engine, GUI toolkit,
> Windowing Platform Abstraction Library, Networking library)
> - libecereaudio0 (an audio library using ALSA on Linux / DirectAudio on
> Windows)
> - libecerecom0 (a minimalistic eC Runtime Library that can be used instead
> of but not together with libecere0, and therefore is not very useful for
> practical applications)
> - libeda0 (the Ecere Data Access RDBMS abstraction Library, including a
> built-in minimalistic RDBMS engine (EDB))
> - libedasqlite0 (a SQLite driver for EDA, including eC bindings for SQLite)
> - ecere-sdk (the meta package that installs all of the above)
>
> As I mentioned, for the release *after* this overdue update/bugfix release,
> we plan on splitting libecere0 in its individual components, some which are
> already working and organized in separate repositories:
> - https://github.com/ecere/eC ( the minimal compiler including libecc0 and
> components of ecere-dev -- https://pypi.org/project/ecdev/, as well as a
> larger/more practical separate runtime library --
> https://pypi.org/project/ecrt/ currently including the sys namespace of
> libecere0, but which could be further split into individual components)
> - https://github.com/ecere/gfx (2D/3D graphics engine previously within
> libecere0, likely to be further split into individual drivers for X11,
> OpenGL, possibly 2D and 3D graphics separated, with also separate driver
> libraries to load different 3D asset formats, 2D image formats...)
> - https://github.com/ecere/wpal (previously within libecere0)
> - https://github.com/ecere/sockets (previously within libecere0)
>
> The GUI toolkit has not yet been separated out.
>
> And the other components also being split:
> - https://github.com/ecere/ectp2 (an incomplete more refactor of the
> compiler's libecc0 into a hand-written recursive descent parser rather than
> using flex/bison)
> - https://github.com/ecere/epj2make (the build system previously within
> ecere-dev)
> - https://github.com/ecere/bgen (bindings generator previously within
> ecere-dev)
> - https://github.com/ecere/sqlite (previously within libedasqlite0)
>
> Te Ecere IDE (depending on the GUI toolkit) has not yet been reorganized.
>
> Separately from all this, there is also the ecosystem of all software
> written in the eC programming language.
> Currently, that software is mostly developed by ourselves, but we hope this
> componentization, as well as the availability of bindings to several
> programming languages (C, C++, Python, with Rust and Java in progress) will
> help facilitate adoption independently of the eC language, libraries and
> tools.
>
> We are currently actively working on two new open-source projects which are
> components of our GNOSIS Geospatial Software suite implementing standards of
> the Open Geospatial Consortium in which we're actively involved.
>
> The first of these projects is DGGAL ( https://dggal.org ), which is already
> picking up significant momentum:
>
> https://github.com/ecere/dggal (https://pypi.org/project/dggal/)
>
> The second is libCartoSym which is very recent, but will hopefully also gain
> traction:
>
> https://github.com/ecere/libCartoSym ( http://cartosym.org )
>
> which itself is made up of several libraries: libCartoSym, libCQL2,
> libDE9IM, libSFCollections, libSFGeometry, libGeoExtents
>
> which should probably also be packaged individually, as software projects
> may which to depend independently on some but not all of these.
> We expect libCQL2 in particular to gather significant interest in the
> geospatial community.
>
> > Once this is decided I'd volunteer to create a packaging repository for
> > ecere there and try to fix / modernise the packaging as far as I'm able
> > to do to get you up and running.
>
> Awesome! Thank you so much for the help.
>
> > This will not happen before next week but you can decide about the team
> > first.
>
> Next week or whenever is convenient for you is fine.
>
> > just a short answer since I'm pretty busy at DebConf
>
> Thanks for replying from DebConf! Maybe I can try to fit DebConf 26 in my
> travel plan next year!
> Enjoy the rest of the conference.
>
> Kind regards,
>
> -Jerome
>
> On 2025-07-17 04:52, Andreas Tille wrote:
> > Hi Jerome,
> >
> > just a short answer since I'm pretty busy at DebConf: We should move
> > that package to salsa.debian.org. There you should either decide for
> > some team you feel good in - otherwise the Debian team might be fine.
> > This means that any developer permits you touching and uploading your
> > package. In case you consider ecere an own ecosystem (libecere etc.)
> > with a couple of packages we might ask for a separate team there.
> >
> > Once this is decided I'd volunteer to create a packaging repository
> > for ecere there and try to fix / modernise the packaging as far as
> > I'm able to do to get you up and running.
> >
> > This will not happen before next week but you can decide about the
> > team first.
> >
> > Kind regards
> > Andreas.
> >
> > Am Thu, Jul 17, 2025 at 01:12:53AM +0000 schrieb jer...@ecere.com:
> > > Dear Andreas,
> > >
> > > > > Just let us know about the status and how you want to proceed.
> > >
> > > > If there is no immediate urgency, could we perhaps plan a quick online
> > > > call or IRC chat in early July?
> > >
> > > Réjean is starting to work for Ecere full time next week, and I have a
> > > little more breathing room to put into this updated release of the
> > > Ecere SDK
> > > myself as well. Would you be available for a relatively short
> > > meeting to
> > > guide us through the changes in Debian packaging in the last decade
> > > and help
> > > us identify what needs to be done on that end? We could meet either
> > > on IRC,
> > > or voice teleconferencing if you prefer and that would be more
> > > practical. If
> > > so, please let us know when would be convenient.
> > >
> > > Alternatively, if you could perhaps give us some initial pointers by
> > > e-mails
> > > that would also be very much appreciated.
> > >
> > > The first and most important thing for this release is to address
> > > those
> > > FTBFS bugs in Debian, as well as update the packaging to reflect the
> > > Debian
> > > policy changes. We may also need to integrate additional
> > > improvements to the
> > > compiler for platform support, including support for musl libc and
> > > arm64
> > > Linux, some of which have been made in our new stand-alone eC
> > > compiler/runtime library repository ( https://github.com/ecere/eC ).
> > > We've
> > > also recently noticed new breakage with GCC 15 which we still need to
> > > address. And we likely need to transition the code to use OpenSSL 3
> > > rather
> > > than 1.1.
> > >
> > > Separately, we would also try to synchronize this release with
> > > updating the
> > > Windows installer as well, which also involves updating the GCC
> > > distribution
> > > that is bundled with it, as well as reviewing the ~1900 commits in our
> > > active development branch to see whether some of these could make it
> > > to the
> > > release as well. That will require some additional follow-up efforts
> > > on our
> > > side.
> > >
> > > This new fully backward-compatible release of the Ecere SDK would
> > > likely be
> > > the last monolithic one, with future releases splitting the 'libecere'
> > > shared library into several individual components, limiting the
> > > dependencies
> > > on third-party libraries such as OpenSSL and OpenGL to the specific
> > > components requiring them (though we could still have meta ecere-sdk
> > > packages including all the sub-components to facilitate the
> > > transition, both
> > > for the code as well as for installable packages).
> > >
> > > Thank you very much for your patience in keeping ecere-sdk in
> > > unstable, and
> > > for any help you or anyone else in the Debian community could
> > > provide in
> > > getting the package back in modern shape.
> > >
> > > Kind regards,
> > >
> > > -Jerome
> > >
>
--
https://fam-tille.de
