4 gigs is still a common amount of RAM these days for laptops, if the VM
takes almost all of that, it makes the machine drag to almost a halt. Most
apps build fine in 1gig of RAM, indeed that's the default for most CI
instances, like travis-ci and gitlab-ci.
Right now, the git pre-commit hook is pretty annoying to work with when
development since it tests every single file. That means notes, incomplete
stuff, etc. will be run through the tests. So all of the files need to be
clean in order to commit even a single trivial fix. This commit changes it
so that the pre-commit hook is only run on the files staged to be committed.
I was wrong - we don't check for trailing whitespaces on lines. That
would have to happen at parse time, not in the linter, so it would slow
things down and would become an error, not a warning. Not really worth
it.
1. It is packaged in modern versions of distros, update docs accordingly
2. 1.1 is hopelessly outdated - support 1.4 onwards
3. Check the version properly, and write a better config (previously it
wrote the 1.1 config for 1.1 and 1.3+
4. Ensure that the default share from later versions is not present when
building, it's only required for provisioning.
On slow machines or VMs like the Debian jenkins box, the VM boot timeout
needs to be a lot longer, otherwise vagrant times out before setting up
the VM.
Setting it in the config file was not working, and right now, all of the
options are in the config file and not as command line flags, so remove
--debian-mirror to keep that consistent.
Makebuildserver for debian jenkins
@mvdan and I worked out a plan with Holger, the Debian Developer running the reproducible builds jenkins build farm. The idea is for that to just run `./makebuildserver` in the jenkins script. Then we'll make sure that it works. This also makes it easy for anyone to set up and run an FDroid build instance, which is important for things like the verification server and for people to be able to run reproducible builds on their own machine.
This does change some of the defaults, but they can all be overridden in the `makebs.config.py` for f-droid.org.
More comments in the commits.
See merge request !89
This also provides a config option to override that default. ~/.cache is
a standard location on GNU/Linux machines for cached content. It is also
good to have the cache outside of the git repo in case `git clean -fdx` is
run, which would delete all files in the directory that are not part of the
git repo, including buildserver/cache/
This makes it so that ./makebuildserver will run without any config file,
using the defaults that are embedded in the script itself. This is like
how `fdroid` works.
This host automatically detects which is the closest mirror, then uses that
one. It does so dynamically, so it'll work on machines that move too. Now
that we are pushing more people to run F-Droid build servers, the defaults
should take those use cases into account.
This keeps the numbers of names down to a minimum, and since the config
is placed right next to the script, this keeps tab completion working
nicely when the config file is in place.
The old file name is still supported.
I really hope I can revert this in the near future. Having to mutilate
my name just so that pip will work is a terrible workaround.
For better or worse, this only affects scripts defined in setup.py.
Since we only sorted by count, ignoring the string, it meant that items
with the same count might be arranged in different manners. Hence the
`stats` behaviour was not predictable at all. Now it sorts first by
count, then by string.
It is a good idea in theory, especially for extra tasks specified by the
user. But in practice, tasks specified by developers often don't have a
clean counterpart. So this just breaks the build.
We were passing the utf-8 encoded string to textwrap, which took the
bytes as characters. Hence multi-byte unicode characters (in utf-8)
would count as multiple columns, which is clearly wrong.
Add Author Name and Author Email fields. (Closes: #90)
Adds the two new fields as discussed in issue #90. Both are optional.
Mind that the Wiki template needs to be extended before merging.
See merge request !87
