Throwing this out there for anyone interested. Karsten (quaid) has
requested a script that will compare the packages between two
releases. Below is a quick IRC chat we had. I've been busy with
other stuff so I won't be able to get to it right away. The idea of
coming to us is maintainability. Whatever we end up with will end up
in CVS and maintained by us so anyone out there that's good with
Perl/Python/XML sign up. Don't take it if you don't have time to do
it, I already did that :) Whoever wants it go ahead and reply to the
list so everyone knows, and add it to:
If you need any help let me know and I'll point you in the right direction.
======== From #fedora-docs ===========
[15:16:54] * quaid gets an example
[15:18:06] <quaid> and someone did help with that list, which I
just put into a <screen> block
[15:19:30] <quaid> so, you can see a bit of the package info in
there, and the designation of if it is coming in or out.
[15:20:11] <quaid> naturally, it would be cool for it to say what
happened to a package leaving, such as going to Extra, but that
doesn't seem doable
... that info isn't stored anywhere to extract.
[15:20:24] <quaid> so, here is the need, in cascading order:
[15:20:29] <mmcgrath> k
[15:20:31] <quaid> 1. treediff -> a nice list
[15:20:39] <quaid> 2. nice list -> XML list
[15:21:06] <quaid> 3. a nice script that can be run somewhere to
let a clueless editor do this easily
[15:21:10] <quaid> </>
[15:21:49] <quaid> we want to put in the set for each test, etc.,
so it shows the package changes incrementally in that way.
[15:23:25] <mmcgrath> I got'cha.
[15:23:45] <mmcgrath> So what of that stuff would you like the
infrastructure team to do?
[15:26:37] <mmcgrath> quaid: I think I'm following you now, you
just really want some scripts to do all of this stuff automatically
and then stick the
results somewhere for you guys to do some final touches.
[15:27:34] <quaid> mmcgrath: right, although the results could be
a 100% valid XML document (header declaring it as e.g. a 'section'),
and we really
don't need to anything more than XInclude it.
[15:28:45] <quaid> also, a reason for turning to Infrastructure v.
cooking it up ourselves in maintainability ... we want something that
is part of
the formal process and has some support so when e.g. treediff or
something changes, the smarts are there to fix it. :)
[15:29:57] <mmcgrath> I don't think that will be too much of a
problem. We can at least have SOMETHING to you soon. you'll probably
have to get back
to me a few times about how to fine tune it
Michael Schwendt schrieb:
> On Thu, 27 Jul 2006 11:36:58 -0600, Orion Poplawski wrote:
>> Error was: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert
>> certificate expired'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl
>> handshake failure')]
> So, would anyone please give a short introduction on when the OTRS
> ticketing system ought to be used instead of bugzilla?
> What I'm still missing is the announcement for everyone. Which system do
> we use when?
Well, don't ask FESCO, let's ask and kick the proper people:
I'd be interested in the answers, too. I don't really like having two
systems and would have prepared if we (people outside of the
infrastructure group) stick to bugzilla.
my name is pasqual milvaques, I'm a spanish dba and software developer
and I'm going to try to give a hand to you in creating a homepage for
the fedora infrastructure project and in other things I can help.
I have created a draft for the page which I send attached with this
mail. The idea is to have in this page a list of all infrastructure
pieces which are being used with their links and some basic information.
the draft has not all the links, I will review it to add more links that
I have seen in the fedora infrastructure mailing list and (of course)
any link you indicate to me. In the next days I will review it and will
take deeper look to the wiki to search for more information (all this
system is bigger than I expected) and to define the work methodology.
well, take a look to the draft as in it you will find some of my doubts
(what is docs-rawhide? where is nagios?) and make me any comments you
regards and will be in contact
So while dgilmore was rebuilding the builders this weekend I realized
a couple of things:
We need to re-think the cvs situation. Not only have the configs
become woefully out of date with whats on the actual builders, but
upgrades can become difficult when moving from one OS to another
because of incompatibilities. I don't know that we should get rid of
all of it just re-think what goes in it or try to simplify it a bit.
Maybe write a script that runs daily and compares whats in CVS with
what's live? Not perfect but better than what we have. Regardless of
what we do with it we need to figure out where to put CVS because not
everyone has access to lockbox.
I've also been giving more thought to the security/access issue.
While re-doing the accounting system we need to think about ways to
increase security while lowering the barrier for entry to help support
Fedora's infrastructure. We can add much of this to the current
accounting system for testing for when the new system gets built but
I'd like input on this from current infrastructure people and those
that aren't as active but are interested in participating more.
Which brings me to restarting the topic of
officers/leaders/sponsors/whatever. By creating more fine-grained
security on the servers there is less of a need for root access on
those machines. People interested in working on mail, will be in a
mail group and have access to it. Nagios, web, proxy, builders, cvs,
etc, all come to mind of things that can be administered without full
root access. So the question is how do we determine who has root to
what boxes? Should we pick some leaders of Red Hat engineers and
community members to have full root? If so should it be of a set
number, similar to the FESCo? I lean towards this setup because it
allows more people to participate sooner (without having to prove
themselves as much) but it will keep those with full root access to
the box low.
Lot of stuff for one email but it would be nice to get a lot of this
figured out before the next meeting so it doesn't run too long :-D
Is there anyone besides Sopwith (is he still around or already on
vacation?) who can help fix bug 198109? Seems the "initialcclist" in
owners.list is not propagating to Bugzilla. That blocks proper
co-maintainership in Extras.
Im preparing to reinstall the extras builders. I'm after the details and
whereabouts of the kickstart files that were previously used. they will be
getting fc5 installed on them all.