Avoid spurious libgcc-s1 Debian package dependency

[tautschnig]

Marked as Draft (and do-not-merge, do-not-review), includes extra debug output.

Do not add a strict dependency on gcc, which in a GitHub container isn't
necessarily the same version as in a pristine Ubuntu system.

Fixes: #5875

• Each commit message has a non-empty body, explaining why the change was made.
• n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• n/a My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[codecov]

Codecov Report

Merging #5877 (7f213db) into develop (6779f39) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop    #5877   +/-   ##
========================================
  Coverage    72.90%   72.90%           
========================================
  Files         1425     1425           
  Lines       154282   154282           
========================================
  Hits        112485   112485           
  Misses       41797    41797           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7f998c4...8514130. Read the comment docs.

[hannes-steffenhagen-diffblue]

Huh, that seems screwy? So the github actions ubuntu-18.04 container isn't necessarily actually ubuntu-18.04?

[hannes-steffenhagen-diffblue]

For curiosities sake, how did you detemine this was the issue?

[kroening]

The cleaner answer here could be do build that package in a docker container (Github actions does this). The problem with the proposed tweak is that Github may well choose to make further changes to their standard image, and then the issue is back.

[hannes-steffenhagen-diffblue]

@tautschnig Following @kroening's comment here, I believe the correct thing to do would be to specify this running on the ubuntu:18.04 docker image via the container attribute, then we don't have to remove packages which seems slightly sketchy anyway.

TBH I didn't realise that the actions images had so much nonstandard stuff in them when we came up with these actions.

[tautschnig]

@tautschnig Following @kroening's comment here, I believe the correct thing to do would be to specify this running on the ubuntu:18.04 docker image via the container attribute, then we don't have to remove packages which seems slightly sketchy anyway.
[...]

I tried this avenue, but then our use of submodules requires git 2.18, which isn't in Ubuntu 18.04. Thus sticking with the force-downgrade option for now. Marking the PR as ready-for-review as the logs confirmed that libgcc-s1 no longer is among the dependencies being generated.

[NlightNFotis]

LGTM

[thomasspriggs]

@tautschnig Following @kroening's comment here, I believe the correct thing to do would be to specify this running on the ubuntu:18.04 docker image via the container attribute, then we don't have to remove packages which seems slightly sketchy anyway.
[...]

I tried this avenue, but then our use of submodules requires git 2.18, which isn't in Ubuntu 18.04. Thus sticking with the force-downgrade option for now. Marking the PR as ready-for-review as the logs confirmed that libgcc-s1 no longer is among the dependencies being generated.

Can you further explain what aspects of submodules aren't working with git 2.17? I am using ubuntu 18.04 locally and I haven't seen any submodule related issues.

[tautschnig]

@tautschnig Following @kroening's comment here, I believe the correct thing to do would be to specify this running on the ubuntu:18.04 docker image via the container attribute, then we don't have to remove packages which seems slightly sketchy anyway.
[...]

I tried this avenue, but then our use of submodules requires git 2.18, which isn't in Ubuntu 18.04. Thus sticking with the force-downgrade option for now. Marking the PR as ready-for-review as the logs confirmed that libgcc-s1 no longer is among the dependencies being generated.

Can you further explain what aspects of submodules aren't working with git 2.17? I am using ubuntu 18.04 locally and I haven't seen any submodule related issues.

See https://github.com/diffblue/cbmc/runs/2021105147 for one of the past logs. That says:

The repository will be downloaded using the GitHub REST API
To create a local Git repository instead, add Git 2.18 or higher to the PATH
Error: Input 'submodules' not supported when falling back to download using the GitHub REST API. To create a local Git repository instead, add Git 2.18 or higher to the PATH.

[hannes-steffenhagen-diffblue]

@tautschnig That seems like an issue with the github action we use for fetching the code. I don't think that's a real blocker for building on 18.04 proper, worst case we can just work around that.

[tautschnig]

@tautschnig That seems like an issue with the github action we use for fetching the code. I don't think that's a real blocker for building on 18.04 proper, worst case we can just work around that.

Up to you. Can I suggest we put a fix in place before merging #5883 today? This might be merging this PR and doing a cleaner solution later on, or someone making the container solution work today.

[hannes-steffenhagen-diffblue]

@tautschnig seems good to me, plan is to merge this and put building in docker in the mid-term