Discussion:
linux-next: Tree for Oct 24
Thierry Reding
2013-10-25 14:17:08 UTC
Permalink
On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding
On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
Hi all,
I've uploaded today's linux-next tree to the master branch of the
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
--------------
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
Guenter Roeck
2013-10-25 15:02:28 UTC
Permalink
Post by Thierry Reding
On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding
On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
Hi all,
I've uploaded today's linux-next tree to the master branch of the
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
--------------
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
Thierry Reding
2013-10-25 15:17:18 UTC
Permalink
Post by Guenter Roeck
Post by Thierry Reding
On Fri, Oct 25, 2013 at 6:35 AM, Thierry Reding
On Fri, Oct 25, 2013 at 1:35 AM, Thierry Reding
Hi all,
I've uploaded today's linux-next tree to the master branch of the
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
--------------
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
Guenter Roeck
2013-10-25 17:17:21 UTC
Permalink
Post by Thierry Reding
Post by Guenter Roeck
"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
Geert Uytterhoeven
2013-10-25 18:04:36 UTC
Permalink
Post by Guenter Roeck
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 -- ***@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
Guenter Roeck
2013-10-25 15:09:01 UTC
Permalink
Today's linux-next tree of the h8300-remove tree got a conflict in
drivers/parport/Kconfig
caused by commits e9783b0 (Revert "drivers: parport: Kconfig: exclude h8300
for PARPORT_PC") and d90c3eb (Kconfig cleanup (PARPORT_PC dependencies)).
I fixed it up (see below). Please verify that the resolution looks good.
Thanks,
Thierry
---
diff --cc drivers/parport/Kconfig
index f536685,dc82ef0..2225237
--- a/drivers/parport/Kconfig
+++ b/drivers/parport/Kconfig
@@@ -41,8 -35,10 +41,7 @@@ if PARPOR
config PARPORT_PC
tristate "PC-style hardware"
- depends on (!SPARC64 || PCI) && !SPARC32 && !M32R && !FRV && !S390 && \
- (!M68K || ISA) && !MN10300 && !AVR32 && !BLACKFIN && \
- !XTENSA && !CRIS
-
+ depends on ARCH_MIGHT_HAVE_PC_PARPORT
-
---help---
You should say Y here if you have a PC-style parallel port. All
IBM PC compatible computers and some Alphas have PC-style
I dropped the patch (revert) causing the conflict.

Guenter
Mark Brown
2013-10-25 15:45:46 UTC
Permalink
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.
Ingo Molnar
2013-10-26 08:40:33 UTC
Permalink
Today's linux-next merge of the tip tree got conflicts in
tools/perf/config/Makefile
tools/perf/config/feature-tests.mak
caused by commits 405ffbd (perf tools: Check libunwind for availability of
dwarf parsing feature) and mostly 308e1e7 (tools/perf/build: Clean up the
libunwind logic in config/Makefile) as well as various follow-up patches.
I fixed it up (see below). Please verify that the resolution looks good.
Also note that this isn't really a trivial resolution of a conflict, but
required modifying various other files. That causes rerere magic not to
work and needs part of conflict to be resolved manually. Perhaps a good
idea would be to rebase Jean's patch on top of the cleanups going on in
the tip tree? Perhaps even carry the patch in the tip tree?
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html
Now that they've been pulled by rmk, we can't back them out with
ugly reverts, so I'm not sure what we can do to resolve in the ARM
tree; it looks like the perf Makefile has changed significantly in
-tip.
I realize that it was acked by Arnaldo, but for workflow reasons I'd
really prefer it if non-trivial perf tooling patches went to Arnaldo
as a pull request so that he can resolve any such conflicts. perf is
in constant development so it's less work for you that way.

(Kernel side changes can go that route as well, as long as they are
perf related.)

Thanks,

Ingo
Will Deacon
2013-10-26 14:01:25 UTC
Permalink
Hi Ingo,

[adding rmk]
Post by Ingo Molnar
I fixed it up (see below). Please verify that the resolution looks good.
Also note that this isn't really a trivial resolution of a conflict, but
required modifying various other files. That causes rerere magic not to
work and needs part of conflict to be resolved manually. Perhaps a good
idea would be to rebase Jean's patch on top of the cleanups going on in
the tip tree? Perhaps even carry the patch in the tip tree?
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html
Now that they've been pulled by rmk, we can't back them out with
ugly reverts, so I'm not sure what we can do to resolve in the ARM
tree; it looks like the perf Makefile has changed significantly in
-tip.
I realize that it was acked by Arnaldo, but for workflow reasons I'd
really prefer it if non-trivial perf tooling patches went to Arnaldo
as a pull request so that he can resolve any such conflicts. perf is
in constant development so it's less work for you that way.
Sure. I wasn't aware quite how much you guys had planned for the perf
Makefile and I (wrongly) assumed that Arnaldo's ack was enough of an
indication that conflicts would be unlikely and/or trivial.

In future, I'll push back on any perf changes outside of arch/ in my tree,
but that doesn't help us get out of the current situation: the patches are
currently sitting in rmk's tree for 3.13, so that won't meet with -tip
(outside of next) until Linus pulls them both. What can we do about that?

Will
Ingo Molnar
2013-10-27 07:12:37 UTC
Permalink
Post by Will Deacon
Hi Ingo,
[adding rmk]
Post by Ingo Molnar
I fixed it up (see below). Please verify that the resolution looks good.
Also note that this isn't really a trivial resolution of a conflict, but
required modifying various other files. That causes rerere magic not to
work and needs part of conflict to be resolved manually. Perhaps a good
idea would be to rebase Jean's patch on top of the cleanups going on in
the tip tree? Perhaps even carry the patch in the tip tree?
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203077.html
Now that they've been pulled by rmk, we can't back them out with
ugly reverts, so I'm not sure what we can do to resolve in the ARM
tree; it looks like the perf Makefile has changed significantly in
-tip.
I realize that it was acked by Arnaldo, but for workflow reasons I'd
really prefer it if non-trivial perf tooling patches went to Arnaldo
as a pull request so that he can resolve any such conflicts. perf is
in constant development so it's less work for you that way.
Sure. I wasn't aware quite how much you guys had planned for the perf
Makefile and I (wrongly) assumed that Arnaldo's ack was enough of an
indication that conflicts would be unlikely and/or trivial.
That was a bit of unlucky timing.
Post by Will Deacon
In future, I'll push back on any perf changes outside of arch/ in my
tree, but that doesn't help us get out of the current situation: the
patches are currently sitting in rmk's tree for 3.13, so that won't meet
with -tip (outside of next) until Linus pulls them both. What can we do
about that?
Unless you guys want to do a revert I guess there's not much to do but to
warn Linus in the ARM pull request that a conflict is coming up.

Thanks,

Ingo
Russell King - ARM Linux
2013-10-27 10:00:48 UTC
Permalink
Post by Ingo Molnar
Post by Will Deacon
In future, I'll push back on any perf changes outside of arch/ in my
tree, but that doesn't help us get out of the current situation: the
patches are currently sitting in rmk's tree for 3.13, so that won't meet
with -tip (outside of next) until Linus pulls them both. What can we do
about that?
Unless you guys want to do a revert I guess there's not much to do but to
warn Linus in the ARM pull request that a conflict is coming up.
From Will's description, it sounded like this could be quite hairy to
fix up, so I'd like to include the conflict resolution in the pull
request so Linus has something to refer to if needed. Could someone
please forward me that?

Thanks.
Thierry Reding
2013-10-28 07:47:22 UTC
Permalink
Post by Ingo Molnar
Post by Ingo Molnar
Post by Will Deacon
In future, I'll push back on any perf changes outside of arch/ in my
tree, but that doesn't help us get out of the current situation: the
patches are currently sitting in rmk's tree for 3.13, so that won't meet
with -tip (outside of next) until Linus pulls them both. What can we do
about that?
Unless you guys want to do a revert I guess there's not much to do but to
warn Linus in the ARM pull request that a conflict is coming up.
From Will's description, it sounded like this could be quite hairy to
fix up, so I'd like to include the conflict resolution in the pull
request so Linus has something to refer to if needed. Could someone
please forward me that?
Hi Russell,

I've attached the relevant parts of the resolution, although I'm not
sure if anybody's actually confirmed that it's correct. FWIW, if I run

make tools/perf

I do get the expected output:

Auto-detecting system features:
... backtrace: [ on ]
... dwarf: [ on ]
... fortify-source: [ on ]
... glibc: [ on ]
... gtk2: [ on ]
... gtk2-infobar: [ on ]
... libaudit: [ OFF ]
... libbfd: [ OFF ]
... libelf: [ on ]
... libelf-getphdrnum: [ on ]
... libelf-mmap: [ on ]
... libnuma: [ OFF ]
... libperl: [ on ]
... libpython: [ on ]
... libpython-version: [ OFF ]
... libslang: [ OFF ]
... libunwind: [ on ]
... libunwind-debug-frame: [ OFF ]
... on-exit: [ on ]
... stackprotector: [ on ]
... stackprotector-all: [ on ]

Which I guess means that the version of libunwind that I have doesn't
enable debug-frame support, but that's as expected according to the
package build script.

Thierry
Russell King - ARM Linux
2013-10-28 08:45:37 UTC
Permalink
Post by Thierry Reding
Post by Ingo Molnar
Post by Ingo Molnar
Post by Will Deacon
In future, I'll push back on any perf changes outside of arch/ in my
tree, but that doesn't help us get out of the current situation: the
patches are currently sitting in rmk's tree for 3.13, so that won't meet
with -tip (outside of next) until Linus pulls them both. What can we do
about that?
Unless you guys want to do a revert I guess there's not much to do but to
warn Linus in the ARM pull request that a conflict is coming up.
From Will's description, it sounded like this could be quite hairy to
fix up, so I'd like to include the conflict resolution in the pull
request so Linus has something to refer to if needed. Could someone
please forward me that?
Hi Russell,
I've attached the relevant parts of the resolution, although I'm not
sure if anybody's actually confirmed that it's correct.
I'm not sure whether that can happen any time before -final - Will is
(storm dependent) flying out to Linaro Connect today, and I've no idea
who to turn to for this to be tested for ARM.

I guess we have some time given that Linus has released -rc7 and his
comments during the Kernel Summit/in the rc7 announcement.

Russell King - ARM Linux
2013-10-26 13:19:38 UTC
Permalink
diff --cc arch/arm/Kconfig
index c06647d,7db8abe0..b6a708e
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -5,7 -5,7 +5,8 @@@ config AR
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
+ select ARCH_USE_CMPXCHG_LOCKREF
+ select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_WANT_IPC_PARSE_VERSION
Thanks. Generally we want these things to be arranged alphabetically to
reduce the longer term chances of hitting merge conflicts, but in this
case it wouldn't make any difference.
Thierry Reding
2013-10-28 07:34:46 UTC
Permalink
Post by Russell King - ARM Linux
diff --cc arch/arm/Kconfig
index c06647d,7db8abe0..b6a708e
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@@ -5,7 -5,7 +5,8 @@@ config AR
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
+ select ARCH_USE_CMPXCHG_LOCKREF
+ select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_WANT_IPC_PARSE_VERSION
Thanks. Generally we want these things to be arranged alphabetically to
reduce the longer term chances of hitting merge conflicts, but in this
case it wouldn't make any difference.
I was aiming for alphabetical order... guess I need to revisit my ABCs.

Thierry
Continue reading on narkive:
Loading...