Mark J. Wielaard

A few weeks back Sourceware joined the Software Freedom Conservancy. This week Sourceware joins the fediverse at @sourceware@fosstodon.org.

The account will be used for Sourceware announcements, notices about downtime and temporary issues with our network.

Sourceware is run by volunteers who can be contacted on the public overseers@sourceware.org mailinglist [inbox].

Or you can file an issue in the Sourceware Infrastructure bugzilla component.

There is also an irc channel #overseers on irc.libera.chat. Overseers Open Office hours take place in the same irc channel every second Friday of the month at UTC 18:00.

After various discussions and lots of positive feedback Software Freedom Conservancy and Sourceware proudly announce that Sourceware today joins SFC as a member project!

For almost 25 years Sourceware has been the long-time home of various core toolchain project communities. Projects like Cygwin, a UNIX API for Win32 systems, the GNU Toolchain, including GCC, the GNU Compiler Colection, two C libraries, glibc and newlib, binary tools, binutils and elfutils, debuggers and profilers, GDB, systemtap and valgrind. Sourceware also hosts standard groups like gnu-gabi and the DWARF Debugging Standard. See the full list project hosted and services provided on the Sourceware projects page.

As the fiscal host of Sourceware, Software Freedom Conservancy will provide a home for fundraising, legal protection and governance that will benefit all projects under Sourceware’s care.  We share one mission: developing, distributing and advocating for Software Freedom.  Together we will offer a worry-free, friendly home for core toolchain and developer tool projects.

We are pleased to announce a new release of Valgrind, version 3.21.0, available from https://valgrind.org/downloads/current.html.

Summary of new features

valgrind now provides gdb python commands. These GDB front end commands provide a better integration in the GDB command line interface, so as to use for example GDB auto-completion, command specific help, searching for a command or command help matching a regexp, … For relevant monitor commands, GDB will evaluate arguments to make the use of monitor commands easier.

The vgdb utility now supports extended-remote protocol when invoked with --multi. In this mode the GDB run command is supported. Which means you don’t need to run gdb and valgrind from different terminals.

The behaviour of realloc with a size of zero can now be changed for tools that intercept malloc with --realloc-zero-bytes-frees=yes|no

Make the address space limit on FreeBSD amd64 128Gbytes

When doing a memcheck delta leak_search, it is now possible to only output the new loss records compared to the previous leak search.

Memcheck now performs checks for the use of realloc with a size of zero. --show-realloc-size-zero=yes|no

The helgrind option --history-backtrace-size= allows to configure the number of entries to record in the stack traces of “old” accesses.

Cachegrind--cache-sim=no is now the default.

cg_annotate, cg_diff, and cg_merge have been rewritten in Python. As a result, they all have more flexible command line argument handling, e.g. supporting --show-percs and --no-show-percs forms as well as the existing --show-percs=yes and --show-percs=no.

cg_annotate is much faster, e.g. 3-4x on common cases. It now supports diffing (with --diff, --mod-filename, and --mod-funcname) and merging (by passing multiple data files). It now provides more information at the file and function level.

DHAT supports a new user request which allows you to override the 1024 byte limit on access count histograms for blocks of memory.

Full release notes at https://valgrind.org/docs/manual/dist.news.html

Please donate to the Software Freedom Conservancy this year. Software Freedom Conservancy has been growing and is able to take on the work it does thanks to the incredible support of individuals who care about an organization who stands up for the equitable, ethical and end user focused technologies.

They have been a great partner to Sourceware, helping with the GNU Toolchain Infrastructure, putting developers and community first.

The FSF was nice enough to host a video chat on Sourceware infrastructure – A presentation and community Q&A. Which was basically the BoF we had wanted to give about Sourceware Infrastructure at the Cauldron. Extended with some discussion on recent developments, Sourceware as Conservancy member project and collaboration with the FSF tech-team. It was less interactive than the in person BoF would have been, but there was some nice feedback afterwards.

