Skip to content
Snippets Groups Projects
  1. Sep 14, 2023
  2. Sep 11, 2023
  3. Sep 08, 2023
    • GitBot's avatar
      Integrate gitlab-ci/remove-release-name-from-deploy-target and 10 more · a282c3f6
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@f2a29f53
      
      Refactoring: remove RELEASE_NAME from deploy targets
      
      Append it to the configured target at the deploy class level instead.
      This removes the need for eval'ing the variables before usage.
      RELEASE_NAME can be used directly at the class level because it is known
      from build-version.env.
      
      This makes the deploy behavior identical to the Azure stage.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@e136e5e2
      
      Remove top-level "release" folder from package
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@1d5e479f
      
      Define MACHINE variable on job level
      
      Instead of passing MACHINE from stage to stage or loading it from
      testdata.json, use the original value from the Jinja2 loop and set it
      directly for each job where it is used.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@cdd47023
      
      Introduce separate variables to set RELEASE_NAME and RELEASE_VERSION
      
      The expressions to calculate RELEASE_NAME and RELEASE_VERSION cannot be
      stored within these variables themseselves. If set on the trigger level,
      they would override the calculated values in build-version.env then,
      as trigger variables always have the highest precedence.
      
      Use separate variables RELEASE_VERSION_EXPRESSION and
      RELEASE_NAME_EXPRESSION to define how RELEASE_VERSION and RELEASE_NAME
      are calculated instead.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@372d192b
      
      Use RELEASE_VERSION and RELEASE_NAME from build-version job
      
      Instead of passing these variables from stage to stage or regenerating
      their values in later stages, use the ones set in the build-version job
      at all places.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@cad30c20
      
      Remove RELEASE_SUFFIX variable
      
      The RELEASE_NAME variable can be set directly now, so there's no need to
      have a dedicated RELEASE_SUFFIX anymore. A previous configuration like
      
        RELEASE_SUFFIX: "-custom"
      
      can now be achieved using:
      
        RELEASE_NAME: "Yocto-${RELEASE_VERSION}-custom"
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@922f49f8
      
      Add yocto version job
      
      This adds a machine-independent job "build-version" which populates the
      RELEASE_VERSION and RELEASE_NAME variables, so that following jobs can
      use these without depending on the various build jobs.
      The variables can be set from the trigger job in a project's
      `.gitlab-ci.yml` file. They are eval'ed before saving them to
      version.env, so we can use deferred variable expansion or even command
      execution to construct their values. This mechanism is already used for
      the Flash-N-Go System variables.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@073ae81e
      
      LAVA: rename MACHINE to LAVA_MACHINE
      
      Rename variable in order to avoid confusion with the original MACHINE
      variable used everywhere else. Also rename the local Jinja2 variable to
      include an underscore to make naming consistent.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@a91baa55
      
      Clean build.env before writing
      
      This had been accidentally removed in
      5e36715ef6cf98df4c1b98fedddc0c3c50ed4040.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@1860ca8e
      
      Remove LOG_PREFIX variable
      
      This was used in times when the same code was executed from different
      places. We don't do that anymore, so the variable is obsolete.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@3d2dbe4d
      
      Documentation: update job generation chapter
      a282c3f6
  4. Sep 04, 2023
  5. Aug 31, 2023
    • Felix Gerking's avatar
      utils:mxt-app: Improve config parser · fe3b93c4
      Felix Gerking authored
      Config files generated with maXTouchStudio contain a FILE_INFO_HEADER
      section that was not handled correctly by the mxt-app parser.
      Add this section to the skipped sections.
      fe3b93c4
  6. Aug 30, 2023
  7. Aug 29, 2023
  8. Aug 28, 2023
  9. Aug 24, 2023
  10. Aug 23, 2023
    • Dmitry Petrov's avatar
      uuu: update scripts for mx6 boards · 46e834f3
      Dmitry Petrov authored and Jonas Höppner's avatar Jonas Höppner committed
      The current uuu script (uuu.lst) doesn't work for mx6 devices.
      
      Restore previously used script and:
      * make it more flexible by adding input arguments
      * remove "write" commands for unused components (dtb and modules)
      
      Also updated .bat and .sh wrappers to generate fng-boot boot script
      and combined linux image (kernel + dtb).
      46e834f3
  11. Aug 22, 2023
  12. Aug 21, 2023
  13. Aug 16, 2023
  14. Aug 11, 2023
  15. Aug 09, 2023
    • Jonas Höppner's avatar
      fng-install: Remove from distro layer · e79e8579
      Jonas Höppner authored
      - Removed recipes
      - Removed references in the DISTRO, the files are now included via a new
        variable called MACHINE_INSTALL_SCRIPTS that is added to the
        DISTRO_INSTALL_SCRIPTS to keep the rest of the chain untouched.
        MACHINE_INSTALL_SCRIPTS is set in the machine layer if needed.
      e79e8579
  16. Aug 07, 2023
  17. Aug 04, 2023
  18. Aug 01, 2023
  19. Jul 27, 2023
    • GitBot's avatar
      Integrate gitlab-ci/separate-images-in-multiple-pipelines and 1 more · 1baf144b
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@9406ad75
      
      Yocto build: separate images in multiple pipelines
      
      Instead of building the Yocto image, the Yocto SDK and the FNGSystem
      image in one single pipeline, separate them into three independent
      pipelines that are triggered in parallel.
      
      This makes the concept more modular: we have a single general pipeline
      now which is configurable from outside via variables. Hence we can have
      a custom number of pipelines along with custom build targets in each
      project without having to make code changes in the gitlab-ci project.
      
      The default Yocto manifest pipeline configures three build pipelines:
      
      - yocto-build-jobs
      - sdk-build-jobs
      - fngsystem-build-jobs
      
      In a project including the Yocto manifest pipeline, we can disable
      certain build pipelines using job rules, e.g. disabling the SDK build:
      
      sdk-build-jobs:
        rules:
          - when: never
      
      Furthermore we can add more pipelines by simply adding jobs extending
      the '.build-jobs' class in the project's .gitlab-ci.yml:
      
      yocto-custom-build-jobs:
        extends:
          - .build-jobs
        variables:
          BITBAKE_TASK: build
          CI_PARAM_IMAGE: custom-image
          CI_PARAM_DISTRO: custom-distro
          PACKAGE_TYPE: image
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@447804d2
      
      .gitlab-ci: increase analyze timeout
      1baf144b
  20. Jul 25, 2023
    • GitBot's avatar
      Integrate gitlab-ci/unify-image-and-sdk-package-jobs and 3 more · 949497cf
      GitBot authored
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@5762a54c
      
      Yocto build: unify image and SDK package jobs
      
      Image and SDK package jobs call the same package script just with
      different arguments. Instead of having two job classes `package_release`
      and `package_sdk` for these two tasks, merge them into the base class
      `package` and make the differences configurable via a variable
      `PACKAGE_TYPE`.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@8e72eac2
      
      Yocto build: add variable for manual builds
      
      Instead of hard-coding the rules for manual builds in each actual job,
      conditionally add this to the `buildbase` class and add a variable
      `MANUAL_BUILD` to the according jobs.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@e6d71996
      
      Yocto build: unify image and SDK build jobs
      
      Image and SDK builds share a lot of similar code. Instead of having two
      job classes `build_yocto_image` and `build_yocto_sdk` for these two
      tasks, merge them into the base class `build_yocto` and make the
      differences configurable via a variable.
      
      The `dump_install_command` part of the script, which was not executed
      for SDK builds, is always present now, but it's only executed if the
      `INSTALLSCRIPT` variable is set, which is not the case for SDK builds.
      
      The `collect_srcrevs` part of the script is executed in all cases. It
      was not part of the SDK build before, but it's not less relevant there.
      
      --
      
      Commit: seco-ne/yocto/infrastructure/gitlab-ci@f892500f
      
      Yocto build: make main artifacts path configurable
      
      Instead of specifying all possible artifacts paths and abusing the fact
      that GitLab ignores non-existing paths during artifact upload, implement
      a cleaner solution with a configurable path.
      949497cf
  21. Jul 24, 2023
  22. Jul 14, 2023
    • Dmitry Petrov's avatar
      wlvncc: wayland vnc client · 4354d3dc
      Dmitry Petrov authored
      The package depends on gbm which is not supported for seco-mx6-fsl
      machine. See commit 4420f4fa ("qtbase: Remove gbm packageconfig_distro
      option for seco-mx6-fsl machine").
      
      Also the package depends on libavcodec provided by ffmpeg. It requires
      to accept the commercial license. The following line should be added to
      local.conf:
      LICENSE_FLAGS_ACCEPTED = "commercial_ffmpeg"
      4354d3dc
  23. Jul 12, 2023
  24. Jul 06, 2023
  25. Jun 27, 2023
    • Felix Gerking's avatar
      fng-install: Allow installation from user partition · 0859b233
      Felix Gerking authored
      If the --files-on-target flag is set, the partition where the installation
      files are stored remains mounted during the installation. The partition
      from which to install cannot be a target partition for the installation.
      Since the partition table cannot be changed safely, the --reuse-partition
      option is implied.
      
      BCS 746-001239
      0859b233
  26. Jun 23, 2023
  27. Jun 22, 2023
  28. Jun 20, 2023
Loading