Re: gdb builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware)

Re: gdb builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware)

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

Hi Tom,

On Wed, 2022-06-15 at 09:33 +0200, Tom de Vries wrote:
> This caused a build breaker (which I ran into once the warning 
> suppression in debuginfod-support.c was enabled also for x86_64).
> 
> Fixed here ( 
> https://sourceware.org/pipermail/gdb-patches/2022-June/190097.html ).

Apologies, I was sure I had tested everywhere, but clearly missed that
on an older install I didn't have debuginfod installed. Thanks for
fixing it.

> I did wonder why the builder didn't catch this.  I found out that
> the 
> buildbot gdb-opensuseleap-x86_64 did't fail because the buildbot
> builds 
> gdb without debuginfod support.
> 
> Mark, is this something we want to fix?
> 
> For opensuse it's package libdebuginfod-devel.

Yep, that seems like a good idea. Should now be added to the opensuse-
leap container.

CC buildbot list, where you can propose such patches yourself if you
notice anything else missing.

Cheers,

Mark


[-- Attachment #2: Type: text/x-patch, Size: 1071 bytes --]

From 1e59a7816e641fe0ae35dc971fad046dc3cb10f9 Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mark@klomp.org>
Date: Wed, 15 Jun 2022 13:04:15 +0200
Subject: [PATCH] Containerfile-opensuse-leap: Add libdebuginfod-devel

---
 builder/containers/Containerfile-opensuse-leap | 1 +
 1 file changed, 1 insertion(+)

diff --git a/builder/containers/Containerfile-opensuse-leap b/builder/containers/Containerfile-opensuse-leap
index ecfa0d3..77f94d5 100644
--- a/builder/containers/Containerfile-opensuse-leap
+++ b/builder/containers/Containerfile-opensuse-leap
@@ -9,6 +9,7 @@ RUN zypper -n install \
         bzip2 libbz2-devel xz xz-devel gzip zlib-devel zstd libzstd-devel \
         findutils file tar curl libarchive-devel libcurl-devel \
         libmicrohttpd-devel sqlite-devel libelf-devel libdw-devel \
+        libdebuginfod-devel \
         xmlto poppler-tools libxslt docbook-dtds docbook-xsl-stylesheets \
         libxml2-devel dos2unix dpkg python3-devel python3-mock \
         python3-rpm python3-pyxdg python3-pip openmpi-devel gdb help2man wget \
-- 
2.18.4

Re: gdb builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware)

[Mark Wielaard]

Hi Tom,

On Wed, 2022-06-15 at 13:09 +0200, Mark Wielaard wrote:
> > I did wonder why the builder didn't catch this.  I found out that
> > the 
> > buildbot gdb-opensuseleap-x86_64 did't fail because the buildbot
> > builds 
> > gdb without debuginfod support.
> > 
> > Mark, is this something we want to fix?
> > 
> > For opensuse it's package libdebuginfod-devel.
> 
> Yep, that seems like a good idea. Should now be added to the
> opensuse-
> leap container.

Note that this didn't actually work. Although the package is now
installed:

builder@df808da35762:~/build> rpm -qa | grep debuginfod
libdebuginfod-devel-0.185-150400.3.35.x86_64

The configure test still fails:

configure:7009: checking whether to use debuginfod
configure:7011: result: auto
configure:7017: checking for libdebuginfod >= 0.179
configure:7024: $PKG_CONFIG --exists --print-errors "libdebuginfod >= 0.179"
configure:7027: $? = 0
configure:7041: $PKG_CONFIG --exists --print-errors "libdebuginfod >= 0.179"
configure:7044: $? = 0
configure:7069: gcc -o conftest -g -O2      -ldebuginfod conftest.c -ldl  >&5
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot find -ldebuginfod
collect2: error: ld returned 1 exit status

The problem is:

builder@df808da35762:~/build> ls -lah /usr/lib64/libdebuginfod.so
lrwxrwxrwx 1 root root 22 May  7 23:06 /usr/lib64/libdebuginfod.so ->
libdebuginfod-0.185.so
builder@df808da35762:~/build> ls -lah /usr/lib64/libdebuginfod-0.185.so
ls: cannot access '/usr/lib64/libdebuginfod-0.185.so': No such file or
directory

Is that a opensuse leap packaging bug?

BTW. To debug such builder container issues you can use this IMHO handy
guide:
https://sourceware.org/git/?p=builder.git;a=blob;f=README_containers;hb=HEAD

> CC buildbot list, where you can propose such patches yourself if you
> notice anything else missing.
> 
> Cheers,
> 
> Mark
> 

Re: gdb builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware)

[Martin Liška]

