Bug 1679470

Hi Zamir, can you please look for the other mentioned packages part of LXQt?

I'm quite busy recently. I can take a look when I have some spare time, but I cannot make any promise about when.

I want to get a clear idea what's the issue. So it's some scriptlets being removed in Rawhide, but they are actually still needed for EPEL, am I right?

yes (In reply to Zamir SUN from comment #2)

I'm taking this one in case I missed during the updating to LXQt 0.15.0. But I don't promise when I can finish.

No problem. This issue's meant for epel only.
Let me know when to continue with all packages mentioned in comment #0.

Just a note, from the git log the following packages need the fix

libfm-qt 
e21d66e Remove obsolete ldconfig scriptlets                                                    

liblxqt     
241c790 Remove obsolete ldconfig scriptlets

libsysstat     
7a84504 Remove obsolete ldconfig scriptlets
                                                                   
lximage-qt 
d1eceb8 Remove obsolete scriptlets
                                                        
lxqt-globalkeys 
de13d96 Remove obsolete ldconfig scriptlets    

lxqt-powermanagement 
e3171c3 Remove obsolete scriptlets

obconf-qt 
645d874 Remove obsolete scriptlets

pavucontrol-qt 

pcmanfm-qt 
40f5315 Remove obsolete scriptlets

qterminal 
23c30aa Remove obsolete scriptlets

qtermwidget 
29a0230 Remove obsolete ldconfig scriptlets

(In reply to Zamir SUN from comment #6)
> Just a note, from the git log the following packages need the fix
...
> pavucontrol-qt 

This shouldn't be part of the list (you see, I did not put a commit id there 😁)

The command git revert might be helpful.
https://www.theserverside.com/tutorial/How-to-git-revert-a-commit-A-simple-undo-changes-example

Please do it for the epel7 branch only, no idea about epel8. We should use build continionals to can merge back into rawhide.

Actually I've already manually made them happen in my copr (for Rawhide).

As for epel7, I will only cherry-pick the essential commits, as it already diverse from master branch after the 0.14.1 update in epel7. OTOH, epel7 have older Qt which means we won't be able to have 0.15.0 in epel7. As RHEL 7 is already in maintenance phase, I guess they won't update Qt in RHEL-7 any more.

As for epel8, I was blocked by the circular dependency of bootstraping libfm and menu-cache. They depend on each other. I plan to file a bug to ask the libfm packager to get it down in epel8 before I start trying the others.

I'll push the commits to Rawhide after some testing.

> OTOH, epel7 have older Qt which means we won't be able to have 0.15.0 in epel7. As RHEL 7 is already in maintenance phase, I guess they won't update Qt in RHEL-7 any more.

TBH forgest about epel7 then. It's generally too old stuff with all the package versions around everywhere.

In case of epel8 I'm not sure about the scriptlets. What's in the guidelines?

> As for epel8, I was blocked by the circular dependency of bootstraping libfm and menu-cache. They depend on each other. I plan to file a bug to ask the libfm packager to get it down in epel8 before I start trying the others.

It's libfm-qt obviously, libfm is legacy stuff from those lxde times though that spin still exists with magic. Well, I'm remembering some odd bugs happened with menu-cache.


> I'll push the commits to Rawhide after some testing.

Feel free and take your time. Maybe I can help with some tests done from your copr packages?

(In reply to Raphael Groner from comment #10)
> > OTOH, epel7 have older Qt which means we won't be able to have 0.15.0 in epel7. As RHEL 7 is already in maintenance phase, I guess they won't update Qt in RHEL-7 any more.
> 
> TBH forgest about epel7 then. It's generally too old stuff with all the
> package versions around everywhere.
> 
> In case of epel8 I'm not sure about the scriptlets. What's in the guidelines?
> 

I did not see any guidelines specific for epel8 yet.

> It's libfm-qt obviously, libfm is legacy stuff from those lxde times though
> that spin still exists with magic. Well, I'm remembering some odd bugs
> happened with menu-cache.

Well, LXQt need menu-cache. But menu-cache depends on libfm (not libfm-qt!). However libfm depends on menu-cache as well. The bootstrap mode of libfm still asks for menu-cache.

https://github.com/lxde/libfm/blob/master/configure.ac#L157
https://github.com/lxde/menu-cache/blob/master/configure.ac#L31

I will try to bootstrap with the ancient menu-cache 0.4 to see if it works or not later on.

> 
> > I'll push the commits to Rawhide after some testing.
> 
> Feel free and take your time. Maybe I can help with some tests done from
> your copr packages?

That would be helpful. It's here
https://copr.fedorainfracloud.org/coprs/zsun/lxqt/

I haven't been able to package lxqt-archiver yet. Maybe I will have sometime later this week.

As epel8 seems somehow to be a fork of F29 someone could guess guidelines apply from Fedora 29 or 30, too.

Well, I did not realize that my working laptop have my own copr enabled by default until today. I checked it's already using LXQt 0.15.0 from my copr, which looks good.

I'll start pushing them to Rawhide as soon as I can.

Zamir, any news?

As I'm being too busy since last year, I still prefer to merge when I need to do any future updates in EPEL7. As mentioned LXQt 0.15.0 seems to be too new for EPEL7 so I personally feels this pretty low priority.

HTH

OK, no need to hurry because EPEL. Take and enjoy your time.

EPEL 7 entered end-of-life (EOL) status on 2024-06-30.\n\nEPEL 7 is no longer maintained, which means that it\nwill not receive any further security or bug fix updates.\n As a result we are closing this bug.