linux-next: Tree for Oct 24
Hi all, Changes since 20161021: The net tree lost its build failure. The net-next tree gained a conflict against the net tree. The drm-misc tree gained conflicts against the drm-intel tree and a build failure for which I applied a merge fix patch. The akpm-current tree still had its build failures for which I applied 2 patches. Non-merge commits (relative to Linus' tree): 1743 2156 files changed, 167460 insertions(+), 31398 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 245 trees (counting Linus' and 35 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (0c2b6dc4fd4f Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging fixes/master (30066ce675d3 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging kbuild-current/rc-fixes (989cea5c14be kbuild: prevent lib-ksyms.o rebuilds) Merging arc-current/for-curr (27a6de25fa5d ARC: build: retire old toggles) Merging arm-current/fixes (6127d124ee4e ARM: wire up new pkey syscalls) Merging m68k-current/for-linus (6736e65effc3 m68k: Migrate exception table users off module.h and onto extable.h) Merging metag-fixes/fixes (35d04077ad96 metag: Only define atomic_dec_if_positive conditionally) Merging powerpc-fixes/fixes (78914ff08436 powerpc: Ignore the pkey system calls for now) Merging sparc/master (4c1fad64eff4 Merge tag 'for-f2fs-4.9' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs) Merging net/master (44060abe1dd6 Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth) CONFLICT (content): Merge conflict in drivers/net/ethernet/qlogic/Kconfig Applying: qed*: merge fix for CONFIG_INFINIBAND_QEDR Kconfig move Merging ipsec/master (7f92083eb58f vti6: flush x-netns xfrm cache when vti interface is removed) Merging netfilter/master (7034b566a4e7 netfilter: fix nf_queue handling) Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes') Merging wireless-drivers/master (1ea2643961b0 ath6kl: add Dell OEM SDIO I/O for the Venue 8 Pro) Merging mac80211/master (b4f0fd4baa90 qed: Use list_move_tail instead of list_del/list_add_tail) Merging sound-current/for-linus (6aecd8715802 ALSA: hda - Fix headset mic detection problem for two Dell laptops) Merging pci-current/for-linus (02a1b8f4167e PCI: designware-plat: Update author email address) Merging driver-core.current/driver-core-linus (1001354ca341 Linux 4.9-rc1) Merging tty.current/tty-linus (1001354ca341 Linux 4.9-rc1) Merging usb.current/usb-linus (36de70ea8d23 Merge tag 'usb-serial-4.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus) Merging usb-gadget-fixes/fixes (a1aa8cf6471b Revert "Documentation: devicetree: dwc2: Deprecate g-tx-fifo-size") Merging usb-serial-fixes/usb-linus (126d26f66d98 USB: serial: fix potential NULL-dereference at probe) Merging usb-chipidea-fixes/ci-for-usb-stable (6b7f456e67a1 usb: chipidea: host: fix NULL ptr dereference during shutdown) Merging phy/fixes (1001354ca341 Linux 4.9-rc1) Merging staging.current/staging-linus (c89d98e224b4 staging/lustre/llite: Move unstable_stats from sysfs to debugfs) Merging char-misc.current/char-misc-linus (1001354ca341 Linux 4.9-rc1) Merging input-current/for-linus (da25311c7ca8 Input: i8042 - add XMG C504 to keyboard reset table) Me
Re: linux-next: Tree for Oct 24
On Fri, Oct 25, 2013 at 7:17 PM, Guenter Roeck wrote:
> I think one problem we have is how to report breakages. Any summary
> mail or web page doesn't help if no one looks at it. It does help lot
> to send specific e-mail along the line of "Commit 'bla' caused build 'x'
> to fail as follows" to the respective mailing list and patch authors,
> but that takes a lot of time which at least I don't have. And people
> might get annoyed by automated e-mails, so that might not be a good
> idea either.
In theory, these blame emails can be automated using some git bisect
scripting.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 24
On Fri, Oct 25, 2013 at 05:17:18PM +0200, Thierry Reding wrote: > > > > > "Doesn't even build" is relative, though. After all, there still _are_ > > 18 build failures out of 106 in my test builds alone. Where do you draw > > the line ? arm failures are bad, who cares about blackfin ? > > Well, I've been doing x86, ARM and PowerPC builds and of those only 3 > are failing and I didn't fix them because I didn't really know how to. > But you're right, I guess one has to draw the line somewhere, and if > people prefer the tree to just be broken rather than with odd fixes on > top, then that's the way it going to be. > > For now I've settled on pushing a branch which has only the fixes that > are required to make the trees work happily together and a separate tag > which has the patches that unbreak subsystem trees. > > The reason I usually want linux-next to build is because I know that > various people rely on it for their daily work, so my reasoning was that > if I fix it before they even start using it, then they get to spend > their time with something more useful and only one person ends up fixing > the build issues instead of everyone. > Frankly, I don't even know what the best approach would be. Ultimately you are stuck between a rock and a hard place: You want the tree to build so people can use it, but each patch you apply yourself might result in it not getting fixed in the contributing repository. I think one problem we have is how to report breakages. Any summary mail or web page doesn't help if no one looks at it. It does help lot to send specific e-mail along the line of "Commit 'bla' caused build 'x' to fail as follows" to the respective mailing list and patch authors, but that takes a lot of time which at least I don't have. And people might get annoyed by automated e-mails, so that might not be a good idea either. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 24
On Fri, Oct 25, 2013 at 06:33:43AM -0700, Olof Johansson wrote: > On Fri, Oct 25, 2013 at 6:24 AM, Mark Brown wrote: > > The rule I was applying (which I think is the same as Stephen applies) > > is that I'd fix anything that was definitely the result of a merge issue > > (like the build failure in misc due to a sysfs API change in the sysfs > > tree) but not anything that was just plain broken in the tree in > > isolation. > Some of those might still make sense, but as many as possible of them > should be pushed down into the trees where they belong, even if > they're strictly not needed there (as long as they don't break the > standalone tree, of course). Right, this is strictly for issues generated as a result of a change in one tree that cause an issue when merged with another tree like adding a user of an API in one tree that has had an incompatible change in another. signature.asc Description: Digital signature
Re: linux-next: Tree for Oct 24
On Fri, Oct 25, 2013 at 08:02:28AM -0700, Guenter Roeck wrote: > On Fri, Oct 25, 2013 at 04:17:08PM +0200, Thierry Reding wrote: > > On Fri, Oct 25, 2013 at 06:43:53AM -0700, Olof Johansson wrote: > > > On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding > > > wrote: > > > > On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote: > > > >> On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding > > > >> wrote: > > > >> > On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote: > > > >> >> On 10/24/2013 09:31 AM, Thierry Reding wrote: > > > >> >> >Hi all, > > > >> >> > > > > >> >> >I've uploaded today's linux-next tree to the master branch of the > > > >> >> >repository below: > > > >> >> > > > > >> >> > git://gitorious.org/thierryreding/linux-next.git > > > >> >> > > > > >> >> >A next-20131024 tag is also provided for convenience. > > > >> >> > > > > >> >> >Quite a few new conflicts. Some of them non-trivial. I've fixed > > > >> >> >another > > > >> >> >set of build failures, so 32-bit and 64-bit allmodconfigs build > > > >> >> >fine on > > > >> >> >x86. ARM and x86 default configurations also build fine. PowerPC > > > >> >> >is in > > > >> >> >pretty bad shape, mostly due to some OF header rework going on. > > > >> >> > > > > >> >> > > > >> >> Hmm ... I see > > > >> >> > > > >> >> Building arm:defconfig ... failed > > > >> >> -- > > > >> >> Error log: > > > >> >> drivers/built-in.o: In function `mmc_gpio_request_cd': > > > >> >> clkdev.c:(.text+0x74cf8): undefined reference to > > > >> >> `devm_gpio_request_one' > > > >> >> make: *** [vmlinux] Error 1 > > > >> >> > > > >> >> Otherwise pretty much the same as yesterday, with a build log of > > > >> >> total: 110 pass: 88 skipped: 4 fail: 18 > > > >> >> > > > >> >> This is with "v3.12-rc5-7941-g765f88c". > > > >> > > > > >> > Yeah, I saw the devm_gpio_request_one() errors too. They happened > > > >> > for 3 > > > >> > boards on ARM I think. Must have forgotten to update the summary > > > >> > email. > > > >> > I'll see if I can come up with a patch to fix the GPIO related build > > > >> > failures, or at least report it to LinusW or Alexandre. > > > >> > > > >> Hmm. > > > >> > > > >> Please don't apply fixes like these directly to your tree, keep the > > > >> broken parts (or drop the tree that introduced it). It makes the > > > >> process of getting the fixes in where they really have to go much more > > > >> error prone, since there's no way to track whether they have landed in > > > >> the right place yet or not. > > > > > > > > I've found that fixing one build error often subsequent build failures, > > > > which would go unnoticed if I dropped the trees or let the breakage > > > > unfixed. > > > > > > Yeah, that's what happened with the GPIO subsystem on this release -- > > > there are two build errors but your fix resolves one of them such at > > > the other one is exposed. It makes it confusing to bisect down to root > > > cause. I'd almost rather have your tree just being broken, but patches > > > submitted and sent in to the maintainer in question if you want to get > > > it fixed ASAP. > > > > I guess I could probably just push the final merge commit as a tree, but > > it would require me to very strongly resist my compulsive urge not to > > push something that doesn't even build. > > > "Doesn't even build" is relative, though. After all, there still _are_ > 18 build failures out of 106 in my test builds alone. Where do you draw > the line ? arm failures are bad, who cares about blackfin ? Well, I've been doing x86, ARM and PowerPC builds and of those only 3 are failing and I didn't fix them because I didn't really know how to. But you're right, I guess one has to draw the line somewhere, and if people prefer the tree to just be broken rather than with odd fixes on top, then that's the way it going to be. For now I've settled on pushing a branch which has only the fixes that are required to make the trees work happily together and a separate tag which has the patches that unbreak subsystem trees. The reason I usually want linux-next to build is because I know that various people rely on it for their daily work, so my reasoning was that if I fix it before they even start using it, then they get to spend their time with something more useful and only one person ends up fixing the build issues instead of everyone. Thierry pgpYFdASqbWIw.pgp Description: PGP signature
Re: linux-next: Tree for Oct 24
On Fri, Oct 25, 2013 at 04:17:08PM +0200, Thierry Reding wrote: > On Fri, Oct 25, 2013 at 06:43:53AM -0700, Olof Johansson wrote: > > On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding > > wrote: > > > On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote: > > >> On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding > > >> wrote: > > >> > On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote: > > >> >> On 10/24/2013 09:31 AM, Thierry Reding wrote: > > >> >> >Hi all, > > >> >> > > > >> >> >I've uploaded today's linux-next tree to the master branch of the > > >> >> >repository below: > > >> >> > > > >> >> > git://gitorious.org/thierryreding/linux-next.git > > >> >> > > > >> >> >A next-20131024 tag is also provided for convenience. > > >> >> > > > >> >> >Quite a few new conflicts. Some of them non-trivial. I've fixed > > >> >> >another > > >> >> >set of build failures, so 32-bit and 64-bit allmodconfigs build fine > > >> >> >on > > >> >> >x86. ARM and x86 default configurations also build fine. PowerPC is > > >> >> >in > > >> >> >pretty bad shape, mostly due to some OF header rework going on. > > >> >> > > > >> >> > > >> >> Hmm ... I see > > >> >> > > >> >> Building arm:defconfig ... failed > > >> >> -- > > >> >> Error log: > > >> >> drivers/built-in.o: In function `mmc_gpio_request_cd': > > >> >> clkdev.c:(.text+0x74cf8): undefined reference to > > >> >> `devm_gpio_request_one' > > >> >> make: *** [vmlinux] Error 1 > > >> >> > > >> >> Otherwise pretty much the same as yesterday, with a build log of > > >> >> total: 110 pass: 88 skipped: 4 fail: 18 > > >> >> > > >> >> This is with "v3.12-rc5-7941-g765f88c". > > >> > > > >> > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3 > > >> > boards on ARM I think. Must have forgotten to update the summary email. > > >> > I'll see if I can come up with a patch to fix the GPIO related build > > >> > failures, or at least report it to LinusW or Alexandre. > > >> > > >> Hmm. > > >> > > >> Please don't apply fixes like these directly to your tree, keep the > > >> broken parts (or drop the tree that introduced it). It makes the > > >> process of getting the fixes in where they really have to go much more > > >> error prone, since there's no way to track whether they have landed in > > >> the right place yet or not. > > > > > > I've found that fixing one build error often subsequent build failures, > > > which would go unnoticed if I dropped the trees or let the breakage > > > unfixed. > > > > Yeah, that's what happened with the GPIO subsystem on this release -- > > there are two build errors but your fix resolves one of them such at > > the other one is exposed. It makes it confusing to bisect down to root > > cause. I'd almost rather have your tree just being broken, but patches > > submitted and sent in to the maintainer in question if you want to get > > it fixed ASAP. > > I guess I could probably just push the final merge commit as a tree, but > it would require me to very strongly resist my compulsive urge not to > push something that doesn't even build. > "Doesn't even build" is relative, though. After all, there still _are_ 18 build failures out of 106 in my test builds alone. Where do you draw the line ? arm failures are bad, who cares about blackfin ? Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 24
On Fri, Oct 25, 2013 at 06:43:53AM -0700, Olof Johansson wrote: > On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding > wrote: > > On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote: > >> On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding > >> wrote: > >> > On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote: > >> >> On 10/24/2013 09:31 AM, Thierry Reding wrote: > >> >> >Hi all, > >> >> > > >> >> >I've uploaded today's linux-next tree to the master branch of the > >> >> >repository below: > >> >> > > >> >> > git://gitorious.org/thierryreding/linux-next.git > >> >> > > >> >> >A next-20131024 tag is also provided for convenience. > >> >> > > >> >> >Quite a few new conflicts. Some of them non-trivial. I've fixed another > >> >> >set of build failures, so 32-bit and 64-bit allmodconfigs build fine on > >> >> >x86. ARM and x86 default configurations also build fine. PowerPC is in > >> >> >pretty bad shape, mostly due to some OF header rework going on. > >> >> > > >> >> > >> >> Hmm ... I see > >> >> > >> >> Building arm:defconfig ... failed > >> >> -- > >> >> Error log: > >> >> drivers/built-in.o: In function `mmc_gpio_request_cd': > >> >> clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one' > >> >> make: *** [vmlinux] Error 1 > >> >> > >> >> Otherwise pretty much the same as yesterday, with a build log of > >> >> total: 110 pass: 88 skipped: 4 fail: 18 > >> >> > >> >> This is with "v3.12-rc5-7941-g765f88c". > >> > > >> > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3 > >> > boards on ARM I think. Must have forgotten to update the summary email. > >> > I'll see if I can come up with a patch to fix the GPIO related build > >> > failures, or at least report it to LinusW or Alexandre. > >> > >> Hmm. > >> > >> Please don't apply fixes like these directly to your tree, keep the > >> broken parts (or drop the tree that introduced it). It makes the > >> process of getting the fixes in where they really have to go much more > >> error prone, since there's no way to track whether they have landed in > >> the right place yet or not. > > > > I've found that fixing one build error often subsequent build failures, > > which would go unnoticed if I dropped the trees or let the breakage > > unfixed. > > Yeah, that's what happened with the GPIO subsystem on this release -- > there are two build errors but your fix resolves one of them such at > the other one is exposed. It makes it confusing to bisect down to root > cause. I'd almost rather have your tree just being broken, but patches > submitted and sent in to the maintainer in question if you want to get > it fixed ASAP. I guess I could probably just push the final merge commit as a tree, but it would require me to very strongly resist my compulsive urge not to push something that doesn't even build. I suppose if we could write that down into some kind of rule I could go look at it until the compulsiveness wears down... =) > In particular, the gpio fix in the tree right now has no description, etc. Yes, I know. FWIW I fixed that up properly in today's tree, which I'm almost ready to push out. Thierry pgp3jWloyp_oT.pgp Description: PGP signature
Re: linux-next: Tree for Oct 24
On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding wrote: > On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote: >> On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding >> wrote: >> > On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote: >> >> On 10/24/2013 09:31 AM, Thierry Reding wrote: >> >> >Hi all, >> >> > >> >> >I've uploaded today's linux-next tree to the master branch of the >> >> >repository below: >> >> > >> >> > git://gitorious.org/thierryreding/linux-next.git >> >> > >> >> >A next-20131024 tag is also provided for convenience. >> >> > >> >> >Quite a few new conflicts. Some of them non-trivial. I've fixed another >> >> >set of build failures, so 32-bit and 64-bit allmodconfigs build fine on >> >> >x86. ARM and x86 default configurations also build fine. PowerPC is in >> >> >pretty bad shape, mostly due to some OF header rework going on. >> >> > >> >> >> >> Hmm ... I see >> >> >> >> Building arm:defconfig ... failed >> >> -- >> >> Error log: >> >> drivers/built-in.o: In function `mmc_gpio_request_cd': >> >> clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one' >> >> make: *** [vmlinux] Error 1 >> >> >> >> Otherwise pretty much the same as yesterday, with a build log of >> >> total: 110 pass: 88 skipped: 4 fail: 18 >> >> >> >> This is with "v3.12-rc5-7941-g765f88c". >> > >> > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3 >> > boards on ARM I think. Must have forgotten to update the summary email. >> > I'll see if I can come up with a patch to fix the GPIO related build >> > failures, or at least report it to LinusW or Alexandre. >> >> Hmm. >> >> Please don't apply fixes like these directly to your tree, keep the >> broken parts (or drop the tree that introduced it). It makes the >> process of getting the fixes in where they really have to go much more >> error prone, since there's no way to track whether they have landed in >> the right place yet or not. > > I've found that fixing one build error often subsequent build failures, > which would go unnoticed if I dropped the trees or let the breakage > unfixed. Yeah, that's what happened with the GPIO subsystem on this release -- there are two build errors but your fix resolves one of them such at the other one is exposed. It makes it confusing to bisect down to root cause. I'd almost rather have your tree just being broken, but patches submitted and sent in to the maintainer in question if you want to get it fixed ASAP. In particular, the gpio fix in the tree right now has no description, etc. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 24
On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote: > On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding > wrote: > > On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote: > >> On 10/24/2013 09:31 AM, Thierry Reding wrote: > >> >Hi all, > >> > > >> >I've uploaded today's linux-next tree to the master branch of the > >> >repository below: > >> > > >> > git://gitorious.org/thierryreding/linux-next.git > >> > > >> >A next-20131024 tag is also provided for convenience. > >> > > >> >Quite a few new conflicts. Some of them non-trivial. I've fixed another > >> >set of build failures, so 32-bit and 64-bit allmodconfigs build fine on > >> >x86. ARM and x86 default configurations also build fine. PowerPC is in > >> >pretty bad shape, mostly due to some OF header rework going on. > >> > > >> > >> Hmm ... I see > >> > >> Building arm:defconfig ... failed > >> -- > >> Error log: > >> drivers/built-in.o: In function `mmc_gpio_request_cd': > >> clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one' > >> make: *** [vmlinux] Error 1 > >> > >> Otherwise pretty much the same as yesterday, with a build log of > >> total: 110 pass: 88 skipped: 4 fail: 18 > >> > >> This is with "v3.12-rc5-7941-g765f88c". > > > > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3 > > boards on ARM I think. Must have forgotten to update the summary email. > > I'll see if I can come up with a patch to fix the GPIO related build > > failures, or at least report it to LinusW or Alexandre. > > Hmm. > > Please don't apply fixes like these directly to your tree, keep the > broken parts (or drop the tree that introduced it). It makes the > process of getting the fixes in where they really have to go much more > error prone, since there's no way to track whether they have landed in > the right place yet or not. I've found that fixing one build error often subsequent build failures, which would go unnoticed if I dropped the trees or let the breakage unfixed. Except for very few occasions I've immediately sent out patches to the respective subsystem maintainers, so they should've gotten picked up. What's the difference if I do it as part of linux-next to if somebody does it outside? At least this way they are part of the linux-next tree so if I create the next one and cherry-pick the patches and they still apply I can be reasonably sure that they haven't landed in the right place yet. Thierry pgpAc_ZFR0YAL.pgp Description: PGP signature
Re: linux-next: Tree for Oct 24
On Fri, Oct 25, 2013 at 6:24 AM, Mark Brown wrote: > On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote: >> On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding > >> > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3 >> > boards on ARM I think. Must have forgotten to update the summary email. >> > I'll see if I can come up with a patch to fix the GPIO related build >> > failures, or at least report it to LinusW or Alexandre. > >> Hmm. > >> Please don't apply fixes like these directly to your tree, keep the >> broken parts (or drop the tree that introduced it). It makes the >> process of getting the fixes in where they really have to go much more >> error prone, since there's no way to track whether they have landed in >> the right place yet or not. > > The rule I was applying (which I think is the same as Stephen applies) > is that I'd fix anything that was definitely the result of a merge issue > (like the build failure in misc due to a sysfs API change in the sysfs > tree) but not anything that was just plain broken in the tree in > isolation. Some of those might still make sense, but as many as possible of them should be pushed down into the trees where they belong, even if they're strictly not needed there (as long as they don't break the standalone tree, of course). -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 24
On Fri, Oct 25, 2013 at 06:16:02AM -0700, Olof Johansson wrote: > On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding > > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3 > > boards on ARM I think. Must have forgotten to update the summary email. > > I'll see if I can come up with a patch to fix the GPIO related build > > failures, or at least report it to LinusW or Alexandre. > Hmm. > Please don't apply fixes like these directly to your tree, keep the > broken parts (or drop the tree that introduced it). It makes the > process of getting the fixes in where they really have to go much more > error prone, since there's no way to track whether they have landed in > the right place yet or not. The rule I was applying (which I think is the same as Stephen applies) is that I'd fix anything that was definitely the result of a merge issue (like the build failure in misc due to a sysfs API change in the sysfs tree) but not anything that was just plain broken in the tree in isolation. signature.asc Description: Digital signature
Re: linux-next: Tree for Oct 24
On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding wrote: > On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote: >> On 10/24/2013 09:31 AM, Thierry Reding wrote: >> >Hi all, >> > >> >I've uploaded today's linux-next tree to the master branch of the >> >repository below: >> > >> > git://gitorious.org/thierryreding/linux-next.git >> > >> >A next-20131024 tag is also provided for convenience. >> > >> >Quite a few new conflicts. Some of them non-trivial. I've fixed another >> >set of build failures, so 32-bit and 64-bit allmodconfigs build fine on >> >x86. ARM and x86 default configurations also build fine. PowerPC is in >> >pretty bad shape, mostly due to some OF header rework going on. >> > >> >> Hmm ... I see >> >> Building arm:defconfig ... failed >> -- >> Error log: >> drivers/built-in.o: In function `mmc_gpio_request_cd': >> clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one' >> make: *** [vmlinux] Error 1 >> >> Otherwise pretty much the same as yesterday, with a build log of >> total: 110 pass: 88 skipped: 4 fail: 18 >> >> This is with "v3.12-rc5-7941-g765f88c". > > Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3 > boards on ARM I think. Must have forgotten to update the summary email. > I'll see if I can come up with a patch to fix the GPIO related build > failures, or at least report it to LinusW or Alexandre. Hmm. Please don't apply fixes like these directly to your tree, keep the broken parts (or drop the tree that introduced it). It makes the process of getting the fixes in where they really have to go much more error prone, since there's no way to track whether they have landed in the right place yet or not. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Oct 24
On Thu, Oct 24, 2013 at 10:02:22PM -0700, Guenter Roeck wrote: > On 10/24/2013 09:31 AM, Thierry Reding wrote: > >Hi all, > > > >I've uploaded today's linux-next tree to the master branch of the > >repository below: > > > > git://gitorious.org/thierryreding/linux-next.git > > > >A next-20131024 tag is also provided for convenience. > > > >Quite a few new conflicts. Some of them non-trivial. I've fixed another > >set of build failures, so 32-bit and 64-bit allmodconfigs build fine on > >x86. ARM and x86 default configurations also build fine. PowerPC is in > >pretty bad shape, mostly due to some OF header rework going on. > > > > Hmm ... I see > > Building arm:defconfig ... failed > -- > Error log: > drivers/built-in.o: In function `mmc_gpio_request_cd': > clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one' > make: *** [vmlinux] Error 1 > > Otherwise pretty much the same as yesterday, with a build log of > total: 110 pass: 88 skipped: 4 fail: 18 > > This is with "v3.12-rc5-7941-g765f88c". Yeah, I saw the devm_gpio_request_one() errors too. They happened for 3 boards on ARM I think. Must have forgotten to update the summary email. I'll see if I can come up with a patch to fix the GPIO related build failures, or at least report it to LinusW or Alexandre. Thierry pgpo9Ypt14keR.pgp Description: PGP signature
Re: linux-next: Tree for Oct 24
On 10/24/2013 09:31 AM, Thierry Reding wrote: Hi all, I've uploaded today's linux-next tree to the master branch of the repository below: git://gitorious.org/thierryreding/linux-next.git A next-20131024 tag is also provided for convenience. Quite a few new conflicts. Some of them non-trivial. I've fixed another set of build failures, so 32-bit and 64-bit allmodconfigs build fine on x86. ARM and x86 default configurations also build fine. PowerPC is in pretty bad shape, mostly due to some OF header rework going on. Hmm ... I see Building arm:defconfig ... failed -- Error log: drivers/built-in.o: In function `mmc_gpio_request_cd': clkdev.c:(.text+0x74cf8): undefined reference to `devm_gpio_request_one' make: *** [vmlinux] Error 1 Otherwise pretty much the same as yesterday, with a build log of total: 110 pass: 88 skipped: 4 fail: 18 This is with "v3.12-rc5-7941-g765f88c". Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Oct 24
Hi all, I've uploaded today's linux-next tree to the master branch of the repository below: git://gitorious.org/thierryreding/linux-next.git A next-20131024 tag is also provided for convenience. Quite a few new conflicts. Some of them non-trivial. I've fixed another set of build failures, so 32-bit and 64-bit allmodconfigs build fine on x86. ARM and x86 default configurations also build fine. PowerPC is in pretty bad shape, mostly due to some OF header rework going on. I'm somewhat short on time today, so I probably won't manage to send out detailed conflict reports out today. I'll try to do that tomorrow, though. Thierry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
On Thu, Oct 25, 2012 at 03:05:43PM +0100, Jan Beulich wrote: > >>> On 25.10.12 at 15:46, Konrad Rzeszutek Wilk > >>> wrote: > > On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote: > >> On Thu, 25 Oct 2012, Jan Beulich wrote: > >> > >>> On 24.10.12 at 23:33, Randy Dunlap wrote: > >> > > On 10/23/2012 09:19 PM, Stephen Rothwell wrote: > >> > > > >> > >> Hi all, > >> > >> > >> > >> Changes since 201201023: > >> > >> > >> > > > >> > > on x86_64: > >> > > > >> > > drivers/built-in.o: In function `dbgp_reset_prep': > >> > > (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep' > >> > > drivers/built-in.o: In function `dbgp_external_startup': > >> > > (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup' > >> > > > >> > > > >> > > Full randconfig file is attached. > >> > > >> > So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP > >> > dbgp_reset_prep() and dbgp_external_startup() get pointlessly > >> > defined and exported. This got broken by the merge > >> > recommendation for the ARM side changes (originally compilation > >> > of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0). > >> > > >> > >From my pov, fixing the USB side would be the clean solution (i.e. > >> > putting those function definitions inside a CONFIG_USB_SUPPORT > >> > conditional). > >> > > >> > The alternative of a smaller change would be to extend the > >> > conditional around the respective xen_dbgp_...() declarations > >> > in include/linux/usb/ehci_def.h to become > >> > > >> > #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT) > >> > > >> > Please advise towards your preference. > >> > >> I think that your first suggestion is the right one. > > > > Can you guys spin up a patch pls and make sure it does not break > > compilation. Thx. > > I'd really like to hear Greg's opinion on which route to take before > pointlessly trying the other one. I have no idea, please send patches. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
>>> On 25.10.12 at 15:46, Konrad Rzeszutek Wilk wrote: > On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote: >> On Thu, 25 Oct 2012, Jan Beulich wrote: >> > >>> On 24.10.12 at 23:33, Randy Dunlap wrote: >> > > On 10/23/2012 09:19 PM, Stephen Rothwell wrote: >> > > >> > >> Hi all, >> > >> >> > >> Changes since 201201023: >> > >> >> > > >> > > on x86_64: >> > > >> > > drivers/built-in.o: In function `dbgp_reset_prep': >> > > (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep' >> > > drivers/built-in.o: In function `dbgp_external_startup': >> > > (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup' >> > > >> > > >> > > Full randconfig file is attached. >> > >> > So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP >> > dbgp_reset_prep() and dbgp_external_startup() get pointlessly >> > defined and exported. This got broken by the merge >> > recommendation for the ARM side changes (originally compilation >> > of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0). >> > >> > >From my pov, fixing the USB side would be the clean solution (i.e. >> > putting those function definitions inside a CONFIG_USB_SUPPORT >> > conditional). >> > >> > The alternative of a smaller change would be to extend the >> > conditional around the respective xen_dbgp_...() declarations >> > in include/linux/usb/ehci_def.h to become >> > >> > #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT) >> > >> > Please advise towards your preference. >> >> I think that your first suggestion is the right one. > > Can you guys spin up a patch pls and make sure it does not break > compilation. Thx. I'd really like to hear Greg's opinion on which route to take before pointlessly trying the other one. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote: > On Thu, 25 Oct 2012, Jan Beulich wrote: > > >>> On 24.10.12 at 23:33, Randy Dunlap wrote: > > > On 10/23/2012 09:19 PM, Stephen Rothwell wrote: > > > > > >> Hi all, > > >> > > >> Changes since 201201023: > > >> > > > > > > on x86_64: > > > > > > drivers/built-in.o: In function `dbgp_reset_prep': > > > (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep' > > > drivers/built-in.o: In function `dbgp_external_startup': > > > (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup' > > > > > > > > > Full randconfig file is attached. > > > > So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP > > dbgp_reset_prep() and dbgp_external_startup() get pointlessly > > defined and exported. This got broken by the merge > > recommendation for the ARM side changes (originally compilation > > of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0). > > > > >From my pov, fixing the USB side would be the clean solution (i.e. > > putting those function definitions inside a CONFIG_USB_SUPPORT > > conditional). > > > > The alternative of a smaller change would be to extend the > > conditional around the respective xen_dbgp_...() declarations > > in include/linux/usb/ehci_def.h to become > > > > #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT) > > > > Please advise towards your preference. > > I think that your first suggestion is the right one. Can you guys spin up a patch pls and make sure it does not break compilation. Thx. > > > Otherwise we could also make drivers/xen/dbgp.c compile if > CONFIG_EARLY_PRINTK_DBGP rather than CONFIG_USB_SUPPORT. > I think that it would create fewer maintenance pains if dbgp_reset_prep > and dbgp_external_startup had the same compile requirements as their xen > counterparts (aside from Xen support of course). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
On Thu, 25 Oct 2012, Jan Beulich wrote: > >>> On 24.10.12 at 23:33, Randy Dunlap wrote: > > On 10/23/2012 09:19 PM, Stephen Rothwell wrote: > > > >> Hi all, > >> > >> Changes since 201201023: > >> > > > > on x86_64: > > > > drivers/built-in.o: In function `dbgp_reset_prep': > > (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep' > > drivers/built-in.o: In function `dbgp_external_startup': > > (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup' > > > > > > Full randconfig file is attached. > > So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP > dbgp_reset_prep() and dbgp_external_startup() get pointlessly > defined and exported. This got broken by the merge > recommendation for the ARM side changes (originally compilation > of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0). > > >From my pov, fixing the USB side would be the clean solution (i.e. > putting those function definitions inside a CONFIG_USB_SUPPORT > conditional). > > The alternative of a smaller change would be to extend the > conditional around the respective xen_dbgp_...() declarations > in include/linux/usb/ehci_def.h to become > > #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT) > > Please advise towards your preference. I think that your first suggestion is the right one. Otherwise we could also make drivers/xen/dbgp.c compile if CONFIG_EARLY_PRINTK_DBGP rather than CONFIG_USB_SUPPORT. I think that it would create fewer maintenance pains if dbgp_reset_prep and dbgp_external_startup had the same compile requirements as their xen counterparts (aside from Xen support of course). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)
>>> On 24.10.12 at 23:33, Randy Dunlap wrote: > On 10/23/2012 09:19 PM, Stephen Rothwell wrote: > >> Hi all, >> >> Changes since 201201023: >> > > on x86_64: > > drivers/built-in.o: In function `dbgp_reset_prep': > (.text+0xb96b5): undefined reference to `xen_dbgp_reset_prep' > drivers/built-in.o: In function `dbgp_external_startup': > (.text+0xb9d95): undefined reference to `xen_dbgp_external_startup' > > > Full randconfig file is attached. So this is because with !USB_SUPPORT but EARLY_PRINTK_DBGP dbgp_reset_prep() and dbgp_external_startup() get pointlessly defined and exported. This got broken by the merge recommendation for the ARM side changes (originally compilation of drivers/xen/dbgp.c depended on just CONFIG_XEN_DOM0). >From my pov, fixing the USB side would be the clean solution (i.e. putting those function definitions inside a CONFIG_USB_SUPPORT conditional). The alternative of a smaller change would be to extend the conditional around the respective xen_dbgp_...() declarations in include/linux/usb/ehci_def.h to become #if defined(CONFIG_XEN_DOM0) && defined(CONFIG_USB_SUPPORT) Please advise towards your preference. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Oct 24
Hi all, Changes since 201201023: The wireless-next tree lost its conflicts. The pm tree gained a build failure for which I applied a patch. The tty tree gained a build failure for which I disabled a staging driver. The usb tree lost its build failure. The akpm tree still has its 2 build failures for which I reverted some commits. It also lost a patch that turned up elsewhere. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 205 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (2d1f4c8 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux) Merging fixes/master (12250d8 Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux) Merging kbuild-current/rc-fixes (b1e0d8b kbuild: Fix gcc -x syntax) Merging arm-current/fixes (b43b1ff Merge tag 'fixes-for-rmk' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc into fixes) Merging m68k-current/for-linus (8a745ee m68k: Wire up kcmp) Merging powerpc-merge/merge (83dac59 cpuidle/powerpc: Fix snooze state problem in the cpuidle design on pseries.) Merging sparc/master (43c422e apparmor: fix apparmor OOPS in audit_log_untrustedstring+0x1c/0x40) Merging net/master (37561f6 tcp: Reject invalid ack_seq to Fast Open sockets) Merging sound-current/for-linus (21b3de8 ALSA: als3000: check for the kzalloc return value) Merging pci-current/for-linus (0ff9514 PCI: Don't print anything while decoding is disabled) Merging wireless/master (290eddc Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211) Merging driver-core.current/driver-core-linus (d28d388 firmware loader: sync firmware cache by async_synchronize_full_domain) Merging tty.current/tty-linus (6f0c058 Linux 3.7-rc2) Merging usb.current/usb-linus (3b6054d usb hub: send clear_tt_buffer_complete events when canceling TT clear work) Merging staging.current/staging-linus (b3ca610 staging: ramster: depends on NET) Merging char-misc.current/char-misc-linus (ddffeb8 Linux 3.7-rc1) Merging input-current/for-linus (0cc8d6a Merge branch 'next' into for-linus) Merging md-current/for-linus (72f36d5 md: refine reporting of resync/reshape delays.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (c9f97a2 crypto: x86/glue_helper - fix storing of new IV in CBC encryption) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging asm-generic/master (c37d615 Merge branch 'disintegrate-asm-generic' of git://git.infradead.org/users/dhowells/linux-h