On 6/15/22 16:38, Mark Wielaard wrote:
> Hi Tom,
> 
> On Wed, 2022-06-15 at 13:09 +0200, Mark Wielaard wrote:
>>> I did wonder why the builder didn't catch this.  I found out that
>>> the 
>>> buildbot gdb-opensuseleap-x86_64 did't fail because the buildbot
>>> builds 
>>> gdb without debuginfod support.
>>>
>>> Mark, is this something we want to fix?
>>>
>>> For opensuse it's package libdebuginfod-devel.
>>
>> Yep, that seems like a good idea. Should now be added to the
>> opensuse-
>> leap container.
> 
> Note that this didn't actually work. Although the package is now
> installed:
> 
> builder@df808da35762:~/build> rpm -qa | grep debuginfod
> libdebuginfod-devel-0.185-150400.3.35.x86_64
> 
> The configure test still fails:
> 
> configure:7009: checking whether to use debuginfod
> configure:7011: result: auto
> configure:7017: checking for libdebuginfod >= 0.179
> configure:7024: $PKG_CONFIG --exists --print-errors "libdebuginfod >= 0.179"
> configure:7027: $? = 0
> configure:7041: $PKG_CONFIG --exists --print-errors "libdebuginfod >= 0.179"
> configure:7044: $? = 0
> configure:7069: gcc -o conftest -g -O2      -ldebuginfod conftest.c -ldl  >&5
> /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: cannot find -ldebuginfod
> collect2: error: ld returned 1 exit status
> 
> The problem is:
> 
> builder@df808da35762:~/build> ls -lah /usr/lib64/libdebuginfod.so
> lrwxrwxrwx 1 root root 22 May  7 23:06 /usr/lib64/libdebuginfod.so ->
> libdebuginfod-0.185.so
> builder@df808da35762:~/build> ls -lah /usr/lib64/libdebuginfod-0.185.so
> ls: cannot access '/usr/lib64/libdebuginfod-0.185.so': No such file or
> directory
> 
> Is that a opensuse leap packaging bug?

Note we don't have the package in Leap and this is what I see when building the current Containerfile-opensuse-leap:

STEP 3/10: RUN zypper -n install         gcc gcc-c++ libtool ccache valgrind         isl-devel mpc-devel mpfr-devel gmp-devel         patch util-linux diffutils iproute2 bsdtar cpio procps         coreutils make git autoconf dejagnu automake gettext-devel bison flex         bzip2 libbz2-devel xz xz-devel gzip zlib-devel zstd libzstd-devel         findutils file tar curl libarchive-devel libcurl-devel         libmicrohttpd-devel sqlite-devel libelf-devel libdw-devel         libdebuginfod-devel         xmlto poppler-tools libxslt docbook-dtds docbook-xsl-stylesheets         libxml2-devel dos2unix dpkg python3-devel python3-mock         python3-rpm python3-pyxdg python3-pip openmpi-devel gdb help2man wget         texinfo libexpat-devel glibc-devel glibc-locale
...
'libdebuginfod-devel' not found in package names. Trying capabilities.
No provider of 'libdebuginfod-devel' found. ['--plus-content debug'?]

Martin

> 
> BTW. To debug such builder container issues you can use this IMHO handy
> guide:
> https://sourceware.org/git/?p=builder.git;a=blob;f=README_containers;hb=HEAD
> 
>> CC buildbot list, where you can propose such patches yourself if you
>> notice anything else missing.
>>
>> Cheers,
>>
>> Mark
>>

Re: gdb builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware)

[Mark Wielaard]

Hi Martin,

On Wed, Jun 15, 2022 at 09:18:38PM +0200, Martin Liška wrote:
> > Is that a opensuse leap packaging bug?
> 
> Note we don't have the package in Leap and this is what I see when building the current Containerfile-opensuse-leap:
> 
> STEP 3/10: RUN zypper -n install         gcc gcc-c++ libtool ccache valgrind         isl-devel mpc-devel mpfr-devel gmp-devel         patch util-linux diffutils iproute2 bsdtar cpio procps         coreutils make git autoconf dejagnu automake gettext-devel bison flex         bzip2 libbz2-devel xz xz-devel gzip zlib-devel zstd libzstd-devel         findutils file tar curl libarchive-devel libcurl-devel         libmicrohttpd-devel sqlite-devel libelf-devel libdw-devel         libdebuginfod-devel         xmlto poppler-tools libxslt docbook-dtds docbook-xsl-stylesheets         libxml2-devel dos2unix dpkg python3-devel python3-mock         python3-rpm python3-pyxdg python3-pip openmpi-devel gdb help2man wget         texinfo libexpat-devel glibc-devel glibc-locale
> ...
> 'libdebuginfod-devel' not found in package names. Trying capabilities.
> No provider of 'libdebuginfod-devel' found. ['--plus-content debug'?]

That is surprising, I did test locally before adding the package. And
clearly the buildbot/docker builder could find the package and build
the image. And when I do it locally it also seems to work:

$ podman build -t builder-opensuse-leap -f builder/containers/Containerfile-opensuse-leap builder/containers
[...]
Retrieving package libdebuginfod-devel-0.185-150400.3.35.x86_64 (129/429),  23.4 KiB (  8.9 KiB unpacked)
Retrieving: libdebuginfod-devel-0.185-150400.3.35.x86_64.rpm [done]
[...]
(129/429) Installing: libdebuginfod-devel-0.185-150400.3.35.x86_64 [.......done]
[...]
Successfully tagged localhost/builder-opensuse-leap:latest
395a607b4cd69683b3212862d3dd3c8557b2a581f210cb903c1168ecd5f01b16

