https://bugzilla.redhat.com/show_bug.cgi?id=1853888 Lyes Saadi <fedora(a)lyes.eu&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora(a)lyes.eu Blocks| |177841 (FE-NEEDSPONSOR) Doc Type|--- |If docs needed, set a value --- Comment #1 from Lyes Saadi <fedora(a)lyes.eu&gt; --- Hello :)! You seem to be new here! You should consider reading thoroughly this page: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers I am not a sponsor, so I won't do a proper review of your package. But, I've got some advices :P. --- 1. Store your project online, on a permanent place, preferably on a forge. Mainly because the Source tag have to be a URL (except if you have to clean the package before of some prohibited content or you use revision control, but you at least need to provide the URL from where you got the code in a comment), see https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/. A forge is an ideal choice for that, I would recommend GitHub, GitLab, Pagure, SourceHut, Bitbucket... etc. Also, fix your url. For me at least, `codecolla.com:10734` is unreachable. --- 2. Please fix your indentation and separate different sections. Your indentation is huge and inconsistent. Maybe you use 2-tab indentation? Use spaces instead, it will render more nicely and will be more readable. Also, we tend to separate these sections with 1 or more blank lines: Package Information (Name-Version-Release-Summary), Upstream Information (License-URL-Source[-Architecture]), BuildRequires, Requires, Description, Prep, Build, Install, Files, Changelog. Example: ``` Name: LTK Version: 1.5.3 Release: 11%{?dist} Summary: Ladspa v3 ToolKit License: GPLv3 URL: codecolla.com:10734 Source: %{name}-%{version}.tar.gz BuildRequires: gcc BuildRequires: glibc-devel BuildRequires: make BuildRequires: libunwind-devel Requires: libunwind %description Ladspa V3 ToolKit is a general purpose toolkit enabling object oriented programming in c. %prep %setup -q -c %build make NAME=%{name} VERSION=%{version} %install [...] ``` See how much nicer and cleaner it looks ;)? --- 3. Use `%make_build NAME=%{name} VERSION=%{version}`. This will allow for parallel build and is recommended for more consistency between packages ;). Even better, you could just add NAME := libLTK and VERSION := 1.5.3 to the Makefile, so you'd only have to call `%make_build`. --- 4. Add the installation process to the Makefile. In an `install` target, and replace all that with `%make_install`. This will make it way more readable and easier to maintain. --- 5. Add the compiler flags! By adding `%set_build_flags` in a separate line before `%make_build` or, by adding `%{optflags}` after `%make_build` like that: `%make_build %{optflags}`. See https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags. --- 6. Add a license to the package by including it in the tarball. And add in the `%files` section `%license LICENSE`. GPLv3 requires that the license be distributed with the program. --- 7. Remove the photos from the tarball. You don't install them, and they add an unnecessary weight. And if they are not Licensed in GPLv3, it could be a Licensing violation. --- 8. Remove the `%postun`. ``` %postun rm -f %{_libdir}/lib%{name}.so rm -f %{_includedir}/%{name} ``` It is done automatically. --- 9. Add a devel subpackage for the includes and unversioned.so. If you don't know how to do this, look at packages like libhandy for example: https://src.fedoraproject.org/rpms/libhandy/blob/master/f/libhandy.spec But generally, just add this after the `%description` section: ``` %package devel Summary: Development files for %{name} Requires: %{name}%{?_isa} = %{version}-%{release} %description devel The %{name}-devel package contains libraries and header files for developing applications that use %{name}. ``` And this after the `%files` section: ``` %files devel %{_libdir}/lib%{name}.so %{_includedir}/%{name}.%{version} %{_includedir}/%{name} %{_includedir}/%{name}.%{version}/instance.h %{_includedir}/%{name}.%{version}/utils.h ``` And remove those lines from the other files section. ---- 10. Version your changelogs. You don't need to do that for older changelogs, but, at least, the last one: ``` * Sat Jul 04 2020 Lewis ANESA <lan(a)codecolla.com&gt; - 1.5.3-11 - Merge branch 'logs' ``` ---- 11. Rename the spec or the package. The package and the spec should have the exact same name. I would recommend renaming the package `libLTK` -> `ltk`, unless you really want your package to be uppercase (RPM is case-sensitive, it will be harder to install), also the lib suffix isn't necessary in Fedora. I hope I've covered them all :P. Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=177841 [Bug 177841] Tracker: Review requests from new Fedora packagers who need a sponsor -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component

