Discussion:
Trying out More Go Packaging: Bugs and Questions
(too old to reply)
Fabio Valentini
2018-02-27 14:49:44 UTC
Permalink
Hi everybody,

I've been following the (long overdue) improvements concerning go packaging
in fedora, and since I saw that packages are starting to make use of the
new mechanisms, I wanted to finally check it out and started "converting"
one of my own (one of ~50) golang packages
(golang-github-AudriusButkevicius-cli). However, I came across a few
stumbling blocks (and at least one bug) in the current implementation
(please correct me if I am just doing it wrong):

1) The currently implemented macros have different names than the ones that
were proposed at the "More Go Packaging" wiki page, which confused me. I
had to look at a recently "converted" package to figure out the correct
macro names. I guess the documentation just hasn't caught up yet here.

2) Additionally, I wasn't able to figure out why I have to set both
"%gobaseipath" and "%provider_prefix".

3) The %gosource macro doesn't work correctly (at least for github
sources). The "/archive/" part between the "import path" and "%{commit}" or
"%{version}" is missing as far as I can see.

4) The downloaded tarball has potentially ambiguous names, for example one
of my golang packages (github.com/AudriusButkevicius/cli) produces a
"cli-%{shortcommit}" or "cli-%{version}.tar.gz" tarball when using
%gosource, which is why I manually changed the link to
AudriusButkevicius-cli-*.tar.gz back when I generated the .spec file with
gofed. I suggest using both project and repository names for determining
the tarball name to avoid confusion and name clashes.

5) I couldn't figure out how to correctly handle the "post-release
snapshot" case, where both "Version" and "%commit" have to be set. The
macros just generated a Release tag like for packaging a released version,
ignoring the "commit" tag completely.

6) When I finally got the macros right enough for %prep, %build, and
%install to proceed, the build failed due to missing debuginfo files (and
warnings about duplicate files) - well, it's a source-only library package,
how do I specify this with the new macros?

I hope those issues are only part of the "transitional period", because I'd
really like to clean up my go package .spec files going forward.

The contents of the .spec file at the point where I gave up trying to get
it to build successfully are available via this gist link:
https://gist.github.com/decathorpe/366daeb50e889fcd9153eedb1b761804

Fabio
Nicolas Mailhot
2018-02-27 15:03:36 UTC
Permalink
Le 2018-02-27 15:49, Fabio Valentini a écrit :

Hi Fabio,

Thanks a lot for testing, we need more input to produce great Go
packaging tooling.
Post by Fabio Valentini
I've been following the (long overdue) improvements concerning go
packaging in fedora, and since I saw that packages are starting to
make use of the new mechanisms, I wanted to finally check it out and
started "converting" one of my own (one of ~50) golang packages
(golang-github-AudriusButkevicius-cli). However, I came across a few
stumbling blocks (and at least one bug) in the current implementation
1) The currently implemented macros have different names than the ones
that were proposed at the "More Go Packaging" wiki page, which
confused me.
Yes, Jan changed quite a few macro names and semantics when merging and
rewriting macro code in go last week. Some of his changes are very good
and quite better than what I proposed, others I don't quite agree with
and I'm not sure they actually work. And clearly the result is not
tested enough.

My plan is to take all the improvements Jan made, reintegrate everything
that can be on the original proposed macro names (I don't want to
rewrite my 550+ tested Go specs more than absolutely necessary), and
make a new pass on the documentation for things that changed for the
better but require call changes in the specs.

In the meanwhile you should still have the original PR to go-compilers
in Pagure which is not what Jan merged, has some bits that will be done
better with the code Jan wrote, but in the meanwhile is actually working
and tested.

Regards,

--
Nicolas Mailhot
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send a
Robert-André Mauchin
2018-02-27 17:34:11 UTC
Permalink
Post by Nicolas Mailhot
Hi Fabio,
Thanks a lot for testing, we need more input to produce great Go
packaging tooling.
Post by Fabio Valentini
I've been following the (long overdue) improvements concerning go
packaging in fedora, and since I saw that packages are starting to
make use of the new mechanisms, I wanted to finally check it out and
started "converting" one of my own (one of ~50) golang packages
(golang-github-AudriusButkevicius-cli). However, I came across a few
stumbling blocks (and at least one bug) in the current implementation
1) The currently implemented macros have different names than the ones
that were proposed at the "More Go Packaging" wiki page, which
confused me.
Yes, Jan changed quite a few macro names and semantics when merging and
rewriting macro code in go last week. Some of his changes are very good
and quite better than what I proposed, others I don't quite agree with
and I'm not sure they actually work. And clearly the result is not
tested enough.
My plan is to take all the improvements Jan made, reintegrate everything
that can be on the original proposed macro names (I don't want to
rewrite my 550+ tested Go specs more than absolutely necessary), and
make a new pass on the documentation for things that changed for the
better but require call changes in the specs.
In the meanwhile you should still have the original PR to go-compilers
in Pagure which is not what Jan merged, has some bits that will be done
better with the code Jan wrote, but in the meanwhile is actually working
and tested.
Regards,
--
Nicolas Mailhot
How do we test this? I installedtho go-srpm-macros from Rawhide but it doesn't
seem to have the required macros?


