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
