Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot build +gnome variant for Debian #4286

Closed
unman opened this issue Sep 7, 2018 · 11 comments
Closed

Cannot build +gnome variant for Debian #4286

unman opened this issue Sep 7, 2018 · 11 comments
Labels
C: builder Qubes Builder C: Debian/Ubuntu T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.

Comments

@unman
Copy link
Member

unman commented Sep 7, 2018

Qubes OS version:

R4.0

Affected component(s):

Qubes Builder


Steps to reproduce the behavior:

Select stretch+gnome from builder setup.
Build Template

Expected behavior:

Template will contain gnome applications

Actual behavior:

Template seems identical to basic Stretch template.
No extended Gnome applications included.

General notes:

Tried build following discussion in #4195 and #1781


Related issues:

@marmarek
Copy link
Member

marmarek commented Sep 7, 2018

I think it relies on TEMPLATE_FLAVOR_DIR += +gnome:$$SCRIPTSDIR/gnome in builder.conf

Do you have it?

@unman
Copy link
Member Author

unman commented Sep 7, 2018

yes indeed, it's a clean builder environment.

@marmarek
Copy link
Member

marmarek commented Sep 7, 2018

make build-info reports stretch+gnome+standard, not sure if that a problem. Do you have full build log?

@marmarek
Copy link
Member

marmarek commented Sep 7, 2018

TEMPLATE_FLAVOR_DIR is broken. If you look at the process list during the build, you'll find sudo env -i ... TEMPLATE_FLAVOR_DIR=+gnome:CRIPTSDIR/gnome .... $S is missing, or actually, expanded $SCRIPTSDIR. Adding more dollars doesn't help (TEMPLATE_FLAVOR_DIR=+gnome:/gnome).

Ideas welcome. It's about Makefile in linux-template-builder.

@unman
Copy link
Member Author

unman commented Sep 12, 2018

I've had a quick look at this, and it seems as if it would affect any variant build.

There seem to be two issues:
First, we need "$$$$" in builder.conf so that we get $SCRIPTSDIR in template_builder. (That seems to be derived from examples/templates.conf.)
Second, as far as I can see, SCRIPTSDIR is never set, so even if the variable is correctly referenced in template-builder, it drops out at the build stage.

From the docs it looks as if SCRIPTSDIR should be retained as well as TEMPLATE_SCRIPTS set in Makefile.builder (BuilderPluginAPI refers).

I've put in two PRs to fix this.

@marmarek
Copy link
Member

The sole purpose of $TEMPLATE_SCRIPTS is to have less ambiguous name for BuilderPluginAPI. But internally everything use $SCRIPTSDIR. Maybe we should deprecate the later and use $TEMPLATE_SCRIPTS everywhere?
Or at least in templates.conf (then exporting SCRIPTSDIR should be unnecessary).

@unman
Copy link
Member Author

unman commented Sep 18, 2018

We need to have the (ugly) $$$$ because we want $TEMPLATE_SCRIPTS in linux-template-builder Makefile.
This, combined with exporting TEMPLATE_FLAVOR_DIR would do it.
An alternative would be to explicitly set SCRIPTSDIR at an early stage, so the variable is deferenced and remove the overwrite in linux_template_builder.

@marmarek
Copy link
Member

We need to have the (ugly) $$$$ because we want $TEMPLATE_SCRIPTS in linux-template-builder Makefile.

Ok, lets do this, instead of $SCRIPTSDIR there. Later we may fix it some better way. Could you update QubesOS/qubes-builder#62?

@unman
Copy link
Member Author

unman commented Sep 18, 2018

Done

@marmarek
Copy link
Member

marmarek commented Oct 2, 2018

Does it work now? @unman

@unman
Copy link
Member Author

unman commented Oct 3, 2018

All good.
Closing now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: builder Qubes Builder C: Debian/Ubuntu T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists.
Projects
None yet
Development

No branches or pull requests

3 participants