https://bugzilla.redhat.com/show_bug.cgi?id=2430590
--- Comment #35 from Cristian Le <[email protected]> --- > I changed the Source0: to a URL but I'm not sure that helps - it seems that > the file still needs to be downloaded into SOURCES Yes it helps contributors help update, including automations like packit [1] which helps create the PRs automatically when a new version is released. By default it only updates the `Version` tag, and does the downloading and uploading from the template in `Source0`. Re the still needs to be downloaded, yes that is a general workflow in (almost) all spec files here, i.e. use `spectool -g` to download them (and then upload them to lookaside cache). > I don't understand this - the Sourceforge archive IS git. ( > https://sourceforge.net/p/linux-gpib/git/ci/master/tree/ ) Yes, but it does not seem to provide archives (as you just noted in a few hours :) ). E.g. for a github repo (https://github.com/tukaani-project/xz/) the release git archive (and even arbitrary commit ones) are available (https://github.com/tukaani-project/xz/archive/<commitish>.tar.gz). On the other hand, sourceforge provides release tarballs (github equivalent is https://github.com/tukaani-project/xz/releases/download/v5.8.3/xz-5.8.3.tar.gz), which I linked previously in https://sourceforge.net/projects/linux-gpib/files/linux-gpib%20for%203.x.x%20and%202.6.x%20kernels/. The difference between a git archive and the release tarball is that the latter can have arbitrary contents (hence the libxz issue [2]) and it is usually used to provide pre-compiled `configure` files (which you are not supposed to use either way). > There is no firmware files in `linux-gpib-kernel`, these are the files that > are now also part of the linux-kernel. Everything in the Sourceforge git > archive (and consequently .zip file) is GPL Oh I see, where did you get the link for https://linux-gpib.sourceforge.io/firmware? The only reference I found is to https://github.com/fmhess/linux_gpib_firmware. > I define soversion and used %{soversion} but this is probably not what you > want .. please check and let me know The current version looks good. The issue is that you should use the soversion in the `%{_libdir}/libgpib.so.%{soversion}` so that if there is a change in that file, you catch it early and can check all dependents are compatible and are being rebuilt. For this package this might not be an issue, but it's good practice to use in general. > What do you mean by 'Sections' - please elaborate There are various sections defined, but over here I mainly refer to the build-scriplets [3] `%prep`, `%conf`, `%build`, `%install`, `%check`, and `%generate_buildrequires` which behave effectively like sections so it is common to use those as the main separators, e.g. ``` ... %prep %autosetup %build %cmake %cmake_build ... ``` in the current one the `# Post-install stuff` is a confusing deliminator, particularly since `%post` and such belong to specific (sub-)package and not the build process. > I removed the ldconfig_scriptlets as they are not used in Fedora (if I reads > the documentation correctly). I think the ldconfig is still needed. `%ldconfig_scriptlets` and `%ldconfig` are the same thing [4-6]. I did misunderstood its function though ``` ldconfig will look only at files that are named lib*.so* (for regular shared objects) or ld-*.so* (for the dynamic loader itself). Other files will be ignored. Also, ldconfig expects a certain pattern to how the symbolic links are set up, like this example, where the middle file (libfoo.so.1 here) is the SONAME for the library: libfoo.so -> libfoo.so.1 -> libfoo.so.1.12 ``` but obviously the `%ldconfig` are not needed because you already have those files in `%files` and if you would need it it should be at build time. But let me double-check with devel room. > - Please confirm the providence of all the Source/Patch files > ++ yes all GPL files Not exactly what I asked, but that was on my fault. Besides licensing there is also the copyright holder, and who is it in those cases, you, upstream, or a third-party. If it's the 2nd or 3rd one, you must include a reference. > about the tcl Can you post on #devel or #buildsys:fedoraproject.org matrix room about this? [1]: https://packit.dev/docs/fedora-releases-guide [2]: https://en.wikipedia.org/wiki/XZ_Utils_backdoor [3]: https://rpm-software-management.github.io/rpm/manual/spec.html#build-scriptlets [4]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_shared_libraries [5]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_linker_configuration_files [6]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#alternatives-to-rpath -- 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=2430590 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202430590%23c35 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
