sdk build failures with cargo since v1967.0.0

[Dongsu Park]

Hi, I'm maintainer of Flatcar Linux <https://flatcar-linux.org>.

I'm aware that it's coreos-dev list. Though since Flatcar Linux is

a fork of Container Linux, I'm pretty sure some of you could have

some idea about my issue.

Recently I started seeing strange build issues since v1967.0.0.

A typical error happens during builds of Flatcar SDK like below:

  >>> Emerging (1 of 1) sys-apps/portage-2.3.40-r1::coreos
  >>> Installing (1 of 1) sys-apps/portage-2.3.40-r1::coreos
  Updating seed stage...
  emerge --quiet --update --deep --newuse --complete-graph --rebuild-if-new-ver gcc

  emerge: there are no ebuilds to satisfy "dev-util/cargo:0".

I suppose, it started to occur since the PR

https://github.com/coreos/coreos-overlay/pull/3458 was merged.

The description looks fine. Since there's no need to keep

coreos-cargo any more, all rust-related packages were moved to

portage-stable instead. That makes a perfect sense.

Following the principle, I made both coreos-overlay and

portage-stable in sync with upstream coreos repos.

Nevertheless I'm still seeing the ebuilds error during SDK builds.

Does anyone have an idea, how I can fix (or workaround) the issue?

Thanks,

Dongsu

[David Michael]

On Tue, Dec 18, 2018 at 5:14 PM Dongsu Park <don...@kinvolk.io> wrote:
>
> Hi, I'm maintainer of Flatcar Linux <https://flatcar-linux.org>.
> I'm aware that it's coreos-dev list. Though since Flatcar Linux is
> a fork of Container Linux, I'm pretty sure some of you could have
> some idea about my issue.
>
> Recently I started seeing strange build issues since v1967.0.0.
> A typical error happens during builds of Flatcar SDK like below:
>
> >>> Emerging (1 of 1) sys-apps/portage-2.3.40-r1::coreos
> >>> Installing (1 of 1) sys-apps/portage-2.3.40-r1::coreos
> Updating seed stage...
> emerge --quiet --update --deep --newuse --complete-graph --rebuild-if-new-ver gcc
>
> emerge: there are no ebuilds to satisfy "dev-util/cargo:0".
>
> I suppose, it started to occur since the PR
> https://github.com/coreos/coreos-overlay/pull/3458 was merged.
> The description looks fine. Since there's no need to keep
> coreos-cargo any more, all rust-related packages were moved to
> portage-stable instead. That makes a perfect sense.

I think it was actually caused by this PR:
https://github.com/coreos/portage-stable/pull/699

> Following the principle, I made both coreos-overlay and
> portage-stable in sync with upstream coreos repos.
> Nevertheless I'm still seeing the ebuilds error during SDK builds.
>
> Does anyone have an idea, how I can fix (or workaround) the issue?

Did you pull in this commit in scripts?
https://github.com/coreos/scripts/commit/fceffdb6601d146fd20adb8528a954c614822ccf

I think Gentoo has since fixed the issue upstream, too, so you might
be able to sync portage-stable eclasses instead to fix it.

Thanks.

David

[David Michael]

Oh, and since your build failure seems to be happening during the seed
update, you can apply this commit to work around it as well:
https://github.com/coreos/scripts/commit/373d5a814ba7b4ecba181ad37b8b4c8b98bd0402

You should be able to revert that again once you've produced a new SDK
without the cargo package in it.

Thanks.

David

[Dongsu Park]

Hi David,

That commit was already in flatcar-linux/coreos-overlay,

but not in the SDK v1953.0.0 that was actually used by our builds.

> I think Gentoo has since fixed the issue upstream, too, so you might

> be able to sync portage-stable eclasses instead to fix it.

Oh, and since your build failure seems to be happening during the seed
update, you can apply this commit to work around it as well:
https://github.com/coreos/scripts/commit/373d5a814ba7b4ecba181ad37b8b4c8b98bd0402

Yes, that did the trick.

I commented out the line "update_seed: yes", rebuilt the SDK v1981.0.0.

Then the SDK build succeeded, the build issue was gone.

I see how I can get other builds working as well, based on the SDK tarball.

Thanks a lot! :-)

Dongsu