Re: Packaging Proton Bridge: cryptic compilation failure

[Marek Paśnikowski]

On czwartek, 5 grudnia 2024 17:37:05 CET you wrote:
> Le samedi 30 novembre 2024 à 8:22 PM, Ian Eure <ian@retrospec.tv> a écrit :
> > Hi Marek,
> > 
> > On Sat, Nov 30, 2024, at 6:56 PM, Marek Paśnikowski wrote:
> > > On sobota, 30 listopada 2024 19:08:49 CET Cayetano Santos wrote:
> > > > > sam. 30 nov. 2024 at 17:26, Marek Paśnikowski
> > > > > marek@marekpasnikowski.pl
> > > > > wrote:
> > > > > Hello Guix
> > > > > 
> > > > > 
> > > > > I am towards the end of a first pass of packaging the Proton Bridge
> > > > > program to access my Proton Mail with KMail.
> > > > > 
> > > > > 
> > > > > I have worked through and learned about many peculiarities of Golang
> > > > > build
> > > > > system. As long as I had an error message, I was able to at least
> > > > > work
> > > > > around problems. However, the latest build failure is completely
> > > > > cryptic
> > > > > to me, as its log contains zero error messages. It works fine until
> > > > > I
> > > > > get a "build
> > > > > failed" summary:
> > > > > The debug for dummies manual advices using the "--keep-failed" flag
> > > > > when
> > > > > you build packages. Using a shell container helps to understand this
> > > > > kind
> > > > > of cryptic messages too.
> > > > 
> > > > --
> > > > Cayetano Santos
> > > 
> > > Thank you Ian, Cayetano for swiftly reminding me to Read The Manual. I
> > > was so tired with constant tweaking of package after package, that I
> > > forgot to go to the basics.
> > > 
> > > 
> > > I learned that I can source variables to emulate the build environment,
> > > in
> > > which I issued the same command that go build system uses to build the
> > > package. Here is the result, much cleaner with the interesting stuff
> > > right at the end:
> > > 
> > > 
> > > [...]
> > > # github.com/ProtonMail/go-crypto/openpgp/packet
> > > /tmp/guix-build-go-github-com-protonmail-go-proton-api-0.4.0.drv-0/src/
> > > github.com/ProtonMail/go-crypto/openpgp/packet/packet_sequence.go:12:92:
> > > undefined: errors.ErrMalformedMessage
> > > /tmp/guix-build-go-github-com-protonmail-go-proton-api-0.4.0.drv-0/src/
> > > github.com/ProtonMail/go-crypto/openpgp/packet/packet_sequence.go:13:16:
> > > undefined: errors.ErrMalformedMessage
> > > /tmp/guix-build-go-github-com-protonmail-go-proton-api-0.4.0.drv-0/src/
> > > github.com/ProtonMail/go-crypto/openpgp/packet/packet_sequence.go:94:17:
> > > undefined: errors.ErrMalformedMessage
> > > /tmp/guix-build-go-github-com-protonmail-go-proton-api-0.4.0.drv-0/src/
> > > github.com/ProtonMail/go-crypto/openpgp/packet/config_v5.go:6:2:
> > > undefined:
> > > V5Disabled
> > > /tmp/guix-build-go-github-com-protonmail-go-proton-api-0.4.0.drv-0/src/
> > > github.com/ProtonMail/go-crypto/openpgp/packet/marker.go:27:33:
> > > undefined:
> > > packetTypeMarker
> > > /tmp/guix-build-go-github-com-protonmail-go-proton-api-0.4.0.drv-0/src/
> > > github.com/ProtonMail/go-crypto/openpgp/packet/padding.go:20:33:
> > > undefined:
> > > packetPadding
> > > 
> > > 
> > > I remember faking a Proton’s fork with the upstream package because
> > > GitHub
> > > failed to find it. It could be the one, or not. At least I have a thread
> > > to
> > > follow now; and a new tool for deep inspection.
> > 
> > It's been a while since I've worked in Go, but based on:
> > https://github.com/ProtonMail/go-crypto/blob/main/openpgp/packet/packet_s
> > equence.go#L9
> > 
> > 
> > ...I suspect the go-crypto repository houses multiple Go packages, which
> > all need to be packaged individually in Guix. It looks like your Guix
> > packages aren't doing that, which may explain the error you're getting.
> > This is just a hunch, it's been a few years since I wrote Go, and I never
> > dealt with packaging beyond stuffing static binaries into Docker
> > containers -- but it feels at least close to the root of the issue to me.
> > 
> > 
> > -- Ian
> 
> Hi,
> 
> As a everyday user of ProtonMail/guix for work i'm also interested to help
> you on this task. Perhaps could you provide a chan that contain only the
> dependencies and manifest to build proton-bridge ?
> 
> 
> That help us to reproduce the build and try to package and push go package
> that miss.
> 
> Best regards,
> SR


