1. 04 Dec, 2021 7 commits
    • Anton Midyukov's avatar
    • Anton Midyukov's avatar
      firmware: drop orphaned kernel-modules-acpi_call (use/firmware/laptop) · 7d1c6174
      Anton Midyukov authored
      Not available for all kernels in p10, sisyphus.
      Available for std-def only i p9.
      7d1c6174
    • Anton Midyukov's avatar
    • Anton Midyukov's avatar
      e5c6a9b5
    • Michael Shigorin's avatar
      bin/archdep-filter: a debugging note · ca6ec25e
      Michael Shigorin authored
      ...just to have it handy when it's in need next time.
      ca6ec25e
    • Michael Shigorin's avatar
      bin/archdep-filter: cosmetic cleanups · b963e9bf
      Michael Shigorin authored
      "-a arch" is not requisite either; and having bunches
      of empty lines in the resulting pkglists that are user
      visible at least within the conventional installer's
      alterator-pkg (groups selection) module wouldn't be nice.
      
      I chose to sacrifice empty-line separators for clarity;
      the really good cleanup would save *single* empty lines
      between chunks of non-empty ones (not at the pkglist's
      start or end); feel free to implement that as well.
      b963e9bf
    • Michael Shigorin's avatar
      bin/archdep-filter: implement multi-!matching too · 1b5b309b
      Michael Shigorin authored
      This has been clearly lacking while making the previous commit
      but the implementation isn't that clear so let it be a separate
      step.
      
      The problem requiring the change in subsequent processors
      is that these relied upon "@arch" as a flag to be inspected,
      and "pkg@!arch1,arch2" on arch2 needs to take out *all* of that
      fragment *including* arch1 mention as well.
      
      Part of the cause is difference in handling: "positive" multi-match
      would explode its "client" line into multiple lines to filter down
      the pipeline, while "negative" multi-match *has* to keep that line
      on a similarly single line (otherwise we'd end up with N-1 of those
      slipping past the filter for particular architecture thus defeating
      the whole purpose of "negative" matching semantics):
      
      $ echo 'pkg@!E2K,mipsel,riscv64' |
        sed -r  ':loop; s/^((([^@]+@!)[^,]+)+),([a-zA-Z0-9_]+)/\1@!\4/; t loop'
      pkg@!E2K@!mipsel@!riscv64
      
      I've tried my best to test this specific change but it still might
      introduce a regression in some corner case; feel free to report;
      looks like there's a space for improvement in m-p's automated
      tests department as well.
      
      So now we can do:
      
        pkg@!ARCHES1,ARCHES2,arch3,arch4
      
      and have pkg excluded on arches mentioned; the previous approach
      could only offer explicit whitelists (not that it was entirely
      wrong but then again, we have both ExclusiveArch and ExcludeArch
      rpmtags in our spec files).
      1b5b309b
  2. 23 Nov, 2021 5 commits
  3. 22 Nov, 2021 9 commits
  4. 16 Nov, 2021 3 commits
  5. 15 Nov, 2021 16 commits