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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
it's the version currently shipped by bookworm, so let's unify this widely-used
dependency to make bootstrapping easier.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
these two functions don't actually use the `type_name` parameter, but the
interface including custom formatters require it.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
HashMaps are not ordered, so each package build containing a section config
dump would have the documentation ordered randomly.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Mostly relevant when the config is written out again after parsing it
with unknown sections. Previously, with duplicate keys, only the last
value would be saved. Now, duplicate keys are assumed to be part of
an array schema and handled as such.
Because the unknown section parsing does not know if a certain
property does actually have an array schema, it's not possible to
detect duplicate keys for non-array-schema properties, and if a
property with array-schema shows up only once, it will not be saved as
a Value::Array, but a Value::String.
Writing, or to be precise the format_section_content methods, already
handle Value::Array, so don't need to be adapted.
Fixes: 0cd0d16 ("section config: support allowing unknown section types")
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
while these are (currently) only used by a single member each, having *all*
dependency versions specified in the top level Cargo.toml only makes the whole
process of managing them less error-prone.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
- proxmox_io::boxed::uninitialized(len) -> Box<[u8]>
same as vec::uninitialized, but as a box
- proxmox_io::boxed::zeroed(len) -> Box<[u8]>
same as vec::zeroed, but as a box
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
so that we no longer have to (or forget to) bump the version in multiple places.
notable changes:
- outdated versions have been unified
- proxmox-metrics -> proxmox-async no longer uses explicit empty features
(proxmox-async doesn't provide any anyway)
- proxmox-subscription -> proxmox-http no longer uses explicit default_features
= false (proxmox-http has an empty default feature anyway)
- missing path dependencies added (mainly proxmox-rest-server)
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
noteworthy changes:
- proxmox-http had a default_features_false dep on hyper, which is dropped (the
default feature is empty anyway)
- hyper, libc, nix, tokio and url versions are unified
- missing (cosmetic) bindgen feature on zstd enabled everywhere
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Similar to commit c9ede1c ("support unknown types in section config")
in pve-common.
Unknown sections are parsed as String-JSON String key-value pairs
without any additional checks and also written as-is.
Suggested-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
we already expose the raw sections which are sometimes
easier to use, but we don't expose the order at all this way
otherwise
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Additional properties will be parsed according to the default string
schema.
This is relevant for use cases when the full schema is not known for
some reason or another. In particular this allows support for parsing
older/newer versions of configuration files. One example of this is
the proposed proxmox-mail-forward helper binary, which currently
doesn't have access to the PBS API types for dependency reasons and
is only interested in the email field for the root user. If it can
only use a minimal schema with additional_properties set to true, it
will be robust against changes.
Writing already works, because the ObjectSchema's verify_json()
already handles additional_properties correctly and
format_section_content() handles them like all other properties
(method doesn't depend on the schema).
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
