On czwartek, 5 grudnia 2024 17:37:05 CET you wrote: > Le samedi 30 novembre 2024 à 8:22 PM, Ian Eure 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.