collab1.fedoraproject.org is up and running. Yahoo! So whats missing?
Well, it doesn't actually do anything yet. Plans for it include
1) gobby (its AMAZING)
2) pastebin or something like it (also amazing)
So who wants to set up what? Luke, you'd mentioned you might be able to
get gobby up sometime this week / next. Is that still the case? If so
I'll open a ticket and assign it to you.
My only request for pastebin is that we use something that has an
upstream, and that we don't modify it other then to create a template for
that good ol' fedora look and feel.
If someone wants to do a part (paulo, you'd mentioned some interest) just
let me know. These types of servers also fall under "tools" so you'll
need to be part of the sysadmin-tools FIG.
15:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Who's here?
15:00 < mmcgrath> Who's here?
15:00 * iWolf is here
15:00 < ivazquez> Pong.
15:00 -!- petreu [n=peter@fedora/Standby] has quit Read error: 104 (Connection reset by peer)
15:00 * dgilmore
15:00 < dgilmore> skvidal: that was for you
15:00 < skvidal> what
15:00 < skvidal> oh
15:01 * nirik is lurking in the spectator bleachers.
15:01 < skvidal> sorry
15:01 < skvidal> doing other stuff
15:01 < abadger1999> here
15:01 -!- caillon [n=caillon(a)188.8.131.52] has left #fedora-meeting ["Leaving"]
15:02 * ricky
15:02 < yingbull> ping
15:02 < yingbull> pong, whichever
15:02 -!- notting [n=notting@redhat/notting] has joined #fedora-meeting
15:02 -!- MrBawb [i=abob(a)guppy.drown.org] has joined #fedora-meeting
15:02 < ricky> Bad time for me to start eating a mango :(
15:03 < jcollie> ping
15:03 < mmcgrath> heh no worries.
15:03 * f13
15:03 < mmcgrath> alrighty, lets get started
15:03 -!- petreu| is now known as petreu
15:03 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets
15:03 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=as...
15:03 < zodbot> mmcgrath: http://tinyurl.com/2hyyz6
15:04 < mmcgrath> so first ticket
15:04 < mmcgrath> .ticket 347
15:04 < zodbot> mmcgrath: #347 (Set localtime on all our servers to UTC) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/347
15:04 -!- daMaestro [n=jon@fedora/damaestro] has joined #fedora-meeting
15:04 < mmcgrath> dgilmore: any word on that?
15:05 -!- wolfy [n=lonewolf@fedora/wolfy] has left #fedora-meeting ["If you don't know what procrastination is just look up the definition tomorrow."]
15:05 < dgilmore> mmcgrath: I was thinking we should be able to use puppet to push out the timezone files to each box
15:06 < dgilmore> and then reboot everything
15:06 < mmcgrath> <nod> that works for me, right now its not puppet managed but I don't see any reason why it shouldn't be.
15:06 < jcollie> i do that on my boxes at work, although not with puppet
15:06 < dgilmore> i think using puppet will make it much simpler to do that lagging in and running commands on each and every box
15:06 < mmcgrath> dgilmore: I remember you saying you'd be doing it during a trip or something, when was that scheduled for?
15:06 < dgilmore> mmcgrath: ill be in boston all next week
15:07 < mmcgrath> Should we schedule some outage for it?
15:07 < dgilmore> so i figured id do it about midnight wednesday or thursday
15:07 < dgilmore> yeah we should
15:07 < dgilmore> lets schedule it for thursday
15:08 < mmcgrath> sounds good to me, mind sending out an outage notification? I'll make sure I'm around then as well, shouldn't take too long.
15:09 < f13> thursday works for me.
15:10 < mmcgrath> k, then we'll get that all setup..
15:10 < mmcgrath> anyone have any concerns about that before moving on?
15:10 < jcollie> not from me
15:10 < dgilmore> ill send out the notice
15:11 < mmcgrath> thanks
15:11 < mmcgrath> alrighty, next ticket.
15:11 < mmcgrath> .ticket 365
15:11 < zodbot> mmcgrath: #365 (mailman setup (project/hosted)) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/365
15:11 < mmcgrath> jcollie: want to take the floor on that one?
15:11 < jcollie> sure
15:11 < jcollie> i think we're ready to go, except for documenting a SOP
15:12 < jcollie> which would be SOOO much easier if we were on mediawiki but that's another topic
15:12 < mmcgrath> heheheh
15:12 < mmcgrath> cool
15:13 < mmcgrath> jcollie: once the sop's done just close that ticket and you have a huge thankyou from us and a bunch of other fedorahosted users, that will be most helpful to finally deploy.
15:13 < jcollie> there are a couple of lists out there so it wouldn't hurt for people to subscribe and start sending some mail through
15:13 < mmcgrath> alrighty, next ticket
15:13 < mmcgrath> .ticket 270
15:13 < zodbot> mmcgrath: #270 (Fedora Wiki allows editing raw HTML) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/270
15:13 -!- viking-ice [n=johannbg(a)dsl-149-97-225.hive.is] has joined #fedora-meeting
15:13 < mmcgrath> ricky: paulobanon: I'm not sure what the latest is on that to be honest.
15:13 -!- jnettlet__ [n=jnettlet(a)c-76-118-159-90.hsd1.ma.comcast.net] has joined #fedora-meeting
15:13 -!- viking-ice [n=johannbg(a)dsl-149-97-225.hive.is] has quit Connection reset by peer
15:13 < mmcgrath> Maybe its something we should't put much work into until after the wiki migration?
15:14 < ricky> Sorry for letting that sit - hopefully, it won't be a problem anymore soon :)
15:14 < jcollie> how fast do we think we can move to mediawiki?
15:14 < ricky> We have a pretty nice-looking setup already, thanks to mizmo.
15:14 < mmcgrath> jcollie: well, I've got to go around to the teams and make sure everyone's ok.
15:14 < mmcgrath> here's the hangups that I still know about
15:14 < ricky> I assume that we want FAS integration from the get-to?
15:14 < ricky> **get-go
15:14 < mmcgrath> 1) docbook (this is a must)
15:14 < mmcgrath> 2) FAS integration
15:14 < mmcgrath> 3) Make sure the art attachments migrated properly.
15:15 -!- fcrippa [n=fcrippa(a)host75-233-static.28-87-b.business.telecomitalia.it] has joined #fedora-meeting
15:15 < mdomsch> howdy
15:15 < mmcgrath> mdomsch: howdy.
15:15 < mmcgrath> so those are the big hanups.
15:15 < mmcgrath> ricky: mind taking the Meeting keyword out of that?
15:16 < ricky> mmcgrath: Sure thing.
15:16 < mmcgrath> alrighty
15:16 < mmcgrath> next ticket then.
15:16 < mmcgrath> .ticket 395
15:16 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/395
15:16 < mmcgrath> I don't think there's been any new progress on that but thought I'd check.
15:16 < jcollie> not much has happened lately...
15:16 < mmcgrath> jcollie: anything?
15:16 < mmcgrath> no worries, we've got time to work on that one.
15:17 < jcollie> but we've got 1+ month to get that into shape
15:17 < ivazquez> Do we have Asterisk/Callweaver/w/e up yet?
15:17 < mmcgrath> Ok, so thats all the tickets. I wanted to switch over to something that some of us have been working pretty hard at this week.
15:17 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Buildsystem.
15:17 < f13> que the dramatic lights
15:18 < mmcgrath> ivazquez: yeah, Asterisk is up but not fully deployed (no fas integration, no mailboxes, etc) but we have had meetings on it.
15:18 < jcollie> ivazquez: yes -- asterisk1 is up and running but it's still in a beta state
15:18 < mmcgrath> ok. so the buildsystem
15:18 < mmcgrath> for those of you that haven't seen the nagios alerts we've had 8 outages of the buildsystem since monday.
15:18 < dgilmore> :(
15:18 < mmcgrath> coming at all hours of the day or night.
15:18 < mmcgrath> Its not been fun.
15:18 < mmcgrath> so whats been done?
15:18 < jcollie> yeah that blows major chunks
15:19 < mmcgrath> well, we've spent some time getting the database in better shape.
15:19 < mmcgrath> we've made the website not hit the rpmfiles table which made a huge difference in general load on the db, but didn't help the spikes.
15:19 < mmcgrath> we added a robots.txt file, banned the soc search engine from crawling it.
15:20 < jcollie> do we want to ban all search engines?
15:20 < f13> and we threw 2K tasks at it
15:20 -!- ChitleshGoorah [n=chitlesh(a)184.108.40.206] has joined #fedora-meeting
15:20 < dgilmore> we should add those indexes to the task table
15:20 < mmcgrath> jcollie: until I can sleep through the night we do.
15:20 -!- knurd is now known as knurd_afk
15:20 < mmcgrath> <nod>
15:20 < mmcgrath> there's an index we got rid of and an index we're looking to add.
15:20 < mmcgrath> .taskload
15:20 < zodbot> mmcgrath: Tasks running - Open: 38 Total: 253
15:20 < abadger1999> (two indexes to add)
15:20 < f13> it's been moving very fast today
15:20 < f13> as far as chewing through open tasks
15:21 < mmcgrath> dgilmore's also working on moving the hub away from the website.
15:21 < mmcgrath> /koji/ is the website and /kojihub is the xmlrpc interface.
15:21 < f13> new repo tasks are faster than ever.
15:21 < f13> close to 10 minutes now
15:21 < f13> http://koji.fedoraproject.org/koji/taskinfo?taskID=457867
15:22 < dgilmore> f13: still to long i think but its better
15:22 < mmcgrath> interestingly we've seen many times where the hub is nice, peppy and responsive and the website isn't, but since they're both on the same box right now, there's no way to stop or restart one without the other.
15:22 < f13> dgilmore: it's only 4~ minutes for the query before it hands it off to the builder to createrepo
15:23 < f13> dgilmore: the fact that we could get a 13 minute newRepo task done, while the builders have 300~ queued tasks is pretty amazing in my book
15:23 < mmcgrath> I think there's still a lot of work todo but with the exception of some timeouts this morning (very short lived) from nagios to check swap, I've not seen any actual outages yet.
15:23 < f13> yeah, today has been quite nice
15:23 < f13> I think splitting the hub from teh website is a good step
15:23 < mmcgrath> f13: how long did you say it takes to do the whole signing process?
15:23 < f13> and I'd like to take that further by having the repos stuff done by something else too
15:24 < mmcgrath> and is that something that blocks on disk IO or koji io or both?
15:24 < f13> mmcgrath: signing of packages depends on how many packages, but can often take a couple hours
15:24 < f13> mmcgrath: both.
15:24 < dgilmore> f13: im seeing about 17 minutes on sparc http://sparc.koji.fedoraproject.org/koji/taskinfo?taskID=50738
15:24 < f13> signing does in this order:
15:24 < f13> query koji for existing cached or written out signatures for a set of biulds.
15:24 < f13> copy unsigned rpms to a work directory
15:24 < f13> rpm sign the rpms
15:24 < f13> import the signed headers into koji
15:25 < f13> ask koji to write out copies of the packages with the signed headers to the koji directories.
15:25 < dgilmore> f13: can you approve my announcement please :)
15:25 < skvidal> f13: I looked at this step in koji
15:25 < skvidal> [15:20] <f13> rpm sign the rpms
15:25 < f13> the query and the import take a long time, but then again so does the copying/signing if there ar ea lot of builds.
15:25 < skvidal> does it just call rpm --resign with xargs?
15:25 < f13> skvidal: 'in koji' ?
15:25 < f13> the signing doesn't happen in koji
15:25 < skvidal> well, I looked to see where it occurred
15:25 < mmcgrath> f13: Also I put in a bug to koji to hash the tasks directory, hopefully that will help us some.
15:25 < skvidal> and it doesn't seem to be called anywhere
15:25 < skvidal> ok
15:26 < skvidal> that's what I thought was going on
15:26 < skvidal> so i'm not losing my mind
15:26 < f13> skvidal: signed_unsigned is a terrible terrible script in the releng git repo
15:26 < skvidal> okay, I kinda got that feeling
15:26 < skvidal> thanks
15:26 < f13> it's slated to be replaced by sigul, although some parts of it will survive as a client of siguls to query koji for what neesd to be signed.
15:27 < f13> sign_unsigned came from inside RH
15:27 * skvidal is shocked to hear that
15:27 < mmcgrath> heh
15:28 < mmcgrath> alrighty so thats really whats been going on there.
15:28 < mmcgrath> its been sucking up a lot of our time this week but hopefully some of our problems can be bandaided until the permanent fixes can be put in. Koji's been deployed for almost a year now, there's still a long way to do.
15:28 < mmcgrath> koji is a journey, not a destination :)
15:29 -!- kital [n=Joerg_Si@fedora/kital] has joined #fedora-meeting
15:29 < mmcgrath> alrighty, so thats really all I have that I really wanted to talk about this meeting so lets open the floor.
15:29 < ricky> Wow, only one year.
15:29 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor
15:29 < smooge> just as long as cooker isnt the destination
15:29 -!- jnettlet_ [n=jnettlet(a)c-76-118-159-90.hsd1.ma.comcast.net] has quit Connection timed out
15:29 < mmcgrath> Anyone have anything they'd like to discuss?
15:30 < jcollie> i've been working on a tg based openid server for a day or so
15:30 < ricky> jcollie: Oooh, that'd be really handy in FAS!
15:30 < mmcgrath> jcollie: how's that going? It'll be nice to have some more openid expertise around here.
15:30 < jcollie> so it should be pretty easy to use your fedora id to log into stuff
15:30 < ricky> The provider that I have there is hideous (and probably only a partial/incorrect implementation of the spec)
15:30 < jcollie> i've had a couple of successful logins with it but somethings broken right now
15:31 < jcollie> i'm using the python-openid libs so we should be good as far as standards go
15:31 < daMaestro> +1 on openid
15:31 -!- spoleeba [n=one@fedora/Jef] has quit "Leaving"
15:31 < daMaestro> i'd love for FAS users to be able to login to the unity stuff
15:31 < lmacken> awesome.
15:32 < lmacken> jcollie: did you get the nested arg stuff working ?
15:32 < ricky> I'm curious as to how you're testing it.
15:32 < jcollie> lmacken: yes, thanks for the help
15:32 < GeroldKa> ping kanarip
15:32 < lmacken> great. no problem
15:32 < kanarip> GeroldKa, pong
15:32 < abadger1999> jcollie: What are your plans for that? Separate server? Integrate into FAS2 if we're interested (We are!)
15:32 < ricky> I think I used http://openidenabled.com/resources/openid-test/diagnose-server, but it might not be the most up-to-date/complete.
15:33 < daMaestro> i do have a question about my upcoming attempt to migrate everything from moinmoin to zwiki; am i just wasting me time? would it at least be interested to see how zope handles our current data set?
15:33 < daMaestro> s/interested/interesting/
15:33 < jcollie> abadger1999: it used the tg identity stuff so we should be able to plug in a fas identity provider
15:33 < jcollie> er uses
15:33 < ricky> jcollie: Ohh, so it's a client, not a provider?
15:33 < jcollie> no it's a provider
15:33 < ricky> Or it could be both.. hmm.
15:34 < jcollie> we would need to write a separate consumer
15:35 < jcollie> code is here: http://jcollie.fedorapeople.org/samadhi.git/
15:35 < jcollie> i'll probably request hosted space soon
15:35 < ricky> abadger1999: Do you know if we can have multiple auth providers in a TG project?
15:35 < lmacken> jcollie: great name :)
15:35 < jcollie> lmacken: thought you'd like it
15:36 < abadger1999> ricky: I think the web app only knows about a single provider.
15:36 < jcollie> dl the code and look at the logo i ginned up quick
15:36 < abadger1999> That provider could get information from multiple sources, though.
15:36 < ricky> Ah, great.
15:36 < jcollie> eventually i'll need some help prettifying the html... i'm no good a css and all that
15:37 -!- fabian_a [n=fabian(a)84-75-160-95.dclient.hispeed.ch] has joined #fedora-meeting
15:37 < mmcgrath> that will be great to finally get installed.
15:37 < ricky> jcollie: Anyway, when you get a chance, we'd love you to take a look at OpenID in FAS :)
15:37 < mmcgrath> Alrighty, anyone else have anything they'd like to discuss?
15:38 < ricky> I'd be glad to nuke whatever hideousness I put there before.
15:38 < daMaestro> mmcgrath, is my attempts with zwiki futile?
15:39 < mmcgrath> daMaestro: probably
15:39 < daMaestro> ok
15:39 < mmcgrath> unless you want the experience of doing it :)
15:40 < mmcgrath> alrighty, anyone have anything else? If not I'll close the meeting.
15:40 < dgilmore> nothing else?
15:40 < dgilmore> :)
15:41 < mmcgrath> Alrighty!
15:41 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting closed
15:41 < mmcgrath> thanks for coming everyone!
The koji builders don't check back in automatically if they've lost a
connection to the host. I put this script together in an attempt to fix
it, thought I'd post it here before sticking it on the builders. Basic
premis is check if its checked in in 5 minutes (should be waaay more then
enough) unless the box is under high load, then check 15 minutes, might
be over kill.
I'd like to run this check via cron every 5 minutes on each builder.
Anyone have any suggested fixes or against me running this?
Hello TurboGears application developers,
We would like to upgrade the version of Turbogears and SQLAlchemy
present on the Fedora Infrastructure app servers in the near future.
There are a few details that make this an update that I would like to
have people test heavily but overall it should be an easy upgrade for
most people. Details:
TurboGears 1.0.4 is an update that retains TG-1.0.x compatibility. We
don't anticipate any problems with this portion.
SQLAlchemy 0.4 is an incompatible update to SA-0.3.x. TurboGears-1.0.4
includes changes to allow us to use it with minimal porting. Most
Fedora Web apps are using SQLObject so they shouldn't be affected by
this update. python-fedora's tgfas, pkgdb, and smolt use SQLAlchemy.
loupgaroublond has already ported smolt so porting tgfas and pkgdb
should be all that is needed to enable this. I'll be testing ports of
both of those this week.
If anyone has another web app that should be accounted for by this
update, please *holler loudly*.
The two issues I anticipate:
1) FC6 is EOL but app3 is still FC6. I've had success using EPEL-5
packages on FC6/app3 for a few packages in the past but this could be a
bit more involved as TurboGears has a lot of dependencies. Unless we
can plan on obsoleting app3 before we upgrade we'll need to do some
testing on publictest1 as well as publictest10 to be sure that the TG
package and dependencies work on FC6.
2) Because python-fedora has to be ported to the new SA API I also want
to update the code to use the latest TurboGears conventions. This will
allow us to simplify the TG-Auth code quite a bit (I'll be able to get
rid of about half of our code in favor of code that's carried in TG
proper). However, there is the risk that some of the bugs that we fixed
when creating our code will be reintroduced because of this. I'm
thinking especially about the session bug where people would hit the
login page and then not be logged in or hit the logout page but not be
logged out. Since that bug was hard to reproduce reliably, I'll need
other people to help test this.
I'm getting the new python-fedora working on publictest10 right now and
will be installing and testing the new stack on publictest1 soon
(probably tomorrow.) I'll send a note for people to beat on it while I
port over the packagedb.
So a year ago we talked back and forth about what to do for FAS2. We've
spent a LOT of time on getting an easy front end to an LDAP back end. It
was a reasonably heated debate whether or not to use LDAP or postgres for
the back end. I was heavily in favor of LDAP for 3rd party support.
Well, over time its become clear that LDAP is just not very good at doing
groups as we want it to do. We need to have people self-add themselves to
groups, track when they were added, who added them. People can have
different access levels in the group (unapproved, user, sponsor, admin).
LDAP is very geared towards what most people need (someone in charge of a
group and adding people to that group). In an open environment like ours,
we need the whole application process. Its not that LDAP is bad, just not
the right tool for the job.
At the same time, during this last year, we've seen a huge push towards
OpenID adaptation which is something we've always wanted on the front end.
Our turbogears apps have proved to work very well and creating an api to
work with FAS2 is very easy. In light of these things, the big benefit of
having ldap on the back end (3rd party apps) seems less grand and less of
We've been working on FAS2 for almost a year now, and with the deadline
looming the FAS2 dev's (me and ricky) talked about the best way to move
forward. We've decided to stick with an rdms. Fortunately it shouldn't
be too difficult for us.
We had been basing our application on fedora-ds, during the last year
we've seen great changes in this application and how its packaged. This has
made it less stable/desirable as a back end. All signs point to using
postgres on the back end as being both the easier choice and the more
reliable choice based on what we've seen.
I don't like to make decisions like this in a vacuum but time is tight and
I really want to make this deadline.
Thoughts? Comments? Concerns?
So I spent some time last night and produced this:
It's worth noting that the upgrade from Moin1.5.8 -> Moin 1.6.1 took
longer then going from Moin 1.5.8 to the mediawiki install above. There's
still some work to be done (especially a theme). But I think the
conversion to mediawiki is much closer to us now then ever before if we
decide to go this route.
Question 1, do we want to try this conversion?
Question 2, Who is willing to take orders from me with regards to getting
a new template done? (by orders I basically just mean do this, this is
broken, this header didn't come out, we need a css fix here). Just
something functional so it can be presented to the rest of the project and
ultimately redesigned for a crisp look and feel?
Question 3, I did a brief look, there's a lot of stuff that's broken,
mostly tables. Does anyone see anything that came out completely
un-recognized? I'm especially referring to the translated pages.
This is a very rough conversion, but it did convert, most of the text is
there, formatting needs work. I'm still working on the script so send any
suggestions / comments my way.
15:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here?
15:00 < jima> not me!
15:00 < warren> m
15:00 -!- notting [n=notting@redhat/notting] has joined #fedora-meeting
15:01 < mmcgrath> abadger1999: dgilmore f13 gregdek jcollie ivazquez iWolf J5 lmacken mbonnet paulobanon_ paulobanon ricky skvidal spoleeba yingbull PING
15:01 < skvidal> hi
15:01 * dgilmore is here
15:01 < yingbull> pong
15:01 * abadger1999 is here
15:01 < spoleeba> mmcgrath, oh no
15:01 * lmacken is here
15:01 < skvidal> wow
15:01 < jcollie> mmcgrath: i'll brb in the middle of some trouble...
15:01 < skvidal> no one does the /me blank thing
15:01 < mmcgrath> jcollie: no problem.
15:01 -!- mbacovsk [n=mbacovsk(a)44.252.broadband5.iol.cz] has joined #fedora-meeting
15:01 < spoleeba> mmcgrath, im on a con call
15:01 * mmcgrath
15:01 * dgilmore
15:01 < mmcgrath> spoleeba: no worries.
15:01 < skvidal> ah, much better
15:01 * asgeirf *newbie* is here...
15:02 < mmcgrath> asgeirf: welcome!
15:02 < lmacken> skvidal: sorry, I forgot to flush the dircproxy users this week :(
15:02 < jima> ah, fresh meat!
15:02 -!- nim-nim [n=nim-nim@fedora/nim-nim] has quit Read error: 104 (Connection reset by peer)
15:02 < skvidal> lmacken: :)
15:02 < spoleeba> mmcgrath, trying to convince esmf developers to target fedora
15:02 < mmcgrath> Ok, well lets get started. We may have to put some things off until later as some people are busy right now, but thats not a problem.
15:03 < skvidal> spoleeba: just keep the icbm developers from targeting fedora
15:03 < jima> skvidal: i concur.
15:03 < mmcgrath> So lots has happened since our last meeting, because we missed some in there.
15:03 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=as...
15:03 < zodbot> mmcgrath: http://tinyurl.com/2hyyz6
15:03 < J5> pong
15:03 < f13> mmcgrath: howdy
15:03 < mmcgrath> so first ticket up is something notting asked about just today
15:03 < mmcgrath> .ticket 347
15:03 < zodbot> mmcgrath: #347 (Set localtime on all our servers to UTC) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/347
15:03 < mmcgrath> J5: word
15:03 < dgilmore> mmcgrath: did i says id do it?
15:04 < mmcgrath> So when we do finally do this, we'll have cron jobs and all kinds of things to change.
15:04 < mmcgrath> dgilmore: yes you did.
15:04 < dgilmore> we need to look at cron job scheduling
15:04 < mmcgrath> I don't think anyone's against it, but we'll have to make sure we have our plan and do it. Its going to take time to actually do it.
15:04 < dgilmore> mmcgrath: week of 25th ill be in boston. so i think ill do it one night that week
15:05 < dgilmore> so lets work up a plan. and get word out there
15:05 < mmcgrath> dgilmore: solid, that works for me. Go ahead and assign that ticket to you.
15:05 < mmcgrath> We *can* do this in steps if we want. I'll leave that up to you (if you were volunteering for it that is)
15:05 < skvidal> mmcgrath: why do we have to change cron jobs? just to make sure they don't run at peak hours?
15:05 < mmcgrath> skvidal: yeah
15:05 < jima> oh, goody
15:05 < mmcgrath> especially with rawhide builds and stuff.
15:05 < skvidal> I mean have about 14 timezones where people are using fedora readily
15:06 < jima> my cron jobs run whenever
15:06 < skvidal> is there EVER a non-peak hour?
15:06 < f13> yes
15:06 < mmcgrath> For some machines yeah. Not all of them though.
15:06 < jima> skvidal: non-peak US/EU is ideal, i think.
15:06 < f13> koji isn't nearly as busy between 1am -> 4am Eastern
15:06 < mmcgrath> I think many of our important cron jobs are running on the hour anyway, but the buildsystem does have lulls
15:06 < f13> of course, doing rawhide during then makes koji a little busy (:
15:06 < jima> i do believe most of our contributors are in US/EU
15:06 < skvidal> jima: india is growing
15:07 < mmcgrath> skvidal: but the fact taht we're increasingly not having downtime is good :) though it will cause us challenges in the future.
15:07 < mmcgrath> like when to back up what, etc.
15:07 < skvidal> right
15:07 < skvidal> all I'm wondering is maybe we leave the cron jobs alone
15:07 < mmcgrath> dgilmore: were you volunteering for that or did I misread you?
15:07 < skvidal> and see how things are
15:07 < skvidal> but change the system time
15:08 * iWolf slinks into the back
15:08 * mmcgrath thinks dgilmore might have been called away for a bit, we can get back to that if need be.
15:08 < dgilmore> mmcgrath: ill look at how it effects things
15:08 < mmcgrath> dgilmore: excellent, thanks.
15:08 * dgilmore was taking the ticket
15:09 < dgilmore> is slow due to no mouse
15:09 < mmcgrath> next ticket is 365 but jcollie is busy right now.
15:09 < mmcgrath> .ticket 270
15:09 < zodbot> mmcgrath: #270 (Fedora Wiki allows editing raw HTML) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/270
15:09 < mmcgrath> paulobanon_: paulobanon: ricky: ping?
15:09 * mmcgrath hasn't seen them today much, might be busy.
15:09 < f13> skvidal: we'll have to change the rawhide compose cron
15:09 * mmcgrath notes he's going to have a whole special wiki talk after the tickets so we don't have to get into it too much.
15:09 < mmcgrath> moving on
15:09 < mmcgrath> .ticket 302
15:09 < zodbot> mmcgrath: #302 (Moin patches) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/302
15:10 < f13> skvidal: we time that so that there is fresh rawhide content waiting for RH folks to start work, who primarily start in UTC -5
15:10 < mmcgrath> Last I've heard these are still not upstream, I'm going to un-meeting-ize this.
15:10 < dgilmore> mmcgrath: seems sane
15:10 < skvidal> f13: eastern standard tribe
15:10 < f13> yeah
15:10 < mmcgrath> netxt ticket
15:10 < mmcgrath> .395
15:10 < mmcgrath> also one for jcollie
15:10 < dgilmore> f13: we can work it
15:11 < mmcgrath> we actually did have that one working for a bit, expect it to be deployed with the rest of asterisk.
15:11 < mmcgrath> next topic!
15:11 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- The Wiki
15:11 < mmcgrath> so lets have a chat about this.
15:11 < abadger1999> Woo hoo!
15:11 < mmcgrath> I'd like to officially propose we move from Moin to Mediawiki.
15:11 < skvidal> wikis are for losers
15:11 < skvidal> let's go with a big dir on fedora people
15:11 < notting> deep hurting.
15:11 < skvidal> anyone can edit
15:11 < mmcgrath> I've been doing some script conversions and thanks to ivazquez and unicode magic... I've been very happy with the results.
15:11 < jima> notting: deep stabbing?
15:12 < jwb> mmcgrath, how different are the sytaxes?
15:12 < dgilmore> mmcgrath: i want moin syntax
15:12 < mmcgrath> jwb: they're pretty different.
15:12 < jwb> uuff
15:12 < notting> mmcgrath: do we have someone lined up for prettyfication?
15:12 < dgilmore> jwb: i personally hate mediawiki's syntax
15:12 < jwb> does mediawiki have a gui mode that makes that moot?
15:12 < lmacken> any way we can get a rich text editor plugin or something ?
15:12 < mmcgrath> Here's what we have so far - https://publictest1.fedoraproject.org/wiki/Infrastructure
15:12 < mmcgrath> dgilmore: we might just be able to find a plugin for that.
15:13 < dgilmore> when ive had to use it ive had to copy paste and run regexs in vi to get it to do what is simple in moin
15:13 -!- glezos [n=glezos@fedora/glezos] has joined #fedora-meeting
15:13 < mmcgrath> There's going to be bits and pieces to change but for the most part. Its been very good.
15:13 < dgilmore> mmcgrath: if you do ill be a happy man
15:13 * ivazquez apologizes for being late
15:13 < jwb> that looks like arse...
15:13 * glezos too
15:13 < mmcgrath> ivazquez: no worries
15:13 -!- mether [n=ask@fedora/mether] has quit Read error: 113 (No route to host)
15:13 < dgilmore> lmacken: mediawiki does have soem wysiwyg editors
15:13 < mmcgrath> glezos: we're just talking about mediawiki - https://publictest1.fedoraproject.org/wiki/Infrastructure
15:13 < jwb> mmcgrath, maybe some of that doesn't work well from external connections?
15:13 < mmcgrath> jwb: we'll have someone make a template for it.
15:13 < warren> mmcgrath, would mediawiki be any easier or harder to integrate with FAS?
15:14 < jwb> mmcgrath, no, i mean it looks broken
15:14 < mmcgrath> warren: easier.
15:14 < warren> cool
15:14 < mmcgrath> jwb: define broken? as in there's the #! html box at the top?
15:14 < notting> hey, i could read InfrastructurePrivate w/o logging in
15:14 < jwb> mmcgrath, no... let me post a screenshot
15:14 < mmcgrath> warren: unlike moin, mediawiki has a full and documented api (someone has even written a fuse filesystem for it I hear) as well as a good plugin/extensions system.
15:15 < mmcgrath> Aside from dennis hating the markup, is anyone against this?
15:15 < mmcgrath> poelcat: ping (thought you might want to know we're talking about this)
15:15 < skvidal> and an xml-rpc interface iirc
15:15 < notting> i am very ambivalent
15:15 < jwb> mmcgrath, http://jwboyer.fedorapeople.org/Screenshot.png
15:15 < notting> what do our most prominent wiki-ans think?
15:15 < skvidal> notting: eat more roughage
15:15 < ivazquez> I'm not against it, but that script needs quite a bit more tweaking.
15:15 < abadger1999> Do we know how it will scale under load? Will the db be a bottleneck?
15:16 < yingbull> mmcgrath: I'm either way, but if it performs better that's good. Can we QA that?
15:16 < dgilmore> mmcgrath: we using mysql on the backend?
15:16 < iWolf> I just wonder if we will end up with a whole other set of problems.
15:16 * abadger1999 wonders how new install smolt checkins and release day wiki traffic will work out
15:16 < mmcgrath> jwb: thats just the tables not being converted right, its still a work in progress.
15:16 < warren> iWolf, scalability wont be one of them...
15:16 < dgilmore> abadger1999: we should be able to cluster that. and if we are using mysql thats pretty easy to do
15:16 < ivazquez> iWolf: I don't doubt we will. It's just a matter of deciding which set we can live with.
15:17 < yingbull> Would the mediawiki use an existing mysql farm, or would it have its own servers?
15:17 < notting> what do the docs people think?
15:17 < jwb> mmcgrath, ok... i won't go posting that link profusely ;)
15:17 < mmcgrath> yingbull: yes, you can do a search on it now and its way way faster.
15:17 < mmcgrath> jwb: ;-)
15:17 < warren> Has moin ever corrupted itself?
15:17 < mmcgrath> dgilmore: right now yeah. I don't want to put anything else on postgres for the time being.
15:17 < mmcgrath> warren: yes.
15:17 < yingbull> mmcgrath: that means its scales for content size, just wondering about actual load.
15:17 < warren> mmcgrath, how often?
15:17 < mmcgrath> warren depends, why?
15:17 < warren> just wondering
15:17 < dgilmore> mmcgrath: :) i personally much prefer mysql
15:17 < abadger1999> dgilmore: heh. I've had nothing but pain from clustering mysql but it could be how it was being used.
15:17 < warren> mmcgrath, because I would expect that from a non-RDBMS multi-user concurrent system
15:18 < mmcgrath> warren: In fairness though the times it got corrupt we were probably doing stupid things, there's been tickets about badness getting stuck in logs, people's accoutns not working right, etc.
15:18 < dgilmore> abadger1999: ive had success in the past clustering it
15:18 < dgilmore> ive not tried postgres
15:18 < mmcgrath> the other thing I like about mediawiki is we have multiple options for scaling, caching, clustering, etc.
15:18 < warren> and they take security seriously
15:18 < dgilmore> mmcgrath: i do like that
15:19 < dgilmore> warren: they have to its php
15:19 < skvidal> dgilmore: :)
15:19 < warren> I'm guessing we would wall this into its own VM guest with strict selinux policies.
15:19 < mmcgrath> So if I went to other teams and said "The infrastructure team would like to migrate to mediawiki" Thats not a false statement as far as anyone here is concerned?
15:19 < abadger1999> +1
15:19 < warren> +1
15:19 < yingbull> Sounds good.
15:19 < lmacken> +1
15:19 < J5> +1
15:20 < lmacken> what about plone!
15:20 < lmacken> (j/k)
15:20 < EvilBob> yeah thanks
15:20 < mmcgrath> ok, I'll get that conversation started to the various wiki users.
15:20 < skvidal> +1
15:20 < iWolf> +0 (defers to the more active members)
15:20 < glezos> mmcgrath: +1 from the L10n part -- will get back to you with more info in a week, after I meet with the mediawiki i18n folks at FOSDEM.
15:20 < ivazquez> +1
15:20 < mmcgrath> Its not a done deal that we'll move but if we can satisfy all of the teams, it will be.
15:20 < asgeirf> 0 :)
15:20 < glezos> I wonder whether the fact that mediawiki being a very active upstream project will make it harder for us to push any code of ours there
15:20 < mmcgrath> oh!
15:20 < mmcgrath> that reminds me.
15:21 < warren> glezos, nothing can be harder than upstream moin who doesn't want any contributions
15:21 < ivazquez> It might also mean that it's less necessary.
15:21 < skvidal> ivazquez: +1
15:21 < mmcgrath> glezos talked to some of the mediawiki guys and will be talking to them at fosdem (i think) so even before we deploy it, there might be a strong partnership between the Fedora Project and the mediawiki guys. Which is a very good thing and in stark contrast to the relationship with moin-upstream.
15:21 < dgilmore> +1
15:21 < iWolf> mmcgrath: that's a good thing
15:21 * abadger1999 changes his vote to +100 :-)
15:22 < mmcgrath> heh
15:22 < glezos> mmcgrath: the mediawiki guys have been *very* positive in discussing and looking at the issues we'll have, especially in terms of translations.
15:22 < mmcgrath> ok, well, there's not much else to talk about there, I'm going to continue working on that script. I've got to get the tables working right. I'll try to get back with mizmo to see about a better template for that place.
15:22 < glezos> I'll make sure to report back with the meeting's points.
15:22 < mmcgrath> glezos: I'm happy to hear that.
15:22 < mmcgrath> ok, next topic
15:23 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Fedora Hosted.
15:23 < mmcgrath> Two things here.
15:23 < spoleeba> telecon done
15:23 < mmcgrath> first, we now have mtn support on fedorahosted + trac - https://fedorahosted.org/elfutils/browser
15:23 < mmcgrath> spoleeba: excellent.
15:23 < mmcgrath> The next (and bigger thing)
15:24 < mmcgrath> serverbeach (who provides all the hosting for fedorahosted) would like to do a joint pressrelease about fedorahosted.
15:24 < dgilmore> we are taking on sourceforge?
15:24 < dgilmore> :) cool
15:24 < mmcgrath> The last bit that we'd need to get done AFAIK, is the mailing lists which jcollie is extremely close to completing.
15:24 < mmcgrath> https://fedorahosted.org/mailman/listinfo
15:24 < warren> yay!
15:24 < mmcgrath> Once thats available, I think we should do the announcement.
15:24 < mmcgrath> f13: what do you think?
15:24 < warren> mmcgrath, does that mean we have our own MTA? control our own spam filtering?
15:24 < dgilmore> mmcgrath: sounds good
15:25 < mmcgrath> warren: we have that now, just no one's implemented the spam filtering.
15:25 < spoleeba> mmcgrath, i officially have no problem with a joint press-release...do we get to look at it first?
15:25 < f13> hrm.
15:25 < warren> mmcgrath, ok, I'm very interested in that part.
15:25 < mmcgrath> spoleeba: I'm sure we could, max and paul are already involved in all of that.
15:25 < f13> there was one more thing I wanted done before we left 'beta' stage.
15:25 < f13> that was raw webspace for hosted projects.
15:25 * mmcgrath actually wanted to not provide that.
15:26 < warren> we need that if we're going to have a complete upstream hosting solution
15:26 < mmcgrath> f13: how much storage space did you have in mind for that? I figured the wiki would be enough.
15:26 < f13> mmcgrath: wiki eh?
15:27 < mmcgrath> f13: if we're going to do that we need to come up with a solution quick, they want to do the release soon unless thats the sort of thing that doesn't block the official announcement.
15:27 < iWolf> It could always be a later feature enhancement.
15:27 < f13> we have a working model in what seth setup for fedorapeople...
15:28 < mmcgrath> f13: we do have https://fedorahosted.org/releases/p/y/python-fedora/
15:28 < skvidal> we could nfs export across the vpn :)
15:28 < mmcgrath> f13: except that working model uses full shell accounts.
15:28 < mmcgrath> something which would require us to completely re-design our security settings.
15:29 < f13> mmcgrath: the wiki is a bit harder to automate attaching to
15:29 < f13> but it's not the worst option in the world.
15:29 < mmcgrath> f13: no need to attach to the wiki, we have the releases ability now.
15:29 < mmcgrath> people can scp the files they want up there.
15:29 < f13> mmcgrath: uh... so the people who are doing fedora hosted projects /already have/ fedora people space.
15:29 < warren> mmcgrath, and using fedorapeople can we sustainably have multiple upstream project developers put files in a repository and get permissions right?
15:29 < f13> I'm not sure what you're afraid of.
15:30 < warren> f13, 2 or more people working on the same project?
15:30 < skvidal> warren: acls
15:30 < f13> mmcgrath: I would have hoped the webspace would be more like 'python-fedora.fedorahosted.org/'
15:30 < glezos> f13: that does sound like a nice feature to have for a hosted solution.
15:31 < mmcgrath> f13: is this something you really want to block the announcement? if it is we need to come up with a solution for it now.
15:31 < skvidal> f13: A couple of hangups
15:31 * jcollie is back
15:31 < skvidal> 1. we need a box
15:31 < notting> how is fedorahosted.org/releases populated now?
15:31 * mmcgrath thinks this is something we "could" do but shouldn't.
15:31 < skvidal> 2. we need to say explicitly to the users: no php, cgi, etc
15:31 < f13> mmcgrath: I'd be ok announcing it, if we have at least agreed upon a future feature of having hosted raw webspace.
15:31 < warren> f13, we wouldn't want to put upstream project tarballs into the mirror structure?
15:32 < notting> f13: nah
15:32 < notting> erm
15:32 < notting> warren: nah
15:32 < warren> http://download.fedora.redhat.com/pub/fedora/projects/
15:32 < mmcgrath> notting: its in the faq. If you don't have an actual shell on there (which most people don't) you just 'scp filename-1.0.tar.gz fedorahosted.org:projectName' some voodoo on the backend sends it to the right place.
15:32 < warren> If we mirror it, we don't need to back it up. =)
15:32 < mmcgrath> warren: we could announce to mirrors its available though, run rsync fedorahosted::
15:32 < mmcgrath> its in there and available to be synced out.
15:32 < warren> mm
15:32 < f13> mmcgrath: can we do dns tricks so that <project>.fedorahosted.org works ?
15:33 < f13> I know it's asthetics but it /does/ look better
15:33 < mmcgrath> f13: what would people see at project.fedorahosted.org ?
15:33 < mmcgrath> the trac instance?
15:33 < f13> mmcgrath: anybody reading a spec file.
15:33 < lmacken> can we assume most of the fedorahosted projects are actually in Fedora? if so, new releases can just entail pushing into fedora. Then we wouldn't need raw webspace ?
15:33 < f13> mmcgrath: spec files reference the url to the tarball release
15:33 < f13> lmacken: that is terrible for cross-distro
15:34 < f13> lmacken: it's extremely rude to tell Debian "get the tarball from the source rpm in Fedora release Blah"
15:34 < mmcgrath> f13: no I mean if I typed project.fedorahosted.org into my browser, what comes up?
15:34 < lmacken> not if we link to the tarballs ?
15:34 < f13> mmcgrath: directory listing of https://fedorahosted.org/releases/p/y/python-fedora/
15:34 < mmcgrath> lmacken: besides, we already have that
15:34 < skvidal> f13: not the hosted page?
15:34 < lmacken> or somehow autopopulate builds onto the wiki
15:34 < f13> ok, wait
15:34 < mmcgrath> ahhh
15:34 < skvidal> f13: ie: not the wiki instance?
15:34 < f13> in my /grand/ thought
15:34 * mmcgrath sees what f13 is saying here.
15:35 < f13> <projectname>.fedorahosted.org would lead to raw webspace that hte project could do whatever within our rules
15:35 < f13> a pretty page
15:35 < f13> fedorahosted.org/project/ leads you to Trac
15:35 < f13> which often isn't nearly as pretty
15:35 < f13> and yes, this is a lot like how sourceforge works.
15:35 * mmcgrath thinks thats confusing.
15:35 < mmcgrath> so what is koji's home page?
15:36 < f13> mmcgrath: it depends on what the project wnats to do
15:36 < f13> mmcgrath: making every project's home page the Trac instance is kind of lame
15:36 < skvidal> f13: why?
15:36 < mmcgrath> thats confusing though, some projects will use project.fh.o some will use fh.o/project If I want to check out elfutils, how will I know which one to go to?
15:37 < f13> mmcgrath: you're coming at this with prior knowledge that elfutils is hosted with us
15:37 < f13> mmcgrath: invalid use case.
15:37 < f13> mmcgrath: people who are looking for the upstream of elfutils is going ot read the elfutils spec or documentation or whatever and be directed at their homepage
15:37 < f13> or you'll pull up the Trac instance which teh wiki there could say "See <here> for our homepage"
15:38 -!- stickster is now known as stickster_afk
15:38 < mmcgrath> f13: I even know elfutils is hosted with us because they told me, now I want to see it. Which one do I go to?
15:38 < warren> mmcgrath, even downloading tarballs from sourceforge is a bit ambiguous because people have different URL's depending on how they downloaded it
15:39 < warren> mmcgrath, if we want to eliminate different URL's then we have to enforce it with redirects.
15:39 -!- stickster_afk is now known as stickster
15:39 < notting> w.r.t download space, if all we have is the wiki, how are files pushed through that, and does tracwiki scale for serving lots of large files?
15:39 * f13 sees this discussion going nowhere in a hurry
15:39 < mmcgrath> notting: actually the wiki is horrible for pushing files.
15:39 < lmacken> right now elfutils points directly to koji for new releases.
15:39 < abadger1999> f13: Are we more like launchpador sourceforge?
15:39 < f13> mmcgrath: 'the wiki' are you talking about Moin or Trac?
15:39 < abadger1999> (Where we want to be)
15:39 * mmcgrath doesn't compare us to either of them.
15:39 < mmcgrath> f13: Trac.
15:39 < f13> IIRC Trac just is a direct link to the attachment on the filesystem
15:40 < warren> Ubuntu doenst bother to make tarballs, they build directly from bzr on launchpad for things that they are upstream.
15:40 < f13> abadger1999: I'm more familiar with sf.
15:40 < f13> http://sourceforge.net/projects/pidgin vs pidgin.sf.net
15:41 < f13> hrm, perhaps not the best example
15:41 < abadger1999> Just wondering because sf provides web space via shell access while launchpad provides an external links section where you can list a home page if you want more than they provide.
15:41 < f13> but when I dreampt up fedora hosted, I pictured Trac as one of the tools a hosted project would have, not the /only/ tool.
15:41 * warren entirely supports f13 on this.
15:42 < f13> and where a number of projects might have a rich home page for users, and use the Trac instance as a development tool
15:42 * mmcgrath saw it as a simple and complete set of tools.
15:42 < notting> ferexample, we may have a project that wants just 1) download space 2) git + gitweb 3) a mailing list. how does trac help them?
15:42 < f13> that said, maybe our "customers" are perfectly happy with only having Trac.
15:42 < mmcgrath> f13: what can you do on raw space that you can't do with trac wiki?
15:42 < skvidal> mmcgrath: well, the page controls are better
15:42 < mmcgrath> notting: FWIW, we have lots of people that don't have a trac instance.
15:42 < f13> mmcgrath: html, easily manage content programatically
15:42 < skvidal> f13: umm
15:42 < skvidal> wait
15:43 < lmacken> Hmm.. I've seen trac used as a pretty functional homepage as well
15:43 < lmacken> http://cherrypy.org
15:43 < warren> and some people don't want trac at all because it can be a distraction
15:43 < skvidal> f13: are we talking about RAW stuff like php or cgis b/c that's not bloody likely
15:43 < notting> mmcgrath: right, but if they want to tie together a link to gitweb, a link to the ML, etc. ... trac is the only solution atm
15:43 < mmcgrath> The bottom line is we can't provide everything to everyone.
15:43 < mmcgrath> we have a "web" solution do we need 2?
15:43 < f13> skvidal: no of course not, there would be restriction around what could be used.
15:43 < warren> Hosted should be a menu of services that upstream projects can pick from.
15:43 < mmcgrath> warren: it is and will be.
15:43 < mmcgrath> but whats on the menu?
15:43 < f13> lets look at 108 as a great example
15:44 < f13> people hated 108 because to get anything on the web, they either had to fuck with wiki, or svn
15:44 < f13> what they really wanted was the ability to just rsync (via ssh) content into a dir
15:44 * mmcgrath is pretty sure thats not why people hated 108
15:44 < mmcgrath> it was closed source and complicated. Trac is neither of those.
15:44 < f13> mmcgrath: that was on eof the big complaints I heard from a lot of people trying to use it to host projects.
15:44 < f13> mmcgrath: from the usability side
15:44 < mmcgrath> Ok, lets take a step back.
15:44 < mmcgrath> is this a blocker to the announcement?
15:45 < skvidal> not imo
15:45 < f13> I'm leaning toward no, as long as we have a roadmap for something like this we can make public
15:45 < warren> We should at least define exactly what we want and write it as a "coming soon" feature on the roadmap.
15:45 < mmcgrath> Ok, then we should discuss this at another time.
15:45 < notting> yeah, as long as we have a plan so we can tell people 'yes', 'no', 'yes, but in 3 months' when they ask for foo, bar, or baz
15:45 * mmcgrath is already tired of the slippery slope we're headed down with fedorahosted.
15:45 * ricky gets here.
15:46 < mmcgrath> everything some says 'wouldn't it be nice" we've implemented the feature, its got to stop. There is beauty in simplicity.
15:46 * f13 notes that he's been making noise about having web space for projects since day 1.
15:46 < mmcgrath> and some how, over 100 projects have thrived while not having web space.
15:46 < dgilmore> mmcgrath: i want a pony
15:46 < f13> mmcgrath: uh, other than adding additional SCMs, and a couple trac plugins, what exactly ahve we done?
15:46 < mmcgrath> f13: I'm sorry I just don't remember that at all. I'm probably rembering it wrong but I don't remember anything about raw webspace ever.
15:46 < warren> mmcgrath, this is one of the few things that we really need to make hosted complete.
15:47 < J5> I have to agree. By giving people the world we make it harder to create a good experience
15:47 < mmcgrath> f13: just that. I want to make sure it stops there.
15:47 < mmcgrath> warren: I think hosted is complete.
15:47 < notting> is the scp fedorahosted:blah magic work for anything?
15:47 < notting> or just blah-1.2.3.tar.gz?
15:47 < mmcgrath> notting: only if you don't have a shell account.
15:47 < mmcgrath> scp anything fedorahosted:project
15:47 -!- mbacovsk [n=mbacovsk(a)44.252.broadband5.iol.cz] has quit Read error: 110 (Connection timed out)
15:47 < mmcgrath> warren: excpet for mailing.
15:47 < notting> so we have webspace ;)
15:47 < warren> f13, I do recall that from day 1 as well.
15:47 < warren> mmcgrath, which is already on the roadmap
15:48 < f13> mmcgrath: perhaps we should survey our current customers, and potential customers (108 holdouts, et.redhat.com folks, people.redhat.com folks) about it.
15:48 < mmcgrath> f13: I think thats the wrong way to go. We need to have in mind a solution that we want it to be. If its the right tool for those people they will come, if not they won't.
15:48 < dgilmore> f13: most if not all people haviing people.redhat.com space ahve fedorapeople.org space
15:48 < mmcgrath> we can't conform to everyone's needs on this or it will consume ALL of our time like 108's did the 108 people.
15:49 < skvidal> okay
15:49 < skvidal> let's chill
15:49 < skvidal> everyone
15:49 < warren> mmcgrath, this is not a slippery slope. Raw web space is one of the fixed set of things people expect for an upstream project.
15:49 < dgilmore> skvidal: :)
15:49 < mmcgrath> this is a free 'value added' fedora service. If we end up spending lots of time on it, thats less time for other things.
15:49 < dgilmore> lets move on now
15:49 < skvidal> yes
15:49 < skvidal> we're not blocking announcing it
15:49 < skvidal> we can sort this out later
15:49 < dgilmore> no we can announce as is
15:49 < skvidal> on a day when we're all less busy
15:49 < dgilmore> i think its done being a beta
15:49 < skvidal> and less stress-y
15:49 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Asterisk
15:50 < dgilmore> :) it works
15:50 < skvidal> we'll learn a lot about what people want from tickets
15:50 < mmcgrath> The Board has put a higher priority on our asterisk setup.
15:50 < skvidal> eyeroll
15:50 < skvidal> sorry, the board has an asterisk fetish for odd reasons :)
15:50 < mmcgrath> asterisk as it stands has enough shortcommings that it won't be usable for us without a few things.
15:50 < spoleeba> skvidal, i have an n810 now.. id like to use it for..something
15:50 < mmcgrath> 1) they've requested town-hall style meetings.
15:50 < dgilmore> skvidal: we do
15:50 < skvidal> dgilmore: :)
15:50 < mmcgrath> jcollie: do you want to talk about that for a moment and the implementation you tested?
15:50 < jcollie> ujh sure
15:50 < jcollie> erg
15:51 < jcollie> it's ticket 395
15:51 < mmcgrath> .ticket 395
15:51 < mmcgrath> :)
15:51 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/projects/fedora-infrastructure/ticket/395
15:52 < jcollie> basically the board wants to have some conferences calls streamed out so that 10s or maybe even 100s of people can listen in live
15:52 < dgilmore> taking feedback via irc
15:52 < jcollie> so i've figured out a way to get the audio out of the asterisk conference call and stream it using flumotion
15:53 < dgilmore> jcollie: and its all FOSS?
15:53 < jcollie> yup
15:53 < dgilmore> streaming ogg
15:53 < spoleeba> jcollie, thats a nice valentines day present
15:53 < jcollie> its streaming ogg/vorbis right now but i was going to test ogg/speex
15:54 < jcollie> fluendo even has a java applet for those unfortunate to be running windows
15:54 < jcollie> the java applet is gpl too i think
15:54 < dgilmore> cool
15:54 < warren> bbl
15:54 * mmcgrath notes he used this system the other day. It actually worked, rather well.
15:54 < jcollie> the java applet isn't in fedora yet but i have a srpm under development
15:55 < lmacken> good deal
15:55 < ivazquez> Does IcedTea support audio yet?
15:55 < glezos> jcollie: sounds great
15:55 < spoleeba> jcollie, so where is it at right now? does all the board members need to test it?
15:55 < jcollie> also, i'd prefer to use a development version of flumotion than what is in fedora right now but i'm not stuck on that
15:55 < mmcgrath> spoleeba: its not at that point yet
15:55 < mmcgrath> our asterisk deployment isn't even official yet, we'll need to get that finalized and in puppet before we start considering these things.
15:56 < jcollie> i just did a technology preview to see if i could get the audio out of asterisk and into flumotion
15:56 < spoleeba> mmcgrath, the big concern was making sure connected audio source clients...weren't stupidly configed
15:56 < jcollie> yeah, we need to make sure that all the board members have decent headsets and a working SIP client setup
15:56 < spoleeba> jcollie, ha!
15:56 < spoleeba> jcollie, 'decent'
15:57 < jcollie> the mics built into laptops pick up too much ambient noise
15:57 < poelcat> mmcgrath: sorry on another call... yay for Mediawiki :)
15:57 < jcollie> spoleeba: actually you can get by with some really cheap ones - i use these generic labtec ones
15:57 < spoleeba> jcollie, i want to test my n810 :->
15:57 < mmcgrath> I'm actually working on trying to get some dial in numbers for that. We'll see how it goes but areacodes in boston and raleigh would help a lot.
15:57 < jcollie> so no need to spend $100s
15:58 < spoleeba> jcollie, just let me know when you wwant me to test it
15:58 < jcollie> dial in numbers should be pretty easy to find
15:58 < notting> 888-fed-ora1?
15:58 < skvidal> umm
15:58 < skvidal> eww
15:58 < dgilmore> most of the board brought headsets when we looked at using asterisk for board meetings
15:58 -!- jmtaylor [n=jason(a)220.127.116.11] has joined #fedora-meeting
15:58 < mmcgrath> notting: the 888 numbers require per minute charges.
15:59 < mmcgrath> Ok, hey guys we're running out of time. There's a couple of other things I wanted to get to.
15:59 < dgilmore> notting: we have to pay for that
15:59 < jcollie> i'm also thinking about using an IRC bot to control the conference
15:59 < dgilmore> jcollie: awesome
15:59 < dgilmore> mmcgrath: move on
15:59 < mmcgrath> jcollie: sorry to cut you off :(
15:59 < jcollie> yeah, the board doesn't want to do this until sometime in april anyway
15:59 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- FAS2
15:59 < mmcgrath> we're moving to database with that, abadger1999 has been very helpful and ricky and I will be back on it hard core next week.
15:59 < mmcgrath> and last thing
16:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- My Fedora
16:00 < mmcgrath> J5: how's that going?
16:00 * mmcgrath hopes J5 is still around.
16:00 < J5> been working on the build page - it has been slow since I am learning new things
16:00 < J5> But it is coming on nicely
16:00 < mmcgrath> is there a demo up anywhere yet?
16:01 < J5> just in git
16:01 < J5> I'll get something up by next week
16:01 < J5> the end of next week that is
16:01 < mmcgrath> <nod> no worries. Do you have an ETA for when you'd like to deploy?
16:01 < ricky> Probably sometime after FAS2, I assume?
16:01 < J5> yes
16:02 < J5> well we can get the non-login stuff (it is still useful for searching packages and quickly navigating them)
16:02 < mmcgrath> <nod>
16:02 < J5> before fas2
16:02 < mmcgrath> J5: thanks for that.
16:02 < mmcgrath> alrighty, before we go
16:02 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor.
16:02 < mmcgrath> Anyone have anything else?
16:02 < skvidal> how about them backups?
16:03 < mmcgrath> ahh, yes dgilmore has been working on backups.
16:03 < skvidal> yay for all the work dgilmore and mmcgrath put in to make tape backups work
16:03 < mmcgrath> dgilmore: how's that going?
16:03 < dgilmore> skvidal: the backup on /mnt/koji is running very slowly
16:03 * mmcgrath notes tapes are in and AFAIK backing.
16:03 < mmcgrath> dgilmore: how long do you suspect a full koji backup will take?
16:03 < dgilmore> mmcgrath: at the rate we are going days
16:03 < mmcgrath> how many though?
16:04 < jcollie> what kind of tape hw do we have?
16:04 < mmcgrath> its a TL2000 with LTO-3 tapes.
16:04 < jcollie> are we still using bacula?
16:04 < dgilmore> since 10pm cst we have backed up 300gb of 2tb
16:04 < dgilmore> jcollie: yeah
16:05 < jcollie> this just uses a single LTO drive then?
16:05 < mmcgrath> jcollie: yeah.
16:05 < mmcgrath> dgilmore: anything else? We should probably wrap it up.
16:05 < jcollie> hmm too bad
16:06 < dgilmore> mmcgrath: its running and is working
16:06 < dgilmore> we will need to do some test restores
16:06 < mmcgrath> yeah
16:06 < dgilmore> but thats it
16:07 < mmcgrath> k.
16:07 * mmcgrath looks forward to that.
16:07 < mmcgrath> Ok, anyone have anything else?
16:07 * dgilmore has nothing
16:07 < jcollie> nope
16:08 < mmcgrath> allllllrighty
16:08 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Closed
Hi! I'm Jared Smith, and I'm finally getting around to introducing
myself. I've been a long-time lurker on the IRC channel and the mailing
OK, so what do you need to know about me? Let's see... I've been using
Linux professionally for about ten years now, and was using various
flavors of UNIX before that. I managed over 6500 Linux boxes at a
previous employer, and racked a fair number of those myself. I've
pretty much "been there, done that, and still have the scars to prove
it" when it comes to managing IT infrastructure and data centers.
I'm also big into VoIP (and even co-authored an O'Reilly book on
Asterisk), so I'm hoping to help out jcollie and mmcgrath in that area
as well. I'm currently working for Digium (the company behind Asterisk)
as their Community Relations Manager and lead trainer.
I've also done quite a bit of database work (mostly PostgreSQL) and some
programming in various languages.
Anyhoo, enough about me...
-Jared Smith (jsmith on IRC)
I realized I have never done a 'self-introduction' to any of the
Fedora items.. so I had better do so now that I am a chief asbestos
Full Legal Name: Stephen Smoogen
City, Country: Albuquerque NM, USA UTC-07:00
Profession: Systems Administration, Computer Security, Loon.
Affiliation: University of New Mexico
Your goals in the Fedora Project: To help build a stable enterprise
Linux and have a good desktop platform.
I started in Linux in 1992 when working as a student at New Mexico
Tech. I got handed a box of floppies to try out and found Linux to
have all the tools I needed to get a remote telescope communication
working that I couldnt do with other software. I then went to work at
Los Alamos National Labs and then a browser company called Spyglass.
At Spyglass, I worked with Red Hat on the Red Baron browser (ok I did
QA on it in the back room while trying to keep the AIX 3 boxes
running). I went to work at Red Hat in 1997 as a Technical Support
Monkey, and worked at Red Hat til 2001 in various places. I then went
back to work at Los Alamos and then Sandia National Laboratories for a
year. I am currently working as a Unix/Linux Administrator at the
University of New Mexico while I work on my Masters/Phd that I am
hoping to someday maybe sorta get.
I have done mostly computer systems administration, and computer
security. My programming skills have been more on finding where a core
dump occurs and what input triggered it. I am hoping to help grow EPEL
to a larger audience and to work eventually on a not-so-l33t-security
GPG KEYID and fingerprint:
pub 1024D/D7840F95 2003-06-01 [expires: 2010-06-08]
Key fingerprint = EA1D 11EC 8B94 CD22 7DF0 AA46 F20A 1093 D784 0F95
uid Stephen J Smoogen (Main Email) <smooge(a)gmail.com>
uid [jpeg image of size 4099]
uid Stephen J Smoogen (Alternate Email) <smooge(a)unm.edu>
uid Stephen J Smoogen (Alternate Email)
uid Stephen J Smoogen (Alternate Email) <smooge(a)mindspring.com>
uid Stephen J Smoogen (Alternate Email)
uid Stephen J Smoogen (Alternate Email) <smooge(a)jitagames.com>
sub 1024g/43A39C4B 2003-06-01 [expires: 2010-06-08]
sub 1024D/8723487C 2005-06-09 [expires: 2010-06-08]
sub 1024g/9B6AD5B9 2005-06-09 [expires: 2010-06-08]
sub 1024R/614037DB 2008-01-30 [expires: 2010-06-08]
sub 1024R/50524DCB 2008-01-30 [expires: 2010-06-08]
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
I was wondering if any one knew what time of the day the upstream fedora
mirrors do their syncing?
Recently, I have received a number of rsync errors (error 24 "vanishing
files"); I believe it is because we are tying to sync at the same time
as as upstream sync. Currently, I am syncing at 0, 6, 12, and 18 CST.
Can anyone recommend better times?
Thanks in advance,
Argonne National Laboratory
Computing and Information Systems