lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7c55aa3f-1027-a640-9501-55502fd2745d@linuxfoundation.org>
Date:   Wed, 1 Jul 2020 09:34:38 -0600
From:   Shuah Khan <skhan@...uxfoundation.org>
To:     Sasha Levin <sashal@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
        linux@...ck-us.net, shuah@...nel.org, patches@...nelci.org,
        ben.hutchings@...ethink.co.uk, lkft-triage@...ts.linaro.org,
        skhan@...uxfoundation.org
Subject: Re: [PATCH 5.7 000/265] 5.7.7-rc1 review

On 7/1/20 8:40 AM, Sasha Levin wrote:
> On Tue, Jun 30, 2020 at 05:33:25PM +0200, Greg Kroah-Hartman wrote:
>> On Tue, Jun 30, 2020 at 11:12:48AM -0400, Sasha Levin wrote:
>>> On Tue, Jun 30, 2020 at 10:38:45AM +0200, Greg Kroah-Hartman wrote:
>>> > On Mon, Jun 29, 2020 at 07:18:26PM -0400, Sasha Levin wrote:
>>> > > On Mon, Jun 29, 2020 at 02:37:53PM -0600, Shuah Khan wrote:
>>> > > > Hi Sasha,
>>> > > >
>>> > > > On 6/29/20 9:13 AM, Sasha Levin wrote:
>>> > > > >
>>> > > > > This is the start of the stable review cycle for the 5.7.7 
>>> release.
>>> > > > > There are 265 patches in this series, all will be posted as a 
>>> response
>>> > > > > to this one.  If anyone has any issues with these being 
>>> applied, please
>>> > > > > let me know.
>>> > > > >
>>> > > > > Responses should be made by Wed 01 Jul 2020 03:14:48 PM UTC.
>>> > > > > Anything received after that time might be too late.
>>> > > > >
>>> > > > > The whole patch series can be found in one patch at:
>>> > > > >     
>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-5.7.y&id2=v5.7.6 
>>>
>>> > > > >
>>> > > >
>>> > > > Looks like patch naming convention has changed. My scripts look
>>> > > > for the following convention Greg uses. Are you planning to use
>>> > > > the above going forward? My scripts failed looking for the usual
>>> > > > naming convention.
>>> > > >
>>> > > > The whole patch series can be found in one patch at:
>>> > > >     
>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.6-rc1.gz 
>>>
>>> > > > or in the git tree and branch at:
>>> > > >     
>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
>>> linux-5.7.y
>>> > > > and the diffstat can be found below.
>>> > >
>>> > > Sorry for that. I was hoping to avoid using the signed upload 
>>> mechanism
>>> > > Greg was using by simply pointing the links to automatically 
>>> generated
>>> > > patches on cgit (the git.kernel.org interface).
>>> > >
>>> > > Would it be ok to change the pattern matching here? Something 
>>> like this
>>> > > should work for both Greg's format and my own (and whatever may come
>>> > > next):
>>> > >
>>> > >     grep -A1 "The whole patch series can be found in one patch 
>>> at:" | tail -n1 | sed 's/\t//'
>>> >
>>> > If those don't work, I can still push out -rc1 patches.
>>> >
>>> > It might be best given that the above -rc.git tree is unstable and 
>>> can,
>>> > and will, change, and patches stored on kernel.org will not.
>>>
>>> That's a good point. Maybe we should push tags for -rc releases too?
>>> that would allow us to keep stable links using the git.kernel.org
>>> interface.
>>
>> If we really want to do this, then yes, we could.  But that kind of goes
>> against what we (well I) have been doing in the past with that tree...
> 
> We've been force pushing it, yes, but if we add tags it would just keep
> older version around so I don't think it would change much for our
> workflow, but it would make it easy to get to older versions.
> 

I can make changes to my scripts as long as the process is consistent
for stable releases. Let mw know what you come up with, I will make
adjustments to my scripts.

thanks,
-- Shuah

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