| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Currently cargo-license mangles libm's Cargo.toml information very badly!
And also our licence checker script is rather too stupid to do the
boolean logic. I have a better licence checker elsewhere, in a
personal project but ... it's GPL'd :-).
https://salsa.debian.org/dgit-team/tag2upload-service-manager/-/blob/main/maint/check-licences?ref_type=heads
|
| | |
|
| |
|
|
|
|
|
| |
The script is a bit tricky because it needs to set arguments
correctly, use the right dependencies, treat packages differently
from scripts, and find all of the packages and scripts
in our repository.
|
| |
|
|
| |
For some reason this will soon be necessary with mypy.
|
| |
|
|
|
|
| |
This has a little complexity since beautifulsoup4 is fairly well
duck-typed, but it also has type annotations to describe its
duck-typing.
|
| | |
|
| |
|
|
|
|
| |
The `black` formatter did most line wrapping for us, and we accept
its default of 88 characters there, but for comments and docstrings
(which black doesn't wrap) we allow up to 99 characters.
|
| | |
|
| | |
|
| |
|
|
|
| |
(Python coding style guide and lint tools deprecate it,
even if your font distinguishes l, 1, I, and |.)
|
| | |
|
| |
|
|
| |
Due to precedence, both work the same, but the former is preferred.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Black" is an "opinionated" python formatter, whose opinionatedness
is somewhat in the spirit of rustfmt.
This MR runs black with default settings on all of our python code
in Arti. It was produced by the following commands
```
# Everything in python/
black python/
# Everything with a .py extension
fd '.py$' -X black
# Everything with a python shebang.
git grep -l '#! */usr/bin/env *python' | xargs black
```
|
| | |
|
| |
|
|
|
| |
Additionally, document that this tool requires particular versions
of nightly, since the rustdoc json format is unstable.
|
| | |
|
| |
|
|
| |
This is very useful when iterating through CI.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This new feature lets us provide the "enable these options which are
needed to make the tests pass" featrure, which is different for each
of the afflicted crates. Then we can test these crates
tor-hsservice
arti
arti-client
which minimal features.
This will be important in a moment, as we're going to want to be
relying on actually minimal features tests in arti cfg.rs.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Python tool to build RPC method/type documentation.
See merge request tpo/core/arti!2479
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Uses the RPC library to extract a list of RPC methods and objects;
uses rustdoc-nightly to extract documentation for them;
outputs a markdown document.
|
| | |
| |
| |
| |
| | |
Prompted by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2488#note_3087164
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
tor-llcrypto: replace simple_asn1 dependency with der-parser
Closes #1632
See merge request tpo/core/arti!2462
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
| |
This will allow us to upgrade to the latest version of rusqlite.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Adding an exception for now, as per #1608
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes the `minimal-versions` failure:
```
error: package ID specification `[email protected]` did not match any packages
Did you mean one of these?
[email protected]
```
(we don't actually need to un-downgrade `futures-lite` anymore)
But we *do* need to un-downgrade `event-listener`
(`async-global-executor` needs `event_listener::EventListener` to be `UnwindSafe`,
and in `event-listener 3.0.0`, they are not)
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Fix reproducible build CI job for macOS
Closes #1394 and #1507
See merge request tpo/core/arti!2377
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
osxcross tries in various ways to detect which version of the compiler
we have, which version of the OS, which C++ standard library we use, and
many other things. With this variable set, osxcross seems able to detect
the environment provided by the SDK that we use.
The error messages from osxcross is as follows:
osxcross: error: cannot find libc++ headers
osxcross: error: while detecting target
This origins from its internal target detection code in target.cpp of
osxcross. This file contains a signficant amount of the detection for
paths of different versions of the macOS SDK's and macOS versions. All
of this is truly cursed.
In osxcross's main.cpp, the variable is read in:
if (char *p = getenv("MACOSX_DEPLOYMENT_TARGET")) {
target.OSNum = parseOSVersion(p);
unsetenv("MACOSX_DEPLOYMENT_TARGET");
}
and setting it thus forces the OS version to be parsed from the variable
instead of its (in our case failed) attempt at detecting the version
itself.
Fixes: tpo/core/arti#1394
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
Run tests of every crate, with all features disabled
See merge request tpo/core/arti!2350
|
