Created attachment 211247 [details] bump to 1.6.7 Version bump to 1.6.7 I want to use the clouddns plugin which was added in 1.6.3
It's unfetchable: > => Attempting to fetch https://codeload.github.com/Azure/go-autorest/tar.gz/v0.1.0?dummy=/Azure-go-autorest-v0.1.0_GH0.tar.gz > fetch: https://codeload.github.com/Azure/go-autorest/tar.gz/v0.1.0?dummy=/Azure-go-autorest-v0.1.0_GH0.tar.gz: Not Found > => Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/Azure-go-autorest-v0.1.0_GH0.tar.gz > fetch: http://distcache.FreeBSD.org/ports-distfiles/Azure-go-autorest-v0.1.0_GH0.tar.gz: Not Found > => Couldn't fetch it - please try to retrieve this
ok weird... I built it on my machine before opening the bug and successfully built and installed the modified version. I will double check
(In reply to freebsd from comment #2) Don't worry, I've got this resolved.
PORTREVISION Is not needed.
(In reply to Yuri Victorovich from comment #3) ah okay. What was the issue? Have I added the dependencies wrong? It's just my second submitted bug/patch.
Build fails: import cycle not allowed > ===> Building coredns from github.com/coredns/coredns > import cycle not allowed > package github.com/coredns/coredns > imports github.com/coredns/coredns/core/plugin > imports github.com/coredns/coredns/plugin/clouddns > imports google.golang.org/api/dns/v1 > imports google.golang.org/api/internal/gensupport > imports github.com/googleapis/gax-go/v2 > imports github.com/googleapis/gax-go/v2
Created attachment 211252 [details] patch The attached patch fails in poudriere with "import cycle not allowed".
(In reply to Yuri Victorovich from comment #7) ok, hold on. I will double check to be sure it works. Not entirely sure why I could do "make" and "make install" but you can't even compile. Maybe my working copy was not clean or so.... I'm quite new to this process.
(In reply to Walter Schwarzenfeld from comment #4) Not at all or just not in this case?
Please build in poudriere, it fails there. We can't commit it w/out it building in poudriere.
(In reply to freebsd from comment #9) https://docs.freebsd.org/doc/4.5-RELEASE/usr/share/doc/en/books/porters-handbook/x387.html Examples of when PORTREVISION should be bumped: Addition of patches to correct security vulnerabilities, bugs, or to add new functionality to the FreeBSD port. Changes to the port makefile to enable or disable compile-time options in the package. Changes in the packing list or the install-time behaviour of the package (e.g. change to a script which generates initial data for the package, like ssh host keys). Version bump of a port's shared library dependency (in this case, someone trying to install the old package after installing a newer version of the dependency will fail since it will look for the old libfoo.x instead of libfoo.(x+1)). Silent changes to the port distfile which have significant functional differences, i.e. changes to the distfile requiring a correction to distinfo with no corresponding change to PORTVERSION, where a diff -ru of the old and new versions shows non-trivial changes to the code.
go.mk bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243780
(In reply to Yuri Victorovich from comment #3) How have you resolved this issue? I followed this to create my patch: https://www.freebsd.org/doc/en/books/porters-handbook/book.html#using-go 1. make makesum 2. edit Makefile 3. make gomod-vendor 4. copy the GH_TUPLE output from 3 to Makefile and replace old GH_TUPLE 5. make makesum On 4 I get this error/warning: # Mirrors for the following packages are not currently known, please look them up and handle these tuples manually: # ::a14579fbfb1a:group_name/vendor/go.etcd.io/etcd Which I don't fully understand. According to the changelog "go.etcd.io" was added in 1.12 to modules2tuple and 1.14 is being used. On 5 I also get the "can't fetch" error where I'm not sure why. How have you fixed it?
(In reply to freebsd from comment #13) I resolved only the GH_TUPLE part (it produced duplicate lines). The cyclic dependency is up to maintainers of go.mk.
(In reply to Yuri Victorovich from comment #14) You can build the package so you can use it locally. But it can't be committed until the poudriere build passes. It's pending go.mk fix or some other kind of resolution.
(In reply to Yuri Victorovich from comment #15) Yea, I just try to understand the process and issue fully. That for the next time I might be able to handle this myself. The GH_TUPLE in my patch contained all these lines: Azure:go-autorest:v0.2.0:azure_go_autorest_1/vendor/github.com/Azure/go-autorest/autorest/date \ Azure:go-autorest:v0.2.0:azure_go_autorest_2/vendor/github.com/Azure/go-autorest/autorest/to \ Azure:go-autorest:v0.3.1:azure_go_autorest_3/vendor/github.com/Azure/go-autorest/autorest/azure/cli \ Azure:go-autorest:v0.4.2:azure_go_autorest_4/vendor/github.com/Azure/go-autorest/autorest/azure/auth \ Azure:go-autorest:v0.5.0:azure_go_autorest_5/vendor/github.com/Azure/go-autorest/tracing \ Azure:go-autorest:v0.8.1:azure_go_autorest_6/vendor/github.com/Azure/go-autorest/autorest/adal \ Azure:go-autorest:v0.9.4:azure_go_autorest_7/vendor/github.com/Azure/go-autorest/autorest \ which I think are the duplicates you mean. When I deleted all those and added "Azure:go-autorest:v13.0.0:azure_go_autorest/vendor/github.com/Azure/go-autorest \" (from the old Makefile) at least the "cant't fetch" error is gone. But is this an issue with "modules2tuple" then? Shouldn't it print valid output?
(In reply to freebsd from comment #16) > But is this an issue with "modules2tuple" then? Shouldn't it print valid output? Yes, but this is some sort of gray area where "modules2tuple" fails. I've discussed this or a similar issue with the "modules2tuple" author and he said this. So every once in a while its output needs to be corrected.
(In reply to Yuri Victorovich from comment #17) ah okay. Thanks for clarification :) So my procedure was correct in general but unfortunately I ran into 1.5 bugs of other systems?
(In reply to freebsd from comment #18) > So my procedure was correct in general but unfortunately I ran into 1.5 bugs of other systems? Exactly!
Committed with changes, thanks!
A commit references this bug: Author: yuri Date: Sun Feb 2 00:30:43 UTC 2020 New revision: 524795 URL: https://svnweb.freebsd.org/changeset/ports/524795 Log: dns/coredns: Update 1.6.2 -> 1.6.7 PR: 243776 Submitted by: freebsd@rainbowfab.org (original version) Changes: head/dns/coredns/Makefile head/dns/coredns/distinfo