search

maruos / blueprints

Container builder for Maru OS.
Apache License 2.0
15 stars 12 forks source link

Move to latest Debian release 'buster' #19

Closed pdsouza closed 3 years ago

pdsouza commented 5 years ago

Buster has been released and we should upgrade from stretch ASAP.

Press release: https://lists.debian.org/debian-announce/2019/msg00003.html Overview of new stuff: https://wiki.debian.org/NewInBuster Complete release notes: https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html

utzcoz commented 4 years ago

Hi @pdsouza , can we plan to merge buster building to main branch? @pintaf builds it and runs it to its porting maru-0.7. There are no response from other maintainers, maybe we can build two versions, one with stretch, one with buster, and provide them to user for testing.

pdsouza commented 4 years ago

@pintaf Thanks for the feedback! As @utzcoz mentioned, I will be merging this to master soon. @utzcoz Yes, sounds good. Thank you for reminding me about this! I am going to do some much needed maintenance this weekend on maru-0.6 (I need to merge in some updates from LineageOS that's breaking our build) and I will also take care of merging buster building as well.

And thanks everyone for your patience on this taking forever, I have been swamped with other work lately. But I should be able to get everything fixed up this weekend.

pdsouza commented 4 years ago

Alright I've merged in @utzcoz's dual Dockerfile approach to master. I just built and ran an armhf buster container on my Nexus 5 and it appears that things are still working normally like when I tested it last time. The next official release will include buster containers by default. We can always revert back to stretch if needed.

If there are no other concerns I will close this issue in a few days.

pdsouza commented 4 years ago

Looks like Travis CI still fails to build arm64 buster containers: https://travis-ci.org/github/maruos/blueprints/jobs/725457381#L4377.

They build fine on my desktop though.

utzcoz commented 4 years ago

@pdsouza Looks like it is a qemu simulation problem of travis. Maybe we can try multiarch.

utzcoz commented 4 years ago

A very strange phenomenon, if I run arm64 building firstly, it will success. But armhf building will fail. @pdsouza I create a new pr to fix it with splitting building with two travis instances.

pdsouza commented 4 years ago

@utzcoz Thank you for looking into this so quickly! I also noticed that if I build the other way, i.e. arm64 first and then armhf, that if I first mount binfmt_misc with 64-bit qemu-user-static and then run the Dockerfile.armhf build, I get the same curl error I was getting before. I have a feeling that we must unmount and remount binfmt_misc between builds of different architectures. Maybe the kernel is caching the qemu-user-static binary file descriptor between builds, and it continues to use the first binary loaded somehow. This is just a guess though, I haven't tried remounting yet.

Either way, using separate travis instances is a good solution!

github-actions[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.