[opensuse-kernel] Use fragment configs for -debug and i386/default?
Hi, some time ago, we switched the vanilla configs and subsequenly a few other special flavors to only contain the diff agains the -default kernel. I think it's a good idea to finish this conversion and only have a single base config per architecture. After doing sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default scripts/sequence-patch.sh --fast cd tmp/current ./run_oldconfig.sh I get this $ wc -l config/*/* 15 config/arm64/64kb 8480 config/arm64/default 4 config/arm64/vanilla 6846 config/armv6hl/default 3 config/armv6hl/vanilla 9160 config/armv7hl/default 8795 config/armv7hl/lpae 3 config/armv7hl/vanilla 216 config/i386/debug 341 config/i386/default 8332 config/i386/pae 6 config/i386/vanilla 48 config/ppc64/debug 6804 config/ppc64/default 3 config/ppc64/vanilla 46 config/ppc64le/debug 6654 config/ppc64le/default 3 config/ppc64le/vanilla 3366 config/s390x/default 3 config/s390x/vanilla 77 config/x86_64/debug 8363 config/x86_64/default 43 config/x86_64/syzkaller 6 config/x86_64/vanilla 67617 total config/armv7hl/lpae is still not converted, because armv6 and armv7 are currently disabled. config/i386/debug is larger than the other debug flavors, because it enables some drivers that pae does not (e.g. CONFIG_ISA). Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 07 Apr 2017 10:38:21 +0200, Michal Marek wrote:
Hi,
some time ago, we switched the vanilla configs and subsequenly a few other special flavors to only contain the diff agains the -default kernel. I think it's a good idea to finish this conversion and only have a single base config per architecture. After doing
sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default scripts/sequence-patch.sh --fast cd tmp/current ./run_oldconfig.sh
I get this
$ wc -l config/*/* 15 config/arm64/64kb 8480 config/arm64/default 4 config/arm64/vanilla 6846 config/armv6hl/default 3 config/armv6hl/vanilla 9160 config/armv7hl/default 8795 config/armv7hl/lpae 3 config/armv7hl/vanilla 216 config/i386/debug 341 config/i386/default 8332 config/i386/pae 6 config/i386/vanilla 48 config/ppc64/debug 6804 config/ppc64/default 3 config/ppc64/vanilla 46 config/ppc64le/debug 6654 config/ppc64le/default 3 config/ppc64le/vanilla 3366 config/s390x/default 3 config/s390x/vanilla 77 config/x86_64/debug 8363 config/x86_64/default 43 config/x86_64/syzkaller 6 config/x86_64/vanilla 67617 total
config/armv7hl/lpae is still not converted, because armv6 and armv7 are currently disabled. config/i386/debug is larger than the other debug flavors, because it enables some drivers that pae does not (e.g. CONFIG_ISA).
This looks promising, thanks for doing this! I had the same idea, but you stepped in more quickly :) Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Dne 8.4.2017 v 11:31 Takashi Iwai napsal(a):
On Fri, 07 Apr 2017 10:38:21 +0200, Michal Marek wrote:
Hi,
some time ago, we switched the vanilla configs and subsequenly a few other special flavors to only contain the diff agains the -default kernel. I think it's a good idea to finish this conversion and only have a single base config per architecture. After doing
sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default scripts/sequence-patch.sh --fast cd tmp/current ./run_oldconfig.sh
I get this
$ wc -l config/*/* 15 config/arm64/64kb 8480 config/arm64/default 4 config/arm64/vanilla 6846 config/armv6hl/default 3 config/armv6hl/vanilla 9160 config/armv7hl/default 8795 config/armv7hl/lpae 3 config/armv7hl/vanilla 216 config/i386/debug 341 config/i386/default 8332 config/i386/pae 6 config/i386/vanilla 48 config/ppc64/debug 6804 config/ppc64/default 3 config/ppc64/vanilla 46 config/ppc64le/debug 6654 config/ppc64le/default 3 config/ppc64le/vanilla 3366 config/s390x/default 3 config/s390x/vanilla 77 config/x86_64/debug 8363 config/x86_64/default 43 config/x86_64/syzkaller 6 config/x86_64/vanilla 67617 total
config/armv7hl/lpae is still not converted, because armv6 and armv7 are currently disabled. config/i386/debug is larger than the other debug flavors, because it enables some drivers that pae does not (e.g. CONFIG_ISA).
This looks promising, thanks for doing this! I had the same idea, but you stepped in more quickly :)
OK, pushed. The change required a fix for scripts/config-diff to handle the lowercase 'x' in CONFIG_CS89x0_PLATFORM. Now config/{x86_64,i386}/debug are identical and 77 lines long. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On sam., 2017-04-08 at 12:38 +0200, Michal Marek wrote:
Dne 8.4.2017 v 11:31 Takashi Iwai napsal(a):
On Fri, 07 Apr 2017 10:38:21 +0200, Michal Marek wrote:
Hi,
some time ago, we switched the vanilla configs and subsequenly a few other special flavors to only contain the diff agains the -default kernel. I think it's a good idea to finish this conversion and only have a single base config per architecture. After doing
sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default scripts/sequence-patch.sh --fast cd tmp/current ./run_oldconfig.sh
I get this
$ wc -l config/*/* 15 config/arm64/64kb 8480 config/arm64/default 4 config/arm64/vanilla 6846 config/armv6hl/default 3 config/armv6hl/vanilla 9160 config/armv7hl/default 8795 config/armv7hl/lpae 3 config/armv7hl/vanilla 216 config/i386/debug 341 config/i386/default 8332 config/i386/pae 6 config/i386/vanilla 48 config/ppc64/debug 6804 config/ppc64/default 3 config/ppc64/vanilla 46 config/ppc64le/debug 6654 config/ppc64le/default 3 config/ppc64le/vanilla 3366 config/s390x/default 3 config/s390x/vanilla 77 config/x86_64/debug 8363 config/x86_64/default 43 config/x86_64/syzkaller 6 config/x86_64/vanilla 67617 total
config/armv7hl/lpae is still not converted, because armv6 and armv7 are currently disabled. config/i386/debug is larger than the other debug flavors, because it enables some drivers that pae does not (e.g. CONFIG_ISA).
This looks promising, thanks for doing this! I had the same idea, but you stepped in more quickly :)
OK, pushed. The change required a fix for scripts/config-diff to handle the lowercase 'x' in CONFIG_CS89x0_PLATFORM. Now config/{x86_64,i386}/debug are identical and 77 lines long.
This is an excellent idea, thanks Michal for making it happen :-) -- Jean Delvare SUSE L3 Support -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi Michal, Am 07.04.2017 um 10:38 schrieb Michal Marek:
some time ago, we switched the vanilla configs and subsequenly a few other special flavors to only contain the diff agains the -default kernel. I think it's a good idea to finish this conversion and only have a single base config per architecture. After doing
sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default scripts/sequence-patch.sh --fast cd tmp/current ./run_oldconfig.sh
I get this
$ wc -l config/*/* [...] 9160 config/armv7hl/default 8795 config/armv7hl/lpae 3 config/armv7hl/vanilla [...] 67617 total
config/armv7hl/lpae is still not converted, because armv6 and armv7 are currently disabled.
"still not converted"??? It's not like we ever discussed a conversion! (Did you maybe mean s/still not/not yet/?) On the contrary, I already explained the default vs. lpae issue to you back when integrating dtb-armv7l into kernel packaging. How do you expect I maintain the lpae config as a fragment? By hand?! Saying "m" a few times more seems way easier to me. lpae is highly different from the 64kb flavor that just tweaks one or two options - the size difference above should make that obvious: The lpae flavor excludes support for old Cortex-A8/-A9/-A5 based platforms and enables a few platforms that depend on LPAE (e.g., LSI Axxia) as well as features that depend on LPAE (e.g., KVM). So please understand that the lpae flavor is not just the equivalent to pae flavor on i386, despite similar naming! vanilla is already a fragment config, based on default. Being based on default means we have no linux-next config for LPAE. So far no one has asked for one. I would claim that the lpae flavor is more important than default, because it supports the newer-generation hardware. So if you absolutely must force fragments onto us (which so far mostly affects myself and the CC'ed contributors, since during my recent absences your ARM engineers didn't even help update arm64!), I would much rather run oldconfig for lpae as a real config and risk having a default fragment break than the other way around. Switching the naming would cause problems for our JeOS images and cause even more confusion for users. Finally, on the topic of updating ARM configs, I am still annoyed about the new merge process: As someone not working on ARM kernels for his job, I need the weekend for testing new kernels on my boards at home. Previously I could commit ARM config changes to master branch myself on Friday, get them transferred to OBS Kernel:HEAD via your cron job on Saturday morning and when back home in the evening (or on Sunday) I could start testing the new packages. These days, despite my IRC pings, Jeff merges pending branches I push only after his next -rc update on Mondays, which then usually delays my testing until the next weekend. Also we don't seem to have any process in place that would notify me or let me review any ARM config changes from others, unless they're posted here as a patch, such as Stefan's that I just noticed. The new process simply doesn't work well for delegation of ARM configs to people outside your branch maintainers, i.e. no sub-maintainer model. In summary, there are delays getting updated configs submitted to your team by myself or community members, and then there are delays getting the submitted config updates merged by your team and thereby into OBS. During that timespan there are no kernels available from Kernel:HEAD ARM repo - Andreas Schwab had complained about that before, to no effect. https://build.opensuse.org/package/binaries/Kernel:HEAD/kernel-default?repos... (Currently this only shows aarch64 binaries, no armv6l or armv7l.) And I doubt you added any checks to stop yourselves from submitting a kernel with non-updated ARM configs to Kernel:stable, should it not get done within sufficient weeks. We had that happen for armv6l before I stepped in, I recall. Why are no alarm bells raised when, say, -rc3 still has "-!needs_updating"? Should be easy to grep for. So the kernel team clearly does not care about the master ARM configs (I was told to monitor an internal-only mailing list to get notified about -rc1 updates disabling the configs, for external contributors that still requires to poll the Git repository - no emails to opensuse-kernel or opensuse-arm for instance), and now you propose yet another change that seems to make the ARM updating process even harder for those that do care. Thank you very much... also for not CC'ing at least me on this proposal/complaint. Subject said nothing about ARM, and we don't have any -debug flavor there, so it would seem rather unrelated. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Dne 8.4.2017 v 21:59 Andreas Färber napsal(a):
Hi Michal,
Am 07.04.2017 um 10:38 schrieb Michal Marek:
some time ago, we switched the vanilla configs and subsequenly a few other special flavors to only contain the diff agains the -default kernel. I think it's a good idea to finish this conversion and only have a single base config per architecture. After doing
sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default scripts/sequence-patch.sh --fast cd tmp/current ./run_oldconfig.sh
I get this
$ wc -l config/*/* [...] 9160 config/armv7hl/default 8795 config/armv7hl/lpae 3 config/armv7hl/vanilla [...] 67617 total
config/armv7hl/lpae is still not converted, because armv6 and armv7 are currently disabled.
"still not converted"??? It's not like we ever discussed a conversion! (Did you maybe mean s/still not/not yet/?) On the contrary, I already explained the default vs. lpae issue to you back when integrating dtb-armv7l into kernel packaging.
I meant to simply say "lpae is not converted."
How do you expect I maintain the lpae config as a fragment? By hand?! Saying "m" a few times more seems way easier to me.
In that case, just continue maintaining it this way.
vanilla is already a fragment config, based on default. Being based on default means we have no linux-next config for LPAE. So far no one has asked for one.
I would claim that the lpae flavor is more important than default, because it supports the newer-generation hardware. So if you absolutely must force fragments onto us (which so far mostly affects myself and the
I'm not forcing this model on anyone. I think it's a good idea to do it for -debug, because the diff to default is minimal. i386/default is also largely similar it i386/pae. Let's see how it will work in practice. Regarding linux-next for lpae, it can be done. It just needs to be switched in 4 different places, so please let me know upfront.
Finally, on the topic of updating ARM configs, I am still annoyed about the new merge process: As someone not working on ARM kernels for his job, I need the weekend for testing new kernels on my boards at home. Previously I could commit ARM config changes to master branch myself on Friday, get them transferred to OBS Kernel:HEAD via your cron job on Saturday morning and when back home in the evening (or on Sunday) I could start testing the new packages. These days, despite my IRC pings, Jeff merges pending branches I push only after his next -rc update on Mondays, which then usually delays my testing until the next weekend.
Do you only test packages, or images built with the Kernel:HEAD packages? If it's the former, then simply do scripts/tar-up.sh && scripts/osc_wrapper upload home:a_faerber:... and have the packages built in your home project while waiting for Jeff to merge your changes.
Also we don't seem to have any process in place that would notify me or let me review any ARM config changes from others, unless they're posted here as a patch, such as Stefan's that I just noticed. The new process simply doesn't work well for delegation of ARM configs to people outside your branch maintainers, i.e. no sub-maintainer model.
There is no sub-maintainer model and to be honest, I do not think we have a scalability problem to require a formal solution like this. Having multiple maintainers per branch with a verbal agreement about the areas of responsibility should work as well, shouldn't it? I can't speak for Jeff, of course. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 08.04.2017 um 23:55 schrieb Michal Marek:
Dne 8.4.2017 v 21:59 Andreas Färber napsal(a):
Hi Michal,
Am 07.04.2017 um 10:38 schrieb Michal Marek:
some time ago, we switched the vanilla configs and subsequenly a few other special flavors to only contain the diff agains the -default kernel. I think it's a good idea to finish this conversion and only have a single base config per architecture. After doing
sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default scripts/sequence-patch.sh --fast cd tmp/current ./run_oldconfig.sh
I get this
$ wc -l config/*/* [...] 9160 config/armv7hl/default 8795 config/armv7hl/lpae 3 config/armv7hl/vanilla [...] 67617 total
config/armv7hl/lpae is still not converted, because armv6 and armv7 are currently disabled.
"still not converted"??? It's not like we ever discussed a conversion! (Did you maybe mean s/still not/not yet/?) On the contrary, I already explained the default vs. lpae issue to you back when integrating dtb-armv7l into kernel packaging.
I meant to simply say "lpae is not converted."
Okay, it sounded very pushy to me before.
vanilla is already a fragment config, based on default. Being based on default means we have no linux-next config for LPAE. So far no one has asked for one.
I would claim that the lpae flavor is more important than default, because it supports the newer-generation hardware. So if you absolutely must force fragments onto us (which so far mostly affects myself and the
I'm not forcing this model on anyone. I think it's a good idea to do it for -debug, because the diff to default is minimal. i386/default is also largely similar it i386/pae. Let's see how it will work in practice.
Don't get me wrong, I am commenting solely on lpae here. vanilla and 64kb being fragments is a very helpful feature, thank you very much! Having lpae not be a fragment obviously contradicts your "only have a single base config per architecture" paradigm, which sounded like you wanted to enforce that in your scripts.
Regarding linux-next for lpae, it can be done. It just needs to be switched in 4 different places, so please let me know upfront.
Thanks for that offer. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am 08.04.2017 um 23:55 schrieb Michal Marek:
Dne 8.4.2017 v 21:59 Andreas Färber napsal(a):
config/armv7hl/lpae is [...] not converted, because armv6 and armv7 are currently disabled. [...] Finally, on the topic of updating ARM configs, I am still annoyed about
Am 07.04.2017 um 10:38 schrieb Michal Marek: the new merge process: As someone not working on ARM kernels for his job, I need the weekend for testing new kernels on my boards at home. Previously I could commit ARM config changes to master branch myself on Friday, get them transferred to OBS Kernel:HEAD via your cron job on Saturday morning and when back home in the evening (or on Sunday) I could start testing the new packages. These days, despite my IRC pings, Jeff merges pending branches I push only after his next -rc update on Mondays, which then usually delays my testing until the next weekend.
Do you only test packages, or images built with the Kernel:HEAD packages?
Both. Packages on boards that already run openSUSE, and a few branched JeOS images that build against Kernel:HEAD for unfinished boards. We also have a public devel:ARM:Factory:Contrib:HEAD project building against Kernel:HEAD. (Apart from JeOS-efi image, other images were usually temporary there, favoring manual addition of Kernel:HEAD for build power reasons.)
If it's the former, then simply do
scripts/tar-up.sh && scripts/osc_wrapper upload home:a_faerber:...
and have the packages built in your home project while waiting for Jeff to merge your changes.
Thanks for that tip! That was much faster than trying to build locally in tmp/current/ (takes all weekend), and OBS makes installation easier.
Also we don't seem to have any process in place that would notify me or let me review any ARM config changes from others, unless they're posted here as a patch, such as Stefan's that I just noticed. The new process simply doesn't work well for delegation of ARM configs to people outside your branch maintainers, i.e. no sub-maintainer model.
There is no sub-maintainer model and to be honest, I do not think we have a scalability problem to require a formal solution like this. Having multiple maintainers per branch with a verbal agreement about the areas of responsibility should work as well, shouldn't it? I can't speak for Jeff, of course.
I'm not worried about scalability, just about review and coordination. Unlike the upstream kernel workflow with scripts/get_maintainer.pl CC'ing sub-maintainers about certain changes, I don't get notified if anyone else touches config/arm*/*. Takashi, Jean and others doing cross-architecture cleanups have been so kind to ask on this list first before performing config changes. However if someone were to push a for-next branch with updated ARM configs in my absence, I wouldn't get any automatic email, because the "... is ready to be merged" mails only go to Jeff (and an internal list with quite some traffic), and there is no diffstat or other indication (apart from voluntary commit message conventions for ARM-only changes) to indicate that it is something for me to be aware of. With help from Jeff I've managed to set up email filters so that I now see when -rc1 has arrived in master. But by the time I get such update notifications it would be too late to object to any particular ARM-side change, only reverts or fix-ups would be possible at that point - for example, Dirk once simply disabled all Renesas options without any discussion or notification - thus it remained that way. (And as seen, email filters don't guarantee I read it immediately or can react to it when on travels - thanks to Stefan who ping'ed me on IRC.) kernel.opensuse.org only shows merged commits, not pending branches, so Matwey didn't see either when I had partial updates queued already and spent time on patches at some point. Master branch shouldn't contain any embargoed patches, so making branch existence or contents visible externally would seem thinkable. Wouldn't it be possible to extend your branch-checking scripts to address these issues in some form or another? Also, nobody seemed to notice that a while ago there was a dtb packaging pull request on GitHub - I only learned via pings on #opensuse-arm (after I had declined an SR against the old dtb-source). So it seems that each branch maintainer/reviewer needs to set the GitHub "watch" settings for that repository to get notified of pulls that affect them? No automatic mirroring from GitHub into SUSE, no kbuild notifications? Overall it just feels like the assumption still is that everything is handled by the SUSE kernel team, with little provisions for the openSUSE community to participate, myself being somewhere in between. Patches on opensuse-kernel have been working best so far, so should I simply integrate some git-send-email --to=opensuse-kernel@opensuse.org or maybe better opensuse-arm@opensuse.org into my git-push scripts, to lead by example? Absence of emails would then likely mean no update done yet. Might cause some list "spam" though. Ideas welcome. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
08.04.2017 22:59, Andreas Färber пишет:
Hi Michal,
Am 07.04.2017 um 10:38 schrieb Michal Marek:
some time ago, we switched the vanilla configs and subsequenly a few other special flavors to only contain the diff agains the -default kernel. I think it's a good idea to finish this conversion and only have a single base config per architecture. After doing
sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default scripts/sequence-patch.sh --fast cd tmp/current ./run_oldconfig.sh
I get this
$ wc -l config/*/* [...] 9160 config/armv7hl/default 8795 config/armv7hl/lpae 3 config/armv7hl/vanilla [...] 67617 total
config/armv7hl/lpae is still not converted, because armv6 and armv7 are currently disabled.
"still not converted"??? It's not like we ever discussed a conversion! (Did you maybe mean s/still not/not yet/?) On the contrary, I already explained the default vs. lpae issue to you back when integrating dtb-armv7l into kernel packaging.
How do you expect I maintain the lpae config as a fragment? By hand?! Saying "m" a few times more seems way easier to me.
lpae is highly different from the 64kb flavor that just tweaks one or two options - the size difference above should make that obvious: The lpae flavor excludes support for old Cortex-A8/-A9/-A5 based platforms and enables a few platforms that depend on LPAE (e.g., LSI Axxia) as well as features that depend on LPAE (e.g., KVM). So please understand that the lpae flavor is not just the equivalent to pae flavor on i386, despite similar naming!
vanilla is already a fragment config, based on default. Being based on default means we have no linux-next config for LPAE. So far no one has asked for one.
I would claim that the lpae flavor is more important than default, because it supports the newer-generation hardware. So if you absolutely must force fragments onto us (which so far mostly affects myself and the CC'ed contributors, since during my recent absences your ARM engineers didn't even help update arm64!), I would much rather run oldconfig for lpae as a real config and risk having a default fragment break than the other way around. Switching the naming would cause problems for our JeOS images and cause even more confusion for users.
Dear All, Year or two ago I regularly submitted here config-update patches for arm. Unfortunately, I don't have much time to track new kernel releases now. But, I would like to say from my experience that I think that kernel configs might be managed better than now. Frankly speaking, the first thing I did when I needed to update ARM config was cherry-picking last arch-independent changes from x86_64 config. There are things like filesystems and network protocols. It In my personal opinion, to split out arch-independent config options would be more useful than default/lpae diffing. That would simplify ARM config maintenance at least.
Finally, on the topic of updating ARM configs, I am still annoyed about the new merge process: As someone not working on ARM kernels for his job, I need the weekend for testing new kernels on my boards at home. Previously I could commit ARM config changes to master branch myself on Friday, get them transferred to OBS Kernel:HEAD via your cron job on Saturday morning and when back home in the evening (or on Sunday) I could start testing the new packages. These days, despite my IRC pings, Jeff merges pending branches I push only after his next -rc update on Mondays, which then usually delays my testing until the next weekend.
Also we don't seem to have any process in place that would notify me or let me review any ARM config changes from others, unless they're posted here as a patch, such as Stefan's that I just noticed. The new process simply doesn't work well for delegation of ARM configs to people outside your branch maintainers, i.e. no sub-maintainer model.
In summary, there are delays getting updated configs submitted to your team by myself or community members, and then there are delays getting the submitted config updates merged by your team and thereby into OBS. During that timespan there are no kernels available from Kernel:HEAD ARM repo - Andreas Schwab had complained about that before, to no effect.
https://build.opensuse.org/package/binaries/Kernel:HEAD/kernel-default?repos...
(Currently this only shows aarch64 binaries, no armv6l or armv7l.)
And I doubt you added any checks to stop yourselves from submitting a kernel with non-updated ARM configs to Kernel:stable, should it not get done within sufficient weeks. We had that happen for armv6l before I stepped in, I recall. Why are no alarm bells raised when, say, -rc3 still has "-!needs_updating"? Should be easy to grep for.
So the kernel team clearly does not care about the master ARM configs (I was told to monitor an internal-only mailing list to get notified about -rc1 updates disabling the configs, for external contributors that still requires to poll the Git repository - no emails to opensuse-kernel or opensuse-arm for instance), and now you propose yet another change that seems to make the ARM updating process even harder for those that do care. Thank you very much... also for not CC'ing at least me on this proposal/complaint. Subject said nothing about ARM, and we don't have any -debug flavor there, so it would seem rather unrelated.
Regards, Andreas
-- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Fri, 07 Apr 2017 10:38:21 +0200, Michal Marek wrote:
Hi,
some time ago, we switched the vanilla configs and subsequenly a few other special flavors to only contain the diff agains the -default kernel. I think it's a good idea to finish this conversion and only have a single base config per architecture. After doing
sed -i '/CONFIG_MMU=y/d' config/*/debug config/i386/default scripts/sequence-patch.sh --fast cd tmp/current ./run_oldconfig.sh
I get this
$ wc -l config/*/* 15 config/arm64/64kb 8480 config/arm64/default 4 config/arm64/vanilla 6846 config/armv6hl/default 3 config/armv6hl/vanilla 9160 config/armv7hl/default 8795 config/armv7hl/lpae 3 config/armv7hl/vanilla 216 config/i386/debug 341 config/i386/default 8332 config/i386/pae 6 config/i386/vanilla 48 config/ppc64/debug 6804 config/ppc64/default 3 config/ppc64/vanilla 46 config/ppc64le/debug 6654 config/ppc64le/default 3 config/ppc64le/vanilla 3366 config/s390x/default 3 config/s390x/vanilla 77 config/x86_64/debug 8363 config/x86_64/default 43 config/x86_64/syzkaller 6 config/x86_64/vanilla 67617 total
config/armv7hl/lpae is still not converted, because armv6 and armv7 are currently disabled. config/i386/debug is larger than the other debug flavors, because it enables some drivers that pae does not (e.g. CONFIG_ISA).
BTW, recently I noticed that config/i386/default varies unstably after running run_oldconfig.sh. Some configs are turned on once, and turned off at the next update, or so. Any side-effect by this change...? Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Dne 24.4.2017 v 17:44 Takashi Iwai napsal(a):
BTW, recently I noticed that config/i386/default varies unstably after running run_oldconfig.sh. Some configs are turned on once, and turned off at the next update, or so. Any side-effect by this change...?
Do you remember what command you used to change the configs in 9add1483339d ("Enable CONFIG_KXCJK1013 for Cherrytrail devices (boo#1034809).") The logic for run_oldconfig.sh -nco-{y,m,n} is as follows: # do not change trimmed configs unless requested if test -z "$set_flavor" && ! \ grep -q '^CONFIG_MMU=' "${prefix}config/$config"; then continue fi Which means that if you explicitly specify the flavor, it will change even fragmented configs. This makes perfect sense for --flavor vanilla, but --flavor default is probably not explicit enough. That the option disappeared when Jeff ran run_oldconfig.sh is correct, because it was redundant. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon, 24 Apr 2017 21:51:25 +0200, Michal Marek wrote:
Dne 24.4.2017 v 17:44 Takashi Iwai napsal(a):
BTW, recently I noticed that config/i386/default varies unstably after running run_oldconfig.sh. Some configs are turned on once, and turned off at the next update, or so. Any side-effect by this change...?
Do you remember what command you used to change the configs in
9add1483339d ("Enable CONFIG_KXCJK1013 for Cherrytrail devices (boo#1034809).")
IIRC, I just ran the usual patches/script/run_oldconfig.sh on the tree expanded by sequence-patch.
The logic for run_oldconfig.sh -nco-{y,m,n} is as follows:
# do not change trimmed configs unless requested if test -z "$set_flavor" && ! \ grep -q '^CONFIG_MMU=' "${prefix}config/$config"; then continue fi
Which means that if you explicitly specify the flavor, it will change even fragmented configs. This makes perfect sense for --flavor vanilla, but --flavor default is probably not explicit enough. That the option disappeared when Jeff ran run_oldconfig.sh is correct, because it was redundant.
I didn't specify the flavor. Or maybe I ran run_oldconfig.sh multiple times. That makes any difference? Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2017-04-24 22:21, Takashi Iwai wrote:
On Mon, 24 Apr 2017 21:51:25 +0200, Michal Marek wrote:
Dne 24.4.2017 v 17:44 Takashi Iwai napsal(a):
BTW, recently I noticed that config/i386/default varies unstably after running run_oldconfig.sh. Some configs are turned on once, and turned off at the next update, or so. Any side-effect by this change...?
Do you remember what command you used to change the configs in
9add1483339d ("Enable CONFIG_KXCJK1013 for Cherrytrail devices (boo#1034809).")
IIRC, I just ran the usual patches/script/run_oldconfig.sh on the tree expanded by sequence-patch.
The logic for run_oldconfig.sh -nco-{y,m,n} is as follows:
# do not change trimmed configs unless requested if test -z "$set_flavor" && ! \ grep -q '^CONFIG_MMU=' "${prefix}config/$config"; then continue fi
Which means that if you explicitly specify the flavor, it will change even fragmented configs. This makes perfect sense for --flavor vanilla, but --flavor default is probably not explicit enough. That the option disappeared when Jeff ran run_oldconfig.sh is correct, because it was redundant.
I didn't specify the flavor. Or maybe I ran run_oldconfig.sh multiple times. That makes any difference?
Running it multiple times should not make any difference. Can you check next time you do a config update if config/i386/default changed? It should not change unless you are explicitly adding a difference from pae or if there is a version update removing options. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (5)
-
Andreas Färber -
Jean Delvare -
Matwey V. Kornilov -
Michal Marek -
Takashi Iwai