• Salsa CI documentation updated

    From =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?@21:1/5 to All on Tue Sep 24 18:20:01 2024
    XPost: linux.debian.devel.mentors

    Hi!

    We've overhauled the README.md at https://salsa.debian.org/salsa-ci-team/pipeline to be as complete as
    possible, yet clear and to the point. If you are not yet using Salsa
    CI for pre-upload quality assurance for your package, you might want
    to check out what Salsa CI offers, or just review that your current
    usage is optimal.

    We also added a RUNNERS.md for those who want to experiment with
    customer runners or donate CI capacity to Debian.

    Feedback and improvement suggestions are also welcome as Merge
    Requests are via email.

    - Otto

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Iustin Pop@21:1/5 to All on Sun Sep 29 17:10:01 2024
    On 2024-09-27 22:29:54, Otto Kekäläinen wrote:
    Hi!

    On Fri, 27 Sept 2024 at 09:38, Iustin Pop <iustin@k1024.org> wrote:
    I just added a barebone config for one of my packages, and while the
    pipeline worked, I got an error for the arm64 cross-compile that seems
    to be due to tooling issues:

    In addition to what Johannes replied about cross-builds having issues
    in general right now, we know a lot of people are running into this
    and are tracking it in https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/374

    Thanks, I didn't think that there might an issue open. I'll continue
    discussion there, appreciated.

    iustin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Iustin Pop@21:1/5 to All on Fri Sep 27 14:40:02 2024
    On 2024-09-24 09:18:45, Otto Kekäläinen wrote:
    Hi!

    We've overhauled the README.md at https://salsa.debian.org/salsa-ci-team/pipeline to be as complete as possible, yet clear and to the point. If you are not yet using Salsa
    CI for pre-upload quality assurance for your package, you might want
    to check out what Salsa CI offers, or just review that your current
    usage is optimal.

    Wow, this is really, really awesome. Thanks a lot!

    iustin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Iustin Pop@21:1/5 to All on Fri Sep 27 16:40:01 2024
    On 2024-09-24 09:18:45, Otto Kekäläinen wrote:
    Hi!

    We've overhauled the README.md at https://salsa.debian.org/salsa-ci-team/pipeline to be as complete as possible, yet clear and to the point. If you are not yet using Salsa
    CI for pre-upload quality assurance for your package, you might want
    to check out what Salsa CI offers, or just review that your current
    usage is optimal.

    We also added a RUNNERS.md for those who want to experiment with
    customer runners or donate CI capacity to Debian.

    Feedback and improvement suggestions are also welcome as Merge
    Requests are via email.

    I just added a barebone config for one of my packages, and while the
    pipeline worked, I got an error for the arm64 cross-compile that seems
    to be due to tooling issues:

    make[1]: Entering directory '/builds/debian/mt-st/debian/output/source_dir' echo '#define VERSION "1.7"' > version.h
    aarch64-linux-gnu-gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/builds/debian/mt-st/debian/output/source_dir=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -
    mbranch-protection=standard -Wl,-z,relro -Wl,-z,now -DDEFTAPE='"/dev/tape"' -o mt mt.c
    aarch64-linux-gnu-gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/builds/debian/mt-st/debian/output/source_dir=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -
    mbranch-protection=standard -Wl,-z,relro -Wl,-z,now -DDEFTAPE='"/dev/tape"' -o stinit stinit.c
    ccache: error: execute_noreturn of /usr/bin/aarch64-linux-gnu-gcc failed: Exec format error
    make[1]: *** [Makefile:44: stinit] Error 1
    make[1]: *** Waiting for unfinished jobs....
    ccache: error: execute_noreturn of /usr/bin/aarch64-linux-gnu-gcc failed: Exec format error


    The log is at https://salsa.debian.org/debian/mt-st/-/jobs/6343717.
    While this is not marked as blocking, just warning, it's still
    annoying. Is this a known issue? I would like to keep the cross-build,
    and I see nothing about this being problematic in the docs.

    thanks!
    iustin

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Johannes Schauer Marin Rodrigues@21:1/5 to All on Fri Sep 27 18:10:01 2024
    Hi,

    in general, for any cross-building issues, please feel free to write to debian-cross@lists.debian.org

    Quoting Iustin Pop (2024-09-27 16:23:16)
    I just added a barebone config for one of my packages, and while the pipeline worked, I got an error for the arm64 cross-compile that seems to be due to tooling issues:

    make[1]: Entering directory '/builds/debian/mt-st/debian/output/source_dir' echo '#define VERSION "1.7"' > version.h
    aarch64-linux-gnu-gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/builds/debian/mt-st/debian/output/source_dir=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -
    mbranch-protection=standard -Wl,-z,relro -Wl,-z,now -DDEFTAPE='"/dev/tape"' -o mt mt.c
    aarch64-linux-gnu-gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/builds/debian/mt-st/debian/output/source_dir=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -
    mbranch-protection=standard -Wl,-z,relro -Wl,-z,now -DDEFTAPE='"/dev/tape"' -o stinit stinit.c
    ccache: error: execute_noreturn of /usr/bin/aarch64-linux-gnu-gcc failed: Exec format error
    make[1]: *** [Makefile:44: stinit] Error 1
    make[1]: *** Waiting for unfinished jobs....
    ccache: error: execute_noreturn of /usr/bin/aarch64-linux-gnu-gcc failed: Exec format error

    You can see why this happens further up in the log:

    The following NEW packages will be installed:
    binutils-aarch64-linux-gnu:arm64 binutils-common:arm64
    cpp-14-aarch64-linux-gnu:arm64 cpp-aarch64-linux-gnu cross-config
    crossbuild-essential-arm64 dpkg-cross file g++-14-aarch64-linux-gnu:arm64
    g++-aarch64-linux-gnu gcc-14-aarch64-linux-gnu:arm64 gcc-14-base:arm64
    gcc-aarch64-linux-gnu libasan8:arm64 libatomic1:arm64 libbinutils:arm64
    libc6:arm64 libc6-dev:arm64 libcc1-0:arm64 libconfig-auto-perl
    libconfig-inifiles-perl libcrypt-dev:arm64 libcrypt1:arm64
    libctf-nobfd0:arm64 libctf0:arm64 libdebian-dpkgcross-perl
    libfile-homedir-perl libfile-which-perl libgcc-14-dev:arm64 libgcc-s1:arm64

    A bunch of arm64 packages are installed and specifically gcc-14-aarch64-linux-gnu is installed as the arm64 package which obviously, the amd64 salsa ci runner is unable to execute.

    One of the reasons for why you see the problem that late is because salsa-ci is not using sbuild to cross-build packages. Sbuild comes with some safeguards against this sort of situation and if you were to try and cross-build mt-st with sbuild in unstable you would instead see a conflict when it tries to install the cross-build dependencies.

    The log is at https://salsa.debian.org/debian/mt-st/-/jobs/6343717.
    While this is not marked as blocking, just warning, it's still
    annoying. Is this a known issue? I would like to keep the cross-build,
    and I see nothing about this being problematic in the docs.

    yes, this is a known issue but it is not related to salsa-ci pipeline at all but is a general cross-building issue that existed over half a year by now and is recorded in #1065416. Luckily, that bug found a resolution and packages fixing it are already in experimental.

    I you pass the correct options to sbuild such that you convince it to pull some packages from experimental instead of using unstable, you can already see how mt-st cross-builds just fine:

    sbuild -d unstable --no-run-lintian --build arm64 --host amd64 \
    --extra-repository "deb-src http://deb.debian.org/debian unstable main" \
    --extra-repository='deb http://deb.debian.org/debian experimental main' \
    --build-dep-resolver=aptitude \
    --add-depends='libc6-dev-amd64-cross (= 2.40-2cross1)' \
    --add-depends='linux-libc-dev (= 6.11-1~exp1)' \
    mt-tsc

    The above assumes that your system is arm64 and you want to build for amd64. If you are using an intel box and want to build for arm64 instead, just swap the --build and --host arguments.

    Thanks!

    cheers, josch
    --==============r17902229571123589=MIME-Version: 1.0
    Content-Transfer-Encoding: 7bit
    Content-Description: signature
    Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

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

    iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmb214sACgkQ8sulx4+9 g+HE8hAAj1uxnj9aE4i+VJ1pJ1yfjWitxKOK55Goi2DzQX3gZ2XNrA5GG/2o9Hyo D781V0IdYvqMMq+rPsGV4pEAA9r0htn+f+CiGAJkEjqrYug+/Jcr0o2zz7w70Q+q osV4lWLIMFiidWgRrccImSvcg1pAiA6EsuUICYQ/E85an0UpG/HiF98QUnv8Kj4u KDJwvETJFcnck3fJZ0pIq0DLEoCisltWmO5zPjMDUSA6H2/HtFb/MYfu1H8xgD4c rZ/xeDcSjZSYjXTWYHkU0GhHMm5ab1SZe4jkGBwIYfae7U23AYosMJYXO3DdYJ88 hIz/IB//E3lTLpB8rUxkOjSPGlNLF/VVImaxKaUbhf9T1braEnRM+kxaHeJbfh8t fMQ9fI1Aae1uySt3CPZC8zUNbnuQ2WfZDC/MzXiMtc7nAzDlAk2tfTDEVO1MZig1 KCLsg9+62S8qqQQGAH3wu+ysYT28vmpF5VebvDww8DF0Cv/wz4PaacwZT9nM2Tqm lRhPJ4u2+rvdn6ZyLIMvTrma5K2o+sKseHnqt8iIVPs9FVJbl6FCJ7+DKXZSXib0 QwTU15FnL77WS7Qf9skJ9p3mm3HJG6xOzepiJV6fbsLT3mlTzG9L/HCLma6sy/tW Wo9mWZ/8jQP9UN0QpMabI4T3OgDMjcSktu3543KJ8Z+KNNGELW0=
    =HHyN
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?@21:1/5 to All on Sat Sep 28 07:40:01 2024
    Hi!

    On Fri, 27 Sept 2024 at 09:38, Iustin Pop <iustin@k1024.org> wrote:
    I just added a barebone config for one of my packages, and while the
    pipeline worked, I got an error for the arm64 cross-compile that seems
    to be due to tooling issues:

    In addition to what Johannes replied about cross-builds having issues
    in general right now, we know a lot of people are running into this
    and are tracking it in https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/374

    While Salsa CI can't fix the fundamental cross-build issue, we should
    try to have better error messages and better documentation on why
    cross-builds are allowed to fail by default so people are not left
    wondering..

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