$ podman run --name opensuse-leap -ti --entrypoint /bin/bash builder-opensuse-leap
builder@9d1600f0c01e:~> rpm -q libdebuginfod-devel
libdebuginfod-devel-0.185-150400.3.35.x86_64

Are the container files pulling from the wrong repositories?

> > BTW. To debug such builder container issues you can use this IMHO handy
> > guide:
> > https://sourceware.org/git/?p=builder.git;a=blob;f=README_containers;hb=HEAD
> > 
> >> CC buildbot list, where you can propose such patches yourself if you
> >> notice anything else missing.
> >>
> >> Cheers,
> >>
> >> Mark

Re: gdb builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware)

[Martin Liška]

On 6/15/22 21:48, Mark Wielaard wrote:
> $ podman run --name opensuse-leap -ti --entrypoint /bin/bash builder-opensuse-leap
> builder@9d1600f0c01e:~> rpm -q libdebuginfod-devel
> libdebuginfod-devel-0.185-150400.3.35.x86_64
> 
> Are the container files pulling from the wrong repositories?

Yeah, I was still using 15.3, while we released 15.4 in the meantime.
Apparently the following helps:

podman build ... --pull=true

And about:

ls -lah /usr/lib64/libdebuginfod-0.185.so
ls: cannot access '/usr/lib64/libdebuginfod-0.185.so': No such file or
directory

It's really a broken package and I'm going to fix it (it's missing
Requires:       libdebuginfod1 = %{version}

In the meantime I install it manually in this podman file.

Cheers,
Martin

Re: gdb builder status (Was: Adding binutils to the GNU Toolchain buildbot on sourceware)

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]

Hi Martin,

On Thu, Jun 16, 2022 at 06:09:13AM +0200, Martin Liška wrote:
> > $ podman run --name opensuse-leap -ti --entrypoint /bin/bash builder-opensuse-leap
> > builder@9d1600f0c01e:~> rpm -q libdebuginfod-devel
> > libdebuginfod-devel-0.185-150400.3.35.x86_64
> > 
> > Are the container files pulling from the wrong repositories?
> 
> Yeah, I was still using 15.3, while we released 15.4 in the meantime.
> Apparently the following helps:
> 
> podman build ... --pull=true

Aha. The reason this wasn't necessary on the container builders was
because they do a docker system prune -a -f every Sunday to get a
fresh image.

Note that this did also cause libabigail to turn green on opensuse
leap (because it got a newer elfutils):
https://sourceware.org/pipermail/libabigail/2022q2/004430.html

> And about:
> 
> ls -lah /usr/lib64/libdebuginfod-0.185.so
> ls: cannot access '/usr/lib64/libdebuginfod-0.185.so': No such file or
> directory
> 
> It's really a broken package and I'm going to fix it (it's missing
> Requires:       libdebuginfod1 = %{version}
> 
> In the meantime I install it manually in this podman file.

Thanks!

I'll add this to the README_containers.

Cheers,

Mark

[-- Attachment #2: 0001-README_containers-Document-build-pull-and-system-pru.patch --]
[-- Type: text/x-diff, Size: 1819 bytes --]

From 530d374997b18b46965de4c93e86543e1d2b89f5 Mon Sep 17 00:00:00 2001
From: Mark Wielaard <mark@klomp.org>
Date: Thu, 16 Jun 2022 23:18:43 +0200
Subject: [PATCH] README_containers: Document build --pull and system prune -a
 -f

---
 README_containers | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/README_containers b/README_containers
index 66ac558..c414f72 100644
--- a/README_containers
+++ b/README_containers
@@ -69,8 +69,9 @@ Building the image
 ------------------
 
 Note that the container files are rebuild once a week for the
-builder.sourceware.org workers. So although unlikely it might be that
-a freshly build container contains slightly newer versions of the
+builder.sourceware.org workers (each Sunday the container builders run
+docker system prune -a -f). So although unlikely it might be that a
+freshly build container contains slightly newer versions of the
 packages than the one that ran on the builder.sourceware.org worker.
 
 The containers contain all build dependencies for all projects
@@ -85,6 +86,10 @@ podman build -t builder-debian-stable \
              -f builder/containers/Containerfile-debian-stable \
              builder/containers
 
+If you want to make sure you get the latest base image add --pull
+which will attempt to pull a newer version of the image even if you
+already got one locally.
+
 Or use docker instead of podman, they take the same arguments
 (although the last PATH is optional in some versions).
 
@@ -109,4 +114,7 @@ container and enter it as root:
 podman start debian-stable
 podman exec -it --user root debian-stable apt install emacs
 
+After you are done you can reclaim all disk space used by the images
+and containers by running: podman system prune -a -f
+
 The same works with the docker command.
-- 
2.30.2