Hoping to disable i686 and 32-bit arm for Podman and related tools for existing Fedora releases

[Lokesh Mandvekar]

Hi,

We (podman upstream and fedora maintainers) are hoping to disable i686
and 32-bit arm builds for Podman and some related tools under
https://github.com/containers org. We would like to do this also for
released Fedora versions, and not just the upcoming ones.

What Fedora paperwork do we need in place to get this going?

Thanks
-- 
Lokesh
Libera, GitLab, GitHub, Fedora: lsm5
Matrix: @lsm5:lsm5.ems.host
GPG: 0xC7C3A0DD
https://keybase.io/lsm5

[Peter Robinson]

On Tue, Feb 7, 2023 at 11:43 AM Lokesh Mandvekar <lsm5(a)fedoraproject.org&gt; wrote:
>  Hi,
>
>  We (podman upstream and fedora maintainers) are hoping to disable i686
>  and 32-bit arm builds for Podman and some related tools under
>  https://github.com/containers org. We would like to do this also for
>  released Fedora versions, and not just the upcoming ones. 
There are still active users of Fedora IoT 36 on armhfp using
containers so I suspect they may be unhappy of they go away before the
F-36 EOL in the late May/early June timeframe.

Peter

> What Fedora paperwork do we need in place to get this going?
>
> Thanks
> --
> Lokesh
> Libera, GitLab, GitHub, Fedora: lsm5
> Matrix: @lsm5:lsm5.ems.host
> GPG: 0xC7C3A0DD
> https://keybase.io/lsm5
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Lokesh Mandvekar]

On Tue, Feb 7, 2023 at 5:56 PM Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:

>  There are still active users of Fedora IoT 36 on armhfp using
>  containers so I suspect they may be unhappy of they go away before the
>  F-36 EOL in the late May/early June timeframe. 
I see. I guess we could leave armhfp be until then. Btw, just curious
what happens to IoT on armhfp once f36 goes EOL.
Would users have to pick something else?

Thanks,

>  Peter
>  


-- 
Lokesh
Libera, GitLab, GitHub, Fedora: lsm5
Matrix: @lsm5:lsm5.ems.host
GPG: 0xC7C3A0DD
https://keybase.io/lsm5

[Peter Robinson]

On Tue, Feb 7, 2023 at 12:36 PM Lokesh Mandvekar <lsm5(a)fedoraproject.org&gt; wrote:
>  On Tue, Feb 7, 2023 at 5:56 PM Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:
>
>  > There are still active users of Fedora IoT 36 on armhfp using
>  > containers so I suspect they may be unhappy of they go away before the
>  > F-36 EOL in the late May/early June timeframe.
>
>  I see. I guess we could leave armhfp be until then. Btw, just curious
>  what happens to IoT on armhfp once f36 goes EOL.
>  Would users have to pick something else? 
Basically yes.

[Demi Marie Obenour]

On 2/7/23 07:52, Peter Robinson wrote:
>  On Tue, Feb 7, 2023 at 12:36 PM Lokesh Mandvekar
> <lsm5(a)fedoraproject.org&gt; wrote:
> >
> > On Tue, Feb 7, 2023 at 5:56 PM Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:
> >
> >> There are still active users of Fedora IoT 36 on armhfp using
> >> containers so I suspect they may be unhappy of they go away before the
> >> F-36 EOL in the late May/early June timeframe.
> >
> > I see. I guess we could leave armhfp be until then. Btw, just curious
> > what happens to IoT on armhfp once f36 goes EOL.
> > Would users have to pick something else?
>  
>  Basically yes. 
Not sure if Debian supports armhfp, but in the long term the answer is
going to be to find a distro that cross-compiles everything.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Michel Alexandre Salim]

On Wed, 2023-02-08 at 22:24 -0500, Demi Marie Obenour wrote:
>  On 2/7/23 07:52, Peter Robinson wrote:
>  > On Tue, Feb 7, 2023 at 12:36 PM Lokesh Mandvekar
>  > <lsm5(a)fedoraproject.org&gt; wrote:
>  > > 
>  > > On Tue, Feb 7, 2023 at 5:56 PM Peter Robinson
>  > > <pbrobinson(a)gmail.com&gt; wrote:
>  > > 
>  > > > There are still active users of Fedora IoT 36 on armhfp using
>  > > > containers so I suspect they may be unhappy of they go away
>  > > > before the
>  > > > F-36 EOL in the late May/early June timeframe.
>  > > 
>  > > I see. I guess we could leave armhfp be until then. Btw, just
>  > > curious
>  > > what happens to IoT on armhfp once f36 goes EOL.
>  > > Would users have to pick something else?
>  > 
>  > Basically yes.
>  
>  Not sure if Debian supports armhfp, but in the long term the answer
>  is
>  going to be to find a distro that cross-compiles everything.
>   
But of course: https://wiki.debian.org/SupportedArchitectures

