Re: Dumb newbie packager questions

[Stephen Gallagher]

On 10/25/2016 01:48 AM, Adam Williamson wrote:
> On Sat, 2016-10-22 at 22:08 -0600, William Moreno wrote:
>> 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)
> 
> Well, no, because it won't be the same release...that's the 'R' part of
> NEVR. The .fc26 / .fc25 / .fc24 you get in almost any Fedora package -
> it's the value of %{dist} - is part of the release.
> 
> I don't know what happens if you take the %{dist} out of your spec file
> and try to build it for two different build targets, but...don't do
> that. :)
> 

Having done that accidentally last week, I can tell you that the first one will
succeed and the second one will fail when it tries to tag the build at the end,
because the tag is based on NEVR. So the compilation phase will succeed, but the
Koji build as a whole will fail.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Dumb newbie packager questions

[Adam Williamson]

On Sat, 2016-10-22 at 22:08 -0600, William Moreno wrote:
> > 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

Note, this is conventionally given as NEVR (not NVRE), because that's
the logical order: the epoch is more important than both the version
and the release.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Dumb newbie packager questions

[Adam Williamson]

On Sat, 2016-10-22 at 22:08 -0600, William Moreno wrote:
> 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)

Well, no, because it won't be the same release...that's the 'R' part of
NEVR. The .fc26 / .fc25 / .fc24 you get in almost any Fedora package -
it's the value of %{dist} - is part of the release.

I don't know what happens if you take the %{dist} out of your spec file
and try to build it for two different build targets, but...don't do
that. :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Dumb newbie packager questions

[Christopher]

On Sun, Oct 23, 2016 at 12:36 AM William Moreno 
wrote:

> El 22/10/2016 10:27 p. m., "Christopher" 
> escribió:
> >
> > On Sun, Oct 23, 2016 at 12:09 AM William Moreno <
> williamjmore...@gmail.com> wrote:
> >>
> >> El 22/10/2016 9:51 p. m., "Christopher" 
> 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 :)
> >>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Dumb newbie packager questions

[William Moreno]

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

Also you can test to build in Corp
https://copr.fedorainfracloud.org

>>
>> > 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 :)
>>
>>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Dumb newbie packager questions

[Christopher]

On Sun, Oct 23, 2016 at 12:09 AM William Moreno 
wrote:

> El 22/10/2016 9:51 p. m., "Christopher" 
> 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?


> >
> > 2. Should I preserve the entire changelog in the 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.


> > 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 :)
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Dumb newbie packager questions

[William Moreno]

El 22/10/2016 9:51 p. m., "Christopher" 
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)
>
> 2. Should I preserve the entire changelog in the 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

> 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

> 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 :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org