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 > > > > > > > > > -- https://fam-tille.de
