On Sun, Oct 23, 2016 at 12:36 AM William Moreno <williamjmorenor@gmail.com> wrote:

El 22/10/2016 10:27 p. m., "Christopher" <ctubbsii@fedoraproject.org> escribió:
>
> On Sun, Oct 23, 2016 at 12:09 AM William Moreno <williamjmorenor@gmail.com> wrote:
>>
>> El 22/10/2016 9:51 p. m., "Christopher" <ctubbsii@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 :)
>>