[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Konstantin Ryabitsev via RT]

On 2017-05-24 14:42:54, li...@nerdbynature.de wrote:
> > We are trying to identify who are the people who still need to
> > download
> >  patches as opposed to using git directly, and what their use-case
> 
> I never use the links on the kernel.org main page to download patches,
> but
> still: can those be changed to say ".gz" or something, so that
> $browser
> won't _display_ it by default but _download_ it instead?

We'll enable that the moment cgit supports that -- but it currently doesn't. I 
have an RFE open with cgit upstream.

Regards,
-- 
Konstantin Ryabitsev
Linux Foundation Projects

[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Konstantin Ryabitsev via RT]

On 2017-05-24 14:42:54, li...@nerdbynature.de wrote:
> > We are trying to identify who are the people who still need to
> > download
> >  patches as opposed to using git directly, and what their use-case
> 
> I never use the links on the kernel.org main page to download patches,
> but
> still: can those be changed to say ".gz" or something, so that
> $browser
> won't _display_ it by default but _download_ it instead?

We'll enable that the moment cgit supports that -- but it currently doesn't. I 
have an RFE open with cgit upstream.

Regards,
-- 
Konstantin Ryabitsev
Linux Foundation Projects

Re: [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Christian Kujau via RT]

On Mon, 15 May 2017, Konstantin Ryabitsev via RT wrote:
> On 2017-05-15 14:34:56, francoisvalen...@gmail.com wrote:
> > It doesn't work with Firefox-53.0. After quite a long time while
> > firefox
> > uses 100% of CPU, I finally get a text file and not a gzip file of the
> > patch for 4.12-rc1. It was almost instantaneous previously. I don't
> > see
> > this as a progress.
> 
> Firefox will request a gzip version of the patch, download it and then ungzip 
> it for you and display it in the browser. If you'd rather not display 
> that, please use a commandline tool like wget or curl to get the patch.

Yeah, same here: clicking on 4.12-rc2/patch on the kernel.org main 
page makes Firefox 53 freeze for a few minutes, and then display (!) the 
text file (85 MB!) in full. Wow.

> We are trying to identify who are the people who still need to download
> patches as opposed to using git directly, and what their use-case 

I never use the links on the kernel.org main page to download patches, but 
still: can those be changed to say ".gz" or something, so that $browser 
won't _display_ it by default but _download_ it instead?

Thanks,
Christian.
-- 
BOFH excuse #435:

Internet shut down due to maintenance

Re: [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Christian Kujau via RT]

On Mon, 15 May 2017, Konstantin Ryabitsev via RT wrote:
> On 2017-05-15 14:34:56, francoisvalen...@gmail.com wrote:
> > It doesn't work with Firefox-53.0. After quite a long time while
> > firefox
> > uses 100% of CPU, I finally get a text file and not a gzip file of the
> > patch for 4.12-rc1. It was almost instantaneous previously. I don't
> > see
> > this as a progress.
> 
> Firefox will request a gzip version of the patch, download it and then ungzip 
> it for you and display it in the browser. If you'd rather not display 
> that, please use a commandline tool like wget or curl to get the patch.

Yeah, same here: clicking on 4.12-rc2/patch on the kernel.org main 
page makes Firefox 53 freeze for a few minutes, and then display (!) the 
text file (85 MB!) in full. Wow.

> We are trying to identify who are the people who still need to download
> patches as opposed to using git directly, and what their use-case 

I never use the links on the kernel.org main page to download patches, but 
still: can those be changed to say ".gz" or something, so that $browser 
won't _display_ it by default but _download_ it instead?

Thanks,
Christian.
-- 
BOFH excuse #435:

Internet shut down due to maintenance

Re: [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Christian Kujau]

On Mon, 15 May 2017, Konstantin Ryabitsev via RT wrote:
> On 2017-05-15 14:34:56, francoisvalen...@gmail.com wrote:
> > It doesn't work with Firefox-53.0. After quite a long time while
> > firefox
> > uses 100% of CPU, I finally get a text file and not a gzip file of the
> > patch for 4.12-rc1. It was almost instantaneous previously. I don't
> > see
> > this as a progress.
> 
> Firefox will request a gzip version of the patch, download it and then ungzip 
> it for you and display it in the browser. If you'd rather not display 
> that, please use a commandline tool like wget or curl to get the patch.

Yeah, same here: clicking on 4.12-rc2/patch on the kernel.org main 
page makes Firefox 53 freeze for a few minutes, and then display (!) the 
text file (85 MB!) in full. Wow.

> We are trying to identify who are the people who still need to download
> patches as opposed to using git directly, and what their use-case 

I never use the links on the kernel.org main page to download patches, but 
still: can those be changed to say ".gz" or something, so that $browser 
won't _display_ it by default but _download_ it instead?

Thanks,
Christian.
-- 
BOFH excuse #435:

Internet shut down due to maintenance

Re: [Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Christian Kujau]

On Mon, 15 May 2017, Konstantin Ryabitsev via RT wrote:
> On 2017-05-15 14:34:56, francoisvalen...@gmail.com wrote:
> > It doesn't work with Firefox-53.0. After quite a long time while
> > firefox
> > uses 100% of CPU, I finally get a text file and not a gzip file of the
> > patch for 4.12-rc1. It was almost instantaneous previously. I don't
> > see
> > this as a progress.
> 
> Firefox will request a gzip version of the patch, download it and then ungzip 
> it for you and display it in the browser. If you'd rather not display 
> that, please use a commandline tool like wget or curl to get the patch.

Yeah, same here: clicking on 4.12-rc2/patch on the kernel.org main 
page makes Firefox 53 freeze for a few minutes, and then display (!) the 
text file (85 MB!) in full. Wow.

> We are trying to identify who are the people who still need to download
> patches as opposed to using git directly, and what their use-case 

