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
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.
just a short answer since I'm pretty busy at DebConf
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
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
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
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
My Salsa account just got approved.
signup page) to create a team for ecere.
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
Dear Jerome,
Am Thu, Jul 31, 2025 at 12:22:55PM +0000 schrieb [email protected]:
My Salsa account just got approved.
Nice!
Now you follow
https://wiki.debian.org/Salsa/FAQ#How_do_I_create_a_Group.3F_I_see_no_button_for_that.21
signup page) to create a team for ecere.
Once this is create you (as the owner of this team) can add me with permissions "Maintainer" and I'd volunteer to create a repository
for the ecere package there to give you some kick start.
Just let me know if you need more help.
Kind regards
Andreas.
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
Awesome, done, I've invited yourself and Redj as maintainers.
Any help to help us get started with the modernization of the
Debian-specific packaging spec would be most welcome.
If it's possible to automatically import the previous packaging from either:
https://github.com/ecere/ecere-sdk/tree/ppa/latest/debian
or
https://github.com/ecere/ecere-sdk/tree/ppa/debian/debian
to help us get started that would be ideal.
Thanks a lot!
-Jerome
On 2025-07-31 12:41, Andreas Tille wrote:
Dear Jerome,
Am Thu, Jul 31, 2025 at 12:22:55PM +0000 schrieb [email protected]:
My Salsa account just got approved.
Nice!
Now you follow
https://wiki.debian.org/Salsa/FAQ#How_do_I_create_a_Group.3F_I_see_no_button_for_that.21
signup page) to create a team for ecere.
Once this is create you (as the owner of this team) can add me with permissions "Maintainer" and I'd volunteer to create a repository
for the ecere package there to give you some kick start.
Just let me know if you need more help.
Kind regards
Andreas.
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
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 42:56:31 |
| Calls: | 12,110 |
| Calls today: | 1 |
| Files: | 15,008 |
| Messages: | 6,518,438 |