It also supports mips (both 32- and 64-bit) because... 

Cheers,

-- 
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

[Dan Čermák]

Hi Lokesh,

Lokesh Mandvekar <lsm5(a)fedoraproject.org&gt; writes:

>  Hi,
>
>  We (podman upstream and fedora maintainers) are hoping to disable i686
>  and 32-bit arm builds for Podman and some related tools under
>  https://github.com/containers org. We would like to do this also for
>  released Fedora versions, and not just the upcoming ones.
>
>  What Fedora paperwork do we need in place to get this going? 
I would suggest to file a self-contained change proposal to get some
visibility for this change in the official release notes. But afaik all
you have to do is to define `ExclusiveArch:` or `ExcludeArch:` in your
spec file.


Hope this helps,

Dan

[Stephen Smoogen]

On Tue, 7 Feb 2023 at 07:38, Dan Čermák <dan.cermak(a)cgc-instruments.com&gt;
wrote:

>  Hi Lokesh,
>
>  Lokesh Mandvekar <lsm5(a)fedoraproject.org&gt; writes:
>
>  > Hi,
>  >
>  > We (podman upstream and fedora maintainers) are hoping to disable i686
>  > and 32-bit arm builds for Podman and some related tools under
>  > https://github.com/containers org. We would like to do this also for
>  > released Fedora versions, and not just the upcoming ones.
>  >
>  > What Fedora paperwork do we need in place to get this going?
>
>  I would suggest to file a self-contained change proposal to get some
>  visibility for this change in the official release notes. But afaik all
>  you have to do is to define `ExclusiveArch:` or `ExcludeArch:` in your
>  spec file.
>
>  
Depending on where it might have been 'defined', it may need some fiddling
in releng scripts or releng pungi. As part of the self-contained change
proposal make sure you file the requisite releng ticket to make sure they
are aware that the change will be happening, why it is happening (various
software in the chain of dependencies compiles/works on 32 bit), and what
parts will be affected.


>  Hope this helps,
>
>  Dan
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[Lokesh Mandvekar]

On Tue, Feb 7, 2023 at 6:12 PM Stephen Smoogen <ssmoogen(a)redhat.com&gt; wrote:
>  On Tue, 7 Feb 2023 at 07:38, Dan Čermák <dan.cermak(a)cgc-instruments.com&gt; wrote:
> >
> > Hi Lokesh,
> >
> > Lokesh Mandvekar <lsm5(a)fedoraproject.org&gt; writes:
> >
> > > Hi,
> > >
> > > We (podman upstream and fedora maintainers) are hoping to disable i686
> > > and 32-bit arm builds for Podman and some related tools under
> > > https://github.com/containers org. We would like to do this also for
> > > released Fedora versions, and not just the upcoming ones.
> > >
> > > What Fedora paperwork do we need in place to get this going?
> >
> > I would suggest to file a self-contained change proposal to get some
> > visibility for this change in the official release notes. But afaik all
> > you have to do is to define `ExclusiveArch:` or `ExcludeArch:` in your
> > spec file.
> >
>
>  Depending on where it might have been 'defined', it may need some fiddling in
> releng scripts or releng pungi. As part of the self-contained change proposal make sure
> you file the requisite releng ticket to make sure they are aware that the change will be
> happening, why it is happening (various software in the chain of dependencies
> compiles/works on 32 bit), and what parts will be affected.
>  
Thanks all. I'll file a self-contained change for i686 and leave
armhfp as-is for now, and update this thread once I have it ready.


-- 
Lokesh
Libera, GitLab, GitHub, Fedora: lsm5
Matrix: @lsm5:lsm5.ems.host
GPG: 0xC7C3A0DD
https://keybase.io/lsm5

[Maxwell G]

