[Devel-en] 2019.1 - Status of packages in the Sound group [WARNING - long message]

[Giovanni Mariani]

On 7/6/21 4:18 PM, Mikhail Novosyolov wrote:
> 
> 05.07.2021 11:30, Giovanni Mariani пишет:
>> Hi all...
>>
>> In the last few years I more or less worked as voluntary maintainer for the packages in the Sound group.
>>
>> The long time passed since our old 2016.1 distro release caused us remain rather behind regarding the packages we are providing in our repositories. Particularly a bunch of fundamental libraries arrived to their EOL:
>> Qt4, KDE4 and Gtk2; and obviously there are a few packages depending upon the now deprecated or dead libraries.
> 
> Many distros are dropping qt4 stuff, but a lot of qt4 programs have not been ported to qt5 and are very useful, let's better try to avoid dropping them until maintaining qt4 stack and them becomes too difficult.
> 
> Qt4 is C++, there are many problems with old c++ code with newer compilers, but gtk2 is C, I did not see any major problems with gtk2 programs, so there is probably no sense in dropping them.
> 
OK, then we can keep the Qt4pkgs, and also the gtk2 ones (less work :-) 
), if the issue of the gtk2-gtk3 inter-operability you noted below does 
not forbid it....


>> *Srpm packages depending upon KDE4 libs (and no plasma5 port)
>> **************************************************************
>> amarok            (there is a new pre-release supporting KDE5)
>> audex            (last update: 2017)
>> audiokonverter        (there is a new release supporting KDE5)
>> audiokonverter-restricted    (there is a new release supporting KDE5)
>> kmid2            (replaced by new qt5-only dmidplayer)
>> kmidimon        (there is a new release supporting Qt5)
>> konvertible        (last update: 2010)
>> kradio            (last update: 2017)
>> kradioripper        (replaced by kstreamripper)
>> kstreamripper        [already dropped ATM]
>> As rule of thumb, I would drop all the packages requiring an unmaintained library, particularly when it did not have upstream updates since a few years: it is unlikely to get adapted to the newer libraries.
>>
>> *Proposal*: drop all the packages listed above, but audiokonverter and amarok.
> maybe keep those packages that do not require fixing or can be build-fixed easily?
>> For audiokonverter, see if it's best upgrading the existing package to support KDE5 or provide a new plasma5-audiokonverter one (upstream sources allow both option); I have a WIP plasma5-audiokonverter package locally.
> 
> We have dropped kde4 desktop due to lack of maintainer and completely broken dependencies. People tried to automate updating kde5 packages using fedya@'s https://github.com/fedya/updates_tracker , it required changing names from plasma5-foo to just foo to allow that tool to find updates automatically. Some packages are now named plasma5-foo and some are named foo (nobody changed requires in kde4 packages, so they required e.g. kwallet and now kwallet is a kde5 thing, not kde4).
> Now kde4 has been dropped completely (only kdelibs4 have been left because there are some useful programs like quick-usb-formatter that depend on them and do not have a good alternative; if I remmeber correctly, I dropped many packages depending from kdelib4 but left some useful ones).
> 
> So better just rebase audiokonverter to kf5 libs.
> 
I have the same issue with soundkonverter dolphin service: the old 
package works for kde4, but the latest upstream sources can work also 
with kde5, so I was preparing a new plasma5-* package
So we should all agree that the way to go is keeping the old package 
names and uptade them to kde5...

>>
>> *Srpm packages depending upon Gtk2 libs (and no gtk3 port)
>> ***********************************************************
>> ario
>> audacity?
> Audacity can be built and work with wxGTK3.1 + gtk3. I am working on packaging audacity 3.0.3 rc2 and working with upstream a bit, I will probably send a pull request for you to have a look at some time soon after 3.0.3 is released
Thanks, I was having some troubles in building 3.0.2 and was ready to 
try 3.0.3-RC2... If you're already working on it, it's better...

>> aumix
>> autozen
>> calf
>> easymp3gain        (last update: 2013)
>> easytag            (last update: 2015 - replaced by easytag24)
> I did not have a look ast them, but is easytag24 is a complete and good replacement of easytag, then I would package easytag24 with the name easytag. It is not intuitive at all to install easytag24, I remember that I installed it recently and of course I just ran "dnf in easytag" without having a look at results of "dnf search easytag"
I introduced easytag24 a few years ago (2016 IIRC) only because at that 
time someone did not want to remove easytag 2.2.x from our repos (I 
don't remember why): I guess is time to upgrade the "normal" easytag 
package and drop the other...

>> lame    (gtk2 is needed only for the mp3x gui program, not for the library)
> btw I think many audio plugins (jack, lv2 etc.) still use gtk2? or no? I heard that there were conflicts between gtk2 and gtk3 when plugin host (e.g. A... forgot the name of that opensource DAW which is developed actively in gtk2). Or  may be it is not a problem now because a plugin opens a separate process?
IIRC some can be built without the GUI part as in the lame case: in this 
situation we should have no problem.
The gtk3 host - gtk2 plugin could be a problem, yes (you talk about 
Ardour, I guess)... I don't know how we could avoid it: perhaps by using 
Conflicts?

>> While verifying the packages in the Sound Group, I also found 3 other types of issues with the srpm packages in Sound
>>
>> * Some Packages seem to be placed in the wrong Group:
>> ******************************************************
>> Near all the cases listed above are libraries working with sound files (xine-lib also video files). Then the "System/libraries" Group is OK for the produced rpm packages, but not for the srpm ones.
>> For jack and pulseaudio, I think the proposed change is OK if we want to diffrentiate among the variuos system servers we provide (sound, video, print...); as for the library case, the produced rpms will still belong to "system/servers", while the srpm could tell what type of server is.
>>
>> *Proposal*: change all the above srpms as proposed (with the possible exception of: jack and pulseaudio).
>>
>>
>> *There are srpm packages that are actually replaced by other more recent packages that we already have (new package name):
>> ************************************************************************
>>
>> *Proposal*: All of them should be dropped (with the possible exception of sphinx3, until we provide sphinx4).
>>
>>
>> * There are also old and not updated packages of dubious usefulness:
>> *********************************************************************
>> celt051        was provided for compatibility when we switched to celt
>>          0.7.x+: still needed?
>> festvox-suopuhe-lj    are we interested in finnish language?
>> festvox-suopuhe-mv    are we interested in finnish language?
>> pvc        won't build under 2019.1 toolchain and no updates since
>>          2012
>> rio500    the hardware is 20 years old and perhaps no more relevant
>> rioutil    the hardware is 20 years old and perhaps no more relevant
>>
>> *Proposal*: drop all.
> 
> +1. if someone is interested in finnish language, he can maintain finnish-specific packages
> Packages of dubious usefulness should be either dropped or at least moved to contrib if they are in main
> 
You're agreeing with all the 3 solutions proposed above or only with the 
last one? Well, the 2nd I guess is difficult to disapprove... but the 
Group moving surely needs some consensus (particularly for jack & 
pulseaudio)

> HerI would suggest to have a closer look at packages which are needed for fax (like hylafax), dial up modems and other obsolete technologies/hardware, maybe tv tuners as well. Contrib is the best place for them. QA simply does not have such hardware to test them. And there are not many or no at all people using them.
> 
+1
None of them is under Sound, though...

GvM