Kushal Das wrote: What about making directly the build on koji ? It enables to test all version and all arch before the review. I actually think that we should couple a bit more Koji and the BZ such as - I submit a review - I provide a build number from koji (me if I am approved or review-o-matic) - Koji does not delete this build until the review is done - When the package is approved (is so), koji remove the build. Would that be an interesting feature ? Best regards, Pierre

Paul W. Frields wrote: That my though, the only constraints here is for new packager. Correct me if I am wrong but I think only people from the packager group can do a scratch-build. Best regards, Pierre

On Thu, 2008-10-16 at 15:46 +0200, Pierre-Yves wrote: Presumably if we automate this to the point where it uses a bot to "pre-review" then we could just put the bot in the group. -- Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com&gt; PLEASE don't CC me; I'm already subscribed

Debarshi Ray wrote: You perfectly got my point. Should I make a Feature Request on the bugzilla ? Best regards, Pierre

On Thu, 2008-10-16 at 19:19 +0530, Debarshi Ray wrote: Presumably the scripts could check to see if the builds succeeded and annotate the review appropriately. -- Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com&gt; PLEASE don't CC me; I'm already subscribed

On Thu, Oct 16, 2008 at 06:09:48PM +0530, Kushal Das wrote: Could it submit the package to Koji? Always nice to know it builds on ppc/ppc64. Essentially every package guideline which (a) isn't already done by rpmlint, and (b) can feasibly be checked automatically, should be checked. I've long thought that rpmbuild should have an option to run test tools on the generated packages. Particularly rpmlint, but your review tool is another candidate. rpmbuild --test=rpmlint -ba foo.spec Maybe rpmbuild can actually do this with one of its myriad macros? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

On Fri, Oct 17, 2008 at 08:14:31AM -0700, Chris Weyl wrote: It would be great if some effort could also be spent extending rpmlint itself to handle most of these things. Why implement a new tool when we have one already? Also, we need to document somewhere what review items are checked by rpmlint. Last time I did a review, I tried to figure out which of the items on the Packging Guidelines were checked by rpmlint, even going as far to check the source code, but gave up in frustration. It is redundant to give rpmlint output, and then still have to report on every review guideline--even ones that the lack of rpmlint output implies. Furthermore, since the Packaging Guidelines can change, it would help if they were versioned in some way so that rpmlint could refer to which version of the guidelines it is following.

On Fri, Oct 17, 2008 at 11:27:35AM -0400, Chuck Anderson wrote: Unless I am wrong, rpmlint is not a checked for fedora package guidelines, it is distribution agnostic, simply a tool for checking common errors in rpm packages. -- Pat

On Friday 17 October 2008, Jason L Tibbitts III wrote: That's right. If necessary, we'll patch rpmlint in Fedora for Fedora needs, but I'd much rather make changes upstream. The good thing is that a lot of the changes we've historically made in Fedora rpmlint have been found desirable in rpmlint upstream as well - other distros have found them useful too. Compared to vanilla upstream, we currently have only two patches (one of which could actually be applicable upstream) and our own config in the Fedora package. The license checks are a good example of this (and to give credit where it's due, it was spot who implemented them) - the code to check stuff is upstream and we just maintain the list of Fedora-approved license identifiers in config files in the Fedora package. I'm sure that there are a lot of things that are not at all Fedora specific that rpmlint doesn't currently check but very well could. Please do send patches either to Bugzilla or upstream rpmlint Trac, or just file RFE's (these usually preferably in upstream Trac) in case you have good ideas but no code yet. The two things I'd like people to keep in mind when submitting rpmlint RFE's are that 1) ideally checks should be made as generic as feasible so we can maintain them upstream (but that doesn't have to prevent submitting entirely Fedora specific ones in Bugzilla), and 2) apart from some very specific checks on installed packages, the unit of work for rpmlint is one package. I'm not aware of any plans to change that (nor do I really know if it'd be a good direction for rpmlint), so some RFE's/bug reports may be rejected if getting them done would require knowledge of other packages than the one currently being checked. Good patches are of course one way to change that ;)

On Saturday 18 October 2008, Richard W.M. Jones wrote: Right.

What is the status of this project? Did anyone started out writing some code? I want to contribute to this. Is there a webpage? My opinion on this idea is, we should first write a script that displays 3 different kind of outputs: 1- Pure automatic checks: sha1sums, %files etc. -> Display results 2- Semi-automatic checks: For instance, the script will check for static libraries in the build. -> Display results (If there are static libraries then it will warn the reviewer so he can check for the necessity of them.) 3- Purely manual checks: Not everything in the guidelines is easy to implement. Hence after the script is done, it will tell the reviewer what else needs to be checked manually. As time goes more features can be implemented and more items from 3 can be shifted into 1 or 2. We will need to build a powerful parser. I think some code can be borrowed from rpmlint. -oget

On Fri, 2008-10-31 at 16:11 -0700, Orcan Ogetbil wrote: Borrowing code is a losing proposition. What we need is for the main rpmlint script to be refactored so that we can call it with a filename. -- Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com&gt; PLEASE don't CC me; I'm already subscribed

On Mon, 2008-11-03 at 08:39 +0200, Ville Skyttä wrote: Right now rpmlint.py contains a large amount of magick, in the forms of a lot of global code and a rather complex main(). It would be handy various functions could be called that loaded the tests, tested the files, and processed the results. That way rpmlint could be used as part of a larger Python app such as the future Review-o-Matic. -- Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com&gt; PLEASE don't CC me; I'm already subscribed

Orcan Ogetbil wrote: I the ideal tool for this purpose IHO, would be some kind of web application, to handle all the workflow around getting packages into Fedora. * uploading specs and srpms * do automatic tests based on packaging guidelines. * a reviewer multiple choice popquiz to go through all the checks in review guidelines. showing the result of the automatic test for the each rules. TurboGear would be a good choice for such an application. A standalone checker would also be a good idea, for the packager to check that the spec etc, there has been made complies to the guidelines, before it is uploaded to web application. It would also be a good idea to design some kind framework to implement the different rules in a generic way, so it is easier for the web/standalone application to interface with the tests, and it would be easier to add new ones and the current one can made better without breaking the interface with the generic tools. Each test should be some kind of plugin into the main application. Tim

On Saturday, 01 November 2008 at 08:27, Kushal Das wrote: Bleh. What about offline checking? Or at least, will this web application work with lynx/links? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

On Sat, 2008-11-01 at 10:37 -0700, Toshio Kuratomi wrote: Doesn't the chroot mitigate most of the issues there might be in the source package? A VM can probably mitigate the rest. -- Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com&gt; PLEASE don't CC me; I'm already subscribed

2008/11/2 Toshio Kuratomi <a.badger(a)gmail.com&gt;: `[..] [..] It would be there. When we get something working first, we can easily make scripts for reviewer to run locally or even for reporter (for some major part at least) e.g checking spec for guidelines. -- Cheers, rakesh