Kind regards,
-Jerome
On 2025-07-30 06:44, Andreas Tille wrote:
> Hi Jerome,
>
> Am Wed, Jul 30, 2025 at 06:03:12AM +0000 schrieb [email protected]:
> > I just signed up on Salsa as 'jerstlouis'.
>
> Good.
>
> > The account is pending manual review.
>
> Just let me know once the account is available.
>
> > I'm hoping we will be able to start making some progress on this
> > packaging
> > and related build issues this week.
>
> Thank you for this effort
> Andreas.
>
> > 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
> > > > > >
> > > >
> >
