Ticket #1152 (closed defect: worksforme)

Opened 5 years ago

Last modified 5 years ago

openmoko-terminal2 is missing vala dependancy

Reported by: thomas@… Owned by: mickey@…
Priority: high Milestone:
Component: OE bitbake recipes / build system Version: unspecified
Severity: normal Keywords:
Cc: buglog@…, graeme@…, john_lee@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: PatchReviewResult:
Reproducible:

Description

openmoko-terminal2 was recently rewritten and now depends on vala. However, the
bitbake recipie does not ensure that vala is available.

Change History

comment:1 Changed 5 years ago by thomas@…

Furthermore, it seems vala-native cannot be built due to missing glib-native-2.0
dependency:

ERROR: No buildable providers available for required build target vala-native
('glib-native-2.0?')

comment:2 Changed 5 years ago by mickey@…

  • Status changed from new to closed
  • Resolution set to worksforme

If you are building from monotone.openmoko.org, please always check whether this
has been fixed in the meantime in org.openembedded.dev.

comment:3 Changed 5 years ago by thomas@…

As I was trying to report a problem with monotone.openmoko.org, should I use a
different bugzilla component?

comment:4 Changed 5 years ago by mickey@…

  • Cc john_lee@…, graeme@… added

Good question -- John and Graeme, what's your opinion on that?

comment:5 Changed 5 years ago by john_lee@…

2 situations I could think of should be reported here at OM bugzilla:

  1. bugs introduced by modifications only on OM mtn.
  2. OM mtn cannot build on a particular system.
  3. (please add if I missed)

The rest should be directed to OE and get fixed there.

Including moko-autorev.inc often introduces new revs that depend on the later
version of OE. These problems will be fixed on next sync and personnally I
won't fix them between syncs.

comment:6 Changed 5 years ago by thomas@…

So basically, I should not be using monotone.openmoko.org for development work?

comment:7 Changed 5 years ago by graeme@…

If monotone.om.org tree doesnt build then bug should be reported here. John can
then investigate and esculate to bugs.oe.org if it turns out failure is from OE
upstream.

Bugs against mtn.om.org should be rare as the build is checked before update.

So Thomas you should be using mtn.om.org for app development.

comment:8 Changed 5 years ago by john_lee@…

If we want to use OM mtn for development, the policy should be clear that ALL OM
related packages cannot commit code that depends on upstream OE instead of OM
mtn. There's no way we could maintain a stable daily build if we keep changing
the outside dependency.

Note: See TracTickets for help on using tickets.