• Bug#1106313: streamripper: FTBFS in testing/arm64: configure: error: /b

    From Santiago Vila@21:1/5 to All on Mon May 26 10:30:01 2025
    El 26/5/25 a las 9:47, Michael Ablassmeier escribió:
    hm, this seems to be depending on the build system used, it actually built here:

    https://buildd.debian.org/status/logs.php?pkg=streamripper&ver=1.64.6-2&arch=arm64
    getbuildlog streamripper 1.64.6-2 arm64

    > checking whether mbrtowc and mbstate_t are properly declared... yes
    > checking build system type... aarch64-unknown-linux-gnu
    > checking host system type... aarch64-unknown-linux-gnu
    > checking for ld used by GCC... /usr/bin/ld

    That was nearly a year ago and it just means that it built at some time, but not necessarily now.

    There are a number of packages which fail in the same way as this one
    on arm64. I suspect of some build-dependency. I suggest using debbisect
    to figure out which one.

    Thanks.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lucas Nussbaum@21:1/5 to Santiago Vila on Mon May 26 13:00:01 2025
    On 26/05/25 at 12:07 +0200, Santiago Vila wrote:
    El 26/5/25 a las 11:08, Lucas Nussbaum escribi�:
    ijs was fixed by Sergio (Cced) with the following patch:

    diff -Nru ijs-0.35/debian/rules ijs-0.35/debian/rules
    --- ijs-0.35/debian/rules 2025-02-19 17:59:38.000000000 +0100
    +++ ijs-0.35/debian/rules 2025-05-25 00:47:55.000000000 +0200
    @@ -43,7 +43,9 @@

    # put aside upstream-shipped temp files during build but after copyright-check
    upstreamtmpfiles = ltmain.sh configure aclocal.m4 Makefile.in ijs_spec.pdf
    -pre-build:: debian/stamp-upstreamtmpstuff
    +pre-build:: debian/force-autoreconf debian/stamp-upstreamtmpstuff +debian/force-autoreconf:
    + autoreconf -fi
    debian/stamp-upstreamtmpstuff: debian/stamp-copyright-check
    for file in $(upstreamtmpfiles); do \
    [ ! -e $$file ] || [ -e $$file.upstream ] || cp -a $$file $$file.upstream; \

    Ok, the natural question here would be:

    Why do we have to do that now but not in the past?

    I debbisected it:
    bisection finished successfully
    last good timestamp: 20250423T023047Z
    first bad timestamp: 20250423T091925Z
    only one package differs: cdbs 0.4.171 -> 0.4.172

    Looking at cdbs' changes history between those two releases, this sounds relevant:
    https://salsa.debian.org/debian/cdbs/-/commit/5efba11b142b73ffbfa61fff09cdacc3d6db52b9
    but I don't understand the change itself.

    @Alexandre ?

    Can we fix that in cdbs once (if that's really the root of the problem) instead of fixing several different packages?

    (Adding Alexandre to CC as he did the last cdbs uploads)

    Lucas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sergio Durigan Junior@21:1/5 to Santiago Vila on Tue May 27 03:10:01 2025
    On Monday, May 26 2025, Santiago Vila wrote:

    El 26/5/25 a las 11:08, Lucas Nussbaum escribió:
    ijs was fixed by Sergio (Cced) with the following patch:
    diff -Nru ijs-0.35/debian/rules ijs-0.35/debian/rules
    --- ijs-0.35/debian/rules 2025-02-19 17:59:38.000000000 +0100
    +++ ijs-0.35/debian/rules 2025-05-25 00:47:55.000000000 +0200
    @@ -43,7 +43,9 @@
    # put aside upstream-shipped temp files during build but after
    copyright-check
    upstreamtmpfiles = ltmain.sh configure aclocal.m4 Makefile.in ijs_spec.pdf >> -pre-build:: debian/stamp-upstreamtmpstuff
    +pre-build:: debian/force-autoreconf debian/stamp-upstreamtmpstuff
    +debian/force-autoreconf:
    + autoreconf -fi
    debian/stamp-upstreamtmpstuff: debian/stamp-copyright-check
    for file in $(upstreamtmpfiles); do \
    [ ! -e $$file ] || [ -e $$file.upstream ] || cp -a $$file $$file.upstream; \

    Ok, the natural question here would be:

    Why do we have to do that now but not in the past?

    Yesterday I was asking myself the same question after seeing a second
    bug about this problem.

    Can we fix that in cdbs once (if that's really the root of the problem) instead of fixing several different packages?

    I see you've already investigated and found the issue. I had a patch
    ready yesterday (which reverted the problematic change on cdbs), but
    wanted to do more testing today. Unfortunately I was AFK for the entire
    day and couldn't even reply to these messages; sorry about that.

    Either way, I just wanted to say that I agree with the revert. CDBS
    must go; we really need to retire it.

    Thanks,

    --
    Sergio
    GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
    Please send encrypted e-mail if possible
    https://sergiodj.net/

    --=-=-Content-Type: application/pgp-signature; name="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEI3pUsQKHKL8A7zH00Ot2KGX8XjYFAmg1DC4ACgkQ0Ot2KGX8 XjZhQg/+IF/1pjRMPmOQ8aH3lnPT1EeciHfgyLapiqrfK0znEwYj03/Lf1wnWHa1 PAjfV3g5FL+sDDqcI26VXm+IdqEfD/jh3+KL6JMlDy3HWUbKKAuQL8HRlWVDlt47 e6JPHCq9RQLsEMQvxsaCoOEnvGoGicXPzhZTsU4yRpk1N2hEIu/EQnWE/2MUosH6 pEi9kreL70ehsPYae624BB/fk6jWwDFxqoIkdGY0tF1X53vUzG21NMEgE92T+TxW HlXO03KupkXIOes2NR0uBZz/W4HByXgZwnDj+5CIDImQg/pHPXorK9monoSGFOac /la7tSMt22ibF7QqOprl/hdkY3Aj80WABxOwqJBQWbhvbGCHsmZ7zAhr23MrqzFV vKDptHJg6/JpoDovfW7/IB/RylxMggrIDY5+YdtIEZ+w5mw67CwyuuonA3STd0Cc MgaFadf7jsLRPSVHstb9Akos1bRfiolPFnqvzfKxRWEQrgYzyVR9SzW7xjT1b8HB 2mY+O8Y5t6tB4pXxd1UvZZnEA+mpZmvVqq2zhJ+pKQ609G5SHRNWyFgn3oV/q/G/ ZXXkaOk4x09aER7j4tthq7PvAgfG8ONDU4FmDPR+8P6LCriGjq1CAHJZ52plZJ6I 6iRVVSRjjTjyB2x2v7zHpcCresyzMooocxBGS2Q7PzH7rRt00O
  • From Lucas Nussbaum@21:1/5 to Santiago Vila on Tue May 27 07:40:01 2025
    On 27/05/25 at 00:59 +0200, Santiago Vila wrote:
    Could these be selected with UDD for all uploads between two dates
    (then and now).

    Ok, here is a list of packages meeting the following conditions:

    - build-depends on cdbs
    - last uploaded between 2025-04-08 and 2025-05-27

    2025-04-09 libiptcdata 1.0.5-2.4
    2025-04-09 vim-scripts 20210124.4
    2025-04-13 oss4 4.2-build2020-5
    2025-04-24 x2gobroker 0.0.4.3-4.3
    2025-05-04 dhelp 0.6.31
    2025-05-04 libmessage-passing-filter-regexp-perl 0.05-5
    2025-05-04 libmodule-install-copyright-perl 0.009-4
    2025-05-04 libmodule-install-doapchangesets-perl 0.206-4
    2025-05-04 libmodule-install-doap-perl 0.006-4
    2025-05-04 libmodule-install-rdf-perl 0.009-4
    2025-05-04 libmoosex-arrayref-perl 0.005-4
    2025-05-04 libpath-router-perl 0.15-4
    2025-05-04 librdf-trinex-serializer-mockturtlesoup-perl 0.006-4
    2025-05-04 librdf-vcard-perl 0.012-4
    2025-05-05 haskell-ogma-core 1.7.0-2
    2025-05-07 haskell-charsetdetect-ae 1.1.0.4-7.1
    2025-05-09 haskell-ogma-cli 1.7.0-2
    2025-05-24 ijs 0.35-15.3

    ( If somebody could double-check the above, it would be great )

    double-checked (haskell-ogma-{core,cli} are non-free)

    Now we could try building with old cdbs and new cdbs to see
    if there is any difference using diffoscope.

    Most packages in the above list are arch:all so there is very little chance to be misbuilt due to config.guess/config.sub.

    Maybe the other block that was also removed:

    config_rpath := $(shell find $(DEB_SRCDIR) \( -type f -or -type l \) -name config.rpath

    has more chances to create misbuilds.

    if this is about rpath, isn't it going to be specific to arch:any builds
    as well?

    Breakdown per architecture:

    udd=> select source, architecture from sources_uniq where release='sid'
    and source in ('libiptcdata', 'vim-scripts', 'oss4', 'x2gobroker',
    'dhelp', 'libmessage-passing-filter-regexp-perl', 'libmodule-install-copyright-perl',
    'libmodule-install-doapchangesets-perl', 'libmodule-install-doap-perl', 'libmodule-install-rdf-perl', 'libmoosex-arrayref-perl',
    'libpath-router-perl', 'librdf-trinex-serializer-mockturtlesoup-perl', 'librdf-vcard-perl', 'haskell-ogma-core', 'haskell-charsetdetect-ae', 'haskell-ogma-cli', 'ijs') order by architecture;

    source | architecture ----------------------------------------------+--------------
    dhelp | all
    libmodule-install-doap-perl | all
    libmodule-install-rdf-perl | all
    libmoosex-arrayref-perl | all
    libpath-router-perl | all
    librdf-trinex-serializer-mockturtlesoup-perl | all
    librdf-vcard-perl | all
    vim-scripts | all
    libmessage-passing-filter-regexp-perl | all
    libmodule-install-copyright-perl | all
    libmodule-install-doapchangesets-perl | all
    haskell-ogma-cli | any
    oss4 | any
    haskell-charsetdetect-ae | any all
    libiptcdata | any all
    x2gobroker | any all
    ijs | any all
    haskell-ogma-core | any all
    (18 rows)

    (my personal bet is that the impact is going to be zero).

    I agree.

    What is a bit painful here is that we would need to check binaries on
    all architectures. Maybe it's easier to just bin-NMU them all...

    Lucas

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Santiago Vila@21:1/5 to All on Tue May 27 12:50:01 2025
    El 27/5/25 a las 8:45, Santiago Vila escribió:
    - Only two packages have config.guess/config.sub files:

    libiptcdata
    ijs

    - Only one package has config.rpath

    libiptcdata

    Package libiptcdata was uploaded on 2025-04-09 during the
    morning, and all their binaries were built with cdbs 0.4.171
    which had not the bug:

    https://buildd.debian.org/status/package.php?p=libiptcdata

    The bad cdbs (0.4.172) was uploaded the same day but in the afternoon.

    So the binaries of libiptcdata should be good.

    Package ijs was NMUed by Sergio to run autoreconf, which made it to build ok even with the bad cdbs. I wonder how running autoreconf makes
    recent config.guess/config.sub not to be necessary anymore
    for a successful build.

    Sergio: What would you think about reverting the change and relying
    on the fixed cdbs instead? The NMU was made two days ago, so another
    NMU today would not be too bad.

    The ijs package currently in testing is good for Debian 13, so we
    would not even have to ask for an unblock (unless it needs
    more changes not related to this).

    Thanks.

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