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. 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

Le mardi 27 février 2018 à 18:34 +0100, Robert-André Mauchin a écrit : 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

Le samedi 03 mars 2018 à 11:47 -0300, Athos Ribeiro a écrit : 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

On 02/27/2018 07:22 PM, Nicolas Mailhot wrote: 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 :).

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. On 02/27/2018 05:21 PM, Nicolas Mailhot wrote: 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. 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). 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. 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. Cheers Jan

On mardi 27 février 2018 19:39:47 CET you wrote: I think I've found the bug and filed a PR for it: https://github.com/gofed/go-macros/pull/4

On mardi 6 mars 2018 12:47:40 CET Jan Chaloupka wrote: 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é

On 03/07/2018 04:02 PM, Jan Chaloupka wrote: Saying that, I will prepare new builds of gofed so the new spec files are generated with the new macros.

On jeudi 8 mars 2018 16:37:57 CET Jan Chaloupka wrote: 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é

Le mercredi 07 mars 2018 à 16:35 +0100, Nicolas Mailhot a écrit : (also to clean up the way golist is assembled and built, but that need not change the way other packages use it) -- Nicolas Mailhot