IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
I was informed that fuzzit-1.1 is going to be deprecated soon. Generally
the latest version isn't recommened because it's still in beta and theoretically
might be backwards incompatible but let's try rolling forward to avoid PRs
like this going forward. We can always roll it back :-)
Now that v243 is out, the script has been pulled by forks that are
activated on Travis CI. As a result, all those forks have started to send
their fuzzers to Fuzzit inadvertantly consuming our CPUs along the way.
Let's prevent this by bailing out early if the script is run outside of
the systemd repository.
includes two travis ci steps:
1) Every pull-request/push all fuzzing targets will do a quick
sanity run on the generated corpus and crashes (via Fuzzit)
2) On a daily basis the fuzzing targets will be compiled (from
master) and will and their respectible fuzzing job on Fuzzit
will be updated to the new binary.
As we build a custom Docker image, we need to ensure that systemd
correctly detects it's running in a container. One can simply do this
directly in a Dockerfile (ENV container docker) or when starting the
container (-e container=docker). For the sake of readability, let's
pick the latter approach here.
Now that https://github.com/systemd/systemd/pull/12542 is merged,
fuzzbuzz.sh should be changed a little bit to make it work
on Azure Pipelines. We can no longer assume that source repositories
are added "automagically" by Travis CI or that PATH is set properly.
The test has been flaky since varlink was merged.
Let's not annoy people with the test that fails more often than not.
It should be OK because the same test is run on Arch.
These were never set explictily because we relied on Travis CI
canceling a job if it's been stuck for 10 minutes. Now that
the script is run on Azure Pipelines (where the default timeout
is 60 minutes) we should limit the script manually to avoid waiting
for an hour for broken jobs to finish.
This makes the default build much quicker. If people are building systemd for
packaging or actual installation, they probably need to set some more options
anyway (-Ddns-servers=, -Dntp-servers=), so adding -Dman=true is not a big
burden.
For CIs configured locally, -Dman=true is added to restore status quo ante.
We had all kinds of indentation: 2 sp, 3 sp, 4 sp, 8 sp, and mixed.
4 sp was the most common, in particular the majority of scripts under test/
used that. Let's standarize on 4 sp, because many commandlines are long and
there's a lot of nesting, and with 8sp indentation less stuff fits. 4 sp
also seems to be the default indentation, so this will make it less likely
that people will mess up if they don't load the editor config. (I think people
often use vi, and vi has no support to load project-wide configuration
automatically. We distribute a .vimrc file, but it is not loaded by default,
and even the instructions in it seem to discourage its use for security
reasons.)
Also remove the few vim config lines that were left. We should either have them
on all files, or none.
Also remove some strange stuff like '#!/bin/env bash', yikes.
Now that add-apt-repository hasn't failed for almost two days on Semaphore
it should be safe to assume that the key has been propagated properly
and the repository is ready to be used on Travis CI.
