[Kernel.org Helpdesk #46182] Re: Linux 4.14-rc2 (bad patch file on kernel.org)

[Konstantin Ryabitsev via RT]

On 2017-09-24 22:57:37, rdun...@infradead.org wrote:
> On 09/24/17 17:03, Linus Torvalds wrote:
> > I'm back to my usual Sunday release schedule, and rc2 is out there in
> > all the normal places.
> 
> Downloading & applying 4.14-rc2 [patch]
>  rc2=v4.13>
> 
> from kernel.org (home page) gives me a file that does not apply
> cleanly to v4.13:
> 
> --
> |diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> |index 4d81f6d..9deb5a2 100644
> | --- a/virt/kvm/kvm_main.c
> | +++ b/virt/kvm/kvm_main.c
> --
> checking file virt/kvm/kvm_main.c
> Using Plan A...
> patch unexpectedly ends in middle of line
> patch:  unexpected end of file in patch

Ick, looks like the cache truncation bug is still not fixed in the upstream 
cgit and the EPEL update blew away my locally fixed package (which is my fault, 
as I should have versionlocked it). The fixed version is now in place and 
truncated caches are purged. It should generate valid patches now.

> I also notice that the [pgp] signing is not there.  Is that normal?

Yes, see 
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 #46182] Re: Linux 4.14-rc2 (bad patch file on kernel.org)

[Konstantin Ryabitsev via RT]

On 2017-09-24 22:57:37, rdun...@infradead.org wrote:
> On 09/24/17 17:03, Linus Torvalds wrote:
> > I'm back to my usual Sunday release schedule, and rc2 is out there in
> > all the normal places.
> 
> Downloading & applying 4.14-rc2 [patch]
>  rc2=v4.13>
> 
> from kernel.org (home page) gives me a file that does not apply
> cleanly to v4.13:
> 
> --
> |diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> |index 4d81f6d..9deb5a2 100644
> | --- a/virt/kvm/kvm_main.c
> | +++ b/virt/kvm/kvm_main.c
> --
> checking file virt/kvm/kvm_main.c
> Using Plan A...
> patch unexpectedly ends in middle of line
> patch:  unexpected end of file in patch

Ick, looks like the cache truncation bug is still not fixed in the upstream 
cgit and the EPEL update blew away my locally fixed package (which is my fault, 
as I should have versionlocked it). The fixed version is now in place and 
truncated caches are purged. It should generate valid patches now.

> I also notice that the [pgp] signing is not there.  Is that normal?

Yes, see 
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-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

[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

[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

[Kernel.org Helpdesk #38150] [linuxfoundation.org #38150] Re: Linux 4.10.2

[Konstantin Ryabitsev via RT]

On Mon, Mar 13, 2017 at 11:44:18AM -0400, Ilia Mirkin wrote:
>> rcnee@debian:~/linux$ host git.kernel.org
>> git.kernel.org is an alias for pub.kernel.org.
>> pub.kernel.org is an alias for pub.ewr.kernel.org.
>> pub.ewr.kernel.org has address 147.75.196.57
>> pub.ewr.kernel.org has IPv6 address 2604:1380:1:3600::3
>
>$ git fetch origin
>remote: Counting objects: 2543, done.
>remote: Compressing objects: 100% (725/725), done.
>remote: Total 2543 (delta 2112), reused 2207 (delta 1816)
>Receiving objects: 100% (2543/2543), 503.18 KiB | 0 bytes/s, done.
>Resolving deltas: 100% (2112/2112), completed with 675 local objects.
>From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
>   c1ae3cf..56b24d1  master -> origin/master
>$ git show v4.11-rc2
>fatal: ambiguous argument 'v4.11-rc2': unknown revision or path not in
>the working tree.
>Use '--' to separate paths from revisions, like this:
>'git  [...] -- [...]'
>$ git tag -l *4.11-rc[12]
>v4.11-rc1
>$ host git.kernel.org
>git.kernel.org is an alias for pub.kernel.org.
>pub.kernel.org is an alias for pub.ewr.kernel.org.
>pub.ewr.kernel.org has address 147.75.196.57
>pub.ewr.kernel.org has IPv6 address 2604:1380:1:3600::3
>
>Coincidence? (I'm in NYC in case it matters. I'm using IPv4 from here,
>but was most likely on IPv6 at home yesterday when I first had the
>issue.)

I've identified and fixed the mirroring issue with the EWR frontend.  
All repositories should now be up-to-date. Apologies about the problem!

-Konstantin

[Kernel.org Helpdesk #38150] [linuxfoundation.org #38150] Re: Linux 4.10.2

[Konstantin Ryabitsev via RT]

On Mon, Mar 13, 2017 at 11:44:18AM -0400, Ilia Mirkin wrote:
>> rcnee@debian:~/linux$ host git.kernel.org
>> git.kernel.org is an alias for pub.kernel.org.
>> pub.kernel.org is an alias for pub.ewr.kernel.org.
>> pub.ewr.kernel.org has address 147.75.196.57
>> pub.ewr.kernel.org has IPv6 address 2604:1380:1:3600::3
>
>$ git fetch origin
>remote: Counting objects: 2543, done.
>remote: Compressing objects: 100% (725/725), done.
>remote: Total 2543 (delta 2112), reused 2207 (delta 1816)
>Receiving objects: 100% (2543/2543), 503.18 KiB | 0 bytes/s, done.
>Resolving deltas: 100% (2112/2112), completed with 675 local objects.
>From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
>   c1ae3cf..56b24d1  master -> origin/master
>$ git show v4.11-rc2
>fatal: ambiguous argument 'v4.11-rc2': unknown revision or path not in
>the working tree.
>Use '--' to separate paths from revisions, like this:
>'git  [...] -- [...]'
>$ git tag -l *4.11-rc[12]
>v4.11-rc1
>$ host git.kernel.org
>git.kernel.org is an alias for pub.kernel.org.
>pub.kernel.org is an alias for pub.ewr.kernel.org.
>pub.ewr.kernel.org has address 147.75.196.57
>pub.ewr.kernel.org has IPv6 address 2604:1380:1:3600::3
>
>Coincidence? (I'm in NYC in case it matters. I'm using IPv4 from here,
>but was most likely on IPv6 at home yesterday when I first had the
>issue.)

I've identified and fixed the mirroring issue with the EWR frontend.  
All repositories should now be up-to-date. Apologies about the problem!

-Konstantin

[Kernel.org Helpdesk #38150] [linuxfoundation.org #38150] Re: Linux 4.10.2

[Konstantin Ryabitsev via RT]

On Mon, Mar 13, 2017 at 10:32:59AM -0500, Robert Nelson wrote:
>rcnee@debian:~$ git clone
>git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>Cloning into 'linux'...
>remote: Counting objects: 5266818, done.
>remote: Compressing objects: 100% (803214/803214), done.
>remote: Total 5266818 (delta 4423326), reused 5266191 (delta 4422778)
>Receiving objects: 100% (5266818/5266818), 921.29 MiB | 21.70 MiB/s, done.
>Resolving deltas: 100% (4423326/4423326), done.
>Checking connectivity... done.
>Checking out files: 100% (57992/57992), done.
>rcnee@debian:~$ cd linux/
>rcnee@debian:~/linux$ git tag -l *4.11-rc[12]
>v4.11-rc1

I'm chasing down a few reports, but haven't narrowed it down yet. Can 
you tell me what "host git.kernel.org" resolves as for you?

-K

[Kernel.org Helpdesk #38150] [linuxfoundation.org #38150] Re: Linux 4.10.2

[Konstantin Ryabitsev via RT]

On Mon, Mar 13, 2017 at 10:32:59AM -0500, Robert Nelson wrote:
>rcnee@debian:~$ git clone
>git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>Cloning into 'linux'...
>remote: Counting objects: 5266818, done.
>remote: Compressing objects: 100% (803214/803214), done.
>remote: Total 5266818 (delta 4423326), reused 5266191 (delta 4422778)
>Receiving objects: 100% (5266818/5266818), 921.29 MiB | 21.70 MiB/s, done.
>Resolving deltas: 100% (4423326/4423326), done.
>Checking connectivity... done.
>Checking out files: 100% (57992/57992), done.
>rcnee@debian:~$ cd linux/
>rcnee@debian:~/linux$ git tag -l *4.11-rc[12]
>v4.11-rc1

I'm chasing down a few reports, but haven't narrowed it down yet. Can 
you tell me what "host git.kernel.org" resolves as for you?

-K