1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL.RELEAS

  • Bug#1099646: transition: gnat

    From Graham Inggs@21:1/5 to Nicolas Boulenguez on Sat Mar 29 12:20:01 2025
    XPost: linux.debian.bugs.dist

    Hi Nicolas

    On Fri, 28 Mar 2025 at 18:06, Nicolas Boulenguez <[email protected]> wrote:
    As far as I understand, the only remaining blocker is #1100461 (ghdl).

    That seems to be uploaded already, 5.0.1+dfsg-1 is currently binNEW.

    I wonder why gprbuild libgnatcoll libgnatcoll-bindings libgnatcoll-db
    are orange in the transition tracker.

    I believe this happens when there is a match on both the Good and Bad
    regexes in the ben file.

    It might be because e.g. the gprbuild binary package has a dependency
    on libgnatprj12.

    I am open to trying suggestions for improving the ben file.

    Maybe the severity change in
    #1100373 (gprbuild) did confuse the tracker?

    I don't think the tracker knows about bug severities.

    Regards
    Graham

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nicolas Boulenguez@21:1/5 to All on Sat Mar 29 15:00:02 2025
    XPost: linux.debian.bugs.dist

    It might be because e.g. the gprbuild binary package has a dependency
    on libgnatprj12.
    I am open to trying suggestions for improving the ben file.

    Apparently
    .source ~ /gcc/ in is_affected
    intends to match gcc-11 gcc-12 gcc-13 gcc-14-cross-ports and so on.
    .depends ~ /libgnat/ in is_bad
    is always true because is_affected already applies the same filter.
    .depends ~ /libgnat-14/ in is_good and is_bad
    intends to select only libgnat-14.
    so I suggest this.

    is_affected = .depends ~ /^libgnat-/ & !.source ~ /^gcc-/
    is_good = .depends ~ "libgnat-14"
    is_bad = ! .depends ~ "libgnat-14"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nicolas Boulenguez@21:1/5 to All on Sat Mar 29 17:20:01 2025
    XPost: linux.debian.bugs.dist

    Package: release.debian.org
    Followup-For: Bug #1099646

    I would like advice about a test that I broke during this transition. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100373
    We have ignored it as a reproducibility issue, but another symptom is
    that gprbuild recompiles generated Ada sources and their reverse
    dependencies again and again during package builds (at least during
    the build, test and install steps).
    On buildds, this only wastes resources, but this is confusing for
    humans, and hard to connect with #1100373 (for example, 'debian/rules dh_auto_build' and 'debian/rules build' behave differently because the environment differs).
    The fix is trivial https://salsa.debian.org/debian/gprbuild/-/commit/2f1ecf1082709d6fd8a53d497d93b7739ca43176
    but four reverse dependencies need a bin-NMU.

    package build-depends on builds ----------------------------------------------------------------
    gprbuild libgnatprj-dev
    alire libgnatprj-dev
    libgnatcoll libgnatprj-dev libgnatcoll-dev
    libgnatcoll-bindings libgnatcoll-dev libgnatcoll-iconv-dev
    libgnatcoll-db libgnatcoll-iconv-dev

    libgnatcoll-iconv-dev does not call libgnatprj, but depends on the
    virtual libgnatcoll-dev-HASH. HASH will change.

    nmu alire_1.2.1-2 . ANY . -m 'Rebuild with SOURCE_DATE_EPOCH fixed in libgnatprj-dev'
    dw alire_1.2.1-2 . ANY . -m 'libgnatprj-dev (>= 2025.0.0-4)' nmu libgnatcoll_24.1.20230921-6 . ANY . -m 'Rebuild with SOURCE_DATE_EPOCH fixed in libgnatprj-dev'
    dw libgnatcoll_24.1.20230921-6 . ANY . -m 'libgnatprj-dev (>= 2025.0.0-4)' nmu libgnatcoll-bindings_25.0.0-2 . ANY . -m 'Rebuild with SOURCE_DATE_EPOCH fixed in libgnatprj-dev'
    dw libgnatcoll-bindings_25.0.0-2 . ANY . -m 'libgnatcoll-dev (>= 24.1.20230921-6+b1)'
    nmu libgnatcoll-db_25.0.0-2 . ANY . -m 'Rebuild with SOURCE_DATE_EPOCH fixed in libgnatprj-dev'
    dw libgnatcoll-db_25.0.0-2 . ANY . -m 'libgnatcoll-iconv-dev (>= 25.0.0-2+b1)'

    Should I upload gprbuild despite the freeze, or wait for first dot
    release? In the first case, should I wait after this bug is closed
    and open a distinct one? do an intermediate upload to experimental?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)