_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to d
Nicolas Mailhot
2018-02-27 18:22:42 UTC
Permalink
Post by Robert-André Mauchin
How do we test this? I installedtho go-srpm-macros from Rawhide but it
doesn't seem to have the required macros?
Yes in rawhide go-compilers and go-srpm-macros are in an intermediary
not fully tested/integrated state.

The original PR that matched what's in the wiki and is known to work is
here
https://src.fedoraproject.org/rpms/go-compilers/pull-request/2

Just grab the files rebuild the resulting go-compilers package and
you're set to try it on your projects (in a fedora-devel buildroot)

I'll try to mix it with all the nice work Jan did to keep all the parts
where he improved the implementation without the loss of integration
polish of the go-srpm-macros and go-compilers packages he pushed to
fedora-devel. And I definitely do not want something that requires
rewriting the wiki once again :)

Regards,

--
Nicolas Mailhot
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to deve
Athos Ribeiro
2018-03-03 14:47:07 UTC
Permalink
Post by Nicolas Mailhot
Post by Robert-André Mauchin
How do we test this? I installedtho go-srpm-macros from Rawhide but it
doesn't seem to have the required macros?
Yes in rawhide go-compilers and go-srpm-macros are in an intermediary
not fully tested/integrated state.
The original PR that matched what's in the wiki and is known to work is
here
https://src.fedoraproject.org/rpms/go-compilers/pull-request/2
Just grab the files rebuild the resulting go-compilers package and
you're set to try it on your projects (in a fedora-devel buildroot)
I'll try to mix it with all the nice work Jan did to keep all the parts
where he improved the implementation without the loss of integration
polish of the go-srpm-macros and go-compilers packages he pushed to
fedora-devel. And I definitely do not want something that requires
rewriting the wiki once again :)
Are there any intentions to push the macros into f28? I really liked the
improvements in the spec file sizes, but porting too many packages now
and keep them updated in both f28 and rawhide (making the branches
completely different) would mean a lot of extra work. Or maybe I am just
too late here since we are quite close from the beta freeze.

Thanks for the hard work though :)

--
Athos Ribeiro

http://www.ime.usp.br/~athoscr
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to
Nicolas Mailhot
2018-03-04 19:20:25 UTC
Permalink
Post by Athos Ribeiro
Are there any intentions to push the macros into f28? I really liked the
improvements in the spec file sizes, but porting too many packages now
and keep them updated in both f28 and rawhide (making the branches
completely different) would mean a lot of extra work. Or maybe I am just
too late here since we are quite close from the beta freeze.
The intention is to get everything in a state everyone likes in -devel,
and then push it back to as many stable releases as possible (including
maybe EL7, EL6 really seems too old)

The nice thing about using new macro names is that is can not break any
existing spec file, unchanged specs just won't see the changes (except
maybe %gotest, we had to change it brutally because of its insane
argument structure)

The tooling work has progressed a lot those past days, it should now be
able to accommodate both Jan's workflow and mine. The remaining sticking
points are:

1. have the redhat-rpm-config maintainers push the %forge macros to
stable as they promised, now we're reasonably sure they are bug-free

2. testing testing (help appreciated)!

2. fixing (ditto)

3. defining a form of default policy (right now we have lots of flags to
exclude things in install/check/autodeps, but no real opinion on what
exclusions make sense)

4. documenting the changes in the wiki (help *very* appreciated)!

The latest code is in:
https://github.com/gofed/symbols-extractor/ (for the go code)
https://github.com/gofed/go-macros (for Jan's version of macros and
scripts) or
https://github.com/nim-nim/go-macros/tree/improve-integration (for the
changes I did and Jan didn't merge yet)

…and of course in go-compilers and go-srpm-macros whenever Jan does a
build.

I works fine in the simple tests I had time to do, without the warts and
problems reported after the initial merge. Still have some ideas on how
to improve handling of test and example code

Major changes, by memory:

1. revert to %gometa and %forgemeta like documented in the wiki, you can
forget about providerprefix

2. %goinstall now computes project files that need installation, you
don't need the gofiles=$( line anymore. Though of course you can specify
additional files to install as %goinstall arguments. Passing a file
goinstall already wants to install should be transparent without
duplicated file warnings

3. you can add files by extension in goinstall with -e

4. you can specify another import path to goinstall with -i (though that
does not change how code actually references itself so YMMV)

5. new -d -t -r flags to exclude honoured by pretty much all the macros,
read the doc in the macro files of in %{_bindir}/go-rpm-integration

