Package feed: i586 doesn't exist

[MagneFire]

Reported by @PureTryOut.

For some reason the i586 doesn't exist anymore on the nightly ipk path: https://release.asteroidos.org/nightlies/ipk/i586/

No idea what changed here, needs some investigation.

If it turns out that we simple don't need this anymore then we can remove that entry from https://github.com/AsteroidOS/meta-asteroid/blob/0187f0a1845a31f29747c64cf3ea07db040cb66c/conf/distro/asteroid.conf#L41.

[FlorentRevest]

I suppose that qemux86 probably upped its minimal x86 specs and it is no longer i586 or so.

I think we should just use an x86_64 qemu anyway...

[beroset]

I've verified that we don't need i586 any more. The qemux86 target is sufficient and runs just fine using x86_64. The currently recommended practice for QEMU is to use Host Passthrough so that the emulated machine is just like the real one underneath. Also, our emulator page has recently been updated to refer only to x86_64. If you build the qemux86 target now, it produces a target like this:

root@qemux86:~# uname -a
Linux qemux86 5.14.14-yocto-standard #1 SMP PREEMPT Sun Nov 14 20:00:51 UTC 2021 i686 GNU/Linux

[FlorentRevest]

Yes exactly, we use a 64bit emulator but build a 32bit image. Cf the i686 in the uname output.

Of course it works but I think it would be an improvement to just build a 64bit images. i686 is a relic from the past.

[beroset]

Is anyone using this on non-x86 platforms? I can imagine running qemu with this image on, say, a Raspberry Pi 4, but don't know if anyone is actually doing that. It seems like there are three related issues here:

1. the i586 package feed does not exist and is not needed -- can we just remove it and close this issue?
2. the qemu86 target could be built for x86_64 instead of i686 -- is there a benefit?
3. qemu targets for non-x86 machines -- do we need/want one?

What do you all think?

[MagneFire]

1. the i586 package feed does not exist and is not needed  -- can we just remove it and close this issue?

Agree on both. We should create a separate issue for the ones you point out below. One thing to check is if removing i586 will break updates on the emulator image. (Currently looking into this, but getting a black screen for both a x86 and x86_64 target).

2. the qemu86 target could be built for x86_64 instead of i686 -- is there a benefit?

Maybe? Like @FlorentRevest said. x86 is old bumping it to x86_64 is a logical move (might not be the best, I don't know).

3. qemu targets for non-x86 machines -- do we need/want one?

Maybe, in the past some people were asking for images for a Raspberry Pi. There are some additional layers that would need to be added (https://git.yoctoproject.org/meta-raspberrypi/about/ or https://github.com/agherzan/meta-raspberrypi).

But I agree that points 2 and 3 should be separate issues.

[beroset]

I've rebuilt it twice now. With i586 removed (it may as well be since there is no such directory!) it mostly works, but can't find some packages such as asteroid-2048.

 * opkg_prepare_url_for_install: Couldn't find anything to satisfy 'asteroid-2048'

In order to have parity with the other builds, we need to replace i586 with core2-32. Built that way, opkg can find and install asteroid-2048 from within the image, but with another problem:

root@qemux86:~# opkg install asteroid-2048
Installing asteroid-2048 (+git0+0aeb78c95d) on root
 * check_data_file_clashes: Package asteroid-2048 wants to install file /usr/share/icons/asteroid/2048.svg
    But that file is already provided by package  * asteroid-icons-ion
root@qemux86:~# opkg install --force-overwrite asteroid-2048
Installing asteroid-2048 (+git0+0aeb78c95d) on root

But that appears to be a packaging problem with asteroid-2048 rather than anything specifically to do with this issue.

[eLtMosen]

Is that maybe because the game has been renamed to diamonds some hours ago?

[beroset]

Is that maybe because the game has been renamed to diamonds some hours ago?

It's a good thought and I considered that, but it hasn't affected the nightly builds yet.

[MagneFire]

I've rebuilt it twice now. With i586 removed (it may as well be since there is no such directory!) it mostly works, but can't find some packages such as asteroid-2048.

 * opkg_prepare_url_for_install: Couldn't find anything to satisfy 'asteroid-2048'

In order to have parity with the other builds, we need to replace i586 with core2-32. Built that way, opkg can find and install asteroid-2048 from within the image, but with another problem:

root@qemux86:~# opkg install asteroid-2048
Installing asteroid-2048 (+git0+0aeb78c95d) on root
 * check_data_file_clashes: Package asteroid-2048 wants to install file /usr/share/icons/asteroid/2048.svg
  But that file is already provided by package  * asteroid-icons-ion
root@qemux86:~# opkg install --force-overwrite asteroid-2048
Installing asteroid-2048 (+git0+0aeb78c95d) on root

But that appears to be a packaging problem with asteroid-2048 rather than anything specifically to do with this issue.

asteroid-2048 has been removed from the community repo and is in the process of being merged as asteroid-diamonds.

Meanwhile the 2048 icon has been added to our icon set and removed from asteroid-diamonds. It's likely that asteroid-2048 is an artifact from the nightly server and needs to be removed manually.

Not exactly sure why you get two different errors though...

[beroset]

I've done some more digging and found this: https://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#x32 In part, it says "Executing under the x32 psABI enables user programs to utilize CPU and system resources more efficiently while keeping the memory footprint of the applications low. Extra bits are used for registers but not for addressing mechanisms." For that reason, I believe that using core2-32 is a better choice than replacing with x86-64.

[MagneFire]

As of https://github.com/AsteroidOS/meta-asteroid/pull/82 this has been fixed. Thanks @beroset for your investigation into this issue :+1: