Hello all, On Tue, Feb 02, 2021 at 03:08:49PM +0100, Bastian Germann wrote: > Source: libubootenv > Version: 0.3-1 > > A new upstream version 0.3.1 is available for quite some time now. It would > be great to have the package updated in the next few days to that version so > that it can be released with bullseye.
I'd also like to see the new upstream version pushed into bullseye, and possibly cherry-pick if not all then atleast some of the fixes on master as well! I'm willing to do this via NMU if needed/wanted! Would very much like to hear from maintainer(s) if and how you'd like to proceed on this. (Use 0.3.1 release? cherry-pick all/some/none of the master commits? Upload first the debug output fix separately or do one upload that fixes both the debug output problem as well as updates to the new upstream release? Do you have time for this or is it ok if I take it on via NMU?) The fixes in v0.3..v0.3.1 seems really bad to miss out on, but the fixes on master is also all quite useful to include. (Personally I'm not a fan of the new fw_printenv/fw_setenv breaking alot of the long-standing ways the old implementation works and would rather revert back to Debian using the old implementation again until libubootenv matures a bit more, but that might be too late now. But if we're going to stay with libubootenv-tool for bullseye, then we atleast need to fix it up.... URGENTLY!) If not everything on master gets included, I'd personally wish for atleast this one to be cherry-picked because it fixes an unwanted behavioural change: https://github.com/sbabic/libubootenv/commit/20d1ec784eda20f8b5a09e9dd8b186b1a3626b14 I've chatted a bit with the release-team about possibility to get it unblocked at this point in the freeze and they strongly hinted than manual unblock requests are not needed for packages that have (non-trivial) autopkgtests! I'm no autopkgtest expert, but this was enough motivation for me to add an autopkgtest in https://salsa.debian.org/debian/libubootenv/-/merge_requests/3 Help with adding more autopkgtests would be welcome! (I'm personally willing to write one for the commit I linked to above atleast, which could be implemented as simply a cleanup of the smoketest where I currently had to work around fw_setenv (without arguments) not being able to write a default (empty) environment by passing it a key and value to initialize the environment.) Regards, Andreas Henriksson