6. lots of tweaks that should be mostly invisible but make things do the
right thing automatically as much as possible

7. automated md file installation and marking as %doc %gocolllectmd is
dead (in my version, not merged by Jan yet)

8. primitive detection of bundled code (but please just rm -fr vendor)

9. lots of weird user cases now work, even if I'm not sure they're all a
good idea

Anyway if someone wants to test the files, check the spec programmingAPI is convenient and sane, and update
https://fedoraproject.org/wiki/More_Go_packaging
with the changes help would be very appreciated.

We tried to keep API changes to the minimum, but there are some, and I'm
not sure I remember all of them, new eyes would be good.

Regards,

--
Nicolas Mailhot
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe
Jan Chaloupka
2018-03-06 12:44:27 UTC
Permalink
Hi Athos,

hope everything is fine and you have better things to do than spending
much time updating the Go spec files :)

Anything you need and/or anything that could help you to minimize your
packaging time, please, let us know :).
Post by Nicolas Mailhot
Post by Athos Ribeiro
Are there any intentions to push the macros into f28? I really liked the
improvements in the spec file sizes, but porting too many packages now
and keep them updated in both f28 and rawhide (making the branches
completely different) would mean a lot of extra work. Or maybe I am just
too late here since we are quite close from the beta freeze.
The intention is to get everything in a state everyone likes in -devel,
and then push it back to as many stable releases as possible (including
maybe EL7, EL6 really seems too old)
I took a liberty and pushed the new macros into f27+ yesterday.
The naming and API of each macro should be pretty stable now.
There may be slight changes in the API but that should not be fatal.
Feel free to update you packages on f27+ and let us know if there are
any difficulties :).
Post by Nicolas Mailhot
The nice thing about using new macro names is that is can not break any
existing spec file, unchanged specs just won't see the changes (except
maybe %gotest, we had to change it brutally because of its insane
argument structure)
+1
Post by Nicolas Mailhot
The tooling work has progressed a lot those past days, it should now be
able to accommodate both Jan's workflow and mine. The remaining sticking
1. have the redhat-rpm-config maintainers push the %forge macros to
stable as they promised, now we're reasonably sure they are bug-free
Once the macro.forge are available in f27+ (maybe even f26), I will be
more than happy
to dispose all the fallback code I added so the new macros work on f27+.
Post by Nicolas Mailhot
2. testing testing (help appreciated)!
Definitely. Anything you feel is not right or does not work as expected,
feel free to open an issue on https://github.com/gofed/go-macros .
Post by Nicolas Mailhot
2. fixing (ditto)
3. defining a form of default policy (right now we have lots of flags to
exclude things in install/check/autodeps, but no real opinion on what
exclusions make sense)
Agree, so far most of the Go projects I have encountered with seems
pretty default. But you never know.
The more "exotic" layouts we have, the more logic we can put into the
macros so the packaging is still user-friendly.
Post by Nicolas Mailhot
4. documenting the changes in the wiki (help *very* appreciated)!
https://github.com/gofed/symbols-extractor/ (for the go code)
https://github.com/gofed/go-macros (for Jan's version of macros and
scripts) or
https://github.com/nim-nim/go-macros/tree/improve-integration (for the
changes I did and Jan didn't merge yet)
…and of course in go-compilers and go-srpm-macros whenever Jan does a
build.
I works fine in the simple tests I had time to do, without the warts and
problems reported after the initial merge. Still have some ideas on how
to improve handling of test and example code
Let's please keep in mind we still need to do decide what we are going
to do with both wikis.
I would like to consolidate both [1] and [2] documents into a single one
so there is only
one source of truth about the Go packaging.

