Hey all, lxde/Razor-qt, or actually now called lxqt has moved to a new repo, we are still using a downstream repo (github), I'm not sure how often it is actually updated.. The new repo is git://git.lxde.org/git I would like to propose the following (perhaps premature?) changes. * rename lxde-base to lxqt-base (This will happen officially after (razor qt 0.6) the last release under the razor name * move to newest git repo * add new packages + lximage-qt + lxsession is now lxqt-session + lxqt-qtplugin + lxrandr-qt is replaced with lxqt-config-randr + compton-conf + qt-gtk-engine (Qt themes to Gtk 3 mapping engine) (maybe x11-themes?) If you guys on overlay team are busy I don't mind building these and filing a pull request..the main code for overlay is here right? https://github.com/gentoo/qt Reproducible: Always
(In reply to Bombino from comment #0) > If you guys on overlay team are busy I don't mind building these and filing > a pull request..the main code for overlay is here right? > https://github.com/gentoo/qt > I can't comment on the prematurity of the proposed changes (Ben?), but yes, patches are definitely welcome. The "authoritative" repo would be https://git.overlays.gentoo.org/gitweb/?p=proj/qt.git , but we accept pull requests on github at https://github.com/gentoo/qt
https://github.com/gentoo/qt/pull/26
@lxde, how shall we proceed here? would it make sense to create a new category for lxqt?
(In reply to Davide Pesavento from comment #3) > @lxde, how shall we proceed here? would it make sense to create a new > category for lxqt? I make sense I guess.
(In reply to Markos Chandras from comment #4) > (In reply to Davide Pesavento from comment #3) > > @lxde, how shall we proceed here? would it make sense to create a new > > category for lxqt? > > I make sense I guess. *it* make sense
(In reply to Davide Pesavento from comment #3) > @lxde, how shall we proceed here? would it make sense to create a new > category for lxqt? I don't see why we couldn't use the existing lxde-base category for that.
(In reply to Ben de Groot from comment #6) > I don't see why we couldn't use the existing lxde-base category for that. Well, because it's a different project. It is my understanding that lxqt is going to replace both lxde and razorqt, so I suppose that after a while both of them will be masked and removed from the tree, at which point having lxqt ebuilds under lxde-base/ sounds odd.
FWIW, I believe the razorqt-0.6.x release is going to be the last one under the razor name, then in the future its going to be lxqt.. I'm not sure however if lxde is going away, last i heard people were considering developing both in parallel.. but git activity is heavily focused on qt as of late.
(In reply to Davide Pesavento from comment #7) > (In reply to Ben de Groot from comment #6) > > I don't see why we couldn't use the existing lxde-base category for that. > > Well, because it's a different project. Not really. It is a merger of Razor-Qt and an overhaul of existing LXDE packages but using Qt instead of GTK+. It uses the LXDE website and repos. I was going to use the existing category for that, but haven't come around to it. Since I'm now using KDE for my own desktop, and have other things going on in my life, I don't think I will get to this anytime soon. So whoever is going to do the actual work should have first say in this. As long as it gets into the tree when there is a release, I'm happy. I don't mind too much either way what naming is to be used.
(In reply to Bombino from comment #8) > FWIW, I believe the razorqt-0.6.x release is going to be the last one under > the razor name, then in the future its going to be lxqt.. It was said that the 0.6 release would be the last under that name, but I can't see any upstream activity to speak of that would suggest this is actually going to happen. Everyone seems more excited to work on LXQt.
(In reply to Davide Pesavento from comment #7) > (In reply to Ben de Groot from comment #6) > > I don't see why we couldn't use the existing lxde-base category for that. > > Well, because it's a different project. It is my understanding that lxqt is > going to replace both lxde and razorqt, so I suppose that after a while both > of them will be masked and removed from the tree, at which point having lxqt > ebuilds under lxde-base/ sounds odd. I agree here (only to your first half of your message). The whole attempt is essentially a new project, so I'd rather to keep it separate from the existing lxde and razorqt packages. Speaking of LXDE, it's a very stable DE, and I would not like to force people to update to the lxde-qt for no reason. I am not sure masking and removing the old DEs is a reasonable thing to do for no reason. Sure, they will not receive further updates, but as long as they work fine, there is no reason to drop them from the tree. They require zero maintenance plus they keep users happy :)
(In reply to Markos Chandras from comment #11) > (In reply to Davide Pesavento from comment #7) > > (In reply to Ben de Groot from comment #6) > > > I don't see why we couldn't use the existing lxde-base category for that. > > > > Well, because it's a different project. It is my understanding that lxqt is > > going to replace both lxde and razorqt, so I suppose that after a while both > > of them will be masked and removed from the tree, at which point having lxqt > > ebuilds under lxde-base/ sounds odd. > > I agree here (only to your first half of your message). The whole attempt is > essentially a new project, so I'd rather to keep it separate from the > existing lxde and razorqt packages. Speaking of LXDE, it's a very stable DE, > and I would not like to force people to update to the lxde-qt for no reason. > I am not sure masking and removing the old DEs is a reasonable thing to do > for no reason. Sure, they will not receive further updates, but as long as > they work fine, there is no reason to drop them from the tree. They require > zero maintenance plus they keep users happy :) I think we are largely on the same page here how about this for a proposal: lxde-base stays the same for existing gtk version users razorqt-base migrates to lxqt-base and hosts new lxqt-* specific packages FYI: alpha packages with version 0.7RC1 are proposed for May 2014 news://news.gmane.org:119/CAAMR6=4rLdPuauC-6w96rxQjWRUz2x60Zh7xBDoN5h5OwbYQRA@mail.gmail.com
(In reply to Ben de Groot from comment #10) > (In reply to Bombino from comment #8) > > FWIW, I believe the razorqt-0.6.x release is going to be the last one under > > the razor name, then in the future its going to be lxqt.. > > It was said that the 0.6 release would be the last under that name, but I > can't see any upstream activity to speak of that would suggest this is > actually going to happen. Everyone seems more excited to work on LXQt. news://news.gmane.org:119/CAAMR6=67oqbxFw4bqVzzk-zPfO=M3n=UbxdW08=5USQtcRAS5g@mail.gmail.com
(In reply to Bombino from comment #13) > (In reply to Ben de Groot from comment #10) > > (In reply to Bombino from comment #8) > > > FWIW, I believe the razorqt-0.6.x release is going to be the last one under > > > the razor name, then in the future its going to be lxqt.. > > > > It was said that the 0.6 release would be the last under that name, but I > > can't see any upstream activity to speak of that would suggest this is > > actually going to happen. Everyone seems more excited to work on LXQt. > > news://news.gmane.org:119/CAAMR6=67oqbxFw4bqVzzk- > zPfO=M3n=UbxdW08=5USQtcRAS5g@mail.gmail.com That link doesn't work for me. Please quote the relevant part.
(In reply to Ben de Groot from comment #14) > (In reply to Bombino from comment #13) > > (In reply to Ben de Groot from comment #10) > > > (In reply to Bombino from comment #8) > > > > FWIW, I believe the razorqt-0.6.x release is going to be the last one under > > > > the razor name, then in the future its going to be lxqt.. > > > > > > It was said that the 0.6 release would be the last under that name, but I > > > can't see any upstream activity to speak of that would suggest this is > > > actually going to happen. Everyone seems more excited to work on LXQt. > > > > news://news.gmane.org:119/CAAMR6=67oqbxFw4bqVzzk- > > zPfO=M3n=UbxdW08=5USQtcRAS5g@mail.gmail.com > > That link doesn't work for me. Please quote the relevant part. --------------------------snip------------------------------ > > Hey this is somewhat related, I'm trying to get the ebuilds (how gentoo > installs packages fyi) for lxqt merged into Gentoo portage tree, the > following questions have arisen in the process, I'd like to reference > this thread as a quasi official answer to them. > > 1. Will the name razorqt be gone after this last release? > (it was my understanding 0.6 was the last release under that name) The original razor-qt may have a 0.6 release. Later, future development will be done in lxqt. > 2. Will lxde (gtk) still be under development along side lxqt? As long as gtk+ 2 is still widely used, the gtk+ version will exist. Thanks to Andriy, the file manager and panel of the gtk+ version got much updates recently. There is no plan to drop the gtk+ version at the moment. > Please see the threads here: > > https://bugs.gentoo.org/show_bug.cgi?id=501606 > https://github.com/gentoo/qt/pull/26 > > Thanks > > On 04/25/2014 11:22 PM, PCMan wrote: >> We started the merge of lxde and razor-qt in July 2013. >> About 10 months have passed and much has been done. >> As lxqt is currently in a stable status, I'd like to propose for the >> first alpha release in May. >> The purpose of the alpha release is to get some more feedbacks from >> early testers. >> Also, a release is needed to get interested people involved. >> The translations are not done yet, but that's not an issue for an alpha. >> Jerome proposed using 0.7 as the version number. >> Any comments or objections? >> >> Thanks! >> >> ------------------------------------------------------------------------------ >> Start Your Social Network Today - Download eXo Platform >> Build your Enterprise Intranet with eXo Platform Software >> Java Based Open Source Intranet - Social, Extensible, Cloud Ready >> Get Started Now And Turn Your Intranet Into A Collaboration Platform >> http://p.sf.net/sfu/ExoPlatform >>
(In reply to Harvey Mittens from comment #15) > The original razor-qt may have a 0.6 release. And that really, is all. It confirms what I said before: > It was said that the 0.6 release would be the last under that name, but I > can't see any upstream activity to speak of that would suggest this is > actually going to happen.
LXQt 0.7.0 has been released: http://sourceforge.net/p/lxde/mailman/message/32310545/
(In reply to Ben de Groot from comment #17) > LXQt 0.7.0 has been released: > > http://sourceforge.net/p/lxde/mailman/message/32310545/ I have created ebuilds for this release.. been having trouble gettings them into qt-overlay, not sure what the hold up is... https://github.com/gentoo/qt/pull/26
(In reply to Harvey Mittens from comment #18) > (In reply to Ben de Groot from comment #17) > > LXQt 0.7.0 has been released: > > > > http://sourceforge.net/p/lxde/mailman/message/32310545/ > > I have created ebuilds for this release.. > been having trouble gettings them into qt-overlay, not sure what the hold up > is... > > https://github.com/gentoo/qt/pull/26 I'd rather have a new lxqt-base category for that. Using my <lxde> hat here I would rather not mix the gtk and Qt packages into a single category especially since the gtk versions are still alive. Quoting: "> 2. Will lxde (gtk) still be under development along side lxqt? As long as gtk+ 2 is still widely used, the gtk+ version will exist. Thanks to Andriy, the file manager and panel of the gtk+ version got much updates recently. There is no plan to drop the gtk+ version at the moment." The new packages will probably need to maintained by the Qt team, because we, in lxde, have not enough manpower to support another DE at the moment.
(In reply to Markos Chandras from comment #19) > I'd rather have a new lxqt-base category for that. Using my <lxde> hat here > I would rather not mix the gtk and Qt packages into a single category > especially since the gtk versions are still alive. > Fair enough. @Harvey, can you update your pull request please? > The new packages will probably need to maintained by the Qt team, because > we, in lxde, have not enough manpower to support another DE at the moment. Nobody in the Qt team has shown interested in lxqt, and we are short on manpower too, so this is not going to happen either. I'm willing to review and merge users' PRs into qt overlay, but nothing more, sorry.
(In reply to Davide Pesavento from comment #20) > (In reply to Markos Chandras from comment #19) > > I'd rather have a new lxqt-base category for that. Using my <lxde> hat here > > I would rather not mix the gtk and Qt packages into a single category > > especially since the gtk versions are still alive. > > > > Fair enough. Thank you Davide > > @Harvey, can you update your pull request please? > > > The new packages will probably need to maintained by the Qt team, because > > we, in lxde, have not enough manpower to support another DE at the moment. > > Nobody in the Qt team has shown interested in lxqt, and we are short on > manpower too, so this is not going to happen either. I'm willing to review > and merge users' PRs into qt overlay, but nothing more, sorry. If you move them to the qt-overlay then people may start thinking that the qt team will take care of these. And I think we need to find maintainers before we move these ebuilds to the tree. We can't commit them as maintainer-needed neither we can dump them to proxy-maintainers (although we may can do that provided there are more than 1 user willing to maintain that). The other alternative would be to ask on the mailing list (-dev?) for help
(In reply to Markos Chandras from comment #21) > If you move them to the qt-overlay then people may start thinking that the > qt team will take care of these. And I think we need to find maintainers > before we move these ebuilds to the tree. We can't commit them as > maintainer-needed neither we can dump them to proxy-maintainers (although we > may can do that provided there are more than 1 user willing to maintain > that). The other alternative would be to ask on the mailing list (-dev?) for > help I could maintain it, but first I need to have a look at them, so if anything goes ok, I can add me as maintainer in a week or two.
FWIW I'm interested in lxqt too and may be able to assist if needed.
To whom it may concern, I'm using LXQT as my primary DE, I don't mind being a maintainer for these packages or joining the qt-overlay team if that helps.
(In reply to Davide Pesavento from comment #20) > (In reply to Markos Chandras from comment #19) > > I'd rather have a new lxqt-base category for that. Using my <lxde> hat here > > I would rather not mix the gtk and Qt packages into a single category > > especially since the gtk versions are still alive. > > > > Fair enough. > > @Harvey, can you update your pull request please? Done and Done, please leave harsh comments on my ebuilds on github and I will update as needed.. > > > The new packages will probably need to maintained by the Qt team, because > > we, in lxde, have not enough manpower to support another DE at the moment. > > Nobody in the Qt team has shown interested in lxqt, and we are short on > manpower too, so this is not going to happen either. I'm willing to review > and merge users' PRs into qt overlay, but nothing more, sorry.
(In reply to Markos Chandras from comment #21) > (In reply to Davide Pesavento from comment #20) > > (In reply to Markos Chandras from comment #19) > > > The new packages will probably need to maintained by the Qt team, because > > > we, in lxde, have not enough manpower to support another DE at the moment. > > > > Nobody in the Qt team has shown interested in lxqt, and we are short on > > manpower too, so this is not going to happen either. I'm willing to review > > and merge users' PRs into qt overlay, but nothing more, sorry. > > If you move them to the qt-overlay then people may start thinking that the > qt team will take care of these. And I think we need to find maintainers > before we move these ebuilds to the tree. We can't commit them as > maintainer-needed neither we can dump them to proxy-maintainers (although we > may can do that provided there are more than 1 user willing to maintain > that). The other alternative would be to ask on the mailing list (-dev?) for > help I think this calls for the creation of a new lxqt herd, and possibly an lxqt project within Gentoo. As said, most members of the Qt team are not interested in maintaining this, and the LXDE team doesn't seem to be either. Jauhien or Michael, could you take the lead on this? I would support this effort, but I currently don't really have the time. (Also, I'm now using KDE as main desktop.)
(In reply to Ben de Groot from comment #26) > (In reply to Markos Chandras from comment #21) > > (In reply to Davide Pesavento from comment #20) > > > (In reply to Markos Chandras from comment #19) > > > > The new packages will probably need to maintained by the Qt team, because > > > > we, in lxde, have not enough manpower to support another DE at the moment. > > > > > > Nobody in the Qt team has shown interested in lxqt, and we are short on > > > manpower too, so this is not going to happen either. I'm willing to review > > > and merge users' PRs into qt overlay, but nothing more, sorry. > > > > If you move them to the qt-overlay then people may start thinking that the > > qt team will take care of these. And I think we need to find maintainers > > before we move these ebuilds to the tree. We can't commit them as > > maintainer-needed neither we can dump them to proxy-maintainers (although we > > may can do that provided there are more than 1 user willing to maintain > > that). The other alternative would be to ask on the mailing list (-dev?) for > > help > > I think this calls for the creation of a new lxqt herd, and possibly an lxqt > project within Gentoo. As said, most members of the Qt team are not > interested in maintaining this, and the LXDE team doesn't seem to be either. > > Jauhien or Michael, could you take the lead on this? I would support this > effort, but I currently don't really have the time. (Also, I'm now using KDE > as main desktop.) Having a dedicated herd/project for that (could be a Qt subproject but it does not matter) backed up by proxy-maint if users are involved sounds good to me as well.
Yes, we can have a herd, I'll defenetely will join it.
So, I'm testing ebuilds for 0.7.0 (https://github.com/gentoo/qt/pull/26). I'll take them and add to the tree when they will be ready. I'll write to dev-ml in a while asking about adding of lxqt-base category as we need to discuss it before any ebuilds reach the tree.
PR merged.
Guys (whoever was interested in lxqt) can you please create the herd and a mail alias ASAP so that the bugs can be properly assigned? Thanks.
