X.org has announced several packages that they are no longer maintaining, which we should be dropping: https://www.openwall.com/lists/oss-security/2023/05/02/3 I believe I got all of them listed in the Source RPM field, here they are with versions: xfindproxy-1.0.4-4.mga9.src.rpm, libxfontcache-1.0.5-14.mga9.src.rpm, xfwp-1.0.3-8.mga9.src.rpm, xsetpointer-1.0.1-15.mga9.src.rpm, libxkbui-1.0.2-19.mga9.src.rpm, libxxf86misc-1.0.4-4.mga9.src.rpm, libdmx-1.1.4-4.mga9.src.rpm, liboldx-1.0.1-19.mga9.src.rpm, xsetmode-1.0.0-18.mga9.src.rpm, libxevie-1.0.3-13.mga9.src.rpm, libxtrap-1.0.1-10.mga9.src.rpm, x11-font-bitstream-speedo-1.0.2-10.mga9.src.rpm, xrx-1.0.4-10.mga9.src.rpm, libxp-1.0.4-1.mga9.src.rpm, liblbxutil-1.1.0-13.mga9.src.rpm, x11-driver-input-mutouch-1.3.0-28.mga9.src.rpm, x11-driver-input-fpit-1.4.0-27.mga9.src.rpm, x11-driver-input-hyperpen-1.4.1-33.mga9.src.rpm, x11-driver-input-penmount-1.5.0-27.mga9.src.rpm We'll have to be careful, as some of them are currently required by other packages.
Target Milestone: --- => Mageia 9Blocks: (none) => 30163Priority: Normal => release_blocker
Here are the packages to drop listed, hopefully in alphabetic order: libdmx liblbxutil liboldx libxevie libxfontcache libxp libxtrap libxxf86misc x11-driver-input-fpit x11-driver-input-hyperpen x11-driver-input-mutouch x11-driver-input-penmount x11-font-bitstream-speedo xfindproxy xfwp xrx xsetmode Inevitably assigning this globally, but it might need more than one packager to do it all - especially as "some of them are currently required by other packages".
Assignee: bugsquad => pkg-bugs
we will need to rebuild xorg w/o the deps because for ex: urpmq --whatrequires lib64dmx1 lib64dmx-devel lib64dmx1 lib64xorg-x11
CC: (none) => mageia
Should we really do this for mga9? Needs much testing for reliability? = delaying mga9 further. Or do this after RC1, in order to be able to ship RC1 soon?
CC: (none) => fri
We should do this now. Once we release with unmaintained packages/software, we have no recourse. Rushing a distro release that we can't support doesn't help us.
If we don't do it before the rc, which is supposed to be as close to final as possible, it will not get adequate testing before the final iso images are released. For packages being dropped, if they are on the iso images or need to be obsoleted to force removal from user's systems, that has to be done before the RC iso images start testing. Doing it later would lengthen the final iso image testing, which we want to have be as short as possible due to the freeze on all development except fixing bugs impacting the iso images. For this bug, it's due to the security warning from Xorg.
CC: (none) => davidwhodgins
So I searched all unmaintained X.org packages listed and cleaned all packages which depended on they, here the cleaned dependencies list: $ urpmq --whatrequires-recursive lib64dmx1 lib64dmx-devel $ urpmq --whatrequires-recursive lib64dmx-devel $ urpmq --whatrequires-recursive lib64lbxutil1 lib64lbxutil-devel $ urpmq --whatrequires-recursive lib64lbxutil-devel $ urpmq --whatrequires-recursive lib64oldx6 lib64oldx-devel $ urpmq --whatrequires-recursive lib64oldx-devel $ urpmq --whatrequires-recursive lib64xevie1 lib64xevie-devel $ urpmq --whatrequires-recursive lib64xevie-devel $ urpmq --whatrequires-recursive lib64xfontcache1 lib64xfontcache-devel $ urpmq --whatrequires-recursive lib64xfontcache-devel $ urpmq --whatrequires-recursive lib64xp6 lib64xp-devel lib64xprintutil1 $ urpmq --whatrequires lib64xp-devel lib64xprintutil-devel libxprintutil $ urpmq --whatrequires-recursive lib64xtrap6 lib64xtrap-devel xtrap $ urpmq --whatrequires-recursive lib64xtrap-devel xtrap $ urpmq --whatrequires-recursive xtrap $ urpmq --whatrequires lib64xxf86misc1 lib64xxf86misc-devel $ urpmq --whatrequires lib64xxf86misc-devel drakx-kbd-mouse-x11 $ urpmq --whatrequires x11-driver-input-fpit $ urpmq --whatrequires x11-driver-input-hyperpen $ urpmq --whatrequires x11-driver-input-mutouch $ urpmq --whatrequires x11-driver-input-penmount $ urpmq --whatrequires x11-font-bitstream-speedo $ urpmq --whatrequires-recursive xfindproxy $ urpmq --whatrequires-recursive xfwp $ urpmq --whatrequires-recursive xrx $ urpmq --whatrequires-recursive xsetmode $ urpmq --whatrequires-recursive xsetpointer $ urpmq --whatrequires-recursive lib64xkbui1 lib64xkbui-devel $ urpmq --whatrequires-recursive lib64xkbui-devel $ urpmq --whatrequires-recursive lib64xprintutil1 lib64xprintutil-devel $ urpmq --whatrequires-recursive lib64xprintutil-devel All can be removed except for now our "drakx-kbd-mouse-x11" pkg which still depend on xxf86misc-devel. Also new xdpyinfo-1.3.4-2.mga9 should now be moved from Testing to Release to fix dependencies.
CC: (none) => geiger.david68210
List of srpms which can now be retired from our repo: libdmx-1.1.4-4.mga9.src.rpm liblbxutil-1.1.0-13.mga9.src.rpm liboldx-1.0.1-19.mga9.src.rpm libxevie-1.0.3-13.mga9.src.rpm libxfontcache-1.0.5-14.mga9.src.rpm libxp-1.0.4-1.mga9.src.rpm libxtrap-1.0.1-10.mga9.src.rpm xtrap-1.0.3-4.mga9.src.rpm x11-driver-input-fpit-1.4.0-27.mga9.src.rpm x11-driver-input-hyperpen-1.4.1-33.mga9.src.rpm x11-driver-input-mutouch-1.3.0-28.mga9.src.rpm x11-driver-input-penmount-1.5.0-27.mga9.src.rpm x11-font-bitstream-speedo-1.0.2-10.mga9.src.rpm xfindproxy-1.0.4-4.mga9.src.rpm xfwp-1.0.3-8.mga9.src.rpm xrx-1.0.4-10.mga9.src.rpm xsetmode-1.0.0-18.mga9.src.rpm xsetpointer-1.0.1-15.mga9.src.rpm libxkbui-1.0.2-19.mga9.src.rpm libxprintutil-1.0.1-20.mga9.src.rpm Execpt libxxf86misc-1.0.4-4.mga9.src.rpm as we have first to fix our drakx-kbd-mouse-x11 pkg!
So all added in task-obsolete except libxxf86misc for now.
The code which uses libxxf86misc is present since about 2005. It seems to concern test of the X server and another part for mouse setting. https://gitweb.mageia.org/software/drakx-kbd-mouse-x11/tree/lib/xf86misc/main.xs Who knows how this work? Not me. I suggest to keep it to not blocks the Mageia 9 release. For the X test, an option is to withdraw it, this is not so important. We still need to investigate for initIMPS2 function.
CC: (none) => yves.brungard_mageia
Priority: release_blocker => High
drakx relies on libxxf86misc, so it's removal broke stage2 installer (bug 31867), so I've restored the deps so stage2 installer works again, ... that will need to be reviewed for mga10
bug 32031 that is
If we are satisfied with dropping packages for Mageia 9 release, please drop blocking of Bug 30163 - [TRACKER] Packages that need to be obsoleted for Mageia 9 release
FI, I am just having a few proprietary programs failing on mga9 as they are looking for libXp. I was able to fix my very personal issue by building from obsolete/libxp, which does not depend on other obsoleted packages. Bug reports on that will possibly come. Cheers, Chris.
CC: (none) => eatdirt
Mageia 9 released long ago... Targeting mga10
Blocks: 30163 => 32127Target Milestone: Mageia 9 => Mageia 10
I'd like, as I said on the mailing list, that a fine-compiling package, working-package, used, should not be dropped. For instance, xsetmode should stays. Cheers.
See Comment 4. If we can remove our reliance on dead, unmaintained software, we should. There have been other things in the past people would have liked to keep forever (old versions of Gtk+ being just one example), but we just can't responsibly do that.
I disagree. We should remove software when they do not work or do not build. Here, you're using manpower to remove softs and, more importantly, dependencies, that work perfectly fine. Non-sense to me. Unmaintained does not mean broken nor useless.
Unless we have the expertise to maintain the software ourselves, or know that we can rely on someone else that does, it's not good to keep unmaintained stuff, should any serious issues arise with it.
Created attachment 14396 [details] Packages that would be removed from my current m9 x86_64 install The following command shows any of the packages that would be obsoleted based on the srpm list in comment 1. $ cat checkxorgpkgs rpm -q \ lib64xpm4 \ lib64xpm-devel \ lib64xpresent1 \ lib64xpresent-devel \ lib64xxf86misc1 \ lib64xxf86misc-devel \ libxpa1 \ libxpa-devel \ libxplayer-plparser18 \ libxplayer-plparser-devel \ libxplayer-plparser-gir1.0 \ libxplayer-plparser-mini18 \ libxplc0 \ libxplc-devel \ libxpm4 \ libxpm-devel \ libxpresent1 \ libxpresent-devel \ libxxf86misc1 \ libxxf86misc-devel | grep -v -w not The attached file lists the 269 packages that would then be uninstalled, which I generated using "urpme --test".
Note important dropped packages on release notes.
Keywords: (none) => FOR_RELEASENOTES10
urpmq --whatrequires lib64xpm4 I am a maintainer of many of these packages. Please, stop this non-sense. asclock aseprite clisp fbida fluxbox fvwm2 fvwm3 gimp gimp gimp3 grace icewm icewm-light jwm kdocker kterm lib64allegro4.4 lib64dockapp3 lib64gd3 lib64gnokii7 lib64twin0 lib64wraster6 lib64xaw7 lib64xm4 lib64xorg-x11 lib64xpm-devel lib64xpm-devel lib64xpm4 motv mrxvt mtink nethack nexuiz-glx nxagent pekwm perl-Prima posterazor rakarrack root root-graf-x11 snd svlc svlc svlc svlc svlc svlc swi-prolog-x swm texlive texlive windowmaker wmbattery wmbutton wmcalc wmcalclock wmcpuload wmcube wmdiskmon wmglobe wmgrabimage wmix wmlaptop wmmemmon wmmoonclock wmnd wmsmixer wmspaceweather wmstock wmsystemtray wmweather wmwifi x11iraf x2goclient xawtv-misc xd3d xdm xfig xfig xlockmore xonotic xosview xpenguins xsnow xstroke xterm xtux
OK. *IF* we drop important packages, they should be noted. How do other distros handle the unmaintained X.org packages?
I cannot repeat it many times, but *IF* we do this, that must be done by a vote somewhere where *all people involved* in the distro have their voice to say, not just a few connecting to the packager meetings. That would be a massive decision, keeping only a minimal number of packages based on the fact that they are maintained upstream. Also, many packages become unmaintained, and maintained again, so back and forth from obsoletes. All this is non-sense to me from day zero. And, finally, in that list of packages you're planning to drop, they are packages I am using for work and at home every day. My wm is fvwm. If I cannot use it any more, why I should use and work for Mageia? But that's my very personal concern :(
I am NOT pushing this to drop packages, this is not my cup of tea. I am pushing for decision to end the bug. If not to drop any packages here: close this bug and remove from Bug 32127 - [TRACKER] Packages that need to be obsoleted for Mageia 10 release It feels we need some statement, maybe from council, as I see we will knowingly need to keep unmaintained packages (security risk) in order for the system, installer and some applications to work. And I think other distros do the same.
CC: (none) => lewyssmith, marja11
(In reply to Chris Denice from comment #21) > urpmq --whatrequires lib64xpm4 > > I am a maintainer of many of these packages. Please, stop this non-sense. Is there no way to recompile libxpm4 without dependencies on unmaintained dependencies? Are things better in 3.5.17 ? Btw, I see several CVE fixes in 3.5.17, but Mageia 9 still has 3.5.15: https://gitlab.freedesktop.org/xorg/lib/libxpm/-/commits/master/?ref_type=HEADS
All right! But, this is the opportunity to talk about this bug. I have tried to close it already, but some people strongly disagree with my point of view and reopen it. Which means, the fight has to be put on the public place at some point. I do see libxpm on debian, fedora etc... No distro has removed that package, they maintain it locally even though it is no longer maintain upstream: policy full of sense. Here, our bug is opened to drop packages which are not maintained upstream, independently of their usage, independently of any security issues, open or not, and even though they compile fine and are used, or even maintained (by me). The most secure system is the one without users and without running programs. But we don't want that... On the practical side, either the council decide we go for it, we bypass maintainership (and I am out), or, this bug should be closed. I could also see a reasonable solution that the non-maintained upstream packages must have a Mageia maintainer, or should be collectively attributed to packagers packaging programs using them. I will be ok for this too of course. Ok, I'll stop spamming that bug ;)
libXpm is *not* in the list if unmaintained software from upstream! See Comment 0. It's absolutely appropriate to drop unmaintained software if possible, especially issues with them can affect other things. Obviously when it comes to dependencies, it's not always as simple as immediately dropping things. Sometimes it means recompiling things to drop the dependencies. Sometimes it means waiting on other upstreams to untangle those dependencies. We had the example earlier with xxf86misc which we all understand is nit easy to remove. That doesn't invalidate this as a whole. libXpm didn't come up until Comment 19, apparently due to a dependency that it has. That can be investigated and addressed. Nobody is suggesting removing libXpm or anything dependent on it. So please calm down with the hyperbole. There's no reason for this to turn into a big fight.
@Chris You are not spamming! Your view is important. As a general comment, it looks to me: - we have no reason to drop packages simply because they are now unsupported upstream, provided they go on working and cause no grief. We should cetainly not get involved in maintaining them; just using them. - If such packages do cause grief, then they must necessarily be weeded out. - Clearly unmaintained packages should be dropped if they are not required by anything or anyone. - As has been pointed out, we need to be careful about [not] removing on upgrades packages that are no longer in the repertoire, but which might be necessary for the user's existing system.
Well spoken, Lewis. I suggest to: § Drop this bug from blocking Bug 32127 - [TRACKER] Packages that need to be obsoleted for Mageia 10 release § Keep this bug open for discussion when there is something to drop / recompile, or related work on relieving dependency on unmaintained software.
I'd keep it hooked to the tracker until later, otherwise it'll just be forgotten. Which packages do we still have? We can be working on untangling what we can now.
Hi folks, First of all thanks for Mageia and your continuous efforts! LibXp is used in (at least one) prorietary program people paid (dearly) once and would like to keep using on their computer. I wonder also how openmotif handle this, is not libXp needed by openmotif? And large scientif programs (opensource, these ones) need [open]motif. Obviously it suffices to download the libXp rpm from the last Mageia that supports it and install it. But it may be useful to add a special repo for this kind of unsupported stuff, that could be selected additionnaly in the Install and Remove Software applet. Best regards
CC: (none) => gilles.duvert
That reminds me of a discussion from years ago. A separate repo is seemingly the most simple solution, but when you consider that some packages can go back and forth from being supported and unsupported, it would be better to have some metadata to indicate that, which would have visibility to rpmdrake.
Actually I was commenting about a libXp because I just upgraded my Mageia 8 to 9 with apparent success and found "only" this problem. However since then I realized that although the upgrade was deemed OK, I was still running the Mageia 8 kernel: $ uname -a Linux localhost.localdomain 5.15.126-desktop-1.mga8 #1 SMP Fri Aug 11 21:17:00 UTC 2023 x86_64 GNU/Linux although $ cat /etc/mageia-release Mageia release 9 (Official) for x86_64 And in a sense that was fortunate, because, having installed a fresh Mageia 9 on a separate partition, and booted it, I stumbled upon the problem that my ATI Radeon "Bonaire XT" was no more supported by Mageia (this may be described in the Release notes: "The proprietary AMDGPU-PRO driver currently only works with X.org 1.1xx, so it cannot be used in Mageia 9."): the boot would halt there. But I did not ask for the AMDGPU-PRO driver in the installation, and the release note say that "the free drivers for AMD/ATI graphics cards" works well. Apparently to a point. If I understand well, booting with a Mageia8 vmlinuz-5.15.126-desktop-1.mga8 permits my Mageia9 rpms ( x11-driver-video-amdgpu-23.0.0-2.mga9 and others present on my upgraded Mageia8->Mageia9 system ) to work with a "ATI Bonaire" card, whereas booting with a Mageia9 wmlinuz-6-xxx will halt at this same ATI card detection stage. I would certainly prefer that a fresh Mageai9 and future distros installed on my machine would boot in graphic mode without problem. Any suggestion?
Running the Mageia 8 kernel won't make it run the Xorg from Mageia 8, but I don't know the details of the amdgpu-pro support. The "discuss" mailing list, forum, or possibly a new bug report, would be better places to ask.
Thank you for your comments, I will do as you say. But I will dig further to understand what's going on.