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
> > 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 for rsync method instead of using a chmod
> > command.
> > -Proposed by Ansgar Burchardt .
> > +- Do not change the file mode for Debian security uploads.
> > +Proposed by Ansgar Burchardt . Closes: #876900
> >
> > -- Guillem Jover 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