Kind regards,
-Jerome
On 2025-07-17 09:00, Andreas Tille wrote:
> 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 [email protected]:
> > 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 [email protected]:
> > > > 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
> > > >
> >