[1] https://fedoraproject.org/wiki/PackagingDrafts/Go
[2] https://fedoraproject.org/wiki/More_Go_packaging
Post by Nicolas Mailhot
1. revert to %gometa and %forgemeta like documented in the wiki, you can
forget about providerprefix
2. %goinstall now computes project files that need installation, you
don't need the gofiles=$( line anymore. Though of course you can specify
additional files to install as %goinstall arguments. Passing a file
goinstall already wants to install should be transparent without
duplicated file warnings
3. you can add files by extension in goinstall with -e
4. you can specify another import path to goinstall with -i (though that
does not change how code actually references itself so YMMV)
5. new -d -t -r flags to exclude honoured by pretty much all the macros,
read the doc in the macro files of in %{_bindir}/go-rpm-integration
6. lots of tweaks that should be mostly invisible but make things do the
right thing automatically as much as possible
7. automated md file installation and marking as %doc %gocolllectmd is
dead (in my version, not merged by Jan yet)
8. primitive detection of bundled code (but please just rm -fr vendor)
9. lots of weird user cases now work, even if I'm not sure they're all a
good idea
Anyway if someone wants to test the files, check the spec programmingAPI is convenient and sane, and update
https://fedoraproject.org/wiki/More_Go_packaging
with the changes help would be very appreciated.
We tried to keep API changes to the minimum, but there are some, and I'm
not sure I remember all of them, new eyes would be good.
Regards,
Cheers
Jan
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedorap
Jan Chaloupka
2018-03-06 12:30:10 UTC
Permalink
Post by Nicolas Mailhot
Post by Robert-André Mauchin
How do we test this? I installedtho go-srpm-macros from Rawhide but it
doesn't seem to have the required macros?
Yes in rawhide go-compilers and go-srpm-macros are in an intermediary
not fully tested/integrated state.
The original PR that matched what's in the wiki and is known to work is
here
https://src.fedoraproject.org/rpms/go-compilers/pull-request/2
Just grab the files rebuild the resulting go-compilers package and
you're set to try it on your projects (in a fedora-devel buildroot)
I'll try to mix it with all the nice work Jan did to keep all the parts
where he improved the implementation without the loss of integration
polish of the go-srpm-macros and go-compilers packages he pushed to
fedora-devel. And I definitely do not want something that requires
rewriting the wiki once again :)
Regards,
The latest go-srpm-macros and go-compilers ship the latest version of
the new macros. Please, let us now if it still does not work for you :).
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedorap
Nicolas Mailhot
2018-02-27 16:21:41 UTC
Permalink
Post by Fabio Valentini
Hi
I'll answer in more detail since I have a little more time now
Post by Fabio Valentini
2) Additionally, I wasn't able to figure out why I have to set both
"%gobaseipath" and "%provider_prefix".
That's one of the changes Jan made I don't understand either. It's looks
like an attempt to reintroduce old Go packaging conventions, but as they
overlap with the new ones (but are not sufficient to replace them), no
good can come out of it.
Post by Fabio Valentini
3) The %gosource macro doesn't work correctly (at least for github
sources). The "/archive/" part between the "import path" and
"%{commit}" or "%{version}" is missing as far as I can see.
The original code is in redhat-rpm-config in devel only, Jan tried to
rewrite it so it works on stable too, and the result is what you saw. I
think the simplest solution is just to revert this part of the rewrite
and ask the redhat-rpm-config maintainers to push the original working
code to stable redhat-rpm-config (they've already indicated they will
push it to stable as soon as we give them the green light, so the whole
rewrite thing to avoid doing what was already planed is a
misunderstanding)
Post by Fabio Valentini
4) The downloaded tarball has potentially ambiguous names, for example
one of my golang packages (github.com/AudriusButkevicius/cli [1])
produces a "cli-%{shortcommit}" or "cli-%{version}.tar.gz" tarball
when using %gosource, which is why I manually changed the link to
AudriusButkevicius-cli-*.tar.gz back when I generated the .spec file
with gofed.
But you can't do that. The URL in the spec file is supposed to be
auditable. Cut and pasting the url in any download tool should download
the expected archive with the expected filename without any manual
fixing. Changing the archive name in the end of a github URL still
produces the file name you do not like in Firefox for example, so you
have to live with this filename.

It is unfortunate that the archive naming conventions chosen by github
and most of its competitors are so ambiguous, but we can not change them
at Fedora level. It makes setting
%_sourcedir %{_topdir}/SOURCES/%{name}

