Spec URL: https://tieugene.fedorapeople.org/rpms/lxqt-libs/lxqt-libs.spec SRPM URL: https://tieugene.fedorapeople.org/rpms/lxqt-libs/lxqt-libs-0.7.0-1.src.rpm Description: Core utility library for all LXQT components Fedora Account System Username: tieugene Koji builds: http://koji.fedoraproject.org/koji/taskinfo?taskID=7830392 EL7 http://koji.fedoraproject.org/koji/taskinfo?taskID=7830424 F19 http://koji.fedoraproject.org/koji/taskinfo?taskID=7830436 F20 http://koji.fedoraproject.org/koji/taskinfo?taskID=7830456 F21 http://koji.fedoraproject.org/koji/taskinfo?taskID=7830482 F22
Package does not comply to Fedora's packaging conventions to name a package after it's tarname => This package should be named liblxqt
(As also noted by Ralf, but with more details, thus he was quicker:) Wouldn't liblxqt make more sense as a package name in this case? I know we often use the *-libs naming convention in Fedora, but we use that for subpackages, where there is a main package called lxqt, and lxqt-libs is a subpackage of that SRPM with one or more libraries. But here, we have a separate upstream tarball called liblxqt, so I don't see a good reason to name the package differently. There are many lib* packages in Fedora, corresponding to upstream lib* tarballs. We just don't like ADDING a prepended "lib" to libraries that do not have it in the upstream name (e.g. libqt) or using "%package -n libfoo" for subpackages.
(In reply to Kevin Kofler from comment #2) > (As also noted by Ralf, but with more details, thus he was quicker:) Actually, I read about the new LXQt release in the press today and was trying to check the status in Fedora. I couldn't find it, until the mails reflecting Rex's changes to this review request arrived ;)
(In reply to Ralf Corsepius from comment #3) > (In reply to Kevin Kofler from comment #2) > > (As also noted by Ralf, but with more details, thus he was quicker:) > Actually, I read about the new LXQt release in the press today and was > trying to check the status in Fedora. I couldn't find it, until the mails > reflecting Rex's changes to this review request arrived ;) lxqt-0.8.0 is in progress. And this "in progress" doesn't mean rejecting lxqt-0.7.0. Because: * pushing lxqt into fedora/centos/rhel requires tooolong cat * I hope to catch it (lxqt) befor f21 release. * maybe - will be Fedora-21-LXQT-Spin.iso. Maybe.
(In reply to Ralf Corsepius from comment #3) > (In reply to Kevin Kofler from comment #2) > > (As also noted by Ralf, but with more details, thus he was quicker:) > Actually, I read about the new LXQt release in the press today and was > trying to check the status in Fedora. I couldn't find it, until the mails > reflecting Rex's changes to this review request arrived ;) Hm... lxqt-0.8.0 requires libqtxdg-1.0.0, that requires qtmimetypes... I have to test new libqtxdg with razorqt. I think lxqt-0.7.0 as stable is best way now.
(In reply to Eugene A. Pivnev from comment #5) > Hm... lxqt-0.8.0 requires libqtxdg-1.0.0, Where? I do not see such dependency.
(In reply to Ralf Corsepius from comment #6) > (In reply to Eugene A. Pivnev from comment #5) > > Hm... lxqt-0.8.0 requires libqtxdg-1.0.0, > Where? I do not see such dependency. Try to compile: /mnt/shares/home/eugene/rpmbuild/BUILD/lxqt-0.8.0/lxqt-config-0.8.0/lxqt-config-file-associations/mimetypedata.h:32:23: fatal error: XdgMimeType: No such file or directory #include <XdgMimeType> And liblxqt-1.0.0 requires qtmimetype. That is not compilable in RHEL6 and x64: https://build.opensuse.org/package/show/X11:QtDesktop:LXQT/qtmimetypes But razorqt requires libqtxdg... It's a Long Way to Tipperary
(In reply to Eugene A. Pivnev from comment #7) > (In reply to Ralf Corsepius from comment #6) > > (In reply to Eugene A. Pivnev from comment #5) > > > Hm... lxqt-0.8.0 requires libqtxdg-1.0.0, > > Where? I do not see such dependency. > > Try to compile: > /mnt/shares/home/eugene/rpmbuild/BUILD/lxqt-0.8.0/lxqt-config-0.8.0/lxqt- > config-file-associations/mimetypedata.h:32:23: fatal error: XdgMimeType: No > such file or directory > #include <XdgMimeType> Thanks, I see. Another problem is lxqt-admin. It depends on liboops, a library which isn't in Fedora and seems to be dead upstream. > That is not compilable in RHEL6 I don't care. This is Fedora and we do not care about what's in RHEL.
(In reply to Ralf Corsepius from comment #1) > Package does not comply to Fedora's packaging conventions to name a package > after it's tarname => This package should be named liblxqt Spec URL: https://tieugene.fedorapeople.org/rpms/liblxqt/liblxqt.spec SRPM URL: https://tieugene.fedorapeople.org/rpms/liblxqt/liblxqt-0.7.0-1.src.rpm Koji build (f21): http://koji.fedoraproject.org/koji/taskinfo?taskID=7879723
LXQT-0.8.0 released. And it's not compatible with razorqt. Sorry everybody. Will try LXQT-0.8.0 with qt5
*** This bug has been marked as a duplicate of bug 1157402 ***