Bug#922842: ITP: golang-github-containers-image -- Work with containers' images
On Tue, 2019-04-30 at 07:20 -0400, Reinhard Tartler wrote:
>
> I'm not familiar with building packages that way, please excuse my ignorance, but I'd rather focus on tools that I can actually use for uploading packages to Debian. I'm afraid that I'm probably
> unable to help you with this baseimage and/or approach to build packages.
I can understand that, but my problem is that I don't know 'sbuild' and while trying to set it up I'm facing too many unknown tools and proxy issues :-/
>
> > I prefer not to use too much magic (although using containers involves per-se some magic) to better understand what's going on.
>
> Same here. I took a look at https://github.com/debuerreotype/docker-debian-artifacts/blob/064f343bfa6ebf043aac2bbd4c870256cfe82f5a/sid/slim/Dockerfile and it does look pretty magical to me ;-)
How that root-filesystem is built is much magic, I agree with you.
But you end up with a Debian root-filesystem as small as ~60MB and very very few packages installed.
And once I have the container and I'm building in it, there's no much more magic involved anymore.
>
> There is not much magic with sbuild, please see https://wiki.debian.org/sbuild to get started.
As mentioned above, setting up 'schroot', configuring the proxy, ... it's not that easy if you have never done it.
>
> > I don't think that it's a language barrier.
> > But possibly an expertise barrier: my expertise on building Debian packages (specially for Go) is not as extensive as yours :-)
>
> I don't claim extensive experience with Go, or Go packaging, but I think I do have a reasonable grasp of Debian packaging tools.
It's good to have someone with your expertise working on it!
>
> What I find puzzling in your buildlog is that while you do use dpkg-buildpackage, it fails to apply the quilt patches.
'dpkg-buildpackage' doesn't patch for you, you have to do it on advance yourself.
>
> Good luck!
> -rt
Even with a separate workflow, I'm still the opinion that the patch of 'ostree/ostree_src.go' [1] results in invalid Go code.
Can you somehow see the intermediate files being created? Aren't you getting an empty 'ostree/ostree_src.go' file? That should make the Go compilation fail.
I wonder if some 'sbuild' magic is getting rid of the empty Go file before the compilation starts and therefore you don't face the issue...
Unfortunately I don't have that much time work on confirming the issue.
So if you can build it and provide the result via the repository mentioned in [2], then I suppose it's fine for me :-D
[2] https://github.com/containers/libpod/issues/1742#issuecomment-487910563
Cheers,
Silvano
Reply to: