Le blog de pingou - Tag - ReviewLe blog de pingou, ses actualités sur Fedora, ses RPMs, ses tests, son Linux... :-)
Pingou's weblog, his fedora's news, his RPMs, his tests, his Linux... :-)2022-02-17T10:46:15+01:00pingouurn:md5:66db5ce1ed1a80cb2f424695b4bb7780DotclearNew branch request processurn:md5:36fcb2125aad14317d8b1302835195ff2015-01-22T10:52:00+00:002015-01-22T12:57:18+00:00Pierre-YvesGénéralFedoraFedora-planetpkgdbReviewRPM <p><a href="http://blog.pingoured.fr/index.php?post/2014/07/23/New-package%2C-new-branch%2C-new-workflow">A little while ago</a> I blogged about a new process to request a new branch on an existing package.</p>
<p>The code to support this change is now <a href="https://blog.pingoured.fr/index.php?post/2015/01/22/">under review</a> but I thought I should document the workflow a little bit, so here is how I tried to design things:</p>
<p><a href="https://blog.pingoured.fr/public/pkgdb_new_branch_flow_2.png" title="pkgdb_new_branch_flow_2.png"><img src="https://blog.pingoured.fr/public/pkgdb_new_branch_flow_2.png" alt="pkgdb_new_branch_flow_2.png" style="display:block; margin:0 auto;" title="pkgdb_new_branch_flow_2.png, Jan 2015" /></a></p>
<p>Ideally, when the branch is approved and created in pkgdb by the admin, pkgdb will send a message on fedmsg, message that will be seen by a fedmsg-consummer that will automatically update the git repos within, say 2 minutes.
That last part if almost ready and hopefully will be running soon.</p>New package, new branch, new workflow?urn:md5:4a2aa36d93a98d435fd91ed28ddca9192014-07-23T09:28:00+01:002014-07-23T09:28:00+01:00Pierre-YvesGénéralFedoraFedora-planetpkgdbReviewRPM <p>If you are a <a href="http://fedoraproject.org/">Fedora</a> packager, you are probably aware of the new <a href="https://admin.fedoraproject.org/pkgdb/">pkgdb</a>.</p>
<p>One question which has been raised by this new version is: should we change the process to request new branches or integrate new packages in the distribution.</p>
<p>The discussion has occurred on the <a href="https://lists.fedoraproject.org/pipermail/rel-eng/">rel-eng mailing list</a> but I'm gonna try to summarize here what the process is today and what it might become in the coming weeks.</p>
<h5>Current new-package procedure:</h5>
<ol>
<li>packager opens a review-request on bugzilla</li>
<li>reviewer sets the fedora-review flag to ?</li>
<li>reviewer does the review</li>
<li>reviewer sets the fedora-review flag to +</li>
<li>packager creates the scm-request and set fedora-cvs flag to ?</li>
<li>cvsadmin checks the review (check reviewer is a packager)</li>
<li>cvsadmin processes the scm-request (create git repo, create package in pkgdb)</li>
<li>cvsadmin sets fedora-cvs flag to +</li>
</ol>
<h5>New procedure</h5>
<ol>
<li>packager opens a review-request on bugzilla</li>
<li>reviewer sets the fedora-review flag to ?</li>
<li>reviewer does the review</li>
<li>reviewer sets the fedora-review flag to +</li>
<li>packager goes to pkgdb2 to request new package (specifying: package name, package summary, package branches, bugzilla ticket)</li>
<li>requests added to the scm admin queue</li>
<li>cvsadmin checks the review (check reviewer is a packager¹)</li>
<li>cvsadmin approves the creation of the package in pkgdb</li>
<li>package creation is broadcasted on fedmsg</li>
<li>fedora-cvs flag set to + on bugzilla</li>
<li>git adjusted automatically</li>
</ol>
<p>Keeping the fedora-cvs flag in bugzilla allows to perform a regular (daily?) check that there are no fedora-review flag set as + that have been approved in pkgdb and whose fedmsg message hasn't been processed.</p>
<p>Looking at the number, it looks like there are more steps on the new procedure but eventually, most of them can be automated.</p>
<h5>New branch process</h5>
<p>For new branches, the process would be very similar:</p>
<ol>
<li>packager goes to pkgdb2 to request new branch</li>
<li>requests added to the scm admin queue</li>
<li>cvsadmin checks the request (requester is a packager...)</li>
<li>cvsadmin approves the creation of the branch in pkgdb</li>
<li>branch creation is broadcasted on fedmsg</li>
<li>git adjusted automatically</li>
</ol>fedora-create-reviewurn:md5:1ecd737df0cd587614c522698326e0982012-01-08T18:45:00+00:002012-01-08T19:53:46+00:00Pierre-YvesGénéralFedoraFedora-planetPythonReview<p><img src="https://blog.pingoured.fr/public/source.png" alt="source.png" /></p>
<p>A small tool to automatically generate review request.</p> <p><strong><em>English version</em></strong></p>
<p><strong>fedora-create-review</strong> is a small tool I wrote this week-end to help packager to create review request on the Red Hat's bugzilla after making a scratch build on koji.</p>
<p>The basic idea is:</p>
<pre>- from a spec and srpm
- start a koji scratch build
- if build worked
- upload to fedorapeople.org
- create the bugzilla ticket
- Add the koji build in the bugzilla as a link
- otherwise:
- warn user</pre>
<p>The configuration to upload the files on fedorapeople.org can be set on <em>~/.config/fedora-create-review</em></p>
<p>Basic use will be:</p>
<pre>fedora-create-review.py path/to/spec path/to/srpm</pre>
<p>Options can be checked via <em>--help</em></p>
<p>Check the <a href="http://ambre.pingoured.fr/cgit/fedora-create-review.git/">git repo</a> or the <a href="https://github.com/pypingou/fedora-create-review">github mirror</a></p>
<p>Hope this helps.</p>Fedora-review, help yourself!urn:md5:dd07cb59a2e14328e3d6a566eb140c2b2011-11-13T11:36:00+00:002011-11-13T11:36:00+00:00Pierre-YvesGénéralFedoraFedora-planetfedora-reviewFedoraReviewPythonReviewRPM<p><img src="https://blog.pingoured.fr/public/rpm.png" alt="rpm.png" /><img src="https://blog.pingoured.fr/public/source.png" alt="source.png" /></p>
<p>Fedora-review is a tool to speed up review process</p> <p><strong><em>English version</em></strong></p>
<p>All person who have done a number of <a href="http://fedoraproject.org/wiki/Package_Review_Process">reviews</a> to allow <a href="http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/">RPM</a> package to enter the fedora repositories know that it is a pretty repetitive process.</p>
<p>The proof is that a number of person have tried to write tool to automate some/most of the review process. I'm just thinking of:</p>
<ul>
<li><a href="https://github.com/robertfeldt/spec-check">spec-check</a></li>
<li><a href="https://github.com/jness/spec_checks">spec_checks</a></li>
<li><a href="http://project.pingoured.fr/reviewHelper/">reviewHelper</a></li>
<li><a href="https://fedoraproject.org/wiki/Category:Package_Maintainers/Review_Template">templates for reviews</a></li>
</ul>
<p>One of the missing point from these tools was the fact that the test performed are written in one single language, while python guys like to work in python, perl guys would prefer to run their tests in perl, php guys in php and so on.
Also, quite sometime these tests are actually written more for a specific type of package (C/C++, Java, R, perl...) while we would need a more generic solution.</p>
<p>So recently, few of us decided that we really should do something about it.</p>
<p>We started from the work of Tim Lauridsen on <a href="https://github.com/timlau/FedoraReview">FedoraReview</a>. We used this as a basis and decided to enhance it.</p>
<p>The whole project is now located on <a href="http://fedorahosted.org/FedoraReview">http://fedorahosted.org/FedoraReview</a> and we have (among other):</p>
<ul>
<li>Enhance the number of checks run by the tool</li>
<li>Allow language specific tests to override a generic test (for example, in R, if the package if in one of the major repositories, one can check if it is the latest version of the package which is present there)</li>
<li>Allow checks to be written in any executable language (we now have an example of this type of plugin written in perl)</li>
</ul>
<p>This is in addition of what was already there:</p>
<ul>
<li>Integration with bugzilla</li>
<li>Integration with mock</li>
</ul>
<p>For now on what we would like is:</p>
<ul>
<li>Testers to report us bugs</li>
<li>Testers to make feature request</li>
<li>More testers</li>
<li>Potential contributors to help us develop more plugin and check (remember you can do that in any executable language you want!)</li>
<li>More testers (did I say that already?)</li>
</ul>
<p><strong>Please have a look, test it, complain to us and come to help us improve it!</strong>
<br />
<br />
<br /></p>
<p>Want more reading? See <a href="http://inputvalidation.blogspot.com/2011/11/fedora-review-package-reviews-made.html">Stanislav's blog</a>
<br /></p>
<p>Want to see how it looks like?</p>
<pre>
$ fedora-review -b 678809
Processing review bug : 678809
Getting .spec and .srpm Urls from bug report : 678809
Downloading .spec and .srpm files
Building ./678809/seeks-0.4.0-0.5.RC2.fc17.src.rpm using mock fedora-rawhide-i386
INFO: mock.py version 1.1.17 starting...
State Changed: init plugins
INFO: selinux enabled
State Changed: start
INFO: Start(./678809/seeks-0.4.0-0.5.RC2.fc17.src.rpm) Config(fedora-rawhide-i386)
State Changed: lock buildroot
State Changed: clean
INFO: chroot (/var/lib/mock/fedora-rawhide-i386) unlocked and deleted
[... mock output ...]
Build completed ok
Downloading (Source0): http://downloads.sourceforge.net/seeks/solo/seeks-0.4.0-RC2.tar.gz
No upstream for (Source2): seeks.logrotate
No upstream for (Source1): seeks.service
Running checks and generate report
Checking source md5 : /home/pingou/FedoraReview/src/678809/seeks-0.4.0-RC2.tar.gz
Review in: ./678809/seeks-review.txt
</pre>
<p>And the output:</p>
<pre>
Package Review
==============
Key:
- = N/A
x = Check
! = Problem
? = Not evaluated
==== C/C++ ====
[x]: MUST Header files in -devel subpackage, if present.
[x]: MUST ldconfig called in %post and %postun if required.
[x]: MUST Package does not contain any libtool archives (.la)
[ ]: MUST Package does not contains kernel modules.
[...]
==== Generic ====
[ ]: MUST Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines.
[x]: MUST Package successfully compiles and builds into binary rpms on at least one supported architecture.
[x]: MUST All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines.
[ ]: MUST Package contains no bundled libraries.
[ ]: MUST Changelog in prescribed format.
...
</pre>
<p>Feel free to drop by #fedora-review with you suggestions/complains</p>reviewHelperurn:md5:b84bd57b519161e669a7863216592c032010-06-05T20:09:00+01:002011-06-29T14:17:23+01:00Pierre-YvesGénéralFedoraPythonReviewRPM<p><img src="https://blog.pingoured.fr/public/source.png" alt="source.png" /></p>
<p>Automate some of the step needed for a review</p>
<p>Automatiser quelques unes des étapes pour la revue d'un paquet RPM</p> <p><strong><em>English format</em></strong></p>
<p>One month ago I <a href="http://blog.pingoured.fr/index.php?post/2010/05/13/R-autoreview">was presenting a small script</a> to automate to a certain point R review.</p>
<p>Since then, I have quickly been working on re-factoring the code to make it hopefully cleaner and more flexible.</p>
<p>The script works really simply, give it a src.rpm or a url and it will download the src.rpm, download the sources of the package, compare the sha1sum with upstream, install the srpm, build it locally and if the local build worked, start a scratch build on koji and run rpmlint on the generated rpm.</p>
<p>This is made for any package, but according to the name of the package more functionality can be added. I already added the function specific for R reviews, but I would like to know if person from PHP-Pear/Pcl or from Perl would also be interesting to add their own method in this script.</p>
<p>Again the goal is not to replace to reviewer but more to make his task easier also by automating some of the mandatory steps (such as the local build, the sha1sum of the srpm vs the upstream sources or running rpmling). It is not meant to replace a human reviewer but more to assist him.</p>
<p>The script is available at: <a href="http://pingou.fedorapeople.org/reviewHelper.py">http://pingou.fedorapeople.org/reviewHelper.py</a></p>
<p>Let me know if you find it interesting.</p>R-autoreviewurn:md5:d6ddd9a99a90305fa1fea7a3cc8a64ff2010-05-13T10:06:00+01:002011-06-29T14:17:28+01:00Pierre-YvesGénéralFedoraPythonReviewRPM<p><img src="https://blog.pingoured.fr/public/source.png" alt="source.png" /></p>
<p>A script to help to review R packages</p>
<p>Un script pour aider à faire des revues de paquets R</p> <p><strong><em>English version</em></strong></p>
<p>There has been a bunch of new R review submitted to the <a href="http://bugzilla.redhat.com">redhat Bugzilla</a> lately and I have been doing some.</p>
<p>R is easy to package (R2spec being of some help on that) and quite boring to review. The package needs to follow the guidelines but after that besides the license, potential warning at build time and the dependencies there isn't much to check.</p>
<p>So in order to make my life easier I have written a small script that automates a number of steps for me.</p>
<p>There is what it does from a srpm:</p>
<ul>
<li>check for the latest version</li>
<li>download the src.rpm</li>
<li>install the src.rpm</li>
<li>download sources</li>
<li>sha1sum of the sources</li>
<li>sha1sum of the sources from src.rpm</li>
<li>check that R-core is in the Requires line</li>
<li>check that R-devel is in the BuildRequires line</li>
<li>check that tex(latex) is in the BuildRequires line</li>
<li>check that %dir */R/library/%{packname} is present</li>
<li>check that %doc concerns at least doc, html, DESCRIPTION, NEWS and print the other</li>
<li>check the %install</li>
<li>check that there is coherence between noarch and datadir</li>
<li>check that there is not both datadir and libdir in a spec</li>
<li>build locally the rpm and run rpmlint on them</li>
<li>start a build on koji for the src.rpm</li>
</ul>
<p>This output looks like this:</p>
<pre>$ python Scripts/R-autoreview.py -s R-caTools-1.10-2.fc12.src.rpm * Latest version packaged
Target is already in the folder, no need to re-download it
e9f393dbfe3928448ccdc40dd011987d73acce9b caTools_1.10.tar.gz
e9f393dbfe3928448ccdc40dd011987d73acce9b /home/pierrey/rpmbuild/SOURCES/caTools_1.10.tar.gz
* sha1sum are equals
* All required Requires are present
! R-core is present more than once
* All required BuildRequires are present
* There is 1 %dir
%dir is OK
* There is 2 %doc
%doc is OK
* The rpm installed in _libdir
* The rpm seems to have the required element in %install
* The rpm uses %{_libdir} and is arch
rpmbuild -ba /home/pierrey/rpmbuild/SPECS/R-caTools.spec > R-caTools.spec-build.log 2>&1
* Build properly under 2.6.33.3-85.fc13.x86_64
* rpmlint:
R-caTools.src: W: spelling-error %description -l en_US cumsum -> cum sum, cum-sum, cums um
R-caTools.x86_64: W: spelling-error %description -l en_US cumsum -> cum sum, cum-sum, cums um
3 packages and 0 specfiles checked; 0 errors, 2 warnings.
Scratch build on koji for target f14
* Koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2184735
0 free 0 open 3 done 0 failed
2184735 build (dist-f14, R-caTools-1.10-2.fc12.src.rpm) completed successfully</pre>
<pre> TODO:
* Check the sources for license
* Check the build, log for Warning & co</pre>
<p>This script is available at:
<a href="http://pingou.fedorapeople.org/R-autoreview.py">http://pingou.fedorapeople.org/R-autoreview.py</a></p>