https://bugzilla.redhat.com/show_bug.cgi?id=1853888 --- Comment #3 from Lyes Saadi <fedora(a)lyes.eu&gt; --- I can see that it is already much, much better! Good job! This is why I personally use GitLab :P. `URL` tag is for HTTP, you have to point to a website (or the website of a Forge)! Yep, Pagure is awesome (and open for all projects!), and is open source and pretty lightweight! There's also Gitea and many other great choices that I would recommend (over savannah)! The `Source` tag (not the `URL` tag as explained above) HAVE TO (It is 1000% mandatory, unless, as I said, it fallen under two exceptions specified by the Guidelines) point directly (without Cloudflare/Anti-bot protection) to the source .tar.gz archive. That is fine, I guess. I'm a bit worried about the `ln` though, I never did that in a spec file, and you might need to add %{buildroot} to the first argument! I am not sure, though! But you should really replace `make NAME=%{name} VERSION=%{version}` by `%make_build NAME=%{name} VERSION=%{version}`. This will only add parallelism to speed up building, and shouldn't cause errors! `rpm -E "%set_build_flags"`! This is mandatory, you can override some parameters, but you shouldn't, and it generally points to a bigger problem within the code. Oui, j'avais vu ça en vérifiant si vous étiez Packager ou pas :P. Je penserais à y jetter un coup d'œuil ;)! But let's keep the rest of the conversation in English :). Hope a sponsor sees this ticket, so he can proceed to a formal review :P (it shouldn't take too long)! Basically, people not already in the Packager group need to be "approved" by a sponsor. And this generally is done with their first Review Request! -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component

https://bugzilla.redhat.com/show_bug.cgi?id=1853888 --- Comment #5 from Lewis <anesa.lewis(a)gmail.com&gt; --- Hi Robert-André Mauchin, really glad to see you there! "- Feel free to converse in French if needed." ok, everything I'm not sure to say the right way will be written in french. The line you paste there, what do you really expect? (same url as in "URL:"?) Vraiement officiellement? c'est hébergé sur une raspberry pi chez moi et accessible en git uniquement pour le moment : git clone git://codecolla.com/libltk Je compte à termes y mettre un serveur http pour suivre l'évolution des projets, deployer, tester, démontrer, etc... En attendant je pourrais fournir https://copr.fedorainfracloud.org/coprs/lewisanesa/CodeColla/ comme URL non? J'enlève .gz dans les fichiers, les commandes gzip, mais ne dois-je pas les remplacer par d'autres commandes? Sinon, comment rpm build sait où trouver les man pages dans mes sources? Le spec file est auto généré avec un script, il me faut encore travailler dessus. Vous le trouverez à la racine du projet git au nom de make.sh . Done. Le upstream ne risque pas de refuser, puisque c'est moi. Je suis seul et unique a ravailler sur ce projet et je veux coller aux specs de fedora. Je vais faire ça : gcc -shared -fPIC -Wl,-soname,libfoo.so.1 -o libfoo.so.1.0.0 foo.c Mais mettre des virgules dans une commande de compilation me semble étrange. For non french speaking people, I'll recap changes made to fit fedora requirements, may this help someone one day... -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component

https://bugzilla.redhat.com/show_bug.cgi?id=1853888 --- Comment #7 from Lewis <anesa.lewis(a)gmail.com&gt; --- Ok, I think I covered it all. The problem is now that rpm build don't work anymore. You can check it out on git clone git://codecolla.com/libltk cd libltk . make.sh This don't work anymore since I added -Wl,-soname,lib$(NAME).so to the gcc command for final so target. rpm build says : https://termbin.com/z2ye Regards. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component

https://bugzilla.redhat.com/show_bug.cgi?id=1853888 --- Comment #9 from Lewis <anesa.lewis(a)gmail.com&gt; --- Hi, I took Robert-André Mauchin's advices in account. Here is the new srpm and spec files : https://copr-be.cloud.fedoraproject.org/results/lewisanesa/CodeColla/fedo... https://copr-be.cloud.fedoraproject.org/results/lewisanesa/CodeColla/fedo... Now it generates libLTK.so.1 and libLTK.so -> libLTK.so.1 libLTK.so.1.6.3 -> libLTK.so.1 But I still have three questions : Why not do libLTK.so -> libLTK.so.1 -> libLTK.so.1.6.3 links? Shouldn't my package be dependent of libunwind? what if libunwind evolves? How can I change the line "rpmbuild -D "_topdir $(pwd)" -ba $SPEC_FILE" in order to use fedpkg or mock or whatever I have to use? (This line is in the over engineered auto script make.sh at the root of git://codecolla.com/libltk) I said : - Added a MAJOR global definition in the specfile - Commented and corrected Source0 - Added empty line management in dependencies - Switched %prep to %autosetup - Added intermediate shared object file with only major in name - Added it to soname on gcc final output - Gathered together install files and managed multi section manpages - Added link layer to proper tarball creation - Added fedora's compil flags - Removed libunwind dependency (libunwind-devel build dep is enough) - Added constant strings to sprintf calls (fedora flags compatibility) -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component

https://bugzilla.redhat.com/show_bug.cgi?id=1853888 --- Comment #11 from Lewis <anesa.lewis(a)gmail.com&gt; --- Hi, Ok, I'll keep it as is. Great to hear!!! Admit that one day, in the future, other dev use this package. Each time my package changes it's SOMANE (e.g. MAJOR part of the version), I'll have to mail the devel mailing list at least one week before this change? I don't know this mailing list but anyway, I don't plan to change this at all. I'll try it out but that might not change my package, isn't it? I promise I'll integrate it, I installed mock and added myself to mock group already. LTK Spec file is in the SPECS folder. LTK Tarball containig sources is in SOURCES folder. As said in section 4 of https://doc.fedora-fr.org/wiki/RPM_:_environnement_de_construction , $HOME/rpmbuild/SOURCES (dossier contenant les sources : archives, patches...) $HOME/rpmbuild/SPECS (dossier contenant les fichiers .spec contenant les instructions de construction) Do you still want me to gather them in the same folder? Is that mandatory, especially in order to find a sponsor? And last question, if all is ok, am I ready to be sponsorized? Regards, Lewis ANESA. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component

