1. 15 Nov, 2021 1 commit
  2. 15 Oct, 2021 4 commits
  3. 11 Oct, 2021 1 commit
  4. 04 Oct, 2021 1 commit
  5. 15 Sep, 2021 1 commit
  6. 31 Aug, 2021 1 commit
    • Walter Lozano's avatar
      Use simple yml style · f874bb69
      Walter Lozano authored and Emanuele Aina's avatar Emanuele Aina committed
      
      
      In order to avoid issues with scan-copyrights not dealing with !!bool in
      yaml files, switch to a simpler format.
      
      This kind of issue was seen in packages that ship their own configuration
      in d/fill.copyright.blanks.yml, and uses the skip (boolean) option,
      which triggers an error an prevents the pipeline to succeed.
      
      As the issue seems to be an upstream bug, as a workaround change the
      default_style used by yaml dumper from | to the default one, which
      does not add !!bool.
      
      Previously the default_style | was needed as scan-copyright used
      YAML::Tiny and it was not able to parse the files properly, however,
      after switching to YAML::XS this doesn't seem to be an issue any more,
      so default_style can be used with its default.
      Signed-off-by: Walter Lozano's avatarWalter Lozano <walter.lozano@collabora.com>
      f874bb69
  7. 23 Aug, 2021 1 commit
  8. 18 Aug, 2021 1 commit
  9. 30 Jul, 2021 1 commit
  10. 26 Jul, 2021 1 commit
    • Emanuele Aina's avatar
      pkg-merge-upstream-to-downstreams: Python 3.7 (v2021) compatibility · 00290d35
      Emanuele Aina authored
      
      
      Try to be compatible tiwh Python 3.7 as shipped in Buster so the tool
      can work on projects where the default branch points to v2021, either
      because it's been dropped from v2022 or because it's a downstream that
      has not started mirroring v2022 yet.
      
            File "/usr/bin/apertis-pkg-merge-upstream-to-downstreams", line 65, in ensure_downstream_branch
              project_id = urllib.parse.quote(url.path.strip("/").removesuffix(".git"), safe="")
          AttributeError: 'str' object has no attribute 'removesuffix'
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      00290d35
  11. 22 Jul, 2021 4 commits
  12. 14 Jul, 2021 1 commit
  13. 13 Jul, 2021 2 commits
    • Emanuele Aina's avatar
      pkg-merge-upstream-to-downstreams: Ensure the target branch exist · 86604333
      Emanuele Aina authored
      
      
      When pulling an update for a stable branch it should target a `-updates`
      or `-security` branch. However there's no guarantee that they exist, so
      the creaton of the merge may fail:
      
          remote:              WARNINGS: Error encountered with push options
          remote:       'merge_request.create' 'merge_request.remove_source_branch'
          remote:              'merge_request.target=apertis/v2021-security'
          remote:       'merge_request.title=Update from debian/buster-security for
          remote:     apertis/v2021-security': Branch apertis/v2021-security does not
          remote:                                  exist
      
      To avoid that, ensure to push the target branch before creating the MR.
      
      Unfortunately we can't simply use `git push` as the creation of
      protected branches is restricted to the Web UI and the API, so let's use
      the latter, even if it requires a bit of juggling.
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      86604333
    • Emanuele Aina's avatar
      pkg-merge-upstream-to-downstreams: Flush before suprocesses · f863f4ae
      Emanuele Aina authored
      
      
      To ensure the correct ordering of the output, flush stdout before
      launching suprocesses.
      
      This prevents the output of `apertis-pkg-merge-upstream-to-downstreams`
      from being printed much after the output of the suprocess when not
      running on a tty, like when piped to `less` or when being run in the CI.
      While it would be normally expected that the output of the merge follows
      the `Attempt merging` message, in practice it would be displayed
      immediately as it came from a suprocess, while the output of the program
      would be buffered until much later.
      
      Add some flushes to correctly handover the output buffering.
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      f863f4ae
  14. 23 Jun, 2021 2 commits
  15. 18 Jun, 2021 2 commits
  16. 08 Jun, 2021 1 commit
  17. 07 Jun, 2021 2 commits
  18. 04 Jun, 2021 2 commits
    • Ariel D'Alessandro's avatar
      ci-license-scan: Manually check whitelisted files · a51aa6de
      Ariel D'Alessandro authored
      Files whitelisted in debian/apertis/copyright.whitelist are used to
      instruct the scanner process not to raise an error which allows the
      pipeline to succeed and merge the change. However, as a side effect, the
      entries in debian/apertis/copyright with offending licenses are being
      removed, dropping important information.
      
      BOM generator for Apertis binary packages needs the whole information.
      scan-copyright scanner must be called without a whitelist, so the
      pipeline keeps license information for all the present files in the
      source package.
      
      This MR adapts ci-license-scan script to generate license information
      for all the files, without failing on whitelisted offending ones.
      
      Link: https://phabricator.apertis.org/T7878
      
      Signed-off-by: Ariel D'Alessandro's avatarAriel D'Alessandro <ariel.dalessandro@collabora.com>
      a51aa6de
    • Ariel D'Alessandro's avatar
      ci-license-scan: Make "\./" path prefix optional in git patterns · fd3df13c
      Ariel D'Alessandro authored
      
      
      Currently, gitpattern2re is used to convert gitignore patterns to the
      Dpkg::Copyright::Scanner-compatible format. As noted in the code, that
      requires to prepend ^\./, not just ^.
      
      In order to manually match filename regex to those git patterns, that
      prefix must be optional, as the file path from the copyright entry might
      not have it.
      Signed-off-by: Ariel D'Alessandro's avatarAriel D'Alessandro <ariel.dalessandro@collabora.com>
      fd3df13c
  19. 26 May, 2021 1 commit
  20. 19 May, 2021 1 commit
  21. 18 May, 2021 1 commit
    • Emanuele Aina's avatar
      Change default downstream packaging suffix to `+apertisX` · 39794050
      Emanuele Aina authored
      
      
      We moved from `coX` to `apertisX` as the packaging suffix but
      unfortunately it turned out to interact badly with the build suffix on
      OBS in some scenarios:
      
      1. `bluez` in Debian has the `5.55-3` version
      2. it gets uploaded to OBS with no changes, forgetting to add the
         `apertisX` suffix
      3. OBS appends the build suffix, generating binaries with version
         `5.55-3bv2022dev2b1`
      4. we update `bluez` appending the `apertisX` suffix, yielding
         `5.55-3apertis1`
      5. OBS appends the build suffix, generating binaries with version
         `5.55-3apertis1bv2022dev2b1`
      6. reprepro gets the new binaries from OBS but the ordering is now wrong
         since `5.55-3apertis1bv2022dev2b1` < `5.55-3bv2022dev2b1` and will
         refuse to publish the newly built binaries
      
      Switching to `+apertisX` has the following advantages:
      
      * it can be rolled out progressively using the standard workflow
      * no need to change the build suffix
        * no need to rebuild everything on OBS
        * no need to manually delete entries from reprepro
      * backports work correctly, `+apertisX` sorts newer than `coX` and
        the OBS suffixes
      * mixing releases like v2021 and v2022 should not produce surprising
        effects like v2021 builds sorting newer than v2022
      
      The drawbacks are:
      * every non-Apertis-specific package needs to be tweaked
      * if Debian package maintainer releases a new version by appending a
        suffix there are higher chances that the `+apertisX` suffix will sort
        newer (we already have this issue, but this increases the chances to
        hit it)
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      39794050
  22. 06 May, 2021 1 commit
  23. 28 Apr, 2021 1 commit
    • Emanuele Aina's avatar
      pkg-pull-updates: Fix tagging of imported commits after message trimming · 1863584c
      Emanuele Aina authored
      Commit 4d11675a
      
       "pkg-pull-updates: Avoid oversized commit messages"
      resolved to amending the commit generated by `gbp import-dsc` to trim
      the overly long commit messages since they where causing issues with
      GitLab CI/CD.
      
      However, `gbp import-dsc` also creates a git tag for the generated
      commit and after the amend the tag was left dangling, pointing to the
      original commit rather than the amended one.
      
      Invoke `gbp tag --retag` to update the tag as well, so it get pushed
      again with the branch.
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      1863584c
  24. 27 Apr, 2021 3 commits
  25. 26 Apr, 2021 1 commit
    • Emanuele Aina's avatar
      pkg-merge-upstream-to-downstreams: Do not abort automerging · 82ad5fbb
      Emanuele Aina authored
      
      
      When pushing new commits to a MR set to be merged automatically with the
      `merge_request.merge_when_pipeline_succeeds` push option GitLab aborts
      the automated merge.
      
      This meant that our automerging never worked because we first pushed the
      unmerged commit to create the MR and when the local merge attempt
      succeeded we pushed the result to the same MR, causing GitLab to abort
      the automerging.
      
      To make it work, ensure we only push once to create the MR, either with
      the result of the local merge or the unmerged commit if the local
      attempt failed.
      Signed-off-by: Emanuele Aina's avatarEmanuele Aina <emanuele.aina@collabora.com>
      82ad5fbb
  26. 23 Apr, 2021 2 commits