Heads up: OCaml 3.11.0 rebuild for Fedora 11
by Richard W.M. Jones
Just a note that I'll be building OCaml 3.11.0+beta1 in Fedora 11
(future Rawhide). This will break everything OCaml-related for a
little while, since it's known that some packages don't build with the
new OCaml compiler yet.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
15 years, 6 months
Proposal - "Slow updates" repo
by Casey Dahlin
There's been a lot of talk about a stable release lately. Most agree
that its not what Fedora does best and not something that would be
natural for us to do. I have a sort of middle-ground proposal that might
be easy enough to implement that we could try it out.
Currently, when a packager has an update, he runs "make update," and
bodhi goes and grabs the package out of koji and places it in the next
mash of the updates-testing repo (Luke, please shout when I start
getting this wrong). Then, bold subscribers to updates-testing install
it, check it out, and if two people report in that it didn't eat their
brane, it goes into the regular updates repo. That slim sanity check
prevents a whole helluva lot of breakage, but isn't a very broad testing
of the package.
What I propose is having another repo called updates-slow. Like updates
testing this repo ships with Fedora but is disabled and hidden by
default. Interested parties would have to manually enable it, and
disable the regular updates repo. updates-slow would relate to updates
in a similar way that updates relates to updates-testing: packages would
go into it after people getting the general Fedora updates seem to be
ok. The criteria here would have to be much harder than the two karma
points it takes to move out of testing, I would suggest the people
interested in this feature form a group that decides what the entry
policy should be.
The advantage is that this is fairly cheap to set up. Bodhi would need
some level of changes (Luke, what do you think?) but there's no
branching. We're basically just taking the ability which already exists
in yum to selectively take updates and providing a system to
collaboratively exploit this mechanism.
Not branching, however, also creates a disadvantage: with no ability to
create new packages, the slow repo can't take newer fixes without taking
an entire update. The slow repo must consume updates from Fedora in
whole packages; they don't have patch-level control over incoming
changes. Also, the slow repo has to synchronize at release time; you
can't have a late-F9-with-bits-of-F10 offering (hopefully though the
base set is the peak of mainline Fedora's QA).
If the people interested in a stability feature are willing to help
govern and maintain this repo, and help with the bug load (we can't just
dump bugs against backdated versions directly on the maintainers), then
it could go a long way to meeting their needs.
Thoughts?
--CJD
15 years, 6 months
Rawhide boot failure (2008-11-15)
by Chris Adams
Is it just me, or does today's i386 rawhide not boot? I tried booting
from boot.iso in a KVM and PXE booting, and in both cases I get:
Failed to execute /init
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
The x86_64 image appears to work (anaconda starts up anyway).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
15 years, 6 months
sudo and secure-path
by Karlos Smith
I'm not usually one to reopen cans of worms, but I must say that I'm not
happy about the way that secure-path is working in the new sudo build.
As I mention in the BZ I filed
(https://bugzilla.redhat.com/show_bug.cgi?id=471603), *adding* /sbin
/usr/sbin and /usr/local/sbin to the path when sudoing root makes sense,
but hardcoding the path has messed me up. I have scripts that I allow
non-root users to execute through sudo without a password, I don't put
those scripts in any of the *bin dirs, but the script dir is in the
users $PATH.
So in order to prevent people from having to type the occasional
"/sbin/", my users (and I, for I use these scripts as well) now have to
frequently type much longer paths to execute these scripts.
And while it was possible for people to add to their path to work around
the previous issue, I'm SOL, because there's no way to work around
"secure-path".
Is this really the right thing to do?
--
Karlos Smith
Red Hat Global Services
kasmith(a)redhat.com
+1 361 649-6255 c.
15 years, 6 months
Release Candidates?
by G.Wolfe Woodbury
I can see several spins set up for release candidate status. Just no
checksums yet.
Is there a page/list somewhere that shows these statuses?
--
G.Wolfe Woodbury
15 years, 6 months