Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propose the ability to use podman #42

Merged
merged 24 commits into from
Feb 13, 2022

Conversation

metal3d
Copy link
Contributor

@metal3d metal3d commented Apr 22, 2021

  • fix the ldflags to be set in GOFLAGS, so there is no problem by
    escaping environment variables
  • ldflags "-H" should be set with equal sign -H=windowsgui instead of
    `-H windowsgui'
  • add podman detection
  • add podman usage: no need to fix uid with gosu, podman has got an
    option named "--userns" to set to "keep-id".

@lucor
Copy link
Member

lucor commented Apr 27, 2021

Thanks for the PR it looks good to me, just few thoughts.

PRs should be have develop as base branch, could you please switch to it ?

The GOFLAGS could be also set via the fyne-cross --env flag, so we should ensure that internal GOFLAGS value are always appended to the ones specified by the user, if any. (rightmost setting wins)

@metal3d
Copy link
Contributor Author

metal3d commented Apr 27, 2021

I changed the base, so there is a conflict I will resolve.

I will check for GOFLAG.

@metal3d
Copy link
Contributor Author

metal3d commented Apr 27, 2021

Sorry there were a non fixed conflict, I will resolve (and fix the test)

@metal3d
Copy link
Contributor Author

metal3d commented Apr 27, 2021

@lucor I made a new test to fix GOFLAGS if it is sent in parameters. I can see:

$ fyne-cross linux  --debug
/usr/bin/docker run --rm -t -w /app -v /tmp/foo:/app:z -v /home/pafer/.cache/fyne-cross:/go:z -e CGO_ENABLED=1 \
-e GOCACHE=/go/go-build \
-e GOOS=linux -e GOARCH=amd64 -e CC=gcc \
-e GOFLAGS=-ldflags=-w -ldflags=-s \
-e fyne_uid=1000 fyneio/fyne-cross:1.1-base go build -o /app/fyne-cross/bin/linux-amd64/foo -v .

And with --env added:

$ fyne-cross linux --env GOFLAGS="-ldflags=-X='main.Version=1.0.0'" --debug
/usr/bin/docker run --rm -t -w /app -v /tmp/foo:/app:z -v /home/pafer/.cache/fyne-cross:/go:z -e CGO_ENABLED=1 \
-e GOCACHE=/go/go-build \
-e GOFLAGS=-ldflags=-X='main.Version=1.0.0' -ldflags=-w -ldflags=-s \
-e GOOS=linux -e GOARCH=amd64 -e CC=gcc \
-e fyne_uid=1000 fyneio/fyne-cross:1.1-base go build -o /app/fyne-cross/bin/linux-amd64/foo -v .

Copy link
Member

@lucor lucor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tried the changes using a Version as per your example.
I was able to see it into the logs, but in the fyne app that uses that variable seems to be ignored :(
Wondering if the multiple -ldflags are allowed.
Additionally I forgot that there is a fyne-cross --ldflags that we should handle as well.

Comment on lines 143 to 187
// findGoFlags return the index of context where GOFLAGS is set.
func findGoFlags(ctx Context) (int, error) {
for i, env := range ctx.Env {
if strings.Index(env, "GOFLAGS") == 0 {
return i, nil
}
}
return -1, errors.New("GOFLAGS not found in context")
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// findGoFlags return the index of context where GOFLAGS is set.
func findGoFlags(ctx Context) (int, error) {
for i, env := range ctx.Env {
if strings.Index(env, "GOFLAGS") == 0 {
return i, nil
}
}
return -1, errors.New("GOFLAGS not found in context")
}
// findGoFlags return the index of context where GOFLAGS is set, or -1 if is not present.
func findGoFlags(ctx Context) int {
for i, env := range ctx.Env {
if strings.HasPrefix(env, "GOFLAGS") {
return i
}
}
return -1
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about not returning an error here ?

Copy link
Member

@Jacalz Jacalz Apr 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, in the same part do the file. Couldn’t we just use strings.Contains?

Copy link
Contributor Author

@metal3d metal3d May 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lucor I did it the "go" way, but yes, it's possible to only return the index that is -1 if not found

@Jacalz because I want to be sure that this is the environment variable that is found and nothing more. It is possible that you want to pass "GOFLAGS" as a string in -X options (for example to inject a message in a variable at build time to say "with GOFLAGS")

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lucor I don't understand your first question. I was able to set multiple -ldflags - to set Version I also made the test and that worked with: -e GOFLAGS=-ldflags=-X='main.Version=1.0.0'

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did it the "go" way, but yes, it's possible to only return the index that is -1 if not found

Thanks for the changes. I see and agree with you about the Go way to return the error. In that specific case I'm ok with a little exception in favour of saving an err check like the strings.Index method due the fact it won't return error.

don't understand your first question. I was able to set multiple -ldflags - to set Version I also made the test and that worked with: -e GOFLAGS=-ldflags=-X='main.Version=1.0.0'

I tested locally with a small fyne app and tried to "inject" to variable values with ldflags but despite the fact I was able to see the flags in the fyne-cross compilation output, it was not set for the app.

Code I've used to test:

cat main.go 
package main

import (
	"fyne.io/fyne/v2"
	"fyne.io/fyne/v2/app"
	"fyne.io/fyne/v2/container"
	"fyne.io/fyne/v2/widget"
)

var Title = "Default"
var Name = "Default"

func main() {
	a := app.New()
	w := a.NewWindow(Title)

	hello := widget.NewLabel("Hi " + Name)
	w.SetContent(container.NewVBox(
		hello,
	))
	w.Resize(fyne.NewSize(200, 200))

	w.ShowAndRun()
}

Command used to compile:

fyne-cross linux --env GOFLAGS="-ldflags=-X='main.Name=Podman'" --debug .

fyne-cross logs:

[i] Building binary...
/usr/bin/docker run --rm -t -w /app -v /code/lucor/test:/app:z -v /home/lucor/.cache/fyne-cross:/go:z -e CGO_ENABLED=1 -e GOCACHE=/go/go-build -e GOFLAGS=-ldflags=-X='main.Name=Podman' -ldflags=-w -ldflags=-s -e GOOS=linux -e GOARCH=amd64 -e CC=gcc -e fyne_uid=1000 fyneio/fyne-cross:1.1-base go build -o /app/fyne-cross/bin/linux-amd64/test -v .
[✓] Binary: /code/lucor/test/fyne-cross/bin/linux-amd64/test
[i] Packaging app...
/usr/bin/docker run --rm -t -w /app -v /code/lucor/test:/app:z -e CGO_ENABLED=1 -e GOCACHE=/go/go-build -e fyne_uid=1000 fyneio/fyne-cross:1.1-base /usr/local/bin/fyne version
fyne cli version v2.0.2
/usr/bin/docker run --rm -t -w /app/fyne-cross/tmp/linux-amd64 -v /code/lucor/test:/app:z -v /home/lucor/.cache/fyne-cross:/go:z -e CGO_ENABLED=1 -e GOCACHE=/go/go-build -e GOFLAGS=-ldflags=-X='main.Name=Podman' -ldflags=-w -ldflags=-s -e GOOS=linux -e GOARCH=amd64 -e CC=gcc -e fyne_uid=1000 fyneio/fyne-cross:1.1-base /usr/local/bin/fyne package -os linux -name test -icon /app/fyne-cross/tmp/linux-amd64/Icon.png -appBuild 1 -appVersion 1.0 -executable /app/fyne-cross/bin/linux-amd64/test
[✓] Package: /code/lucor/test/fyne-cross/dist/linux-amd64/test.tar.gz

Application output:
image

Please also notes, that fyne-cross exposes also a -ldflags so we should have the following command to work too:

fyne-cross linux -ldflags="-X=main.Name=Podman" --debug .

Wrt the multilple ldflags, it seems that when you specify them like:

GOFLAGS="-ldflags=-X='main.Name=Podman' -ldflags=-s -ldflags=-w" go build

or

go build -ldflags=-X='main.Name=Podman' -ldflags=-s -ldflags=-w

only the last flag is used (try to compile changing the order)

The following instead work as expected:

go build -ldflags "-X=main.Name=Podman -w -s"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks again for working on this @metal3d. It is a very nice feature to have and would be nice to see it landed soon. Do you think you could get this rebased on develop? The tests don't want to start and I think the out-of-date branch might partly be the reason.

I'm currently makeing the merges and conflct resolution. I hope to not make regression...

I finally managed to test this out on my new Fedora 34 installation. I had to install podman-docker to even get it started. Would it be possible to get it to only use podman? After that, I ran into this error:

This is what I discussed earlier - I wanted to use the "podman" command instead of "docker" with "podman-docker" mackage. Yes, of course, the best is to use the "podman" command IMHO. I can make some changes for this.

~/go/bin/fyne-cross linux -arch amd64,arm64 -app-id com.github.jacalz.wormhole-gui -icon internal/assets/icon/icon-512.png
[i] Target: linux/amd64
[i] Cleaning target directories...
[✓] "bin" dir cleaned: /home/jacob/Git/wormhole-gui/fyne-cross/bin/linux-amd64
[✓] "dist" dir cleaned: /home/jacob/Git/wormhole-gui/fyne-cross/dist/linux-amd64
[✓] "temp" dir cleaned: /home/jacob/Git/wormhole-gui/fyne-cross/tmp/linux-amd64
[i] Checking for go.mod: /home/jacob/Git/wormhole-gui/go.mod
[✓] go.mod found
[i] Building binary...
USE PODMAN
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
Error: error getting default registries to try: short-name resolution enforced but cannot prompt without a TTY
[✗] exit status 125
make: *** [Makefile:51: linux] Error 1

It's been a while I didn't make tests with my fyne-cross changes, I don't remember how I tested 😅

I will try to make some tests a soon as the confict and merge / rebase are OK

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I see the problem.

This is the test file:

package main

import (
	"fyne.io/fyne/v2/app"
	"fyne.io/fyne/v2/widget"
)

var Message = "Default"

func main() {
	app := app.New()
	w := app.NewWindow(Message)
	t := widget.NewLabel(Message)

	w.SetContent(t)
	w.ShowAndRun()
}

When I build with:

../../fyne-cross/fyne-cross linux -ldflags="-X main.Message=42"

The error is:

go: parsing $GOFLAGS: non-flag "main.Message=42"

If I do:

# note the "=" after -X
../../fyne-cross/fyne-cross linux -ldflags="-X=main.Message=42"

So it builds, but the main.Message is not set...

it seems to be related to golang/go#26849

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK... I have new information.

The documentation says:

GOFLAGS
A space-separated list of -flag=value settings to apply
to go commands by default, when the given flag is known by
the current command. Each entry must be a standalone flag.
Because the entries are space-separated, flag values must
not contain spaces. Flags listed on the command line
are applied after this list and therefore override it.

So, "flags value" cannot contain spaces... And -ldflag=-X main.Value=foo is badly interpreted. This is the only one ldflag that will not work with -X=main...

That means that this particular ldflag shoud be passed in the command line, not in environment.

So, what I can try is to pass ldflags to the command line...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GOFLAGS seems to be fixed in aa8002d

I didn't tried with "docker". Note that now, the "podman" command is used even if "docker" command is an alias

Copy link
Member

@Jacalz Jacalz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking forward to seeing this landed. Just a few comments/suggestions for you. Will have a closer look once I get all set up with my switch to Fedora Linux.

}
flags := make([]string, len(ldflags))
for i, flag := range ldflags {
flags[i] = fmt.Sprintf("-ldflags=%s", flag)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should be able to just as well not use fmt.Sprintf. Just do flags[i] = "-ldflags=" + flag. Just as readable (in my opinion) but much faster.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in dc40425 ;)

internal/command/docker.go Show resolved Hide resolved
Copy link
Member

@Jacalz Jacalz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks again for working on this @metal3d. It is a very nice feature to have and would be nice to see it landed soon. Do you think you could get this rebased on develop? The tests don't want to start and I think the out-of-date branch might partly be the reason.

I finally managed to test this out on my new Fedora 34 installation. I had to install podman-docker to even get it started. Would it be possible to get it to only use podman? After that, I ran into this error:

~/go/bin/fyne-cross linux -arch amd64,arm64 -app-id com.github.jacalz.wormhole-gui -icon internal/assets/icon/icon-512.png
[i] Target: linux/amd64
[i] Cleaning target directories...
[✓] "bin" dir cleaned: /home/jacob/Git/wormhole-gui/fyne-cross/bin/linux-amd64
[✓] "dist" dir cleaned: /home/jacob/Git/wormhole-gui/fyne-cross/dist/linux-amd64
[✓] "temp" dir cleaned: /home/jacob/Git/wormhole-gui/fyne-cross/tmp/linux-amd64
[i] Checking for go.mod: /home/jacob/Git/wormhole-gui/go.mod
[✓] go.mod found
[i] Building binary...
USE PODMAN
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
Error: error getting default registries to try: short-name resolution enforced but cannot prompt without a TTY
[✗] exit status 125
make: *** [Makefile:51: linux] Error 1

@metal3d
Copy link
Contributor Author

metal3d commented Jun 7, 2021 via email

@metal3d
Copy link
Contributor Author

metal3d commented Jun 22, 2021

Thanks again for working on this @metal3d. It is a very nice feature to have and would be nice to see it landed soon. Do you think you could get this rebased on develop? The tests don't want to start and I think the out-of-date branch might partly be the reason.

I finally managed to test this out on my new Fedora 34 installation. I had to install podman-docker to even get it started. Would it be possible to get it to only use podman? After that, I ran into this error:

~/go/bin/fyne-cross linux -arch amd64,arm64 -app-id com.github.jacalz.wormhole-gui -icon internal/assets/icon/icon-512.png
[i] Target: linux/amd64
[i] Cleaning target directories...
[✓] "bin" dir cleaned: /home/jacob/Git/wormhole-gui/fyne-cross/bin/linux-amd64
[✓] "dist" dir cleaned: /home/jacob/Git/wormhole-gui/fyne-cross/dist/linux-amd64
[✓] "temp" dir cleaned: /home/jacob/Git/wormhole-gui/fyne-cross/tmp/linux-amd64
[i] Checking for go.mod: /home/jacob/Git/wormhole-gui/go.mod
[✓] go.mod found
[i] Building binary...
USE PODMAN
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
Error: error getting default registries to try: short-name resolution enforced but cannot prompt without a TTY
[✗] exit status 125
make: *** [Makefile:51: linux] Error 1

I made some changes to detect docker, and if "docker" is a "podman" alias. So I can use "docker" or "podman" command now. I want to fix the ldflags problem before.

@metal3d
Copy link
Contributor Author

metal3d commented Jun 22, 2021

Thanks again for working on this @metal3d. It is a very nice feature to have and would be nice to see it landed soon. Do you think you could get this rebased on develop? The tests don't want to start and I think the out-of-date branch might partly be the reason.
I finally managed to test this out on my new Fedora 34 installation. I had to install podman-docker to even get it started. Would it be possible to get it to only use podman? After that, I ran into this error:

~/go/bin/fyne-cross linux -arch amd64,arm64 -app-id com.github.jacalz.wormhole-gui -icon internal/assets/icon/icon-512.png
[i] Target: linux/amd64
[i] Cleaning target directories...
[✓] "bin" dir cleaned: /home/jacob/Git/wormhole-gui/fyne-cross/bin/linux-amd64
[✓] "dist" dir cleaned: /home/jacob/Git/wormhole-gui/fyne-cross/dist/linux-amd64
[✓] "temp" dir cleaned: /home/jacob/Git/wormhole-gui/fyne-cross/tmp/linux-amd64
[i] Checking for go.mod: /home/jacob/Git/wormhole-gui/go.mod
[✓] go.mod found
[i] Building binary...
USE PODMAN
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
Error: error getting default registries to try: short-name resolution enforced but cannot prompt without a TTY
[✗] exit status 125
make: *** [Makefile:51: linux] Error 1

I made some changes to detect docker, and if "docker" is a "podman" alias. So I can use "docker" or "podman" command now. I want to fix the ldflags problem before.

OK, for the registry, now, Fedora proposes several registries. The image location should be "docker.io/blablabla" for "moby-engine" (the docker distribution by RH/Fedora" and podman. I should not have this problem because I built the image myself (to fix the entrypoint for podman)

So, the image "url" should be changed to its complete form.

@metal3d metal3d requested a review from Jacalz June 22, 2021 06:46
Copy link
Member

@Jacalz Jacalz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late review. I've had a lot to do with work related stuff.

I still could not use only podman, had to install podman-docker to get to this point. If it is possible to egt it to only use podman directly, that would be great, but not a necessity, I guess. This is looking better, but I am still getting the following output when trying to use it:

/home/jacob/go/bin/fyne-cross windows -arch amd64 -app-id io.github.jacalz.seaborne
[i] Target: windows/amd64
[i] Cleaning target directories...
[✓] "bin" dir cleaned: /home/jacob/Git/seaborne/fyne-cross/bin/windows-amd64
[✓] "dist" dir cleaned: /home/jacob/Git/seaborne/fyne-cross/dist/windows-amd64
[✓] "temp" dir cleaned: /home/jacob/Git/seaborne/fyne-cross/tmp/windows-amd64
[i] Checking for go.mod: /home/jacob/Git/seaborne/go.mod
[✓] go.mod found
Error: short-name resolution enforced but cannot prompt without a TTY
[✗] could not package the Fyne app: exit status 125

@metal3d
Copy link
Contributor Author

metal3d commented Jul 6, 2021

Sorry for the late review. I've had a lot to do with work related stuff.

I still could not use only podman, had to install podman-docker to get to this point. If it is possible to egt it to only use podman directly, that would be great, but not a necessity, I guess. This is looking better, but I am still getting the following output when trying to use it:

/home/jacob/go/bin/fyne-cross windows -arch amd64 -app-id io.github.jacalz.seaborne
[i] Target: windows/amd64
[i] Cleaning target directories...
[✓] "bin" dir cleaned: /home/jacob/Git/seaborne/fyne-cross/bin/windows-amd64
[✓] "dist" dir cleaned: /home/jacob/Git/seaborne/fyne-cross/dist/windows-amd64
[✓] "temp" dir cleaned: /home/jacob/Git/seaborne/fyne-cross/tmp/windows-amd64
[i] Checking for go.mod: /home/jacob/Git/seaborne/go.mod
[✓] go.mod found
Error: short-name resolution enforced but cannot prompt without a TTY
[✗] could not package the Fyne app: exit status 125

You should not require to install "podman-docker", I haven't it and it works now with "podman" command if needed.

For the "short" link name, this is a problem. As explained, podman (and the "docker" version of Fedora named "moby-engine") proposes to use others registries, so we need TTY to answer. If the image is already present (for example because I compiled the image myself to test my changes) so it works.

The problem is that it seems you don't have the image on your Fedora (and it's absolutely normal) - The "solution" is: we change the image path to "docker.io/fyne/fyne-cross" ("docker.io" added to the image name, so podman or moby-engine understand where is the repository) - but this has got a bad behaviour: we can't use a locally built image...

I'm trying to find a way to make it possible to have a TTY to answer the question asked by podman/moby... this problem doesn't happen if you use "docker" (because they configured the docker client to use "docker.io" by default).

Or, maybe you have a better idea ?

@metal3d
Copy link
Contributor Author

metal3d commented Jul 6, 2021

@Jacalz the "pullImage" function can be changed like in e9a493d so it now avoids to ask which repository to use. Could you please check if it's OK on your Fedora ?

@metal3d metal3d requested a review from Jacalz July 6, 2021 16:40
@metal3d
Copy link
Contributor Author

metal3d commented Jul 7, 2021

@Jacalz I tried and see this:

../../fyne-cross/fyne-cross windows
[i] Target: windows/amd64
[i] Cleaning target directories...
[✓] "bin" dir cleaned: /home/metal3d/Projects/fyne-experiments/test-cross/fyne-cross/bin/windows-amd64
[✓] "dist" dir cleaned: /home/metal3d/Projects/fyne-experiments/test-cross/fyne-cross/dist/windows-amd64
[✓] "temp" dir cleaned: /home/metal3d/Projects/fyne-experiments/test-cross/fyne-cross/tmp/windows-amd64
[i] Checking for go.mod: /home/metal3d/Projects/fyne-experiments/test-cross/go.mod
[✓] go.mod found
Resolving "fyneio/fyne-cross" using unqualified-search registries (/etc/containers/registries.conf)
Trying to pull registry.fedoraproject.org/fyneio/fyne-cross:1.1-windows...
Trying to pull registry.access.redhat.com/fyneio/fyne-cross:1.1-windows...
Trying to pull docker.io/fyneio/fyne-cross:1.1-windows...

and the image is well pulled, but the "pullImage" seems to not being used at this stage.

But, for me, it never asks for TTY... Are you up to date with podman ?

Copy link
Member

@Jacalz Jacalz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your work on this. the latest changes seems to make it mostly work without installing podman-docker, nice work. Looks like a few changes are part of this PR that are unrelated to this. Did the merge go wrong?

I'm still running into the issue with TTY on my fully updated Fedora 34 installation. Am I missing something with how I should use podman? I literally just used what I had installed, no tweaking or other changes done on my part.

I also tried doing fyne-cross windows -pull and got an error that the docker executable wasn't available. I tried installing podman-docker and got this instead:

[✓] go.mod found
chown: changing ownership of '/go': Operation not permitted
[✗] could not package the Fyne app: exit status 1

Got a similar error when I tried to run a regular build using fyne-cross as well after having installed podman-docker.

@metal3d
Copy link
Contributor Author

metal3d commented Jul 9, 2021 via email

@Jacalz
Copy link
Member

Jacalz commented Jul 10, 2021

I did use it thorough a Makefile if I remember correctly. It shouldn't cause any issues, I think, but I'll try without just to be sure.

@metal3d
Copy link
Contributor Author

metal3d commented Jul 12, 2021

Thanks for your work on this. the latest changes seems to make it mostly work without installing podman-docker, nice work. Looks like a few changes are part of this PR that are unrelated to this. Did the merge go wrong?

There were something weird as soon as I pull "develop" branch then rebased mine. I don't know why but some things were "recommitted" without any reason.

For example, there is a problem with CHANGELOG.md file... whatever I do, there is a difference between mine and the one from develop branch...

@metal3d
Copy link
Contributor Author

metal3d commented Jul 12, 2021

I made fixes on the rebase, it seems that it's now a bit better.
I will try to see how to avoid the need of TTY - it's not that easy to find where you defined the image names (and so URLs) 😉

@metal3d
Copy link
Contributor Author

metal3d commented Jul 12, 2021

OK @Jacalz I see the problem.

My laptops have this file: /etc/containers/registries.conf, wich is provided by the package named containers-common.

(You can check if your configuration is changed from the RPM version sudo rpm -Vc containers-common and try sudo rpmconf -a to say if you want to take the maintainer version of configuration.)

Inside, there is a list of unqualified-search-registries that I didn't touch (I didn't touch this file anyway). Podman uses this list to search images if the "domain" is not set.

When TTY is not accessible, podman searches inside these registries - but not on your laptop. It's weird because I made tests on my 2 laptops and both don't ask anything. But, if you've got the problem, so others will have the same problem.

There are 2 possibilities:

  • the first one is to add this line in docker.go in the Cmd function (line 124): pullImage(Context{DockerImage: "docker.io/" + image, Pull: true}) - this will pull the image with the right domain - the problem is that it will overwrite the local images, so it breaks local changes on images
  • the second is to add an option for "pullImage" function to say "pull if not present" (exactly like Kubernetes does) - this will pull the images if it's not present on the user's computer

The second option is better IMHO, but to needs a bit more modifications. I can do it. Do you want me to make this changes ?

@metal3d
Copy link
Contributor Author

metal3d commented Jul 13, 2021

@Jacalz I found a way to avoid the problem in a88ea79

  • the makefile tags images with the full name (domain as prefix)
  • I add the domain to the image in command calls

So:

  • if the user hasn't the image (e.g. it hasn't built them) so the pull is made with the full image name
  • if the user has built the images with podman (see the Makefile) so the image is present

This fixes problems for me. It works with Docker and Podman. Note that OCI recommends using the full image name with domain since there are now a few public registries, using the full name avoids image spoofing.

@metal3d metal3d requested a review from Jacalz July 13, 2021 08:29
Copy link
Member

@Jacalz Jacalz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the great work with the changes. I still need to test on my workstation, but I just tested on my laptop (of which I had never used docker or podman). I downloaded this branch and just ran the following command and got the below output.This is getting very close now :)

[jacob@fedora seaborne]$ make windows
/home/jacob/go/bin/fyne-cross windows -arch amd64 -app-id io.github.jacalz.seaborne
[i] Target: windows/amd64
[i] Cleaning target directories...
[✓] "temp" dir cleaned: /home/jacob/Git/seaborne/fyne-cross/tmp/windows-amd64
[✓] "bin" dir cleaned: /home/jacob/Git/seaborne/fyne-cross/bin/windows-amd64
[✓] "dist" dir cleaned: /home/jacob/Git/seaborne/fyne-cross/dist/windows-amd64
[i] Checking for go.mod: /home/jacob/Git/seaborne/go.mod
[✓] go.mod found
Trying to pull docker.io/fyneio/fyne-cross:1.1-windows...
Getting image source signatures
Copying blob 65d943ee54c1 done  
Copying blob 8962bc0fad55 done  
Copying blob e8d62473a22d done  
Copying blob d960726af2be done  
Copying blob 186c77a2a533 done  
Copying blob f2253e6fbefa done  
Copying blob db807893dccf done  
Copying blob 292f24f0ff89 done  
Copying blob 974bf8135e20 done  
Copying blob 6f6e9bee4d1e done  
Copying blob bf3ad36f9777 done  
Copying blob 2411a53787f3 done  
Copying config dcf827d6fe done  
Writing manifest to image destination
Storing signatures
chown: changing ownership of '/go': Operation not permitted
[✗] could not package the Fyne app: exit status 1
make: *** [Makefile:28: windows] Error 1

metal3d and others added 18 commits September 15, 2021 08:51
- Only return the index
- Use `strings.HasPrefix` instead of `strings.Index`
- fix the ldflags to be set in GOFLAGS, so there is no problem by
escaping environment variables
- ldflags "-H" should be set with equal sign `-H=windowsgui` instead of
`-H windowsgui'
- add podman detection
- add podman usage: no need to fix uid with gosu, podman has got an
option named "--userns" to set to "keep-id".
- Only return the index
- Use `strings.HasPrefix` instead of `strings.Index`
- fix the ldflags to be set in GOFLAGS, so there is no problem by
escaping environment variables
- ldflags "-H" should be set with equal sign `-H=windowsgui` instead of
`-H windowsgui'
- add podman detection
- add podman usage: no need to fix uid with gosu, podman has got an
option named "--userns" to set to "keep-id".
- Only return the index
- Use `strings.HasPrefix` instead of `strings.Index`
- Better podman detection, because the user could not have podman-socket
so we detect if "docker" command is installed, and if it's an alias -
either we can use "podman" command
- The podman detection is now cached, because we need to have this
information several times
- Fix the "ldflags" detection. The "-X" option for ldflags is a special
case that we can pass to the command line argument. There are errors if
it's passed in GOFLAGS
- The runner is now globally set
- We prefix the image by "docker.io" in calls. It works with any runner
  (docker, podman, runc...) - it's recommanded by OCI and it avoids
  podman to ask which registry to use.
- If podman is used, the Makefile tags the images with the "docker.io"
  prefix. It could be OK for docker also, but at this time it's enough
  to avoid the image overwrite
We need to parse the entire ldflag argument to check if there are
several `-X` parameters. Then we rebuild the entire string.

TODO: This need automated tests.
This will help to be compatible with others engines later.
@Jacalz
Copy link
Member

Jacalz commented Dec 14, 2021

@metal3d Was I supposed to do a re-review on this? I was never requested for a re-review but it looks like you have pushed a few commits since the last time. If I was, I'm sorry that it took me three months to reach to this :I

Copy link
Member

@Jacalz Jacalz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few notes on switching to execabs instead of exec.

)

// CheckRequirements checks if the docker binary is in PATH
func CheckRequirements() error {
_, err := execabs.LookPath("docker")
_, err := exec.LookPath("docker")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please switch back to execabs (applies to more places in this PR)? It is being used because exec has a security issue on Windows that can't be fixed without breaking the API stability guarantee.

Copy link
Member

@Jacalz Jacalz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have decided that it's fine to land this and fix the minor stuff afterwards. I'll approve this. Thanks a lot for working on this and sorry for the long wait.

@lucor lucor merged commit eaf082c into fyne-io:develop Feb 13, 2022
@lucor
Copy link
Member

lucor commented Feb 13, 2022

Thanks @metal3d and sorry for the long wait.

@metal3d
Copy link
Contributor Author

metal3d commented Feb 18, 2022

I'm sorry to not have answered for a while. Many things happened last months and I missed a lot of discussion.

I'm very happy you accepted this PR :)

@Jacalz
Copy link
Member

Jacalz commented Feb 18, 2022

No worries. Thanks for all your hard work!

@Jacalz
Copy link
Member

Jacalz commented Feb 20, 2022

You can't use it just yet with as the updated images aren't on docker hub currently (I think so at least). They need to be tagged differently, so you'll either have to wait for new images or run make build-images (takes a long time) locally on your computer.

EDIT: The question seems to have been moved to the issue instead.

@lucor lucor mentioned this pull request Mar 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants