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