So. When trying to do the latest merge, this is what I get on a prep for the -tegra config:
+ mv kernel-3.10.0-armv7hl-tegra.config .config ++ head -1 .config ++ cut -b 3- + Arch=arm + make ARCH=arm listnewconfig + grep -E '^CONFIG_' warning: (VIRTIO_PCI && VIRTIO_MMIO && REMOTEPROC && RPMSG) selects VIRTIO which has unmet direct dependencies (VIRTUALIZATION) + '[' -s .newoptions ']' + cat .newoptions CONFIG_ARCH_MULTI_V6 CONFIG_ARCH_MULTI_V7 CONFIG_ARCH_MVEBU CONFIG_ARCH_BCM CONFIG_ARCH_HIGHBANK CONFIG_ARCH_MXC CONFIG_ARCH_OMAP2PLUS CONFIG_ARCH_SOCFPGA CONFIG_PLAT_SPEAR CONFIG_ARCH_SUNXI CONFIG_ARCH_SIRF CONFIG_ARCH_U8500 CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA CONFIG_ARCH_VEXPRESS_CA9X4 CONFIG_ARCH_VIRT CONFIG_ARCH_WM8850 CONFIG_ARCH_ZYNQ + exit 1 error: Bad exit status from /var/tmp/rpm-tmp.JpdsWj (%prep)
Now, looking at the various ARM config files, almost all of those are set in config-armv7. None of them are set in config-armv7-generic or config-armv7-tegra. The questions I have are:
1) What is config-armv7 and why is it different from config-armv7-generic?
2) Why does tegra (and the other boards) not inherit config-armv7 at all and only inherits from temp-armv7-generic (config-armv7-generic + config-generic)?
As it stands right now, either config-armv7-generic needs to inherit all the settings from config-armv7 or they need to be explicitly set in config-armv7-tegra. Explicitly setting them is feasible, but that's a lot of duplication. I've no clue what the setup here is, nor which option is correct.
Can you please tell me which to do so I can continue with this merge? I'd like to get -git12 fixed up and pushed out today.
josh
On Thu, May 2, 2013 at 6:43 PM, Josh Boyer jwboyer@redhat.com wrote:
So. When trying to do the latest merge, this is what I get on a prep for the -tegra config:
- mv kernel-3.10.0-armv7hl-tegra.config .config
++ head -1 .config ++ cut -b 3-
- Arch=arm
- make ARCH=arm listnewconfig
- grep -E '^CONFIG_'
warning: (VIRTIO_PCI && VIRTIO_MMIO && REMOTEPROC && RPMSG) selects VIRTIO which has unmet direct dependencies (VIRTUALIZATION)
- '[' -s .newoptions ']'
- cat .newoptions
CONFIG_ARCH_MULTI_V6 CONFIG_ARCH_MULTI_V7 CONFIG_ARCH_MVEBU CONFIG_ARCH_BCM CONFIG_ARCH_HIGHBANK CONFIG_ARCH_MXC CONFIG_ARCH_OMAP2PLUS CONFIG_ARCH_SOCFPGA CONFIG_PLAT_SPEAR CONFIG_ARCH_SUNXI CONFIG_ARCH_SIRF CONFIG_ARCH_U8500 CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA CONFIG_ARCH_VEXPRESS_CA9X4 CONFIG_ARCH_VIRT CONFIG_ARCH_WM8850 CONFIG_ARCH_ZYNQ
- exit 1
error: Bad exit status from /var/tmp/rpm-tmp.JpdsWj (%prep)
Now, looking at the various ARM config files, almost all of those are set in config-armv7. None of them are set in config-armv7-generic or config-armv7-tegra. The questions I have are:
- What is config-armv7 and why is it different from
config-armv7-generic?
It's non pae vs pae. I did it the same as x86.
- Why does tegra (and the other boards) not inherit config-armv7 at all
and only inherits from temp-armv7-generic (config-armv7-generic + config-generic)?
Because generic is inherited by the other 3.
As it stands right now, either config-armv7-generic needs to inherit all the settings from config-armv7 or they need to be explicitly set in config-armv7-tegra. Explicitly setting them is feasible, but that's a lot of duplication. I've no clue what the setup here is, nor which option is correct.
Tegra will disappear with 3.10 (at least that's the plans) and the other two are different because they need to be. armv7-generic is the shared bits between the two.
Can you please tell me which to do so I can continue with this merge? I'd like to get -git12 fixed up and pushed out today.
If you can push the changes you have I can fix the issues now.
Peter
On Thu, May 02, 2013 at 06:49:00PM +0100, Peter Robinson wrote:
On Thu, May 2, 2013 at 6:43 PM, Josh Boyer jwboyer@redhat.com wrote:
So. When trying to do the latest merge, this is what I get on a prep for the -tegra config:
- mv kernel-3.10.0-armv7hl-tegra.config .config
++ head -1 .config ++ cut -b 3-
- Arch=arm
- make ARCH=arm listnewconfig
- grep -E '^CONFIG_'
warning: (VIRTIO_PCI && VIRTIO_MMIO && REMOTEPROC && RPMSG) selects VIRTIO which has unmet direct dependencies (VIRTUALIZATION)
- '[' -s .newoptions ']'
- cat .newoptions
CONFIG_ARCH_MULTI_V6 CONFIG_ARCH_MULTI_V7 CONFIG_ARCH_MVEBU CONFIG_ARCH_BCM CONFIG_ARCH_HIGHBANK CONFIG_ARCH_MXC CONFIG_ARCH_OMAP2PLUS CONFIG_ARCH_SOCFPGA CONFIG_PLAT_SPEAR CONFIG_ARCH_SUNXI CONFIG_ARCH_SIRF CONFIG_ARCH_U8500 CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA CONFIG_ARCH_VEXPRESS_CA9X4 CONFIG_ARCH_VIRT CONFIG_ARCH_WM8850 CONFIG_ARCH_ZYNQ
- exit 1
error: Bad exit status from /var/tmp/rpm-tmp.JpdsWj (%prep)
Now, looking at the various ARM config files, almost all of those are set in config-armv7. None of them are set in config-armv7-generic or config-armv7-tegra. The questions I have are:
- What is config-armv7 and why is it different from
config-armv7-generic?
It's non pae vs pae. I did it the same as x86.
Er... similar I guess. Not the same. x86 has "PAE" in the PAE config :). You do have a config-armv7-lpae, but that is inheriting from config-armv7-generic.
- Why does tegra (and the other boards) not inherit config-armv7 at all
and only inherits from temp-armv7-generic (config-armv7-generic + config-generic)?
Because generic is inherited by the other 3.
What other 3? There's only 3 kernels total right now: armv7hl (config-armv7), armv7hl-lpae (config-armv7-generic), and tegra (config-armv7-generic but not any of the lpae configs).
As it stands right now, either config-armv7-generic needs to inherit all the settings from config-armv7 or they need to be explicitly set in config-armv7-tegra. Explicitly setting them is feasible, but that's a lot of duplication. I've no clue what the setup here is, nor which option is correct.
Tegra will disappear with 3.10 (at least that's the plans) and the other two are different because they need to be. armv7-generic is the shared bits between the two.
Oh. Good.
Can you please tell me which to do so I can continue with this merge? I'd like to get -git12 fixed up and pushed out today.
If you can push the changes you have I can fix the issues now.
I would feel extremely bad if I pushed something to git that didn't even pass 'make prep'. As a compromise, I added this line in kernel.spec:
@@ -1451,6 +1451,8 @@ mkdir configs rm -f kernel-%{version}-*debug.config %endif
+rm -f kernel-%{version}-arm*.config + # now run oldconfig over all the config files
So the ARM configs won't be included in the prep run. That lets things progress on all the other arches for now. Just remove that line, fix things up, and push out.
I'll hold off on doing the build for a bit. Thanks for the quick reply.
josh
On Thu, May 02, 2013 at 02:02:12PM -0400, Josh Boyer wrote:
I would feel extremely bad if I pushed something to git that didn't even pass 'make prep'. As a compromise, I added this line in kernel.spec:
@@ -1451,6 +1451,8 @@ mkdir configs rm -f kernel-%{version}-*debug.config %endif
+rm -f kernel-%{version}-arm*.config
# now run oldconfig over all the config files
So the ARM configs won't be included in the prep run. That lets things progress on all the other arches for now. Just remove that line, fix things up, and push out.
FYI, I've just done the same thing in f18 during the 3.9 rebase. I don't see us pushing this out until 3.9.1 lands, but please sort out the config options there too.
Dave
On Mon, May 6, 2013 at 9:07 PM, Dave Jones davej@redhat.com wrote:
On Thu, May 02, 2013 at 02:02:12PM -0400, Josh Boyer wrote:
I would feel extremely bad if I pushed something to git that didn't even pass 'make prep'. As a compromise, I added this line in kernel.spec:
@@ -1451,6 +1451,8 @@ mkdir configs rm -f kernel-%{version}-*debug.config %endif
+rm -f kernel-%{version}-arm*.config
# now run oldconfig over all the config files
So the ARM configs won't be included in the prep run. That lets things progress on all the other arches for now. Just remove that line, fix things up, and push out.
FYI, I've just done the same thing in f18 during the 3.9 rebase. I don't see us pushing this out until 3.9.1 lands, but please sort out the config options there too.
Thanks, I'll look at it now, for <= F-18 we still support v5tel so I need to deal with that.
Any idea on eta for 3.9.1?
Peter
On Mon, May 06, 2013 at 09:13:30PM +0100, Peter Robinson wrote:
On Mon, May 6, 2013 at 9:07 PM, Dave Jones davej@redhat.com wrote:
On Thu, May 02, 2013 at 02:02:12PM -0400, Josh Boyer wrote:
I would feel extremely bad if I pushed something to git that didn't even pass 'make prep'. As a compromise, I added this line in kernel.spec:
@@ -1451,6 +1451,8 @@ mkdir configs rm -f kernel-%{version}-*debug.config %endif
+rm -f kernel-%{version}-arm*.config
# now run oldconfig over all the config files
So the ARM configs won't be included in the prep run. That lets things progress on all the other arches for now. Just remove that line, fix things up, and push out.
FYI, I've just done the same thing in f18 during the 3.9 rebase. I don't see us pushing this out until 3.9.1 lands, but please sort out the config options there too.
Thanks, I'll look at it now, for <= F-18 we still support v5tel so I need to deal with that.
Any idea on eta for 3.9.1?
Probably sometime this week I would guess. There's already over a hundred patches queued on Linux-stable for 3.9
Greg typically seems to wait until Linus tags rc1, so whenever the merge window closes, you can probably expect 3.9.1 to land pretty soon afterwards.
Dave
On Mon, May 6, 2013 at 4:26 PM, Dave Jones davej@redhat.com wrote:
On Mon, May 06, 2013 at 09:13:30PM +0100, Peter Robinson wrote:
On Mon, May 6, 2013 at 9:07 PM, Dave Jones davej@redhat.com wrote:
On Thu, May 02, 2013 at 02:02:12PM -0400, Josh Boyer wrote:
I would feel extremely bad if I pushed something to git that didn't even pass 'make prep'. As a compromise, I added this line in kernel.spec:
@@ -1451,6 +1451,8 @@ mkdir configs rm -f kernel-%{version}-*debug.config %endif
+rm -f kernel-%{version}-arm*.config
# now run oldconfig over all the config files
So the ARM configs won't be included in the prep run. That lets things progress on all the other arches for now. Just remove that line, fix things up, and push out.
FYI, I've just done the same thing in f18 during the 3.9 rebase. I don't see us pushing this out until 3.9.1 lands, but please sort out the config options there too.
Thanks, I'll look at it now, for <= F-18 we still support v5tel so I need to deal with that.
Any idea on eta for 3.9.1?
Probably sometime this week I would guess. There's already over a hundred patches queued on Linux-stable for 3.9
Greg typically seems to wait until Linus tags rc1, so whenever the merge window closes, you can probably expect 3.9.1 to land pretty soon afterwards.
I'm kinda hesitant on that plan. We seem to always pull in some patches from -rc1 that wind up being broken and fixed with a later RC, or reverted outright. Of course, there isn't a great answer there but maybe we can bump the karma requirement up when the update is filed?
josh
On Mon, May 06, 2013 at 04:38:43PM -0400, Josh Boyer wrote:
On Mon, May 6, 2013 at 4:26 PM, Dave Jones davej@redhat.com wrote:
FYI, I've just done the same thing in f18 during the 3.9 rebase. I don't see us pushing this out until 3.9.1 lands, but please sort out the config options there too.
Thanks, I'll look at it now, for <= F-18 we still support v5tel so I need to deal with that.
Any idea on eta for 3.9.1?
Probably sometime this week I would guess. There's already over a hundred patches queued on Linux-stable for 3.9
Greg typically seems to wait until Linus tags rc1, so whenever the merge window closes, you can probably expect 3.9.1 to land pretty soon afterwards.
I'm kinda hesitant on that plan. We seem to always pull in some patches from -rc1 that wind up being broken and fixed with a later RC, or reverted outright. Of course, there isn't a great answer there but maybe we can bump the karma requirement up when the update is filed?
Works for me. For 17 we can delay a little longer too (at least while 3.8.x updates are still going out) if we want to be extra safe, and rebase once we get to 3.9.2 or 3.9.3
Dave
On Mon, May 06, 2013 at 04:26:52PM -0400, Dave Jones wrote:
On Mon, May 06, 2013 at 09:13:30PM +0100, Peter Robinson wrote:
On Mon, May 6, 2013 at 9:07 PM, Dave Jones davej@redhat.com wrote:
On Thu, May 02, 2013 at 02:02:12PM -0400, Josh Boyer wrote:
I would feel extremely bad if I pushed something to git that didn't even pass 'make prep'. As a compromise, I added this line in kernel.spec:
@@ -1451,6 +1451,8 @@ mkdir configs rm -f kernel-%{version}-*debug.config %endif
+rm -f kernel-%{version}-arm*.config
# now run oldconfig over all the config files
So the ARM configs won't be included in the prep run. That lets things progress on all the other arches for now. Just remove that line, fix things up, and push out.
FYI, I've just done the same thing in f18 during the 3.9 rebase. I don't see us pushing this out until 3.9.1 lands, but please sort out the config options there too.
Thanks, I'll look at it now, for <= F-18 we still support v5tel so I need to deal with that.
Any idea on eta for 3.9.1?
Probably sometime this week I would guess. There's already over a hundred patches queued on Linux-stable for 3.9
Greg typically seems to wait until Linus tags rc1, so whenever the merge window closes, you can probably expect 3.9.1 to land pretty soon afterwards.
And just after I posted that he posted 3.9.1-rc1 with the comment..
"Responses should be made by Wed May 8 20:28:24 UTC 2013."
I'll roll the rc1 into git after dinner to get some testing, but I won't be pushing out an update until later in the week.
Dave
On Mon, May 6, 2013 at 10:07 PM, Dave Jones davej@redhat.com wrote:
On Mon, May 06, 2013 at 04:26:52PM -0400, Dave Jones wrote:
On Mon, May 06, 2013 at 09:13:30PM +0100, Peter Robinson wrote:
On Mon, May 6, 2013 at 9:07 PM, Dave Jones davej@redhat.com wrote:
On Thu, May 02, 2013 at 02:02:12PM -0400, Josh Boyer wrote:
I would feel extremely bad if I pushed something to git that didn't even pass 'make prep'. As a compromise, I added this line in kernel.spec:
@@ -1451,6 +1451,8 @@ mkdir configs rm -f kernel-%{version}-*debug.config %endif
+rm -f kernel-%{version}-arm*.config
# now run oldconfig over all the config files
So the ARM configs won't be included in the prep run. That lets things progress on all the other arches for now. Just remove that line, fix things up, and push out.
FYI, I've just done the same thing in f18 during the 3.9 rebase. I don't see us pushing this out until 3.9.1 lands, but please sort out the config options there too.
Thanks, I'll look at it now, for <= F-18 we still support v5tel so I need to deal with that.
Any idea on eta for 3.9.1?
Probably sometime this week I would guess. There's already over a hundred patches queued on Linux-stable for 3.9
Greg typically seems to wait until Linus tags rc1, so whenever the merge window closes, you can probably expect 3.9.1 to land pretty soon afterwards.
And just after I posted that he posted 3.9.1-rc1 with the comment..
"Responses should be made by Wed May 8 20:28:24 UTC 2013."
I'll roll the rc1 into git after dinner to get some testing, but I won't be pushing out an update until later in the week.
I've pushed the 3.9 ARM config changes to the F-18 branch, it passes make prep and the allarchconfig.sh config script, I'll do a scratch build but that should stop ARM from blocking the rebase. Thanks
Peter
On Tue, 2013-05-07 at 00:37 +0100, Peter Robinson wrote:
On Mon, May 6, 2013 at 10:07 PM, Dave Jones davej@redhat.com wrote:
On Mon, May 06, 2013 at 04:26:52PM -0400, Dave Jones wrote:
On Mon, May 06, 2013 at 09:13:30PM +0100, Peter Robinson wrote:
On Mon, May 6, 2013 at 9:07 PM, Dave Jones davej@redhat.com wrote:
On Thu, May 02, 2013 at 02:02:12PM -0400, Josh Boyer wrote:
I would feel extremely bad if I pushed something to git that didn't even pass 'make prep'. As a compromise, I added this line in kernel.spec:
@@ -1451,6 +1451,8 @@ mkdir configs rm -f kernel-%{version}-*debug.config %endif
+rm -f kernel-%{version}-arm*.config
# now run oldconfig over all the config files
So the ARM configs won't be included in the prep run. That lets things progress on all the other arches for now. Just remove that line, fix things up, and push out.
FYI, I've just done the same thing in f18 during the 3.9 rebase. I don't see us pushing this out until 3.9.1 lands, but please sort out the config options there too.
Thanks, I'll look at it now, for <= F-18 we still support v5tel so I need to deal with that.
Any idea on eta for 3.9.1?
Probably sometime this week I would guess. There's already over a hundred patches queued on Linux-stable for 3.9
Greg typically seems to wait until Linus tags rc1, so whenever the merge window closes, you can probably expect 3.9.1 to land pretty soon afterwards.
And just after I posted that he posted 3.9.1-rc1 with the comment..
"Responses should be made by Wed May 8 20:28:24 UTC 2013."
I'll roll the rc1 into git after dinner to get some testing, but I won't be pushing out an update until later in the week.
I've pushed the 3.9 ARM config changes to the F-18 branch, it passes make prep and the allarchconfig.sh config script, I'll do a scratch build but that should stop ARM from blocking the rebase. Thanks
Will F17 need the same, or something different?
Justin
On Tue, May 7, 2013 at 1:22 AM, Justin M. Forbes jforbes@redhat.com wrote:
On Tue, 2013-05-07 at 00:37 +0100, Peter Robinson wrote:
On Mon, May 6, 2013 at 10:07 PM, Dave Jones davej@redhat.com wrote:
On Mon, May 06, 2013 at 04:26:52PM -0400, Dave Jones wrote:
On Mon, May 06, 2013 at 09:13:30PM +0100, Peter Robinson wrote:
On Mon, May 6, 2013 at 9:07 PM, Dave Jones davej@redhat.com wrote:
On Thu, May 02, 2013 at 02:02:12PM -0400, Josh Boyer wrote: > I would feel extremely bad if I pushed something to git that didn't even > pass 'make prep'. As a compromise, I added this line in kernel.spec: > > @@ -1451,6 +1451,8 @@ mkdir configs > rm -f kernel-%{version}-*debug.config > %endif > > +rm -f kernel-%{version}-arm*.config > + > # now run oldconfig over all the config files > > So the ARM configs won't be included in the prep run. That lets things > progress on all the other arches for now. Just remove that line, fix > things up, and push out.
FYI, I've just done the same thing in f18 during the 3.9 rebase. I don't see us pushing this out until 3.9.1 lands, but please sort out the config options there too.
Thanks, I'll look at it now, for <= F-18 we still support v5tel so I need to deal with that.
Any idea on eta for 3.9.1?
Probably sometime this week I would guess. There's already over a hundred patches queued on Linux-stable for 3.9
Greg typically seems to wait until Linus tags rc1, so whenever the merge window closes, you can probably expect 3.9.1 to land pretty soon afterwards.
And just after I posted that he posted 3.9.1-rc1 with the comment..
"Responses should be made by Wed May 8 20:28:24 UTC 2013."
I'll roll the rc1 into git after dinner to get some testing, but I won't be pushing out an update until later in the week.
I've pushed the 3.9 ARM config changes to the F-18 branch, it passes make prep and the allarchconfig.sh config script, I'll do a scratch build but that should stop ARM from blocking the rebase. Thanks
Will F17 need the same, or something different?
The same, but I forgot that 3.9 needed a few patches and of course I managed to miss the 3.9.1 push by mere moments.
Peter
On Wed, May 8, 2013 at 5:33 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, May 7, 2013 at 1:22 AM, Justin M. Forbes jforbes@redhat.com wrote:
On Tue, 2013-05-07 at 00:37 +0100, Peter Robinson wrote:
On Mon, May 6, 2013 at 10:07 PM, Dave Jones davej@redhat.com wrote:
On Mon, May 06, 2013 at 04:26:52PM -0400, Dave Jones wrote:
On Mon, May 06, 2013 at 09:13:30PM +0100, Peter Robinson wrote:
On Mon, May 6, 2013 at 9:07 PM, Dave Jones davej@redhat.com wrote: > On Thu, May 02, 2013 at 02:02:12PM -0400, Josh Boyer wrote: > > I would feel extremely bad if I pushed something to git that didn't even > > pass 'make prep'. As a compromise, I added this line in kernel.spec: > > > > @@ -1451,6 +1451,8 @@ mkdir configs > > rm -f kernel-%{version}-*debug.config > > %endif > > > > +rm -f kernel-%{version}-arm*.config > > + > > # now run oldconfig over all the config files > > > > So the ARM configs won't be included in the prep run. That lets things > > progress on all the other arches for now. Just remove that line, fix > > things up, and push out. > > FYI, I've just done the same thing in f18 during the 3.9 rebase. > I don't see us pushing this out until 3.9.1 lands, but please sort out the > config options there too.
Thanks, I'll look at it now, for <= F-18 we still support v5tel so I need to deal with that.
Any idea on eta for 3.9.1?
Probably sometime this week I would guess. There's already over a hundred patches queued on Linux-stable for 3.9
Greg typically seems to wait until Linus tags rc1, so whenever the merge window closes, you can probably expect 3.9.1 to land pretty soon afterwards.
And just after I posted that he posted 3.9.1-rc1 with the comment..
"Responses should be made by Wed May 8 20:28:24 UTC 2013."
I'll roll the rc1 into git after dinner to get some testing, but I won't be pushing out an update until later in the week.
I've pushed the 3.9 ARM config changes to the F-18 branch, it passes make prep and the allarchconfig.sh config script, I'll do a scratch build but that should stop ARM from blocking the rebase. Thanks
Will F17 need the same, or something different?
The same, but I forgot that 3.9 needed a few patches and of course I managed to miss the 3.9.1 push by mere moments.
I'm happy to help push those if you like, but there's some config file name changes due to OMAP being supported as part of the multiplatform kernel as well as matching Makefile.config plus the patches.
Peter
kernel@lists.fedoraproject.org
-
Dave Jones -
Josh Boyer -
Josh Boyer -
Justin Forbes -
Peter Robinson