2023-02-07T11:43:53Z Lokesh Mandvekar <lsm5(a)fedoraproject.org&gt;:

>  We (podman upstream and fedora maintainers) are hoping to disable
> i686
>  and 32-bit arm builds for Podman and some related tools under
>  https://github.com/containers org. We would like to do this also for
>  released Fedora versions, and not just the upcoming ones.
>
>  What Fedora paperwork do we need in place to get this going? 
arm32 has been removed entirely from F37+. I don't think excluding
packages from arm32 at this point in the F36 release cycle is
acceptable. Wait until the release goes EOL.

As for i686, you don't need extra paperwork thanks to exclude packages
thanks to
https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval.
You just need to properly handle dependent packages. You cannot
ExcludeArch a package unless all of its dependents are also excluded.
It's recommended to exclude Go packages with
`ExclusiveArch: %{golang_arches_future}`.
For other packages, a regular `ExcludeArch: %{ix86}` is sufficient.

Here's some of the dependents you need to account for:

---
$ cat <<EOF | sudo tee /etc/yum.repos.d/koji.repo
[koji]
name=koji
baseurl=https://kojipkgs.fedoraproject.org/repos/rawhide/latest/$basearch/
enabled=0


[koji-source]
name=koji-source
baseurl=https://kojipkgs.fedoraproject.org/repos/rawhide/latest/src/
enabled=0
EOF

$ for p in aardvark-dns buildah catatonit conmon containers-common crun podman skopeo
netavark; do
echo $p
echo ------
repoquery -q --repo=koji{,-source} --forcearch i686 --qf=%{name}.%{arch} --latest=1
--whatrequires $p
echo
echo
done

aardvark-dns
------
netavark.i686


buildah
------
ansible-bender.noarch
buildah-tests.i686
podman-tests.i686


catatonit
------
podman.i686


conmon
------
cri-o.i686
podman.i686
singularity-ce.i686


containers-common
------
containers-common-extra.noarch
cri-o.i686
skopeo.i686
toolbox.i686


crun
------
containers-common-extra.noarch
quadlet.i686
skopeo-tests.i686


podman
------
buildah-tests.i686
cockpit-podman.noarch
copr-builder.i686
distrobox.noarch
nbdkit-cdi-plugin.i686
podman-compose.noarch
podman-docker.noarch
podman-quadlet.i686
podman-tests.i686
python3-mrack-podman.noarch
quadlet.i686
retrace-server.src
skopeo-tests.i686
tmt-provision-container.noarch
toolbox.i686
x11docker.noarch


skopeo
------
bodhi-composer.noarch
bodhi-server.src
podman-tests.i686
rpm-ostree.i686
sigul.src
skopeo-tests.i686
toolbox-tests.i686
virt-bootstrap.noarch


netavark
------
containers-common-extra.noarch

[Lokesh Mandvekar]

On Tue, Feb 7, 2023 at 11:06 PM Maxwell G via devel
<devel(a)lists.fedoraproject.org&gt; wrote:

>  As for i686, you don't need extra paperwork thanks to exclude packages
>  thanks to
>  https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval.
>  You just need to properly handle dependent packages. You cannot
>  ExcludeArch a package unless all of its dependents are also excluded.
>  It's recommended to exclude Go packages with
>  `ExclusiveArch: %{golang_arches_future}`.
>  For other packages, a regular `ExcludeArch: %{ix86}` is sufficient. 
Great, that makes life a lot easier. I'll go ahead with
ExclusiveArch-ing them (or ExcludeArch if permissible). armhfp on f36
will be left as-is.

Thank you.
-- 
Lokesh
Libera, GitLab, GitHub, Fedora: lsm5
Matrix: @lsm5:lsm5.ems.host
GPG: 0xC7C3A0DD
https://keybase.io/lsm5

[Kevin Kofler]

Lokesh Mandvekar wrote:
>  We (podman upstream and fedora maintainers) are hoping to disable
> i686
>  and 32-bit arm builds for Podman and some related tools under
>  https://github.com/containers org. We would like to do this also for
>  released Fedora versions, and not just the upcoming ones. 
In general, dropping architectures from packages in released Fedora versions 
is a no go. That said, i686 is special because it is a multilib-only 
architecture, so executables such as podman should not have been shipped for 
i686 to begin with.

