On Sun, Oct 23, 2016 at 12:36 AM William Moreno <williamjmorenor(a)gmail.com>
wrote:
El 22/10/2016 10:27 p. m., "Christopher"
<ctubbsii(a)fedoraproject.org>
escribió:
>
> On Sun, Oct 23, 2016 at 12:09 AM William Moreno <
williamjmorenor(a)gmail.com> wrote:
>>
>> El 22/10/2016 9:51 p. m., "Christopher"
<ctubbsii(a)fedoraproject.org>
escribió:
>> >
>> > I should probably know the answers to these by now, but...
>> >
>> > 1. If I trigger more than one build for the same NVR in Koji, which
one will get tagged, and when? Which one will Bodhi use when I create an
update?
>>
>> By default koji will not let build a package of there is a previus buid
with the same NVR in the same branch, you can build many times the same NVR
in diferent branches, (fedpkg switch-branch)
>>
>>
>
> If the previous build failed, it should be okay, right? I've been
bumping the release each time I make a change in git. I probably only need
to do it once until the next successful build, right?
Yes, only remember to add a line to the changelog is you update the spec.
>>
>> >
>> > 2. Should I preserve the entire changelog in thJme SPEC? Or should I
roll it over when I update to the latest upstream? It seems the changelog
could easily become the bulk of a package if everything is preserved, and
I'd think git would suffice for anything older than the last few rebases
onto latest upstream.
>>
>> Please keep al the changes in the changelog, al lest than you have some
really olds entries (some years ago)
>>
>> > 3. What does the "e" stand for in n-v-r-e ?
>>
>> The E comer for the epoch rmp tag, this overrides the release and
version tags
>>
>> > 4. I'm familiar with `fedpkg commit --clog` for easy git log
messages, but is there some easy tool for generating the clog message
(especially the date/email/version line) automatically?
>>
>> You can use rpmdev-bumpspec foo.spec
>
>
> Awesome! And, from that I figured out how I can override the info with
RPM_PACKAGER env.
>
>>
>> > 5. What is going on here:
https://kojipkgs.fedoraproject.org//work/tasks/4279/16174279/build.log It
says a file is bad... but I can see the file in git and it looks fine.
Where can I go to see if Koji itself is undergoing problems. Is there a
server status page for outages within the Fedora infrastructure?
>>
>> Try fedpkg local to trigger a local build, source files must be
uploaded by fedpkg new-sources path/to/tarball.tgz
>>
>> The source0 file it is not espected to.be in the package repo, patches
and others soureces can be in the repo
>
>
> These sources are definitely in the repo, and the build works fine
locally. The error is from a missing patch (not Source0), and this patch is
not new and has not changed since the last successful build. Everything
works locally with both mockbuild and local. I'm pretty sure this is a
problem with koji, not the package. I added this as a newbie question,
because I was wondering if there was a server status page I could go to
check to see koji's health.
Do you mean something like this
http://status.fedoraproject.org
Yes, just like that :) I should have guessed it. Unfortunately, that page
is manually updated, so it only shows known issues. However, it does have a
very useful link to IRC, which itself links to a pagure issue tracker, so I
have options for troubleshooting this with fedora-infrastructure team off
list.
Also you can test to build in Corp
https://copr.fedorainfracloud.org
Copr is neat, but I haven't found it to add much value to updating existing
packages, which need to build successfully in koji's buildroots.
For my specific case, since the package builds fine with `fedpkg local` and
`fedpkg mockbuild`, and the the status site shows no issues, I'll follow up
on IRC #fedora-admin
>>
>> > 6. Why does
fedoraproject.org redirect to getfedora.org?
>>
>> This was of the FEDORA Next move get fedora is the home of the
Fedora[Server, Cloud, Worstation] brands, new products new site :)
>>