Also for reference, our latest version of the packaging is hosted on the
ecere-sdk branches "ppa/debian" (might be latest for Debian release):
https://github.com/ecere/ecere-sdk/tree/ppa/debian
and "ppa/latest" (which we were using for the Launchpad recipes):
https://github.com/ecere/ecere-sdk/tree/ppa/latest
The Launchpad recipe is here:
https://code.launchpad.net/~jerstlouis/+recipe/ecere-daily-latest
which uses the 'latest' branch ~1900 commits ahead of the 'master'
branch which is closer to the last Debian release and likely what we
would start from the update/bugfix 0.44.16 release, with the latest
branch remaining as a source for fixes to be cherry-picked, and for the
future componentized version of the SDK.
Launchpad builds are currently failing seemingly due to various
different reasons, including OpenSSL 3 vs. 1.1, an old embedded versions
of libffi (which might not actually need to be built at all on Linux
since I think we link to the system one anyways), and possibly other
reasons to investigate.
Perhaps Redj could start by focusing on the OpenSSL 3 transition and
trying to get some of these Launchpad builds to succeed.
Best,
-Jerome
On 2025-07-17 06:10, [email protected] wrote:
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
