https://bugzilla.redhat.com/show_bug.cgi?id=2130607 --- Comment #15 from Alexander Ploumistos <alex.ploumistos@xxxxxxxxx> --- (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. -- 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=2130607 _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
