On 10/15/2012 02:40 PM, Marc Curry wrote:
On Mon, Oct 15, 2012 at 1:59 AM, Gordan Bobic<[email protected]> wrote:
On 10/14/2012 11:05 PM, Marc Curry wrote:
I was excited to see this project, but I'm wondering if anyone is
still maintaining the distro? The mailing list seems a little quiet
(the last post is March 2012), and when I use yum for any package
maintenance, it seems the repo hasn't been updated since June 2012:
Not using downloaded repomd.xml because it is older than what we have:
Current : Sun Jun 3 03:42:34 2012
Downloaded: Sat Mar 24 17:18:33 2012
The distro is certainly not abandoned, if that's what you are asking. It's
just that both myself and the other maintainer have been rather busy in the
past couple of months with these things called "day jobs", which is why we
haven't yet rebuilt the latest upstream updates.
I completely understand. Its very good to hear that redsleeve is
alive and well!
Thank you. :)
I'd like to preface all the below feedback with a
*huge* thanks for making this distro available!! Its exactly what I
was looking for (replacing an aging web/mail server with a raspberry
pi).
It also turns out that the B-model Pis manufactured from today will be
made with 512MB of RAM instead of 256MB. Definitely a step in the right
direction, but running off an SD card is still going to be painful in
most cases. See SD/CF/USB flash module performance benchmark results I
gathered here:
http://www.altechnative.net/2012/01/25/flash-module-benchmark-collection-sd-cards-cf-cards-usb-sticks/
(Link at the bottom of the article, scroll down for the IOPS performance
table.)
Putting together a set of
scripts that fetch the latest upstream updates and rebuild the new ones
daily is on my todo list.
That would be ideal. The easier and more automated it is, the better.
Let us (the users) know if/how we can help, besides just submitting
bug reports to the list.
Bug reports are good. Please forward them to the list for now. I am
planning to put up a bugzilla for bug tracking.
Note, however, that bugs that are also affecting x86 (test on
CentOS/Scientific Linux) should probably be reported upstream as they
will be affecting both the upstream and the derived distributions.
I will also happily accept any ARM specific patches. :)
The primary advantage of this distro, for me, is familiarity (I use
distros in this family all the time), but if it only gets updated once
in a blue moon...it won't be useful to begin a project using it for a
home server.
The upstream distro only gets updated relatively infrequently - that's kind
of the whole point; the goal posts don't keep changing.
I agree if you mean the infrequent 6.x mileposts, but there are fairly
frequent bug/security updates released that make the upstream distro
"enterprise quality", as well. If its running in a protected/isolated
environment, that's one thing. Using it, as in my case, as a server
connected to the Internet, is another.
True, but in reality, very few of those exploits are actually applicable
to a fairly vanilla system. In a lot of cases they tend to be applicable
to somewhat obscure use-cases.
Of course, if you have a particular security update in mind that is
affecting you, I'm happy to fast-track the update out to the repository.
If there are any packages you would like to see updated sooner rather than
later (e.g. specific bugs you are tripping over or potential security
concerns), do tell - I'll see what I can do to get them updated to the
latest upstream versions ASAP.
The first one that crossed my mind: labeled as a "critical security
update", xulrunner (used by Firefox) was very recently released. I
understand this is not really a concern for typical server function.
There were also about 6 "moderate" and about 4 "important" security
updates in the last month or so, not counting bug fixes.
Are the xulrunner issues applicable without Java or Flash?
Either way, I'll see what I can do to get a new Firefox rolled out
sooner rather than later.
I'm less concerned about minor bug fixes. Ideally there is a script
that automates the update, but in lieu of that, maybe the way to go is
to establish a severity level threshold at which updates are released,
to fix the potentially nasty stuff?
The process is manual at the moment, so if you, or anyone else, has a
specific issue in mind, I'm happy to get the updated packages rebuild
and pushed to the repository. Once the automated daily build process is
in place, most of this will happen automatically, and the only manual
rebuilds/updates will be the ones that fail to build out of the box.
Unfortunately, these have been the ones I've been looking at of late,
because they include some of the important stuff (glibc, kernels), and
those packages also tend to be the ones that take ages to build (and
thus ages to debug the build failure of - and don't even get me started
on OpenOffice/LibreOffice).
Gordan
_______________________________________________
users mailing list
[email protected]
http://lists.redsleeve.org/mailman/listinfo/users