in .rpmmacros almost mandatory when working with such hosting services.
Post by Fabio Valentini
5) I couldn't figure out how to correctly handle the "post-release
snapshot" case, where both "Version" and "%commit" have to be set. The
macros just generated a Release tag like for packaging a released
version, ignoring the "commit" tag completely.
That's one of the rewrite simplifications that does not work out in
practice.
Post by Fabio Valentini
6) When I finally got the macros right enough for %prep, %build, and
%install to proceed, the build failed due to missing debuginfo files
This part is simple, just do not include a %build section if you're not
building anything.
Post by Fabio Valentini
(and warnings about duplicate files)
This looks like a rewrite bug, I never had this with the original code I
submitted :(
Post by Fabio Valentini
The contents of the .spec file at the point where I gave up trying to
https://gist.github.com/decathorpe/366daeb50e889fcd9153eedb1b761804
Thank you for trying I hope we can make all this better soon.

I'll notify the list as soon as I've assembled a new PR that integrates
my original code with the improvements Jan wrote in something that works
for me, please retest it then and report if it works for you. Unless the
redhat-rpm-config bit can move quickly it will probably require testing
converted packages in a fedora-devel buildroot, I hope that's ok with
you

Regards,

--
Nicolas Mailhot
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-leav
Jan Chaloupka
2018-03-06 12:23:39 UTC
Permalink
Hi Fabio,

thank you for staying with us in the Go packaging world and for sharing
any difficulty or problem you encounter with.
I created github repository [1] where you can report all issues wrt.
macros used in Go packaging.
We are currently in a process of iterating over all the macros. Though,
I am finally confident we are going in the right direction.
Providing set of macros we can share with goal to simplify and minimize
package maintenance.
I did not want to make the new macros publicly aware until me and
Nicolas are sure they work in both our environments.
Yet, it's great to see they are already getting accepted.

[1] https://github.com/gofed/go-macros

Let me answer all question as best as I can as well.
Post by Nicolas Mailhot
Post by Fabio Valentini
Hi
I'll answer in more detail since I have a little more time now
Post by Fabio Valentini
2) Additionally, I wasn't able to figure out why I have to set both
"%gobaseipath" and "%provider_prefix".
That's one of the changes Jan made I don't understand either. It's
looks like an attempt to reintroduce old Go packaging conventions, but
as they overlap with the new ones (but are not sufficient to replace
them), no good can come out of it.
The %provider_prefix and %gobaseipath are already gone.
For the %provider_prefix I needed to get more familiar with the forge
macros Nicolas introduced so I can decide if it is sufficient
replacement. And it is.
The %gobaseipath macro had the same meaning as %goipath. I wanted to
stress it must contain the base import path so packagers do not
accidentally set it to invalid value.
I still believe we should stress that information. However, it can be
mentioned in the documentation. If not explicitly stressed in the macro
names it can be later checked by a Go specific spec linter.
Post by Nicolas Mailhot
Post by Fabio Valentini
3) The %gosource macro doesn't work correctly (at least for github
sources). The "/archive/" part between the "import path" and
"%{commit}" or "%{version}" is missing as far as I can see.
The original code is in redhat-rpm-config in devel only, Jan tried to
rewrite it so it works on stable too, and the result is what you saw.
I think the simplest solution is just to revert this part of the
rewrite and ask the redhat-rpm-config maintainers to push the original
working code to stable redhat-rpm-config (they've already indicated
they will push it to stable as soon as we give them the green light,
so the whole rewrite thing to avoid doing what was already planed is a
misunderstanding)
Thanks Nicolas for providing the forge macros. We no longer have to deal
with the gosource (and other macros) manipulation in the context of the
Go packaging. The project repository sources processing has been moved
under general solution. If anything goes wrong with the forged macros,
please open a bz bug for redhat-rpm-config component (CC'ing Nicolas as
well).
Post by Nicolas Mailhot
Post by Fabio Valentini
4) The downloaded tarball has potentially ambiguous names, for example
one of my golang packages (github.com/AudriusButkevicius/cli [1])
produces a "cli-%{shortcommit}" or "cli-%{version}.tar.gz" tarball
when using %gosource, which is why I manually changed the link to
AudriusButkevicius-cli-*.tar.gz back when I generated the .spec file
with gofed.
But you can't do that. The URL in the spec file is supposed to be
auditable. Cut and pasting the url in any download tool should
download the expected archive with the expected filename without any
manual fixing. Changing the archive name in the end of a github URL
still produces the file name you do not like in Firefox for example,
so you have to live with this filename.
It is unfortunate that the archive naming conventions chosen by github
and most of its competitors are so ambiguous, but we can not change
them at Fedora level. It makes setting
%_sourcedir %{_topdir}/SOURCES/%{name}
in .rpmmacros almost mandatory when working with such hosting services.
Post by Fabio Valentini
5) I couldn't figure out how to correctly handle the "post-release
snapshot" case, where both "Version" and "%commit" have to be set. The
macros just generated a Release tag like for packaging a released
version, ignoring the "commit" tag completely.
That's one of the rewrite simplifications that does not work out in
practice.
Post by Fabio Valentini
6) When I finally got the macros right enough for %prep, %build, and
%install to proceed, the build failed due to missing debuginfo files
This part is simple, just do not include a %build section if you're
not building anything.
Thanks Igor (ignatenko) for pointing this out :). If the %build section
is specified the rpm tries to create debuginfo rpm. Which it fails to do
so as pure devel rpm does not ship any binary.
Post by Nicolas Mailhot
Post by Fabio Valentini
(and warnings about duplicate files)
This looks like a rewrite bug, I never had this with the original code
I submitted :(
Post by Fabio Valentini
The contents of the .spec file at the point where I gave up trying to
https://gist.github.com/decathorpe/366daeb50e889fcd9153eedb1b761804
Thank you for trying I hope we can make all this better soon.
I'll notify the list as soon as I've assembled a new PR that
integrates my original code with the improvements Jan wrote in
something that works for me, please retest it then and report if it
works for you. Unless the redhat-rpm-config bit can move quickly it
will probably require testing converted packages in a fedora-devel
buildroot, I hope that's ok with you
Both go-srpm-macros and go-compilers can be updated pretty quickly,
providing fixes and improvements in 30 minutes if needed. Please, open
an issue on https://github.com/gofed/go-macros for each defect. Even if
it is just a documentation issue.
Post by Nicolas Mailhot
Regards,
Cheers
Jan
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email
Robert-André Mauchin
2018-02-27 18:39:47 UTC
Permalink
Post by Fabio Valentini
Hi everybody,
I've been following the (long overdue) improvements concerning go packaging
in fedora, and since I saw that packages are starting to make use of the
new mechanisms, I wanted to finally check it out and started "converting"
one of my own (one of ~50) golang packages
(golang-github-AudriusButkevicius-cli). However, I came across a few
stumbling blocks (and at least one bug) in the current implementation
1) The currently implemented macros have different names than the ones that
were proposed at the "More Go Packaging" wiki page, which confused me. I
had to look at a recently "converted" package to figure out the correct
macro names. I guess the documentation just hasn't caught up yet here.
2) Additionally, I wasn't able to figure out why I have to set both
"%gobaseipath" and "%provider_prefix".
Yes this is redondant. I was prefering to use %forgeurl if necessary.
Post by Fabio Valentini
3) The %gosource macro doesn't work correctly (at least for github
sources). The "/archive/" part between the "import path" and "%{commit}" or
"%{version}" is missing as far as I can see.
I sent a PR for this.
Post by Fabio Valentini
5) I couldn't figure out how to correctly handle the "post-release
snapshot" case, where both "Version" and "%commit" have to be set. The
macros just generated a Release tag like for packaging a released version,
ignoring the "commit" tag completely.
6) When I finally got the macros right enough for %prep, %build, and
%install to proceed, the build failed due to missing debuginfo files (and
warnings about duplicate files) - well, it's a source-only library package,
how do I specify this with the new macros?
I have the same problem, looking at the log it seems every command is run twice? Thus it lists the files twice.

