On Sat, Jul 13, 2013 at 2:13 PM, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > On Sat, 13 Jul 2013 09:02:37 -0400 > Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote: > >> On Tue, Jul 9, 2013 at 11:57 AM, Till Maas <opensource@xxxxxxxxx> >> 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... Except that links I found published, with more detail about how to set up the koji command line tools, pointed precisely there. If it should be fedoraproject.org in general, good. But if one is going to host a website with a different top level domain, it really needs a different SSL key. What's present on fedoraproject.net seems to be simply the content of fedoraproject.org: this kind of duplication of sharing of a single website for multiple URL's is quite commonplace, but SSL creates a real certificate problem if they're in different domains. >> 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. Experimentation shows that running "mock -r dist-6E-epel-x86_64.cfg'' downloads some *.rpm files, but fails overall. When I looked, I saw .rpm files in /var/lib/mock/dist-6EE-epel/root/var/cache/yum/build/packages/. But on doublechecking for this claim, I saw that they're all size zero. Interesting!!!! >> 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: Well, yes. The mock defaults are what I use now. (Sometimes with tweaks, such as using a local mirror, using an internal RHEL mirror for licensed systems, or using Scientific Linux instead of CentOS.) But if I'm having problems with it, then I'd like other folks to know there's a problem and get it into Google's searchable environment of questions and answere. > 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. ;) Then the documentation should say that!!! If somethings going to be described in the documentation but not work in the field, I don't think it's fair to rely on "everyone knows that" or "it's obvious". It may be deduced, but I've got a lot of experience with weird build setups to work from. Not everyone's that experienced. >> Time to submit some RFE's and bug reports, I think.... > > It sounds to me like you got off track in the docs somewhere, we should > correct that. I'll certainly accept I should have been using fedoraprojects.org, and that's cool. The mock *.cfg files can accept comment lines. A comment for the "dist-6E-epel-* configurations saying something like this could be very helpful: # RHEL repositories available only inside koji build systems, not for home use. I wanted to use a testing build environment as close as possible to the koji environment, which I recognize may have component differences or updates not in concert with the published "mock" configurations. For example, in the published mock configs from RHEL 6 and Fedora 19, RHEL 4 based packages can no longer be compiled with the default epel-4-x86_64 configurations because the CentOS mirrorlists they used have been decommissioned: they need a rewrite to talk to http://vault.centos.org. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
