Dear all, my name is Sébastien Le Roux and I am computational material scientist. I write this message to request a review for my first package, Atomes, and therefore I need a sponsor. Atomes is a Free (Open Source) cross-platform toolbox developed to analyze, to visualize and to create/edit three-dimensional atomistic models. More about Atomes here: https://atomes.ipcms.fr/ [EDIT] To correct the use of RPM fusion lib in the source rpm: Spec URL: https://github.com/Slookeur/Atomes-GNU/raw/main/atomes.spec SRPM URL: https://github.com/Slookeur/Atomes-rpm-build/raw/main/atomes-1.1.11-8.fc36.src.rpm Latest successful Koji build : https://koji.fedoraproject.org/koji/taskinfo?taskID=99588553 [/EDIT] Description: Atomes: a toolbox to analyze, to visualize and to edit/create three-dimensional atomistic models. It offers a workspace that allows to have many projects opened simultaneously. The different projects in the workspace can exchange data: analysis results, atomic coordinates ... Atomes also provides an advanced input preparation system for further calculations using well known molecular dynamics codes: Classical MD : DLPOLY and LAMMPS ab-initio MD : CPMD and CP2K QM-MM MD : CPMD and CP2K To prepare the input files for these calculations is likely to be the key, and most complicated step towards MD simulations. Atomes offers a user-friendly assistant to help and guide the scientist step by step to achieve this crucial step. Fedora Account System Username: slook I am extremely motivated and willing to work to packaged and maintain Atomes for the Fedora community. I have been using Fedora since FC2. Best regards. Sébastien Le Roux
Sébastien, it's worth to check the 'fedora-rawhide-x86_64' and uncheck the other chroots under '2. Build options' and check 'Run fedora-review tool for packages in this project' check-box under '3. Other options' at project settings page [0] and rebuild the project, so the reviewer would have review template at hands. Also, there are built packages at copr site for each build which you can find by opening a chroot link at the bottom left of a build details page, so you could minimise download/upload work. Regards, Sergey [0] https://copr.fedorainfracloud.org/coprs/slook/Atomes/edit/
Current package does not compile under Fedora's ffmpeg. The header included has to be ffmpeg-free-devel, but it tries to install ffmpeg-devel. That is provided only on rpmfusion.org and would not work on Fedora. Please modify the spec to build on 'fedpkg --release rawhide mockbuild' command.
tail of my mockbuild attempt: Wrote: /builddir/build/SRPMS/atomes-1.1.5-1.src.rpm No matches found for the following disable plugin patterns: local, spacewalk, versionlock fedora 17 kB/s | 7.4 kB 00:00 No matching package to install: 'ffmpeg-devel' Not all dependencies satisfied Error: Some packages could not be found. Finish: build setup for atomes-1.1.5-1.src.rpm Finish: build phase for atomes-1.1.5-1.src.rpm ERROR: Exception(/home/pemensik/fedora/rawhide/2130607-atomes-fedora/srpm-unpacked/atomes-1.1.5-1.src.rpm) Config(fedora-rawhide-x86_64) 0 minutes 18 seconds INFO: Results and/or logs in: /home/pemensik/fedora/rawhide/2130607-atomes-fedora/srpm-unpacked/results_atomes/1.1.5/1 INFO: Cleaning up build root ('cleanup_on_failure=True') Start: clean chroot Finish: clean chroot ERROR: Command failed: # /usr/bin/systemd-nspawn -q -M 3a3c03db9ee04429865a7aa2de4df042 -D /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root -a --capability=cap_ipc_lock --bind=/tmp/mock-resolv.5wsn7cs2:/etc/resolv.conf --console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/var/lib/mock/fedora-rawhide-x86_64/root/installation-homedir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007" --setenv=PS1=<mock-chroot> \s-\v\$ --setenv=LANG=C.UTF-8 --setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/dnf builddep --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 38 --setopt=deltarpm=False --allowerasing --disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock --disableplugin=local --disableplugin=spacewalk --disableplugin=versionlock /var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/atomes-1.1.5-1.src.rpm --setopt=tsflags=nocontexts No matches found for the following disable plugin patterns: local, spacewalk, versionlock fedora 17 kB/s | 7.4 kB 00:00 No matching package to install: 'ffmpeg-devel' Not all dependencies satisfied Error: Some packages could not be found. Indeed last ffmpeg fedora build does not provide them: https://koji.fedoraproject.org/koji/buildinfo?buildID=2057470
Before everything thanks for all the work, I think to give the link to the package from Github was a terrible idea, I indeed build it using ffmpeg, now the one on Copr here does not use ffmpeg but the free lib: https://copr.fedorainfracloud.org/coprs/slook/Atomes/ If you install one of the repo there you will find an acceptable source rpm. In the mean time I will update the source rpm from the github repo. Please let me know if this helps. Best.
I just correct the git repo with the source RPM, please check it out, you will find now the proper data for the Fedora build in: https://github.com/Slookeur/Atomes-rpm-build/tree/main/Fedora Including the proper spec file and the proper src.rpm for Fedora
(In reply to Sergey from comment #1) > Sébastien, > > it's worth to check the 'fedora-rawhide-x86_64' and uncheck the other > chroots under '2. Build options' and check 'Run fedora-review tool for > packages in this project' check-box under '3. Other options' at project > settings page [0] > and rebuild the project, so the reviewer would have review template at > hands. > > Also, there are built packages at copr site for each build which you can > find by opening a chroot link at the bottom left of a build details page, so > you could minimise download/upload work. > > Regards, > Sergey > > [0] https://copr.fedorainfracloud.org/coprs/slook/Atomes/edit/ I followed your advises, and setup the copr repo so that I could run the fedora-review tool. I will work on the output to improve my RPM, not sure I can do much without help, you give a look to one of the review here: https://download.copr.fedorainfracloud.org/results/slook/Atomes/fedora-36-x86_64/04878251-atomes/fedora-review/review.txt
(In reply to Sébastien Le Roux from comment #6) > (In reply to Sergey from comment #1) > I followed your advises, and setup the copr repo so that I could run the > fedora-review tool. > I will work on the output to improve my RPM, not sure I can do much without > help, > you give a look to one of the review here: > > https://download.copr.fedorainfracloud.org/results/slook/Atomes/fedora-36- > x86_64/04878251-atomes/fedora-review/review.txt Sébastien, I am quite new to this package review process as well, I just have got the small experience already. I have submitted a few packages for review, but there are no big progress for some reason, unfortunately. I would recommend you to look into the review template for all points marked with exclamation mark `[!]` - these are failed checks. Fortunately, they all are in the `SHOULD` section, so basically your rpm is OK, but these checks are also points to improve. Lets take a look: [!]: Reviewer should test that the package builds in mock. disregard this one: this is a task for an actual reviewer. However, you could check that your package builds in mock. To be precise I first build a package with rpmbuild, until I get no errors. Then under mock, again until I get no errors, and then on copr site: its much faster to build a package locally at least in my case. [!]: Buildroot is not present Note: Invalid buildroot found: %{_tmppath}/%{name}-%{version}-build See: https://docs.fedoraproject.org/en-US/packaging-guidelines/ This one is bad: you must use only directories listed here [0] Actually it comes from `BuildRoot:` tag, which should not be used in Fedora's spec files AFAIK, so just remove the line. [!]: Uses parallel make %{?_smp_mflags} macro. It's worth to enable parallel make so the build system could use all (configured) cores and speed up the process. just add `%{?_smp_mflags}` to the make invocation in the %build phase: make `%{?_smp_mflags}` Also, there is an rpmlint tool that checks rpm's structure. Unfortunately, at copr it is broken for some reason (at least not always works) but you could install this tool and check resulting rpms yourself: pmlint atomes-1.1.5-1.fc38.src.rpm =========================================================================================================== rpmlint session starts rpmlint: 2.2.0 configuration: /usr/lib/python3.10/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-legacy-licenses.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/licenses.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml checks: 32, packages: 1 atomes.spec:40: W: unversioned-explicit-provides %{name}-%{version} atomes.src: E: unknown-key 268fd208 ============================================================================ 1 packages and 0 specfiles checked; 1 errors, 1 warnings, 1 badness; has taken 0.2 s and for binary rpm: pmlint atomes-1.1.5-1.fc38.x86_64.rpm ============================================ rpmlint session starts ========================================= rpmlint: 2.2.0 configuration: /usr/lib/python3.10/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-legacy-licenses.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/licenses.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml checks: 32, packages: 1 atomes.x86_64: E: unknown-key 268fd208 atomes.x86_64: W: incoherent-version-in-changelog 1.1.5 ['1.1.5-1.fc38', '1.1.5-1'] atomes.x86_64: E: explicit-lib-dependency libavcodec-free atomes.x86_64: E: explicit-lib-dependency libavformat-free atomes.x86_64: E: explicit-lib-dependency libavutil-free atomes.x86_64: E: explicit-lib-dependency libepoxy atomes.x86_64: E: explicit-lib-dependency libgfortran atomes.x86_64: E: explicit-lib-dependency libswscale-free atomes.x86_64: E: explicit-lib-dependency libxml2 Generally there should be no W: and E: messages. For the former rpm, you should not use this explicit Provides. For the latter you must not use explicit Requires on libraries: build system will check all actual dependencies of installed binary files and adjust the Requirements of a resulting package. And study the guidelines, should questions arise :) [1] Regards, Sergey. [0] https://docs.fedoraproject.org/en-US/packaging-guidelines/RPMMacros/ [1] https://docs.fedoraproject.org/en-US/packaging-guidelines
Hello Sébastien, I have submitted a PR to your github repo with some obvious changes to the spec file, there remain a few issues that need to be worked out and I think we might be also dealing with a couple of non-issues, I will ask about them on devel.
I'm taking the review, I will work on it asap.
Hello, thanks for doing the job Alexander, and please no need to rush ;-) Also I can help along the process, that is an opportunity to improve myself to help others later on, so please let me know what I can do to assist you. Latest build on Copr available here: https://copr.fedorainfracloud.org/coprs/slook/Atomes/ The build was performed using: https://github.com/Slookeur/Atomes-rpm-build/raw/main/Fedora/atomes.spec Latest build review from Copr: https://download.copr.fedorainfracloud.org/results/slook/Atomes/fedora-rawhide-x86_64/04910938-atomes/fedora-review/review.txt Latest rpmlint output from the Copr builts: source rpm: ====================================================================== rpmlint session starts ===================================================================== rpmlint: 2.2.0 ... atomes.src: E: unknown-key 268fd208 atomes.spec:63: W: macro-in-comment %{gpgverify} atomes.spec:63: W: macro-in-comment %{SOURCE2} atomes.spec:63: W: macro-in-comment %{SOURCE1} atomes.spec:63: W: macro-in-comment %{SOURCE0} ======================================= 1 packages and 0 specfiles checked; 1 errors, 4 warnings, 1 badness; has taken 0.1 s ====================================== x86_64 rpm: ====================================================================== rpmlint session starts ===================================================================== rpmlint: 2.2.0 ... atomes.x86_64: E: unknown-key 268fd208 ======================================= 1 packages and 0 specfiles checked; 1 errors, 0 warnings, 1 badness; has taken 0.2 s ====================================== Seems pretty clean, although I have no idea what this "unknown-key " thing is ... yet ;-)
Here goes: Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated Issues: ======= - Package installs a %{name}.desktop using desktop-file-install or desktop- file-validate if there is such a file. * Add the following %check section to your spec file between the %install and %files sections: %check desktop-file-validate %{buildroot}/%{_datadir}/applications/%{name}.desktop If in the future you may want to run any tests, this is the place to add them. Also, since atomes is a graphical desktop application, we should add an AppStream metadata XML file, so that it gets picked up by software-center-type graphical installers, take a look at https://www.freedesktop.org/software/appstream/docs/ - Sources used to build the package match the upstream source, as provided in the spec URL. Note: Upstream MD5sum check error, diff is in /home/user/reviews/2130607-atomes/diff.txt See: https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/ To simplify things, tag a 1.1.6 release in the upstream repository (which I suppose is https://github.com/Slookeur/Atomes) and use that as your source tarball, i.e.: Source0: https://github.com/Slookeur/Atomes/archive/refs/tags/v%{version}.tar.gz Upstream you are using the name Atomes (with a capital "A"), so if you happen to add it to the tarball name, you can define a global variable in the beginning of the spec file, e.g. upname, to refer to that and not worry about uppercase and lowercase letters: %global upname Atomes You could then change the source URL to: Source0: https://github.com/Slookeur/%{upname}/archive/refs/tags/v%{version}.tar.gz Remember that when you are wearing your upstream developer hat, you are free to change whatever version number you feel like and you know nothing about Fedora's release number. With your packager hat on, you can only increment the release number, you can't change whatever number your developer self has used for the version. Try to manage the ensuing schizophrenia… ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: If your application is a C or C++ application you must list a BuildRequires against gcc, gcc-c++ or clang. [x]: Header files in -devel subpackage, if present. [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. [!]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "GNU Affero General Public License v3.0", "FSF All Permissive License", "[generated file]", "*No copyright* GNU Affero General Public License", "FSF Unlimited License (with License Retention) GNU General Public License v2.0 or later [generated file]", "*No copyright* GNU Affero General Public License v3.0 or later", "GNU General Public License v2.0 or later [generated file]", "GNU General Public License v3.0 or later", "FSF Unlimited License [generated file]", "X11 License [generated file]", "*No copyright* [generated file]", "GNU Affero General Public License v3.0 or later". 702 files have unknown license. Detailed output of licensecheck in /home/user/reviews/2130607-atomes/licensecheck.txt As far as I can tell, the files with licenses other than Affero are only used during compilation and they are not part of the binary package, so everything is good there. However, the license mentioned in "COPYING" is "GNU Affero General Public License v3.0" (AGPLv3), whereas in src/affero.h you have "GNU Affero General Public License v3.0 or later" (AGPLv3+). If it's an oversight, change the one that is wrong, otherwise the effective license becomes the more restrictive one. [x]: License file installed when any subpackage combination is installed. [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. *** remember to tag the 1.1.6 release (or whatever subsequent number you decide) [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). *** You can replace any instance of "atomes" with "%{name}" for the added fun [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]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 20480 bytes in 3 files. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. *** As part of the review process, you should have provided a link to a successful scratch build in koji. COPR is fine and all, but it's not the "official" build system. Here's one for you: https://koji.fedoraproject.org/koji/taskinfo?taskID=92962219 [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: 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 %license. [x]: Package requires other packages for directories it uses. [x]: Package must own all directories that it creates. [x]: Package does not own files or directories owned by other packages. [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]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package must not depend on deprecated() packages. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local ===== 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. [-]: Final provides and requires are sane (see attachments). [x]: Package functions as described. *** I need to RTFM and I had only an .xyz file with a graphene sheet with 1500 atoms at hand, but I'd say it does. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify occurs outside of %prep. [x]: Package should compile and build into binary rpms on all supported architectures. [!]: %check is present and all tests pass. *** See the note above about desktop-file-validate. Once we prepare the AppStream metadata file, you'll also need to add a check for that as well. [-]: Packages should try to preserve timestamps of original installed files. [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]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Fully versioned dependency in subpackages if applicable. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Uses parallel make %{?_smp_mflags} macro. [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [!]: Spec file according to URL is the same as in SRPM. Note: Spec file as given by url is not the same as in SRPM (see attached diff). See: (this test has no URL) [-]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Arch-ed rpms have a total of 7710720 bytes in /usr/share [x]: Rpmlint is run on debuginfo package(s). Note: There are rpmlint messages (see attachment). [x]: Rpmlint is run on all installed packages. Note: No rpmlint messages. [x]: Package should not use obsolete m4 macros Rpmlint ------- Cannot parse rpmlint output: Rpmlint (debuginfo) ------------------- Cannot parse rpmlint output: *** When running rpmlint locally, I get this: atomes-debuginfo.x86_64: W: unstripped-binary-or-object /usr/lib/debug/usr/bin/atomes-1.1.6-1.fc38.x86_64.debug atomes-debuginfo.x86_64: E: shared-library-without-dependency-information /usr/lib/debug/usr/bin/atomes-1.1.6-1.fc38.x86_64.debug atomes-debuginfo.x86_64: W: no-documentation atomes-debugsource.x86_64: W: no-documentation atomes.spec:63: W: macro-in-comment %{gpgverify} atomes.spec:63: W: macro-in-comment %{SOURCE2} atomes.spec:63: W: macro-in-comment %{SOURCE1} atomes.spec:63: W: macro-in-comment %{SOURCE0} atomes.spec: W: invalid-url Source1: ./atomes-1.1.6.tar.gz.asc atomes.spec: W: invalid-url Source0: ./atomes-1.1.6.tar.gz atomes-debuginfo.x86_64: W: dangling-relative-symlink /usr/lib/debug/.build-id/63/87711d22856dbdedd43a6fa85603b1e6bae1ab ../../../.build-id/63/87711d22856dbdedd43a6fa85603b1e6bae1ab I'm not really sure about the debuginfo warnings and error and I've seen them in other packages, maybe it's worth asking on devel about them. As for the "macro-in-comment" warnings, when you want to comment out a line that contains a macro, you need to add an extra percent sign to comment out the existing ones, i.e. your %prep line should be changed to this: %prep # %%{gpgverify} --keyring='%%{SOURCE2}' --signature='%%{SOURCE1}' --data='%%{SOURCE0}' Rpmlint (installed packages) ---------------------------- ============================ rpmlint session starts ============================ rpmlint: 2.4.0 configuration: /usr/lib/python3.11/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-legacy-licenses.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml checks: 31, packages: 3 3 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 badness; has taken 1.2 s Source checksums ---------------- https://github.com/Slookeur/Atomes-rpm-build/raw/main/atomes.gpg : CHECKSUM(SHA256) this package : 5e5e75c29719f5f32ca9e688cbc3df56606300ed0833525f47b2665e8ae1f8bb CHECKSUM(SHA256) upstream package : 5e5e75c29719f5f32ca9e688cbc3df56606300ed0833525f47b2665e8ae1f8bb https://github.com/Slookeur/Atomes-rpm-build/raw/main/atomes-1.1.6.tar.gz.asc : CHECKSUM(SHA256) this package : 48e97ef5e4afd3e2a836bf0a070cf91fd7743273f29f5200120ba2727a201549 CHECKSUM(SHA256) upstream package : 3bb3a2e2a070ae403a130cd777eef3911cc8f85e6e74c6ad98f09243eef3e594 https://github.com/Slookeur/Atomes-rpm-build/raw/main/atomes-1.1.6.tar.gz : CHECKSUM(SHA256) this package : e426d08db21b20f9b3bb07e3df9b52d1e407615ff9ae1def453a1b90469e701b CHECKSUM(SHA256) upstream package : e426d08db21b20f9b3bb07e3df9b52d1e407615ff9ae1def453a1b90469e701b diff -r also reports differences Requires -------- atomes (rpmlib, GLIBC filtered): bash-completion desktop-file-utils freeglut gtk3 libavcodec.so.59()(64bit) libavcodec.so.59(LIBAVCODEC_59)(64bit) libavformat.so.59()(64bit) libavformat.so.59(LIBAVFORMAT_59)(64bit) libavutil.so.57()(64bit) libavutil.so.57(LIBAVUTIL_57)(64bit) libc.so.6()(64bit) libcairo.so.2()(64bit) libepoxy.so.0()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgcc_s.so.1(GCC_4.0.0)(64bit) libgdk-3.so.0()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libgfortran.so.5()(64bit) libgfortran.so.5(GFORTRAN_10)(64bit) libgfortran.so.5(GFORTRAN_8)(64bit) libgio-2.0.so.0()(64bit) libglib-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libgomp.so.1()(64bit) libgomp.so.1(GOMP_1.0)(64bit) libgomp.so.1(GOMP_4.0)(64bit) libgomp.so.1(OMP_1.0)(64bit) libgtk-3.so.0()(64bit) libm.so.6()(64bit) libpango-1.0.so.0()(64bit) libpangocairo-1.0.so.0()(64bit) libpangoft2-1.0.so.0()(64bit) libswscale.so.6()(64bit) libswscale.so.6(LIBSWSCALE_6)(64bit) libxml2.so.2()(64bit) libxml2.so.2(LIBXML2_2.4.30)(64bit) libxml2.so.2(LIBXML2_2.6.0)(64bit) libxml2.so.2(LIBXML2_2.6.5)(64bit) mesa-libGLU rtld(GNU_HASH) atomes-debuginfo (rpmlib, GLIBC filtered): atomes-debugsource (rpmlib, GLIBC filtered): Provides -------- atomes: application() application(atomes.desktop) atomes atomes(x86-64) mimehandler(application/x-extension-apf) mimehandler(application/x-extension-awf) atomes-debuginfo: atomes-debuginfo atomes-debuginfo(x86-64) debuginfo(build-id) atomes-debugsource: atomes-debugsource atomes-debugsource(x86-64) Diff spec file in url and in SRPM --------------------------------- --- /home/user/reviews/2130607-atomes/srpm/atomes.spec 2022-10-12 21:34:42.309784359 +0200 +++ /home/user/reviews/2130607-atomes/srpm-unpacked/atomes.spec 2022-10-12 17:40:53.000000000 +0200 @@ -4,7 +4,7 @@ Summary: An atomistic toolbox License: AGPLv3+ -Source0: https://github.com/Slookeur/Atomes-rpm-build/raw/main/%{name}-%{version}.tar.gz -Source1: https://github.com/Slookeur/Atomes-rpm-build/raw/main/%{name}-%{version}.tar.gz.asc -Source2: https://github.com/Slookeur/Atomes-rpm-build/raw/main/atomes.gpg +Source0: ./%{name}-%{version}.tar.gz +Source1: ./%{name}-%{version}.tar.gz.asc +Source2: atomes.gpg URL: https://atomes.ipcms.fr/ Generated by fedora-review 0.9.0 (6761b6c) last change: 2022-08-23 Command line :/usr/bin/fedora-review -b 2130607 -v Buildroot used: fedora-rawhide-x86_64 Active plugins: Generic, C/C++, Shell-api Disabled plugins: R, Java, Perl, Haskell, fonts, Ocaml, SugarActivity, PHP, Python Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH Try to address the issues marked with "!" on the checklist and my comments, we're getting there!
P.S.: I corrected your link to the source rpm (the .fc36 was missing) because fedora-review was complaining and I was too lazy to fetch the file and run it locally :P
Another thing I forgot, we are moving to SPDX license identifiers (starting with F38 I think) and support for them has been backported to current stable releases, so you can use "AGPL-3.0-only" or "AGPL-3.0-or-later" in the License tag.
(In reply to Alexander Ploumistos from comment #11) First of all, thank you so much ! Ok, so I followed your comments/advises, here are my replies/questions: > * Add the following %check section to your spec file between the %install > and %files sections: > > %check > desktop-file-validate %{buildroot}/%{_datadir}/applications/%{name}.desktop Done ! > Also, since atomes is a graphical desktop application, we should add an > AppStream metadata XML file, so that it gets picked up by > software-center-type graphical installers, take a look at > https://www.freedesktop.org/software/appstream/docs/ Will do ASAP > To simplify things, tag a 1.1.6 release in the upstream repository (which I > suppose is https://github.com/Slookeur/Atomes) and use that as your source > tarball, i.e.: > Source0: > https://github.com/Slookeur/Atomes/archive/refs/tags/v%{version}.tar.gz Ok so here I do have some questions, if I tag a release, then I noticed that everything inside the repo is packaged into a single acrive, but the repo contains other stuff that only Fedora RPMs data, not only that but it seems to me that to work this method would require the repo to host the files of the GNU tarball, so that when I create a release it will create the tarball required to build the RPM ... Is the tag a mandatory requirement ? If that is true, then should I create another repo / change this one so that it behave as I mentioned ? Then the following should work (sure it does not for the time being): > You could then change the source URL to: > Source0: > https://github.com/Slookeur/%{upname}/archive/refs/tags/v%{version}.tar.gz > [!]: License field in the package spec file matches the actual license. Asked for the CNRS advise about this, will correct ASAP Will also correct the licence tag thanks to your last comment. > *** remember to tag the 1.1.6 release (or whatever subsequent number you decide) Back to my previous question, is it mandatory ? > *** You can replace any instance of "atomes" with "%{name}" for the added fun I actually did ;-) > *** As part of the review process, you should have provided a link to a > successful scratch build in koji. COPR is fine and all, but it's not the > "official" build system. Here's one for you: > https://koji.fedoraproject.org/koji/taskinfo?taskID=92962219 Ok, to be honest this is likely related to my email about the doc yesterday, I do not really understand what koji is, or even what is a build in Koji, it mentioned yet not explain or a least no clearly enough for newbie to understand. I am discovering the website with your link, but I am not listed as a user there, not sure I can access it ... sorry but could you help me figure out how to provide this famous build with Koji ... I sure need to learn that ;-) > *** See the note above about desktop-file-validate. Once we prepare the > AppStream metadata file, you'll also need to add a check for that as well. > Sure > Generic: > [!]: Spec file according to URL is the same as in SRPM. > Note: Spec file as given by url is not the same as in SRPM (see > attached diff). I guess this is related to your Koji (local) build, is it ? > > *** When running rpmlint locally, I get this: > > atomes-debuginfo.x86_64: W: unstripped-binary-or-object > /usr/lib/debug/usr/bin/atomes-1.1.6-1.fc38.x86_64.debug > atomes-debuginfo.x86_64: E: shared-library-without-dependency-information > /usr/lib/debug/usr/bin/atomes-1.1.6-1.fc38.x86_64.debug > atomes-debuginfo.x86_64: W: no-documentation > atomes-debugsource.x86_64: W: no-documentation > atomes.spec:63: W: macro-in-comment %{gpgverify} > atomes.spec:63: W: macro-in-comment %{SOURCE2} > atomes.spec:63: W: macro-in-comment %{SOURCE1} > atomes.spec:63: W: macro-in-comment %{SOURCE0} > atomes.spec: W: invalid-url Source1: ./atomes-1.1.6.tar.gz.asc > atomes.spec: W: invalid-url Source0: ./atomes-1.1.6.tar.gz > atomes-debuginfo.x86_64: W: dangling-relative-symlink > /usr/lib/debug/.build-id/63/87711d22856dbdedd43a6fa85603b1e6bae1ab > ../../../.build-id/63/87711d22856dbdedd43a6fa85603b1e6bae1ab I will try to find some info about the debuginfo warnings > I'm not really sure about the debuginfo warnings and error and I've seen > them in other packages, maybe it's worth asking on devel about them. As for > the "macro-in-comment" warnings, when you want to comment out a line that > contains a macro, you need to add an extra percent sign to comment out the > existing ones, i.e. your %prep line should be changed to this: > %prep > # %%{gpgverify} --keyring='%%{SOURCE2}' --signature='%%{SOURCE1}' > --data='%%{SOURCE0}' Done
(In reply to Sébastien Le Roux from comment #14) > (In reply to Alexander Ploumistos from comment #11) > > Ok so here I do have some questions, if I tag a release, then I noticed > that everything inside the repo is packaged into a single acrive, but the > repo contains > other stuff that only Fedora RPMs data, not only that but it seems to me > that to work > this method would require the repo to host the files of the GNU tarball, > so that when I create a release it will create the tarball required to build > the RPM ... > > Is the tag a mandatory requirement ? > If that is true, then should I create another repo / change this one so that > it behave as I mentioned ? The basic idea is to have a single place where one can find the sources that correspond to a specific release. You don't have to use github or any other version control system, the source tarballs could just as well be hosted on the website of Atomes. The problem that rpmlint pointed out was that the source tarball in the srpm was not the one that it found upstream. That should never happen and it raises red flags. There are also automated systems that rely on that piece of information (the source URL), for instance koschei, our CI system: https://koschei.fedoraproject.org/ Anitya monitors project pages for new versions and notifies downstream package maintainers whenever there is a new release: https://release-monitoring.org/ This is not Fedora-specific, if someone decided to package Atomes e.g. for Gentoo or OpenMandriva, they could get their information from there. Perhaps if you look at the ways Anitya figures out that there is a new version, you might get some ideas about how to organize your releases in a way that is convenient for you. In my opinion, you are unnecessarily complicating your life with all the different repositories you've set up. Why not keep everything in one place and add OS-specific logic in your setup scripts? These are a few projects whose packages I maintain in Fedora and which compile and run on different systems: https://github.com/hvennekate/Molsketch https://github.com/wojdyr/fityk https://github.com/SciDAVis/scidavis/tree/master/scidavis https://framagit.org/razer/bubblemail (not cross-platform, but provides packages for different distros) When you have some time to spare, you can see how they deal with OS-specific files and packaging. You can also see what information Anitya uses for each of them. > > *** As part of the review process, you should have provided a link to a > > successful scratch build in koji. COPR is fine and all, but it's not the > > "official" build system. Here's one for you: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=92962219 > > Ok, to be honest this is likely related to my email about the doc yesterday, > I do not really understand what koji is, > or even what is a build in Koji, it mentioned yet not explain or a least no > clearly enough for newbie to understand. > I am discovering the website with your link, but I am not listed as a user > there, not sure I can access it ... > sorry but could you help me figure out how to provide this famous build with > Koji ... I sure need to learn that ;-) I suppose you've set up the necessary packaging tools, of not look at https://docs.fedoraproject.org/en-US/package-maintainers/Installing_Packager_Tools/ . Even when you haven't been sponsored into the packager group, you can submit scratch builds to test that a package builds on all officially supported platforms: koji build --scratch rawhide Atomes-1.1.6.src.rpm Have you managed to discover this document yet? https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Build_System/ > > Generic: > > [!]: Spec file according to URL is the same as in SRPM. > > Note: Spec file as given by url is not the same as in SRPM (see > > attached diff). > > I guess this is related to your Koji (local) build, is it ? Nope, that's from the use of different source tarballs upstream and in the source rpm. Btw, you don't have to edit your first comment whenever you update the spec file and source rpm, you can just add a new comment with the new URLs, fedora-review has the logic to pick up the latest version. Also, even though Atomes has not been included in Fedora yet, there is no problem if the first version has a non-one release number, e.g. 1.1.6-12. If it helps you keep track of your files and changes, you can start picking up the habit of incrementing the release number.
(In reply to Alexander Ploumistos from comment #15) > > The basic idea is to have a single place where one can find the sources that > ... > convenient for you. > Thank you, yes, I understand. > In my opinion, you are unnecessarily complicating your life with all the > different repositories you've set up. Why not keep everything in one place > and add OS-specific logic in your setup scripts? You are absolutely right about this, but there is a reason behind all this, in the main repo, I use a custom Makefile, that I use with codeblocks to code/write Atomes, I wasn't/am not sure that a GNU Makefile could work with codeblocks, it easier and cleaner for me to have both at least for the time being, I will take the time to think about it before deciding on the best way to proceed ;-) ... likely to update the main repo with the content of the GNU tarball ... > These are a few projects whose packages I maintain in Fedora and which > compile and run on different systems: > https://github.com/hvennekate/Molsketch > https://github.com/wojdyr/fityk > https://github.com/SciDAVis/scidavis/tree/master/scidavis > https://framagit.org/razer/bubblemail (not cross-platform, but provides > packages for different distros) > > When you have some time to spare, you can see how they deal with OS-specific > files and packaging. You can also see what information Anitya uses for each > of them. I will ! > > > > *** As part of the review process, you should have provided a link to a > > > successful scratch build in koji. COPR is fine and all, but it's not the > > > "official" build system. Here's one for you: > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=92962219 > > koji build --scratch rawhide Atomes-1.1.6.src.rpm > > Have you managed to discover this document yet? Oh I did, just mentioned it in the mailing list yesterday saying how unclear I think it is ;-) I will work on my Koji build ;-) > > > > I guess this is related to your Koji (local) build, is it ? > > Nope, that's from the use of different source tarballs upstream and in the > source rpm. > Ok thanks for clarifying it ! > Btw, you don't have to edit your first comment whenever you update the spec > file and source rpm, you can just add a new comment with the new URLs, > fedora-review has the logic to pick up the latest version. Also, even though > Atomes has not been included in Fedora yet, there is no problem if the first > version has a non-one release number, e.g. 1.1.6-12. If it helps you keep > track of your files and changes, you can start picking up the habit of > incrementing the release number. Will do ! Again thank you for your expertise, really appreciate your time and efforts, next beer(s) on me !
(In reply to Sébastien Le Roux from comment #14) > Ok so here I do have some questions, if I tag a release, then I noticed > that everything inside the repo is packaged into a single acrive, but the > repo contains > other stuff that only Fedora RPMs data, not only that but it seems to me > that to work > this method would require the repo to host the files of the GNU tarball, > so that when I create a release it will create the tarball required to build > the RPM ... A small comment about the split I mentioned earlier: As a developer who wants their program to build on linux, your responsibilities stop at providing a way for people to build the program on any random distribution. In the case of Atomes, there are only files that go under /usr/bin and /usr/share, which are pretty much standard locations on almost every distribution and that simplifies the life of a distro maintainer. So all you need to worry about is that after e.g. a ./configure make make install the program would compile successfully and the files would end up in reasonable places. As a package maintainer, your job is to tailor the package to the specifics of a/your distribution, i.e. make sure dependencies are satisfied, follow the distro's guidelines, use distro-specific tools and all that. Your developer self should do their development only in the Atomes repository and stop there. Your Fedora package maintainer self would then create the Atomes-rpm-build or Atomes-GNU repository in the distribution's dist-git (src.fedoraproject.org). Of course, all of the above is just a suggestion, you do whatever works for you.
Hello, so here is my first successful Kojji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=93011742 I had to rename the git repo in: https://github.com/Slookeur/atomes (also rename the 'Atomes' repo in 'Atomes-codeblocks' to keep my things clear) Builds were failing, and likely to fail in the future, when creating a release the archive were in the format specified in the spec file, but after extracting they were in a format unspecified in the spec file, if that is only possible, ex: %global upname Atomes-GNU Source0: https://github.com/Slookeur/%{upname}/archive/refs/tags/v%{version}.tar.gz Download archive: v1.1.7.tar.gz Extracted folder: Atomes-GNU-v1.1.7 And builders are looking for %{name}-${version} And I am not sure where to, if only it is possible, to correct it. And now the spec file looks like: Source0: https://github.com/Slookeur/%{name}/archive/refs/tags/v%{version}.tar.gz I will take some time to work on the doc, because this Koji build thing is so unclear by reading it ... it really did not help me to grasp the meaning behind all this ... now I am starting to understand ;-) Also correct the release number data, and will take car to increment this number in the future.
Hi Sébastien, (In reply to Sébastien Le Roux from comment #18) > Hello, > > so here is my first successful Kojji build: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=93011742 Well done! > I had to rename the git repo in: https://github.com/Slookeur/atomes > (also rename the 'Atomes' repo in 'Atomes-codeblocks' to keep my things > clear) > > Builds were failing, and likely to fail in the future, when creating a > release the archive were in the format > specified in the spec file, but after extracting they were in a format > unspecified in the spec file, > if that is only possible, ex: > > %global upname Atomes-GNU > Source0: > https://github.com/Slookeur/%{upname}/archive/refs/tags/v%{version}.tar.gz > > Download archive: v1.1.7.tar.gz > Extracted folder: Atomes-GNU-v1.1.7 > > And builders are looking for %{name}-${version} > And I am not sure where to, if only it is possible, to correct it. > And now the spec file looks like: > > Source0: > https://github.com/Slookeur/%{name}/archive/refs/tags/v%{version}.tar.gz I know it can be a bit tricky sometimes, but you don't need to rename your repo, you can tweak the %autosetup (or %setup) macro to work with whatever upstream has provided, e.g.: * tarball named v1.1.7.tar.gz: %autosetup -n v%{version} * tarball named Atomes-GNU-1.1.7.tar.gz: %autosetup -n %{upname}-%{version} * tarball named Atomes-GNU-ImBored-1.1.7.tar.gz %autosetup -n %{upname}-ImBored-%{version} > Also correct the release number data, and will take car to increment this > number in the future. There's a bit of a misunderstanding there. Like I wrote, the package maintainer increments the release number, but I failed to mention that you are supposed to do that for a given software version. Once a new version is packaged, you start again from 1, so your changelog entries would look (random example) like this: 12.7.1-1 12.6.5-3 12.6.5-2 12.6.5-1 … 12.5.9-24 12.5.9-23 … 11.0.8-1 11.0.7.15 11.0.7-14 etc. Does that help with the numbering scheme? Here you'll find the full documentation about versioning and it focuses a lot on the harder/weirder cases, so don't panic when you start scrolling!
(In reply to Alexander Ploumistos from comment #19) Hi Alex, again thank you so much for your insights, really helpful ;-) a> I know it can be a bit tricky sometimes, but you don't need to rename your > repo, you can tweak the %autosetup (or %setup) macro to work with whatever > upstream has provided, e.g.: > > * tarball named v1.1.7.tar.gz: > %autosetup -n v%{version} ok, TAA (I just came up with the TAA label for "Thanks Again Alex") so after reading this I went back to my first repo names. > There's a bit of a misunderstanding there. Like I wrote, the package > maintainer increments the release number, but I failed to mention that you > are supposed to do that for a given software version. Once a new version is > packaged, you start again from 1, so your changelog entries would look > (random example) like this: > > 12.7.1-1 > 12.6.5-3 > 12.6.5-2 > 12.6.5-1 > Does that help with the numbering scheme? TAA, Yes, this is much better, almost like I was completely wrong :-P So if I get this properly I would need a -2 or -3 if I change the RPM itself, ie. the spec file, or any other files associated with the program and delivered by the package, but not the program itself ? I will check the doc to improve my understanding ;-) In the mean time last successful Koji build, with proper numbering, and else: https://koji.fedoraproject.org/koji/taskinfo?taskID=93133666 TAA ;-) Seb
Latest spec file: https://github.com/Slookeur/Atomes-GNU/raw/main/atomes.spec
Hi Sébastien, You are very welcome. (In reply to Sébastien Le Roux from comment #20) > (In reply to Alexander Ploumistos from comment #19) > > TAA, Yes, this is much better, almost like I was completely wrong :-P > So if I get this properly I would need a -2 or -3 if I change the RPM > itself, ie. the spec file, > or any other files associated with the program and delivered by the package, > but not the program itself ? Exactly, as long as the software version in the tarball stays the same, you keep on incrementing the release number. Any rebuild for whatever reason (Fedora Mass Rebuilds, rebuilds against newer versions of dependencies, patches you may want to include, etc.), gets a higher release number. When you release version 1.1.8 upstream, the first package will go to 1.1.8-1. As a rule of thumb, whenever a build has been publicly released (including scratch builds, COPR builds, etc.), the next one should always get a higher (E)VR number (Epoch, Version, Release), to make sure that the package will get updated. For official packages, this is ensured by koji itself, it will not let you submit a build with identical or lower EVR. > > In the mean time last successful Koji build, with proper numbering, and else: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=93133666 See? You're getting the hang of it!
Just three small things left: Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [x]: If your application is a C or C++ application you must list a BuildRequires against gcc, gcc-c++ or clang. [x]: Header files in -devel subpackage, if present. [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. [x]: License file installed when any subpackage combination is installed. [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]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. [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]: 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 %license. [x]: Package requires other packages for directories it uses. [x]: Package must own all directories that it creates. [x]: Package does not own files or directories owned by other packages. [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]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package must not depend on deprecated() packages. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [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. [x]: Packages must not store files under /srv, /opt or /usr/local ===== 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). [x]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [?]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. *** You can remove the gpg key from the sources, since you are not using it. You can always add it back at a later time if you decide to use signature verification. [x]: Package should compile and build into binary rpms on all supported architectures. [x]: %check is present and all tests pass. *** The AppStream metadata file is missing, it should be installed into %{buildroot}%{_metainfodir}/ and then you should add this to your %check section: appstream-util validate-relax --nonet %{buildroot}%{_metainfodir}/*.metainfo.xml and a corresponding entry in %files. [-]: Packages should try to preserve timestamps of original installed files. [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]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Fully versioned dependency in subpackages if applicable. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Uses parallel make %{?_smp_mflags} macro. [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [!]: Spec file according to URL is the same as in SRPM. Note: Spec file as given by url is not the same as in SRPM (see attached diff). See: (this test has no URL) *** This must be fixed. [-]: Large data in /usr/share should live in a noarch subpackage if package is arched. Note: Arch-ed rpms have a total of 7710720 bytes in /usr/share [x]: Rpmlint is run on debuginfo package(s). Note: There are rpmlint messages (see attachment). [x]: Rpmlint is run on all installed packages. Note: No rpmlint messages. [x]: Package should not use obsolete m4 macros Rpmlint ------- Cannot parse rpmlint output: Rpmlint (debuginfo) ------------------- Cannot parse rpmlint output: Rpmlint (installed packages) ---------------------------- ============================ rpmlint session starts ============================ rpmlint: 2.4.0 configuration: /usr/lib/python3.11/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-legacy-licenses.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml checks: 31, packages: 3 3 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 badness; has taken 1.1 s Source checksums ---------------- https://github.com/Slookeur/Atomes-GNU/archive/refs/tags/v1.1.7.tar.gz : CHECKSUM(SHA256) this package : 75ae0a4b7ce7b25599de0a410f9892df97a6f91fb8301320f5b6920766767f7f CHECKSUM(SHA256) upstream package : 75ae0a4b7ce7b25599de0a410f9892df97a6f91fb8301320f5b6920766767f7f Requires -------- atomes (rpmlib, GLIBC filtered): bash-completion desktop-file-utils freeglut gtk3 libavcodec.so.59()(64bit) libavcodec.so.59(LIBAVCODEC_59)(64bit) libavformat.so.59()(64bit) libavformat.so.59(LIBAVFORMAT_59)(64bit) libavutil.so.57()(64bit) libavutil.so.57(LIBAVUTIL_57)(64bit) libc.so.6()(64bit) libcairo.so.2()(64bit) libepoxy.so.0()(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libgcc_s.so.1(GCC_4.0.0)(64bit) libgdk-3.so.0()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libgfortran.so.5()(64bit) libgfortran.so.5(GFORTRAN_10)(64bit) libgfortran.so.5(GFORTRAN_8)(64bit) libgio-2.0.so.0()(64bit) libglib-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libgomp.so.1()(64bit) libgomp.so.1(GOMP_1.0)(64bit) libgomp.so.1(GOMP_4.0)(64bit) libgomp.so.1(OMP_1.0)(64bit) libgtk-3.so.0()(64bit) libm.so.6()(64bit) libpango-1.0.so.0()(64bit) libpangocairo-1.0.so.0()(64bit) libpangoft2-1.0.so.0()(64bit) libswscale.so.6()(64bit) libswscale.so.6(LIBSWSCALE_6)(64bit) libxml2.so.2()(64bit) libxml2.so.2(LIBXML2_2.4.30)(64bit) libxml2.so.2(LIBXML2_2.6.0)(64bit) libxml2.so.2(LIBXML2_2.6.5)(64bit) mesa-libGLU rtld(GNU_HASH) atomes-debuginfo (rpmlib, GLIBC filtered): atomes-debugsource (rpmlib, GLIBC filtered): Provides -------- atomes: application() application(atomes.desktop) atomes atomes(x86-64) mimehandler(application/x-extension-apf) mimehandler(application/x-extension-awf) atomes-debuginfo: atomes-debuginfo atomes-debuginfo(x86-64) debuginfo(build-id) atomes-debugsource: atomes-debugsource atomes-debugsource(x86-64) Diff spec file in url and in SRPM --------------------------------- --- /home/user/reviews/2130607-atomes/srpm/atomes.spec 2022-10-18 09:32:52.275983796 +0200 +++ /home/user/reviews/2130607-atomes/srpm-unpacked/atomes.spec 2022-10-17 16:12:55.000000000 +0200 @@ -6,4 +6,6 @@ License: AGPL-3.0-or-later Source0: https://github.com/Slookeur/%{upname}/archive/refs/tags/v%{version}.tar.gz +Source1: ./v%{version}.tar.gz.asc +Source2: %{name}.gpg URL: https://%{name}.ipcms.fr/ @@ -60,4 +62,5 @@ %prep +# %%{gpgverify} --keyring='%%{SOURCE2}' --signature='%%{SOURCE1}' --data='%%{SOURCE0}' %autosetup -n %{upname}-%{version} Generated by fedora-review 0.9.0 (6761b6c) last change: 2022-08-23 Command line :/usr/bin/fedora-review -b 2130607 -v Buildroot used: fedora-rawhide-x86_64 Active plugins: Generic, C/C++, Shell-api Disabled plugins: PHP, Ocaml, Perl, fonts, Haskell, Java, R, SugarActivity, Python Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH
Hi Sébastien, well done. Here's what's left: - desktop-file-utils and libappstream-glib should be required only at build time, did you have any reason to add them as run time deps? If not, remove them. - The screenshots that are included in the AppStream file are not 16:9 and one of them has padding - this is what you see if you run appstream-util validate-strict: • aspect-ratio-invalid : <screenshot> aspect ratio not 16:9 [https://atomes.ipcms.fr/wp-content/uploads/2022/08/Ni-Phth-1024x512.jpeg] • style-invalid : <image> has vertical padding [https://atomes.ipcms.fr/wp-content/uploads/2022/08/lGeSe-1024x625.png] • aspect-ratio-invalid : <screenshot> aspect ratio not 16:9 [https://atomes.ipcms.fr/wp-content/uploads/2022/08/lGeSe-1024x625.png] • aspect-ratio-invalid : <screenshot> aspect ratio not 16:9 [https://atomes.ipcms.fr/wp-content/uploads/2022/08/workm2-1024x647.png] While the other warnings from appstream-util in strict mode can be ignored, I think that GNOME Software (and all the other software-center-type installers built on the same base) will throw a tantrum. See here for examples of good and bad screenshots: https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#qsr-app-screenshots-info In GNOME, you can use the screenshot window sizer extension to easily get 16:9 application windows: https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#qsr-app-screenshots-info Remember that if you want, you can also caption your images in the XML file, e.g.: <screenshot type="default"> <caption>Distance measurements on a Ni phthalocyanine unit cell</caption> <image>https://atomes.ipcms.fr/wp-content/uploads/2022/08/Ni-Phth-1024x512.jpeg</image> </screenshot>
Re, TAA :-) I think that 'desktop-file-utils' and 'libappstream-glib' are required at install time, that's when the 'install-data-local' commands from 'Makefile.am' are processed, that's why I think I have no choice but to check for this packages. Your opinion is welcome of course ;-) I will prepare the screenshots ASAP ! TAA :-)
(In reply to Sébastien Le Roux from comment #25) > I think that 'desktop-file-utils' and 'libappstream-glib' are required at > install time, that's when the 'install-data-local' commands from > 'Makefile.am' are processed, > that's why I think I have no choice but to check for this packages. Ok, so they are used only when the package is being created, therefore they are not needed at runtime, ergo they should be removed. Looking at your deps for the "rpm Fusion" package, I have a suspicion that there's a misunderstanding someplace. Everything required to compile the program and create the rpms (so everything that happens in %prep, %build, %install and %check) is listed as "BuildRequires". Everything else that the program might need when it is being used is listed as "Requires". Is this clear?
TAA ;-) Yes it is much better now ! I took care of the screenshots, and clean the metainfo xml file, however the 'appstream-util validate-strict' still fails with the following errors: FAILED: • translations-required : <name> has no translations • translations-required : <summary> has no translations • translations-required : <description> has no translations Validation of files failed Still trying to find some help about this
(In reply to Sébastien Le Roux from comment #27) > I took care of the screenshots, and clean the metainfo xml file, however the > 'appstream-util validate-strict' > still fails with the following errors: > > FAILED: > • translations-required : <name> has no translations > • translations-required : <summary> has no translations > • translations-required : <description> has no translations > Validation of files failed > > Still trying to find some help about this Feel free not to care about the translations, or the paragraphs that don't start with an uppercase letter. I will take a look later today.
Since yesterday I got an issue with the Koji builds: rpmbuild -bs atomes.spec is going to build the following (as it is supposed to): $HOME/rpmbuild/SRPMS/atomes-1.1.7-3.fc36.src.rpm Then Koji builds submitted using this SRPM: koji build --scratch rawhide /home/leroux/rpmbuild/SRPMS/atomes-1.1.7-3.fc36.src.rpm are mysteriously failing (same error each time, cannot find *.metainfo.xml file, declared in .spec file). So I used the following: rpmbuild -rp atomes-1.1.7-3.fc36.src.rpm To extract the sources, then I browse $HOME/rpmbuild/SOURCES/Atomes-GNU-1.1.7 To find out that the files are not the one that I expect ... (old ones), and I am kind of confused, because whenever I try to download the data using the link in the spec file I got the proper archive with the good files ... what is going on here ? Are you experiencing the same ?
Ok, sorry about the trouble, just figured out how stupid I am ;-)
I had no problem with fedora-review and I am running another scratch build, give it a few minutes.
I just thought that somehow rpmbuild was downloading the archive from Github, but is wasn't, just updated the archive in the $HOME/rpmbuild/SOURCES directory and everything runs smoothly again ;-)
(In reply to Sébastien Le Roux from comment #32) > I just thought that somehow rpmbuild was downloading the archive from > Github, > but is wasn't, just updated the archive in the $HOME/rpmbuild/SOURCES > directory > and everything runs smoothly again ;-) I figured as much, I've done it myself with local builds quite a few times. Congratulations, everything seems in order, package is approved. Before you can request branches and such, you need to get sponsored to the packager group. You may want to take another look at https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/ or directly open a ticket at https://pagure.io/packager-sponsors/issues . Once that is taken care of, I can help you with the rest of the process.
TAA :-) Will check everything, and let you know.
Re, got a question for you Alex, about these messages I get from rpmlint: atomes.x86_64: E: explicit-lib-dependency libavcodec-free atomes.x86_64: E: explicit-lib-dependency libavformat-free atomes.x86_64: E: explicit-lib-dependency libavutil-free atomes.x86_64: E: explicit-lib-dependency libepoxy atomes.x86_64: E: explicit-lib-dependency libgfortran atomes.x86_64: E: explicit-lib-dependency libswscale-free atomes.x86_64: E: explicit-lib-dependency libxml2 Few days ago I commented the corresponding 'Require' lines in the spec file (after reading that I should not require these lib, even if they are) now earlier today because of your comments I decided to uncomment the lines (and hence get the warning again) ... what should I do ? Because the lib are actually required for Atomes to run ... this is confusing for me. TAA in advance ;-) Seb
Ok again, this was already addressed before, sorry to bother you with that, will correct my spec file and the associated data. I whish I could delete my stupid messages from this feed ;-) Sorry again.
(In reply to Sébastien Le Roux from comment #36) > Ok again, this was already addressed before, sorry to bother you with that, > will correct my spec file and the associated data. > > I whish I could delete my stupid messages from this feed ;-) > > Sorry again. Hey, we've all been there, it shows you are actually learning, which is also good in your quest for a sponsor. As for the libraries required at runtime, did you see the attachment of fedora-review with all of the required so files? They were picked up, even though they had been commented out in the spec file.
Hello, Alex polishing things up, I remove the '--prefix=/usr' in the spec file which I think should not be there, also I noticed something in the build log, see here: https://kojipkgs.fedoraproject.org//work/tasks/913/93520913/build.log When the package starts to build, immediately after the './configure' I always see the following kind of line: ++ -j6 /var/tmp/rpm-tmp.wyKdjC: line 90: -j6: command not found + make or similar depending on the number of cores, I know the '-j' option for make of course, but how come this is never use when building an RPM (noticed the same thing on my workstation) ? TAA ;-)
(In reply to Sébastien Le Roux from comment #38) > Hello, > Alex polishing things up, I remove the '--prefix=/usr' in the spec file > which I think should not be there, > also I noticed something in the build log, see here: > > https://kojipkgs.fedoraproject.org//work/tasks/913/93520913/build.log > > When the package starts to build, immediately after the './configure' I > always see the following kind of line: > > ++ -j6 > /var/tmp/rpm-tmp.wyKdjC: line 90: -j6: command not found > + make > > or similar depending on the number of cores, I know the '-j' option for make > of course, but how come this is never use > when building an RPM (noticed the same thing on my workstation) ? > > TAA ;-) diff -ur a/atomes.spec b/atomes.spec --- a/atomes.spec 2022-10-28 14:37:51.160900761 +0300 +++ b/atomes.spec 2022-10-28 14:38:41.285731286 +0300 @@ -66,7 +66,7 @@ %build %configure -make `%{?_smp_mflags}` +make %{?_smp_mflags} %install %make_install
(In reply to Sébastien Le Roux from comment #38) > Hello, > Alex polishing things up, I remove the '--prefix=/usr' in the spec file > which I think should not be there, As long as your build automation does things The Right Way™ and all the files get installed where they should be, it doesn't matter. (In reply to Sergey from comment #39) > (In reply to Sébastien Le Roux from comment #38) > -make `%{?_smp_mflags}` > +make %{?_smp_mflags} Good eye Sergey. Where those backticks always there? There is an issue with your changelog though, you need to trim it down. The one maintained in the rpm package, should not be the same as the one you maintain upstream (and which you can install with the %doc macro in your %files section). It should contain information about changes made to the package, spec file, perhaps important bugs fixed, etc.. The scope is different than the changes you document upstream. In this case, end users reading it might care for example about configuration file changes, or some shortcut being placed in a specific folder. A co-maintainer or a packager coordinating a rebuild or migration would care about any patches you might have included, changes with regard to dependencies and things like that. See these two sections: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_documentation https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs When you have finished with that, go pass your unsolicited judgement on other people's review requests, so that you may get sponsored. Feel free to cc me in any bugs you comment on.
(In reply to Alexander Ploumistos from comment #40) > (In reply to Sergey from comment #39) > > (In reply to Sébastien Le Roux from comment #38) > > -make `%{?_smp_mflags}` > > +make %{?_smp_mflags} > > Good eye Sergey. Where those backticks always there? > I don't know, I just read the #38 and look into spec.
Thank you both, I will read the doc, take care of the changelog issue, and get back to you when done. Thanks again for helping out ! Really appreciate the laser eyes, the knowledgable comments and the time spent here. S.
One last(?) thing, in the build stanza, "make %{?_smp_mflags}" should be replaced by the %make_build macro. I just realized that there are some documentation pages that still haven't been updated, even though it's been years since we got the build automation macros.
Hi Sébastien, it's good to see that you're back. I hope the recovery was smooth and you can type at 3000 words per minute again. Would you like me to contact the sponsors group and move on with the process? Your last build in COPR fails to install because of the requirement on pangoft2: Problem: cannot install the best update candidate for package atomes-1.1.7-6.fc37.x86_64 - nothing provides pangoft2 needed by atomes-1.1.11-3.fc37.x86_64 You already have the BR on pangoft2 through pkg-config (which is provided by the pango-devel package). Do you also need pangoft2 at runtime? If yes, I think you should change the line in your spec file from "Requires: pangoft2" to "Requires: pango".
(In reply to Alexander Ploumistos from comment #44) Hello Alex, nice to read you after all this time, and happy to see that you kept an eye on this bug ;-) I must confess that I waited to get in touch because I still have some concern with my hand, not back a 100% let say :-( But yeah I am back in business, the first thing I did coming back, or close enough was to correct some bugs in Atomes, and hence provide a new package: atomes-1.1.11-4.* As a matter of fact I did some cleaning in my GNU tarball (configure.ac and else) and ended-up cleaning the spec file as well, so I got rid of this pangoft2 that was not needed at the 'Requires:' stage, so that has been taken care of. I actually think that I am pretty good with the spec file for now, no need to use "Requires: pango" because of the "Requires: gtk3" that will require it anyway. So yes, I am ready to move forward with the process ! Please let me know what I can do to help, should I got a look for bug(s) to check to show good faith ? Again nice to read you ! Sébastien
Please change %{_mandir}/man1/%{name}.1.gz to %{_mandir}/man1/%{name}.1* See https://docs.fedoraproject.org/en-US/packaging-guidelines/#_manpages . I don't think the current changelog is helpful, being full of - Revised package entries. Changelog entries should be describing the changes made instead of being added for their own sake.
(In reply to Dominik 'Rathann' Mierzejewski from comment #46) > Please change > > %{_mandir}/man1/%{name}.1.gz > > to > > %{_mandir}/man1/%{name}.1* > > See https://docs.fedoraproject.org/en-US/packaging-guidelines/#_manpages . > Thank you I missed that ;-) For the ChangeLog, I will correct it to describe the changes, I was not sure how relevant it would be to know that I updated the metadata or some modification in the Makefile.am. Will change that ;-) Thanks for your input.
The Pagure repository was created at https://src.fedoraproject.org/rpms/Atomes
The Pagure repository was created at https://src.fedoraproject.org/rpms/atomes
I was going through my open bugs and I noticed we forgot to close this one. Ideally, it should have been done from bodhi, but it makes no difference.