so ardumont, just use:

ok, my nix setup conflicts!

As user:

pkg-config --debug libsystemd
no output option set, defaulting to --exists
Error printing disabled by default due to use of output options --exists, --atleast/exact/max-version, --list-all or no output option at all. Value of --print-errors: 0
Error printing disabled
Adding virtual 'pkg-config' package to list of known packages
Looking for package 'libsystemd'
Looking for package 'libsystemd-uninstalled'

thanks for the pointer !

The most recent update of the state of this task has shown a regression in the journal test coverage, which, per se, is not a big deal (just a few points). But it does raise the question of how, once we have attained whatever "minimum" coverage we are OK with, we monitor overtime that there is no regression. For instance, I think that code reviews should show to the reviewers how the submitted diff affects code coverage. Ideally, reviewers should be able to so if it has a net positive or negative effect on coverage, and take that into account in their review decisions. (Which is not to say we should never accept diffs that decrease code coverage—there might be reasons to do so. But it is a data point that would be useful for reviewers to see.)

In T1689#31540, @olasd wrote:

IMy suggestion was having *someone* trigger the merge with a comment on the diff, once the tests pass.

In T1689#31539, @zack wrote:

I'm not a fan of automated merging when the test suite passes. I think merging code from third parties should always be a manual step by someone. If it can be made a Web UI button, even better, if not we will just standardize to the local arc workflow, which I've recently documented in the wiki.

Thanks for the investigation @olasd.

(looks like Herald can't easily trigger on a comment, because that'd be too easy)

So, according to the fine manual (https://secure.phabricator.com/book/phabricator/article/differential_land/) the "Land Revision" button on the Phabricator user interface depends on setting up:

• Drydock repository automation : https://secure.phabricator.com/book/phabricator/article/drydock_repository_automation/
• Which depends on setting up Drydock working copies : https://secure.phabricator.com/book/phabricator/article/drydock_working_copies/
• Which depends on setting up Drydock hosts : https://secure.phabricator.com/book/phabricator/article/drydock_hosts/
• Which depends on Almanac : https://secure.phabricator.com/book/phabricator/article/almanac/

Closing this as I forgot it exists a configuration entry to force the serving of assets by Django (https://forge.softwareheritage.org/rCDFD7b3213293ca1670a738d540cbba05e87e5cf6042).

This script is obsolete now that we migrated to git-buildpackage.

Seems to be fixed since 2019-02-12.

Fix indentation (missing 4 spaces)

The closure was a lie

The first publication round has been done by hand.

(i've retitled this according to consensus)

All tests in our unittest.TestCases are now named test_$something, which allows them to be picked up by pytest.

No objections here either.

nice regexp-fu. We just have to make sure "grep 'istest'" doesn't return anything afterward

I've submitted D516 as a showcase of a testsuite migration that would allow running pytest on swh.core

In T1261#23444, @olasd wrote:

find . -name 'test_*.py' -exec sed -i -e '/@istest/!b;n;s/def /def test_/' '{}' \+

According to the docs [1], it supports the unittest-like tests natively anyway: 'pytest supports running Python unittest-based tests out of the box.'