Does dropping the 32-bit i686 build also imply you cannot use 32-bit 
containers on a 64-bit architecture? If so, will anybody notice? Since you 
did not use any special naming tricks (both package naming and file naming) 
to allow installing both versions (as in, e.g., wine), one has to go out of 
one's way to install the 32-bit version instead of the 64-bit one, and they 
cannot both be installed at once.

        Kevin Kofler

[Lokesh Mandvekar]

On Wed, Feb 8, 2023 at 9:01 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Does dropping the 32-bit i686 build also imply you cannot use 32-bit
>  containers on a 64-bit architecture? If so, will anybody notice? Since you
>  did not use any special naming tricks (both package naming and file naming)
>  to allow installing both versions (as in, e.g., wine), one has to go out of
>  one's way to install the 32-bit version instead of the 64-bit one, and they
>  cannot both be installed at once. 
Checked with the team and I'm told 32-bit containers on 64-bit arch
should not be impacted.

HTH.

Thanks.
-- 
Lokesh
Libera, GitLab, GitHub, Fedora: lsm5
Matrix: @lsm5:lsm5.ems.host
GPG: 0xC7C3A0DD
https://keybase.io/lsm5

[Kevin Kofler]

Lokesh Mandvekar wrote:
>  Checked with the team and I'm told 32-bit containers on 64-bit
> arch
>  should not be impacted. 
Good to know. Then I think nobody will miss the i686 build or even notice 
its absence (considering that it is not a shared library and that pure i686 
installations of Fedora have not been supported for years now).

        Kevin Kofler

[Daniel P. Berrangé]

On Wed, Feb 08, 2023 at 07:17:16PM +0530, Lokesh Mandvekar wrote:
>  On Wed, Feb 8, 2023 at 9:01 AM Kevin Kofler via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
>  > Does dropping the 32-bit i686 build also imply you cannot use 32-bit
>  > containers on a 64-bit architecture? If so, will anybody notice? Since you
>  > did not use any special naming tricks (both package naming and file naming)
>  > to allow installing both versions (as in, e.g., wine), one has to go out of
>  > one's way to install the 32-bit version instead of the 64-bit one, and they
>  > cannot both be installed at once.
>  
>  Checked with the team and I'm told 32-bit containers on 64-bit arch
>  should not be impacted. 
More generally podman can run containers of foreign architectures using
qemu-user emulation, albeit with an obvious speed penalty. Still this
has been useful for testing issues on non-x86_64 arches where hardware
access is hard to come by.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Stephen Gallagher]

On Wed, Feb 8, 2023 at 9:35 AM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote:
...
>  > Checked with the team and I'm told 32-bit containers on
> 64-bit arch
>  > should not be impacted.
>
>  More generally podman can run containers of foreign architectures using
>  qemu-user emulation, albeit with an obvious speed penalty. Still this
>  has been useful for testing issues on non-x86_64 arches where hardware
>  access is hard to come by. 
Hold up, this is a really useful tip buried in this thread. Is there a
good howto or example of how to do this? This deserves a Fedora
Magazine or CommBlog article!

[Daniel P. Berrangé]

On Wed, Feb 08, 2023 at 09:43:19AM -0500, Stephen Gallagher wrote:
>  On Wed, Feb 8, 2023 at 9:35 AM Daniel P. Berrangé
> <berrange(a)redhat.com&gt; wrote:
>  ...
>  > > Checked with the team and I'm told 32-bit containers on 64-bit arch
>  > > should not be impacted.
>  >
>  > More generally podman can run containers of foreign architectures using
>  > qemu-user emulation, albeit with an obvious speed penalty. Still this
>  > has been useful for testing issues on non-x86_64 arches where hardware
>  > access is hard to come by.
>  
>  Hold up, this is a really useful tip buried in this thread. Is there a
>  good howto or example of how to do this? This deserves a Fedora
>  Magazine or CommBlog article! 
AFAIR, assuming you have 'qemu-user-static-XXXX' RPM installed for the
arch you need (which registers the binfmt handlers at boot), there is
not much more to it than passing '--arch $NAME' to 'podman run'

e.g. on my current x86_64 F37 host I can do

$ podman run -it --arch s390x fedora:rawhide
[root@89b49bd5fefd /]# uname -a
Linux 89b49bd5fefd 6.0.8-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 11 15:09:04 UTC
2022 s390x GNU/Linux
[root@89b49bd5fefd /]# uname -m
s390x

