From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id ED86960BA7 for <pve-devel@lists.proxmox.com>; Thu, 13 Jan 2022 17:21:27 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E40A92110F for <pve-devel@lists.proxmox.com>; Thu, 13 Jan 2022 17:20:57 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 7152921101 for <pve-devel@lists.proxmox.com>; Thu, 13 Jan 2022 17:20:57 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 4565746B2C for <pve-devel@lists.proxmox.com>; Thu, 13 Jan 2022 17:20:57 +0100 (CET) Message-ID: <688038e8-1cb6-4cf6-2058-ee793b67bda0@proxmox.com> Date: Thu, 13 Jan 2022 17:20:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Thunderbird/97.0 Content-Language: en-US To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>, Dominik Csapak <d.csapak@proxmox.com> References: <20211201085514.1648428-1-d.csapak@proxmox.com> <20211201085514.1648428-3-d.csapak@proxmox.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> In-Reply-To: <20211201085514.1648428-3-d.csapak@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.058 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [calendarevent.pm] Subject: Re: [pve-devel] [PATCH common 1/1] CalendarEvent: use rust implementation X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Thu, 13 Jan 2022 16:21:28 -0000 On 01.12.21 09:55, Dominik Csapak wrote: > by replacing the parsing code and 'compute_next_event' by their > PVE::RS::CalendarEvent equivalent > > adapt the tests, since we do not have access to the internal structure > (and even if we had, it would be different) and the error messages > are different > > the 'compute_next_event' and parsing tests still pass though > > Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> > --- > src/PVE/CalendarEvent.pm | 251 +----------------------------------- > test/calendar_event_test.pl | 42 +++--- > 2 files changed, 23 insertions(+), 270 deletions(-) > > diff --git a/src/PVE/CalendarEvent.pm b/src/PVE/CalendarEvent.pm > index 56e9923..e2bf53a 100644 > --- a/src/PVE/CalendarEvent.pm > +++ b/src/PVE/CalendarEvent.pm > @@ -6,6 +6,7 @@ use Data::Dumper; > use Time::Local; > use PVE::JSONSchema; > use PVE::Tools qw(trim); > +use PVE::RS::CalendarEvent; this is actually not ideal as pve-common is also used in PMG and for some infra stuff, so pve-rs isn't available there everywhere... hacked around that for now by just dropping the d/control dependency for now, as I depend on the correct pve-rs version in pve-manager directly anyway...