From: "Timo Wilken" <guix@twilken.net>
To: "wolf" <wolf@wolfsden.cz>
Cc: 54097@debbugs.gnu.org
Subject: bug#54097: [PATCH] import: go: Handle subpackage versioning correctly.
Date: Mon, 22 May 2023 21:11:34 +0200 [thread overview]
Message-ID: <CST1MCR6Z0PA.2YU25GTLRLRIJ@lap.twilken.net> (raw)
In-Reply-To: <ZGqTGVrlJsLi9hxW@ws>
Hi wolf,
On Sun May 21, 2023 at 11:54 PM CEST, wolf wrote:
> Please give the github.com/Azure/go-autorest/tracing@v0.6.0 a go. My code
> failed on it, and (assuming I applied the patch correctly) your does as well.
> Here are reproduction steps to make it easier for you (please tell me if I did
> something wrong):
I don't think you did anything wrong there.
That's an issue I've run into in the past as well, though it seems to be a bug
in the Go build system, not the importer (and in my patch I only touch the
importer).
> I will not pretend to have a full grasp on how (guix build-system go) works,
> however my debugging lead me to the observation that it tries to unpack two
> dependencies into one file system tree overlayed on top of each other. I think
> the current way (GO111MODULE=off) of building of golang packages does not play
> very well with well, go modules.
Fair enough! I don't know much about Go -- I don't write software in it, I
just want to package some stuff written in it; in my case, that's
Matrix-related programs.
> Either the build system needs to be smarter about unpacking dependencies (and
> doing it in a correct order), or we should start using go modules for the builds
> (it can still be down offline, just the dependencies are in different paths).
> The second approach is what I wanted to explore, but did not get to it yet (and
> likely will not for a month or two).
Your second approach sounds sensible!
If I can find the time and motivation to dig in to this, I might have a go as
well... But if you get anything working, that would be much appreciated! :)
Cheers,
Timo
next parent reply other threads:[~2023-05-22 19:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6dd1de3dd4d968876fa55f5126056834c77b0244.1684703258.git.guix@twilken.net>
[not found] ` <ZGqTGVrlJsLi9hxW@ws>
2023-05-22 19:11 ` Timo Wilken [this message]
[not found] ` <87pm5xrbsg.fsf@gnu.org>
2023-06-17 15:12 ` bug#63001: bug#63631: [PATCH] import: go: Handle subpackage versioning correctly Timo Wilken
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CST1MCR6Z0PA.2YU25GTLRLRIJ@lap.twilken.net \
--to=guix@twilken.net \
--cc=54097@debbugs.gnu.org \
--cc=wolf@wolfsden.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).