From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 9B66D1FF17E for ; Thu, 13 Nov 2025 13:46:56 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 2161E1B2D9; Thu, 13 Nov 2025 13:47:51 +0100 (CET) Mime-Version: 1.0 Date: Thu, 13 Nov 2025 13:47:18 +0100 Message-Id: From: "Lukas Wagner" To: "Thomas Lamprecht" , "Proxmox Backup Server development discussion" , "Shannon Sterz" X-Mailer: aerc 0.21.0-0-g5549850facc2-dirty References: <20251113114014.308133-1-s.sterz@proxmox.com> <01a612c8-42b3-4d75-86b2-80a88c3a0262@proxmox.com> In-Reply-To: <01a612c8-42b3-4d75-86b2-80a88c3a0262@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1763038012460 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.030 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox-backup] notifications: adapt to proxmox-apt making old_version optional X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Backup Server development discussion Cc: Lukas Wagner Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" On Thu Nov 13, 2025 at 1:16 PM CET, Thomas Lamprecht wrote: > Am 13.11.25 um 12:40 schrieb Shannon Sterz: >> Signed-off-by: Shannon Sterz >> --- >> src/server/notifications/template_data.rs | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/src/server/notifications/template_data.rs b/src/server/notifications/template_data.rs >> index 0dcc5ed3..9adc4699 100644 >> --- a/src/server/notifications/template_data.rs >> +++ b/src/server/notifications/template_data.rs >> @@ -177,7 +177,7 @@ impl PackageUpdatesTemplateData { >> .map(|info| UpgradablePackage { >> package_name: info.package.clone(), >> available_version: info.version.clone(), >> - installed_version: info.old_version.clone(), >> + installed_version: info.old_version.clone().unwrap_or_default(), >> }) >> .collect(), >> } > > What about adapting installed_version to reality and make it also an > option? I mean, depends a bit on how handlebars will handle such things > then, and also how willing we're adopting light breakage if it fixes > wrong historic assumptions. > > Our shipped template for this default/package-updates-body.txt.hbs should > be updated in any case though, maybe special case the no installed_version, > be that None or "", and add a NEW or something like that there. Yes, I think adapting the template would definitely makes sense. I vaguely remember seeing "null" entries there at some point but didn't investigate back then; I guess these must have been new packages. With regards to adapting the `installed_version` member, once the template is adapted, it probably does not make difference for the template, since both `null` and `""` would evaluate to 'false' in the if-statement which would need to be added. But for correctness, changing it to be an Option definitely makes sense to me. _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel