I have just updated the October FreeMedia List on the page (
It is getting bigger and bigger :-) and I am finding it difficult to
sort out the duplicates, will do so as I get more time..
Please mark the Requests you have accepted on the page, and I'll also
request all who have listed themselves on the LocalContact page to
mark the requests in your area.
I am running with little short of time (again) these days and i'll try
to cover up things..
[PS. Fell free to mark duplicate/multiple names If you find]
>I recently got a offer from a local ISP . They want me to build and
maintain a low cost linux server which will manage and distribute
bandwidth as per client package or scheme. Moreover it will >keep
details about bandwidth used by clients, online time, download and
upload details etc. The ISP is using a 8mbps connection as input.
>How can I accomplish this job? Currently I am trying Squid to distribute the bandwidth. But I dont want to use a proxy server.
Why don't you use a router?
Forwarding from the packaging list because a prototype could perhaps be
easy to cook up :)
-------- Original Message --------
Subject: [Fedora-packaging] time for a review-oh-matic?
Date: Fri, 3 Oct 2008 12:21:04 -0700
From: Chris Weyl <cweyl(a)alumni.drew.edu>
Reply-To: Discussion of RPM packaging standards and practices for
So, building on the spirited debate going on with respect to a
suggested review template, is it time for a review-oh-matic type
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
==> 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
Ex astris, scientia
http://www.gutenberg.net - Fine literature digitally re-published
http://www.plos.org - Public Library of Science
http://www.creativecommons.org - Flexible copyright for creative work