-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
http 2.0.0 #160
http 2.0.0 #160
Conversation
Only try BLKGETSIZE on blockdevs, use BLKGETSIZE64 instead of BLKGETSIZE, store BLKGETSIZE64 a u64 and then "as _" at point-of-use (musl). Closes: #155
… time from readEntries()
Reported by roz@rozbrajacz.futbol: warning: call to `.borrow()` on a reference in this situation does nothing --> src/ops/webdav.rs:752:42 | 752 | for prop_namespace in props.map(|p| p.borrow().borrow_xml_name()).flat_map(|p| p.namespace).unique() { | ^^^^^^^^^ help: remove this redundant call | = note: the type `N` does not implement `Borrow`, so calling `borrow` on `&N` copies the reference, which does not do anything and can be removed = note: `#[warn(noop_method_call)]` on by default warning: `https` (bin "http") generated 1 warning (run `cargo fix --bin "http"` to apply 1 suggestion) Finished dev [unoptimized + debuginfo] target(s) in 6.59s warning: the following packages contain code that will be rejected by a future version of Rust: traitobject v0.1.0 note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`
Thanks to Peter for unpromptedly noting you need AR=/usr/gnu/bin/ar to build on the illumos gate: https://101010.pl/@ptribble@mastodon.social/111714709767618224
…s changes (davfs2)
… to answer cached-as-incompressible files
… limit the on-disk cache size, in-memory cache size, and cache retention time (now LRU)
…ivial string operations
Real diffstat (not including vendored deps):
|
aaaand here's the issue:
god. |
Yeah okay this is rust-lang/cargo#1565 And this would involve publishing three different pieces of shit (the vendored deps), then fucking up our dependencies, then publishing http directly. On every release. cargo resists being useful at every step of the way I am instead opting to re-route our release model as
|
he he he |
Actually the best course of action would be to unprotect Rest assured that many versions of this were developed and thoroughly tested by serving all |
Have you basically baked in a good few of our dependencies? How come no more crates.io deploy? |
Yes, three deps are vendored now because we need to patch them (for both security advisories and performance). As for the latter: #160 (comment) |
Is this saying that it refuses to build using our baked in dependencies? That seems very stupid 😞 |
it is very stupid yes |
Whilst very sucky... is there anything to be said for forking those 'vendor' libs so we can have a lib that we can then 'just use' here? |
There is in that, after vendoring, i did fork them by editing them. But separating them out more is equivalent to keeping them in-tree: it would also mean uploading them all to crates.io, each time, if that's even possible (because we do need to explicitly override a dep in our |
so either we have:
cool |
Hotfix in 2.0.1 in #161 |
There's a potential release issue in that fuck knows how well cargo will take to our overrides. And that can only be tested live. So I'm gonna be testing it live in a bit.
BREAKING:
Fixed:
Changed:
New:
Internal:
i: affects vendored iron; h: affects vendored hyper; r: affects vendored rfsapi
Closes: #140