Skip to content
This repository has been archived by the owner on May 28, 2023. It is now read-only.

Houston CI fails if project uses Meson subprojects feature #779

Open
1 task done
stsdc opened this issue Apr 10, 2020 · 2 comments
Open
1 task done

Houston CI fails if project uses Meson subprojects feature #779

stsdc opened this issue Apr 10, 2020 · 2 comments

Comments

@stsdc
Copy link
Member

stsdc commented Apr 10, 2020

Prerequisites

  • I have searched open and closed issues for duplicates.

Describe the bug

I'm using a Meson's subprojects feature, where special *.wrap files are created and Mesons uses them to download dependencies that are unavailable in system packages.
I'm using this feature to built Monitor with live-chart library. But CI fails with:

meson.build:15:0: ERROR:  Failed to initialize 'subprojects/live-chart':
Automatic wrap-based subproject downloading is disabled

dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

To Reproduce

Use Meson subprojects feature with wrap files.

Expected behavior

Wrap files are recognized and Meson downloads subprojects.

Logs

Logs on Travis CI.

@davidmhewitt
Copy link
Member

davidmhewitt commented Apr 14, 2020

The Houston build environment does not allow downloading things from random places on the internet for security reasons. Anything you need to build the project has to be in your GitHub repository, or available in the apt software repositories for the version of elementary you're building against.

@hannesschulze
Copy link

Hi there,

I would really appreciate the ability to use meson subprojects in elementary apps. I am currently working on three projects, all using subprojects and all of them have different use cases:

  • Optimizer is currently using subprojects for detecting GPU usage. It is therefore using two different libraries (currently for AMD and Nvidia cards) depending on which one is available. I do not want to include this source code in the main repo because it is not really what Optimizer is doing. These projects are forks and they may be updated in order to follow upstream
  • I have a more complex (currently private) project which is made up of a more abstract library basically providing a full framework used by the app. I'm not even near the first release and this lib already has > 300 source files, so I would really like to keep them separated
  • This project and also Conecto (which I also might want to release in the near future) are written in C++. I've always been using Google Test for my unit tests in C++ projects, which is commonly included as a submodule and also available in meson's wrapdb.

So I think that this restriction might keep some more complex projects which do not want to have everything in their main repo from publishing their apps in App Center.

The Houston build environment does not allow downloading things from random places on the internet for security reasons

From a security perspective, the apps would still have to be reviewed on release. The releases only represent a snapshot of the code so subprojects could be reviewed beforehand, right? Would it be possible to check that subprojects are pulling from a specified tag and prevent them from pulling everything that is currently on master?

Anything you need to build the project has to be in your GitHub repository, or available in the apt software repositories for the version of elementary you're building against.

As you can see in elementary/monitor#164 it is still possible to use Git submodules, so from what I'm seeing, there is no actual security advantage in disabling downloading meson subprojects.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants