[Devel-en] New platform: forking rosa2021.1 into rosa2023.1

Tue Jan 17 13:11:06 MSK 2023

Hi all! Sorry for not replying for so long...

28.12.2022 19:25, Giovanni Mariani пишет:
> On 28/12/22 14:59, Mikhail Novosyolov wrote:
>> Hi all! Happy New Year!
>>
>> Quite a lot of time has passed since release of first ISO images based on rosa2021.1 and even more time since its development was started. Now it is time to create a new platform, while continuing maintenance of the old one.
>>
> Great news! I was just wondering when this would start...
>
> The plan you propose is sound...
> Some little remarks below for some of the proposed steps.
>
>> 7. Make a mass rebuild (with publishing of results into the repository,
>> packages will have a new suffix/disttag rosa2023.1). Find which packages stopped being buildable compared
>>  to the list from point 5. It will give us a list of packages broken because
>>  of glibc and we will be able to quickly fix common problems without spending time on classifying each problem.
>
> For this one (and step 5 and 12), I think we need a place where put and interactively edit the "broken stuff" list to mark the packages being worked and fixed... just to avoid someone doing two time the same work.
> In the past ABondrov used google docs, but perhaps there are better alternatives at hand...

I also wanted to write about it.

The problem of those Google Docs tables was that they were editable for anyone who had a link. To my mind, it would be great to give a read-only link to a wide community to attract new contributors and to make the process of distro development more open.

We have already created such tables, where which read-write access is allowed only for authorized people and there is a read-only link for others.

We are using Yandex Disk, https://disk.yandex.ru . It is a Google Drive alike thing with OnlyOffice (which is named "R7 Office" in the Russian market, but has the same codebase) as a document editor. The editor there is the same as on personal.onlyoffice.com.

Here is a read-only link to table

So, I would ask you and symbianflo@ to make an account on Yandex and write your logins to me. I will open read-write access for you.

Please sign up at https://passport.yandex.com/ (in English). If you have troubles, I can make accounts for you...

>
>>  9. [in parallel with other things] Reformat main and contrib. There are
>>     many strange, old, not maintained, not used packages in main. We
>>     have to form the new main repository from packages which are used in
>>     ISO images, plus some server packages plus some other packages and
>>     all packages required to build them, recursively. All other packages
>>     should go into contrib. Here we will have to take
>>     installed_pkgs.log.gz from build lists of mass build and some how
>>     process them with a script.
> Perhaps this could be the time for also taking out from Contrib EOL stuff as qt4/(kde4)/gtk2/python2 packages or old and unmaintained packages having a newer alternative...
> For the Sound packages (ie the ones I know about better), there are still a few of them...
A lot of old, not buildable and not maintained packages have already been taken out from repos, irton@ (proklov_av@) has done this great work, now contrib is actually fully buildable (see https://abf.io/platforms/rosa2023.1/mass_builds). Of course, packages that have a better working alternatives can be dropped, but I would avoid dropping packages just because they use gtk2 or e.g. qt4, there a lot of useful programs that is old toolkits but still work, for example alarm-clock-applet.
>
>> 10. We have gcc 11 in rosa2021.1, gcc 12 is the latest version, gcc 13
>>     is going to be released in spring 2023. I do not see sense in
>>     updating gcc now. Updating it from 11 to 12 will break building a
>>     lot of packages but will not give any profit (at least nothing comes
>>     to mind). I suggest to make other big updates for now and wait,
>>     maybe we will better update to v13 nearer to its release.
>
> I'm basically OK with your proposal, but we could face two issues with it:
> 1) Finding packages that will not build, because they use some stuff not present in (or changed since) the libc/libc++ (probably more the latter than the former) coming with gcc 11.2.0.
> I already found a such case with Ardour (I wrote you about this, do you remember?):
> ********************************
> ../gtk2_ardour/option_editor.cc: In member function ‘void EntryOption::filter_text(const Glib::ustring&, int*)’:
> ../gtk2_ardour/option_editor.cc:354:48: error: no matching function for call to ‘std::basic_string<char>::erase(std::basic_string<char>::const_iterator&)’
>   354 |                                 t = text.erase (t);
>       |                                     ~~~~~~~~~~~^~~
> [...]
> /usr/include/c++/11.2.0/bits/basic_string.h:4793:7: note:   candidate expects 2 arguments, 1 provided
> ********************************
> Every release >= 7.0.0 failed to build with this error related to the standard library headers.
> Luckily it was only one single change in the Ardour sources, easy to find and to reverse, but IMO the thing could happen other times, as our gcc toolchain becomes older...
>
> 2) Gcc 14 (if not before) should disable by default or remove at all the support for a few compatibility features dropped by C99  and still supported (eg. implicit function declaration).
> LLVM/Clang should get this at release 16.
> See:
> https://lwn.net/Articles/913505/
> https://fedoraproject.org/wiki/Changes/PortingToModernC
>
> Given the  big number of packages involved and the complication deriving from autoconf scripts using the deprecated features, this work could require a very long time to be finished. So, perhaps, we should start working with newer compilers and catch/fix all the fallout from them earlier than we would prefer... but I guess that we can start this just after releasing the new 2023.1.
>
> Just my two cents...
>
Thanks for pointing out this!

Our gcc is 11, only one version behind the newest one - 12, I think it is quite new for now:) We can use llvm12/llvm15/llvm16 like chromium-browser-stable and/or create and use libstdc++-gcc14 if needed.

Hope that gcc 13 will not be affected by what you gave links to. We can package a newer gcc (as a container) later and run a mass build with it attached as a container.