Log from last EPEL SIG meeting
by Thorsten Leemhuis
= Meeting 20070325 =
[[TableOfContents]]
== Attending ==
* dgilmore
* mmcgrath
* nirik
* quaid
* stahnma
* thimm
* thl
== Summary ==
* RHEL5 final should be on the builders soon (maybe already when you
read this); thl will announce to Fedora contributors to actually start
to build for EPEL5 -- seems to him a lot of people wait for a "Go"
signal. The packages currently in EPEL5 probably need a rebuild; it was
discussed to simply delete the repo and build the packages again, but
between the meeting and writing the logs this issue was raised again on
the list
* repo layout -- outlined in
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenan...
might need updates/modified tools; anyone willing to help?
* shortcut for branching ; dgilmore has something locally; for now
send him an email or irc ping and i can ping all of a owners packages ;
including a list of packages might be helpful in case you don't want all
of your packages branched
* we sooner or later need scripts that check upgrade paths,
repoclosure and similar stuff (like: making sure no packages enter the
repo that are part of the base); reuse the Fedora scripts? should work,
but they probably need adjustments and enhancements ; anyone willing to
help?
* EPEL Steering Committee proposal
http://fedoraproject.org/wiki/ThorstenLeemhuis/EPELSteeringCommittee ;
small details were mentioned and added to the proposal; will get send to
fedora-maintainers (happened already) and then to FESCo for further
discussion and ratifying
* New meeting time -- it was agreed on to meet on Wednesday at 17:00
UTC in the future
== Full Log ==
{{{
00:00 < dgilmore> | thl, thimm, stahnma, mmcgrath, quaid, spot, jima.
EEPLE meeting ping
00:00 < mmcgrath> | pong
00:00 --- | thl has changed the topic to: EPEL meeting
00:00 < thl> | dgilmore, pong
00:01 < dgilmore> | http://fedoraproject.org/wiki/EPEL/Schedule
schedule
00:01 * | nirik is here too.
00:01 < thl> | dgilmore, what the RHEL5 on builder status?
00:01 < dgilmore> | sorry nirik forgot to ping you too
00:02 < nirik> | no worries. ;)
00:02 < dgilmore> | thl: Im going to make it happen today
00:02 < thl> | dgilmore, great
00:02 < thl> | well, that creates two questions afaics:
00:02 * | mmcgrath notes we still don't have clearence to
do that.
00:02 < nirik> | for testing is the centos beta pretty close to
the same as whatsa in el5?
00:02 < thl> | a) shall we tell everybody to actually start for
real?
00:02 < thl> | b) rebuild everything again?
00:02 --> | thim1 (Axel Thimm) has joined #fedora-meeting
00:02 <-- | thim1 has quit (Client Quit)
00:02 < thl> | nirik, centos beta is rhel5beta2
00:02 < mmcgrath> | I think b) would be good to do if for no other
reason then to help test koji.
00:03 < thl> | nirik, but that should be good enough; and the
final should be out soon afaics
00:03 --> | thim1 has joined #fedora-meeting
00:03 --> | thim1 is Axel Thimm
00:03 * | dgilmore has been stuck in koji for last couple
of days
00:03 < nirik> | ok. Does a rebuild mean bump release on everything?
00:03 < dgilmore> | nirik: yep
00:03 < thl> | nirik, yes, but we can use the script
00:03 < thl> | mmcgrath, -ECanFollow
00:03 < nirik> | also, only el-5? or el-4 as well?
00:04 < thl> | mmcgrath, do the builders use koji already?
00:04 < dgilmore> | nirik: only EL-5
00:04 < thl> | nirik, what dgilmore said
00:04 < nirik> | ok
00:04 < thl> | nirik, I can do that
00:04 < mmcgrath> | thl: not yet but they're close. When were you
thinking the rebuild would happen?
00:04 < dgilmore> | thl: today or toomoorow they will have koji and
plague
00:04 < nirik> | we also might want to make sure that everything
thats in el4 is also in el5, and/or was moved into core, or some other
good reason why it's not in there...
00:05 < thl> | mmcgrath, I'd say we should annouce it once, so
people that want to do the rebuild theirselfs can do; then we can script
the rest
00:05 < mmcgrath> | dgilmore: how close is it to actually being put
into a package build -> sign -> move to mirror.
00:05 < thl> | dgilmore, sounds fun :)
00:06 < dgilmore> | mmcgrath: right now all id need to do is setup a
cron job to rsync results to buildsys
00:06 < mmcgrath> | Cool
00:06 < thl> | so, shall we tell people to actually start now?
Seems some fedora contributors are waiting for a "go"
00:06 < dgilmore> | mmcgrath: I need to get on lmacken and get bohdi
working
00:06 < thim1> | I missed the first couple of minutes (irc kicked
me out)=> why rebuild?
00:06 * | quaid is a'lurking
00:06 < mmcgrath> | <nod>
00:07 < thl> | hi thimm thim1
00:07 < mmcgrath> | thim1: The current packages are built against betas.
00:07 < dgilmore> | thim1: to have things linked against RHEL5 final
00:07 < thl> | thimm, sopme people feared there might be
problems as we build against beta1 until now
00:07 < thl> | z00dax did, and he has a point afaics
00:07 < thim1> | I didn't know that, I thought we were riding on GA
00:07 < mmcgrath> | Personally I'm not worried about it, but I don't
want people coming up to us with "such and such package doesn't work.
Must be because it was compiled against the beta"
00:08 < thim1> | I agree with rebuilding against GA
00:08 < thim1> | That's why GA != beta
00:08 < thim1> | :)
00:08 < thim1> | But do we need to bump releases?
00:08 < thl> | I'll announce that; wait some days, and
script-rebuild the rest
00:08 < dgilmore> | so next on the list is final repo layout
00:08 < thim1> | Can we assume that EPEL was a sandbox and rebuild
on the same NVRs?
00:08 < dgilmore> | thats going to take some work to make it happen
00:09 < dgilmore> | thim1: we could if we delete everything first
00:09 < mmcgrath> | honestly since we're still not 'official' I'd be
fine deleting all the bin's we currently have.
00:09 < thim1> | Lots of specfiles are now in sync Fedora <->
EPEL, would be sad to frok them all
00:09 < thl> | dgilmore, I'd still like to know if should Fedora
controbutors to actually start now
00:09 < thl> | mmcgrath, +1
00:09 < thim1> | I'd go with deleting and rebuilding
00:09 < thim1> | w/o bumping releases
00:09 < mmcgrath> | it just seems less.... murky :-)
00:10 < thim1> | Well, we're not started yet
00:10 < thim1> | ;)
00:10 < dgilmore> | that can be done
00:10 < thl> | mmcgrath, but then you or dgilmore have to do it
afaics
00:10 < thl> | I don#t think i have the permissions everywhere
to do that
00:10 < thim1> | NExt time we should consider using a disttag of
el4.92 for example
00:10 < dgilmore> | thl: id like to wait until we have RHEL5 final
but then open the flood gates
00:10 < mmcgrath> | I'm not even sure I have permission to do that.
00:10 < mmcgrath> | I still don't have direct access to the main
mirror (I think I'm caught up in a ticket queue)
00:10 < thl> | dgilmore, sure, that what I mean; but if you
reall do it today, then we could annouce "go" soon
00:11 < dgilmore> | thl: sure
00:11 < dgilmore> | thl: what do you want me to do?
00:11 < thl> | dgilmore, k, then I'll annouce it when you
annouce the RHEL5 GA is in place
00:11 < thl> | dgilmore, well, the rebuild with delete
00:11 < dgilmore> | thl: deleting ok
00:11 < thl> | can you handle that?
00:12 < dgilmore> | thl: yes
00:12 < thl> | also queuing the rebuilds? Or do you need help
with that?
00:12 < mmcgrath> | dgilmore: how do we delete whats there? I'm not
that familiar with the actual sync script. do they just do a rsync
--delete?
00:12 < dgilmore> | thl: there are some scripts to do that
00:12 < dgilmore> | mmcgrath: rm -rf on buildsys
00:12 < thl> | dgilmore, remember to keep the buildorder if
possible
00:13 < mmcgrath> | dgilmore:k
00:13 < dgilmore> | mmcgrath: the rsync to master mirror has a
--delete-after
00:13 <-- | thimm has quit (Read error: 110 (Connection timed
out))
00:13 < stahnma> | sorry im late
00:13 < mmcgrath> | I figured, didn't want to assume.
00:14 < thl> | k, move to "final repo layout"?
00:14 < thl> | hi stahnma ; thim1 still around?
00:14 < thl> | (just wondering)
00:14 * | thim1 is here
00:14 < dgilmore> | thl: i think what you have proposed is fine but
current tools can not work with it
00:14 < thl> | dgilmore, would it be hard to adjust? where is
the problem? push scripts?
00:15 < dgilmore> | current tools do do testing either
00:15 < dgilmore> | thl: pushscripts
00:15 < thl> | do do?
00:15 < dgilmore> | thl: bohdi may be better
00:15 < nirik> | what is the proposed repo layout?
00:15 < thl> | nirik,
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenan...
00:15 < thl> | (near the end)
00:16 < thl> | dgilmore, so what do we do?
00:16 < dgilmore> | i need to get with lmacken and make sure it will
work for us
00:16 < thl> | dgilmore, can we have different build targets for
now, that get pushed to different directories?
00:16 < thl> | dgilmore, the stuff from lmacken supports testing
afaik
00:16 < dgilmore> | thl: we could but that will require work on
packagers
00:17 < dgilmore> | thl: it supports testing. Not sure about the sub
dir part
00:17 < thl> | dgilmore, can we simply use the testing repo for
now as in the layout
00:17 < dgilmore> | does anyone object to the layout?
00:17 < mmcgrath> | not me.
00:18 < thim1> | Where do security updates go into?
00:18 < dgilmore> | thl: for the tetsing part requires changes to
push scripts
00:18 < thl> | dgilmore, no, I meant just use testing for now
00:18 < dgilmore> | thim1: straight into the repo not testing
00:18 < thl> | and nothing else
00:18 < thl> | that makes it obvious that this stuff is not
ready for the public yet, too
00:18 < dgilmore> | thl: it would require me to for the extras push
scripts to do
00:18 < thim1> | OK, are we discussion rebuilds or layout?
00:19 < dgilmore> | s/for/fork/
00:19 < thl> | dgilmore, can't you just configure a different
target dir?
00:19 < thl> | thim1, layout
00:19 < dgilmore> | thl: not that im aware ill look see if i can
00:19 < thim1> | Why are push scripts a problem for the layout?
00:19 < nirik> | how far away is bodhi?
00:19 < dgilmore> | nirik: AFAIK close
00:20 < mmcgrath> | lmacken: ping?
00:20 < dgilmore> | hopefully we can switch to bohdi and koji at the
same time
00:20 < thl> | dgilmore, thx; let me know if I can help you with
them
00:20 < thim1> | We already have similar setup on the Fedora side
of the infrastructure, can't we reuse that?
00:20 < nirik> | cool. That would be ideal... then we have testing
support, security updates marking, etc.
00:20 < thl> | thim1, the fedora extras stuff does not handle
testing at all
00:20 < thl> | the new stuff from lmacken should
00:21 < thim1> | thl: Understand, thanks!
00:21 < dgilmore> | lets move on
00:21 < thl> | dgilmore, +1
00:21 < dgilmore> | Next on teh list is shortcut for branching
00:21 < mmcgrath> | thim1: 'bohdi' is a whole updates system, its
more robust then just our current scripts. Its a good thing :-)
00:21 < thim1> | I know, looking forward to it :)
00:21 < dgilmore> | for now send me an email or irc ping and i can
ping all of a owners packages
00:21 --- | thl has changed the topic to: EPEL meeting --
shortcut for branching
00:22 < thl> | dgilmore, is there a way to say "don't branch foo"?
00:22 < dgilmore> | thl: not in what i currently have
00:22 * | nirik needs to branch another of his packages
soon... but needs to get the maintainer of the prereqs to branch first.
00:22 < thl> | I for example have several packages that got
moved to core
00:22 < thl> | (and thus to RHEL5)
00:22 < dgilmore> | i could quite easily pass a list of packages and
branch them
00:23 < thim1> | branch and delete superfluous branches?
00:23 < thl> | dgilmore, maybe something like that would be nice
00:23 < dgilmore> | thl: ill add tho my script the ability to exclude
a list
00:23 < thl> | dgilmore, sounds sane, too
00:23 < nirik> | we do need to make sure if something was branched
for epel-4 that it's still in epel-5 or rhel-5 core...
00:23 < dgilmore> | nirik: indeed
00:23 < thim1> | We can't control RHEL5 core :)
00:24 < nirik> | sure, but we shouldn't drop a package on upgrade
if we can at all avoid it.
00:24 < dgilmore> | nirik: though AFAIK upgrades fron RHEL4 ->RHEL5
are unsupported
00:24 < thim1> | That's not true anymore
00:24 < nirik> | really? wow. ok.
00:24 < dgilmore> | thim1: im wrong? i konda hope so
00:25 < thim1> | Yes, it was an important discussion topic between
customers/partners and RHEL
00:25 < thim1> | But maybe not all subscribtion models support it,
though
00:25 < dgilmore> | no idea
00:25 < thim1> | Ask you local RHEL representatiove for a detailed
product view ;)
00:25 < dgilmore> | but regardless we want to make sure the same
functionality exists
00:26 < thim1> | We must make sure that upgrades are not
obstructed by EPEL
00:26 < thl> | scripts?
00:26 < thim1> | Otherwise what RHEL and partners have agreed is a
different thing
00:26 < dgilmore> | all the branching needs to happen on the cvs
server so an admin has to handle it
00:26 < thim1> | thl: scripts?
00:26 < thl> | scripts could check if the upgrade path are fine
00:27 < thim1> | thl+++
00:27 < thl> | or if a pacakge accidentally enters EPEL5, even
if it is part of RHEL5
00:27 < thl> | someone would just need to write them
00:27 < thim1> | Like for FC6+FE6 currently
00:27 < thl> | yeah, but they probably need some adjustments for
RHEL
00:27 < thim1> | Reuse the Fedora scripts?
00:27 < thim1> | Sure, depends also on layout
00:27 < thim1> | And testing the testing repo, too
00:28 < nirik> | I think also bodhi does some checking on newly
built packages...
00:28 < nirik> | ie, EVR, broken deps, etc.
00:28 < thim1> | About the layout: Do we really want
/epel/5/5.0/... or epel/5/5/....?
00:28 < thl> | nirik, yeah, I think so, too
00:28 < dgilmore> | nirik: its supposed to not push packages if it
breaks deps
00:28 < thl> | thim1, the reasons for that are in the proposal
00:29 < thl> | I'd say we should keep those scripts in mind, but
they are no high priority for the start
00:29 < nirik> | well, if we can start with bodhi they shouldn't
be needed...
00:30 < dgilmore> | thl: Tell contributors to start | as sson as
RHEL5 is sorted out
00:30 < thl> | dgilmore, will do
00:30 < dgilmore> | moving to next areas
00:30 < thl> | nirik, I don#t want to be a testbed for new stuff
;-)
00:30 < thim1> | thl: I reread the proposal, where is the reason
for "5/5.0" ?
00:30 --> | stahnma_ (Michael Stahnke) has joined
#fedora-meeting
00:30 < thl> | nirik, at least not more then strictly needed
00:30 < nirik> | thl: sure, but we already are to some extent...
koji, etc. ;)
00:31 < dgilmore> | koji will happen for all soon
00:31 < thl> | thim1, below it; starts with "This layout may
looks complicated, but has one major benefit:..."
00:31 < thim1> | That explains 5.0, 5.1 etc
00:31 < thim1> | not 5/5.0
00:32 < dgilmore> | thim1: can we talk about the layout on the list
please
00:32 < thl> | thim1, you mean the extra 5/ in it?
00:32 < thl> | dgilmore, +1
00:32 < thim1> | thl: yes
00:32 < dgilmore> | lets move on for now and discuss it on the
list and come to an agreement
00:32 < thl> | thim1, makes everything a bit easier IMHO
00:32 < thl> | dgilmore, +1
00:32 < dgilmore> | I want to talk about thl's EPEL Steering
Committie proposal
00:33 < stahnma_> | +1
00:33 < thl> | dgilmore, I just modified it a small bit
00:33 < thl> | as requested by thim1 on the list
00:33 < thl> |
http://fedoraproject.org/wiki/ThorstenLeemhuis/EPELSteeringCommittee?acti...
00:34 --- | thl has changed the topic to: EPEL meeting --
EPEL Steering Committee
00:34 < thl> | I'd say I post it to fedora-maintainers tomorrow
00:34 < dgilmore> | thl: ok
00:34 < thl> | and then FESCo can look at it on Thursday, people
agree that this is the way forward
00:34 * | mmcgrath is apathetic about SIG vs Steering
Committee.
00:35 < thim1> | thl: I like it +1
00:35 < dgilmore> | does anyone have anything to say for or against
the propossal
00:35 < mmcgrath> | just as long as progress continues to get made.
00:35 < thl> | mmcgrath, +1
00:35 < thl> | mmcgrath, we probably need to use the wiki a bit
more for votings
00:35 < nirik> | it's fine with me, I don't much care either, but
if we need to vote on hard things and make decisions, thats fine.
00:35 < dgilmore> | thl: wiki or mailing list
00:36 < thl> | dgilmore, +1
00:36 < thl> | and we should annouce votings beforehand if possible
00:36 < thl> | to make sure people can send in their opinions,
even if they can't make the meeting
00:36 < mmcgrath> | thl: +1, yeah people get very picky about that
type of voting.
00:36 < thl> | I'll add a note to the proposal
00:37 < thl> | mmcgrath, I know, I'm one of those people
sometimes (see FAB list, even if it was no voting) ;-)
00:37 < thl> | other stuff that is missing?
00:38 < dgilmore> | OK time to moveon thl send the propossal out
today or toomoorw
00:38 < thl> | k
00:38 < stahnma_> | me fear about the SC is that if we want to get
companies and customers involved in EPEL, the SC seems to close them out
00:38 < thim1> | New meeting time?
00:38 --- | dgilmore has changed the topic to: EPEL Meeting
-- Free Chat
00:38 < stahnma_> | it's like they have to jump through hoops to get
a voice
00:39 < stahnma_> | (my isp will probabl drop during this meeting, so
just keep talking if I die)
00:39 < thl> | stahnma_, primary discussion channel is the list
00:39 < thim1> | http://fedoraproject.org/wiki/EPEL/NewMeetingTime
00:39 < thim1> | Only thl and myself added some time slots
00:39 < nirik> | I think we should strive for reaching a consensus
on issues, and only vote when there is some kind of deadlock... so
normally they would have a voice I would think.
00:39 < thl> | IRC is always just a add on, as not all people
can do / like IRC
00:39 < dgilmore> | thim1: all the available times i cant attend
00:40 < thim1> | dgilmore: Which weekday time slots are free for you?
00:40 < nirik> | thim1: almost anytime is ok for me...
00:40 < stahnma_> | just curious, do we a have a US west-coasters?
00:40 < thl> | stahnma_, yes, quaid is
00:40 < mmcgrath> | stahnma_: just quaid
00:40 < mmcgrath> | AFAIK
00:40 < quaid> | but
00:41 < stahnma_> | I thought most were out of Eastern and Central
00:41 < quaid> | I'm very flexible
00:41 < quaid> | like, i was going to approve some Midnight PDT times
00:41 < dgilmore> | thim1:
00:41 < dgilmore> | 23:00-3:00 UTC or
00:41 < dgilmore> | 11:30-12:30 UTC
00:41 < quaid> | and others :)
00:42 < quaid> | there are some early mornings PDT I can do, like
Noon UTC
00:42 < dgilmore> | basicly i cant do it doing work time $DayJob wont
allow me any more time
00:42 <-- | stahnma has quit (Read error: 110 (Connection
timed out))
00:42 < thim1> | The how about a noon UTc slot?
00:42 < thl> | bad for me
00:42 * | stahnma_ has a similar situation... I am normally
on IRC at work, but can't promise a time
00:42 < quaid> | hmm
00:43 < dgilmore> | 11:30UTC is when i get up
00:43 < quaid> | I usually don't have this problem with just East
Coast/Europe
00:43 < quaid> | like, what about 2200 UTC?
00:44 < thim1> | That's 0:00 in main parts of Europe
00:44 * | thl heads to bead at around 01:00 UTC
00:44 < quaid> | ah, early to bed, early to rise :)
00:44 < thl> | bed
00:44 < thl> | quaid, yes :)
00:44 < dgilmore> | quaid: i finish work at 23:00UTC
00:44 * | stahnma_ too or 0:00
00:45 < quaid> | evil bosses!
00:45 < thl> | I think the sunday meeting time still seems to
match most people best
00:45 < thl> | I know it's not ideal
00:45 < thim1> | I won't be able to come on Sundays
00:45 < thl> | but for now it seems the best afaics
00:45 < dgilmore> | quaid: i hope to have a new one soon but dont
want to assume i will
00:45 < quaid> | dgilmore: yeah, i hear dat
00:46 < stahnma_> | I can probably do a day meeting---but I might be
unresponsive if I have "real work" to do :)
00:46 < dgilmore> | the only time i could possibly commit to is lunch
00:47 < nirik> | would sat be any better than sunday?
00:47 < dgilmore> | which is when FESCo meeting happens
00:47 < thl> | nirik, thim1's times are
http://fedoraproject.org/wiki/EPEL/NewMeetingTime
00:47 < thl> | (mine, too, but no one else used it)
00:48 < thim1> | dgilmore: lunch: when is that in UTC?
00:48 < nirik> | thl: so wed at 00:00UTC wouldn't work for you?
00:49 < thl> | a bit critical now with the dst switch...
00:49 < thl> | (often it's a bit earlier than 01:00 UTC when I
seitch of the computers)
00:49 < thim1> | dgilmore: lunchtime=fesco: How about fesco slot
on Wed?
00:50 < thl> | btw, FESCo is back to 17:00 UTC iirc, isn#t it?
00:50 < thl> | now with the DST change?
00:50 < dgilmore> | thim1: i added to the list
00:50 < dgilmore> | i cant guarantee my availablility
00:50 < dgilmore> | thl: i cant remeber
00:50 < thim1> | thl: DST changes in the US were two weeks ago
00:50 < thl> | I'd say we give this another week, and try to
sort out the details on the list
00:50 < thim1> | So it wn't change agin
00:51 < thl> | thim1, they already switched FESCo last time iirc
00:51 < thim1> | That's what I mean
00:51 < thim1> | They won't switch again
00:51 < thl> | thim1, but it's wrong in
http://fedoraproject.org/wiki/EPEL/NewMeetingTime then
00:51 < thim1> | Currently it is 00:00 UTC, that's what it will
stay for the summer time
00:52 < thl> | thim1,
http://fedoraproject.org/wiki/Development/SteeringCommittee
00:52 < thl> | "Affectionately known as FESCo. Currently meets
every Thursday on the Freenode IRC Network in #fedora-meeting at 17:00
UTC."
00:52 < thl> | that what I'm trying to tell you ;-)
00:52 < mmcgrath> | heh
00:52 < thim1> | OK, one of the wiki pages is wrong :)
00:52 < thim1> | Anyway, we should just pick another day than
fesco to not collide
00:52 < mmcgrath> | s/one/many/ s/is/are/ :)
00:53 < thl> | thim1, no, it was 00:00 until one or two weeks
ago iirc
00:53 < dgilmore> | anyone else have anything else to talk about
00:53 < nirik> | I have one quick Q...
00:53 < mmcgrath> | not I
00:53 < thim1> | dgilmore: when is your lunch time in UTC?
00:53 --> | FrancescoUgolini (Francesco Ugolini) has joined
#fedora-meeting
00:54 < nirik> | centos has a 'extras' repo... do we know if they
are going to keep doing that? or get those things in epel? do we have
any centos contacts?
00:54 < mmcgrath> | don't ask him to give up his lunch. he's a busy
guy as it is :P
00:54 < thl> | z00dax in #epel should know
00:54 < nirik> | The main reason I ask is that they have Xfce in
there... but it's the old version. I have gotten several requests for
4.4 for epel, but I don't want to step on their toes.
00:54 < dgilmore> | thim1: 17:00:00 UTC
00:54 < thim1> | mmcgrath: dgilmore offered, I'm wouldn't ask
otheriwse
00:55 < dgilmore> | nirik: i think they are dropping it not sure
00:55 < mmcgrath> | oh :)
00:55 < thl> | nirik, I'd say asz z00dax
00:55 < nirik> | ok, can check with him. thanks.
00:55 < dgilmore> | thim1: i usually only take lunch one or two days
a week
00:56 < stahnma_> | dgilmore: that is a sad state of affairs
00:56 < dgilmore> | stahnma_: it is but i usually dont ahve time to
take it
00:56 < dgilmore> | thursdays i take it for fesco
00:58 < dgilmore> | lancelan: ping
00:59 < thim1> | thl: Wed 00:00 UTC?
00:59 < thl> | Wed 17:00 UTC?
01:00 <-- | FrancescoUgolini has quit ("Leaving")
01:00 < dgilmore> | thl: i cant guarantte but i could try
01:00 < mmcgrath> | both WORKSFORME
01:00 < mmcgrath> | as long as I remember :D
01:01 < stahnma_> | please send out a notice on list, and I will try
to attend
01:01 < stahnma_> | also a reminder in #epel will help :)
01:01 < thl> | stahnma_, sorry, forgot about it this week
01:01 < stahnma_> | thl it's ok, that's not why I was late today
01:01 < thl> | quaid, wed 17:00 UTC?
01:02 < thim1> | thl: Wed 17:00 UTC OK with me :)
01:02 < dgilmore> | ok So next meeting will be at 17:00 UTC on wednesday
01:03 < dgilmore> | im going to close this meeting in 60
01:03 < thl> | this wednesday?
01:03 < thl> | e.g. in three days?
01:03 < thl> | or in 10 from now?
01:03 < dgilmore> | yes unless you want to wait 10 days
01:03 < thl> | unsure; I'm fine with both :)
01:03 < dgilmore> | lets make it 10 days
01:04 < thl> | dgilmore, +1
01:04 < dgilmore> | probaly wont have much to report in 3
01:04 < stahnma_> | +1
01:04 < dgilmore> | closing in 30
01:04 < dgilmore> | closing in 20
01:04 < dgilmore> | closing in 10
01:05 < dgilmore> | --- Meeting closed --
}}}
16 years, 6 months
Fedora EPEL Package Build Report 2007-03-29
by Fedora Koji Build System
Packages built and released for Fedora EPEL 5: 30
NEW TurboGears-1.0.1-2.el5
NEW cmucl-19d-3.el5
firmware-addon-dell-1.2.6-1.el5
NEW libnet-1.1.2.1-10.el5
libsmbios-0.13.5-1.el5
NEW nas-1.8b-1.el5
NEW numpy-1.0.1-2.2.el5
NEW pgfouine-0.7.2-3.el5
NEW phpPgAdmin-4.1.1-1.el5
NEW python-TestGears-0.2-4.el5
NEW python-cherrytemplate-1.0.0-5.el5
NEW python-clientform-0.2.6-1.el5
NEW python-configobj-4.4.0-1.el5
NEW python-formencode-0.7-2.el5
NEW python-irclib-0.4.6-3.el5
NEW python-json-3.4-3.el5
NEW python-mechanize-0.1.6-0.1.b.el5
NEW python-myghty-1.1-3.el5
NEW python-nose-0.9.2-1.el5
NEW python-paste-1.2.1-1.el5
NEW python-paste-deploy-1.1-1.el5
NEW python-paste-script-1.1-1.el5
NEW python-psycopg2-2.0.5.1-3.el5
NEW python-ruledispatch-0.5a0-0.4.svnr2115.el5
NEW python-simplejson-1.5-1.el5
NEW python-sqlobject-0.7.3-1.el5
NEW python-tgfastdata-0.9a6-6.el5
NEW python-turbocheetah-0.9.5-7.el5
NEW python-turbojson-0.9.9-3.el5
NEW python-turbokid-0.9.9-4.el5
Packages built and released for Fedora EPEL 4: 10
jasper-1.900.1-1.el4
NEW libnet-1.1.2.1-7.el4
libsmbios-0.13.5-1.el4
maxima-5.11.0-8.el4
nas-1.8b-1.el4
NEW pgfouine-0.7.2-1.el4
NEW phpPgAdmin-4.1.1-1.el4
NEW python-psycopg2-2.0.5.1-8.el4
NEW queuegraph-1.1-1.el4
sbcl-1.0.4-1.el4
For more information about the built packages please see the repository
or the Fedora Info Feed: http://fedoraproject.org/infofeed/
16 years, 6 months
brp-python-bytecompile in EL4
by Bernard Johnson
Is there anything that we can do to add the brp-python-bytecompile to
EPEL4 buildsys? Out of all the "current" buildsys environments (FE5,
FE6, F7 devel, EPEL4, EPEL5), it is the only one that doesn't do the
automatic byte compilation.
Because of this, I have to either add conditional code specifically to
byte-compile for EL4 in my spec (ugly) or branch my spec specifically
for EL4 (ugly).
Neither of these is ideal.
It would be easy to add this brp-* script and the macros to trigger it
in the EPEL4 system. This has the side effect of requiring
scripts/macros that a base EL4 doesn't have and the package will not
build on a base EL4.
But I don't see this as a blocker, since we are already adding macros
that will break building on a base EL4 system (if used).
The way to fix this would be assure that the macros can be made
available back to the EL4 system.
There is currently a discussion on fedora-devel regarding adding macros
back into the base system. Check it out "Opinions: Providing
'buildsys-macros' in the installed system".
It cover most of the stuff that I just brought up, just not specifically
about brp-python-bytecompile..
16 years, 6 months
Rebuild for RHEL5 final
by Thorsten Leemhuis
Hi all!
In the meeting last Sunday (I'll write the summary later) it was agreed
on to rebuild all the packages of EPEL5 once we have RHEL5 in place on
the builders (which should happen soon or has already happened) as
everything which is in EPEL5 now was build against RHEL5Beta1, which is
quite old and a lot of stuff changed for the final.
The idea that was agreed on in the meeting was to just delete the EEPL5
repo and rebuild everything once automatically in the proper order
without changing %release.
Now that I've thought about it some more I don't like that plan that
much anymore, as then it's not possible to differentiate if people have
the old or the new package installed. Sure, that shouldn't be many
people yet, but nevertheless it could create problems.
Opinions? Just ignore that? Or simply do a script-build mass rebuild of
EPEL5 with increased %release?
CUI
thl
16 years, 6 months
fyi: qt4: rhel5 vs epel-4
by Rex Dieter
Just checked that rhel5 includes qt4. Biggest issue being:
1. upgrade path is busted. rhel5's qt4-4.2.1-1 vs epel4's qt4-4.2.3
I guess there's not much to do about that now. Suggestions? Is it
worth worrying much about at this point?
And to a lesser degree:
2. the rhel5 pkg only loosely followed extras's qt4 packaging (it
varies in a few significant ways). I'll make rh maintainer aware.
-- Rex
16 years, 6 months
howto coordinate with RHEL packages/pakagers?
by Patrice Dumas
Hello,
Maybe there is something obvious I didn't figured out, but I don't know
where to look for some information about RHEL packages:
* is there somewhere a list of packages in RHEL? And versions/maintainer
information?
* where are the spec file available? Do we have to expand srpms or
is there something convenient similar with the fedora cvs? I can't
even find the srpms.
I can see a communication channel, bugzilla, but it is not necessarily
the most convenient, it can be a bit heavy sometime.
--
Pat
16 years, 6 months
Fedora EPEL Package Build Report 2007-03-26
by Fedora Koji Build System
Packages built and released for Fedora EPEL 5: 8
ganglia-3.0.4-2.el5
NEW php-pecl-zip-1.8.8-1.el5
NEW postgresql-dbi-link-2.0.0-3.el5
NEW python-html2text-2.26-2.el5
NEW rss2email-2.60-3.el5
NEW ssmtp-2.61-11.1.el5
NEW yumex-1.9.5-1.0.el5
NEW zziplib-0.13.49-1.el5
Packages built and released for Fedora EPEL 4: 6
NEW epel-release-4-5
lzo-1.08-2.el4
NEW postgresql-dbi-link-2.0.0-3.el4
NEW python-html2text-2.26-2.el4
NEW rss2email-2.60-3.el4
NEW zziplib-0.13.49-1.el4
For more information about the built packages please see the repository
or the Fedora Info Feed: http://fedoraproject.org/infofeed/
16 years, 6 months
ABI diff tools
by Patrice Dumas
Hello,
I am searching for a program that would allow to compare 2 libs or a lib
and an application, find the binary interface differences and display
them conveniently. Does something like that exist? I think that it would
be very convenient to help maintaining ABI compatibility in EPEL packages.
--
Pat
16 years, 6 months
Fedora EPEL Package Build Report 2007-03-23
by Fedora Koji Build System
Packages built and released for Fedora EPEL 5: 5
NEW apcupsd-3.14.0-1.el5
NEW lzo-2.02-2.el5
NEW openvpn-2.1-0.17.rc2.el5
NEW python-setuptools-0.6c5-1.el5
NEW sqlgrey-1.7.5-1.el5
Packages built and released for Fedora EPEL 4: 4
NEW apcupsd-3.14.0-1.el4
NEW lzo-1.08-2
NEW openvpn-2.1-0.17.rc2.el4
NEW sqlgrey-1.7.5-1.el4
For more information about the built packages please see the repository
or the Fedora Info Feed: http://fedoraproject.org/infofeed/
16 years, 6 months
