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
Short meeting today. IRC Log attached.
16:03 < warren> meeting time?
16:06 < lyz> yep
16:08 < abadger1999> ready and waiting.
16:08 < abompard> hey there :)
16:08 < warren> mmcgrath said he wouldn't be here
16:08 < lyz> abompard, welcome back
16:08 < abompard> *at last* my internet connection is up
16:08 < abompard> thanks lyz
16:09 < warren> http://fedoraproject.org/wiki/Infrastructure/Schedule
16:09 < warren> How about we just let anybody who has anything new to say, say it.
16:10 < lyz> I'm working on making the shema files for the new account system
16:10 < abompard> lyz: I'll bring myself up to speed on that as soon as I can
16:10 < lyz> ok
16:10 < lyz> I'll email you them
16:10 < abompard> great
16:10 < warren> We can now provide xen guests for your experimentation.
16:11 < lyz> they still need some work
16:11 < warren> Please let me know if you want a xen guest.
16:11 < abompard> noted
16:11 < lyz> I'm hoping to have them done in a week
16:11 < lyz> we'll need a guest then, I assuem
16:11 < lyz> assume
16:12 < abadger1999> warren: Do we need to do our own install into the guests or do you give us a password to get
16:13 < warren> err.. I will be traveling soon, so best ask the team to help you with guests.
16:13 < warren> abadger1999, I installed mercurial and bzrtest, but I didn't add the account system.
16:13 < warren> didn't have time
16:13 < warren> I hoped for quick & easy wiki instructions or the RPM that dgilmore said he wants to make.
16:14 < dgilmore> warren: as soon as i can ill have both done:D
16:15 < dgilmore> warren: the one thing i dont know for sure is all the different groups and what each contains
16:15 * iWolf wanders in
16:15 < warren> sorry, I don't mean to blame, we're all distracted by things outside of this =(
16:17 < dgilmore> warren: its ok
16:17 < warren> lyz, so Fedora Directory Server within that guest?
16:18 < lyz> warren, I think so, I'm going to be testing on openldap
16:18 < lyz> can FDS accept forign schema files?
16:18 < dgilmore> lyz: some
16:19 < dgilmore> lyz i know FDS doesnt like the egroupware schema
16:19 < lyz> do you know why
16:19 < dgilmore> its a little pedantic about the syntax
16:19 < lyz> as long as it is extendable, we'll get it to work
16:20 < warren> OK, someone will setup for you a guest. please let the list know about your needs and progress.
16:21 < lyz> cool
16:23 < abompard> yeah, thanks
16:23 < warren> OK, anybody else have something to report?
16:23 < warren> Or a concern to share
16:24 < warren> mmcgrath, dgilmore, abadger1999: We need to update our infrastructure access and passwords in doc
umentation, and standardize upon a way to encrypt passwords with a set of target keys.
16:25 < warren> And fix the stupid PDU mislabeling
16:25 < dgilmore> just that ive finished most of my list of thinsg
16:25 < dgilmore> warren: yeah i dont have any of that info since we moved
16:26 < warren> it is spread out and much of it unkonwn
16:26 < warren> unkonwn
16:26 < warren> damn
16:26 * warren smacks himself.
16:26 < warren> Ok, if nothing further new to report, this meeting is over.
Tomorrow, I'll be absent from the FESCo and infrastructure meetings:
I'm a voluntary fire fighter in my hometown and we have a training
exercise tomorrow evening (MET) right at the same time as the IRC
Xen Server and Network Tracking
Please track Xen guests and network assignments on this page.
I have a template xen guest installed with yesterday's rawhide on
/dev/mapper/VolGroup00-template of xen1. The template has its
networking disabled. If you copy the template to create another guest,
get an IP address assigned, then add it to
/etc/sysconfig/network-scripts/ifcfg-eth0 before enabling it.
Although I am not sure how useful it is to use this template, given that
you can use anaconda to install a new xen guest within minutes.
Any ideas of the best way to make an image file of this LVM volume so
that we can easily copy it to the xen2 server?
Dudes, I have good news : my internet connection is back.
As soon as I'm done with the backlog (9000+ emails, spamassassin filtered it
out to 2500+, yum yum) I'll be able to resume working with you. I'm looking
forward to it.
http://aurelien.bompard.org ~~~~ Jabber : abompard(a)jabber.fr
"Science sans conscience n'est que ruine de l'âme." -- Rabelais
I'm working on a script to parse owners.list and import it into the new
PackageDB. So far, the biggest hurdle has been that some email
addresses in owners.list do not match with the email addresses in the
accounts system. I've tracked most of these down with a few exceptions
extras-qa  fedoraproject.org: This is the initial qa contact that is
entered into bugzilla for bugs on a package. I'd like to discard this
information and start fresh in the new packageDB. If a qa-contact
should be applied to the package then it should be entered for each
package, otherwise there will be no qa-contact. If we are currently
using extras-qa to do something useful please let me know so we can work
out what's sane to do here.
extras-orphan  fedoraproject.org: For orphaned packages. I think
we're going to create an orphan account to fill this.
fedora-perl-devel-list  redhat.com: It appears that perl packages are
adding this mailing list to the initial CC list. In the new packageDB,
the plan is to have SIG-groups that can watch a package. People in the
SIG would get emailed whenever the SIG was modified. Would this be an
acceptable alternative or do people want mail to go specifically to the
jylitalo  iki fi: xplanet
This package looks like an import from fedora.us times and the rebuilds
in FE seem to have been done by someone other than the packager. I'll
ping the packager to see if he wants to orphan it.
Unknown initialCClist members:
aaron.bennett  olin.edu: ifplugd
carsten  dvdisaster.de: dvdisaster
gary_lerhaupt  dell.com: dkms
jwz  jwz.org: xscreensaver
loic  gnu.org: cal3d, openalpp, osgal, osgcal, poker-engine,
ludovic.rousseau  gmail.com: pcsc-lite, pcsc-perl, pcsc-tools
mystilleef  gmail.com: scribes
pmatilai  laiskiainen.org: apt, fedora-package-config-apt, synaptic
It looks to me as though these are email addresses for upstream
maintainers and interested parties within the Fedora Community that have
no active packages. In the current packageDB schema, all the references
to people ask for further information from the accounts system. This
should help with the current out-of-syncedness we see between
owners.list/bugzilla and the accounts system. However, it causes
problems when we want to add people to the initialCClist that are not in
the accountsDB. I see several possible solutions:
1) Allow packagers to add an account for the upstream person in the
accountsDB. This account is a member of no groups and has no rights but
will be notified of changes to the Fedora Package.
2) Have the upstream person register their bugzilla email address in the
accountsDB and sign up for the packages they want to watch themselves.
3) Allow arbitrary email addresses into the packageDB watchers field
instead of accountDB id's.
Note that the watcher role currently watches more than just bugzilla.
(It is also informed of package commits and other per-package
I think #1 is closer to what we have now than the other two but upstream
maintainers may not want to get cvs commit messages for spec file
changes. Maybe defining a bugzilla-watcher group combined with #1 would
be the best choice?
If you have an idea feel free to send it, otherwise I'll forge ahead on
the path I've outlined.
I've been working on the schema files, but it's turning out that we really do need an enterprise oid. Will someone on the RedHat side fill out the form at http://www.iana.org/cgi-bin/enterprise.pl and give me the OID that results so I may put it in the schema files?
Is it possible that someone take logs at the meeting and send them
out, we should
possible get a BOT that does this that just sits in the channel loggin
the meetings then
send out the meeting logs.
This way I still have a feeling of what is gonig on,