Also the file list is containing folders than should't be there:

%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748/_build"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748/_build/src"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748/_build/src/bazil.org"

These seems to be remnant from the build process and shouldn't be included.



_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe se
Robert-André Mauchin
2018-02-27 20:29:57 UTC
Permalink
Post by Robert-André Mauchin
Post by Fabio Valentini
6) When I finally got the macros right enough for %prep, %build, and
%install to proceed, the build failed due to missing debuginfo files (and
warnings about duplicate files) - well, it's a source-only library package,
how do I specify this with the new macros?
I have the same problem, looking at the log it seems every command is run
twice? Thus it lists the files twice.
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD"
%%dir
"//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa
8987b715bdd21d6adc4c9b20155f748" %%dir
"//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa
8987b715bdd21d6adc4c9b20155f748/_build" %%dir
"//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa
8987b715bdd21d6adc4c9b20155f748/_build/src" %%dir
"//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa
8987b715bdd21d6adc4c9b20155f748/_build/src/bazil.org"
These seems to be remnant from the build process and shouldn't be included.
I think I've found the bug and filed a PR for it:
https://github.com/gofed/go-macros/pull/4

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedorapr
Jan Chaloupka
2018-03-06 11:47:40 UTC
Permalink
Hi Robert-André,

thank you for your patience and all comments pointing out pieces that
are not working as expected.
Introduction of new macros is a time-consuming process and it requires
resilience so we keep up till the state
where the macros are generally usable for a lot of our use cases. Making
the packaging experience as easy as possible at the same time.
Post by Robert-André Mauchin
Post by Fabio Valentini
Hi everybody,
I've been following the (long overdue) improvements concerning go packaging
in fedora, and since I saw that packages are starting to make use of the
new mechanisms, I wanted to finally check it out and started "converting"
one of my own (one of ~50) golang packages
(golang-github-AudriusButkevicius-cli). However, I came across a few
stumbling blocks (and at least one bug) in the current implementation
1) The currently implemented macros have different names than the ones that
were proposed at the "More Go Packaging" wiki page, which confused me. I
had to look at a recently "converted" package to figure out the correct
macro names. I guess the documentation just hasn't caught up yet here.
The "More Go Packaging" wiki page is in most parts very well written
piece of document.
Touching very important topics and suggesting improvements that makes
maintenance easier.
Unfortunately, it was published before the new macros were merged into
Fedora.
Though, it is important to be proactive so my thanks to Nicolas for
sharing his experience in the area.

And yes, the macros are not the same as mentioned in the document. It
took us some time to agree
on common ground and way the macro should be implemented and provided.
We have not finished
the discussion but I am happy we managed to converge to the current
state we can agree on.
Meantime, I started publishing at least some of the macros so they can
be incrementally tested.
Post by Robert-André Mauchin
Post by Fabio Valentini
2) Additionally, I wasn't able to figure out why I have to set both
"%gobaseipath" and "%provider_prefix".
Yes this is redondant. I was prefering to use %forgeurl if necessary.
By the time I joined the Go packaging effort (~3.5y ago) I introduced
two macros that goes hand in hand:
- %provider_prefix for repository providing tarball with source code
- %import_path storing import path prefix the source code tarball provides
I have build a tooling that scans Go packages in the distribution and
understands the macros.

