https://bugzilla.redhat.com/show_bug.cgi?id=1760617 --- Comment #10 from Qianqian Fang <fangqq@xxxxxxxxx> --- @Ankur thanks for the feedback, my updated spec file and srpm file are updated in the above post here are my replies to some of the top issues you spotted, let me know what you think. ------------------------------------------------------------------------- > Should the main spec/package be simply called mmc and then octave-.. as > sub-packages instead of the other way round? done, the main package is now mmc, and octave-mmclab etc are now subpkgs ------------------------------------------------------------------------- > This confirms that the generated srpm does not match the latest spec. Please > post the newest ones. sorry, I must have forgotten to update the srpm previously. Now, the new srpm can be found int he above post. ------------------------------------------------------------------------- > Please remove the executable perm all the permission and end-of-line issues are now corrected in the upstream, and I made a new upstream package to create the rpms https://github.com/fangq/mmc/commit/2139721339907362f269562540b2d63ef88f0561 I confirm that these issues are fixed in the new srpm ------------------------------------------------------------------------- > Lots of bundling here too. Is this required? this case is not bundling - the licenses found by the licensecheck are in the source-code files. They are all compatible with the final binary's license (GPLv3+) according to https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses as required by GPL license, once all these source units are compiled and linked into a binary, the final generated software shall be licensed under GPL https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation so, as long as the licenses of the source units are compatible with GPL, we should label the final executable/package as GPL. So I believe what I did here is correct. ------------------------------------------------------------------------- here are some of the minor comments: > Why does the build require vim-common? I use the xxd utility from vim-common to convert the OpenCL kernel file *.cl to .h file in order to compile it in the binary; this is similar to the case in mcxlab (Bug 1758622). ------------------------------------------------------------------------- > Please move the docs to the a sub-package. I've already put all mmc/examples into mmc-demos and mmc/mmclab/example to mmclab-demos. ------------------------------------------------------------------------- > - Build flags aren't used. Example from the build.log file: > Please use %{set_opt_flags} before you run %make_build done ------------------------------------------------------------------------- > You do not need to use pushd, you can use %make_build -C <directory name> done ------------------------------------------------------------------------- > There's still the ln -s mex etc. Is this the latest srpm? (Each time you > update the spec file, you need to regenerate the srpm and upload the latest > versions of both.) I believe this was a result of obsolete srpm files. please run it again with the new srpm. ------------------------------------------------------------------------- > [!]: Fully versioned dependency in subpackages if applicable. > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in mmclab- > demos , mmc , mmc-demos > Do the Requires be versioned? I think it is fine. this is the initial package, all the features in the demos are supported by this version. In the future, if some demos requires newer versions, I will add version in Requires. ------------------------------------------------------------------------- -- 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 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/package-review@xxxxxxxxxxxxxxxxxxxxxxx
