Reminder: Next meeting on 20080116 at 18:00 UTC
Summary will be part of this weeks report (as always)
00:00:01 < knurd> | Hi everybody; who's around for the EPEL meeting?
00:00:01 * | knurd likes to remind everyone that the schedule for todays meeting as well as a list of all open tasks can be found on http://fedoraproject.org/wiki/EPEL/Schedule
00:00:01 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
00:00:14 < mmcgrath> | pong
00:00:14 * | nirik is here.
00:00:35 --> | stahnma (Michael Stahnke) has joined #fedora-meeting
00:00:46 < knurd> | ohh, and happy new year everyone
00:01:03 < EvilBob> | happy new year knurd
00:01:11 * | _blah_ can't believe it is 2008 already
00:01:17 < stahnma> | greeting's ya'll
00:01:38 --- | knurd has changed the topic to: EPEL SIG Meeting | next testing -> stable move | knurd | http://fedoraproject.org/wiki/EPEL/Tasks/NextTestingStableMove
00:01:40 < nirik> | happy new year back at you all.
00:01:47 * | quaid is here
00:01:47 < knurd> | so let's start
00:02:03 < knurd> | I wrote to the list about $TOPIC already
00:02:16 < knurd> | I'll prepare the next move this WE
00:02:20 < knurd> | for EPEL4
00:02:22 < nirik> | yeah, that sounds good. I think we should setup specific times for stable pushes.
00:02:31 < nirik> | ie, should it be every 2 weeks? every month?
00:02:32 < knurd> | yeah, might be a good idea
00:02:39 < knurd> | every four weeks?
00:02:41 < nirik> | so people know when to expect it, rather than ad-hoc
00:03:24 < knurd> | EPEL5 early each month, EPEL4 mid each month?
00:03:29 < nirik> | every 4 weeks sounds ok to me...
00:03:50 < nirik> | so how long does something need to be in testing? a full 4 weeks? or ?
00:04:16 < knurd> | at least two weeks?
00:04:25 < mmcgrath> | <nod> a schedule.
00:05:12 < nirik> | 2 weeks seems ok. So, around the 1st for epel5, and around the 15th for epel4?
00:05:19 < knurd> | nirik, +1
00:05:31 < knurd> | I'd say I write that to the list and ask for opinions
00:05:39 < knurd> | if that's fine for everyone we just do it
00:05:48 < stahnma> | fine with me
00:06:08 < nirik> | fine with me. I think a regular schedule is good. Let me know if you want me to try and do any of the pushes...
00:06:16 * | knurd will move on then if no one yells
00:06:27 < knurd> | nirik, I'll try to write down the proceedure next time
00:06:55 < nirik> | ok, I'd be happy to help, or just let you do it. ;)
00:07:07 < knurd> | :)
00:07:09 --- | knurd has changed the topic to: EPEL SIG Meeting | EL-updates to the buildsys | unassigned | http://fedoraproject.org/wiki/EPEL/Tasks/Misc
00:07:25 < knurd> | dgilmore, mmcgrath, how hard would be to realize that?
00:07:42 < mmcgrath> | using RHEL, not sure.
00:07:42 < knurd> | there was this build problem from remi on the list
00:07:45 < mmcgrath> | it'd be easy with CentOS.
00:08:14 < knurd> | https://www.redhat.com/archives/epel-devel-list/2008-January/msg00000.html
00:08:17 < mmcgrath> | We just need to figure out a way to keep the RHEL tree updated in an easy way.
00:08:26 * | nirik suggests we switch to centos? :)
00:08:48 * | mmcgrath one sec on the phone with IBM
00:08:50 < knurd> | nirik, that creates just problems in the other direction
00:09:02 < knurd> | and no support for ppc (yet)
00:09:07 < nirik> | yeah, I suppose... ;(
00:09:18 < stahnma> | can we just get entitlements from RH?
00:09:26 < stahnma> | this seems like it shouldn't be THAT hard
00:09:30 < knurd> | and people yeeling "why didn't you update to RHEL 5.2"
00:09:33 < mmcgrath> | we have entitlements from RH but its a matter of keeping it up to date.
00:09:58 < _blah_> | do we just fix build problems as they come up for now?
00:10:08 < knurd> | mmcgrath, can't reposync solve the problem?
00:10:18 < mmcgrath> | possibly.
00:10:19 < knurd> | _blah_, until now we ignored the problem
00:10:28 < _blah_> | knurd: :)
00:10:38 < knurd> | _blah_, that's why I ddin#t answer yet on remi's mail
00:10:42 < mmcgrath> | We're doing similar things in our infrastructure already. how often would we propose running it?
00:10:42 < nirik> | so does it require manually pulling updates and adding them to plague right now?
00:11:02 < dgilmore> | mmcgrath: daily or weekly
00:11:03 < knurd> | mmcgrath, a cronjob that runs once or twiecea day maybe?
00:11:18 < knurd> | s/twiecea/twice a/
00:11:20 < dgilmore> | knurd: certainly not more than once a day
00:11:40 < nirik> | daily would be great.
00:11:50 < nirik> | weekly would be ok if daily causes issues IMHO
00:11:57 < knurd> | dgilmore, well, if we get stuff into EPEL that depends on a specific firefox then daily is a minimum
00:12:07 < knurd> | or how is the firefox problem handled in EL?
00:12:18 < knurd> | is there s stable firefox abi?
00:12:24 < nirik> | I don't think rhel pushes updates more often than once a day anyhow, does it?
00:12:27 --> | awjb (Andreas Bierfert) has joined #fedora-meeting
00:12:37 < nirik> | no, no stable abi... it's firefox-devel like fedora.
00:12:41 < dgilmore> | knurd: rhel is lucky to get updates weekly
00:13:03 < knurd> | dgilmore, yeah, but if there is a new firefox we should rebuild stuff against ir quickly
00:13:14 < dgilmore> | knurd: there is no way it should be done more than daily
00:13:18 < nirik> | daily would be great if possible... dgilmore, could you set that up?
00:13:24 < dgilmore> | nirik: no
00:14:02 * | Jeff_S shows up a bit late...
00:14:06 < nirik> | ok. :) perhaps mmcgrath could?
00:14:12 < knurd> | who can set this up? Does anyone from us besides dgilmore and mmcgrath have access to the machines?
00:14:43 < mmcgrath> | knurd: anyone in sysadmin-main
00:14:46 < dgilmore> | knurd: it is not a matter of just having access
00:15:11 * | quaid senses a stronger objection
00:15:15 < knurd> | dgilmore, --verbose?
00:15:46 --> | kital (JoergSimon) has joined #fedora-meeting
00:16:30 < mmcgrath> | we'd have to make sure we're getting all the various channels copying them to the right place and running the createrepo script on them.
00:16:30 --- | rdieter is now known as rdieter_away
00:16:35 < mmcgrath> | it can all be scripted.
00:16:49 < mmcgrath> | at least I think it can.
00:16:58 < mmcgrath> | we also have to do bad things to get it to contact RHN properly.
00:17:50 <-- | mbacovsk has quit (Remote closed the connection)
00:18:07 < knurd> | so, what to do?
00:18:10 < knurd> | put it on a todo list
00:18:11 < mmcgrath> | So the decision has been made? "We want this to run daily?" or some such thing?
00:18:12 < nirik> | well, the other options I see: do the updates at the same time as the stable pushes?
00:18:18 < knurd> | put it high on the todo-list
00:18:24 < knurd> | ignore the problem?
00:18:25 < nirik> | or just: 'apply updates as people require them' ?
00:18:29 < mmcgrath> | make a ticket it - https://fedorahosted.org/fedora-infrastructure/
00:18:35 --> | mbacovsk (Martin Bacovsky) has joined #fedora-meeting
00:18:56 * | knurd will file a ticket
00:19:04 < knurd> | then we can see where we get from there
00:19:10 < knurd> | that okay for everybody?
00:19:43 < nirik> | sure. I think daily would be great, but less often would be fine too.
00:19:54 < knurd> | nirik, yeah, for the start less often should do
00:20:00 * | knurd moves on
00:20:03 --- | knurd has changed the topic to: EPEL SIG Meeting | RHEL MetaData | stahnma | http://fedoraproject.org/wiki/EPEL/Tasks/RhelMetaData
00:20:05 < knurd> | stahnma ?
00:21:00 < stahnma> | sorry
00:21:08 < stahnma> | not much to update
00:21:14 < stahnma> | I am working on it
00:21:21 < stahnma> | and didn't have much time over the holidays
00:21:24 < stahnma> | am hoping for more very soon
00:21:31 < knurd> | k :)
00:21:38 --- | knurd has changed the topic to: EPEL SIG Meeting | KojiAndBodhiForEpel | mmcgrath | http://fedoraproject.org/wiki/EPEL/Tasks/KojiAndBodhiForEpel
00:21:41 < knurd> | mmcgrath, any news?
00:22:01 < mmcgrath> | knurd: nothing over the holidays. We're hopeful but nothing concrete yet.
00:22:06 < dgilmore> | knurd: do the work or find someone to do it for you. it will not happen until then
00:22:08 < knurd> | k
00:22:22 --- | knurd has changed the topic to: EPEL SIG Meeting | permission to use spec files in other projects | http://fedoraproject.org/wiki/EPEL/Tasks/Misc
00:22:36 < knurd> | as written to the list: made noise about it on FAB-list
00:22:41 * | knurd skips
00:22:46 --- | knurd has changed the topic to: EPEL SIG Meeting | Free discussion around EPEL
00:22:52 < knurd> | anything else to discuss?
00:23:28 < knurd> | quaid, _blah_, Jeff_S, mmcgrath, nirik, anything else?
00:23:33 * | nirik has nothing else...
00:23:39 < Jeff_S> | not me
00:23:59 * | knurd will close the meeting in 30
00:24:02 < quaid> | we doing anything special at FUDCon?
00:24:08 * | mmcgrath has nothing
00:24:43 < tibbs> | I had one minor thing.
00:24:50 < knurd> | tibbs, shoot
00:24:54 < nirik> | it might be nice to do something at fudcon, but not sure what.
00:25:02 < knurd> | quaid, not sure, I leave that to those guys that travel there
00:25:07 < tibbs> | Recently there was a review for an EPEL-only package.
00:25:12 < quaid> | we could have a hackfest with virtual folk, too
00:25:27 < quaid> | if there is work to be done :)
00:25:34 < tibbs> | The only real issue with that review is what to do with the devel branch.
00:25:45 < nirik> | tibbs: I would say dead.package it.
00:26:01 < tibbs> | Yeah, I did say that, but it only works if the package isn't supposed to be there for EPEL6.
00:26:20 < nirik> | it shouldn't be... it's only old old rhel4 that needs it.
00:26:24 < knurd> | tibbs, what's the #bug/reason for not having a devel branch?
00:26:37 * | knurd botes for dead.package in devel as well
00:26:41 < dgilmore> | you can just never import into devel
00:26:58 < f13> | knurd: the epel package may have been rolled into some other package in devel
00:27:00 < nirik> | https://bugzilla.redhat.com/show_bug.cgi?id=426929
00:27:01 < bugbot_> | Bug 426929: medium, medium, ---, Jason Tibbitts, ASSIGNED , Review Request: tetex-lineno - Add line numbers on paragraphs in LaTeX
00:27:17 < nirik> | basically it's in tetex/texlive in all other releases.
00:27:31 < knurd> | well, nevertheless I vote for dead.package
00:27:36 < knurd> | scripts are used to it
00:27:36 < tibbs> | In this case it doesn't apply to anything beyond EPEL4 but I can't say that would be the case for any future EPEL-only packages.
00:27:52 < knurd> | better that then scripts that fail if they don#t find a devel branch at all
00:28:02 < tibbs> | Of course, EPEL-only packages may be sufficiently rare that this isn't a real issue.
00:28:10 < tibbs> | This is the first one I encountered.
00:28:41 < _blah_> | is there any kind of design doc for how to implement the koji features to support EPEL?
00:29:18 < knurd> | _blah_, taking to hte koji author as well as with dgilmore and mmcgrath might be the best start
00:29:33 < knurd> | tibbs, agreed, should not happen often
00:29:51 < knurd> | but what to do? I still think having a dead.package in devel is the best
00:29:55 < nirik> | _blah_: see the ticket: https://hosted.fedoraproject.org/koji/ticket/49
00:31:24 < _blah_> | nirik: thx
00:31:37 < knurd> | tibbs, what was done? for the package in question
00:32:39 < knurd> | ohh, there is a dead.package in the devel branch
00:32:46 < knurd> | I'd say that's fine
00:33:25 < knurd> | fudcon?
00:33:38 < knurd> | who will be there from the EPEL SIG?
00:34:10 * | mmcgrath will be.
00:34:33 * | nirik will be there.
00:34:38 * | knurd does not plan to fly half around the world
00:36:09 < knurd> | nirik, quaid, mmcgrath, maybe you three can work something out for FUDCon?
00:36:46 < nirik> | well, the one thing I can think of would be to do a 'what is epel and why I should branch my packages for it' type session...
00:37:08 <-- | mbacovsk has quit (Remote closed the connection)
00:37:13 < knurd> | nirik, sounds good
00:37:33 < knurd> | seems most people left
00:37:38 < knurd> | I#d say we close the meeting
00:37:52 * | knurd will close the meeting in 30
00:37:55 < nirik> | sounds fine.
00:38:12 * | knurd will close the meeting in 10
00:38:23 < knurd> | -- MARK -- Meeting end
00:38:23 --- | knurd has changed the topic to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel for meeting schedule
00:38:28 < knurd> | thx all
00:38:29 < mmcgrath> | knurd: thanks!
00:38:35 --> | spoleeba (spacious he's so) has joined #fedora-meeting
00:39:14 < quaid> | nirik +1 to that session idea
00:39:27 --- | You're now known as knurd_afk
00:39:28 < knurd_afk> | cu
00:39:32 < nirik> | I guess I can add it to the wiki...
00:39:34 < quaid> | ciao
00:39:41 < nirik> | quaid: you going to be at fudcon?
00:43:16 < quaid> | nirik: I plan to

Some good news for package maintainers with many sub-packages:
Plague used to sleep at least 20 seconds for each (!) file it had to
download from a builder. Even downloading the several small log files used
to take at least 20 seconds *each*.
Reading and debugging the code, I found the source of the problem and
taught the build server to sleep less when files are being downloaded.
Interestingly, the speedup is noticeable even for tiny build-jobs, e.g.
revisor down from 7m to 4m
nagios down from 6m to 4m
but it will be incredible for build-jobs with a larger number of pkgs
(e.g. try moodle or nagios-plugins which are in EPEL already). That
means, such packagers get the build-results and the mail notification
much faster.

Just a few quick observations:
I am trying to use clamd with amavis and Postfix. Amavis is supposed to
pass the attachments to clamd via a Unix socket. That's how it worked
for a while with the clamav packages made by Dag Wieers, no problems at all.
Today I uninstalled Dag's packages and installed the EPEL ones instead.
Big mistake.
The /etc/init.d stuff is badly broken. There isn't even a script proper,
there's just a symlink to a wrapper. The wrapper file is not in the
recognized init.d scripts style.
There's a clamd.init file somewhere in /usr/share, but there's a
<SERVICE> tag in it that needs to be adjusted. That same tag is somehow
propagated in the clamd.sysconfig file and possibly in a buch of other
places. No explanation for its purpose. The way it currently is, the
scripts just fail.
Why is the package failing to work after install? Why it doesn't just
work? Why the over-engineered customization with <SERVICE>?
There's a bunch of CLAMD_SERVICE variables sprinkled all over the place
in the wrapper script, that appears to be related to the <SERVICE> tag.
Holy freaking bejesus. Why should I care about that?
If I wanted to care about that, I would install clamav from source,
thank you very much.
After installing clamav-server and the related packages, the stuff
should Just Work (TM). It should not require dozens of obscure tweaks.
What's the point in having a package otherwise?
The Dag packages simply worked, as they always do, perhaps with some
small adjustments in the .conf file. I uninstalled them today, due to a
conflict with EPEL and thought I could use the EPEL packages instead.
How silly of me. If I can't figure out how to make the EPEL stuff work,
I'll have to go back to Dag's packages and set up all kinds of
exceptions in yum, to work around the broken EPEL packages.
How did these packages go through the verifications before being made
public?
Meanwhile my mail server can either be offline, or without an antivirus.
Merry Christmas. :-(
--
Florin Andrei
http://florin.myip.org/