Slides New services for sourceware projects. Markdown source plus presenter notes.

We are pleased to announce a new release of Valgrind, version 3.20.0, available from http://valgrind.org/downloads/current.html.

This is mostly a bug fix release to make sure valgrind works well against the latest gcc, glibc and linux kernel, but also contains a lot of work to make valgrind work better on FreeBSD. Plus a couple of new features:

• The option “–vgdb-stop-at=event1,event2,…” accepts the new value abexit. This indicates to invoke gdbserver when your program exits abnormally (i.e. with a non zero exit code).
• Fix Rust v0 name demangling.
• The Linux rseq syscall is now implemented as (silently) returning ENOSYS.
• Add FreeBSD syscall wrappers for __specialfd and __realpathat.
• Remove FreeBSD dependencies on COMPAT10, which fixes compatibility with HardenedBSD
• The option –enable-debuginfod= [default: yes] has been added on Linux.
• More DWARF5 support as generated by clang14.

The most interesting bug fixed (IMHO) is #458915 syscall sometimes returns its number instead of return code when vgdb is attached. It might not hit you, but if it did it was really confusing.

Cauldron was fun, heard so many interesting talks, met so many fun people, had great conversations.

I also had a BoF about all the great infrastructure work we have been adding to Sourceware over that last year and had wanted to discuss how the different project hosted on Sourceware wanted to use it to improve their processes: New services for sourceware projects. The sourceware.md file also has the presenter notes and discussion items I had prepared.

But when I said that at the end I also would like to discuss the recent Sourceware as Conservancy member project proposal and that I had asked both Conservancy and FSF members to call in to help with that discussion there was what felt like a shouting match. It was the first time I felt an in-person event was worse than an email discussion. Hopefully people will calm down and restart this discussion on the sourceware overseers list.

Last month the Sourceware overseers started a discussion with the projects hosted on Sourceware and the Software Freedom Conservancy (SFC) to become a Conservancy member project (which means Conservancy would become the fiscal sponsor of Sourceware). After many positive responses the SFC’s Evaluations Committee has voted to accept Sourceware.

Read the rest of this entry »

Make sure to read Nicholas Nethercote’s Twenty years of Valgrind to learn about the early days, Valgrind “skins”, the influence Valgrind had on raising the bar when it comes to correctness for C and C++ programs, and why a hacker on the Rust programming language still uses Valgrind.

Making email/git based workflow more fun, secure and productive by automating contribution tracking and testing across different distros and architectures.

What is Sourceware?

Sourceware, https://sourceware.org/, is community run infrastructure, mailinglists, git, bug trackers, wikis, etc. hosted in the Red Hat Open Source Community Infrastructure Community Cage together with servers from e.g. Ceph, CentOS, Fedora and Gnome.

Sourceware is mainly known for hosting the GNU Toolchain projects, like gcc at https://gcc.gnu.org/, glibc, binutils and gdb. But also hosts projects like annobin, bunsen, bzip2, cgen, cygwin at https://cygwin.org/, debugedit, dwz, elfutils at http://elfutils.org, gccrs, gnu-abi, insight, kawa, libffi, libabigail, mauve, newlib, systemtap and valgrind at https://valgrind.org/.

A longer list of Sourceware projects, those without their own domain name, including several dormant projects, can be found here: https://sourceware.org/mailman/listinfo.

Most of these projects use a email/git based workflow using mailinglists for discussing patches in preference to web based “forges”.

Zero maintenance automation

Although email based git workflows are great for real patch discussions, they do not always make tracking the state of patches easy.

Just like our other services, such as bugzilla, mailinglists and git repos we like to provide zero maintenance infrastructure for tracking and automation of patches and testing.

So we are trying to consolidate around a shared buildbot for (test) automation and patchwork for tracking the state of contributions. By sharing experiences between the Sourceware projects and coordination and fully automating the infrastructure services.

A shared buildbot

