On 1/15/25 17:19, Thomas Lamprecht wrote:
Am 08.01.25 um 09:45 schrieb Dominik Csapak:
The http status code 501 is meant to be 'Not Implemented'[0] but that
clearly does not fit here as the default error when we encounter a
problem during handling an api request or upload.
Not sure about the c
On 1/15/25 17:08, Thomas Lamprecht wrote:
Am 08.01.25 um 09:45 schrieb Dominik Csapak:
In our rust client, we can't access the http reason phrases[0], so let's
put them into the body itself if we don't specify an explicit content.
our proxmox-client code in rust already uses the body as message
Am 03.01.25 um 16:57 schrieb Fiona Ebner:
> During virtual machine creation, the machine version is pinned when
> the guest OS is Windows. The same should be done when the guest OS
> type is newly set to Windows for consistency.
>
> Signed-off-by: Fiona Ebner
> ---
>
> RFC because it is rather a
Am 03.01.25 um 16:57 schrieb Fiona Ebner:
> In commit a35f8577a0 ("include/hw: add macros for deprecation &
> removal of versioned machines"), a new machine version deprecation and
> removal policy was introduced. After only 3 years a machine version
> will be deprecated while being removed after 6
Am 08.01.25 um 14:03 schrieb Fiona Ebner:
> Setting blk->root is a graph change operation and thus needs to be
> protected by the block graph write lock in blk_remove_bs(). The
> assignment to blk->root in blk_insert_bs() is already protected by
> the block graph write lock.
>
> In particular, the
Am 21.11.24 um 15:28 schrieb Maximiliano Sandoval:
> Splitting translatable strings deprives translators for context which
> might be needed for getting the correct tenses or genders. See [1] for
> example.
>
> [1]
> https://wiki.gnome.org/TranslationProject(2f)DevGuidelines(2f)Never(20)split(20)
Am 08.01.25 um 09:45 schrieb Dominik Csapak:
> The http status code 501 is meant to be 'Not Implemented'[0] but that
> clearly does not fit here as the default error when we encounter a
> problem during handling an api request or upload.
Not sure about the clearly; 501 is not a 404 like error but
--- Begin Message ---
Il 15/01/2025 10:00, Daniel Kral ha scritto:
On 1/13/25 13:24, Fabio Fantoni wrote:
btrfs profiles work differently but other hardware or software raids,
many users may not inform themselves well beforehand but even in the
case of informed users even if technically now btrf
Am 08.01.25 um 09:45 schrieb Dominik Csapak:
> In our rust client, we can't access the http reason phrases[0], so let's
> put them into the body itself if we don't specify an explicit content.
>
> our proxmox-client code in rust already uses the body as message if
> there is one [1], so we get tha
Am 12.12.24 um 18:01 schrieb Stoiko Ivanov:
> drop the cherry-picked kernel 6.11 compatibility patches.
>
> this upstream release [0] is a bit larger than usual, and might have a bit
> of potential for regressions.
>
> apart from the compatibilty fixes for newer kernels (up until 6.12),
> fixes t
Maximiliano Sandoval writes:
> Splitting translatable strings deprives translators for context which
> might be needed for getting the correct tenses or genders. See [1] for
> example.
>
> [1]
> https://wiki.gnome.org/TranslationProject(2f)DevGuidelines(2f)Never(20)split(20)sentences.html
>
>
When using arch aarch64 for a VM in combination with new enough Windows
OS type the VM start fails:
> qemu-system-aarch64: -device tpm-tis,tpmdev=tpmdev: 'tpm-tis' is not a valid
> device model name
QEMU uses the `tpm-tis-device` device model for ARM[0] and RISCV[1]
instead of the `tmp-tis` whic
Jing Luo via pve-devel writes:
> -extended description over several lines (indended by space) may follow.
> +extended description over several lines (intended by space) may follow.
I think this should be "indented" instead of indended or intended.
> @@ -517,7 +517,7 @@ All generated templates
--- Begin Message ---
> Fiona Ebner hat am 15.01.2025 11:06 CET
> geschrieben:
>
>
> Am 15.01.25 um 10:51 schrieb Fabian Grünbichler:
> >
> > basically what we have is the following situation:
> >
> > - we have some input data (volid+snapname)
> > - we have a key derived from the input data
applied, with Gabriel's R-b, thanks!
I left out editing the Clipboard to clipboard for now, we got more
broken/mixed instances of that, and IMO it would be better to fix
them in the English original first.
___
pve-devel mailing list
pve-devel@lists.pro
Am 13.01.25 um 16:27 schrieb Jing Luo:
> complained by lintian.
>
> Signed-off-by: Jing Luo
> ---
> dab | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>
applied, thanks!
___
pve-devel mailing list
pve-devel@lists.proxmox.com
http
On Thu, 12 Dec 2024 18:01:45 +0100
Stoiko Ivanov wrote:
> drop the cherry-picked kernel 6.11 compatibility patches.
>
> this upstream release [0] is a bit larger than usual, and might have a bit
> of potential for regressions.
While catching up on upstream's changes (in context of the 2.3.0 rel
Am 15.01.25 um 10:59 schrieb Dominik Csapak:
> pvesm export is mostly used for (remote) migrations, where the
> status progress output lands in a task log. For task logs we want to
> have line based output (since it's not a terminal), but dd uses \r
> to overwrite the same line which does not work
Am 15.01.25 um 11:50 schrieb Fabian Grünbichler:
>
>> Fiona Ebner hat am 15.01.2025 11:46 CET geschrieben:
>>
>>
>> Am 15.01.25 um 11:15 schrieb Fabian Grünbichler:
>>>
Fiona Ebner hat am 15.01.2025 11:06 CET geschrieben:
Am 15.01.25 um 10:51 schrieb Fabian Grünbichler:
>
> Fiona Ebner hat am 15.01.2025 11:46 CET geschrieben:
>
>
> Am 15.01.25 um 11:15 schrieb Fabian Grünbichler:
> >
> >> Fiona Ebner hat am 15.01.2025 11:06 CET geschrieben:
> >>
> >>
> >> Am 15.01.25 um 10:51 schrieb Fabian Grünbichler:
> >>>
> >>> basically what we have is the following si
Am 15.01.25 um 11:15 schrieb Fabian Grünbichler:
>
>> Fiona Ebner hat am 15.01.2025 11:06 CET geschrieben:
>>
>>
>> Am 15.01.25 um 10:51 schrieb Fabian Grünbichler:
>>>
>>> basically what we have is the following situation:
>>>
>>> - we have some input data (volid+snapname)
>>> - we have a key
--- Begin Message ---
IMHO this isn't really a cryptographic use case, so I'd not worry too
much about any of that.
basically what we have is the following situation:
- we have some input data (volid+snapname)
- we have a key derived from the input data (block node name)
- we have a value (block
> Fiona Ebner hat am 15.01.2025 11:06 CET geschrieben:
>
>
> Am 15.01.25 um 10:51 schrieb Fabian Grünbichler:
> >
> > basically what we have is the following situation:
> >
> > - we have some input data (volid+snapname)
> > - we have a key derived from the input data (block node name)
> > -
Am 15.01.25 um 10:51 schrieb Fabian Grünbichler:
>
>> Fiona Ebner hat am 15.01.2025 10:39 CET geschrieben:
>>
>>
>> Am 14.01.25 um 11:03 schrieb DERUMIER, Alexandre:
> If we do need lookup, an idea to get around the character limit is
> using
> a hash of the information to generate
oops, i accidentally committed a change from 4k -> 64k in the bs parameter that
i added for testing
for comments, please disregard this change, this was unrelated and only for me
to test
if we could get more performance out of the export (did not do too much testing
there
yet)
On 1/15/25 10:5
pvesm export is mostly used for (remote) migrations, where the
status progress output lands in a task log. For task logs we want to
have line based output (since it's not a terminal), but dd uses \r
to overwrite the same line which does not work in every situation, e.g.
browsers sometimes simply do
> Fiona Ebner hat am 15.01.2025 10:39 CET geschrieben:
>
>
> Am 14.01.25 um 11:03 schrieb DERUMIER, Alexandre:
> >>> If we do need lookup, an idea to get around the character limit is
> >>> using
> >>> a hash of the information to generate the node name, e.g.
> >>> hash("fmt-$volid@$snapname")
Am 14.01.25 um 11:03 schrieb DERUMIER, Alexandre:
>>> If we do need lookup, an idea to get around the character limit is
>>> using
>>> a hash of the information to generate the node name, e.g.
>>> hash("fmt-$volid@$snapname"), hash("file-$volid@$snapname") or
>>> whatever
>
> yes, I think it shoul
On 1/13/25 13:24, Fabio Fantoni wrote:
btrfs profiles work differently but other hardware or software raids,
many users may not inform themselves well beforehand but even in the
case of informed users even if technically now btrfs allows lower limits
with the creation of raid 0 (and raid10) I t
29 matches
Mail list logo
