Hi! On Wed, 2018-02-14 at 15:44:11 +0100, Aurelien Jarno wrote: > On 2017-10-11 19:03, Guillem Jover wrote: > > commit ef0b3caaced32728f6918900192c02a55a27072f > > Author: Guillem Jover <guil...@debian.org> > > Date: Tue Oct 10 18:25:02 2017 +0200 > > > > Do not change the file mode for security uploads > > > > Closes: #876900 > > > > diff --git a/debian/changelog b/debian/changelog > > index 1c54754..922a5e8 100644 > > --- a/debian/changelog > > +++ b/debian/changelog > > @@ -12,7 +12,8 @@ dupload (2.9.1) UNRELEASED; urgency=medium > > - Switch rsync method to use -L and -t instead of -a. > > - Add a new host filemode option to configure the destination files > > mode. > > - Use --chmod=F<mode> for rsync method instead of using a chmod > > command. > > - Proposed by Ansgar Burchardt <ans...@debian.org>. > > + - Do not change the file mode for Debian security uploads. > > + Proposed by Ansgar Burchardt <ans...@debian.org>. Closes: #876900 > > > > -- Guillem Jover <guil...@debian.org> Thu, 24 Aug 2017 20:45:05 +0200 > > Do you think such changes can be backported to stretch? That would be > very useful for the build daemons.
I assume you mean all the "Improve file mode handling" related changes here? And with backport do you mean cherry-picking those and preparing a stable update, or doing a stable backport? > If you lack time, I can try to do the backport myself and provide you > the patches. Just ask. The code has seen some code churn/cleanup so cherry-picking feels dangerous for a stable update, more so given that it would lose all the testing from buster/sid, it would also involve including new features and config file changes, so I'd be quite hesitant to do that. If you mean a package backport, I'd be fine with that, and don't mind if you'd want to prepare/maintain it? Thanks, Guillem
