[Kernel.org Helpdesk #40777] Re: Linux 4.12-rc1 (file locations)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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
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