[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Meeting Log - 2008-09-25



20:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Who's here?
20:00  * ricky 
20:01 -!- cassmodiah [n=cass fedora/cassmodiah] has quit "שָׁלוֹם"
20:01  * mmcgrath wonders if anyone else is
20:01 < fchiulli> fchiulli is lurking
20:02 < mmcgrath> abadger1999 dgilmore f13 fchiulli G jcollie lmacken marek ping?
20:02 < brothers> hi
20:02 < mmcgrath> brothers: yo
20:02 < dgilmore> gday mates
20:02  * lmacken  
20:02 < fchiulli> mmcgrath: pong
20:02 < abadger1999> hola
20:02 < mmcgrath> yo
20:02 < mmcgrath> ok, lets get started
20:02 -!- skvidal [n=nnnnnnsk fedora/skvidal] has joined #fedora-meeting
20:03  * jcollie will lurk a bit... got some $DAYJOB stuff to do in the background
20:03 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets
20:03 < mmcgrath> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assigned&status=reopened&group=milestone&keywords=%7EMeeting&order=priority
20:03 < zodbot> mmcgrath: http://tinyurl.com/2hyyz6
20:03 < mmcgrath> .ticket 753
20:03 < zodbot> mmcgrath: #753 (Mini-freeze for Fedora 10 beta) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/753
20:03 < mmcgrath> So the freeze is still on until...
20:03 -!- balor [n=balor gimili plus com] has quit Remote closed the connection
20:03 < mmcgrath> 2008-09-30
20:04 < mmcgrath> nothing extrodinary there.
20:04 < mmcgrath> Does anyone have work thats blocking on that release?
20:04 < mmcgrath> I know domsch might have some MM stuff, not totally sure though
20:04 < mmcgrath> k, I'll move on then
20:04 < mmcgrath> .ticket 395
20:04 < zodbot> mmcgrath: #395 (Audio Streaming of Fedora Board Conference Calls) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/395
20:04 < abadger1999> bunch of little stuff.  I'm working on other stuff until then
20:05 < mmcgrath> <nod>
20:05 < mmcgrath> jcollie: anything new on this front?
20:05 < jcollie> nope
20:05 < mmcgrath> k
20:05 < mmcgrath> .ticket 446
20:05 < zodbot> mmcgrath: #446 (Possibility to add external links on spins page) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/446
20:05 < mmcgrath> dgilmore: ^^^
20:05 < dgilmore> nope i think it should be closed
20:06 < mmcgrath> k, if you're ready to close it have at it.
20:06  * nokia3510 says hello
20:06 < mmcgrath> .ticket 740
20:06 < zodbot> mmcgrath: #740 (Loaning out system time to OLPC participants) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/740
20:06  * mmcgrath looks at ticket to see if anything new is there.
20:06 < dgilmore> here i really dont know if we can provide what they want
20:07 < mmcgrath> so my last question there never really got answered.
20:07 < mmcgrath> gregdek: ping
20:07 < gregdek> mmcgrath: pong
20:07 < mmcgrath> dgilmore: do you know if their end goal is education or if their end goal is packages
20:07 < gregdek> Oh, trac ticket.
20:07 -!- mdomsch [n=Matt_Dom cpe-70-124-62-55 austin res rr com] has joined #fedora-meeting
20:07 < mmcgrath> gregdek: we're talkinga bout https://fedorahosted.org/fedora-infrastructure/ticket/740
20:07 < dgilmore> mmcgrath: not really sure.  i think both
20:07 < mmcgrath> k
20:08 < mmcgrath> dgilmore: do you think we could point them to SuSE's open buildsystem?
20:08 < mmcgrath> I have a reasonably good relationship with those guys, not sure if they'd be interested or not.
20:08 < gregdek> aiui, the biggest problem is they've got participants who are being asked to build packages for OLPC, but they don't have Fedora systems, only Debian systems.  And they end up doing weird stuff to get packages built.
20:09 < mmcgrath> and OLPC builds packages now, do we just need the koji client in debian?
20:09 < dgilmore> mmcgrath: not really.
20:09 < dgilmore> mmcgrath: honestly i think having koji in debian/ubuntu would go a long way to helping
20:09 < dgilmore> since mock is tehre and works
20:10 < mmcgrath> I guess I'm still confused by what is there, what they want and what they would suggest Fedora's role in that should be.
20:10 < mmcgrath> gregdek says they have people who are being asked to build packages, is this like OLPC extras or something?
20:10 < mmcgrath> OLPC.us?
20:10 < mmcgrath> :)
20:10 < ricky> Hehe
20:11 < gregdek> You know, I'm unsure.
20:11 < dgilmore> mmcgrath: most of it is dealling with fedora packages.
20:11 < dgilmore> mmcgrath: a tiny amount is packages not in fedora
20:11 < mmcgrath> so getting fedora packages into OLPC?
20:11 < dgilmore> but thats really tiny
20:11 < dgilmore> yeah
20:11 < mmcgrath> so they're worried about the tiny portion not in Fedora?
20:11 < mmcgrath> or the portion that is in Fedora?
20:11 < mmcgrath> if so, are we just talking about another distribution of Fedora similar to what EPEL is now?
20:12 < dgilmore> dealling with testing builds in mock.  i.e. for new packages. dealing with submitting builds to koji
20:12 < mmcgrath> and the requirements are that this work on debian?
20:12 < dgilmore> thats the main hurdle
20:12 -!- jmtaylor [n=jason fedora/jmtaylor] has joined #fedora-meeting
20:13 < mmcgrath> so there's potentially two parts to this
20:13 < mmcgrath> 1) is getting the koji client into debian, mock already is.
20:13 < mmcgrath> dgilmore: does mock build olpc packages just fine?  what does it build against?
20:13 -!- fbijlsma [n=fbijlsma p4FDC4F8C dip t-dialin net] has joined #fedora-meeting
20:13 < dgilmore> mmcgrath: most people use the fedora release  that there targeting against
20:13 < mmcgrath> k
20:14 < dgilmore> mmcgrath: though i have a mock config that uses olpc specfic packages also
20:14 < mmcgrath> and thast something that could be done on debian today?
20:14 < dgilmore> yes
20:14 < dgilmore> really whats missing is koji
20:14 < dgilmore> and maybe fedora-packager
20:15 < mmcgrath> so the thing the OLPC debian guys can't do is actually submit builds to koji so I'd think really we need to get one of those debian guys to get koji into debian.
20:15 < mmcgrath> or one of our guys to do it, I have no idea what the process is there.
20:15 < dgilmore> yeah i think one of them would be best
20:16 < mmcgrath> dgilmore: gregdek: do either of you know who we could assign this ticket to in debian world?
20:16 -!- JSchmitt [n=s4504kr fedora/JSchmitt] has quit "Konversation terminated!"
20:16 < dgilmore> mmcgrath: ill ask them to provide someone
20:16 < mmcgrath> k
20:16 < dgilmore> lets move on
20:16 < mmcgrath> k
20:16 < mmcgrath> Thats the last of the tickets
20:16 -!- kulll [i=d318e24a gateway/web/ajax/mibbit.com/x-d4dfe58a02d08d2a] has joined #fedora-meeting
20:17 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- puppet training
20:17 < mmcgrath> I dropped the ball on that puppet training.  It'll happen next week I swear!
20:17 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- oVirt
20:18 < mmcgrath> I've been working to get xen6 rebuilt with oVirt.  It is now dedicated to just the staging environment.  there's a couple of potential uses there and possibly some upcomming projects as well.
20:18 -!- c_scott [n=cscott schoolserver laptop org] has joined #fedora-meeting
20:18 -!- m_stone [n=mstone dhcp-47-72 media mit edu] has joined #fedora-meeting
20:18 < m_stone> dgilmore: howdy. what can I do for you?
20:18 < mmcgrath> But I (and hopefully the rest of us) will be able to get our hands dirty with ovirt and help the developers harden it and get it ready.
20:18 < mmcgrath> dgilmore: I'll switch the topic back
20:18 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Tickets
20:18 < mmcgrath> .ticket 740
20:18 < zodbot> mmcgrath: #740 (Loaning out system time to OLPC participants) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/740
20:19 < mmcgrath> m_stone: we were looking at that ticket and from what we understand, we just need to get the koji client into debian but we don't know how to do that.
20:19 < m_stone> mmcgrath: that would certainly be a good first step.
20:19 < mmcgrath> m_stone: do you know any debian guys who can package it and get it in?
20:19 < m_stone> I can probably scare some up.
20:20 < m_stone> (though not this week!) :)
20:20 -!- DemonJester [n=DemonJes fedora/DemonJester] has quit "leaving"
20:20 < smooge> quick question... mediawiki .. do we need to update to something furhter on upstream? I am looking at the source now
20:20 < mmcgrath> dgilmore tells me mock is already in debian so it should have everything we need to 1) test mock builds on debian workstations and 2) ultimately submit those builds to koji to be built.
20:20 < dgilmore> m_stone: what kind of educational assistance do you think fedora could offer?
20:20 < m_stone> mmcgrath: the difficulty is that, as of the last time I tested it, mock's usage of yum on debian was failing.
20:20 < dgilmore> m_stone: what are the ultimate end goals  your hopping we can provide?
20:20 -!- marcopg_ [n=marco host162-118-dynamic 9-87-r retail telecomitalia it] has joined #fedora-meeting
20:20 < m_stone> so it was unable to initialize chroots.
20:20 < c_scott> m_stone: no, mock WorksForMe
20:20 < m_stone> c_scott: glad to hear it!
20:21 < c_scott> a koji port would be very nice, though
20:21 < m_stone> I'll retry it myself then.
20:21 < c_scott> i'd like to see the olpc repo configurations make it into mock upstream, though
20:21 < dgilmore> m_stone: i know mock worked for me when testing
20:21 < m_stone> (or else teach mock to be able to pull form urls)
20:21 < abadger1999> That would be nice from my perspective as well.
20:21 < m_stone> i.e. to pull configurations from, say, http urls
20:21 < dgilmore> m_stone: was it just ubuntu that was having issues?  i used plain debian
20:22  * abadger1999 needs olpc repo's for the package database.
20:22 < nirik> smooge: it still needs to be built for epel... ianweller or you or whoever should do that if it's ready to be used. ;)
20:22 < m_stone> dgilmore: it was plain debian too.
20:22 < c_scott> dgilmore: yes, i use plain debian, too.
20:22 < m_stone> dgilmore: I last tested this March 7 though.
20:22 < m_stone> so it has been a while.
20:22 < m_stone> dgilmore: anyway, returning to your questions about educational assistance and goals...
20:22 < dgilmore> c_scott: there a few extra configs that need to get into mock
20:23 < m_stone> http://wiki.laptop.org/go/Developer/Fedora  should give you some idea of the audience we're targetting.
20:23 < m_stone> however, if you glance at the 'outside reading' section...
20:24 < m_stone> you'll see that the tutorials/guidelines for actually writing specfiles which are listed are all severely out of date..
20:24 < mdomsch> c_scott, if the olpc configs exist, adding them to mock should be trivial
20:24 < c_scott> mdomsch: dgilmore's got 'em
20:24 < m_stone> either the Maximum-RPM snapshot or the draft 'creating rpms' chapter.
20:25 < m_stone> dgilmore: consequently, I'm interested in three basic things.
20:26 < m_stone> dgilmore: 1) ability to use A Single Program for basic specfile maintenance tasks. this could be the common Makefile if it were easily adapted by newbies to new packages, it could be my Makefiles, etc.
20:26 -!- Gaaruto [n=Gaaruto fedora/Gaaruto] has joined #fedora-meeting
20:26 < m_stone> having to immediately learn the individual command lines for git, cvs, rpmbuild, rpmlint, mock, and koji simultaneously doesn't work real well, in my experience.
20:27 < mmcgrath> m_stone: it doesn't work well even one at a time :)
20:27 < dgilmore> m_stone: you mean for getting packages ready for review?
20:27 < m_stone> 2) some authoritative written documentation on how to deal with specfiles.
20:27 < m_stone> dgilmore: for that, and also for bumpspec, changelog update from VCS logs, simplified error detection for %files problems, ...
20:27 < m_stone> that sort of thing.
20:27 < abadger1999> m_stone: Are we mostly talking new packages or maintaining old packages?
20:28 < m_stone> abadger1999: a mix of both. the documentation I wrote was geared at tweaking existing packages.
20:29 < m_stone> abadger1999: on the other hand, requests for new packages come up frequently. since FUDCON Boston, though, it's been a lot easier to get help from folks like mether on the new-requests packaging.
20:29 < c_scott> also, i'd rather like some tools to help manage forked packages -- starting with basic notifications when there's a new (say) f9 release of a package with an olpc3 fork
20:29 < m_stone> dgilmore: similarly, a source-code browser for the patched contents of SRPMs. -- I've started on this myself and may eventually finish it, but this ought to be useful for Fedora too.
20:29 < c_scott> and, if I get ambitious, a way of automatically applying patches to (say) f9 packages to get a corresponding olpc3 package
20:30 < m_stone> dgilmore: anyway, moving into the rest of the education problem.
20:30 < abadger1999> m_stone: #fedora-devel is the best resource for tweaking existing packages as it's likely to be one-off questions.
20:30 < m_stone> dgilmore: I benefitted greatly from hands-on tutoring on making rpms from bernie, from dcbw, and from you.
20:31 < m_stone> dgilmore: however, in order to be able to benefit from that tutoring, I needed both a fedora machine and access to the tutor.
20:31 < abadger1999> New packages would benefit from having someone mentor.
20:31 < m_stone> dgilmore: lots of people who I've tutored since then simply do not have easy access to a fedora development machine.
20:31 < m_stone> conceivably they could use a livecd, but in practice, it's still a real pain.
20:31 < abadger1999> The mingw people have started building a script that can help with forked packages... although we'dwant to reduce forking in olpc's case if possible.
20:31 < m_stone> and they still have to figure out where to find a mentor and how to give the mentor access to the build environment, etc...
20:32 < dgilmore> m_stone: so with the approriate tools on whatever distro they use they should be able to do thinks ok.
20:32 < dgilmore> m_stone: and they would have an XO to actually test things on
20:32 < c_scott> abadger1999: the goal is actually to help distinguishing (a) what packages are currently forked, (b) what the patch is that requires them to be forked
20:32 < c_scott> abadger1999: both help long term in ensuring changes are merged upstream to mitigate future need for the fork
20:33 -!- stickster_afk is now known as stickster
20:33 < abadger1999> c_scott: I think the mingw script does the opposite.
20:33 < c_scott> abadger1999: ?
20:33 < abadger1999> But maybe you could run it with the branches switched.
20:33 < m_stone> dgilmore: it's possible that you're right; it just makes more sense to me think of it as a Fedora-based 'newbie's sandbox' in koji.
20:34 < f13> sorry, I was busy
20:34 < m_stone> dgilmore: for example, you can imagine wanting to build up a browsable library of spec-file corrections made by experienced folks to newbie specfiles.
20:34 < abadger1999> Basically, it was designed so the mingw people could have a cross-compiled version of a Fedora package.  then they can run the script to tell them what has changed in the Fedora-native package.
20:34 < m_stone> dgilmore: so that new folks have a wide variety of materials to browse to try to bootstrap themselves into knowledge.
20:34 < c_scott> abadger1999: ok, i see
20:35 < c_scott> abadger1999: but that tends to perpetuate the fork ;-)
20:35 < c_scott> i want to base all our packages on an f9 package, and just apply a patch to them automatically
20:35 < abadger1999> c_scott: yeah.  In their case, the fork is permanent (the crosscompiled package is always going to be separate even if the source is all the same).
20:36 < abadger1999> <nod>
20:36 < dgilmore> m_stone: we have cvs history :).  i can think of a few improvements for fedora-packager from this.
20:36 < m_stone> dgilmore: how is cvs history browsable?
20:37 < dgilmore> m_stone: cvsweb
20:37 < abadger1999> You want to say I have one olpc-specific patch and two that I submitted upstream (Fedora).  New Fedora version is out, what patches can I drop, what patch do I need to rebase to the new version.
20:37 < m_stone> dgilmore: and how can diff between the upstream sources?
20:37 -!- ldimaggi_ [n=ldimaggi nat/redhat/x-ce1910205342fe50] has quit "Leaving"
20:37 < m_stone> dgilmore: remember that a lot of folks are both the upstream and the packager for us.
20:37 < m_stone> and it's particularly confusing for them since the fedora docs mainly assume that packagers are not upstream.
20:37 < dgilmore> http://cvs.fedoraproject.org/viewvc/rpms/ however not easily searchable
20:38 < abadger1999> m_stone: Not that they aren't... just that they separate their roles.
20:39 < dgilmore> m_stone: it would be great if you could add some comments to that ticket.
20:39 < m_stone> dgilmore: okay, I can do that.
20:39 < m_stone> poke me again when it's not release week. :)
20:39 < dgilmore> :)  will do
20:39 < m_stone> also, thanks for being so open to these suggestions.
20:40 < mmcgrath> we like openess :)
20:40 < m_stone> as I said before, I'm happy to take a crack at some of this myself; I just wanted to make sure you were aware of what I was aiming for.
20:40 < mmcgrath> dgilmore: m_stone: anything else for now or can we move on to the next meeting item?
20:40 < mmcgrath> m_stone: FYI, you can almost always find us in #fedora-admin should you have questions or ideas concerning this (or anything else for that matter)
20:40 < m_stone> mmcgrath: I'll follow up w/ dgilmore again in future weeks, then we can see where we stand.
20:40 < m_stone> good?
20:40 < mmcgrath> sounds good, m_stone please do make notes in the ticket so we don't forget - https://fedorahosted.org/fedora-infrastructure/ticket/740
20:40 < m_stone> mmcgrath: will do.
20:41 < mmcgrath> You'll need a fedora account for that, but not a CLA - https://admin.fedoraproject.org/accounts/
20:41 < mmcgrath> Ok, if there's nothing else I'll move on to the next item.
20:41 -!- bryan_kearney [n=bkearney nat/redhat/x-ff8ab0eafb7c82fd] has left #fedora-meeting ["Jar Jar Binks is my co-pilot"]
20:41 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- oVirt
20:41 < mmcgrath> K, so the oVirt team (ovirt.org) is working on some stuff and I think it'd be good for our team to adopt it.
20:42 < ricky> I looked at the website a tiny bit.  Is it an appliance "take-over-the-machine" type thing, or just a package that you install?
20:42 < mmcgrath> We can't blanket move our infrastructure to it because we're almost entirely paravirt right now and not all of our hardware suports hardware virt.
20:42 < mmcgrath> ricky: both.
20:42 < SmootherFrOgZ> ricky: it's an appliance
20:42 < mmcgrath> But right now they just have an image for you to use and install.
20:42 < ricky> Aw :-(
20:43 < mmcgrath> ricky: my understanding is this is still very early.
20:43 < mmcgrath> the good thing about us getting involved now is we can make sure and make suggestions to help suit our needs and what we think others needs will be.
20:43 < ricky> OK.  Hopefully, that will be one of the things
20:44 < SmootherFrOgZ> mmcgrath: what is the goal ? use the image appliance or make all service up and running for fedora-infra ?
20:44 < mmcgrath> well, in our case there's a couple of goals.
20:44 < mmcgrath> the primary goal is to look at whether or not we think ovirt will be the future of virtualization in the RH stack of virtualization.
20:45 < mmcgrath> I don't think we really have a say in it, but as fedora goes, it typically follows that RHEL goes.
20:45 < dgilmore> mmcgrath: having a base appserver appliance proxyserver applaince etc?
20:45 < mmcgrath> And managment tools in the open source space are horrible right now.
20:45 < mmcgrath> dgilmore: well, the ovirt stack's primary win is its management piece, and really thats the appliance.
20:45 < mmcgrath> so, in theory, we can 'convert' our current images to use to ovirt stack.
20:45 < mmcgrath> which, AFAIK, will just work.
20:45 < dgilmore> mmcgrath: ok
20:45 < SmootherFrOgZ> mmcgrath: correct
20:46 < mmcgrath> SmootherFrOgZ: did you do any conversions or was all your stuff fresh?
20:46 < lmacken> mmcgrath: how come we can't just start using it on everything?  It uses libvirt, which supports xen and kvm, no ?
20:46 < SmootherFrOgZ> some conversions from xen host, yeah
20:46  * lmacken knows nothing about oVirt though, other than it is a rails app
20:46 < mmcgrath> lmacken: well, it uses libvirt's api, and libvirts api supports xen and kvm, but ovirt doesn't yet.
20:46 < mmcgrath> I get the feeling that we are VERY early adopters of ovirt.
20:46 < lmacken> odd, ok.
20:47 < mmcgrath> SmootherFrOgZ: were your xen host images actual disk images or were they partition images?
20:47 -!- Sonar_Guy [n=Who_Know fedora/sonarguy] has joined #fedora-meeting
20:47 < lmacken> Sounds good to me though, I'm all for it.  Do we have any kvm guests yet ?
20:47 < mmcgrath> not a single one yet.
20:47  * ricky didn't know about the rails part :-)
20:47 < mmcgrath> though hopefully some of our staging environment will be.
20:48 < dgilmore> mmcgrath: we were very early adopters of xen also
20:48  * SmootherFrOgZ only use partition images, but i did some tries with disk image 
20:48 < lmacken> dgilmore: and TurboGears ;)
20:48 -!- mdomsch [n=Matt_Dom cpe-70-124-62-55 austin res rr com] has quit Remote closed the connection
20:48 < mmcgrath> dgilmore: yep, and I miss all that pain :)
20:48 < mmcgrath> SmootherFrOgZ: k
20:49 < mmcgrath> So yeah, I'm hoping FI can get a good working relationship with the oVirt guys so if you see them poking around at what we're doing, spend some time talking to them, ask questions and answer theirs.
20:49 < SmootherFrOgZ> i think we should add closer look on all services that ovirt requires also
20:49 -!- nman64 [n=n-man fedora/nman64] has quit Remote closed the connection
20:49 < ricky> #ovirt and #ovirt-devel, I assume?
20:50 < mmcgrath> <takes_off_RH_hat>Considering that RH bought Qumranet it seems likely to me that they'll be pushing harder for KVM, especially since its already in the kernel and some how xen has still managed to fail at that </rh_hat_off>
20:50 < mmcgrath> <nod>
20:50 < ricky> Er, not #ovirt-devel, #ovirt on OFTC, apparently
20:50 < mmcgrath> I don't really have a view into that virtualization stack stuff yet but maybe this will be a better way to see what RH's roadmap is for all of that.
20:50 < dgilmore> ricky: the virt guys seem to like oftc
20:51 < ricky> Heh.
20:51 < mmcgrath> I have to figure there will be a seemless way to convert from xen to kvm by RHEL6 but I guess we'll have to see.
20:51 < dgilmore> #virt there is for libvirt
20:51 < mmcgrath> :)
20:51 < mmcgrath> So anywho, anyone have any questions on that?
20:51  * dgilmore has none
20:51 < ricky> Is this something that'd be hard to setup at home?
20:51 < mmcgrath> ricky: you'd need hardware virt support.
20:51 < SmootherFrOgZ> ricky: not
20:51 < mmcgrath> I actually don't have a single box here at home that has that.
20:52 < ricky> But it won't take over the machine with appliance-y stuff, right?
20:52 < mmcgrath> other then that though, I don't think it'd be difficult.
20:52 < mmcgrath> ricky: the appliance is an actual image that you'd run in KVM.
20:52 < SmootherFrOgZ> ricky: but you will also need to have a lot of memory for the image appliance
20:52 < mmcgrath> so its like a 500M download or something then you run it.
20:52 < ricky> OK
20:53 < SmootherFrOgZ> ricky: fedora packages seem to work well just like ovirt repo btw
20:53 < mmcgrath> Ok, anyone have anything else on that?  If not I'll open the floor.  (we're running out of time)
20:53 < dgilmore> nothing more from me
20:53 -!- fbijlsma [n=fbijlsma p4FDC4F8C dip t-dialin net] has quit Read error: 113 (No route to host)
20:53 < mmcgrath> k
20:53 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Open Floor
20:53 < mmcgrath> Anyone have anything they want to talk about?
20:53  * mmcgrath wants to mention he'll be missing for a chunk of tomorrow afternoon.
20:53 < SmootherFrOgZ> just a quick question
20:54 < mmcgrath> SmootherFrOgZ: sure thing.
20:54 < SmootherFrOgZ> there is a cron tack on buildsys (for koji) which actually does nothing
20:54 < SmootherFrOgZ> s/tack/task
20:54 < mmcgrath> which one?
20:54 < dgilmore> SmootherFrOgZ: what one
20:54 < mmcgrath> its on buildsys.fedoraproject.org or koji.fedoraproject.org ?
20:55 < SmootherFrOgZ> this cron deamon on koji.fp.o
20:56 < SmootherFrOgZ> Cron <apache koji1> $SCRIPT --action=prune
20:56 < dgilmore> abadger1999: thats for koji-gc
20:56 < dgilmore> SmootherFrOgZ: ^
20:56 < SmootherFrOgZ> there a couple of
20:56 < SmootherFrOgZ> delete, purge, etc
20:56 < mmcgrath> dgilmore: are we gc'ing again?
20:56 < dgilmore> SmootherFrOgZ: it needs to be fixed i was waiting for infra freeze to be over to fix it
20:56 < dgilmore> mmcgrath: no
20:57 < dgilmore> mmcgrath: auth is not right
20:57 < dgilmore> I can fix it now
20:57 -!- rdieter is now known as rdieter_away
20:57 < SmootherFrOgZ> here is the lil' log
20:57 < dgilmore> but was going to wait for freeze to be done
20:57 < dgilmore> SmootherFrOgZ: i know exactly what it is
20:57 < SmootherFrOgZ> Error: unable to log in, no authentication methods available
20:57 < dgilmore> SmootherFrOgZ: for now ignore it
20:57 < SmootherFrOgZ> dgilmore: ok ;)
20:58 < mmcgrath> dgilmore: yeah, lets fix it after the freeze.
20:58 < mmcgrath> Ok, anyone have anything else to discuss?  If not I'll close the meeting in 30
20:58 < ricky> If we're have any thoughts about which CA we're planning to use, I'd be willing to test it out at home
20:58 < dgilmore> ricky: dogtag
20:59 < ricky> Cool, I'll start playing around with it and seeing how FAS can talk to it, etc.
20:59 < dgilmore> ricky: i have some feedback from the devs on what we will need to do to migrate from what we have now
20:59 < mmcgrath> 15
20:59 < mmcgrath> :)
20:59 < ricky> Worst case, I'll start a fresh setup with it just to test FAS against it
20:59 < ricky> That's all I had :-)
20:59 < mmcgrath> K
20:59 < mmcgrath> with that
21:00 -!- mmcgrath changed the topic of #fedora-meeting to: Infrastructure -- Meeting Closed

Attachment: pgpKkP67nWeBH.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]