5:06 a.m.
Hi, folks.
I've been active enough that an intro probably isn't needed, but I've
not successfully worked my way through the Fedora access to manage
particular packages nor have I gotten koji access. I'd particularly
like to get the old "mkrdns" tool into Fedora and EPEL, since it's a
personal favorite for auto-managing reverse DNS and it's very stable.
Is there someone who can walk me through the Fedora koji access
procedures? I've got Fedora 19 running in a VM, with access to my
github repositories. I normally build my tools with "mock" for
testing, but I'm happy to work with other build systems.
Nico Kadel-Garcia <nkadel(a)gmail.com>
10:57 a.m.
Hi Nico,
On Tue, Jul 09, 2013 at 06:06:38AM -0400, Nico Kadel-Garcia wrote:
I've been active enough that an intro probably isn't needed,
but I've
not successfully worked my way through the Fedora access to manage
particular packages nor have I gotten koji access. I'd particularly
like to get the old "mkrdns" tool into Fedora and EPEL, since it's a
personal favorite for auto-managing reverse DNS and it's very stable.
Is there someone who can walk me through the Fedora koji access
procedures? I've got Fedora 19 running in a VM, with access to my
github repositories. I normally build my tools with "mock" for
testing, but I'm happy to work with other build systems.
to get koji build access you need to become a package maintainer as
described here:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
Essentially you need to create a spec/SRPM for the package, upload it to
Bugzilla and find a sponsor that reviews the files. Then you will become
a package maintainer and get koji access as well. To find a sponsor it
is usually helpful to show your knowledge to the process and the
packaging guidelines by preliminary reviewing other peoples specs/SRPMs
on Bugzilla.
I hope the complex procedure does not repel you and you still like to
get the package into Fedora. :-)
If you have further questions, please ask. If you did some preliminary
reviews and do not find a sponsor, you can write me directly and I will
see what I can do as time permits.
Regards
Till
8:02 a.m.
On Tue, Jul 9, 2013 at 11:57 AM, Till Maas <opensource(a)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. 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.
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.
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.
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.
Time to submit some RFE's and bug reports, I think....
1:13 p.m.
On Sat, 13 Jul 2013 09:02:37 -0400
Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
On Tue, Jul 9, 2013 at 11:57 AM, Till Maas
<opensource(a)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
6 p.m.
On Sat, Jul 13, 2013 at 2:13 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Sat, 13 Jul 2013 09:02:37 -0400
Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
> On Tue, Jul 9, 2013 at 11:57 AM, Till Maas <opensource(a)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...
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.
6:23 p.m.
On Sat, Jul 13, 2013 at 07:00:14PM -0400, Nico Kadel-Garcia wrote:
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.
I'll certainly accept I should have been using
fedoraprojects.org, and
that's cool.
But why did you try fedoraproject.net? It should not be promoted
anywhere as far as I know.
Regards
Till
6:47 p.m.
On Sat, Jul 13, 2013 at 7:23 PM, Till Maas <opensource(a)till.name> wrote:
On Sat, Jul 13, 2013 at 07:00:14PM -0400, Nico Kadel-Garcia wrote:
> 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.
> I'll certainly accept I should have been using fedoraprojects.org, and
> that's cool.
But why did you try fedoraproject.net? It should not be promoted
anywhere as far as I know.
I'm frankly unsure. It worked enough to produce a legible
dist-6E-epel.cfg, just not a valid one due to the misused topurl.
4001
days inactive
4005
days old
6 comments
3 participants
participants (3)
-
Kevin Fenzi -
Nico Kadel-Garcia -
Till Maas