Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1151711

Summary: Review Request: liblxqt - Core LXQT library
Product: [Fedora] Fedora Reporter: Eugene A. Pivnev <ti.eugene>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: kevin, package-review, rc040203, rdieter
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-19 14:12:42 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 928937    

Comment 1 Ralf Corsepius 2014-10-14 17:17:12 UTC
Package does not comply to Fedora's packaging conventions to name a package after it's tarname => This package should be named liblxqt

Comment 2 Kevin Kofler 2014-10-14 17:31:35 UTC
(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.

Comment 3 Ralf Corsepius 2014-10-14 17:58:30 UTC
(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 ;)

Comment 4 Eugene A. Pivnev 2014-10-14 18:22:09 UTC
(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.

Comment 5 Eugene A. Pivnev 2014-10-15 07:37:57 UTC
(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.

Comment 6 Ralf Corsepius 2014-10-15 09:34:38 UTC
(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.

Comment 7 Eugene A. Pivnev 2014-10-15 10:26:14 UTC
(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

Comment 8 Ralf Corsepius 2014-10-15 10:48:37 UTC
(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.

Comment 9 Eugene A. Pivnev 2014-10-16 06:08:23 UTC
(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

Comment 10 Eugene A. Pivnev 2014-10-19 14:12:42 UTC
LXQT-0.8.0 released. And it's not compatible with razorqt.
Sorry everybody.
Will try LXQT-0.8.0 with qt5

Comment 11 Rex Dieter 2014-10-30 12:58:12 UTC

*** This bug has been marked as a duplicate of bug 1157402 ***