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 - Review Request: liblxqt - Core LXQT library
Summary: Review Request: liblxqt - Core LXQT library
Keywords:
Status: CLOSED DUPLICATE of bug 1157402
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: qt-reviews
TreeView+ depends on / blocked
 
Reported: 2014-10-11 07:09 UTC by Eugene A. Pivnev
Modified: 2014-10-30 12:58 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-19 14:12:42 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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 ***


Note You need to log in before you can comment on or make changes to this bug.