Miroslav Vadkerti
Miroslav Vadkerti
We discussed this contribution on the hacking meeting: * let's go with multiple pages (tmt-try, tmt-run and a generic tmt for test/plan/story) * there is consensus on ^
mmkay, seems I am able to reproduce the problem directly via a generated containerfile: ``` ⬢ [nix] ❯ bluebuild generate > Containerfile podman buildINFO => Recipe ./recipes/recipe.yml is valid INFO...
with `--network=host` it just works. Is there a possibility to force host networking when using `blue-build` ?
ok, I am suspecting ipv6 to be causing it
mmkay this stinks: ``` ⬢ [nix] ❯ podman run --rm -it ghcr.io/ublue-os/sericea-main@sha256:bce60c243bcc152e7a8d96c6f0177f9eed2911d2a0d0cf52e400088dbfe30796 curl -I gitlab.com curl: (6) Could not resolve host: gitlab.com workstation on move-to-blue-build [✘»!+?] ⬢ [nix] ❯...
ok, I guess nothing to do with blue-build anyway: ``` ⬢ [nix] ❯ podman run --rm -it quay.io/fedora/fedora-sway-atomic cat /etc/resolv.conf search localdomain nameserver 169.254.1.1 nameserver 192.168.1.1 workstation on move-to-blue-build...
but it would be valuable to be able to force host networking
> * The testing farm always updates the guest before installing the rpms under test > @thrix, is this already covered on the Testing Farm side? We do this now...
@shi2wei3 @henrywang kindly asking for follow up :)
Relevant RH issues: https://issues.redhat.com/browse/KQE-59