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

EPEL SIG Log -- 05 Sept 2007



[18:01] *** You set the channel topic to "EPEL Sig meeting".
[18:01] <nirik> afternoon stahnma (or evening or morning)
[18:01] <stahnma> afternoon/evening
[18:01] <stahnma> ping dgilmore, Jeff_S, knurd, mmcgrath, nirik,
stahnma, quaid and everyone interested in EPEL
[18:01] * nirik wonders if anyone else is around. ;)
[18:02] <stahnma> me too
[18:02] <stahnma> I thought the new time might work out better...we'll see
[18:02] <rsc> RobertScheck
[18:03] <stahnma> mmcgrath: ? , Jeff_S, quaid?
[18:04] <stahnma> ok
[18:04] <stahnma> we don't have quarum
[18:04] <nirik> yeah, doesn't seem so. ;(
[18:04] <stahnma> no voting tonight
[18:04] <stahnma> not that anything was up on the table
[18:04] *** You set the channel topic to "EPEL Meeting | push to
stable easily -- knurd".
[18:04] <stahnma> knurd is obviusly not here
[18:04] <stahnma> but there has been discussion on list
[18:05] <nirik> yeah, it's the middle of his night. ;)
[18:05] <stahnma> yup
[18:05] <stahnma> are we making progress here?
[18:05] <stahnma> I haven't kept up with it 100%
[18:05] <stahnma> rsc: feel free to participate as much as you want
[18:05] <nirik> well, I think we decided to do monthly pushes of new
packages only...
[18:05] <stahnma> or anyone in the peanut gallery :)
[18:05] <mmcgrath> pong
[18:06] <jwb> er
[18:06] <nirik> I have the info on how to do pushes now, but haven't
had time to try one.
[18:06] <stahnma> ok
[18:06] <jwb> monthly pushes for new packages?
[18:06] <nirik> yeah.
[18:06] <jwb> why only monthly?
[18:06] <stahnma> to maintain stability
[18:06] * mmcgrath was fine with quartly or whenever RH did it honestly.
[18:06] <rsc> stahnma: I am already EPEL maintainer, isn't that enough?
[18:06] <stahnma> EL doesn't introduce new packages ad hoc
[18:07] <mmcgrath> its not like we keep the testing repo private.
[18:07] <stahnma> rsc sure is
[18:07] <nirik> well, we could possibly do more often, the thought is
that it might be pretty time consuming
[18:07] <stahnma> I just saw you popped in at the start of the
meeting, and thought you might something to add (no worries)
[18:07] <rsc> stahnma: no problem. I'll shout, if there's something
[18:08] <stahnma> right now while the repo is still growing pushing
new packages into it seems to make sense
[18:08] <stahnma> though using epel-testing also makes sense
[18:08] <rsc> btw, is there a real chance for getting koji for EPEL?
[18:08] <stahnma> either way, as long as progress is being made on
list, I think we can move on
[18:08] <stahnma> rsc: not near term
[18:08] <stahnma> moving on?
[18:09] *** You set the channel topic to "EPEL Meeting | do more on
the list and less in the meetings; "Power to the people with no
delay." aka "Steering Committee's are slow and old style" -- all".
[18:09] <stahnma> I think knurd snuck this one in here
[18:09] <stahnma> It's a good reminder
[18:09] <stahnma> lists don't have timezones to work around
[18:09] <nirik> yeah. It's hard to remember to make sure and reply to
all the list stuff, but I think it's a good thing to try for...
[18:09] <stahnma> I don't think there's a lot of comments on this one....
[18:10] <nirik> we should also remember to send things to the list
when they are talked about on irc or whatever.
[18:10] *** You set the channel topic to "EPEL Meeting | MetaData for
all Packages available to contributors. -- stahnma".
[18:10] <stahnma> I had a little bit of time today to work on this
[18:10] <stahnma> but didn't get very far
[18:10] <stahnma> I will continue working on it tonight
[18:10] <stahnma> one issue is that my enterprise account may not have
access to all channels
[18:11] <stahnma> it would be wonderful to get a real RHN account from
RH for EPEL
[18:11] <stahnma> or at least some representation with a direct link to RHEL/RHN
[18:11] <mmcgrath> for what purpose?
[18:11] <stahnma> to see what packages are stepping on items offered by RH
[18:12] <stahnma> also, a new issue was brough up on list about
pear/php stuff in EL4, since RH ships a moving AMP stack on RHEL
[18:12] <stahnma> how does a maintainer build PHP packages in EL
[18:13] <stahnma> the people I have spoken with in #rhel and #rhn
about epel often sight concern over "stepping on RHN"
[18:13] <nirik> they are just like any other package... but yeah, no
idea if they are already in some channel from RHEL
[18:13] <nirik> I'd be happy for us not to step on them, but it's not
clear how we can find out if we are or not.
[18:13] <stahnma> nirik: that's the issue.  I will continue to look into it
[18:14] <stahnma> I assume a solution is out there, and we may be
making it more complicated than it really is
[18:14] --> bpepple|lt has joined this channel
(n=bpepple|@rrcs-70-61-160-147.central.biz.rr.com).
[18:14] *** You set the channel topic to "EPEL Meeting |
[:EPEL/CommunicationPlan:Communication plan] for enterprise
customers/ISVs/IHVs -- stahnma, quaid".
[18:14] <stahnma> sorry, I forgot to ask if we can move on
[18:14] <nirik> well, I would expect redhat has a way of determining
if something is already offered by them or not.
[18:14] <stahnma> (I'm new here)
[18:14] <stahnma> :)
[18:15] <nirik> anyhow, yeah, move on
[18:15] <stahnma> I have little updates on this.  Again, figuring out
the RHN conflicts will help the communcation/adoption of EPEL
[18:15] <stahnma> my company is moving RHEL 5 builds to EPEL though :)
[18:15] <nirik> cool.
[18:16] <stahnma> quaid isn't present, so that's all I have
[18:16] <stahnma> this is looking like it coudl be quite a short meeting
[18:16] * nirik would be ok with that.
[18:16] <stahnma> job decription is also quaid
[18:16] *** You set the channel topic to "EPEL Meeting | General Discussion".
[18:17] * mmcgrath has nothing
[18:17] <nirik> I have a item or two real quickly...
[18:17] <stahnma> dgilmore had mentioned he would like to step down
from EPEL on the list
[18:17] <stahnma> do we solicit for another spot to be filled?
[18:18] <stahnma> I can bring it up on list
[18:18] <stahnma> nirik: what do you have?
[18:18] <nirik> I have added epel4 and epel5 audit files in the
fedora-security setup. I generated them by looking at the fc7 lists
and putting in only those packages that exist in epel4 or epel5. Now
comes the fun part of auditing everything to see what security updates
we need/are missing.
[18:18] <nirik> I have slowly started on that. If anyone would like to
help, let me know.
[18:18] <stahnma> do you have any documentation describing the process?
[18:18] <stahnma> I am not familiar with it
[18:19] <nirik> yeah, there is a readme and such, I can dig it up.
[18:19] <nirik> Basically we have a file that has each CVE listed and
then if our package is vunerable or not.
[18:19] <stahnma> I can try to help, but you can also solicit on list.
[18:20] <nirik> so something like:
[18:20] <nirik> CVE-2005-4803 version (graphviz, fixed 2.2.1)
[18:20] <nirik> so the graphviz in epel5 is newer than the version it
was fixed in (2.2.1) so it's ok.
[18:20] <stahnma> can that  process be automated?
[18:21] <nirik> possibly, but it's pretty complex.
[18:21] <stahnma> ok
[18:21] <nirik> There is newer version, there is backported patch, not
vunlerable because it's a windows thing, etc.
[18:21] <stahnma> ah yes, backporting
[18:21] <nirik> but we do need to track security well on EPEL.
[18:21] <stahnma> that would make things hard
[18:22] <stahnma> agreed
[18:22] <nirik> I can solicit the list... although it's currently in
an area that requires you to be in the security team to check in
changes.
[18:22] <stahnma> ah
[18:22] * stahnma is not on the security team
[18:22] <nirik> I can keep working on it too.
[18:23] <stahnma> ok
[18:23] <stahnma> any other business from anybody?
[18:23] <nirik> Also, a somewhat related item:
[18:23] <nirik> looking at security, I note there are a number of
packages that have branches for epel, but don't seem to have been
built.
[18:23] <nirik> I guess I can generate a list and bug people on the
list about it.
[18:24] <stahnma> I would assume some people are still waiting on deps
[18:24] <stahnma> but it might be time to ping them
[18:24] <nirik> mediawiki has a el5 branch, but doesn't appear to be
in the repo... for example.
[18:24] <stahnma> yeah, and I would love it :)
[18:24] <stahnma> bug reports are probably ok on that
[18:24] <nirik> libmodplug was another. I think there were some more too.
[18:25] <nirik> anyhow, just thought I would mention it.
[18:25] * nirik has no more.
[18:25] <stahnma> I will close meeting in 10
[18:25] <ivazquez> I have something I'd like to ask about.
[18:25] <stahnma> ok
[18:25] <stahnma> I won't close :)
[18:25] <ivazquez> EPEL5 has lapack 3.1.1, but doesn't EL5 have lapack 3.0?
[18:27] <stahnma> ok, I am not familiar with lapack
[18:28] <nirik> yeah, seems to be the case. ;(
[18:28] <ivazquez> AIUI, EPEL has not going to replace packages in the
base EL set.
[18:28] <ivazquez> *was
[18:28] <nirik> this gets back to trying to make sure we don't step on RHEL
[18:28] <stahnma> EL 5 has 3.0-37
[18:28] <stahnma> from what I can see in RHN
[18:29] <stahnma> nirik, can shoudl this be filed as a bug with you?
[18:29] <nirik> well, I guess we need to just remove it... ;(
[18:29] <stahnma> or more on the infrastructure side?
[18:29] <nirik> yeah, we should come up with a way to get repo
requests done/tracked.
[18:30] <stahnma> maybe we should also bring that up on list
[18:30] <nirik> perhaps we could setup a epel traq instance? mmcgrath ?
[18:30] <stahnma> or use the same trac?
[18:30] <mmcgrath> buhhh
[18:30] <nirik> yeah, or just use infrastructures...
[18:30] <nirik> :)
[18:31] <mmcgrath> for what?  when files need to be removed?
[18:31] <nirik> yeah, packages removed from the repo...
[18:31] <stahnma> or general issues with epel infrastrcuture?
[18:31] <mmcgrath> how is it done im fedora?
[18:32] * stahnma isn't sure :)
[18:32] <nirik> mail to releng?
[18:32] <jwb> yes
[18:33] <stahnma> are any epel-infrastructure people also in releng?
[18:33] <nirik> so we could just also make a epeleng alias?
[18:33] <jwb> who's the epel infrastructure people?
[18:34] <mmcgrath> for epel we should probably email epel_signers-members fp o
[18:34] <stahnma> jwb trumps me with his logic
[18:34] <jwb> that was a real question.  but i think the answer is no
[18:34] <jwb> rel-eng is me, spot, rdieter, f13, jeremy, and warren
[18:34] <stahnma> yeah, I don't know
[18:35] <mmcgrath> there's no difference between the epel and normal
fedora 'infrastructure' people.  but epel doesn't have any release
engineers.  The closest thing is the signers.
[18:35] <stahnma> ok
[18:35] <stahnma> well, as long as a task gets handled in a timely
maner, the process isn't all that important
[18:35] <nirik> yeah, but it would be good to have a process we can
point people at...
[18:35] <stahnma> hopefully these needs will rarely arise
[18:35] <stahnma> true
[18:36] <nirik> so they don't just give up and it never gets done.
[18:36] <stahnma> yes
[18:36] <stahnma> should the official process just be to bring it up
on epel-devel-list?
[18:36] <stahnma> it seems easy enough, and probably effective
[18:37] <stahnma> brb
[18:37] <nirik> so, for now, how about email to epel_signers-members@ ?
[18:37] <mmcgrath> WORKSFORME
[18:37] <nirik> good catch on that ivazquez.
[18:37] <-- kanarip has left this server (Remote closed the connection).
[18:37] <nirik> sure, that would be fine too...
[18:38] --> kanarip has joined this channel (n=kanarip fedora/kanarip).
[18:38] <stahnma> ok
[18:38] <stahnma> any other items?
[18:38] * stahnma will close the meeting in 10
[18:38] <stahnma> -- MARK -- Meeting end
[18:38] <nirik> ivazquez: is there a bug filed on that lapack thing?
If not we should so the maintainer knows whats going on.



Todos:
* Continue to investigate Metadata/package conflicts with RHN/EL and
EPEL -- stahnma
* Security setup for EPEL4-5, nirik will send out more information on
list.  -- nirik
* How to notify the EPEL team if a package should be removed due to
conflicting with EL. -- nirik
* Evaluate meeting time again.  Same people that are normally there,
were there.  Minus Knurd.


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