Re: Bug#962596: Backport to stretch?
Hi, On Mon, Feb 1, 2021 at 9:48 PM Julien Cristau wrote: > stretch is EOL, so I am not planning on touching it myself. > Cc:ing the team that looks after stretch-lts in case they want to handle > this. Thanks, I'll start to take a look at it. IIUC, this commit[1] needs a backport to stretch, correct? [1]: https://salsa.debian.org/debian/ca-certificates/-/commit/62a6fc666ddc27baa0150e2b210814ecf1fc587e - u
(E)LTS report for January 2021
hi, in January 2021 I spent 6.5h managing (E)LTS contributors: - dispatching work hours for LTS and ELTS - preparing the monthly Freexian blog post published on raphaelhertzog.com - prepare and run the monthly team meeting on irc - mail and irc communication, incl. - semi-automatic unclaim packages - too many claimed packages - missing DLAs on www.d.o - sudo DLA post mortem - merging merge requests for webwml.git - announce EOL of reel in stretch via DLA-2532-1 -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
How to backport test binaries?
Hello, On several occasions, I've seen that fixing commits of CVEs have some sort of binaries (either an image or some compressed file or whatever) added as a test to ensure that the fix is indeed working as expected. And whilst trying to backport, the patches don't seem to like git binaries and so they complain with: ```git binary diffs are not supported``` How do we work around that? Do we not backport these binaries and just test the upstream way? I'd like to backport such binaries but unsure how to. Let me know how do y'all deal with this. - u