I never use the links on the kernel.org main page to download patches, but 
still: can those be changed to say ".gz" or something, so that $browser 
won't _display_ it by default but _download_ it instead?

Thanks,
Christian.
-- 
BOFH excuse #435:

Internet shut down due to maintenance

Re: linux-next: stats (Was: Linux 4.12-rc1)

[Sebastian Reichel]

Hi Stephen,

On Tue, May 16, 2017 at 07:32:09AM +1000, Stephen Rothwell wrote:
> On Mon, 15 May 2017 16:51:08 +0200 Sebastian Reichel  wrote:
> > On Mon, May 15, 2017 at 11:15:50PM +1000, Stephen Rothwell wrote:
> > > There are also 288 commits in next-20170502 that didn't make it into
> > > v4.12-rc1.
> > > 
> > > [...]
> > >
> > > Top ten commiters:
> > > 
> > >  66 s...@canb.auug.org.au
> > >  47 paul...@linux.vnet.ibm.com
> > >  34 t...@linutronix.de
> > >  23 li...@roeck-us.net
> > >  14 alexandre.bell...@free-electrons.com
> > >  11 p...@axentia.se
> > >   9 quwen...@cn.fujitsu.com
> > >   8 o...@lixom.net
> > >   7 s...@kernel.org
> > >   5 mathieu.poir...@linaro.org  
> > 
> > Did you compile the list today? I started adding content for 4.13
> > after Linus tagged v4.12-rc1 and my power-supply for-next branch
> > curently has exactly 7 patches.
> 
> As I said above these are commits that were in linux-next on May 2nd
> but were not in v4.12-rc1

oh, I missed that.

> 99484df028dd power: supply: bq27xxx: Add power_supply_battery_info support
> ac8eb82d2fed power: supply: bq27xxx: Add chip data memory read/write support
> a66c51d4fe5a power: supply: bq27xxx: Add bulk transfer bus methods
> 7192174d20dc dt-bindings: power: supply: bq27xxx: Add monitored-battery 
> documentation
> fb38342a5ae6 power: supply: core: add power_supply_battery_info and API
> bbdc4f09fe12 devicetree: property-units: Add uWh and uAh units
> ecc931a585b3 dt-bindings: power: supply: add simple-battery DT binding
> 
> There can be various reasons that they didn't make it in and, in fact,
> these are not in yesterday's linux-next either.

Thanks, I forgot about those when I wrote my mail. The patch author
asked me to drop them for 4.12 due to some problems.

-- Sebastian


signature.asc
Description: PGP signature

Re: linux-next: stats (Was: Linux 4.12-rc1)

[Sebastian Reichel]

Hi Stephen,

On Tue, May 16, 2017 at 07:32:09AM +1000, Stephen Rothwell wrote:
> On Mon, 15 May 2017 16:51:08 +0200 Sebastian Reichel  wrote:
> > On Mon, May 15, 2017 at 11:15:50PM +1000, Stephen Rothwell wrote:
> > > There are also 288 commits in next-20170502 that didn't make it into
> > > v4.12-rc1.
> > > 
> > > [...]
> > >
> > > Top ten commiters:
> > > 
> > >  66 s...@canb.auug.org.au
> > >  47 paul...@linux.vnet.ibm.com
> > >  34 t...@linutronix.de
> > >  23 li...@roeck-us.net
> > >  14 alexandre.bell...@free-electrons.com
> > >  11 p...@axentia.se
> > >   9 quwen...@cn.fujitsu.com
> > >   8 o...@lixom.net
> > >   7 s...@kernel.org
> > >   5 mathieu.poir...@linaro.org  
> > 
> > Did you compile the list today? I started adding content for 4.13
> > after Linus tagged v4.12-rc1 and my power-supply for-next branch
> > curently has exactly 7 patches.
> 
> As I said above these are commits that were in linux-next on May 2nd
> but were not in v4.12-rc1

oh, I missed that.

> 99484df028dd power: supply: bq27xxx: Add power_supply_battery_info support
> ac8eb82d2fed power: supply: bq27xxx: Add chip data memory read/write support
> a66c51d4fe5a power: supply: bq27xxx: Add bulk transfer bus methods
> 7192174d20dc dt-bindings: power: supply: bq27xxx: Add monitored-battery 
> documentation
> fb38342a5ae6 power: supply: core: add power_supply_battery_info and API
> bbdc4f09fe12 devicetree: property-units: Add uWh and uAh units
> ecc931a585b3 dt-bindings: power: supply: add simple-battery DT binding
> 
> There can be various reasons that they didn't make it in and, in fact,
> these are not in yesterday's linux-next either.

Thanks, I forgot about those when I wrote my mail. The patch author
asked me to drop them for 4.12 due to some problems.

-- Sebastian


signature.asc
Description: PGP signature

[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Konstantin Ryabitsev via RT]

On 2017-05-15 11:42:48, torva...@linux-foundation.org wrote:
> so the capability is there, it's just not done as several individual
> files any more.

I've published a news item explaining the new process and the reasoning behind 
not providing these automatically generated tarballs and patches as part of the 
cryptographically verifiable /pub tree:

https://www.kernel.org/rc-tarballs-and-patches-starting-with-412-rc1.html

Regards,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
Linux Foundation Projects
Montréal, Québec

[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Konstantin Ryabitsev via RT]

On 2017-05-15 11:42:48, torva...@linux-foundation.org wrote:
> so the capability is there, it's just not done as several individual
> files any more.

I've published a news item explaining the new process and the reasoning behind 
not providing these automatically generated tarballs and patches as part of the 
cryptographically verifiable /pub tree:

https://www.kernel.org/rc-tarballs-and-patches-starting-with-412-rc1.html

Regards,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
Linux Foundation Projects
Montréal, Québec

Re: linux-next: stats (Was: Linux 4.12-rc1)

[Stephen Rothwell]

Hi Sebastian,