https://bugzilla.redhat.com/show_bug.cgi?id=1853888 --- Comment #13 from Robert-André Mauchin 🐧 <zebob.m(a)gmail.com&gt; --- I believe your spec filename and spec Name field should be named libltk, and that the devel libs requires it. - Escape the macros in changelog by doubling the %%, for example - Switched %%prep to %%autosetup - The changelog entries should contain the Version-Release info: %changelog * Wed Jul 15 2020 Lewis ANESA <lan(a)codecolla.com&gt; - 1.6.3-14 - Corrected links and compil flags Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed ===== 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]: ldconfig not called in %post and %postun for Fedora 28 and later. [x]: Package does not contain any libtool archives (.la) [x]: Rpath absent or only used for internal libs. [x]: Development (unversioned) .so files in -devel subpackage, if present. 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: "Unknown or generated". 19 files have unknown license. Detailed output of licensecheck in /home/bob/packaging/review/LTK/review- LTK/licensecheck.txt [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. [-]: Package contains desktop file if it is a GUI application. [x]: 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). [!]: 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. [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 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]: Dist tag is present. [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 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]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 0 bytes in 0 files. [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). [?]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [x]: Scriptlets must be sane, if used. [x]: SourceX tarball generation or download is documented. Note: Package contains tarball without URL, check comments [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [-]: 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]: 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]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on debuginfo package(s). Note: There are rpmlint messages (see attachment). [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: LTK-1.6.3-14.fc33.x86_64.rpm LTK-devel-1.6.3-14.fc33.x86_64.rpm LTK-debuginfo-1.6.3-14.fc33.x86_64.rpm LTK-debugsource-1.6.3-14.fc33.x86_64.rpm LTK-1.6.3-14.fc33.src.rpm LTK.x86_64: W: spelling-error Summary(en_US) Ladspa -> Lad spa, Lad-spa, Lads pa LTK.x86_64: W: spelling-error %description -l en_US Ladspa -> Lad spa, Lad-spa, Lads pa LTK.x86_64: W: no-version-in-last-changelog LTK.x86_64: W: no-documentation LTK-devel.x86_64: W: no-version-in-last-changelog LTK-debuginfo.x86_64: W: no-version-in-last-changelog LTK-debugsource.x86_64: W: no-version-in-last-changelog LTK.src: W: spelling-error Summary(en_US) Ladspa -> Lad spa, Lad-spa, Lads pa LTK.src: W: spelling-error %description -l en_US Ladspa -> Lad spa, Lad-spa, Lads pa LTK.src: W: no-version-in-last-changelog LTK.src:68: W: macro-in-%changelog %prep LTK.src:68: W: macro-in-%changelog %autosetup LTK.src:92: W: macro-in-%changelog %postun LTK.src: W: invalid-url Source0: SOURCES/LTK-1.6.3.tar.gz 5 packages and 0 specfiles checked; 0 errors, 14 warnings. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component

https://bugzilla.redhat.com/show_bug.cgi?id=1853888 --- Comment #15 from Robert-André Mauchin 🐧 <zebob.m(a)gmail.com&gt; --- Mock takes a srpm as input, not a spec file. You can generate a srpm with: fedpkg --release f33 srpm -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component

https://bugzilla.redhat.com/show_bug.cgi?id=1853888 Lewis <anesa.lewis(a)gmail.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(anesa.lewis@gmail | |.com) | --- Comment #17 from Lewis <anesa.lewis(a)gmail.com&gt; --- Project in pseudo stand by because I moved to a just built house, had a baby and a new work, all together. But I'll come back in some month, I promise. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component

Product: Fedora Version: rawhide Component: Package Review Lewis <anesa.lewis(a)gmail.com&gt; has canceled Package Review <package-review(a)lists.fedoraproject.org&gt;&#39;s request for Lewis <anesa.lewis(a)gmail.com&gt;&#39;s needinfo: Bug 1853888: Review Request: libLTK - Ladspa v3 ToolKit https://bugzilla.redhat.com/show_bug.cgi?id=1853888 --- Comment #19 from Lewis <anesa.lewis(a)gmail.com&gt; --- Project in pseudo stand by because house built, had a second baby, work fine. Project active, need time for Fedora integration. But I'll come back in some month/years, I promise.

https://bugzilla.redhat.com/show_bug.cgi?id=1853888 Lewis <anesa.lewis(a)gmail.com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(anesa.lewis@gmail | |.com) | --- Comment #21 from Lewis <anesa.lewis(a)gmail.com&gt; --- Project in pseudo stand by because lots of other work. Project still active, need time for Fedora integration. But I'll come back in some months (think end of 2023, start of 2024), I promise. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1853888 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=rep...