16:00:57 <smooge> #startmeeting EPEL
16:00:57 <zodbot> Meeting started Fri Sep  5 16:00:57 2014 UTC.  The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:57 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:20 <Evolution> woohoo!
16:01:26 <smooge> #meetingname epel-weeklym-meeting-2014-09-05
16:01:26 <zodbot> The meeting name has been set to 'epel-weeklym-meeting-2014-09-05'
16:01:32 <smooge> #topic Robot Roll Call
16:01:39 * smooge is here
16:01:47 * nirik is around... barely.
16:01:49 * Evolution is here
16:01:52 * bharper is here from IUS
16:01:58 * bstinson is here
16:02:46 <smooge> #topic Agenda Listing
16:03:03 <smooge> #info 1) Discussion of current EPEL policies
16:03:14 * stahnma is around in the cheap seats
16:03:31 <smooge> #info 2) Discussion of proposed EPEL policy changes
16:03:31 <smooge> #info 3) Discussion of consolidation and rewrite of EPEL pages.
16:03:31 <smooge> #info 4) Open Flood.
16:03:55 <smooge> Does that sound correct to everyone?
16:04:41 <stahnma> +1 from me
16:04:41 <smooge> oh wait
16:04:50 <smooge> #info 0) Old Business
16:05:25 * maxamillion is here
16:05:27 <smooge> nirik, could you do me a favour? op zodbot :)
16:05:35 <maxamillion> oh, I missed roll call :X
16:05:35 <Evolution> so, for old business, Jeff_S actually brought up a decent point on the mailing list.
16:05:45 <Jeff_S> hey, I'm here a bit late
16:06:04 <smooge> #topic Old Business
16:06:22 <Evolution> pretty much everyone on the currently re-formed board is a hatter.
16:06:40 <smooge> ok I don't see any old business but figured I should put it here.
16:06:41 <Evolution> I'd like to nominate either Jeff_S or bstinson as our token non-hatter rep
16:07:01 <Jeff_S> is there someone that isn't from RH?  I guess I don't know smooge's employeer :)
16:07:11 <smooge> I am a hatter
16:07:11 <bstinson> i was planning on lurking/contributing anyways so I'll be around
16:07:12 <Jeff_S> Evolution: thanks for teaching me to speak up
16:07:16 * bharper is not a hatter
16:07:25 * carlgeorge is not a hatter
16:07:37 <Evolution> Jeff_S: enthusiasm will be punished appropriately.
16:07:40 * stahnma is not either. But I've also been fairly neglectful in my fedora stuff lately ;(
16:07:47 <Jeff_S> +1 to bstinson.  I'm happy to also; either way
16:07:58 <stahnma> +1 to Jeff_S or bstinson
16:08:07 <Jeff_S> I was referring to the current 4 people that were semi-officially decided already
16:08:07 <smooge> ok first of all I am not going to nominate someone just for showing up
16:08:10 <Evolution> since Jeff_S is deferring, let's go bstinson
16:08:39 <Evolution> smooge: bstinson is the author of the centpkg tool we're using/working on.
16:08:56 <Evolution> he's from the centos side of the house, and has been around a bit.
16:08:59 <smooge> I understand that.. I want to know they want to do this versus drafting
16:09:15 <Evolution> Jeff_S has been on the centos qa team for eons.
16:09:36 <Evolution> I'm fine either way. simply offering them up to the sacrifice.
16:09:37 <smooge> so for the 5th member I would like to have someone self-nominate.
16:10:09 <smooge> #topic 0) Old Business. Add a 5th member
16:10:21 <bstinson> I would like to nominate myself as the 5th member of EPSCO
16:10:33 <Jeff_S> +1
16:10:42 <Jeff_S> if my vote means anything :)
16:10:45 <stahnma> do I get a vote?
16:10:52 <stahnma> (I approve)
16:10:55 <Jeff_S> stahnma: only if you say it in caps
16:11:06 <stahnma> uppercase +1
16:11:10 <Jeff_S> ;)
16:11:10 <smooge> at this point anyone who is here is going to get a vote just like we did at the last meetings for the first 4.
16:11:26 <smooge> Are there any objections to having bstinson as a 5th member?
16:11:45 <smooge> ...4
16:11:49 <smooge> ...3
16:11:53 <smooge> ...2
16:11:57 * nirik has no objections.
16:11:59 <smooge> ...1
16:12:32 <smooge> seeing as there are no objections, I would like to welcome bstinson as the 5th member to the emergency EpSCO board.
16:12:57 * Jeff_S hopes someone is making siren-related logos for this committee
16:13:06 <bstinson> thank you all
16:13:08 <smooge> #agreed bstinson will be the fifth epsco member
16:13:27 <smooge> #topic 0) Old Business. Lifetime of this committee
16:14:10 <smooge> there were some questions about making the lifetime of this emergency committee linked to a fedora release and a request to tie it to a date.
16:14:47 <smooge> I would like to propose that we end this committee terms on March 31 2015
16:14:59 <smooge> (i can't rememeber if there is a #propose or something)
16:15:41 <nirik> sure, fine with me.
16:15:42 <Evolution> so the new committee starts april fools day?
16:15:48 <smooge> yes.
16:15:53 <Evolution> joke's on them I guess.
16:15:53 <maxamillion> *awesome*
16:16:10 <Evolution> +1 here, and an added +1 for the evil.
16:16:18 <smooge> +1 from me
16:16:25 <bstinson> +1 here
16:16:28 <smooge> bstinson, dgilmore ?
16:16:50 <stahnma> agree
16:16:55 <smooge> 4 votes for, 1 abstention by not being awake yet.
16:17:55 <smooge> #agreed Term for current EpSCO will end March 31st 2015. New committee will start April 1st 2015.
16:18:03 <smooge> Any other old business?
16:18:53 <dgilmore> hey
16:19:04 <smooge> hi dgilmore :)
16:19:46 <smooge> ok I don't see any other old business I could remember. So I will move to our first topic
16:20:03 <smooge> #topic 1) Discussion of current EPEL policies
16:20:38 <smooge> Currently our written policies are as nirik put it All Fedora guidelines +  https://fedoraproject.org/wiki/EPEL:Packaging
16:20:49 <dgilmore> smooge: yep
16:21:12 <nirik> so I was asked to look at our wording around 'never conflict with rhel'...
16:21:13 <stahnma> the update policy is super difficult for some components
16:21:14 <smooge> I don't have a link for the current Fedora Guidelines. I would like to add that to this page so it is clarified
16:21:32 <Evolution> I think for the most part these are fine. there are some rough edges though.
16:21:37 <nirik> thinking about it tho, I think a better way to do it might be to add a faq item about why conflicts might arise.
16:21:45 <nirik> since people seem to not uderstand them
16:21:46 <Evolution> life expectancy, and upgrade policies could use some tuning I think.
16:21:54 <bzbot> New Fedora EPEL bug 1138804 filed by anto.trande@gmail.com.
16:21:55 <bzbot> Bug https://bugzilla.redhat.com/show_bug.cgi?id=1138804 telegram-cli, unspecified, unspecified, ---, anto.trande, NEW , telegram-cli is not compiled on  big-endian architectures
16:21:57 <bstinson> https://fedoraproject.org/wiki/Packaging:Guidelines
16:22:03 <smooge> ok first off I would like to ask... do we have any unwritten guidelines?
16:22:18 <nirik> no idea.
16:22:24 <stahnma> not that I know of
16:22:25 <Jeff_S> Not that I'm aware of
16:22:41 <Evolution> nirik: you mentioned an update policy that's frowned upon on the list.
16:22:56 <nirik> hum?
16:22:58 <Evolution> would the 'frowned upon' bit qualify here as an unwritten policy?
16:22:59 <smooge> well do we have written down that we remove packages that are orphaned or not maintained?
16:23:30 <Evolution> or was that smooge's email...
16:23:31 * Evolution looks
16:23:33 <stahnma> or what to do when fixing/maintaining a package is an API/ABI break?
16:23:43 <dgilmore> they are suppose dto announce when removing a packge
16:23:43 <nirik> smooge: not that I know of. But we haven't in the past either, so really it would be a new policy. ;)
16:23:50 <dgilmore> maybe we should automate that
16:23:57 <dgilmore> i do not think it happens
16:24:32 <nirik> thats being done/pushed by the new security team group
16:24:35 <Evolution> dgilmore: I think automating it would be good, as there seem to be timing differences between removal and announcement
16:25:03 <Evolution> some get announced and languish before removal. others fairly promptly.
16:25:36 <dgilmore> Evolution: well removal happens when they file a ticket, we do try to promptly do it
16:25:51 <smooge> nirik, ok thanks. I remember doing it a long time ago for some packages we found orphaned and no one wanting to maintain it and thought it policy
16:26:09 <dgilmore> but there have been cases we haven't  usually because there is questions around it
16:27:39 <Evolution> dgilmore: does the bug trigger an email to the list (or could it be made to do so?)
16:27:47 <Evolution> something folks could see/watch?
16:28:08 <Evolution> this is probably down in the weeds for this meeting though
16:28:23 <smooge> ok sorry guys.. I forgot to frame this. I would like us to talk about what we currently have and what we might not have written down. Anything we see that needs to be changed should be noted and then we will start work on that in 'future' meetings. Does that help?
16:28:25 <nirik> there's a outstanding request to send the weekly point of contact/changes email to epel-devel for epel stuff (like the fedora one that goes to fedora devel list)
16:28:56 <Jeff_S> Yeah, that'd be nice
16:28:56 <dgilmore> Evolution: no idea
16:31:00 <smooge> nirik, what kind of work would be needed for that.
16:31:19 <nirik> smooge: I think it's just a bit of cron scripting... should not be hard.
16:31:22 <smooge> sorry my network froze up and I had to restart it.. did I miss anything after dgilmore: Evolution: no idea
16:31:25 <Evolution> smooge: I see room for improvement around package removal notifications. package life cycle, and api/abi for package updates
16:31:50 <Evolution> smooge: 12:31:01] < nirik> smooge: I think it's just a bit of cron scripting... should not be  hard.
16:31:55 <smooge> ok thanks
16:32:44 <dgilmore> maybe we can script it in docker :P
16:33:03 <smooge> OK so other than the current policies are rough and need rewriting.. there aren't any general things that kevin and dgilmore have been doing the last 4 years that isn't on that page?
16:33:08 <Evolution> dgilmore: you can't say stuff like that in places where I can't throw things at you
16:33:26 <dgilmore> Evolution: :) why do you think I said it
16:33:49 <dgilmore> smooge: no its just kinda moved along
16:33:57 <nirik> nothing comes to mind.
16:33:57 <smooge> Also would rewriting those policies to make them better understood be considered by others on the committee to be new policies?
16:34:29 <smooge> some groups would see it that way, others would consider it still old
16:34:29 <nirik> I think we should be happy to re-write things, but we should make sure the re-write doesn't change them.
16:34:54 <Evolution> smooge: to me that depends on the level of change. if it's a simple "make this clearer" no.
16:35:10 <Evolution> if "hey, we added this to document something" then yes.
16:36:00 <smooge> ok so here is what I would like to do next meeting. People take a section they think is unclear and rewrite them and post to the list. We can bikeshed it there and agree/disagree with the rewrites at the next meeting or two.
16:36:27 <Evolution> sounds good.
16:36:39 <smooge> That way there aren't any silent changes which the writer thinks are just cosmetic but actually change things to the other writers.
16:36:44 <bstinson> +1
16:36:48 <stahnma> ok
16:36:56 <smooge> s/writers/committee members/
16:37:28 <smooge> actually this is not restricted to committee members. If you as someone reading this IRC conversation want to join in please do.
16:38:08 <maxamillion> I'm lurking but don't really have much input :/
16:38:42 <smooge> #agreed People will go through https://fedoraproject.org/wiki/EPEL:Packaging and take a section they feel is rough and try to smooth it out a bit. Proposal for changes to the email list (epel-devel) and agreement/disagreement next several meetings.
16:39:01 <smooge> #topic  2) Discussion of proposed EPEL policy changes
16:39:11 <bzbot> New Fedora EPEL bug 1138810 filed by razvan.sandu@mobexpert.ro.
16:39:11 <bzbot> Bug https://bugzilla.redhat.com/show_bug.cgi?id=1138810 squirrelmail, unspecified, unspecified, ---, mhlavink, NEW , SELinux is preventing squirrelmail of sending messages
16:39:45 <smooge> ehehe that is the problem with doing the meeting here. Bug reports in the middle of the meeting..
16:40:01 <Evolution> is this topic covered in the previous decision?
16:40:05 <Jeff_S> maybe they'll get more attention
16:40:15 <bstinson> smooge: is this the dot-release timeline suggestion you posted to the list?
16:40:52 <smooge> Well actually this was more about the policy points in the https://fedoraproject.org/wiki/EPEL-faster-repo-ideas section
16:41:22 <smooge> that we didn't cover already in old business or Current Policies
16:41:43 <smooge> I apologize.. I should have made the agenda a bit more detailed
16:41:45 <stahnma> would this include ability to use/depend/buildupon software collections?
16:42:10 <smooge> Software Collections will require SC to be something Fedora Guidelines support
16:42:31 <stahnma> couldn't they be brought into the EPEL guidelines?
16:43:05 * nirik is -10 to SCLs with no approved fedora guidelines
16:43:11 <dgilmore> stahnma: no
16:43:25 <stahnma> hmm
16:43:25 <dgilmore> stahnma: not sure we can allow depending of software collections
16:43:29 <smooge> I don't think so. SCLs require changes to build systems, bodhi etc etc
16:43:38 <stahnma> right, that's implementation
16:43:41 <stahnma> not discussion
16:43:53 <Evolution> so, I understand that the code mostly originates from fedora, but this is tied to enterprise applications, which is largely outside the fedora scope.
16:43:57 <stahnma> Let's put this on teh agenda next week
16:43:58 <smooge> well implementation of those items are dependant on Fedora wanting them
16:44:08 <stahnma> or EPEL wanting them
16:44:27 <Evolution> this is one of the reasons I would be in favor of removing epel from both fedora and centos, and working it as a collaborative project
16:44:37 <nirik> if folks in EPEL really want them, they should work with the fedora FPC to get the guidelines approved.
16:44:39 <Evolution> we could then cherrypick what makes sense.
16:44:53 <stahnma> nirik: I honestly have much less interst in fedora than EPEL
16:45:25 <stahnma> and there is an upstream for SC (Red Hat)
16:45:26 <nirik> Evolution: sure, but SCL's without complete guidelines don't make sense to me. ;)
16:45:27 <stahnma> for EL
16:45:34 <stahnma> so it seems odd to just rule it out
16:45:38 <Evolution> nirik: 100% agree.
16:45:54 <Evolution> nirik: but that's not the same as a blanket 'no' which is what stahnma just got
16:46:02 <maxamillion> I'm a big fan of SCLs but I don't think they should be in EPEL until there is a guideline in Fedora space for them since EPEL is a subproject of EPEL (for whatever my opinion is worth in this conversation ... not sure where the community vs board lines are here)
16:46:09 * nirik said no without guidelines to be clear.
16:46:16 <maxamillion> EPEL is a subproject of Fedora*
16:46:42 <nirik> anyhow, is this a sidetrack?
16:46:50 <stahnma> yeah, not sure
16:46:55 <RemiFedora> maxamillion, waiting for SCL Guildelines... good luck... I don't think this will never happen
16:47:05 <smooge> stahnma, the SCL's are currently upstreamed but a wild west. They do not have the guidelines to be self-hosting and various items that CentOS and SciLin groups have run into in trying to rebuild them
16:47:43 <Evolution> smooge: where's the upstream for scls?
16:47:51 <Evolution> it's damned sure not softwarecollections.org
16:47:52 <smooge> softwarecollections.org I believe
16:48:07 <Evolution> it *should* be that, but it's not.
16:48:07 <stahnma> as I said, let's put it on the agenda for a later time
16:48:09 <smooge> or what i was told by the SCL people
16:48:16 <stahnma> I think there are other itemst o get through today
16:48:48 <smooge> #agreed table software collections discussion for later meeting. details to be hashed out on list.
16:49:49 <smooge> so from the list of policy questions on the wiki page https://fedoraproject.org/wiki/EPEL-faster-repo-ideas
16:50:26 <smooge> I would like to start with moving testing time from 2 weeks to 1 week.
16:50:54 <stahnma> I'm +1 on 1 week
16:50:56 <bstinson> +1
16:50:58 <Evolution> +1 here.
16:51:05 <smooge> #link  https://fedoraproject.org/wiki/EPEL-faster-repo-ideas
16:51:06 <stahnma> I rarely had any karma or testing from anybody on 2 weeks
16:51:10 <Evolution> if there are automated tests, I'd be fine cutting it even more.
16:51:21 <smooge> #link https://fedoraproject.org/wiki/Packaging:Guidelines
16:51:33 <nirik> it would seem odd to me to have it shorter than fedora.
16:51:41 <nirik> but I am ok with moving it to a week.
16:51:55 <carlgeorge> in IUS, we leave packages in testing for 2 weeks, but trim that down if there are CVE fixes
16:52:32 <Evolution> the problem I see is that very few folks contribute karma
16:52:34 <stahnma> nirik: the difference is that in Fedora, people actually get karma
16:52:35 <dgilmore> im okay with moving to a week
16:52:40 <Evolution> hence my statement about automated testing.
16:52:42 <smooge> nirik, ok so I thought someone said it was 1 week in Fedora currently and EPEL was longer.
16:52:43 <stahnma> in EPEL, nobody tests
16:52:44 <stahnma> :(
16:52:52 <bharper> just like IUS
16:52:58 <stahnma> so it's just a waiting period, that accomplishes nothing
16:53:01 <stahnma> and prevents no bugs
16:53:04 <carlgeorge> most of the bug reports we get for IUS come after a package has hit stable
16:53:10 <stahnma> same for EPEL
16:53:12 <stahnma> IMHO
16:53:17 <carlgeorge> so often times the two week period feels like a waste
16:53:19 <nirik> smooge: it is one week in fedora... it's currently 2 weeks in epel
16:53:49 <smooge> ok I would like to put them to the same length. I apologize for misunderstanding what you said a bit ago
16:53:54 <bstinson> what needs to be done on the auto-karma portion?
16:54:09 <nirik> bstinson: can you expand on your question?
16:55:01 <Evolution> nirik: if we implement ci testing automation via published tests/scripts, could we provide 'auto-karma' to packages?
16:55:21 <nirik> sure.
16:55:58 <bstinson> i guess my first question should have been, will CI/auto-karma be handled by fedora-infra?
16:56:06 <bstinson> if so, how can we help?
16:57:28 <smooge> well it would probably be working with the #fedora-apps guys on how the tools integrate into ?bodhi?
16:57:54 <smooge> and the fedora-qa people
16:58:27 <smooge> as they have been working on some parts for Fedora proper. From that it would be writing general tests for packages and outlining the criteria we are using
16:58:28 * nirik nods.
16:58:46 <nirik> taskotron is going to production in fedora right after alpha.
16:58:59 <nirik> we could possibly ask them to add epel tests then
16:59:03 * Jeff_S GTG... will read through the logs later.  Thanks everyone.
17:00:41 <bharper> FYI, IUS does some testing.  We have automation that installs every package in the testing repos within mock.  We are looking to update from mock to docker so we can run some addtional tests.
17:00:43 <smooge> Jeff_S, no problem and thanks for your time. I will be calling this meeting in 15 minutes with moving other items to next week
17:00:58 <Evolution> how much do the fedora  folks (not the ones here) care about epel though?
17:01:12 <Evolution> it seems like it's largely two different crowds.
17:01:13 <stahnma> in my experience, very little
17:01:14 <smooge> fedora is a very very large organization...
17:01:24 <smooge> what part of fedora are you talking about
17:01:29 <Evolution> stahnma: yeah. that's what I was getting at.
17:01:46 <smooge> the ones working on taskatron and bodhi?
17:01:51 <Evolution> yes.
17:01:54 <nirik> well, last I mentioned it there was interest in running tests against epel at some point.
17:02:08 <nirik> I can ask more directly.
17:02:26 <smooge> the primary os for bodhi application is EL
17:02:27 <Evolution> nirik: please, and possibly also introduce bstinson and I to them as well?
17:03:01 <nirik> sure.
17:03:26 <Evolution> thanks.
17:03:41 <Evolution> bstinson: I'm going to repeatedly throw you under the bus, FYI...
17:03:43 <Evolution> :-P
17:04:17 <bstinson> heh
17:04:33 * bstinson makes a good speedbump
17:05:01 <carlgeorge> Everything I've seen discussed so far seems to point to limiting the release schedule for packages in the new repo (EPIC?).  Is there anything wrong with just following the upstream releases?
17:05:02 <nirik> https://taskotron.stg.fedoraproject.org/resultsdb/jobs (the staging instance against fedora, FWIW)
17:06:23 <nirik> carlgeorge: most folks want some kind of predictable schedule... if we just updated everything as upstream did, different parts would break at different times. Personally I would hate that in a enterprise setup...
17:07:31 <Evolution> yeah. that wouldn't be good. but doing a quarterly update to new versions should be okay.
17:08:50 <smooge> carlgeorge, the issue we have to straddle is that we have users who are running 1-4 systems and want the latest stuff to get something done. Then we have the people running thousands of systems who if they have to change want it done with plenty of flashing red lights.
17:09:18 <Evolution> smooge: wasn't that the idea behind the 3 separate repos?
17:09:32 <Evolution> to allow users to choose the level of pain they're prepared to accept?
17:09:39 <smooge> I believe so.
17:09:55 <carlgeorge> I could see the value in having current epel, quarterly epel, and latest epel (synced with upstream)
17:10:34 <carlgeorge> epel-edge i guess
17:10:39 <smooge> well latest epel would have to be with the caveat that it is a rawhide... because the majority of people doing the packaging for latest stuff don't use EPEL
17:11:07 <smooge> bugs are going to be ignored if they don't replicate in Fedora kind of thing
17:11:21 <nirik> also, in a number of cases 'latest upstream' may not make sense for rhel... ie, it needs newer stuff than is in base rhel to work.
17:11:52 <Evolution> nirik: that's the idea behind the centos sigs. we're going to be pushing some newer-than-base anyway
17:12:07 <nirik> right.
17:12:45 <Evolution> the thinking was that one of the epel.next repos would be an excellent common area for those to land.
17:13:15 <Evolution> that way it's not exclusively centos, and we're then helping to contribute to epel/upstream.
17:13:47 <smooge> well the one issue I see with that is that several of the sigs have already put out conflicting things they want
17:14:22 <smooge> trying to make them unconflict in a common repo is going to be a 'we like his baby more than your baby'
17:15:23 <Evolution> so, we're ripping off the KDE project's guidelines for that to some extent.
17:16:34 <Evolution> things don't update base unless they have to. things should be shared unless absolutely impossible. impossible-to-share-things go in the sig's special snowflake repo with documentation/warnings that it conflicts.
17:16:47 <bstinson> EPEL: as usual, EPEL-Rolling: Updated quarterly or at a dot-release, EPEL-edge: SIG Content, can conflict, no set update schedule
17:17:54 <maxamillion> Evolution: bstinson: at that point I kind of think the SIG should just maintain a COPR and say "hey, this is were you get our content built for EL6/EL7 and requires EPEL"
17:17:56 <Evolution> I'd prefer to keep the sig-specific content out of epel.
17:19:00 <Evolution> maxamillion: that's exactly the idea. except that we want packages common to the sigs to be widely available
17:20:02 <bstinson> s/SIG Content/SIG Dependencies/? that's closer to what i was getting at
17:20:19 <Evolution> I see it as a bit of a failing that right now people have to go to epel for some stuff, IUS for other stuff... repeat ad nauseum
17:20:58 <smooge> so I would like to see a bit more writeup on how an Edge would work and then how it would work in a Fedora workflow.
17:21:37 <smooge> I am also giving a 10 minute warning. We have one committee member in another meeting and another who is very ill.
17:21:53 <carlgeorge> When a package from epel-edge conflicts/replaces a stock package, should the name be different to prevent automatic upgrades?
17:22:09 <carlgeorge> i.e. mysql won't auto update to mysql55
17:22:23 <Evolution> smooge: I can work up how it would work with carlgeorge and bstinson, but I may need someone to translate that to fedora-workflow.
17:22:33 <smooge> I can help on that part
17:22:33 <Evolution> smooge: can I look to you for some help with that bit of the writing?
17:22:36 <Evolution> okay
17:22:38 * nirik has a ton of things to do, will try and look back
17:22:55 <smooge> ok I am going to table this topic to next meeting
17:23:05 <Evolution> carlgeorge: that's a bit of a hack/fix. it works, but it ain't pretty.
17:23:35 <smooge> #topic Open Flood (not that was any different from the last 10 minutes :))
17:23:50 <carlgeorge> Whats the alternative?  If a repo is left enabled, a package with the same name will be updated.
17:25:52 <smooge> ok my laptop wireless went down again.
17:26:20 <smooge> I need to reboot so will close this meeting out. My apologies for this
17:26:31 <smooge> #endmeeting