Spec URL: https://gbcox.fedorapeople.org/specs/copyq.spec SRPM URL: https://repos.fedorapeople.org/repos/gbcox/forefront/fedora-21/SRPMS/copyq-2.4.6-1.src.rpm Description: CopyQ is advanced clipboard manager with searchable and editable history with support for image formats, command line control and more. Featured in Linux Magazine: http://www.linux-magazine.com/Issues/2013/154/CopyQ Project site: http://sourceforge.net/projects/copyq/ Is a great package for all DMs, but it's few dependencies and low resource requirements make it a good match for LXQt. Fedora Account System Username: gbcox
*** Bug 1130472 has been marked as a duplicate of this bug. ***
Regarding licensing of some of the QT files: https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#How_should_I_handle_multiple_licensing_situations.3F The source code contains some .c files which are GPLv2+ and some other .c files which are BSD. They're compiled together to form an executable. Since some of the files are licensed as GPL, the resulting executable is also GPL. The License tag should read: License: GPLv2+ Note that you do NOT need to list BSD in the License tag, the License tag reflects the resulting, packaged, items in the binary RPM.
Regarding the comment regarding gtk-icon-cache, this does not apply since it is a Qt application, in order for this to work I would need to add gtk as a dependency and as the note says, this is not required: Note that no dependencies should be added for this. If gtk-update-icon-cache is not available, there's nothing that would be needing the cache update, ditto if "touch" is not available, there's nothing that would benefit from icon cache updates installed yet either. Not adding the dependency on gtk-update-icon-cache (ie. gtk2 >= 2.6.0) or "touch" makes it easier to use the package (or the same specfile) on systems where it's not available nor needed, such as older distro versions or (very) trimmed down installations, and generally results in less entries in specfiles, rpmdb, and repo metadatas.
Revised file location... Spec URL: https://gbcox.fedorapeople.org/specs/copyq.spec SRPM URL: https://repos.fedorapeople.org/repos/gbcox/forefront/fedora-21/SRPMS/copyq-2.4.6-1.fc21.src.rpm
%global name copyq %global version 2.4.6 %global release 1 %global build_req cmake, libXtst-devel, qt4-devel, qtwebkit-devel Why do you define these macros? They're already defined as RPM packaging macros.
It's a stylistic choice, I think it makes it easier to maintain the spec. I didn't see where they were predefined: http://rpm.org/api/4.4.2.2/config_macros.html Can you give me a URL if it is an issue?
(In reply to Gerald Cox from comment #6) > It's a stylistic choice, I think it makes it easier to maintain the spec. I > didn't see where they were predefined: > http://rpm.org/api/4.4.2.2/config_macros.html Name: copyq Summary: Advanced clipboard manager Version: 2.4.6 Release: 1%{?dist} License: GPLv3+ Url: http://sourceforge.net/projects/copyq/ Source0: http://sourceforge.net/projects/copyq/files/%{name}-%{version}.tar.gz BuildRequires: cmake, libXtst-devel, qt4-devel, qtwebkit-devel --- %global name %global version %global release %global build_req are redundant. See http://fedoraproject.org/wiki/How_to_create_an_RPM_package > > Can you give me a URL if it is an issue? $ cat /usr/lib/rpm/macros --- Then 1) %{__make} %{?jobs:-j%jobs} --> make %{?_smp_mflags} You don't need to indicate full path to the executable 2) %{_datadir}/applications/%{name}.desktop You must validate every desktop file. http://fedoraproject.org/wiki/Packaging:Guidelines#desktop-file-install_usage http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#desktop-database 3) %{_datadir}/icons/hicolor/*/apps/%{name}*.svg "If an application installs icons into one of the subdirectories in %{_datadir}/icons/ (such as hicolor in the following examples), icon caches must be updated so that the installed icons show up in menus right after package installation." http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache 4) %{_datadir}/copyq/translations/*.qm http://fedoraproject.org/wiki/Packaging:Guidelines#Handling_Locale_Files 5) %clean rm -rf $RPM_BUILD_ROOT %defattr(-,root,root) Unless you wish to package copyq in EPEL5, commands above are redundant. http://fedoraproject.org/wiki/EPEL:Packaging#Cleaning_BuildRoot_in_.25clean 6) Use %license macro to mark the LICENSE file.
Antonio, Thanks, I'll review and update as appropriate. Also, I forgot to comment on the qt/qxt files (qt-examples, libqxt-devel). I'm going to discuss that upstream to see how he wishes to handle.
Antonio, Thanks again for your assistance and time. I've incorporated all your recommendations and refreshed the spec file. Just waiting for a response on how upstream wants to handle qt-examples and libqxt-devel.
Antonio, I got a response from upstream. Basically the few files that were from qt-examples the developer needed to make some modifications. Regarding the files from qxtlib-devel, those were also modified. Additionally, qxtlib is no longer maintained and that project recommends you don't include the entire library, but rather just take and modify what you need. http://dev.libqxt.org/libqxt/wiki/Home I'm also thinking that qt-examples is meant to be also used in that manner. Just to check I did: dnf repoquery --whatrequires qt-examples It returned no packages. Just for grins I did the same with ligqxt-devel... same thing, it returned no packages. That said, I don't think this is an issue. Do you agree?
(In reply to Gerald Cox from comment #10) > Antonio, > I got a response from upstream. Basically the few files that were from > qt-examples the developer needed to make some modifications. Regarding the > files from qxtlib-devel, those were also modified. Additionally, qxtlib is > no longer maintained and that project recommends you don't include the > entire library, but rather just take and modify what you need. > http://dev.libqxt.org/libqxt/wiki/Home > > I'm also thinking that qt-examples is meant to be also used in that manner. > Just to check I did: > dnf repoquery --whatrequires qt-examples > It returned no packages. > > Just for grins I did the same with ligqxt-devel... same thing, it returned > no packages. > > That said, I don't think this is an issue. Do you agree? Sorry i don't understand. Agree about what? Those files should be removed before to compile because bundled. In particular, header files in ./qt and in ./qtx are already packaged in Fedora (respectively in qt*-examples and libqxt-devel).
> %global name copyq > %global version 2.4.6 > %global release 1 > > It's a stylistic choice, I think it makes it easier to maintain > the spec. I didn't see where they were predefined: What becomes easier? You can rearrange the lines in your spec file to move "Name:", "Version:" and "Release:" to the top with an empty line for better readability. You are not forced to copy the order of the lines from other people's spec files. And yes, the tags "Name:", "Version:" and "Release:" define %{name}, %{version} and %{release}, respectively. Defining them as globals prior to assigning them to the tags doesn't add any benefit. The redefinition bears a risk even. Consider this: %global release 1 Release: %{release}%{?dist} The "Release:" tag overrides the definition of %{release}. Through-out the spec file where you use %{release}, its value will not be 1 due to the redefinition.
(In reply to Antonio Trande from comment #11) > (In reply to Gerald Cox from comment #10) > Sorry i don't understand. > Agree about what? > > Those files should be removed before to compile because bundled. > In particular, header files in ./qt and in ./qtx are already packaged in > Fedora (respectively in qt*-examples and libqxt-devel). Unless I am mistaken I used the command: dnf repoquery --whatrequires qt-examples dnf repoquery --whatrequires libqxt-devel I receive zero packages, which apparently shows that no one else is using these as package requirements.
(In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment #12) > What becomes easier? > > You can rearrange the lines in your spec file to move "Name:", "Version:" > and "Release:" to the top with an empty line for better readability. You are > not forced to copy the order of the lines from other people's spec files. > > And yes, the tags "Name:", "Version:" and "Release:" define %{name}, > %{version} and %{release}, respectively. Defining them as globals prior to > assigning them to the tags doesn't add any benefit. > > The redefinition bears a risk even. Consider this: > > %global release 1 > Release: %{release}%{?dist} > > The "Release:" tag overrides the definition of %{release}. Through-out the > spec file where you use %{release}, its value will not be 1 due to the > redefinition. Michael, Thanks for taking the time to comment. I agree and have already made the change.
(In reply to Gerald Cox from comment #13) > (In reply to Antonio Trande from comment #11) > > (In reply to Gerald Cox from comment #10) > > > Sorry i don't understand. > > Agree about what? > > > > Those files should be removed before to compile because bundled. > > In particular, header files in ./qt and in ./qtx are already packaged in > > Fedora (respectively in qt*-examples and libqxt-devel). > > Unless I am mistaken I used the command: > dnf repoquery --whatrequires qt-examples > dnf repoquery --whatrequires libqxt-devel > > I receive zero packages, which apparently shows that no one else is using > these as package requirements. Okay but does copyq need it or not? In both cases a way out exists.
(In reply to Antonio Trande from comment #15) > Okay but does copyq need it or not? > In both cases a way out exists. Thanks again for your quick replies and help. Yes, copyq needs the files. The files have been changed. They are not what is in the Fedora repository.
I'm gonna look through my disk to find my spec and post it here if there are any substantial differences.
(In reply to Gerald Cox from comment #16) > (In reply to Antonio Trande from comment #15) > > > Okay but does copyq need it or not? > > In both cases a way out exists. > > Thanks again for your quick replies and help. > Yes, copyq needs the files. The files have been changed. They are not > what is in the Fedora repository. If they have been patched by upstream because of their own needs, you will have to ask a bundled file exception so.
Antonio what about this: https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries Conditionalized functionality Packages which bundle specific subsets of third-party source code with the sole purpose of providing functionality that is not available in the system copy, and explicitly conditionalize that use in such a way that if the system copy provides that functionality, the bundled source code is not used, are exempt from the requirement to delete the bundled source code during %prep. Packages in this exception case MUST document this situation in a specfile comment, and verify that the functionality is properly conditionalized with each update.
(In reply to Gerald Cox from comment #19) > Antonio what about this: > https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries > > Conditionalized functionality > Packages which bundle specific subsets of third-party source code with the > sole purpose of providing functionality that is not available in the system > copy, and explicitly conditionalize that use in such a way that if the > system copy provides that functionality, the bundled source code is not > used, are exempt from the requirement to delete the bundled source code > during %prep. Packages in this exception case MUST document this situation > in a specfile comment, and verify that the functionality is properly > conditionalized with each update. An example of bundled files exception. https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions
Antonio, What I am saying is that this particular instance I believe falls under the category of "Conditionalized functionality". The package does not bundle the entire library, only a subset. The files have been changed because the functionality is not available in the system copy. An exception for this case already exists. All I need to do is document the spec file accordingly.
I submitted this question to the Fedora packagers list: I am working on packaging a program which includes a very small subset of files from these packages. From qt-examples, there are four files. From libqxt-devel, there are three files. All of the files have been modified for use by the application. I have done a search to see if these rpms are build requires for other packages: dnf repoquery --whatrequires qt-examples dnf repoquery --whatrequires libqxt-devel In both cases I receive zero hits. I'm thinking now that qt-examples doesn't really qualify as a "library". It is described as "Programming Examples for Qt" - which to me means the intent is to take what you need and modify. The intent was never that this be a "library". In the case of libqxt-devel: http://dev.libqxt.org/libqxt/wiki/Home The website says: "This package is no longer maintained. Qxt will likely not work with newer Qt versions due to usage of internal api. We recommend that you pick out the parts you want instead of using the entire libqxt." Which is exactly what the developer did. Considering the above, I'm thinking no exception is required for the inclusion of these 7 files. Comments? I don't want to waste peoples time by going through the exception process if it isn't needed. Thanks very much!
Antonio, Kevin replied on the packagers mailing list... libext is covered by the copylib blanket exception. qt-examples are just as stated, the contents are examples and isn't a library so no exception is needed. Gerald B. Cox wrote: > libqxt is no longer maintained: > http://dev.libqxt.org/libqxt/wiki/Home > and that project is recommending that you do what the develop did... which > is not use the entire library and just pick out the parts you need. That means it falls under the "copylib" blanket exception. I don't really like that, but if the upstream project refuses to provide a usable library, there's not much other that can be done than copying. > qt-examples by the name seems to imply the same thing. These are examples > to be modified and used. Examples are clearly material for copy&paste, they aren't even libraries. So that is not a bundled library at all. Kevin Kofler
(In reply to Gerald Cox from comment #23) Sorry, I had a typo above, I meant to say libqxt rather than libext. You can proceed with the package review. Exceptions for libqxt and qt-examples are not needed. Thanks!
(In reply to Gerald Cox from comment #24) > (In reply to Gerald Cox from comment #23) > > Sorry, I had a typo above, I meant to say libqxt rather than libext. You > can proceed with the package review. Exceptions for libqxt and qt-examples > are not needed. Thanks! Please, post another review release every time you change the SPEC file. - Scriptlets are incomplete See http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache %post /bin/touch --no-create %{_datadir}/icons/hicolor/scalable/apps &>/dev/null || : %postun if [ $1 -eq 0 ] ; then /bin/touch --no-create %{_datadir}/icons/hicolor/scalable/apps &>/dev/null /usr/bin/gtk-update-icon-cache %{_datadir}/icons/hicolor/scalable/apps &>/dev/null || : fi %posttrans /usr/bin/gtk-update-icon-cache %{_datadir}/icons/hicolor/scalable/apps &>/dev/null || : - Package does not own files or directories owned by other packages. %{_datadir}/icons/hicolor is owned by other package. copyq must own just own files: %{_datadir}/icons/hicolor/scalable/apps/%{name}*.svg - Package must own all directories that it creates. > %dir %{_datadir}/%{name} > %dir %{_datadir}/%{name}/themes > %{_datadir}/%{name}/themes/*.ini can be replaced by a simple %{_datadir}/%{name}/ - > %{_libdir}/%{name} can be replaced by %{_libdir}/%{name}/ - %build honors compiler flags are not used. Please use %cmake macro. - %defattr(-,root,root) is useless - %{_prefix}/%{_lib} = %{_libdir} - Upstream provides some tests which may be ran during the RPM building. - AUTHORS, CHANGES, README.md, HACKING files can be packaged as documentation - It's possible to generate HTML documentation with doxygen and also a manpage by using help2man tool. Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - gtk-update-icon-cache is invoked in %postun and %posttrans if package contains icons. Note: icons in copyq See: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache - If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. Note: Cannot find LICENSE in rpm(s) See: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files in private %_libdir subdirectory (see attachment). Verify they are not in ld path. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "BSD (3 clause)", "GPL (v3 or later)", "Unknown or generated". 34 files have unknown license. Detailed output of licensecheck in /home/sagitter/1211831-copyq/licensecheck.txt [!]: Package requires other packages for directories it uses. Note: No known owner of /usr/share/copyq/translations [!]: Package must own all directories that it creates. Note: Directories without known owners: /usr/share/copyq/translations [!]: Package does not own files or directories owned by other packages. Note: Dirs in package are owned also by: /usr/share/icons/hicolor/scalable/apps(hicolor-icon-theme, fedora-logos), /usr/share/icons/hicolor(hicolor-icon-theme, fedora-logos), /usr/share/icons/hicolor/scalable(hicolor-icon-theme, fedora-logos) [!]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [!]: Each %files section contains %defattr if rpm < 4.4 Note: %defattr present but not needed [-]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [!]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [-]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [!]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. Note: Test run failed [?]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Test run failed [x]: Packages must not store files under /srv, /opt or /usr/local Note: Test run failed [!]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Package contains desktop file if it is a GUI application. [x]: Package installs a %{name}.desktop using desktop-file-install or desktop- file-validate if there is such a file. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package do not use a name that already exist [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [!]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [!]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: Dist tag is present (not strictly required in GL). [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Uses parallel make %{?_smp_mflags} macro. [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [?]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Test run failed [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: copyq-2.4.6-1.fc23.x86_64.rpm copyq-2.4.6-1.fc23.src.rpm copyq.x86_64: W: spelling-error %description -l en_US searchable -> search able, search-able, unsearchable copyq.x86_64: W: no-manual-page-for-binary copyq copyq.src: W: spelling-error %description -l en_US searchable -> search able, search-able, unsearchable 2 packages and 0 specfiles checked; 0 errors, 3 warnings. Rpmlint (installed packages) ---------------------------- Cannot parse rpmlint output: Requires -------- copyq (rpmlib, GLIBC filtered): /bin/sh libICE.so.6()(64bit) libQtCore.so.4()(64bit) libQtGui.so.4()(64bit) libQtNetwork.so.4()(64bit) libQtScript.so.4()(64bit) libQtSvg.so.4()(64bit) libQtWebKit.so.4()(64bit) libQtXml.so.4()(64bit) libSM.so.6()(64bit) libX11.so.6()(64bit) libXext.so.6()(64bit) libXfixes.so.3()(64bit) libXtst.so.6()(64bit) libc.so.6()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libm.so.6()(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) rtld(GNU_HASH) Provides -------- copyq: application() application(copyq.desktop) copyq copyq(x86-64) libitemdata.so()(64bit) libitemencrypted.so()(64bit) libitemfakevim.so()(64bit) libitemimage.so()(64bit) libitemnotes.so()(64bit) libitemsync.so()(64bit) libitemtags.so()(64bit) libitemtext.so()(64bit) libitemweb.so()(64bit) Unversioned so-files -------------------- copyq: /usr/lib64/copyq/plugins/libitemdata.so copyq: /usr/lib64/copyq/plugins/libitemencrypted.so copyq: /usr/lib64/copyq/plugins/libitemfakevim.so copyq: /usr/lib64/copyq/plugins/libitemimage.so copyq: /usr/lib64/copyq/plugins/libitemnotes.so copyq: /usr/lib64/copyq/plugins/libitemsync.so copyq: /usr/lib64/copyq/plugins/libitemtags.so copyq: /usr/lib64/copyq/plugins/libitemtext.so copyq: /usr/lib64/copyq/plugins/libitemweb.so Source checksums ---------------- http://sourceforge.net/projects/copyq/files/copyq-2.4.6.tar.gz : CHECKSUM(SHA256) this package : 04e6b944f8d85ee50ce40814fc44cfa1fec21a1957fd48ea155378b3fedaf895 CHECKSUM(SHA256) upstream package : 04e6b944f8d85ee50ce40814fc44cfa1fec21a1957fd48ea155378b3fedaf895 Generated by fedora-review 0.5.2 (63c24cb) last change: 2014-07-14 Command line :/usr/bin/fedora-review -m fedora-rawhide-x86_64 -b 1211831 Buildroot used: fedora-rawhide-x86_64 Active plugins: Generic, Shell-api, C/C++ Disabled plugins: Java, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby Disabled flags: EXARCH, EPEL5, BATCH, DISTTAG
Antonio, Thanks for the quick and detailed response. The icon-cache issue was a result of me mis-interpreting the instructions in comment 3. I'm currently applying all of your recommendations. I do have a comment regarding the error: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. Note: Cannot find LICENSE in rpm(s) See: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text You had mentioned that earlier and pointed me to the guidelines which said that now the license should be in %license. However the error above is saying that it needs to be in %doc. I'm assuming that %license is correct and the %doc error is wrong and is to be ignored. Can you please clarify? Thanks!
(In reply to Gerald Cox from comment #26) > Antonio, Thanks for the quick and detailed response. The icon-cache issue > was a result of me mis-interpreting the instructions in comment 3. I'm > currently applying all of your recommendations. > > I do have a comment regarding the error: > > If (and only if) the source package includes the text of the license(s) in > its own file, then that file, containing the text of the license(s) for the > package is included in %doc. > Note: Cannot find LICENSE in rpm(s) > See: > http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text > > You had mentioned that earlier and pointed me to the guidelines which said > that now the license should be in %license. However the error above is > saying that it needs to be in %doc. I'm assuming that %license is correct > and the %doc error is wrong and is to be ignored. > > Can you please clarify? Thanks! It's a false positive from fedora-review checks. https://bugzilla.redhat.com/show_bug.cgi?id=1127916
Hello Antonio, I've uploaded a revised spec file with the changes recommended implemented. I unfortunately couldn't use the: can be replaced by a simple %{_datadir}/%{name}/ because that gave me duplicate file errors because of the -f *.lang statement. Thanks again for your assistance.
(In reply to Gerald Cox from comment #28) > Hello Antonio, > > I've uploaded a revised spec file with the changes recommended implemented. > I unfortunately couldn't use the: > > can be replaced by a simple > %{_datadir}/%{name}/ > > because that gave me duplicate file errors because of the -f *.lang > statement. > > Thanks again for your assistance. What error? (In reply to Gerald Cox from comment #28) > Hello Antonio, > > I've uploaded a revised spec file with the changes recommended implemented. > I unfortunately couldn't use the: > > can be replaced by a simple > %{_datadir}/%{name}/ > > because that gave me duplicate file errors because of the -f *.lang > statement. > > Thanks again for your assistance. Set cmake option -DTRANSLATION_INSTALL_PREFIX:PATH=share/%{name}/locale to support find-lang destination directories. copyq tests are missing as well HTML doc and manpage. Does copyq need of additional icons ?
Wow, you're fast... thanks so much again... (In reply to Antonio Trande from comment #29) > (In reply to Gerald Cox from comment #28) > What error? (In reply to Gerald Cox from comment #28) warning: File listed twice: /usr/share/copyq/locale/copyq_af.qm warning: File listed twice: /usr/share/copyq/locale/copyq_cs.qm warning: File listed twice: /usr/share/copyq/locale/copyq_da.qm warning: File listed twice: /usr/share/copyq/locale/copyq_de.qm warning: File listed twice: /usr/share/copyq/locale/copyq_es.qm warning: File listed twice: /usr/share/copyq/locale/copyq_fr.qm warning: File listed twice: /usr/share/copyq/locale/copyq_hu.qm warning: File listed twice: /usr/share/copyq/locale/copyq_it.qm warning: File listed twice: /usr/share/copyq/locale/copyq_ja.qm warning: File listed twice: /usr/share/copyq/locale/copyq_pl.qm warning: File listed twice: /usr/share/copyq/locale/copyq_pt_BR.qm warning: File listed twice: /usr/share/copyq/locale/copyq_ru.qm warning: File listed twice: /usr/share/copyq/locale/copyq_tr.qm warning: File listed twice: /usr/share/copyq/locale/copyq_uk.qm warning: File listed twice: /usr/share/copyq/locale/copyq_zh_CN.qm warning: File listed twice: /usr/share/copyq/locale/copyq_zh_TW.qm > copyq tests are missing as well HTML doc and manpage. I plan to work with upstream with the additional documentation and have it incorporated later. I didn't do the copyq tests because I thought they were not listed as "must", but were optional. Is that not correct? > > Does copyq need of additional icons ? I have requested the developer add additional icons, which I will incorporate in a future release. For now *.svg are the only ones included. I have added the cmake option. Thanks for that. I will be posting a new version of the spec file shortly.
(In reply to Gerald Cox from comment #30) > Wow, you're fast... thanks so much again... > > (In reply to Antonio Trande from comment #29) > > (In reply to Gerald Cox from comment #28) > > What error? (In reply to Gerald Cox from comment #28) > > warning: File listed twice: /usr/share/copyq/locale/copyq_af.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_cs.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_da.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_de.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_es.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_fr.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_hu.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_it.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_ja.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_pl.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_pt_BR.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_ru.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_tr.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_uk.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_zh_CN.qm > warning: File listed twice: /usr/share/copyq/locale/copyq_zh_TW.qm They're just warnings and we know why they come out. > > > > copyq tests are missing as well HTML doc and manpage. > I plan to work with upstream with the additional documentation and have it > incorporated later. I didn't do the copyq tests because I thought they were > not listed as "must", but were optional. Is that not correct? Tests are advisable and may point out problems... > > > > > Does copyq need of additional icons ? > I have requested the developer add additional icons, which I will > incorporate in a future release. For now *.svg are the only ones included. > > I have added the cmake option. Thanks for that. > > I will be posting a new version of the spec file shortly.
I'm having problems contacting my build system right now... I'll let you know when I can get the revised spec posted. Thanks again. I really appreciate it.
Antonio... ok, I have uploaded a revised spec. The tests aren't really designed for packaging, they are more for development.
(In reply to Gerald Cox from comment #33) > Antonio... ok, I have uploaded a revised spec. The tests aren't really > designed for packaging, they are more for development. http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs Please, post a new release with related SPEC/SRPM links after sec file changing. > This page describes how to run automatic test cases to see if the application > works properly. https://github.com/hluk/CopyQ/wiki/Running-Tests It seems to me a good reason to do that in the RPM packaging.
(In reply to Antonio Trande from comment #34) > (In reply to Gerald Cox from comment #33) > > Antonio... ok, I have uploaded a revised spec. The tests aren't really > > designed for packaging, they are more for development. > > http://fedoraproject.org/wiki/Packaging:Guidelines#Changelogs > > Please, post a new release with related SPEC/SRPM links after sec file > changing. > I didn't think that applied during the review process, but I'll do it going forward. > > This page describes how to run automatic test cases to see if the application > works properly. > https://github.com/hluk/CopyQ/wiki/Running-Tests > > It seems to me a good reason to do that in the RPM packaging. The tests require the program to be compiled with test flags on. qmake doesn't exist, that script would need to be patched. The actual running of tests, starts the copyq server. I'm using the application now... it is functioning properly. If you want me to post a .2 version of the spec before you review again I will, but the .1 version has the changes and is ready for your review. Thanks again!
Antonio, I think I was misinterpreting what you asking. I will change to allow users to run the testing. I was thinking that you wanted the actual testing done during the build. I will put it in a .2 spec file. ;-) Thanks!
Revised file location... Spec URL: https://gbcox.fedorapeople.org/specs/copyq.spec SRPM URL: https://repos.fedorapeople.org/repos/gbcox/forefront/fedora-21/SRPMS/copyq-2.4.6-2.fc21.src.rpm
> Bumping %release for each update during review is an old item on this list: https://fedoraproject.org/wiki/Packaging:FrequentlyMadeMistakes > warning: File listed twice: /usr/share/copyq/locale/copyq_af.qm If there's disagreement between package submitter and reviewer, often it's a good idea to look up what the packaging guidelines say: https://fedoraproject.org/wiki/Packaging:Guidelines#Duplicate_Files | A Fedora package must not list a file more than once in the spec | file's %files listings. If you think your package is a valid exception | to this, please bring it to the attention of the Packaging Committee | so they can improve on this Guideline. So, in this particular case you would have the %files list from %find_lang and the tree of files as added by %_datadir/%name. The former with %lang(…) attributes, the latter without. One can only hope that rpmbuild doesn't take either one, but prefers the entries with %lang attribute. There is _nothing wrong_ with a longer explicit %files section, which only includes what %find_lang doesn't (not limited to the /usr/share/copyq/locale directory). If Gerald prefers %dir %{_datadir}/%{name} %dir %{_datadir}/%{name}/locale %{_datadir}/%{name}/themes/ nothing wrong with that. I don't understand why it's felt as important to request including only %_datadir/%name just to save two lines (or a few more in the future). Btw, the packager could even append to %name.lang in %install and shorten the visible %files section further. ;-) The spec file would not get more readable, though.
(In reply to Michael Schwendt (Fedora Packager Sponsors Group) from comment #38) > > Bumping %release for each update during review is an old item on this list: > > https://fedoraproject.org/wiki/Packaging:FrequentlyMadeMistakes Yes, my bad, wrong assumption. I've corrected going forward with the -2 which I posted earlier. > > > warning: File listed twice: /usr/share/copyq/locale/copyq_af.qm > Yes, I noticed the warnings. I initially thought %find_lang would also include the directory, which it didn't and caused the directory ownership error, so I had explicitly listed the %dir to resolve all that.
> There is _nothing wrong_ with a longer explicit %files section, > which only includes what %find_lang doesn't > (not limited to the /usr/share/copyq/locale directory). If Gerald prefers > > %dir %{_datadir}/%{name} > %dir %{_datadir}/%{name}/locale > %{_datadir}/%{name}/themes/ > >nothing wrong with that. > I don't understand why it's felt as important to request including > only %_datadir/%name just to save two lines (or a few more in the future). I have not any problem to list all directories explicitly except files listed twice. I thought that it was not so important. Gerald, you can follow Michael's advice of course. - INSTALL is not required for packaging - Have you looked why some tests fail ? If you execute "copyq tests", not all finish successfully. You can run all tests (or specific tests) by %check xvfb-run -a ./copyq tests in the RPM packaging - copyq does not work for me. Try to strace it, a lot of icons are not found. Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - Package does not contain duplicates in %files. Note: warning: File listed twice: /usr/share/copyq/locale/copyq_af.qm See: http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles - If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. Note: Cannot find LICENSE in rpm(s) See: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files in private %_libdir subdirectory (see attachment). Verify they are not in ld path. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "BSD (3 clause)", "GPL (v3 or later)", "Unknown or generated". 34 files have unknown license. Detailed output of licensecheck in /home/sagitter/1211831-copyq/licensecheck.txt [x]: Package must own all directories that it creates. Note: Directories without known owners: /usr/share/icons/hicolor/scalable/apps, /usr/share/icons/hicolor, /usr/share/icons/hicolor/scalable [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: gtk-update-icon-cache is invoked in %postun and %posttrans if package contains icons. Note: icons in copyq [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. Note: Test run failed [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Test run failed [x]: Packages must not store files under /srv, /opt or /usr/local Note: Test run failed [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: Package requires other packages for directories it uses. [x]: Package does not own files or directories owned by other packages. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Package contains desktop file if it is a GUI application. [x]: Package installs a %{name}.desktop using desktop-file-install or desktop- file-validate if there is such a file. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package do not use a name that already exist [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [?]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [?]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: Dist tag is present (not strictly required in GL). [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Uses parallel make %{?_smp_mflags} macro. [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Test run failed [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: copyq-2.4.6-2.fc23.x86_64.rpm copyq-2.4.6-2.fc23.src.rpm copyq.x86_64: W: spelling-error %description -l en_US searchable -> search able, search-able, unsearchable copyq.x86_64: W: no-manual-page-for-binary copyq copyq.x86_64: W: install-file-in-docs /usr/share/doc/copyq/INSTALL copyq.src: W: spelling-error %description -l en_US searchable -> search able, search-able, unsearchable 2 packages and 0 specfiles checked; 0 errors, 4 warnings. Rpmlint (installed packages) ---------------------------- Cannot parse rpmlint output: Requires -------- copyq (rpmlib, GLIBC filtered): /bin/sh libICE.so.6()(64bit) libQtCore.so.4()(64bit) libQtGui.so.4()(64bit) libQtNetwork.so.4()(64bit) libQtScript.so.4()(64bit) libQtSvg.so.4()(64bit) libQtTest.so.4()(64bit) libQtWebKit.so.4()(64bit) libQtXml.so.4()(64bit) libSM.so.6()(64bit) libX11.so.6()(64bit) libXext.so.6()(64bit) libXfixes.so.3()(64bit) libXtst.so.6()(64bit) libc.so.6()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libm.so.6()(64bit) libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit) rtld(GNU_HASH) Provides -------- copyq: application() application(copyq.desktop) copyq copyq(x86-64) libitemdata.so()(64bit) libitemencrypted.so()(64bit) libitemfakevim.so()(64bit) libitemimage.so()(64bit) libitemnotes.so()(64bit) libitemsync.so()(64bit) libitemtags.so()(64bit) libitemtext.so()(64bit) libitemweb.so()(64bit) Unversioned so-files -------------------- copyq: /usr/lib64/copyq/plugins/libitemdata.so copyq: /usr/lib64/copyq/plugins/libitemencrypted.so copyq: /usr/lib64/copyq/plugins/libitemfakevim.so copyq: /usr/lib64/copyq/plugins/libitemimage.so copyq: /usr/lib64/copyq/plugins/libitemnotes.so copyq: /usr/lib64/copyq/plugins/libitemsync.so copyq: /usr/lib64/copyq/plugins/libitemtags.so copyq: /usr/lib64/copyq/plugins/libitemtext.so copyq: /usr/lib64/copyq/plugins/libitemweb.so Source checksums ---------------- http://sourceforge.net/projects/copyq/files/copyq-2.4.6.tar.gz : CHECKSUM(SHA256) this package : 04e6b944f8d85ee50ce40814fc44cfa1fec21a1957fd48ea155378b3fedaf895 CHECKSUM(SHA256) upstream package : 04e6b944f8d85ee50ce40814fc44cfa1fec21a1957fd48ea155378b3fedaf895 Generated by fedora-review 0.5.2 (63c24cb) last change: 2014-07-14 Command line :/usr/bin/fedora-review -m fedora-rawhide-x86_64 -b 1211831 Buildroot used: fedora-rawhide-x86_64 Active plugins: Generic, Shell-api, C/C++ Disabled plugins: Java, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP, Ruby Disabled flags: EXARCH, EPEL5, BATCH, DISTTAG
(In reply to Antonio Trande from comment #40) > > Gerald, you can follow Michael's advice of course. Antonio, if you know of another method to resolve the duplicate file issue, please let me know. I am always open to new ideas and techniques. The only way I know to get rid of the warnings in a straight forward and easy to understand way is by using %dir. > > - INSTALL is not required for packaging OK, I've removed it from %doc > > - Have you looked why some tests fail ? The tests all run fine for me. http://goo.gl/dHoKlS Remember, these tests are not intended for packaging, and require quite a bit of time to run - depending on your machine up to 15 minutes. I did have a conversation with the developer because I was a bit concerned that turning them on may impact normal performance. That doesn't appear to be the case, however depending on when and how they are used could cause some confusion to the end user. The developer is going to add some additional information to the test instructions to clarify when and how they should be used. > If you execute "copyq tests", not all finish successfully. Try running them from your desktop environment after you have installed the package. You should see them running, it is a bit entertaining to watch. Get a cup of coffee though, it takes some time. > > You can run all tests (or specific tests) by > > %check > xvfb-run -a ./copyq tests > > in the RPM packaging The tests won't work in packaging since they are designed to be run from the desktop environment. > > - copyq does not work for me. That is strange, I have run it on two separate machines with no problem. This probably would be an instance where you would want to run the tests (from your desktop environment) and report the results. > Try to strace it, a lot of icons are not found. Yes, I am aware of the icon issue and am working with the developer to correct. See comment #30. That should not be affecting the functionality of the program. > > Issues: > ======= > - Package does not contain duplicates in %files. > Note: warning: File listed twice: /usr/share/copyq/locale/copyq_af.qm > See: http://fedoraproject.org/wiki/Packaging/Guidelines#DuplicateFiles I will correct this using the %dir - but if you know of a better way, let me know. > - If (and only if) the source package includes the text of the license(s) in > its own file, then that file, containing the text of the license(s) for the > package is included in %doc. > Note: Cannot find LICENSE in rpm(s) > See: > http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text > > This is a false positive, as you pointed out in comment #27. As always, thanks again for your help. It is much appreciated.
(In reply to Gerald Cox from comment #41) > > > > - Have you looked why some tests fail ? > The tests all run fine for me. http://goo.gl/dHoKlS > Remember, these tests are not intended for packaging, and > require quite a bit of time to run - depending on your > machine up to 15 minutes. I did have a conversation with the > developer because I was a bit concerned that turning them on may impact > normal performance. That doesn't appear to be the case, however depending > on when and how they are used could cause some confusion to the end user. > The developer is going to add some additional information to the test > instructions to clarify when and how they should be used. > > > If you execute "copyq tests", not all finish successfully. > > Try running them from your desktop environment after you have installed > the package. You should see them running, it is a bit entertaining to > watch. Get a cup of coffee though, it takes some time. > Is copyq designed for a specific Desktop Environment?
(In reply to Gerald Cox from comment #41) > > > > > - copyq does not work for me. > That is strange, I have run it on two separate machines with no problem. > This probably would be an instance where you would want to run the tests > (from your desktop environment) and report the results. > > You're right. Probably i'm not able to use copyq. To run a window: $ copyq (server) $ copyq toggle
Antonio, I think I missed something big here. When you mentioned you couldn't run copyq that set off some alarm bells... Requires: qt, qtwebkit, libXtst, libXfixes That is a big embarrassing oops... I was so fixated on the build, I forgot the runtime - and didn't notice because I am running kde. Please try copyq again after this new build. If it isn't working for you I would like to understand why. Revised file location... Spec URL: https://gbcox.fedorapeople.org/specs/copyq.spec SRPM URL: https://repos.fedorapeople.org/repos/gbcox/forefront/fedora-21/SRPMS/copyq-2.4.6-3.fc21.src.rpm
(In reply to Gerald Cox from comment #44) > Antonio, I think I missed something big here. When you mentioned you > couldn't run copyq that set off some alarm bells... > > Requires: qt, qtwebkit, libXtst, libXfixes These package are automatically required when user installs the package. http://fedoraproject.org/wiki/Packaging:Guidelines#Requires http://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires I have not executed copyq correctly. https://bugzilla.redhat.com/show_bug.cgi?id=1211831#c43
(In reply to Gerald Cox from comment #41) > > > > - Have you looked why some tests fail ? > The tests all run fine for me. http://goo.gl/dHoKlS > Remember, these tests are not intended for packaging, and > require quite a bit of time to run - depending on your > machine up to 15 minutes. I did have a conversation with the > developer because I was a bit concerned that turning them on may impact > normal performance. That doesn't appear to be the case, however depending > on when and how they are used could cause some confusion to the end user. > The developer is going to add some additional information to the test > instructions to clarify when and how they should be used. > > > If you execute "copyq tests", not all finish successfully. > > Try running them from your desktop environment after you have installed > the package. You should see them running, it is a bit entertaining to > watch. Get a cup of coffee though, it takes some time. > I wish know why tests fail on my Fedora 21 Gnome: see http://fpaste.org/215458/97406714/
(In reply to Antonio Trande from comment #45) > (In reply to Gerald Cox from comment #44) > > Antonio, I think I missed something big here. When you mentioned you > > couldn't run copyq that set off some alarm bells... > > > > Requires: qt, qtwebkit, libXtst, libXfixes > > These package are automatically required when user installs the package. > http://fedoraproject.org/wiki/Packaging:Guidelines#Requires > http://fedoraproject.org/wiki/Packaging:Guidelines#Explicit_Requires Yes, but libXfixes was missing... :-( I've fixed the explicit requires and included libXfixes-devel... we should be good now on the dependencies... Revised file location... Spec URL: https://gbcox.fedorapeople.org/specs/copyq.spec SRPM URL: https://repos.fedorapeople.org/repos/gbcox/forefront/fedora-21/SRPMS/copyq-2.4.6-4.fc21.src.rpm I have gnome installed, so I will also test and let you know what I find.
Antonio, I tested under gnome and the tests fail for me also. Looks like an incompatibility with the desktop, so appears you need a kde or lxqt environment to run. Not sure if it would work with kwin under gnome, if that is even possible. That said, let me know if there are any other issues. Thanks again for all your help with this. I really appreciate it.
(In reply to Gerald Cox from comment #48) > Antonio, > > I tested under gnome and the tests fail for me also. Looks like an > incompatibility with the desktop, so appears you need a kde or lxqt > environment to run. Not sure if it would work with kwin under gnome, if > that is even possible. > > That said, let me know if there are any other issues. Thanks again for all > your help with this. I really appreciate it. How this issue can influence user experience with copyq on Gnome? If it's not a great problem, this review can be closed positively but it's better to open a bug report where point out what is the current problem of copyq on Gnome.
(In reply to Antonio Trande from comment #49) > (In reply to Gerald Cox from comment #48) > > Antonio, > How this issue can influence user experience with copyq on Gnome? Under normal operation I don't think it will be an issue. The vast majority of the tests passed... when there was a failure a pop-up displayed "Tab name must be non-empty and unique" - under normal operation if you did this, you would follow the prompt instruction. It's more than likely a quirk in qtest, but doesn't appear serious at all. > If it's not a great problem, this review can be closed positively but it's > better to open a bug report where point out what is the current problem of > copyq on Gnome. I'll discuss the behavior of the tests running under gnome with the developer and do a bug report when I can narrow down the correct component. It may be qtest and not anything to do with copyq. It doesn't appear to be a great issue and affects a few tests. Remember also the developer is going to revise his testing doc to indicate proper usage. Thanks again I appreciate all your assistance. Michael Schwendt - thank you also for taking the time to comment. I appreciate your input!
(In reply to Gerald Cox from comment #50) > (In reply to Antonio Trande from comment #49) > > (In reply to Gerald Cox from comment #48) > > > Antonio, > > > How this issue can influence user experience with copyq on Gnome? > Under normal operation I don't think it will be an issue. The vast majority > of the tests passed... when there was a failure a pop-up displayed "Tab name > must be non-empty and unique" - under normal operation if you did this, you > would follow the prompt instruction. It's more than likely a quirk in > qtest, but doesn't appear serious at all. > > > If it's not a great problem, this review can be closed positively but it's > > better to open a bug report where point out what is the current problem of > > copyq on Gnome. > I'll discuss the behavior of the tests running under gnome with the > developer and do a bug report when I can narrow down the correct component. > It may be qtest and not anything to do with copyq. It doesn't appear to be a > great issue and affects a few tests. Remember also the developer is going > to revise his testing doc to indicate proper usage. > Package approved. Please, open a RedHat bugzilla report to point out to all Fedora users this issue with a reference to the bug report on upstream ticket system.
New Package SCM Request ======================= Package Name: copyq Short Description: CopyQ is advanced clipboard manager with searchable and editable history with support for image formats, command line control and more. Upstream URL: http://sourceforge.net/projects/copyq/ Owners: gbcox Branches: f21 f22 InitialCC:
If the above description is too long, use this one. New Package SCM Request ======================= Package Name: copyq Short Description: copyq - Advanced Qt based clipboard manager Upstream URL: http://sourceforge.net/projects/copyq/ Owners: gbcox Branches: f21 f22 InitialCC:
Git done (by process-git-requests).
Built for F22, F21 and RAWHIDE. Closing.
copyq-2.4.6-4.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/copyq-2.4.6-4.fc22
copyq-2.4.6-4.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/copyq-2.4.6-4.fc21
copyq-2.4.6-5.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/copyq-2.4.6-5.fc21
copyq-2.4.6-4.fc22 has been pushed to the Fedora 22 stable repository.
copyq-2.4.6-5.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.