No meeting for 2015-07-31
by Stephen John Smoogen
Due to various people not being able to attend, the next EPSCO meeting
will be 2015-08-07.
Items to be discussed:
Python3
Alternative architectures.
--
Stephen J Smoogen.
8 years, 9 months
EPEL Steering Committee 2015-07-17
by Stephen John Smoogen
17:00:07 <smooge> #startmeeting EPEL
17:00:07 <zodbot> Meeting started Fri Jul 17 17:00:07 2015 UTC. The
chair is smooge. Information about MeetBot at
http://wiki.debian.org/MeetBot.
17:00:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea
#link #topic.
17:00:11 <smooge> #meetingname epel
17:00:11 <zodbot> The meeting name has been set to 'epel'
17:00:22 <nirik> morning
17:00:22 <smooge> #topic Meat and Greets
17:00:46 <smooge> Hello I am Stephen Smoogen and I am your majordomo
for today. Please say hi and hello.
17:00:54 <smooge> We will do a roll call to see if we have quorum
17:00:54 * nirik needs coffee... back in a min. ;)
17:01:04 <nirik> hello and hi smooge. :)
17:01:07 <Evolution> hi and hello
17:01:22 <smooge> bstinson, are you available?
17:01:29 <smooge> dgilmore, are you available?
17:01:36 <smooge> avij, are you available?
17:01:53 <bstinson> o/
17:01:56 <smooge> My apologies for not sending out an email about the
meeting this week.
17:02:31 <smooge> We have minimal quorum. I don't have an agenda so we
will just go over a couple of points.
17:02:36 <smooge> #topic Minimal agenda
17:02:59 <smooge> #info Other architectures for EPEL
17:03:32 <smooge> #info Python34 is in EPEL7
17:04:08 <smooge> #info Open Floo(d)r
17:04:32 <smooge> #topic Other Architectures for EPEL
17:04:52 * nirik is back from the coffee machine
17:04:58 <smooge> #info s390 request for builds in EPEL.
17:05:08 <smooge> #info i386 via CentOS i386
17:05:27 <smooge> #info ppc64le/arm64
17:06:07 <smooge> The s390 item I believe will have to be discussed
better at FLOCK?
17:06:51 <smooge> Evolution, bstinson what is the status of CentOS
i386 for EL-7?
17:07:15 <Evolution> smooge: it's built and in beta for feedback. it
will likely be gold soon
17:07:30 <Evolution> barring a blocker bug, it'll be gold shortly
17:09:07 <smooge> ok cool
17:09:26 <smooge> I guess at that point we would look at how we are
going to import and build against it.
17:10:24 <Evolution> from reading the notes of the last minutes, that
might be tricky
17:12:18 * nirik nods
17:12:30 <Evolution> smooge: there was something about koji-shadow not
being an option iirc
17:12:35 <Evolution> or am I mis-remembering.
17:12:55 <Evolution> some of this can hopefully be addressed at flock
when folks (lookin at you bstinson!) are face to face.
17:13:27 <smooge> I don't know myself. That is definately a
releng/koji developers in a cage match thing
17:13:46 <smooge> I just sit outside and wait for the match to be over
17:13:48 <nirik> I don't think koji-shadow will work, but I don't
recall the specific reason why. ;)
17:14:24 <Evolution> aarch64 will also be up on that list.
17:14:32 <Evolution> we'll be coming out of beta with it quite soon
17:15:13 <smooge> nirik, is there a non-koji shadow?
17:15:17 <Evolution> the testing is done, and essentially it's just
the signing/distribution mechanics to be fiddled with.
17:15:26 <nirik> yeah, and there's at least some interest in s390 and ppc64le
17:15:29 <smooge> I mean koji-public
17:15:54 <smooge> cool
17:16:00 <nirik> smooge: not sure what you mean... we could run
seperate kojis for things, but then the trick is keeping them all in
sync
17:16:29 <nirik> oh yeah, thats it. koji-shadow doesn't work with
external repos (which we use in epel)
17:16:36 <smooge> nirik, so I thought koji-shadow was basically the
mechanism to allow for the RHEL bits to be seen by koji but not the
rest of the world
17:16:41 <nirik> no
17:16:45 <smooge> ah ok
17:16:51 <smooge> so never mind what I was saying
17:16:53 <nirik> koji-shadow is a set of scripts secondary arches run.
17:17:05 <nirik> it watches the primary builds and tries to do them the same way
17:17:20 <nirik> same versions/buildroot, etc
17:17:40 <nirik> but with epel, all the rhel stuff is in external
repos, so it could not tell when a rhel thing changed.
17:17:59 <nirik> we could switch x86_64/ppc64 over to just using centos... ;)
17:18:12 <nirik> but some people might not like that
17:18:41 <bstinson> another win would be some sort of thing that
watches external repos (we need to work on something like that on the
CentOS side anyways)
17:18:53 <bstinson> but that's not a short-term solution
17:18:57 <nirik> yeah
17:20:27 <nirik> so, put on those thinking caps and perhaps we will
come up with some plan. ;)
17:22:12 <smooge> nirik, so what makes a repository external versus
internal to a koji-shadow
17:22:17 <Evolution> see, this is why I like bstinson....
17:22:26 <Evolution> he just keeps signing himself up for more work
17:22:35 <bstinson> heh, you have no idea...
17:22:40 <nirik> smooge: external repos are listed in koji as just
https://whateverhost/repo
17:22:41 <bstinson> some day i'll learn
17:22:45 <smooge> Evolution, I actually heard him say "Evolution
can... " when he said that
17:22:51 <nirik> internal repos are ones it builds itself out of local packages.
17:23:34 <smooge> ah ok so the koji would need to be able to build all
of "CentOS i386 7" for it to work.. or am I jumping to the wrong
conclusion too
17:23:44 <nirik> so if foo was rebuilt for say epel7, koji knows it
needs to make a new repo with that package in it... but with external
it just loads those when doing builds, it has no way to know or care
whats in them
17:25:22 <nirik> well, the issue with arches is that koji doesn't know
how to get different stuff from different places.
17:25:42 <Evolution> in the case of x86, there would be collisions as well.
17:25:56 <nirik> if 'foo' is in rhel x86_64, and centos i386 and
wherever s390, it can't get the right foo from all of those, it has to
have 1 place it knows foo
17:26:37 <nirik> koji wasn't really setup with this case in mind. ;)
17:27:23 <Evolution> the 'rebuild' usecase is a bit of a snowflake for
a variety of reasons...
17:27:59 <nirik> yeah
17:28:19 <smooge> I say we just move epel to coprs and be done with it.
17:28:41 <Evolution> smooge: you can't joke about that stuff. someone
will hear it and then it'll happen
17:28:44 <Evolution> :-P
17:28:55 * smooge should stop drinking Bourbon and Mylanta before noon
17:29:17 <Evolution> hey, that's my 'building golang for aarch64' cocktail
17:29:48 <smooge> I call it Creme De Minthhhh
17:30:03 <smooge> so anything more on this until Flock?
17:30:32 <Evolution> I don't think so. most all the secondary arch
bits have some sticking point that require releng folks to curse.
17:30:38 <smooge> #topic Python34 in EL7
17:31:17 <smooge> OK this looks like it went golden and now it is a
matter of doing the many packages just so we can start the dance again
with python35 at Xmas
17:31:19 <nirik> I think the main thing to talk about here is the
packages in rhel already that are python2 only
17:31:42 <smooge> sounds good
17:31:45 <smooge> or bad...
17:32:07 <nirik> I am leaning toward suggesting new packages... python3-foo
17:32:18 <nirik> will require reviews, but will just be a lot less messy
17:32:31 <bstinson> do we need the FPC to comment on that?
17:32:34 <nirik> and then versions won't be tied to rhel versions
17:33:00 <nirik> I don't think so... it's just a epel
preference/policy. I guess it might not hurt tho
17:33:04 <Evolution> nirik: I like/hate that approach.
17:33:30 <Evolution> it makes this simpler in a number of ways, but
the review process will be fun
17:33:32 <nirik> well, if we don't do that, it means we will have to
keep packages lower than or the same as their rhel versions
17:33:49 <Evolution> no, I totally agree it's the way to go.
17:33:58 <Evolution> but the reviews...
17:34:22 <nirik> well, we don't need to do every package out there,
only ones people are actually interested in and willing to maintain
17:34:56 <bstinson> MUST: be a new package named python3-<foo>,
SHOULD: rebase from fedora's master to make review easier
17:35:19 * nirik nods.
17:35:47 <smooge> speaking of reviews.. do we have a backlog of ones?
How do we tell
17:36:38 <nirik> http://fedoraproject.org/PackageReviewStatus/EPEL.html
17:39:23 * nirik closes some of those
17:39:40 <Evolution> I need dgilmore to finish up the review of mine.
17:39:53 <Evolution> or transfer it to someone else. unsure how that
works exactly
17:40:23 <smooge> I am not sure myself
17:41:03 <smooge> that was what I was wondering was how many
'outstanding' reviews might be there that are in a mixed state..
started but not finished as I would like to figure out how to clean
that house also.
17:41:40 <nirik> not easy to tell. ;)
17:42:21 <nirik> some/many are in the general review queue.
17:42:45 <smooge> ah ok.. I guess it is a time to dive in and do some things
17:42:51 <smooge> in my copious spare time.
17:42:57 <bstinson>
https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
17:42:58 <smooge> I will do it while you guys are at flock
17:43:30 <bstinson> looks like we need a comment in the bug for a
weeks time before it can be reassigned
17:44:45 <smooge> so back to the topic at hand. I think there is
general agreement that packages for python3 will need a 'new' package
and review or EPEL
17:46:00 <bstinson> +1 (with the expectation that i'll have to take a
few reviews)
17:46:04 <nirik> +1
17:47:03 <Evolution> +1
17:47:04 <smooge> Evolution?
17:48:14 <smooge> sorry
17:48:17 <smooge> irc puked on me
17:48:25 <Evolution> no worries. I delayed a bit.
17:48:30 <smooge> #agreed python3 packages will need new package
python3-foo which will require a review but if based off existing
fedora package should be 'faster' to review than from scratch.
17:48:50 <smooge> #topic Open Flood
17:49:19 <smooge> OK 12 minutes to the top of the hour. Any open
items, complaints, witch burnings, or drinking tips?
17:50:35 <smooge> .... puts away his lit torch and kerosene
17:50:50 <smooge> .... closing in 2 minutes
17:50:59 <nirik> toss the drinks on the complaining witches and burn them?
17:52:03 <smooge> #endmeeting
møte: sources. © Copyright 2015 Chaoyi Zha, Ralph Bean, and others.
--
Stephen J Smoogen.
8 years, 9 months
EPEL Steering Committee Meeting 2015-07-10
by Stephen John Smoogen
http://meetbot.fedoraproject.org/fedora-meeting/2015-07-10/epel.2015-07-1...
http://meetbot.fedoraproject.org/fedora-meeting/2015-07-10/epel.2015-07-1...
8:03:30 <smooge> #startmeeting epel
18:03:30 <zodbot> Meeting started Fri Jul 10 18:03:30 2015 UTC. The
chair is smooge. Information about MeetBot at
http://wiki.debian.org/MeetBot.
18:03:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea
#link #topic.
18:03:38 <smooge> #meetingname epel
18:03:38 <zodbot> The meeting name has been set to 'epel'
18:03:52 <smooge> #chairs nirik dgilmore Evolution bstinson avij
18:03:59 <nirik> morning everyone
18:04:02 <smooge> #chair nirik dgilmore Evolution bstinson avij
18:04:02 <zodbot> Current chairs: Evolution avij bstinson dgilmore nirik smooge
18:04:02 <bstinson> hi all
18:04:11 <smooge> #topic Meats and Greets
18:04:35 <smooge> hi I am your majordomo for the EPSCO meeting today.
18:04:43 <avij> hello, long time no see. I was travelling for the last
two weeks, back home today.
18:04:49 <smooge> hi avij
18:05:11 <nirik> yeah lots of folks have been out or traveling or the like
18:05:18 <nirik> tis the season
18:05:58 <smooge> ok current chimed in steering committee members:
avij, bstinson, and nirik. We have a bare quorum
18:06:07 <smooge> dgilmore, you available?
18:06:25 <smooge> #topic Outstanding Issues
18:06:46 <smooge> OK there has not been a meeting for a while so I am
not sure what topics are currently outstanding
18:07:17 <dgilmore> smooge: yeah
18:07:44 <smooge> Oh mirrormananger
18:08:21 <smooge> There were a lot of reports about bad mirrors a
while ago. puiterwijk worked on a script to try and determine what
mirrors and such were happening and also a script to fix broken
pickles
18:08:31 <dgilmore> smooge: ppc64le, i686, aarch64 support also
18:08:39 <nirik> as far as I know we have had no server side issues
since the ones a few weeks ago
18:08:56 <smooge> We didn't see any last week when I was pinging
people who complained on #centos.
18:09:08 <smooge> and on #epel so I think the issues are better now
18:09:43 <smooge> I don't know of any other issues...
18:09:48 <smooge> so time for new topics
18:09:53 <puiterwijk> dgilmore: secondary arches are supported by my
script and report as OK on my last daily run
18:10:02 <nirik> if anyoone has mirror issues, please report them. ;)
18:10:07 <smooge> #topic Secondary architectures (or whatever they
should be called)
18:10:17 <dgilmore> puiterwijk: nothing to do with mirrormanager
18:10:34 <dgilmore> puiterwijk: my point was to do with supporting
those arches in epel7
18:10:35 <smooge> There have been a couple of requests for building
architectures which aren't ones we cover
18:10:54 * nirik is still not sure of any good plan for some of these.
18:11:06 <dgilmore> nirik: me either
18:11:15 <nirik> aarch64 and ppc64le we could possibly have builders for.
18:11:17 <smooge> #info other arches: s390, ppc64le, i386, aarch64,
arm32, ppc64be
18:11:35 <nirik> i686 is centos only
18:11:53 <nirik> s390 we would likely have no local builders for
18:11:57 <smooge> and so would be arm32
18:12:23 <smooge> s/likely/definitively and absolutely/
18:12:46 <dgilmore> smooge: we should get a z series box in phx2
18:13:13 <smooge> dgilmore, we should also get a moon base. let me
tell you which one is more likely :)
18:13:22 <dgilmore> I do not know the best way to support the different arches
18:13:26 <markwkm> has the hercules emulator been considered for s390 builds?
18:14:04 <dgilmore> markwkm: it could be possible. but massively slow
18:14:04 <nirik> we don't normally allow emulated builds
18:14:18 <nirik> well, fedora doesn't anyhow
18:15:40 <nirik> perhaps we could try and come up with a plan for
these at flock? but not sure centos and other interested parties would
be there I guess.
18:16:08 <smooge> well someone from centos was going to be there from
the releng/centos meeting that sgallagh wanted to start
18:16:10 <bstinson> for sure kbsingh and I will be there
18:16:18 <markwkm> i have access to z hardware and would like to see
how i could help
18:16:33 <dgilmore> okay lets talk at flock on how to add other arches
18:16:35 <smooge> oh great.. I can't go to a fricking FLOCK and
finally kbsingh can come over
18:16:55 <dgilmore> smooge: I think you two are teh same person
18:16:59 <dgilmore> never seen together
18:17:03 <smooge> could be..
18:17:06 <bstinson> ^ this is true
18:17:23 <smooge> we even sound alike
18:18:19 <smooge> so there are a couple of issues here that I would
like to outline in this meeting so that people reading the mail later
have an idea WHY it has to be put off until Flock.
18:18:30 <dgilmore> smooge: sure
18:19:08 <smooge> The first issue I see is what I would call 'Koji
fragility' but probably has a better name with releng
18:19:53 <smooge> If a builder/architecture is unavailable for a
particular release (epel-7, etc) all builds for that release are
blocked
18:20:36 <smooge> So if we have an s390 builder in amsterdam that we
can't get to for some reason... all of EPEL for that release are
blocked
18:20:56 <smooge> dgilmore, did I phrase that correctly?
18:21:17 <dgilmore> smooge: sure, I do not see that as a big issue though
18:22:31 <smooge> The second issue is that of chain of evidence. We
control all our builders for primary architectures so that if a
builder is tampered with we have outside control on it.
18:23:05 <dgilmore> smooge: that would need to happen for builders for
any architecture where a builder is remote
18:23:17 * nirik dislikes remote builders for that reason
18:23:17 <dgilmore> smooge: and the only possible remote arches is s390
18:23:49 <smooge> Several of the architectures would require us to
trust the outside s390 isn't tampering in the builder
18:24:11 <smooge> s/Several of the architectures/A remote s390/
18:25:33 <dgilmore> to me the trickiest thing is that the way koji
does its things we need the nvrs to match up exactly
18:25:51 <smooge> The third issue is koji and download disk space. The
number of packages for each platform would require us to budget for
more disk space than what we had
18:25:58 <dgilmore> and if we add 32 bit x86 we may have issues with
the builds CentOS has patched
18:27:04 <smooge> Fourth, koji has certain NVR needs for build
requirements. This may be affected by the way 32 bit x86 is patched by
CentOS
18:27:26 <smooge> any other issues ?
18:27:56 <nirik> for rhel based ones, they may not have the same
package set as x86_64
18:28:10 <nirik> (this is a long ongoing issue with ppc64 and such,
but worth mentioning)
18:28:26 <smooge> There is another issue I just realized.
18:29:28 <smooge> Sixth, CentOS does not have seperate channels like
RHEL does for packages. This means that they have packages we don't
have in our build root due to the mixing of
Workstation/Server/Cluster/ etc while we only have Server
18:29:32 <dgilmore> nirik: less of an issue now but yeah
18:29:48 <smooge> Seventh, different arches have different package sets
18:31:24 <smooge> OK I think that covers the major issues with
'secondary architectures'
18:31:50 <dgilmore> smooge: mostly yeah
18:32:07 <smooge> I expect there are other issues but those seem to be
the major stoppers
18:32:13 <smooge> are there others dgilmore ?
18:32:45 <dgilmore> smooge: likely. but right now I am not thinking of any
18:32:56 <smooge> ok cool. we can add them later.
18:33:30 <smooge> #info There are at least 7 major problems which need
to be worked through so that other architectures can be added to EPEL.
18:33:53 <dgilmore> smooge: I do not see a lot of them as problems
18:33:55 <smooge> #info there will be a meeting at FLOCK between
Releng/CentOS and others to discuss how to work on these
18:33:59 <dgilmore> but sure
18:33:59 <dgilmore> \
18:34:06 <bstinson> (CentOS hat on) I'll make sure we talk through
some of these on our end before FLOCK
18:34:47 <smooge> #info FLOCK is https://fedoraproject.org/wiki/Flock
August 12 -> 15 in Rochester NY
18:35:11 <smooge> ok any other items for the committee?
18:35:23 <smooge> #topic Open Flood
18:35:48 <nirik> I had a few things to mention...
18:35:55 <nirik> python34 is in epel7 stable now.
18:36:06 <nirik> epel-rpm-macros is in epel7 stable also.
18:36:40 <nirik> There's some movement to add it to el5/el6 too to
allow us to make macros more standard between fedora and epel
18:37:00 <nirik> thats all I had I think
18:38:24 <dgilmore> nirik: do we need to update comps to always
include epel-rpm-macros in buildroots?
18:38:43 <nirik> yes, that would be good.
18:38:50 <nirik> wasn't sure the status on that
18:38:52 <dgilmore> will get that done
18:39:17 <smooge> thanks nirik. that is big news on the python34 route
18:40:37 <dgilmore> nirik: koji is done
18:40:42 <bstinson> hrmm, was it not in the buildroots before?
18:40:42 <nirik> dgilmore: cool.
18:41:00 <nirik> bstinson: the srpm build root probibly not.
18:42:03 <bstinson> ah, that's probably why it didn't create the
/usr/bin/python3 symlink (just noticed that a couple of days ago)
18:42:33 <nirik> not sure thats related, but we can investigate.
18:42:42 <dgilmore> nirik: it was not
18:44:22 <dgilmore> comps is done
18:44:32 <dgilmore> will go out in the next push started after now
18:50:44 <smooge> ok I think we can close this meeting out.
18:50:47 <smooge> #endmeeting
møte: sources. © Copyright 2015 Chaoyi Zha, Ralph Bean, and others.
--
Stephen J Smoogen.
8 years, 9 months
2015-07-03 meeting cancelled
by Stephen John Smoogen
It is a holiday for most people in the US so most of the EPEL SCO are
supposed to be away from keyboard. The next EPEL SCO meeting will be:
2015-07-10
--
Stephen J Smoogen.
8 years, 10 months