Jérémy Lal <kapouer-QATUhw8NPUbYtjvyW6yDsg@public.gmane.org> writes:
> Hi,
>
> some remarks below:
Thank you! I'm following up one two items that are resolved below. I'm
still working to resolve the other dependencies, and I will followup on
those separately when I have something to add to discussion.
>> GITHUB.COM/SASSOFTWARE/RELIC
>>
>> Packaging is here:
>> https://salsa.debian.org/go-team/packages/relic
>>
>> Latest build output:
>> https://salsa.debian.org/jas/relic/-/jobs/5162602
>>
>> Fails like this:
>>
>> # github.com/sassoftware/relic/cmdline/remotecmd
>> src/github.com/sassoftware/relic/cmdline/remotecmd/azure.go:65:20: cannot
>> use &dvCache{…} (value of type *dvCache) as cache.ExportReplace value in
>> argument to public.WithCache: *dvCache does not implement
>> cache.ExportReplace (wrong type for method Export)
>> have Export(cache.Marshaler, string)
>> want Export(context.Context, cache.Marshaler,
>> cache.ExportHints) error
>> src/github.com/sassoftware/relic/cmdline/remotecmd/azure.go:79:12: not
>> enough arguments in call to s.cli.Accounts
>> have ()
>> want (context.Context)
>> src/github.com/sassoftware/relic/cmdline/remotecmd/azure.go:79:12:
>> assignment mismatch: 1 variable but s.cli.Accounts returns 2 values
>>
>> The reason seems to be that our
>> golang-github-azuread-microsoft-authentication-library-for-go-dev is too
>> new. Should we package an older version?
>
>
>> I have opened an upstream bug about this requesting them to use a newer
>> dependency:
>>
>> https://github.com/sassoftware/relic/issues/39
>>
>> Looking at the API changes, I think this could be patched easily by
>> somehow who knows Go. Is that the right approach? Patches welcome.
>>
>
> It's not so straightforward because azure bumped its API and did breaking
> changes.
> I had the same problem in python recently.
Fortunately, I realized that rekor needs very little from relic. I have
now uploaded relic to NEW containing only a quite stripped down relic
library:
https://salsa.debian.org/go-team/packages/relic/-/commit/00e505565d5bfc8903b6a056979abe2982befcdc
Relic looks useful on its own, so I hope to revisit the package (or
someone else could work on it) but fortunately it seems we can get relic
into a usable state for rekor.
Relic had several dependencies that I packaged which may now not be
needed after all. I won't do source-only uploads until I've confirmed
that dependencies are needed by rekor, and will open RC bugs on any
packages that remains too. Some of the packages I added looks useful on
their own, though, but if nobody else cares about them, and rekor
doesn't need them, let's keep them out of trixie.
>> SIGS.K8S.IO/RELEASE-UTILS
>>
>> Packaging is here:
>> https://salsa.debian.org/go-team/packages/golang-k8s-sigs-release-utils
>>
>> Latest build output:
>> https://salsa.debian.org/jas/golang-k8s-sigs-release-utils/-/jobs/5162686
>>
>> There is discussion about this one here:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060840
>>
>> Can we avoid this dependency by patch rekor? That would be nice since
>> it seems like a problematic package. It needs
>> github.com/uwu-tools/magex and github.com/common-nighthawk/go-figure
>> that are not packaged.
>>
>
> Yes, you should be able to get rid of it.
> This is an example of how to inject the version, it might work well with
> DEB_UPSTREAM_VERSION
> https://github.com/ansible/receptor/blob/6494b00a36df0a8b4fdf895a962a985d03d33f76/Makefile#L50
I discovered that rekor use sigs.k8s.io/release-utils quite for its
"rekor-cli version" ASCII art output:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060840#30
However after excluding the mage stuff, the package built easily and is
now in unstable in good shape:
https://tracker.debian.org/pkg/golang-k8s-sigs-release-utils
/Simon
Attachment:
signature.asc
Description: PGP signature