one caveat is that if you later run without --arch, I've seen it remember
pick the foreign arch container that's already downloaded, instead of
fetching the native arch container.

Also qemu-user emulation isn't perfect, so if you hit wierd inexplicable
behaviour, QEMU upstream will welcome bug reports...

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Daniel Walsh]

On 2/8/23 09:51, Daniel P. Berrangé wrote:
>  On Wed, Feb 08, 2023 at 09:43:19AM -0500, Stephen Gallagher wrote:
> > On Wed, Feb 8, 2023 at 9:35 AM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote:
> > ...
> >>> Checked with the team and I'm told 32-bit containers on 64-bit arch
> >>> should not be impacted.
> >> More generally podman can run containers of foreign architectures using
> >> qemu-user emulation, albeit with an obvious speed penalty. Still this
> >> has been useful for testing issues on non-x86_64 arches where hardware
> >> access is hard to come by.
> > Hold up, this is a really useful tip buried in this thread. Is there a
> > good howto or example of how to do this? This deserves a Fedora
> > Magazine or CommBlog article!
>  AFAIR, assuming you have 'qemu-user-static-XXXX' RPM installed for the
>  arch you need (which registers the binfmt handlers at boot), there is
>  not much more to it than passing '--arch $NAME' to 'podman run'
>
>  e.g. on my current x86_64 F37 host I can do
>
>  $ podman run -it --arch s390x fedora:rawhide
>  [root@89b49bd5fefd /]# uname -a
>  Linux 89b49bd5fefd 6.0.8-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov 11 15:09:04 UTC
> 2022 s390x GNU/Linux
>  [root@89b49bd5fefd /]# uname -m
>  s390x
>
>  one caveat is that if you later run without --arch, I've seen it remember
>  pick the foreign arch container that's already downloaded, instead of
>  fetching the native arch container.
>
>  Also qemu-user emulation isn't perfect, so if you hit wierd inexplicable
>  behaviour, QEMU upstream will welcome bug reports...
>
>  With regards,
>  Daniel 
Yes Podman picks the latest image of a particular name.  Many debates 
have happened on this, but this is the default.

running code for whatever arch (was: Re: Hoping to disable i686 and 32-bit arm for Podman and related tools for existing Fedora releases)

[Roberto Ragusa]

On 2/8/23 15:43, Stephen Gallagher wrote:

> > More generally podman can run containers of foreign architectures
> using
> > qemu-user emulation, albeit with an obvious speed penalty. Still this
> > has been useful for testing issues on non-x86_64 arches where hardware
> > access is hard to come by.
>  
>  Hold up, this is a really useful tip buried in this thread. Is there a
>  good howto or example of how to do this? This deserves a Fedora
>  Magazine or CommBlog article! 
Well, I was just left amazed just a couple of days ago when mounting the
microSD of my raspberry on Fedora.
The idea was to just fsck the filesystem, then I mounted it,
played a bit around and then realized that there might have been
updates available for some packages.
So, by habit more than thinking, I've just "chroot" into the
mounted filesystem and run "apt update; apt upgrade".
And while the commands were working I realized "wait a moment,
this is supposed to be arm code, but it is running fine!".
Quick "ps", wow, so they are using qemu transparently.
Don't tell me that they are supporting...
... yes they are.
An absolutely obscure gem feature deserving much more publicity.

# ls /proc/sys/fs/binfmt_misc/
kshcomp          qemu-hexagon       qemu-mips64     qemu-ppc      qemu-sh4         
qemu-xtensaeb
qemu-aarch64     qemu-hppa          qemu-mips64el   qemu-ppc64    qemu-sh4eb       
register
qemu-aarch64_be  qemu-m68k          qemu-mipsel     qemu-ppc64le  qemu-sparc       
status
qemu-alpha       qemu-microblaze    qemu-mipsn32    qemu-riscv32  qemu-sparc32plus 
windows
qemu-arm         qemu-microblazeel  qemu-mipsn32el  qemu-riscv64  qemu-sparc64     
windowsPE
qemu-armeb       qemu-mips          qemu-or1k       qemu-s390x    qemu-xtensa

Best regards.

-- 
    Roberto Ragusa    mail at robertoragusa.it