By the time Nicolas introduced his forgeurl macro, I was not fully aware
of its meaning so I kept the original one.
After learning provider_prefix is equivalent to forgeurl, I switched to
it as the new forgemeta proved to simplify
the spec file meta data specification (including manipulation with
Release tag).

In most cases the change is compatible with my tooling. However, there
are some drawbacks
I will have to iterate on so the tooling is operational again. Though,
it should not affect any spec file
up to defining some additional macros if a packager wishes to include
the spec file for automatic distribution-scoped analysis.
Post by Robert-André Mauchin
Post by Fabio Valentini
3) The %gosource macro doesn't work correctly (at least for github
sources). The "/archive/" part between the "import path" and "%{commit}" or
"%{version}" is missing as far as I can see.
I sent a PR for this.
Post by Fabio Valentini
5) I couldn't figure out how to correctly handle the "post-release
snapshot" case, where both "Version" and "%commit" have to be set. The
macros just generated a Release tag like for packaging a released version,
ignoring the "commit" tag completely.
6) When I finally got the macros right enough for %prep, %build, and
%install to proceed, the build failed due to missing debuginfo files (and
warnings about duplicate files) - well, it's a source-only library package,
how do I specify this with the new macros?
I have the same problem, looking at the log it seems every command is run twice? Thus it lists the files twice.
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748/_build"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748/_build/src"
%%dir "//usr/share/gocode/src/bazil.org/fuse//builddir/build/BUILD/fuse-371fbbdaa8987b715bdd21d6adc4c9b20155f748/_build/src/bazil.org"
These seems to be remnant from the build process and shouldn't be included.
_______________________________________________
Regards
Jan
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe
Robert-André Mauchin
2018-03-07 14:50:29 UTC
Permalink
Post by Jan Chaloupka
Hi Robert-André,
thank you for your patience and all comments pointing out pieces that
are not working as expected.
Introduction of new macros is a time-consuming process and it requires
resilience so we keep up till the state
where the macros are generally usable for a lot of our use cases. Making
the packaging experience as easy as possible at the same time.
Can we already use the new guidelines in "production"? Should I recommed their
use in the Golang Package Review? Or should we still wait for you to adjust
the finer details?
Also will this be available for EPEL7 too?

Best regards,

Robert-André


_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-
Jan Chaloupka
2018-03-07 15:02:30 UTC
Permalink
Post by Robert-André Mauchin
Post by Jan Chaloupka
Hi Robert-André,
thank you for your patience and all comments pointing out pieces that
are not working as expected.
Introduction of new macros is a time-consuming process and it requires
resilience so we keep up till the state
where the macros are generally usable for a lot of our use cases. Making
the packaging experience as easy as possible at the same time.
Can we already use the new guidelines in "production"? Should I recommed their
use in the Golang Package Review? Or should we still wait for you to adjust
the finer details?
Go for it :) We still can not guarantee the macros will not change their
API but the macro names and their flags are solid.
We could introduce more flags if needed. However, most of the changes
are in macro implementation only.
In case there is macro incompatible change we will let you know.

Nicolas, can you more elaborate on that? I don't see any more reason why
we should block folks from relying on the new macros.
Post by Robert-André Mauchin
Also will this be available for EPEL7 too?
I hope they will be. Thought, it will be not so trivial cause RHEL has
different policies. It will take some time.
Post by Robert-André Mauchin
Best regards,
Robert-André
_______________________________________________
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an e
Jan Chaloupka
2018-03-07 15:07:34 UTC
Permalink
Post by Jan Chaloupka
Post by Robert-André Mauchin
Post by Jan Chaloupka
Hi Robert-André,
thank you for your patience and all comments pointing out pieces that
are not working as expected.
Introduction of new macros is a time-consuming process and it requires
resilience so we keep up till the state
where the macros are generally usable for a lot of our use cases. Making
the packaging experience as easy as possible at the same time.
Can we already use the new guidelines in "production"? Should I recommed their
use in the Golang Package Review? Or should we still wait for you to adjust
the finer details?
Go for it :) We still can not guarantee the macros will not change
their API but the macro names and their flags are solid.
We could introduce more flags if needed. However, most of the changes
are in macro implementation only.
In case there is macro incompatible change we will let you know.
Saying that, I will prepare new builds of gofed so the new spec files
are generated with the new macros.
Post by Jan Chaloupka
Nicolas, can you more elaborate on that? I don't see any more reason
why we should block folks from relying on the new macros.
Post by Robert-André Mauchin
Also will this be available for EPEL7 too?
I hope they will be. Thought, it will be not so trivial cause RHEL has
different policies. It will take some time.
Post by Robert-André Mauchin
Best regards,
Robert-André
_______________________________________________
_______________________________________________
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe se
Jan Chaloupka
2018-03-08 15:37:57 UTC
Permalink
Post by Jan Chaloupka
Post by Jan Chaloupka
Post by Robert-André Mauchin
Post by Jan Chaloupka
Hi Robert-André,
thank you for your patience and all comments pointing out pieces that
are not working as expected.
Introduction of new macros is a time-consuming process and it requires
resilience so we keep up till the state
where the macros are generally usable for a lot of our use cases. Making
the packaging experience as easy as possible at the same time.
Can we already use the new guidelines in "production"? Should I recommed their
use in the Golang Package Review? Or should we still wait for you to adjust
the finer details?
Go for it :) We still can not guarantee the macros will not change
their API but the macro names and their flags are solid.
We could introduce more flags if needed. However, most of the changes
are in macro implementation only.
In case there is macro incompatible change we will let you know.
Saying that, I will prepare new builds of gofed so the new spec files
are generated with the new macros.
F27 gofed build:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-52f059bf00
F28 gofed build:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-13edd2e62f
Post by Jan Chaloupka
Post by Jan Chaloupka
Nicolas, can you more elaborate on that? I don't see any more reason
why we should block folks from relying on the new macros.
Post by Robert-André Mauchin
Also will this be available for EPEL7 too?
I hope they will be. Thought, it will be not so trivial cause RHEL
has different policies. It will take some time.
Post by Robert-André Mauchin
Best regards,
Robert-André
_______________________________________________
_______________________________________________
_______________________________________________
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send
Robert-André Mauchin
2018-03-08 18:57:59 UTC
Permalink
Post by Jan Chaloupka
Post by Jan Chaloupka
Saying that, I will prepare new builds of gofed so the new spec files
are generated with the new macros.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-52f059bf00
https://bodhi.fedoraproject.org/updates/FEDORA-2018-13edd2e62f
Can I suggest a few thing?

