Things aren't looking so hot. It appears the CVS volume group is not able to
assemble correctly, and Matthew Galgoci has been doing deep level fsck's. He
suspects we'll wind up with file system hamburger though :/
At this point it may be best to rectify why we got filesystem scribbles,
reinstall and restore from backup. The CVS commits list should show what
changes were made after the last backup.
Release Engineer: Fedora
-------- Original Message --------
Subject: fedora.phx changes needed
Date: Thu, 16 Nov 2006 15:32:46 -0500
From: Warren Togami <wtogami(a)redhat.com>
1) Please confirm that these IP's are not already taken, then assign:
2) New Domains and IP's
Port forward TCP 8887, 8888 and 8889
xenbuilder2.fedora.redhat.com (new external IP)
xenbuilder2.fedora.phx.redhat.com (new internal IP)
3) Remove hammer1 and hammer3 from both internal and external IP's and
addresses. Remove port forwards on these IP's.
4) FYI: hammer1 hardware is becoming xen3. You may want to update labels.
---------- Forwarded message ----------
From: root <root(a)fedoraproject.org>
Date: Nov 17, 2006 8:40 AM
Subject: SMART error (FailedOpenDevice) detected on host:
This email was generated by the smartd daemon running on:
host name: cvs-int.fedora.redhat.com
DNS domain: fedora.redhat.com
NIS domain: (none)
The following warning/error was logged by the smartd daemon:
Device: /dev/sdf, unable to open device
For details see host's SYSLOG (default: /var/log/messages).
You can also use the smartctl utility for further investigation.
No additional email messages about this problem will be sent.
For those that missed today's IRC meeting, here's a brief package DB
There was a lot of talk at the Fedora Summit about things that directly
impact Infrastructure. One of the changes is that the buildsys and
package DB need to be pushed forward in order to enable the Core +
Extras merge. From the information given at the summit, I think we're
going to have to do some revising of the PackageDB schema to make it
handle the data that the release team will need.
Since I almost have an importer for the current Extras owners.list and
cvs modules information, my plan is to go ahead with creating the
packageDB with its current schema and then have Jesse Keating and others
look at it and tell me what things need to be added (where to tie in
buildsystem ACLs, how to enable inheritance of collections, etc). I'm
going to try to finish the initial work between now and Monday night so
that Jesse can begin looking at it early next week.
At that time we should also have enough of a base that we can start
recruiting people to work on individual aspects of this project. Off
the top of my head, I think we can use:
* one or two web designers to either mockup or directly write "kid
templates" for the web front end to the DB.
* Some people to write importers for other information that should go
into the db (for instance, Christian is working on importing the package
review ticket information into the database.)
== Tie in's with our Other Infrastructure Projects ==
* Some people who have an interest in the buildsystem to think of how
we'd like to interface the packageDB to the buildsys. What information
do we want to keep track of from it? What things do we want to kick off
from the packageDB? Note that we may be using plague in the next
generation buildsystem or we may be using a brew hybrid. This hasn't
been decided yet.
* The next generation account system is coming along. We need to
decide if we're going to port the python APIs from the old account
system over to the new one or write a new python API. Then the code has
to be written to enable this and we have to port the packageDB code to
any changes that were made.
I've finally been able to convert all extras package modules/branches (from
FC3 and up) to git, much in the same layout as dist-hg (each release "branch"
being its own standalone repo (complete with inherited history from devel/
branch at split time))
I haven't yet started modifying Makefiles and plague to handle getting a
checkout of a package from a tag and building it. That will probably come
Some interesting comparisons:
Time to convert from CVS to GIT:
Time to convert from CVS to HG:
Size of dist-git (with full repack -a -d):
Size of dist-hg (no extra processing):
None of the above are really deciding factors in what to use, just some
interesting anecdotal observations.
Release Engineer: Fedora
So the doc guys have a script they run that produces release notes on
the wiki. It does a series of posts. The problem is there's a
feature in the wiki to prevent spamming. Does anyone know if we can
allow certain namespace on the wiki or certain users to post as much
as they want? If not we may just have to turn it off for a short
period of time while they run the script before releases.
Infrastructure team has ratified these requirements for a
publictest[1-9] address running sshd.
1) Must use Denyhosts.
2) NO PASSWORDS in authentication, only ssh keys.
3) Infrastructure team must explicitly approve it.
I have recently been sponsored and am unable to request a package build.
I have added my e-mail address to ~/.plague-client.cfg (and owners.list
for the packages), and my CVS, fedora account system and bugzilla access
all work fine. ~/.fedora.cert, .fedora-server-ca.cert and
~/.fedora-upload-ca.cert are all present.
About 6 days have passed since I first attempted a build, so it
shouldn't be a synchronization issue.
When submitting a plague build job I get the following:
"Server returned an error: Insufficient privileges."
I have opened an Fedora Infrastructure ticket for this (wasn't sure if
this is the correct action, hence the mail :-) ). It's available at:
The packages in question are espeak and flite.
Please help? Thanks!
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.
CSIR E-mail Legal Notice
CSIR Copyright, Terms and Conditions
For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.