Reminder: Next meeting on 20080213 at 18:00 UTC in #fedora-meeting
Summary will be part of this weeks report (as always)
00:00:59 < knurd> | Hi everybody; who's around for the EPEL meeting? 00:00:59 * | 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:59 --- | knurd has changed the topic to: EPEL Sig meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process 00:01:02 <-- | mefoster has left #fedora-meeting ( "Konversation terminated!") 00:01:03 < knurd> | all mine 00:01:21 < knurd> | thx bugzappers 00:01:29 <-- | No5251 has quit ("Kein Anschluss unter dieser Nummer!") 00:01:37 * | nirik is still here. 00:02:29 --> | J5 (John (J5) Palmieri) has joined #fedora-meeting 00:02:36 < knurd> | anybody seen mmcgrath? he seems rather busy in the past days afaics 00:02:42 < knurd> | or is he on vacation? 00:03:07 < nirik> | he's around... just busy I think. 00:03:18 <-- | axelilly has left #fedora-meeting ( ) 00:03:28 * | knurd wonders where smooge went 00:03:59 < knurd> | well, let's start really slow 00:04:14 < knurd> | nirik, do you know if/where the EPEL dep checker script runs? 00:04:31 < knurd> | mmcgrath or dgilmore installed one months ago 00:04:39 < nirik> | no idea. There is one mschwent had, but also one mmcgrath had setup... 00:04:39 < knurd> | but the one from mschwendt looks way better 00:05:10 < knurd> | nirik, did mschwendt install it as a cron job somewhere? 00:05:18 < smooge> | potty break 00:05:18 < knurd> | I thought he just kicked it manually 00:05:24 < nirik> | no idea. I haven't seen it run... 00:05:28 < nirik> | I can mail him and ask. 00:06:18 < knurd> | nirik, feel free to mail him, but I'd prefer to know first if there is a script running somewhere alreday :/ 00:06:20 < smooge> | the one that mmcgrath installed I think was broken and I was trying to get some time to fix it.. which only came up now ;(. So mschwents is better 00:06:47 < knurd> | smooge, do you have access to the machined wher the old script ran? 00:07:01 < knurd> | or shall we just ask mschwendt to install his somewhere? 00:07:20 < knurd> | he likely has permissions to do so 00:07:52 < smooge> | no I don't mmcgrath sent out an email a while back 00:08:02 < smooge> | with the script in it. 00:08:20 < nirik> | http://mschwendt.fedorapeople.org/extras-repoclosure-modified-20080115.tgz is mschewnts script 00:09:26 < knurd> | so, how to move on? ask mschwendt to install is? nirik, or do you want to handle that? you likely have the needed permissions as well 00:09:42 --> | mdomsch (Matt_Domsch) has joined #fedora-meeting 00:10:11 < smooge> | mdomsch, has permission to. he can do anything :) 00:10:17 < nirik> | sure, I can ask him if we can just run it on the buildsys box, or what. 00:10:27 < knurd> | nirik, k, thx 00:10:38 --> | JonRob (purple) has joined #fedora-meeting 00:10:40 --- | knurd has changed the topic to: EPEL SIG Meeting | next testing -> stable move | knurd | http://fedoraproject.org/wiki/EPEL/Tasks/NextTestingStableMove 00:10:50 < knurd> | is prepared; docs were imrpoved as well 00:11:06 < knurd> | the whole preparation can be done in about 10 or 15 minutes 00:11:15 < knurd> | maybe even less with a quick machine 00:11:31 < knurd> | any questions? otherwise I'll quickly move on 00:11:37 --> | choke (Colby Hoke) has joined #fedora-meeting 00:11:50 --- | knurd has changed the topic to: EPEL SIG Meeting | KojiAndBodhiForEpel | mmcgrath | http://fedoraproject.org/wiki/EPEL/Tasks/KojiAndBodhiForEpel 00:12:00 < nirik> | sounds good to me. 00:12:01 < knurd> | no mmcgrath, no Jeff_S thus likely no news 00:12:08 --- | knurd has changed the topic to: EPEL SIG Meeting | broken dep reports go to the list | mmcgrath ? | http://fedoraproject.org/wiki/EPEL/Tasks/Misc 00:12:16 < knurd> | discussed already, thus skipping this 00:12:23 --- | knurd has changed the topic to: EPEL SIG Meeting | fill the steering committee | all | http://fedoraproject.org/wiki/EPEL/Tasks/Misc 00:12:46 < knurd> | smooge, +1 for you becoming a steering committee member 00:13:08 < nirik> | +1 here. 00:13:19 < knurd> | but I think we need to have more +1 from at least 3 or four other steering committee members 00:13:24 --> | stahnma (Michael Stahnke) has joined #fedora-meeting 00:13:32 * | stahnma arrives 00:13:35 * | quaid is here too 00:13:38 < knurd> | thus I suppose we need to wait another week or two before it becomes official 00:13:40 < knurd> | ohh 00:13:45 < knurd> | okay, htere are two more 00:13:53 < knurd> | hi quaid, hi stahnma 00:14:06 < stahnma> | g'day 00:14:20 < knurd> | quaid, smooge, nirik and I just say "smooge, +1 for smooge becoming a steering committee member" 00:14:23 --- | choke is now known as c_hoke 00:14:23 * | smooge waits to see if he is cool enough to sit with at the big kids table 00:14:26 < quaid> | smooge for steering committee? +1 00:14:26 < stahnma> | +1 00:14:35 < knurd> | k, it's official now 00:14:39 * | quaid is a little kid in a booster chair 00:14:43 < knurd> | welcome to the stering committee smooge 00:14:44 < stahnma> | welcome to the big kids table 00:15:00 < knurd> | k, that makes seven again 00:15:06 < knurd> | I mentioned it on the list already 00:15:15 < knurd> | someone else wants to leave sooner or later 00:15:20 * | knurd is that someone else 00:15:38 < knurd> | I can stay around and help, but I'd like to get a more free time for RPM Fusion 00:15:49 < knurd> | and some fresh ideas for EPEL would help as well 00:15:59 --- | stickster_afk is now known as stickster 00:16:13 < knurd> | thus I'd suggest we elect a new chairmen over the next two weeks/in the next meeting 00:16:18 --- | c_hoke is now known as c_hoke_ 00:16:23 < quaid> | I wonder if any of the RHTers who deal with RHX would be interested 00:16:31 < knurd> | any volunteers for that job? 00:16:46 < knurd> | quaid, I haven't seen much from them yet 00:16:56 * | mmcgrath is here now, sorry 00:16:58 * | quaid cannot do it but thinks any of the current and new member dude would be good 00:16:58 --- | c_hoke_ is now known as c_hoke 00:16:59 < knurd> | there was only the zenoss discussions, but that just faded out 00:17:00 * | stahnma doesn't know if he has the time available.... 00:17:13 < quaid> | knurd: that is part of the idea, maybe if they were more involved as leaders ... 00:17:15 < knurd> | nirik do you want to do it? 00:17:26 < quaid> | pile on nirik! 00:17:38 < knurd> | quaid, as I mentioned on the list: we can make the steering committee even bigger if we want to 00:17:44 < knurd> | and if it's good for EPEL 00:17:48 < nirik> | ha. I would do it if no one else wanted the job... ;) If someone did that would be fine with me too... I am also low on time. 00:18:01 --> | ldimagg__ (Len DiMaggio) has joined #fedora-meeting 00:18:08 <-- | ldimaggi_ has quit (Read error: 110 (Connection timed out)) 00:18:12 < stahnma> | that's how I feel, and can only make meetings occassionally as they are in the middle of $DAYJOB 00:18:12 < knurd> | seven people in hte steering committe IMHO is a goal and not a hard number/must 00:18:30 < knurd> | stahnma, with me out of the mix you guys could find a better time 00:18:38 < knurd> | as then everyone is based in the US 00:18:42 < knurd> | afaics 00:19:00 < stahnma> | I though Jeff_S was in Europe somewhere... 00:19:05 < quaid> | true that 00:19:07 < knurd> | he is? 00:19:13 < quaid> | Portland, OR I thought 00:19:23 * | stahnma could be confused, or maybe he was travelling when I asked 00:19:28 < quaid> | sheltren? 00:19:33 * | smooge deals with 20 phone calls at once... 00:19:39 < smooge> | thanks everyone for the support 00:19:52 < knurd> | have fun with the phone 00:20:05 < knurd> | smooge, or would you me interested in the chairmen's job? 00:20:10 < smooge> | I am interested 00:20:29 < smooge> | my platform is free beer and penguin mints 00:20:58 < knurd> | so, that makes smooge ("I am interested") and nirik ("I would do it if no one else wanted the job...[...] I am also low on time.") 00:21:03 < knurd> | afaics 00:21:21 < knurd> | I'd say we continue to discuss this on the list over the next few days 00:21:25 < nirik> | perhaps throw that to the list and see if anyone else is interested, and we can vote/dicuss next meeting? 00:21:27 < smooge> | okie dokie 00:21:30 < knurd> | and then find a solution in the next meeting? 00:21:32 < stahnma> | + 00:21:57 < knurd> | k, seems we are all in agreement here 00:22:06 < knurd> | I'll annouce it on the list then 00:22:18 < knurd> | anything else regarding this topic? 00:22:32 < knurd> | any other self nominations for EPEL steeting committee members? 00:23:19 * | knurd takes that as "no" and "no" and moves on 00:23:26 --- | knurd has changed the topic to: EPEL SIG Meeting | broken dep reports go to the list | mmcgrath ? | http://fedoraproject.org/wiki/EPEL/Tasks/Misc 00:23:29 < knurd> | mmcgrath, still around? 00:23:42 < mmcgrath> | yeah 00:23:47 < knurd> | is "the broken deps report" script stil lrunning for EPEL? 00:23:51 < nirik> | knurd: I mailed mschewnt asking about setting his script up on the buildsys box 00:23:52 * | mdomsch is late I see 00:23:56 < mmcgrath> | AFAIK it is. let me look. 00:23:57 < mdomsch> | what did I get volunteered for? 00:24:46 < knurd> | mdomsch, nothing yet; but if you want to become a EPEL steering committee member feel free to self nominate 00:24:49 < mmcgrath> | knurd: hrm, looks like the cron job got removed. 00:24:50 < smooge> | mdomsch, installing the script onto the buildsys box :).. but I was joking 00:25:04 < mmcgrath> | I'll need to figure out what happened to it but will make sure its running. 00:25:08 --> | rharrison (Russell Harrison) has joined #fedora-meeting 00:25:15 < knurd> | mmcgrath, don't invest any work 00:25:27 < knurd> | mmcgrath, afaics the script from mschwendt is way better 00:25:33 < knurd> | mmcgrath, I#d say we switch to his one 00:25:50 < knurd> | mmcgrath, mschwendt might even have permissions to set it up on that box 00:25:56 < knurd> | and his script mails the list 00:26:08 < knurd> | something the old script didn't do 00:26:14 < mmcgrath> | knurd: that totally works for me, mschwendt rocks. 00:26:36 < mmcgrath> | hopefully his script doesn't take an hour to run either :-/ 00:26:57 < knurd> | mmcgrath, k; then we are all up2date then; nirik will talk to mschwendt about it 00:27:03 < knurd> | (or did already ;-) ) 00:27:15 --- | knurd has changed the topic to: EPEL SIG Meeting | Free discussion around EPEL 00:27:18 < nirik> | well, sent email in any case. 00:27:20 < knurd> | anything else? 00:27:35 < smooge> | ok how are we doing for packages etc? 00:27:46 < smooge> | how many are still in waiting to be branched etc? and wish list? 00:27:53 --- | jwb is now known as jwb_gone 00:28:12 < stahnma> | smooge: that sounds like good metrics to have 00:28:18 < knurd> | smooge, we have 1000 srpms now in epel5 + epel5 testing and come close to 2000 rpms 00:28:39 < smooge> | is that src.rpms or combined x.rpms and src.rpms? 00:28:44 < knurd> | waiting to be branched -> there are about 5500 package in fedora rawhide iirc 00:28:59 < knurd> | about 1600 srpms in rhel5 00:29:03 < smooge> | hmmm I counted 4500 src.rpms in fedora rawhide earlier this week 00:29:15 * | nirik should poke ixs and silug again... there are some perl packages I need before I can branch munin... 00:29:32 < knurd> | smooge, http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus says: 00:29:33 < knurd> | - 5634 packages 00:29:34 < knurd> | - 9260 binary rpms in devel 00:29:52 < knurd> | but I'm not sure how that's counted 00:30:11 < knurd> | my hope for the long term future for EPEL was: continue as we do 00:30:14 < nirik> | I see 5299 src.rpms in devel right now 00:30:31 < knurd> | and when RHEL6 ships poke Fedora maintainers and build lots of stuff for EPEL 00:30:47 < smooge> | ah I was looking at 8/Everthings/SRPMS directory 00:31:10 < knurd> | smooge, then you missed new pacakges that entered Fedora since F8 was shipped 00:31:19 < knurd> | as those are in the updates repo only 00:31:26 < smooge> | yeah.. 5299 is what I see too. 00:32:40 < smooge> | Ok one thing I would like to look at doing is getting a discussion going on when we move packages from testing to stable. I would like to work on a regular schedule for it so that 'customers' would know that Black Tuesday was coming up or something 00:32:40 < knurd> | some of them make not much sense for EPEL 00:32:46 < knurd> | hunspell-dicts for example 00:33:21 < knurd> | smooge, the dates are: mid months around the 15th for EPEL4 and early each months around the 1st for EPEL5 00:33:29 < smooge> | duh 00:33:35 < smooge> | I am way behind on stuff 00:33:50 < knurd> | tha's quite new; we settled on that one or two meetings ago 00:33:51 < smooge> | ok need to go over the wiki to catch up with stuff. 00:34:15 < knurd> | smooge, np, keeping track of everything in Fedora-land is hard 00:35:02 < knurd> | anything else? 00:35:12 < smooge> | no thats about it. 00:35:32 <-- | kital has quit (Read error: 110 (Connection timed out)) 00:35:37 * | knurd will close the meeting in 30 00:35:43 < smooge> | I think I will go over the EPEL pages and see what needs to be updated 00:35:46 < smooge> | Oh one second 00:35:49 < smooge> | mirrors 00:36:17 * | knurd waits 00:36:24 < smooge> | I think once we are pushing things regularly and getting more packages.. it would be a good idea to start recruuitiong more mirrors 00:36:34 < smooge> | s/once/now/ 00:36:53 < nirik> | sure, always good... how many do we have now? 00:36:54 < smooge> | how does this usually happen (and am I going over something that is already said?) 00:36:56 * | nirik goes to look. 00:37:00 < knurd> | http://mirrors.fedoraproject.org/publiclist/EPEL/ 00:37:15 < knurd> | there are a few, but more can't hurt 00:37:24 < knurd> | I'm not on the mirror-list 00:37:29 < knurd> | anyone else? 00:38:10 < knurd> | asking on that closed list might be the best start for more mirrors 00:38:19 < smooge> | I think I have a couple of things at the back of my mind. I will try to get them out for the next meeting 00:39:12 < knurd> | smooge, thx; in case of questions with the mirror stuff contact mdomsch; he maintains the stuff on http://mirrors.fedoraproject.org and he should be on the mirror-admins-list 00:39:17 < smooge> | Hmm I need to get john branched. Will go finish up my fedora project activation stuff and work on that 00:39:54 < smooge> | knurd, actually I am also on the list :). They forgot to take me off when I left RH :) 00:40:01 < knurd> | hehe :) 00:40:09 < knurd> | anything else? 00:40:12 * | knurd will close the meeting in 30 00:40:41 * | knurd will close the meeting in 10 00:40:53 < knurd> | -- MARK -- Meeting end 00:40:53 --- | 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
On Wed, 30 Jan 2008 21:23:48 +0100, Thorsten Leemhuis wrote:
00:09:26 < knurd> | so, how to move on? ask mschwendt to install is? nirik, or do you want to handle that? you likely have the needed permissions as well 00:09:42 --> | mdomsch (Matt_Domsch) has joined #fedora-meeting 00:10:11 < smooge> | mdomsch, has permission to. he can do anything :) 00:10:17 < nirik> | sure, I can ask him if we can just run it on the buildsys box, or what. 00:10:27 < knurd> | nirik, k, thx
00:23:51 < nirik> | knurd: I mailed mschewnt asking about setting his script up on the buildsys box
So, here are some public comments on that. Didn't know this was a topic in the meeting once more.
For Extras we used to execute some nohup background jobs in the post-push hook (near the bottom of the pushscript config file). That was the primary way of running scripts, particularly when pushes were done almost daily. [To push without re-running such stuff, there's option -s which also skips the repoprune and repoview steps, btw.] In the signer's group env one must be careful, though, and work around permission problems in some Python generated files (e.g. urlgrabber files created by yum) if they are shared.
Running fully automated hardly ever was a good idea because Core and Extras were not pushed at once and could be out-of-sync. Whether to include or exclude updates-testing was an unresolved matter, too. Later I switched to preventing broken deps by excluding packages from needsign with the help of the RCNeedsign.py script. That got rid of the public summaries and only mailed packagers privately (warning about whether needsign and/or test updates were included).
To run the code as a cron job somebody first needs to spend some time and determine under which circumstances it would run into error conditions. Such as metadata loading problems (also adding the lockfile check for the Plague needsign repodata lock), and then try to catch all errors. Otherwise there would be the risk that it spams packagers with wrong reports. Mission objective: also check yum api's error return codes.
I haven't done that extra work because of the Core+Extras+Test Updates split (see above) and because it has never been agreed on how often to mail broken deps reports to owners and the list. The initial work-around for repo I/O problems was to sleep 12 minutes when repoclosure returned an error and retry a few times. That seemed to work for cron as well as the background jobs. The old scripts are in fedora cvs, so copying existing bits from them would be possible.
The old repoclosure code is integrated into the pushscript and the RCNeedsign.py module -- [That's the one that installs the pkgs from the needsign queue into temporary repos to allow for proper ExcludeArch/ExclusiveArch handling prior to running repoclosure on that. Originally I wanted to test adding multilib support to it but didn't continue when koji+bodhi appeared on the radar.]
The additional Extras repoclosure scripts on the buildsys machine are a bit specific to Extras. Not all constants are fetched from the Config_*.py files. E.g. the script needed to distinguish between Core and Extras (it's a similar thing for for CentOS-or-RHEL and EPEL) through a repoid keyword, hardcoded in the rc-report.py script. Which package owners list to read was hardcoded, too. A few other features were added without any way to configure them (e.g. the history support that printed the age in days of a broken dep or the function that only sends a summary to the list if there are new reports). The used Yum is a private copy with the checkForObsoletes patch applied.
The recently published repoclosure tarball is easier to modify. It doesn't depend on the pushscript code or config files. It takes an ordinary yum.conf file as input. It can be configured with Fedora Account System account details for package owner db access outside fedora infrastructure. All it needs is Yum post 2.6.1 with checkForObsolete.
Whether and how often to run a script like that, whether or not to include "testing" or needsign (*without* multilib, ExcludeArch, Exclusive}Arch), whether to run against CentOS or the private RHEL repos, I don't want to decide. I would appreciate if somebody else took over. Sometimes people, who have a fixed package in updates-testing already, complain about a broken deps report that doesn't cover updates-testing. On the other hand, some people complain if a report covers updates-testing. Furthermore, there are packagers who believe every report to be false. The only fun of doing repoclosure stuff is to see those people who understand the reports and fix their packages silently as soon as they receive a report.
On 30.01.2008 23:07, Michael Schwendt wrote:
On Wed, 30 Jan 2008 21:23:48 +0100, Thorsten Leemhuis wrote:
00:09:26 < knurd> | so, how to move on? ask mschwendt to install is? nirik, or do you want to handle that? you likely have the needed permissions as well 00:09:42 --> | mdomsch (Matt_Domsch) has joined #fedora-meeting 00:10:11 < smooge> | mdomsch, has permission to. he can do anything :) 00:10:17 < nirik> | sure, I can ask him if we can just run it on the buildsys box, or what. 00:10:27 < knurd> | nirik, k, thx 00:23:51 < nirik> | knurd: I mailed mschewnt asking about setting his script up on the buildsys box
So, here are some public comments on that.
thx for your detailed mail Michael. It helps a lot!
Didn't know this was a topic in the meeting once more.
Well, a solution still hasn't be found and we need a dep checking script. We could reenable the old one, but it doesn't mail the list, and that's needed as some fellow packagers ignore ^w miss the mails they get directly.
[...] The recently published repoclosure tarball is easier to modify. It doesn't depend on the pushscript code or config files. It takes an ordinary yum.conf file as input. It can be configured with Fedora Account System account details for package owner db access outside fedora infrastructure. All it needs is Yum post 2.6.1 with checkForObsolete.
That sounds to me like the way forward. mmcgrath, nirik, do we have a new-enough yum for it?
Whether
We IMHO really need a dep checker script.
and how often to run a script like that,
How long does it take to run? I'd say if it doesn't consume to many resources it'd say at least two, better three times a week. Once a week is the minimum I'd say.
whether or not to include "testing"
For EPEL we afaics need to run it one without testing and once with. Only then we notice if a dep is broken in stable and only then people will tell the signers to push a new build to stable quickly to fix the issue properly.
or needsign
Not sure. I don't think that's worth the trouble.
(*without* multilib, ExcludeArch, Exclusive}Arch),
Multilib-checks likely need to be done.
whether to run against CentOS or the private RHEL repos
I'd prefer the private RHEL repos if that's possible without to much trouble. CentOS would be fine as well, but there are small differences (no PPC (yet) for example; small delay with updates, new releases)
, I don't want to decide.
I'd finding the answers should be that hard. I'd even say we should be able to do this quickly here on the list.
I would appreciate if somebody else took over.
mmcgrath, nirik?
[...]
Cu knurd
On Feb 3, 2008 7:37 AM, Thorsten Leemhuis fedora@leemhuis.info wrote:
whether to run against CentOS or the private RHEL repos
I'd prefer the private RHEL repos if that's possible without to much trouble. CentOS would be fine as well, but there are small differences (no PPC (yet) for example; small delay with updates, new releases)
Well how many people have PPC :)?
Actually I was going to look at testing against both. This allows us to catch items where CentOS has something and RHEL doesn't.. and if something conflicts with the CentOS 'extras' repo so that problems can be managed correctly.
On 03.02.2008 18:52, Stephen John Smoogen wrote:
On Feb 3, 2008 7:37 AM, Thorsten Leemhuis fedora@leemhuis.info wrote:
whether to run against CentOS or the private RHEL repos
I'd prefer the private RHEL repos if that's possible without to much trouble. CentOS would be fine as well, but there are small differences (no PPC (yet) for example; small delay with updates, new releases)
Well how many people have PPC :)?
No idea :)
Actually I was going to look at testing against both.
Yeah, might be a good idea.
This allows us to catch items where CentOS has something and RHEL doesn't..
Well, no offense, but that's afaics would be a bug in CentOS, as they aim to be compatible.
and if something conflicts with the CentOS 'extras' repo so that problems can be managed correctly.
Good idea.
But on the other hand: the repotag wars were now nearly a year ago and one of the bad guys (/me) leaves soon. Maybe we could somehow come over it and make peace with the CentOS guys and work together in a better way that works better for both sides? That was my and afaics everybody's else plan when we started EPEL, but didn't happen due some mis-communication and misunderstandings (that's the short story and I blame myself for a few of those issues that lead to the current situation) in the initial EPEL start phase.
CU knurd
Thorsten Leemhuis wrote:
On 03.02.2008 18:52, Stephen John Smoogen wrote:
On Feb 3, 2008 7:37 AM, Thorsten Leemhuis fedora@leemhuis.info wrote:
whether to run against CentOS or the private RHEL repos
I'd prefer the private RHEL repos if that's possible without to much trouble. CentOS would be fine as well, but there are small differences (no PPC (yet) for example; small delay with updates, new releases)
Well how many people have PPC :)?
No idea :)
Actually I was going to look at testing against both.
Yeah, might be a good idea.
This allows us to catch items where CentOS has something and RHEL doesn't..
Well, no offense, but that's afaics would be a bug in CentOS, as they aim to be compatible.
Uhm no. Red Hat does not always ship various -devel and some other packages when a package was built. CentOS also has made sure that you get everything that would have come from a package so that you could use it to do other development. This was a big problem in 2/3 and a bit in 4. I think 5 may not have had this issue.
and if something conflicts with the CentOS 'extras' repo so that problems can be managed correctly.
Good idea.
But on the other hand: the repotag wars were now nearly a year ago and one of the bad guys (/me) leaves soon. Maybe we could somehow come over it and make peace with the CentOS guys and work together in a better way that works better for both sides? That was my and afaics everybody's else plan when we started EPEL, but didn't happen due some mis-communication and misunderstandings (that's the short story and I blame myself for a few of those issues that lead to the current situation) in the initial EPEL start phase.
That is my hope. I can't say that it will happen, but I will work towards it.
On 03.02.2008 19:42, Stephen Smoogen wrote:
Thorsten Leemhuis wrote:
On 03.02.2008 18:52, Stephen John Smoogen wrote:
On Feb 3, 2008 7:37 AM, Thorsten Leemhuis fedora@leemhuis.info wrote: This allows us to catch items where CentOS has something and RHEL doesn't..
Well, no offense, but that's afaics would be a bug in CentOS, as they aim to be compatible.
Uhm no. Red Hat does not always ship various -devel and some other packages when a package was built. CentOS also has made sure that you get everything that would have come from a package so that you could use it to do other development. This was a big problem in 2/3 and a bit in 4. I think 5 may not have had this issue.
Ahh, k, didn't know that. Thx for letting me/us know.
and if something conflicts with the CentOS 'extras' repo so that problems can be managed correctly.
Good idea.
But on the other hand: the repotag wars were now nearly a year ago and one of the bad guys (/me) leaves soon. Maybe we could somehow come over it and make peace with the CentOS guys and work together in a better way that works better for both sides? That was my and afaics everybody's else plan when we started EPEL, but didn't happen due some mis-communication and misunderstandings (that's the short story and I blame myself for a few of those issues that lead to the current situation) in the initial EPEL start phase.
That is my hope. I can't say that it will happen, but I will work towards it.
I actually some weeks ago looked once what's in CentOS extras that's not yet in EPEL. The xfce desktop environment is still missing in EPEL, but nirik is planing to build it iirc (the CentOS extras package are rebuilds of the Fedora packages). Mono is also not completely in EPEL, but Xavier has started with it iirc.
Note that if EPEL really wants to be suitable for both RHEL and CentOS without causing to many broken deps problems EPEL need to invent some tricks (two repos?) in the long run afaics, as sometimes stuff hits RHEL a bit earlier then CentOS. That has consequences for CentOS&EPEL users if a EPEL packages depends on the new stuff; the quarterly updates (does anybody have a better name for them; they are not quarterly...) are the big (only?) problem area here afaics.
CU knurd
Thorsten Leemhuis wrote:
On 03.02.2008 19:42, Stephen Smoogen wrote:
Thorsten Leemhuis wrote:
On 03.02.2008 18:52, Stephen John Smoogen wrote:
On Feb 3, 2008 7:37 AM, Thorsten Leemhuis fedora@leemhuis.info wrote: This allows us to catch items where CentOS has something and RHEL doesn't..
Well, no offense, but that's afaics would be a bug in CentOS, as they aim to be compatible.
Uhm no. Red Hat does not always ship various -devel and some other packages when a package was built. CentOS also has made sure that you get everything that would have come from a package so that you could use it to do other development. This was a big problem in 2/3 and a bit in 4. I think 5 may not have had this issue.
Ahh, k, didn't know that. Thx for letting me/us know.
I think it was brought a couple of times a loooong time ago.. but its been over a year since I remember.
and if something conflicts with the CentOS 'extras' repo so that problems can be managed correctly.
Good idea.
But on the other hand: the repotag wars were now nearly a year ago and one of the bad guys (/me) leaves soon. Maybe we could somehow come over it and make peace with the CentOS guys and work together in a better way that works better for both sides? That was my and afaics everybody's else plan when we started EPEL, but didn't happen due some mis-communication and misunderstandings (that's the short story and I blame myself for a few of those issues that lead to the current situation) in the initial EPEL start phase.
That is my hope. I can't say that it will happen, but I will work towards it.
I could have added some words to that line. I meant it as:
It is my hope that EPEL/CentOS communities will be able to work better together as there are more CentOS boxes than RHEL boxes. I can't say that it will happen, but I will at least make sure that our differences are easier for people to know about.
I actually some weeks ago looked once what's in CentOS extras that's not yet in EPEL. The xfce desktop environment is still missing in EPEL, but nirik is planing to build it iirc (the CentOS extras package are rebuilds of the Fedora packages). Mono is also not completely in EPEL, but Xavier has started with it iirc.
Note that if EPEL really wants to be suitable for both RHEL and CentOS without causing to many broken deps problems EPEL need to invent some tricks (two repos?) in the long run afaics, as sometimes stuff hits RHEL a bit earlier then CentOS. That has consequences for CentOS&EPEL users if a EPEL packages depends on the new stuff; the quarterly updates (does anybody have a better name for them; they are not quarterly...) are the big (only?) problem area here afaics.
"When they get to them" updates. Black Someday is what I know two places have called it when they start getting pages that various desktops started auto-updating and the network is full.
Sorry for the delay here... finally getting around to some backlogged emails. ;(
On Sun, 03 Feb 2008 15:37:47 +0100 fedora@leemhuis.info (Thorsten Leemhuis) wrote:
On 30.01.2008 23:07, Michael Schwendt wrote:
On Wed, 30 Jan 2008 21:23:48 +0100, Thorsten Leemhuis wrote:
00:09:26 < knurd> | so, how to move on? ask mschwendt to install is? nirik, or do you want to handle that? you likely have the needed permissions as well 00:09:42 --> | mdomsch (Matt_Domsch) has joined #fedora-meeting 00:10:11 < smooge> | mdomsch, has permission to. he can do anything :) 00:10:17 < nirik> | sure, I can ask him if we can just run it on the buildsys box, or what. 00:10:27 < knurd> | nirik, k, thx 00:23:51 < nirik> | knurd: I mailed mschewnt asking about setting his script up on the buildsys box
So, here are some public comments on that.
thx for your detailed mail Michael. It helps a lot!
Didn't know this was a topic in the meeting once more.
Well, a solution still hasn't be found and we need a dep checking script. We could reenable the old one, but it doesn't mail the list, and that's needed as some fellow packagers ignore ^w miss the mails they get directly.
[...] The recently published repoclosure tarball is easier to modify. It doesn't depend on the pushscript code or config files. It takes an ordinary yum.conf file as input. It can be configured with Fedora Account System account details for package owner db access outside fedora infrastructure. All it needs is Yum post 2.6.1 with checkForObsolete.
That sounds to me like the way forward. mmcgrath, nirik, do we have a new-enough yum for it?
On the buildsys? no. 2.6.0 is there.
Whether
We IMHO really need a dep checker script.
Yes. Agreed.
and how often to run a script like that,
How long does it take to run? I'd say if it doesn't consume to many resources it'd say at least two, better three times a week. Once a week is the minimum I'd say.
Looks like it takes about 5min here. I would say once a week is enough... unless the broken deps are in stable, then instead of running it more, I think we just go and try and fix them or contact the maintainer via email/irc/phone to fix them.
whether or not to include "testing"
For EPEL we afaics need to run it one without testing and once with. Only then we notice if a dep is broken in stable and only then people will tell the signers to push a new build to stable quickly to fix the issue properly.
Sure, but hopefully the stable run is empty usually.
or needsign
Not sure. I don't think that's worth the trouble.
Yeah, me either.
(*without* multilib, ExcludeArch, Exclusive}Arch),
Multilib-checks likely need to be done.
Yeah.
whether to run against CentOS or the private RHEL repos
I'd prefer the private RHEL repos if that's possible without to much trouble. CentOS would be fine as well, but there are small differences (no PPC (yet) for example; small delay with updates, new releases)
Well, it's not easy to do that from what I can see. The buildsys doesn't have a new enough yum, and none of my machines here have access to RHEL repos. I can easily run it against centos...
, I don't want to decide.
I'd finding the answers should be that hard. I'd even say we should be able to do this quickly here on the list.
I would appreciate if somebody else took over.
mmcgrath, nirik?
I can run it from here against centos. Will post the results to the list, and if they look good for everyone, can enable it to mail maintainers. Does that sound good?
Cu knurd
kevin
On Fri, 15 Feb 2008 12:39:24 -0700, Kevin Fenzi wrote:
That sounds to me like the way forward. mmcgrath, nirik, do we have a new-enough yum for it?
On the buildsys? no. 2.6.0 is there.
A newer one is in /srv/extras-push/work/buildsys-utils/pushscript, which is a cvs working-copy directory.
You can uncomment the
sys.path.insert(0,'/srv/extras-push/work/buildsys-utils/pushscript')
at the beginning of the repoclosure script to use it on the buildsys machine.
On 15.02.2008 20:39, Kevin Fenzi wrote:
On Sun, 03 Feb 2008 15:37:47 +0100 fedora@leemhuis.info (Thorsten Leemhuis) wrote:
On 30.01.2008 23:07, Michael Schwendt wrote:
On Wed, 30 Jan 2008 21:23:48 +0100, Thorsten Leemhuis wrote: and how often to run a script like that,
How long does it take to run? I'd say if it doesn't consume to many resources it'd say at least two, better three times a week. Once a week is the minimum I'd say.
Looks like it takes about 5min here. I would say once a week is enough... unless the broken deps are in stable, then instead of running it more, I think we just go and try and fix them or contact the maintainer via email/irc/phone to fix them.
If it really takes only a few minutes to run I'd much prefer to run it right after every push -- that way packagers normally will get a feedback closely after they realized a change.
If we do it only once a week the worst case might be around 11 days (7 days between runs + 4 days from needsign to repo) between doing a change on foo and getting a mail that "foo broke the world". That's to long IMHO.
whether or not to include "testing"
For EPEL we afaics need to run it one without testing and once with. Only then we notice if a dep is broken in stable and only then people will tell the signers to push a new build to stable quickly to fix the issue properly.
Sure, but hopefully the stable run is empty usually.
And if not we quickly should do something. Even in testing there are to many broken deps. :-/
CU knurd
On Sat, 16 Feb 2008 12:43:45 +0100 fedora@leemhuis.info (Thorsten Leemhuis) wrote:
On 15.02.2008 20:39, Kevin Fenzi wrote:
On Sun, 03 Feb 2008 15:37:47 +0100 fedora@leemhuis.info (Thorsten Leemhuis) wrote:
On 30.01.2008 23:07, Michael Schwendt wrote:
On Wed, 30 Jan 2008 21:23:48 +0100, Thorsten Leemhuis wrote: and how often to run a script like that,
How long does it take to run? I'd say if it doesn't consume to many resources it'd say at least two, better three times a week. Once a week is the minimum I'd say.
Looks like it takes about 5min here. I would say once a week is enough... unless the broken deps are in stable, then instead of running it more, I think we just go and try and fix them or contact the maintainer via email/irc/phone to fix them.
If it really takes only a few minutes to run I'd much prefer to run it right after every push -- that way packagers normally will get a feedback closely after they realized a change.
Well, or if we are going to do that, we could add in the needsign queue and run it before a push? Or just do that and make it a policy to never push a package with broken deps?
If we do it only once a week the worst case might be around 11 days (7 days between runs + 4 days from needsign to repo) between doing a change on foo and getting a mail that "foo broke the world". That's to long IMHO.
Sure, I guess...
whether or not to include "testing"
For EPEL we afaics need to run it one without testing and once with. Only then we notice if a dep is broken in stable and only then people will tell the signers to push a new build to stable quickly to fix the issue properly.
Sure, but hopefully the stable run is empty usually.
And if not we quickly should do something. Even in testing there are to many broken deps. :-/
Agreed. So, perhaps we should talk about just making it a policy to never push a package with broken deps, and remove the ones that are currently in testing with broken deps.
CU knurd
kevin
epel-devel@lists.fedoraproject.org
-
Kevin Fenzi -
Michael Schwendt -
Rahul Sundaram -
Stephen John Smoogen -
Thorsten Leemhuis