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

2017-05-24 Thread 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)

2017-05-24 Thread 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)

2017-05-24 Thread 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)

2017-05-24 Thread 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)

2017-05-24 Thread 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)

2017-05-24 Thread 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


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

2017-05-16 Thread 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)

2017-05-16 Thread 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)

2017-05-15 Thread 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)

2017-05-15 Thread 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)

2017-05-15 Thread 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)

2017-05-15 Thread 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