On Mon, 15 May 2017 16:51:08 +0200 Sebastian Reichel  wrote:
>
> On Mon, May 15, 2017 at 11:15:50PM +1000, Stephen Rothwell wrote:
> > There are also 288 commits in next-20170502 that didn't make it into
> > v4.12-rc1.
> > 
> > [...]
> >
> > Top ten commiters:
> > 
> >  66 s...@canb.auug.org.au
> >  47 paul...@linux.vnet.ibm.com
> >  34 t...@linutronix.de
> >  23 li...@roeck-us.net
> >  14 alexandre.bell...@free-electrons.com
> >  11 p...@axentia.se
> >   9 quwen...@cn.fujitsu.com
> >   8 o...@lixom.net
> >   7 s...@kernel.org
> >   5 mathieu.poir...@linaro.org  
> 
> Did you compile the list today? I started adding content for 4.13
> after Linus tagged v4.12-rc1 and my power-supply for-next branch
> curently has exactly 7 patches.

As I said above these are commits that were in linux-next on May 2nd
but were not in v4.12-rc1:

99484df028dd power: supply: bq27xxx: Add power_supply_battery_info support
ac8eb82d2fed power: supply: bq27xxx: Add chip data memory read/write support
a66c51d4fe5a power: supply: bq27xxx: Add bulk transfer bus methods
7192174d20dc dt-bindings: power: supply: bq27xxx: Add monitored-battery 
documentation
fb38342a5ae6 power: supply: core: add power_supply_battery_info and API
bbdc4f09fe12 devicetree: property-units: Add uWh and uAh units
ecc931a585b3 dt-bindings: power: supply: add simple-battery DT binding

There can be various reasons that they didn't make it in and, in fact,
these are not in yesterday's linux-next either.
-- 
Cheers,
Stephen Rothwell

Re: linux-next: stats (Was: Linux 4.12-rc1)

[Stephen Rothwell]

Hi Sebastian,

On Mon, 15 May 2017 16:51:08 +0200 Sebastian Reichel  wrote:
>
> On Mon, May 15, 2017 at 11:15:50PM +1000, Stephen Rothwell wrote:
> > There are also 288 commits in next-20170502 that didn't make it into
> > v4.12-rc1.
> > 
> > [...]
> >
> > Top ten commiters:
> > 
> >  66 s...@canb.auug.org.au
> >  47 paul...@linux.vnet.ibm.com
> >  34 t...@linutronix.de
> >  23 li...@roeck-us.net
> >  14 alexandre.bell...@free-electrons.com
> >  11 p...@axentia.se
> >   9 quwen...@cn.fujitsu.com
> >   8 o...@lixom.net
> >   7 s...@kernel.org
> >   5 mathieu.poir...@linaro.org  
> 
> Did you compile the list today? I started adding content for 4.13
> after Linus tagged v4.12-rc1 and my power-supply for-next branch
> curently has exactly 7 patches.

As I said above these are commits that were in linux-next on May 2nd
but were not in v4.12-rc1:

99484df028dd power: supply: bq27xxx: Add power_supply_battery_info support
ac8eb82d2fed power: supply: bq27xxx: Add chip data memory read/write support
a66c51d4fe5a power: supply: bq27xxx: Add bulk transfer bus methods
7192174d20dc dt-bindings: power: supply: bq27xxx: Add monitored-battery 
documentation
fb38342a5ae6 power: supply: core: add power_supply_battery_info and API
bbdc4f09fe12 devicetree: property-units: Add uWh and uAh units
ecc931a585b3 dt-bindings: power: supply: add simple-battery DT binding

There can be various reasons that they didn't make it in and, in fact,
these are not in yesterday's linux-next either.
-- 
Cheers,
Stephen Rothwell

[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Konstantin Ryabitsev via RT]