Thank you for your offer.  I accept it with gratitude.

During previous 3 days I was spinning in circles trying to pin down a correct 
combination of dependency versions with the same function prototype.  This 
morning I found one such combination and was able to push through to the top 
level, where the Go component of proton-bridge itself fails to build.

Unfortunately I still can see the same dreaded error of
" go build log
type func(a Address, b Address) int of
     func(a,         b Address) Int {…} does not match inferred type
     func(a Address, b Address) bool
 for func(a E,       b E      ) bool
"

I have prepared the "proton-bridge" bridge of my channel in a way preserving 
the other module files, but hopefully isolating them from use by Guix:
" .guix-channel
(channel
 (version 0)
 (directory "proton-bridge") ; <--- channel-root/proton-bridge/sovereign/...
 (dependencies
  (channel
   (introduction
    (channel-introduction
     (version 0)
     (commit "61c9f87404fcb97e20477ec379b643099e45f1db")
     (signer "A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351")))
   (name efraim-dfsg)
   (url "https://git.sr.ht/~efraim/my-guix";))
  (channel
   (introduction
    (channel-introduction
     (version 0)
     (commit "7c67c3a9f299517bfc4ce8235628657898dd26b2")
     (signer "CD2D 5EAA A98C CB37 DA91  D6B0 5F58 1664 7F8B E551")))
   (name guixrus)
   (url "https://git.sr.ht/~whereiseveryone/guixrus";))
  (channel
   (introduction
    (channel-introduction
     (version 0)
     (commit "897c1a470da759236cc11798f4e0a5f7d4d59fbc")
     (signer "2A39 3FFF 68F4 EF7A 3D29 12AF 6F51 20A0 22FB B2D5")))
   (name nonguix)
   (url "https://gitlab.com/nonguix/nonguix";))
  (channel
   (introduction
    (channel-introduction
     (version 0)
     (commit "c24ce7cb11e74da13d491f9de3c4b7040a069f43")
     (signer "590E 500F E39D 26B3 E60B 743B 6D81 B120 7711 899F")))
   (name deployment)
   (url "https://git.marekpasnikowski.pl/git/deployment.git";))
  (channel
   (introduction
    (channel-introduction
     (version 0)
     (commit "7d17bded11ef1239592e6e5abd40ceee1e99cbb8")
     (signer "590E 500F E39D 26B3 E60B 743B 6D81 B120 7711 899F")))
   (name distribution)
   (url "https://git.marekpasnikowski.pl/git/distribution.git";)))))
"

My intention is to preserve the define-module headers while keeping them 
accurate.  Do let me know if I misunderstood the (directory) field.

Please be understanding of the changing code style.  Throghout the last two 
weeks I have iterated through multiple styles with increasing focus on 
efficiency of implementation.  Towards the end I have developed an idea of
a universal origin function which constructs an origin object with data 
supplied to it inside a given package definition.

At this point I am more concerned with getting to the finish line than keeping 
the style consistent.  I am planning to rewrite everything from scratch once a 
working solution is found.

signature.asc
Description: This is a digitally signed message part.