[Devel-en] 2019.1 - Status of packages in the Sound group [WARNING - long message]
Mikhail Novosyolov
m.novosyolov at rosalinux.ru
Tue Jul 6 17:18:41 MSK 2021
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.
> So I settled to do an audit of all the Sound srpm packages to see what of them are in the situation described above and, while at it, I also looked for packages having or not having updates ready (new releases or interesting upstream patches) and for packages not being updated upstream since a long time (sometime good candidates for a removal)
>
> Now I would like to share what I found, because I feel that it could be useful in giving shape at the next distro release.
>
> So: if my counts are right, we have a total of 461 srpm packages in the
> Sound group.
> Of them: 58 have a dead URL
> 198 + 1 (unsure) have no updates since >= 3 years
> 107 have a new release upstream, ready to be picked
> 54 have updates (patches in git or whatever source
> control system it's used upstream)
>
>
> And here is an hopefully complete list of the issues I found, with some proposals to solve them.
>
> * Srpm packages depending upon Qt4 libs (and no qt5 port)
> **********************************************************
> easymp3gain (last update: 2013)
> ermixer (last update: 2003)
> fretscale (last update: 2012)
> kradio see below
> kradioripper see below
> kstreamripper see below
> lastfm-desktop
> pianobooster (there is a new release supporting Qt5)
> picard (there is a new release supporting Qt5 and python3)
> qtradio (last update: 2014)
> tomahawk (there is a new pre-release supporting Qt5)
> tutka?
> 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 pianobooster, picard, tomawhak and perhaps lastfm-desktop and tutka.
>
>
> *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.
>
>
> *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
> 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"
> extace (last update: 2008)
> foo-yc20 (this won't build against our faust 2.x.x - drop)
> galan (last update: 2007)
> ghostess
> gjay (last update: 2016)
> gmpc (11.8.16)
> gmpc-lastfm (0.20.0) (this could not work with the current gmpc - drop)
> gmpc-libnotify (11.8.16)
> gmpc-lyrics (11.8.16)
> gmpc-magnatune (11.8.16)
> gmpc-mdcover (0.20.0) (this could not work with the current gmpc - drop)
> gmpc-mserver (0.20.0) (this could not work with the current gmpc - drop)
> gmpc-shout (0.20.0) (this could not work with the current gmpc - drop)
> gmpc-wikipedia (11.8.16)
> gmusicbrowser
> gnome-alsamixer (last update: 2017)
> gnormalize (last update: 2012)
> gnuitar (last update: 2005)
> grip
> gst123 (last update: 2017)
> gtkguitune
> gwc
> gxtuner (last update: 2013)
> hexter
> hinetradio (last update: 2012)
> invada-studio-plugins-lv2
> jack_capture (last update: 2017)
> jack-rack (last update: 2014)
> jackeq (last update: 2012)
> jamin (last update: 2013)
> 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?
> lash (last update: 2009)
> lingot (there is a new release supporting gtk3)
the less programs in gtk2 exist, the less effrts will be required to maintain gtk2 themes
> mhwaveedit (last update: 2018)
> midicontroller? (last update: 2004)
> nekobee
> nekostring (last update: 2014)
> newtonator (last update: 2012)
> nted (last update: 2014)
> openav-sorcer-lv2
> pavumeter? (last update: 2007)
> phasex (last update: 2013)
> songwrite2 (replaced by songwrite3)
> songwrite3? (last update: 2017)
> timemachine
> wavbreaker
> whysynth (last update: 2017)
> wsynth-dssi
> xhippo no more developed
> xsynth-dssi (last update: 2010)
> zita-rev1 (there is a new release using cairo, rather than
> directly gtk2)
> 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. But for the GTk2 stuff, this would mean dropping some "big stuff" (eg: audacity, calf, gmpc, nted...), while they could be ported to gtk3 in a near future, because upstream is still active.
>
> *Proposal*: keep the packages having updates for sure; drop for sure all the packages not updated since long time (> 3 years?), because it's unlikely they will have major changes in the next future.
> To be decided for the others: keeping the will force us to continue to keep around the gtk2 libraries, with all the maintenance work this means; dropping those packages too fast, while upstream is still more or less active, could force us to restore in a near future some of the packages we dropped today.
>
>
> 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:
> ******************************************************
> diaspora is a game
> jack is in System/Servers, but could be Sound
> libtunepimp is in System/libraries, but really should be
> Sound (as for libmusicbrainz)
> linthesia is a game
> portaudio is in System/libraries, but really should be Sound
> portmidi is in System/libraries, but really should be Sound
> pulseaudio is in System/Servers, but could be Sound
> python-livestreamer should go in Video, given the Description
> python3-livestreamer should go in Video, given the Description
> taglib is in File tools, but really should be Sound
> (used only for tagging sound files)
> xine-lib is in System/libraries, but should be Sound or Video
> 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):
> ************************************************************************
> celt051 (celt)
> easytag (easytag24)
> gmpc-extraplaylist (gmpc)
> gmpc-osd (gmpc)
> jconvolver-reverbs (jconvolver)
> kmid2 (qmidplayer)
> libtunepimp (libmusicbrainz5?)
> songwrite2 (songwrite3)
> speex (opus)
> sphinx2 (sphinx3)
> sphinx3 (sphinx4 - not provided yet in ROSA)
> SpiralLoops (spiralsynthmodular)
> SpiralSynth (spiralsynthmodular)
>
> *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
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.
>
> My plan is to implement the above proposals and to start updating the packages having new stuff upstream. But, being only a volunteer, I would like having some approval from the main stakeholders of the distribution, at least for the proposals...
>
> Cheers.
> GvM
> _______________________________________________
> Devel-en mailing list
> Devel-en at lists.rosalinux.ru
> http://lists.rosalinux.ru/mailman/listinfo/devel-en
More information about the Devel-en
mailing list