We have a shared buildbot for Sourceware projects at https://builder.sourceware.org/. This includes compute resources (buildbot-workers) for various architectures thanks to some generous sponsors. We have native/VM workers for x86_64, ppc64le, s390x, ppc64, i386, arm64 and armhf for debian, fedora and centos (although not all combinations yet) and x86_64 container builders for fedora, debian and opensuse.

There are currently 95 builders on 15 workers, doing ~300 builds a day (more on week days, less on weekends). There are a couple of full testsuite builders (for gcc and binutils-gdb), but most builders are “quick” CI builders, which will sent email whenever a regression is detected. It seems to catch and report a couple of issues a week across all projects.

Builder is its own project on Sourceware which comes with its own git repo, mailinglist and amazing community, that can help you integrate new builders, add workers, containers and get you access to systems to replicate any failures where the buildbot logs don’t give enough information.

And buildbot itself is automated, so whenever a change is made to add a new builder, or define a new container, the buildbot automatically reconfigures itself and the workers will start using the new container images starting with the next build.

The same mechanism can also be used to run tasks on specific commits or periodically. Tasks which are now often done by a cron job or git hook. For example to update documentation, websites, generate release tars or update bugzilla. The advantage over cron jobs is that it can be done more immediately and/or only when really needed based on specific commit files. The advantage over git hooks is that they run in the builder context, not in the context of the specific user that pushed a commit.

Picking your (CI) tests

Although the buildbot itself is zero maintenance, getting and acting on the results of course is not. We already divide the tests into quick CI tests and full test runs. And most tests upload all results to bunsendb. bunsen can help pick good CI tests by indicating which tests are flaky or compare results across different setups.

A prototype testsuite log comparison bunsenweb widget is running at https://builder.sourceware.org/testruns/

Lots of things will be coming here, including taking advantage of testrun cluster analysis that’s already being done, a per-testrun testcase search/browse engine, other search operators, testsuite summary (vs detail) grids, who knows, ideas welcome!

What about pre-commit checks?

The builder CI checks what has been committed on the main branch of the projects. This makes sure that what is checked out is in a good state and that any pushed regressions are found early and often.

There is also support for git user try branches. When a user pushes to their try branch the same builder CI checks are ran, so a project developer knows their proposed patch(es) won’t break the build or introduce regressions.

The binutils and gdb communities are currently trying this out. Once new builder resources from OSUOSL are installed we’ll roll this out to other Sourceware projects.

What about non-committers?

The above only helps developers that have commit access on sourceware, but not others who sent in patches. For that we have https://patchwork.sourceware.org/ plus the CICD trybot that DJ wrote https://sourceware.org/glibc/wiki/CICDDesign. The glibc community is already using this. We would like to connect patchwork, buildbot and the trybot for other Sourceware projects

The current trybot doesn’t do authentication, this might not be OK for all builders. So we want to either require checking for known GPG keys on the patch emails or let a trusted developer set a flag in patchwork before the trybot triggers. Once we have public-inbox setup we could also use b4 for DKIM attestation for known/trusted hackers.

Some projects have already experimented with public-inbox. But we don’t have an instance running on sourceware itself yet. This would resolve complaints of not very usable mailman archives.

But I really like to have a webforge!

You are in luck. We already have a sourcehut mirror at https://sr.ht/~sourceware/ This allows anybody to fork any sourceware project on sourcehut, prepare their patches and submit a merge request through email (without having to locally setup git send-email or smtp – the patch emails are generated server side).

Sourcehut is designed around email based workflows, fully Free Software, doesn’t use javascript and is much faster and resource constrained compared to (proprietary) alternatives.

The sourcehut mirror is currently read-only (but syncs automatically with any git updates made on sourceware). When sourcehut supports project groups (one of the beta goals) we will test a self-hosted instance to see whether this is a good way to attract more contributors without loosing the advantages of the email based workflow. The various sr.ht components are very modular so we can only use those parts we need.