LXDE development is discontinued, upstream shifted to LXQt, and most of current packages are maintainer-needed in Gentoo. Even though they work for now, it's only a matter of time before they start breaking. We're keeping x11-misc/pcmanfm and its core dependencies, while most of other lxde-base packages will be removed from the tree.
So I wasted my time porting these ebuilds from GTK+2 to GTK+3?
(In reply to Andreas Sturmlechner from comment #1) > So I wasted my time porting these ebuilds from GTK+2 to GTK+3? I wouldn't say you wasted your time, these packages can always be moved to an overlay. Given this is abandoned upstream I think it was clear that LXDE will have to go at some point, it was just a matter of time. Besides, nobody in Gentoo stepped in in the meantime to maintain this.
Don't get me wrong, I'm none too shy over last-riting packages. I have looked into it myself for LXDE with bug 751076, bug 769524 and bug 776373 and ultimately decided against it after finding slowly moving, but not completely abandoned upstream repositories, extracting one or two fixes from there. That work got noticed so we know there are users out there. There is some ground to look at lxde-base/lxdm bugs, which is included by this cleanup, but *that* package actually has a maintainer. Some of those bugs may be obsolete (looking at least at the consolekit one). Right now this category does not block any migration tracker, ebuilds are up to date wrt EAPI, nor are major bugs pending; I don't think it is good use of anyone's time to clean up now [over e.g. the many still pending items in gtk2-removal and other trackers]. Once the time has come, it is the kind of thing where someone from that user base may finally be ready to step up for maintenance.
...besides, the sole reasoning given for last-riting lxde-base/* makes it weird when at the same time equally unmaintained (and replaced by x11-misc/pcmanfm-qt) x11-misc/pcmanfm is being kept.
(In reply to Andreas Sturmlechner from comment #3) > > There is some ground to look at lxde-base/lxdm bugs, which is included by > this cleanup, but *that* package actually has a maintainer. Some of those > bugs may be obsolete (looking at least at the consolekit one). Yep. But it has multiple alternatives available, and latest release is from 2015. It doesn't seem to have received any development after from what I can see. I'd say we've last-rited for less. But luckily it doesn't seem to depend on the lxde-internals either if we want to keep it. Though I've just build-test it and the ebuild needs updates. > > Right now this category does not block any migration tracker, ebuilds are up > to date wrt EAPI, nor are major bugs pending; I don't think it is good use > of anyone's time to clean up now [over e.g. the many still pending items in > gtk2-removal and other trackers]. Once the time has come, it is the kind of > thing where someone from that user base may finally be ready to step up for > maintenance. So just postpone it and wish someone has time later? I'd say it's declared abandoned by upstream. *IF* upstream ever resumes the development, it can be added back with a new maintainer. Please remember that we've sent multiple e-mails to mailing lists stating lxde will be and did become unmaintained. You've fixed some lxde bugs by yourself. You know these bugs will just keep piling on, and eventually it'll be removed. When's the right time to call it? We have someone doing the work *right* now. > > ...besides, the sole reasoning given for last-riting lxde-base/* makes it > weird when at the same time equally unmaintained (and replaced by x11- > misc/pcmanfm-qt) x11-misc/pcmanfm is being kept. This is definitely poking the ice a bit. I've been looking to last-rite lxde ever since I disbanded the project over a year ago precisely due to lack of upstream interest. Now pcmanfm on the other hand had its latest release earlier this year, and seems to have a dedicated upstream maintainer. I'm also aware pcmanfm is really popular with other lighweight WMs, and that there aren't really alternatives to be suggested for it?
(In reply to Joonas Niilola from comment #5) > (In reply to Andreas Sturmlechner from comment #3) > > > > There is some ground to look at lxde-base/lxdm bugs, which is included by > > this cleanup, but *that* package actually has a maintainer. Some of those > > bugs may be obsolete (looking at least at the consolekit one). > > Yep. But it has multiple alternatives available, and latest release is from > 2015. It doesn't seem to have received any development after from what I can > see. I'd say we've last-rited for less. > > But luckily it doesn't seem to depend on the lxde-internals either if we > want to keep it. Though I've just build-test it and the ebuild needs updates. LXDM will stay in the repository even if it must move categories. There is nothing wrong with the code. Just because something is simple and works doesn't mean no updates should kill it. When it stops working, then I will concede to that idea.
Opened https://bugs.gentoo.org/810329 about lxdm.
(In reply to Joonas Niilola from comment #5) > So just postpone it and wish someone has time later? I'd say it's declared > abandoned by upstream. *IF* upstream ever resumes the development, it can be > added back with a new maintainer. How much research did you put into that? https://blog.lxde.org/ https://github.com/lxde/lxrandr - latest release Mar 2019 https://github.com/lxde/lxsession - latest release Feb 2020 https://github.com/lxde/lxpanel - latest release Feb 2021 https://github.com/lxde/lxterminal - latest release Feb 2021 ...all versions currently packaged in Gentoo. As I already said: slowly moving, but not completely abandoned upstream repositories. (In reply to Joonas Niilola from comment #5) > You've fixed some lxde bugs by yourself. You know these bugs will just keep > piling on, and eventually it'll be removed. When's the right time to call > it? We have someone doing the work *right* now. That may happen in the future, but it did not during the last several months after I applied the *upstream* fixes. (In reply to Joonas Niilola from comment #5) > I'd say we've last-rited for less. Without doubt - a library without consumers, obscure packages where upstream has vanished. A whole category without major bugs, probably not.
(In reply to Andreas Sturmlechner from comment #8) > (In reply to Joonas Niilola from comment #5) > > So just postpone it and wish someone has time later? I'd say it's declared > > abandoned by upstream. *IF* upstream ever resumes the development, it can be > > added back with a new maintainer. > How much research did you put into that? I must admit most of it is from year ago when I disbanded the project, and was looking to last-rite it by myself. Must've not been ported to GTK-3 fully yet then etc. > > > https://github.com/lxde/lxrandr - latest release Mar 2019 And not a single commit afterwards, even with pull requests available and a handful of new bugs reported since. > https://github.com/lxde/lxsession - latest release Feb 2020 > https://github.com/lxde/lxpanel - latest release Feb 2021 > https://github.com/lxde/lxterminal - latest release Feb 2021 Very little activity considering how many issues/bugs they have open. lxterminal for sure has enough alternatives available. But sure, there is some activity overall and the programs work. > > As I already said: slowly moving, but not completely abandoned upstream > repositories. Yes, seems so. > > (In reply to Joonas Niilola from comment #5) > > I'd say we've last-rited for less. > Without doubt - a library without consumers, obscure packages where upstream > has vanished. A whole category without major bugs, probably not. Well I do remember KDE-[34] removal having some similar vibes, where many working packages were removed just because. But we can treat this bug, this suggestion as a prototype and a future reference until the time comes. I do not want to close this yet, to get more feedback. Ideally upstream became more active, and we got a dedicated maintainer in Gentoo to handle it.
(In reply to Joonas Niilola from comment #9) > Well I do remember KDE-[34] removal having some similar vibes, where many > working packages were removed just because. You could only say that if you weren't paying attention back then. It is not comparable at all. - KDE 3 to KDE SC 4 to Plasma-5/Frameworks-5/Applications all were natural successions within the same namespace. It was impossible to keep old versions around without blockers for file collisions all over the place. LXQt OTOH was created as a new project in a new namespace. - When last-rited, Qt4 was unmaintained for 3 years. GTK+3 is not there yet. - Qt4 was blocking openssl-1.1, breaking with gcc, glibc, boost, cmake, ICU, etc. - Qt4WebKit had more holes in it than swiss cheese. Those were excellent arguments to reply to anyone who was against package cleanups. The situation with KDE3/Qt3 will have been similar. To the extent of me voicing opposition, that's it. I have no stakes in LXDE at all and I'm not going to undo any steps towards its removal. (In reply to Joonas Niilola from comment #9) > Ideally upstream became more active, and we got a dedicated maintainer in > Gentoo to handle it. Agreed.
As said, I have been thinking about lxde's removal ever since I disbanded the project +1 year ago. It seems some faults have been fixed meanwhile, and I just tested, and lxde still works. It's unfortunate it has no maintainer in Gentoo currently, but I don't see a reason to force its removal in its current state. I'll write the provided .patch as a reference for future if/when it breaks down, again, and receives no maintainer in Gentoo. Thanks for the effort! Let's leave it to another time.