On 2017-05-14 13:59:22, rdun...@infradead.org wrote:
> On 05/13/17 13:57, Linus Torvalds wrote:
> > One thing worth noting - I haven't uploaded diffs or tar-balls for
> > this rc. Those should now be automagically generated by kernel.org for
> > the rc's, but that also means that they won't be signed by my key. If
> > you really care about signing, get the git repo and check the tag.
> 
> 
> There was some delay (don't know how much), but a bigger problem is
> the file(s) locations and (new) directory structure for them.

This is intentional to indicate the transient autogenerated nature of these 
files. They don't exist in the /pub tree and therefore it is misleading to 
rewrite URLs to place them there.

> Can the generated files please be put in the same places that (most or
> all) previous releases have used?

Not unless there is a convincing reason to do so (and please feel free to 
provide it, as this is not a final change and can always be undone should the 
counter-arguments be convincing).

Regards,
-- 
Konstantin Ryabitsev
Senior Systems Administrator
Linux Foundation Collab Projects
Montréal, Québec

[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Konstantin Ryabitsev via RT]

On 2017-05-14 13:59:22, rdun...@infradead.org wrote:
> On 05/13/17 13:57, Linus Torvalds wrote:
> > One thing worth noting - I haven't uploaded diffs or tar-balls for
> > this rc. Those should now be automagically generated by kernel.org for
> > the rc's, but that also means that they won't be signed by my key. If
> > you really care about signing, get the git repo and check the tag.
> 
> 
> There was some delay (don't know how much), but a bigger problem is
> the file(s) locations and (new) directory structure for them.

This is intentional to indicate the transient autogenerated nature of these 
files. They don't exist in the /pub tree and therefore it is misleading to 
rewrite URLs to place them there.

> Can the generated files please be put in the same places that (most or
> all) previous releases have used?

Not unless there is a convincing reason to do so (and please feel free to 
provide it, as this is not a final change and can always be undone should the 
counter-arguments be convincing).

Regards,
-- 
Konstantin Ryabitsev
Senior Systems Administrator
Linux Foundation Collab Projects
Montréal, Québec

[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Konstantin Ryabitsev via RT]

On 2017-05-15 14:34:56, francoisvalen...@gmail.com wrote:
> It doesn't work with Firefox-53.0. After quite a long time while
> firefox
> uses 100% of CPU, I finally get a text file and not a gzip file of the
> patch for 4.12-rc1. It was almost instantaneous previously. I don't
> see
> this as a progress.

Firefox will request a gzip version of the patch, download it and then ungzip 
it for you and display it in the browser. If you'd rather not display that, 
please use a commandline tool like wget or curl to get the patch.

We are trying to identify who are the people who still need to download patches 
as opposed to using git directly, and what their use-case scenario is.

Regards,
-- 
Konstantin Ryabitsev
Senior Systems Administrator
Linux Foundation Collab Projects
Montréal, Québec

[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)

[Konstantin Ryabitsev via RT]

On 2017-05-15 14:34:56, francoisvalen...@gmail.com wrote:
> It doesn't work with Firefox-53.0. After quite a long time while
> firefox
> uses 100% of CPU, I finally get a text file and not a gzip file of the
> patch for 4.12-rc1. It was almost instantaneous previously. I don't
> see
> this as a progress.

Firefox will request a gzip version of the patch, download it and then ungzip 
it for you and display it in the browser. If you'd rather not display that, 
please use a commandline tool like wget or curl to get the patch.

We are trying to identify who are the people who still need to download patches 
as opposed to using git directly, and what their use-case scenario is.

Regards,
-- 
Konstantin Ryabitsev
Senior Systems Administrator
Linux Foundation Collab Projects
Montréal, Québec

Re: [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations)

[François Valenduc]

Le 15/05/17 à 17:42, Linus Torvalds via RT a écrit :
> On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap  wrote:
>>
>> Can the generated files please be put in the same places that (most or
>> all) previous releases have used?
> 
> I will leave this to Konstantin.. There may well be practical reasons
> for the movement.
> 
>> Oh, and the patch file (on https://kernel.org) is a text file, not a
>> zipped file (as in previous releases).
> 
> Well, if you use a browser, the normal browser compression (behind
> your back) should be in effect. So you won't actually be wasting the
> bandwidth.
> 
> If you use wget, you have to manually ask for it. Quoting Konstantin
> from an earlier discussion:
> 
>> Yes, this is implemented on the http protocol level -- but you have to
>> tell wget to request it:
>>
>> wget -O test.patch.gz \
>>  --header="accept-encoding: gzip" \
>>  https://git.kernel.org/...
>>
>> Browsers do the requesting and ungzipping automatically, but not cmdline
>> tools.
> 
> so the capability is there, it's just not done as several individual
> files any more.
> 
>  Linus
> 
> 
It doesn't work with Firefox-53.0. After quite a long time while firefox
uses 100% of CPU, I finally get a text file and not a gzip file of the
patch for 4.12-rc1. It was almost instantaneous previously. I don't see
this as a progress.

Best regards,

François Valenduc

Re: [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations)

[François Valenduc via RT]

Le 15/05/17 à 17:42, Linus Torvalds via RT a écrit :
> On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap  wrote:
>>
>> Can the generated files please be put in the same places that (most or
>> all) previous releases have used?
> 
> I will leave this to Konstantin.. There may well be practical reasons
> for the movement.
> 
>> Oh, and the patch file (on https://kernel.org) is a text file, not a
>> zipped file (as in previous releases).
> 
> Well, if you use a browser, the normal browser compression (behind
> your back) should be in effect. So you won't actually be wasting the
> bandwidth.
> 
> If you use wget, you have to manually ask for it. Quoting Konstantin
> from an earlier discussion:
> 
>> Yes, this is implemented on the http protocol level -- but you have to
>> tell wget to request it:
>>
>> wget -O test.patch.gz \
>>  --header="accept-encoding: gzip" \
>>  https://git.kernel.org/...
>>
>> Browsers do the requesting and ungzipping automatically, but not cmdline
>> tools.
> 
> so the capability is there, it's just not done as several individual
> files any more.
> 
>  Linus
> 
> 
It doesn't work with Firefox-53.0. After quite a long time while firefox
uses 100% of CPU, I finally get a text file and not a gzip file of the
patch for 4.12-rc1. It was almost instantaneous previously. I don't see
this as a progress.

Best regards,

François Valenduc

Re: [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations)

[François Valenduc]

Le 15/05/17 à 17:42, Linus Torvalds via RT a écrit :
> On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap  wrote:
>>
>> Can the generated files please be put in the same places that (most or
>> all) previous releases have used?
> 
> I will leave this to Konstantin.. There may well be practical reasons
> for the movement.
> 
>> Oh, and the patch file (on https://kernel.org) is a text file, not a
>> zipped file (as in previous releases).
> 
> Well, if you use a browser, the normal browser compression (behind
> your back) should be in effect. So you won't actually be wasting the
> bandwidth.
> 
> If you use wget, you have to manually ask for it. Quoting Konstantin
> from an earlier discussion:
> 
>> Yes, this is implemented on the http protocol level -- but you have to
>> tell wget to request it:
>>
>> wget -O test.patch.gz \
>>  --header="accept-encoding: gzip" \
>>  https://git.kernel.org/...
>>
>> Browsers do the requesting and ungzipping automatically, but not cmdline
>> tools.
> 
> so the capability is there, it's just not done as several individual
> files any more.
> 
>  Linus
> 
> 
It doesn't work with Firefox-53.0. After quite a long time while firefox
uses 100% of CPU, I finally get a text file and not a gzip file of the
patch for 4.12-rc1. It was almost instantaneous previously. I don't see
this as a progress.

Best regards,

François Valenduc

Re: [Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations)

[François Valenduc via RT]

Le 15/05/17 à 17:42, Linus Torvalds via RT a écrit :
> On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap  wrote:
>>
>> Can the generated files please be put in the same places that (most or
>> all) previous releases have used?
> 
> I will leave this to Konstantin.. There may well be practical reasons
> for the movement.
> 
>> Oh, and the patch file (on https://kernel.org) is a text file, not a
>> zipped file (as in previous releases).
> 
> Well, if you use a browser, the normal browser compression (behind
> your back) should be in effect. So you won't actually be wasting the
> bandwidth.
> 
> If you use wget, you have to manually ask for it. Quoting Konstantin
> from an earlier discussion:
> 
>> Yes, this is implemented on the http protocol level -- but you have to
>> tell wget to request it:
>>
>> wget -O test.patch.gz \
>>  --header="accept-encoding: gzip" \
>>  https://git.kernel.org/...
>>
>> Browsers do the requesting and ungzipping automatically, but not cmdline
>> tools.
> 
> so the capability is there, it's just not done as several individual
> files any more.
> 
>  Linus
> 
> 
It doesn't work with Firefox-53.0. After quite a long time while firefox
uses 100% of CPU, I finally get a text file and not a gzip file of the
patch for 4.12-rc1. It was almost instantaneous previously. I don't see
this as a progress.

Best regards,

François Valenduc

[Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations)

[Linus Torvalds via RT]

On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap  wrote:
>
> Can the generated files please be put in the same places that (most or
> all) previous releases have used?

I will leave this to Konstantin.. There may well be practical reasons
for the movement.

> Oh, and the patch file (on https://kernel.org) is a text file, not a
> zipped file (as in previous releases).

Well, if you use a browser, the normal browser compression (behind
your back) should be in effect. So you won't actually be wasting the
bandwidth.

If you use wget, you have to manually ask for it. Quoting Konstantin
from an earlier discussion:

> Yes, this is implemented on the http protocol level -- but you have to
> tell wget to request it:
>
> wget -O test.patch.gz \
>  --header="accept-encoding: gzip" \
>  https://git.kernel.org/...
>
> Browsers do the requesting and ungzipping automatically, but not cmdline
> tools.

so the capability is there, it's just not done as several individual
files any more.

 Linus

[Kernel.org Helpdesk #40777] [linuxfoundation.org #40777] Re: Linux 4.12-rc1 (file locations)

[Linus Torvalds via RT]

On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap  wrote:
>
> Can the generated files please be put in the same places that (most or
> all) previous releases have used?

I will leave this to Konstantin.. There may well be practical reasons
for the movement.

> Oh, and the patch file (on https://kernel.org) is a text file, not a
> zipped file (as in previous releases).

Well, if you use a browser, the normal browser compression (behind
your back) should be in effect. So you won't actually be wasting the
bandwidth.

If you use wget, you have to manually ask for it. Quoting Konstantin
from an earlier discussion:

> Yes, this is implemented on the http protocol level -- but you have to
> tell wget to request it:
>
> wget -O test.patch.gz \
>  --header="accept-encoding: gzip" \
>  https://git.kernel.org/...
>
> Browsers do the requesting and ungzipping automatically, but not cmdline
> tools.

so the capability is there, it's just not done as several individual
files any more.

 Linus

Re: Linux 4.12-rc1 (file locations)

[Linus Torvalds]

On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap  wrote:
>
> Can the generated files please be put in the same places that (most or
> all) previous releases have used?

I will leave this to Konstantin.. There may well be practical reasons
for the movement.

> Oh, and the patch file (on https://kernel.org) is a text file, not a
> zipped file (as in previous releases).

Well, if you use a browser, the normal browser compression (behind
your back) should be in effect. So you won't actually be wasting the
bandwidth.

If you use wget, you have to manually ask for it. Quoting Konstantin
from an earlier discussion:

> Yes, this is implemented on the http protocol level -- but you have to
> tell wget to request it:
>
> wget -O test.patch.gz \
>  --header="accept-encoding: gzip" \
>  https://git.kernel.org/...
>
> Browsers do the requesting and ungzipping automatically, but not cmdline
> tools.

so the capability is there, it's just not done as several individual
files any more.

 Linus

Re: Linux 4.12-rc1 (file locations)

[Linus Torvalds]

On Sun, May 14, 2017 at 10:59 AM, Randy Dunlap  wrote:
>
> Can the generated files please be put in the same places that (most or
> all) previous releases have used?

I will leave this to Konstantin.. There may well be practical reasons
for the movement.

> Oh, and the patch file (on https://kernel.org) is a text file, not a
> zipped file (as in previous releases).

Well, if you use a browser, the normal browser compression (behind
your back) should be in effect. So you won't actually be wasting the
bandwidth.

If you use wget, you have to manually ask for it. Quoting Konstantin
from an earlier discussion:

> Yes, this is implemented on the http protocol level -- but you have to
> tell wget to request it:
>
> wget -O test.patch.gz \
>  --header="accept-encoding: gzip" \
>  https://git.kernel.org/...
>
> Browsers do the requesting and ungzipping automatically, but not cmdline
> tools.

so the capability is there, it's just not done as several individual
files any more.

 Linus

Re: linux-next: stats (Was: Linux 4.12-rc1)

[Sebastian Reichel]

Hi,

On Mon, May 15, 2017 at 11:15:50PM +1000, Stephen Rothwell wrote:
> There are also 288 commits in next-20170502 that didn't make it into
> v4.12-rc1.
> 
> [...]
>
> Top ten commiters:
> 
>  66 s...@canb.auug.org.au
>  47 paul...@linux.vnet.ibm.com
>  34 t...@linutronix.de
>  23 li...@roeck-us.net
>  14 alexandre.bell...@free-electrons.com
>  11 p...@axentia.se
>   9 quwen...@cn.fujitsu.com
>   8 o...@lixom.net
>   7 s...@kernel.org
>   5 mathieu.poir...@linaro.org

Did you compile the list today? I started adding content for 4.13
after Linus tagged v4.12-rc1 and my power-supply for-next branch
curently has exactly 7 patches.

-- Sebastian


signature.asc
Description: PGP signature

Re: linux-next: stats (Was: Linux 4.12-rc1)

[Sebastian Reichel]

Hi,

On Mon, May 15, 2017 at 11:15:50PM +1000, Stephen Rothwell wrote:
> There are also 288 commits in next-20170502 that didn't make it into
> v4.12-rc1.
> 
> [...]
>
> Top ten commiters:
> 
>  66 s...@canb.auug.org.au
>  47 paul...@linux.vnet.ibm.com
>  34 t...@linutronix.de
>  23 li...@roeck-us.net
>  14 alexandre.bell...@free-electrons.com
>  11 p...@axentia.se
>   9 quwen...@cn.fujitsu.com
>   8 o...@lixom.net
>   7 s...@kernel.org
>   5 mathieu.poir...@linaro.org

Did you compile the list today? I started adding content for 4.13
after Linus tagged v4.12-rc1 and my power-supply for-next branch
curently has exactly 7 patches.

-- Sebastian


signature.asc
Description: PGP signature

linux-next: stats (Was: Linux 4.12-rc1)

[Stephen Rothwell]

Hi all,

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20170502 was the first linux-next after
the merge window opened.)

Commits in v4.12-rc1 (relative to v4.11):  12920
Commits in next-20170502:  12432
Commits with the same SHA1:11772
Commits with the same patch_id:  331 (1)
Commits with the same subject line:   41 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20170502: 12144 93%

Some breakdown of the list of extra commits (relative to next-20170502)
in -rc1:

Top ten first word of commit summary:

143 drm
 55 kvm
 38 annotate
 23 net
 20 powerpc
 20 ib
 14 perf
 13 x86
 13 arm64
 12 target

Top ten authors:

 39 dhowe...@redhat.com
 32 rex@amd.com
 24 eric.au...@redhat.com
 14 ray.hu...@amd.com
 14 christian.koe...@amd.com
 12 alexander.deuc...@amd.com
 11 osan...@fb.com
 11 idryo...@gmail.com
 11 cd...@linaro.org
 11 ax...@fb.com

Top ten commiters:

132 alexander.deuc...@amd.com
105 da...@davemloft.net
 38 dhowe...@redhat.com
 38 ax...@fb.com
 37 cd...@linaro.org
 31 idryo...@gmail.com
 26 torva...@linux-foundation.org
 25 n...@linux-iscsi.org
 24 pbonz...@redhat.com
 22 m...@ellerman.id.au

There are also 288 commits in next-20170502 that didn't make it into
v4.12-rc1.

Top ten first word of commit summary:

 23 arm
 19 mm
 18 watchdog
 13 rcu
  9 srcu
  9 rcutorture
  9 btrfs
  8 rcuperf
  8 arm64
  7 fault-inject

Top ten authors:

 45 paul...@linux.vnet.ibm.com
 19 a...@linux-foundation.org
 18 alexandre.bell...@free-electrons.com
 15 t...@linutronix.de
 15 bige...@linutronix.de
 11 p...@axentia.se
  9 quwen...@cn.fujitsu.com
  6 o...@lixom.net
  6 akinobu.m...@gmail.com
  5 ker...@networkimprov.net

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

Top ten commiters:

 66 s...@canb.auug.org.au
 47 paul...@linux.vnet.ibm.com
 34 t...@linutronix.de
 23 li...@roeck-us.net
 14 alexandre.bell...@free-electrons.com
 11 p...@axentia.se
  9 quwen...@cn.fujitsu.com
  8 o...@lixom.net
  7 s...@kernel.org
  5 mathieu.poir...@linaro.org

Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).

-- 
Cheers,
Stephen Rothwell

linux-next: stats (Was: Linux 4.12-rc1)

[Stephen Rothwell]

Hi all,

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20170502 was the first linux-next after
the merge window opened.)

Commits in v4.12-rc1 (relative to v4.11):  12920
Commits in next-20170502:  12432
Commits with the same SHA1:11772
Commits with the same patch_id:  331 (1)
Commits with the same subject line:   41 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20170502: 12144 93%

Some breakdown of the list of extra commits (relative to next-20170502)
in -rc1:

Top ten first word of commit summary:

143 drm
 55 kvm
 38 annotate
 23 net
 20 powerpc
 20 ib
 14 perf
 13 x86
 13 arm64
 12 target

Top ten authors:

 39 dhowe...@redhat.com
 32 rex@amd.com
 24 eric.au...@redhat.com
 14 ray.hu...@amd.com
 14 christian.koe...@amd.com
 12 alexander.deuc...@amd.com
 11 osan...@fb.com
 11 idryo...@gmail.com
 11 cd...@linaro.org
 11 ax...@fb.com

Top ten commiters:

132 alexander.deuc...@amd.com
105 da...@davemloft.net
 38 dhowe...@redhat.com
 38 ax...@fb.com
 37 cd...@linaro.org
 31 idryo...@gmail.com
 26 torva...@linux-foundation.org
 25 n...@linux-iscsi.org
 24 pbonz...@redhat.com
 22 m...@ellerman.id.au

There are also 288 commits in next-20170502 that didn't make it into
v4.12-rc1.

Top ten first word of commit summary:

 23 arm
 19 mm
 18 watchdog
 13 rcu
  9 srcu
  9 rcutorture
  9 btrfs
  8 rcuperf
  8 arm64
  7 fault-inject

Top ten authors:

 45 paul...@linux.vnet.ibm.com
 19 a...@linux-foundation.org
 18 alexandre.bell...@free-electrons.com
 15 t...@linutronix.de
 15 bige...@linutronix.de
 11 p...@axentia.se
  9 quwen...@cn.fujitsu.com
  6 o...@lixom.net
  6 akinobu.m...@gmail.com
  5 ker...@networkimprov.net

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

Top ten commiters:

 66 s...@canb.auug.org.au
 47 paul...@linux.vnet.ibm.com
 34 t...@linutronix.de
 23 li...@roeck-us.net
 14 alexandre.bell...@free-electrons.com
 11 p...@axentia.se
  9 quwen...@cn.fujitsu.com
  8 o...@lixom.net
  7 s...@kernel.org
  5 mathieu.poir...@linaro.org

Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).

-- 
Cheers,
Stephen Rothwell

Re: Linux 4.12-rc1 (file locations)

[Randy Dunlap]

On 05/13/17 13:57, Linus Torvalds wrote:
> One thing worth noting - I haven't uploaded diffs or tar-balls for
> this rc. Those should now be automagically generated by kernel.org for
> the rc's, but that also means that they won't be signed by my key. If
> you really care about signing, get the git repo and check the tag.


There was some delay (don't know how much), but a bigger problem is
the file(s) locations and (new) directory structure for them.

Can the generated files please be put in the same places that (most or
all) previous releases have used?

Oh, and the patch file (on https://kernel.org) is a text file, not a
zipped file (as in previous releases).


thanks.
-- 
~Randy

Re: Linux 4.12-rc1 (file locations)

[Randy Dunlap]

On 05/13/17 13:57, Linus Torvalds wrote:
> One thing worth noting - I haven't uploaded diffs or tar-balls for
> this rc. Those should now be automagically generated by kernel.org for
> the rc's, but that also means that they won't be signed by my key. If
> you really care about signing, get the git repo and check the tag.


There was some delay (don't know how much), but a bigger problem is
the file(s) locations and (new) directory structure for them.

Can the generated files please be put in the same places that (most or
all) previous releases have used?

Oh, and the patch file (on https://kernel.org) is a text file, not a
zipped file (as in previous releases).


thanks.
-- 
~Randy

Linux 4.12-rc1

[Linus Torvalds]

So I'm doing this one day early, because I don't like last-minute pull
requests during the merge window anyway, and tomorrow is mother's day,
so I may end up being roped into various happenings.

Besides, this has actually been a pretty large merge window, so
despite there technically being time for one more day of pulls, I
actually do have enough changes already. So there.

Despite it being fairly large, it has (so far) been pretty smooth. I
don't think I personally saw any breakage at all, which is always
nice. Usually I end up having something break, or trigger some silly
build failure that really should have been noticed before it even got
to me, but so far things are looking good.

Famous last words.

The diffstat for this release looks a bit odd, because it's absolutely
dominated by the new AMD Vega10 header files that have all the
register definitions in them. In fact, that's almost exactly half the
lines of diff in just that.  And if you ignore that part, the new
Intel Atom IPU driver ends up being a noticeable part of the rest.

But if you ignore those two big additions, the statistics look pretty
normal. Two thirds drivers, with the rest being arch updates,
documentation updates and "misc" (filesystems, networking, header
updates, core files).

One thing worth noting - I haven't uploaded diffs or tar-balls for
this rc. Those should now be automagically generated by kernel.org for
the rc's, but that also means that they won't be signed by my key. If
you really care about signing, get the git repo and check the tag.

Go test.

   Linus

---

Al Viro (7):
uaccess unification updates
iov_iter updates
splice updates
fs/compat.c cleanups
vfs fix
misc vfs updates
misc vfs updates

Alex Williamson (1):
VFIO updates

Alexandre Belloni (1):
RTC updates

Andrew Morton (3):
misc updates
more updates
misc fixes

Arnd Bergmann (1):
TEE driver infrastructure and OP-TEE drivers

Bartlomiej Zolnierkiewicz (1):
fbdev updates

Bjorn Helgaas (1):
PCI updates

Bob Peterson (1):
GFS2 updates

Borislav Petkov (1):
EDAC updates

Brian Norris (1):
MTD updates

Bruce Fields (1):
nfsd updates

Catalin Marinas (2):
arm64 updates
more arm64 updates

Chris Mason (1):
btrfs updates

Corey Minyard (1):
IPMI updates

Dan Williams (2):
libnvdimm updates
libnvdimm fixes

Darren Hart (1):
x86 platform-drivers update

Darrick Wong (1):
xfs updates

Dave Airlie (4):
drm u pdates
drm tegra updates
drm CoC pointer
drm fixes

David Howells (1):
hw lockdown support

David Millar (1):
networking updates

David Miller (4):
networking fixes
networking fixes
sparc updates
IDE updates

Dmitry Torokhov (2):
input subsystem updates
some more input subsystem updates

Doug Ledford (2):
rdma updates
more rdma updates

Eric Biederman (1):
namespace updates

Geert Uytterhoeven (1):
m68k updates

Greg KH (5):
USB updates
driver core updates
char/misc driver updates
staging/IIO updates
tty/serial updates

Guenter Roeck (1):
hwmon updates

Hans-Christian Noren Egtvedt (1):
AVR32 removal

Herbert Xu (1):
crypto updates

Ilya Dryomov (1):
ceph updates

Ingo Molnar (21):
EFI updates
scheduler updates
locking updates
perf updates
RAS updates
x86 boot updates
x86 cpu updates
x86 apic updates
x86 asm updates
x86 build update
x86 cleanups
x86 debug updates
x86 irq update
x86 platform updates
x86 vdso updates
x86 mm updates
RCU updates
x86 fixes
stackprotector fixlet
timer fix
perf updates/fixes

Jacek Anaszewski (1):
LED updates

Jaegeuk Kim (1):
f2fs updates

James Bottomley (1):
SCSI updates

James Hogan (2):
metag updates
MIPS updates

James Morris (1):
security subsystem updates

Jan Kara (2):
fsnotify updates
quota, reiserfs, udf and ext2 updates

Jassi Brar (1):
mailbox updates

Jens Axboe (4):
block layer updates
second round of block layer updates
block fixes and updates
block fixes

Jessica Yu (1):
modules updates

Jiri Kosina (3):
HID subsystem updates
livepatch updates
trivial tree updates

Joerg Roedel (1):
IOMMU updates

Jonathan Corbet (2):
documentation update
more documentation updates

Juergen Gross (2):
xen updates
xen fixes

Kees Cook (2):
pstore updates
hardened usercopy updates

Lee Jones (2):
backlight update
MFD updates

Ley Foon Tan (1):
nios2 updates

Linus Walleij (2):
pin control updates
GPIO updates

Luis de Bethencourt (1):
befs fix

Mark Brown (2):
regulator updates
spi updates

Martin Schwidefsky (1):
s390 updates

Masahiro Yamada (3):
Kbuild updates
misc Kbuild updates
Kbuild UAPI updates

Mauro Carvalho Chehab (1):
media updates

Max Filippov (1):
Xtensa updates

Michael 

Linux 4.12-rc1

[Linus Torvalds]

So I'm doing this one day early, because I don't like last-minute pull
requests during the merge window anyway, and tomorrow is mother's day,
so I may end up being roped into various happenings.

Besides, this has actually been a pretty large merge window, so
despite there technically being time for one more day of pulls, I
actually do have enough changes already. So there.

Despite it being fairly large, it has (so far) been pretty smooth. I
don't think I personally saw any breakage at all, which is always
nice. Usually I end up having something break, or trigger some silly
build failure that really should have been noticed before it even got
to me, but so far things are looking good.

Famous last words.

The diffstat for this release looks a bit odd, because it's absolutely
dominated by the new AMD Vega10 header files that have all the
register definitions in them. In fact, that's almost exactly half the
lines of diff in just that.  And if you ignore that part, the new
Intel Atom IPU driver ends up being a noticeable part of the rest.

But if you ignore those two big additions, the statistics look pretty
normal. Two thirds drivers, with the rest being arch updates,
documentation updates and "misc" (filesystems, networking, header
updates, core files).

One thing worth noting - I haven't uploaded diffs or tar-balls for
this rc. Those should now be automagically generated by kernel.org for
the rc's, but that also means that they won't be signed by my key. If
you really care about signing, get the git repo and check the tag.

Go test.

   Linus

---

Al Viro (7):
uaccess unification updates
iov_iter updates
splice updates
fs/compat.c cleanups
vfs fix
misc vfs updates
misc vfs updates

Alex Williamson (1):
VFIO updates

Alexandre Belloni (1):
RTC updates

Andrew Morton (3):
misc updates
more updates
misc fixes

Arnd Bergmann (1):
TEE driver infrastructure and OP-TEE drivers

Bartlomiej Zolnierkiewicz (1):
fbdev updates

Bjorn Helgaas (1):
PCI updates

Bob Peterson (1):
GFS2 updates

Borislav Petkov (1):
EDAC updates

Brian Norris (1):
MTD updates

Bruce Fields (1):
nfsd updates

Catalin Marinas (2):
arm64 updates
more arm64 updates

Chris Mason (1):
btrfs updates

Corey Minyard (1):
IPMI updates

Dan Williams (2):
libnvdimm updates
libnvdimm fixes

Darren Hart (1):
x86 platform-drivers update

Darrick Wong (1):
xfs updates

Dave Airlie (4):
drm u pdates
drm tegra updates
drm CoC pointer
drm fixes

David Howells (1):
hw lockdown support

David Millar (1):
networking updates

David Miller (4):
networking fixes
networking fixes
sparc updates
IDE updates

Dmitry Torokhov (2):
input subsystem updates
some more input subsystem updates

Doug Ledford (2):
rdma updates
more rdma updates

Eric Biederman (1):
namespace updates

Geert Uytterhoeven (1):
m68k updates

Greg KH (5):
USB updates
driver core updates
char/misc driver updates
staging/IIO updates
tty/serial updates

Guenter Roeck (1):
hwmon updates

Hans-Christian Noren Egtvedt (1):
AVR32 removal

Herbert Xu (1):
crypto updates

Ilya Dryomov (1):
ceph updates

Ingo Molnar (21):
EFI updates
scheduler updates
locking updates
perf updates
RAS updates
x86 boot updates
x86 cpu updates
x86 apic updates
x86 asm updates
x86 build update
x86 cleanups
x86 debug updates
x86 irq update
x86 platform updates
x86 vdso updates
x86 mm updates
RCU updates
x86 fixes
stackprotector fixlet
timer fix
perf updates/fixes

Jacek Anaszewski (1):
LED updates

Jaegeuk Kim (1):
f2fs updates

James Bottomley (1):
SCSI updates

James Hogan (2):
metag updates
MIPS updates

James Morris (1):
security subsystem updates

Jan Kara (2):
fsnotify updates
quota, reiserfs, udf and ext2 updates

Jassi Brar (1):
mailbox updates

Jens Axboe (4):
block layer updates
second round of block layer updates
block fixes and updates
block fixes

Jessica Yu (1):
modules updates

Jiri Kosina (3):
HID subsystem updates
livepatch updates
trivial tree updates

Joerg Roedel (1):
IOMMU updates

Jonathan Corbet (2):
documentation update
more documentation updates

Juergen Gross (2):
xen updates
xen fixes

Kees Cook (2):
pstore updates
hardened usercopy updates

Lee Jones (2):
backlight update
MFD updates

Ley Foon Tan (1):
nios2 updates

Linus Walleij (2):
pin control updates
GPIO updates

Luis de Bethencourt (1):
befs fix

Mark Brown (2):
regulator updates
spi updates

Martin Schwidefsky (1):
s390 updates

Masahiro Yamada (3):
Kbuild updates
misc Kbuild updates
Kbuild UAPI updates

Mauro Carvalho Chehab (1):
media updates

Max Filippov (1):
Xtensa updates

Michael