Getting koji access for some Perl tools

[Kevin Fenzi]

On Sat, 13 Jul 2013 09:02:37 -0400
Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> On Tue, Jul 9, 2013 at 11:57 AM, Till Maas <opensource at till.name>
> wrote:
> 
> > to get koji build access you need to become a package maintainer as
> > described here:
> > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
> 
> Thanks. I'm re-registered and have my keys and certificates, *BUT* I'm
> afraid I'm encountering just the sort of problem that made it so
> frustrating.
> 
> For example: doing the "koji mock-config" step pointed to the
> fedoraproject.net website as stated in the directions you pointed out
> creates SSL key problems. 

fedoraproject.net? where do you see that? 

What exact page do you see 'koji mock-config' in? 

(There's no mention of either of those things in the above page, so I
assume it's something off there?)

>That's because the HTTP websites used for
> content seem to have redirects pointed to HTTPS sites, and the key
> used for the fedoraproject.net website is actually the key for the
> fedoraproject.org domain. That's the sort of problem that happens when
> you redirect HTTP to HTTPS and don't consider the consequences of
> servicing sites that are not on the same hostname or domain.

I have no idea what you are trying to reach here. 
You shouldn't ever never to hit fedoraproject.net... 

> If I were administering that, I'd seriously consider not using HTTPS
> for that  content at all. It's a computational burden for the web
> servers or the proxies, and contributes to precisely this sort of
> problem.
> 
> Fortunately for me, I'm a weasel, and checked that simply replacing
> "fedoraproject.net" with "fedoraproject.org" in the URL's seems to
> help. But then the "mock  -r dist-6EE-epel-build-x86_64 init" fails,
> because it can download some but not others of the RPM's. So it looks
> like the upstream yum repository for that is messed up.

There is no external access to RHEL buildroots. Thats all internal to
the buildsystem. 

> f19-x86_64 seems to work, so I can work with that for the moment. But
> I'm really aiming at getting some of this material from Fedora  19
> ported back to RHEL 6 for EPEL.

Use the mock configs shipped with the mock package. 
They point to CentOS, but that should be good enough for your local
testing, no? Or do scratch builds in the buildsystem: 

 koji build --scratch dist-6E-epel foo.src.rpm

> I've also noticed something alarming as well: the f19-i386.cfg,
> f19-x86_64.cfg, etc.  files all use the same "root" for mock.
> That's.... really, really bad if  you ever do cross-platform builds on
> the same mock server. "clean" operations for one setup will overlap
> with build operations for another, and chaos can ensue. "root" in a
> mock *.cfg file should be the same as "basename file.cfg .cfg", in
> general, to void precisely that kind of overlap. I can see why it
> might not occur in koji's build environment: they seem to have
> dedicated servers to each build environment and architecture. But if
> you've got only one build server and build multiple architecture
> packages, it's bad.

This is just one more reason you should never use the koji internal
configs for your testing. ;)
> 
> Time to submit some RFE's and bug reports, I think....

It sounds to me like you got off trac in the docs somewhere, we should
correct that.

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130713/e95087e8/attachment.sig>