- Add a switch to disable the tests like before. I use bcond_without:

# Run tests in check section
%bcond_without check

%if %{with check}
BuildRequires: golang(github.com/stretchr/testify/assert)
BuildRequires: golang(github.com/bmizerany/assert)
%endif

%if %{with check}
%check
%gochecks
%endif

- Try to grab the packager name from Git like they do in rust2rpm:

def detect_packager():
rpmdev_packager = shutil.which("rpmdev-packager")
if rpmdev_packager is not None:
return subprocess.check_output(rpmdev_packager,
universal_newlines=True).strip()

git = shutil.which("git")
if git is not None:
name = subprocess.check_output([git, "config", "user.name"],
universal_newlines=True).strip()
email = subprocess.check_output([git, "config", "user.email"],
universal_newlines=True).strip()
return "{} <{}>".format(name, email)

return None

- why does it needs sudo to run sometimes?

- This is not needed anymore, even on EPEL7:

#define license tag if not already defined
%{!?_licensedir:%global license %doc}

- would it be possible to check the dependencies on https://
src.fedoraproject.org/ instead of pkgdb which is outdated.

- would it be possible to detect if a repo has a tagged release and use it
instead of a commit if it's detected

Best regards,

Robert-André

_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-***@lists.fedoraproj

Nicolas Mailhot
2018-03-07 15:35:08 UTC
Permalink
Le mercredi 07 mars 2018 à 16:02 +0100, Jan Chaloupka a écrit :

Hi,
Post by Jan Chaloupka
Nicolas, can you more elaborate on that? I don't see any more reason
why we should block folks from relying on the new macros.
IMHO they're solid enough to be used in production both for binary
packages and -devel packages (modulo the fixes which are in the PRs I
sent you).

The remaining work is to decide whether to do unit test packages and
example packages (of if yes, how), or just ignore the mess they are, by
making unit tests not participate in requires or just plain not
installing them, and pushing examples to doc.
Post by Jan Chaloupka
Post by Robert-André Mauchin
Also will this be available for EPEL7 too?
I hope they will be. Thought, it will be not so trivial cause RHEL
has different policies. It will take some time.
I doubt anyone will want them in EL before they prove themselves in
Fedora (I'm using them in EL7, but not publicly). So probably at least a
few months, or even a full Fedora release, before attempting to push
them to EL would be wise.

EL+1 is something else as the .0 release is not expected to be as rock
solid as the follow-ups.

Regards,

--
Nicolas Mailhot
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to devel-le
Nicolas Mailhot
2018-03-07 15:38:31 UTC
Permalink
Post by Nicolas Mailhot
Hi,
Post by Jan Chaloupka
Nicolas, can you more elaborate on that? I don't see any more reason
why we should block folks from relying on the new macros.
IMHO they're solid enough to be used in production both for binary
packages and -devel packages (modulo the fixes which are in the PRs I
sent you).
The remaining work
(also to clean up the way golist is assembled and built, but that need
not change the way other packages use it)


--
Nicolas Mailhot
_______________________________________________
devel mailing list -- ***@lists.fedoraproject.org
To unsubscribe send a
Continue reading on narkive:
Loading...