time for a review-oh-matic?
by Chris Weyl
So, building on the spirited debate going on with respect to a
suggested review template, is it time for a review-oh-matic type
service?
Many of the things we do for reviews are the same. Check it builds in
mock (koji scratch), check the srpm sources against upstream, look @
rpmlint, look at the file lists, etc, etc... Wouldn't it make all our
lives to have a simple little tool that a packager could submit a srpm
for review to. It could then, say (and off the top of my head):
1) extract the spec, and push it + the srpm somewhere
2) file a review bug
2) kick off a koji scratch build
3) post a link to the build, success/failure, build logs (a la the
FTBFS overlord)
==> success, pull the built rpms, and post to the review bug:
* rpmlint, requires/provides
* md5/sha1 of srpm provided source against upstream
* a partial template, good bad, etc.
Provisions could be made for dependencies -- e.g. pass blocking review
bug; won't try to do any of the koji bits until the blocking bug(s) is
closed. As the review process goes on, new srpms could be submitted
against the same review and have the same automatic bits run.
This certainly isn't intended to automatically review and approve
packages, and wouldn't be an excuse for reviewers to just rubber
stamp. But it certainly could make the process a little less painful
and more reliable by consistently automating those bits that it's
feasible to.
-Chris
--
Chris Weyl
Ex astris, scientia
15 years, 6 months
Procedure for renaming a package?
by Timothy Selivanow
Since I have to do some updates to my (only, <sigh>) package, I'd also
like to take the opportunity to change its name to something that fits
the python naming guidelines better. Currently it is called 'pysvn',
and I'd like to change it to 'python-pysvn'.
Is there a special procedure for that, e.g. fill out some forms in
triplicate, mail them to some P.O. Box in Indiana, wait 3-6 weeks,
promise my unborn first child to a suspicious gnome-like old man, etc...
Or is it just request the new package, and put in the obsoletes and
virtual provides in the new spec?
Thanks.
15 years, 6 months
Question about how libgcj-devel requires zlib
by Bruno Wolff III
While playing with custom repos I noticed that libgcj-devel requires a
file from zlib-devel that isn't explicitly provided. In a mixed x86_86 / i386
environmentment this requires looking at the file lists to see that
libgcj-devel-4.3.2-4.i386 needs zlib-1.2.3-18.fc9.i386 and that
zlib-1.2.3-18.fc9.x86_64 isn't good enough.
I am not sure if this is actually a bug though and if so, which package
is at fault. I was hoping to get some guidance here on whether or not
this is something I should bugzilla.
15 years, 6 months
