JeremyStarTM/aur-linux-clear
JeremyStarTM/aur-linux-clear
1
0
Fork 1
Code Issues Pull requests 1 Activity

Allow modifying current defconfig #2

Open
yarost12 wants to merge 1 commit from yarost12/aur-linux-clear:YF-allow-modifying-current-config into master
pull from: yarost12/aur-linux-clear:YF-allow-modifying-current-config
merge into: JeremyStarTM:master
Conversation 4 Commits 1 Files changed 1 +11 -3
yarost12 commented 2024-11-22 14:24:05 +01:00
Contributor
Copy link

Allow copying the current config and modifying it by running: _use_current=y _makenconfig=y (or other config modifier).

Allow copying the current config and modifying it by running: _use_current=y _makenconfig=y (or other config modifier).
yarost12 added 1 commit 2024-11-22 14:24:06 +01:00 
Allow copying the current config and modifying it by running:
_use_current=y _makenconfig=y (or other config modifier).
yarost12 requested review from JeremyStarTM 2024-11-22 14:24:16 +01:00
JeremyStarTM requested changes 2024-11-23 14:36:08 +01:00
JeremyStarTM left a comment
Owner
Copy link

I do not entirely see the value of this PR here. Wouldn't it be smarter to modify PKGBUILD#312 to simply always invoke update_defconfig?

I do not entirely see the value of this PR here. Wouldn't it be smarter to modify [PKGBUILD#312](https://git.staropensource.de/JeremyStarTM/aur-linux-clear/src/commit/0ce919c973aa43748a435948250d6b8bcb7f72c8/PKGBUILD#L312) to simply always invoke `update_defconfig`?
yarost12 commented 2024-11-23 22:23:54 +01:00
Author
Contributor
Copy link

But then we're just starting off from scratch every time, unless I'm missing something. We can in theory bring out the checks of modify_defconfig, but then we'd still need to check inside of it to know which util to call.

I just want to be able to do the followin:

  1. mod the config
  2. update the kernel
  3. re-use the config
  4. modify the already customized config if I want to
But then we're just starting off from scratch every time, unless I'm missing something. We can in theory bring out the checks of modify_defconfig, but then we'd still need to check inside of it to know which util to call. I just want to be able to do the followin: 1. mod the config 2. update the kernel 3. re-use the config 4. modify the already customized config if I want to
yarost12 commented 2024-11-23 22:27:54 +01:00
Author
Contributor
Copy link

Also I think you didn't enable landlock correctly, it needs to be added to the CONFIG_LSM list

Also I think you didn't enable landlock correctly, it needs to be added to the CONFIG_LSM list
JeremyStarTM commented 2024-11-23 23:41:53 +01:00
Owner
Copy link

But then we're just starting off from scratch every time, unless I'm missing something. We can in theory bring out the checks of modify_defconfig, but then we'd still need to check inside of it to know which util to call.

Wouldn't be it better if that config overriding code would be executed every time? Let's say that our currently running kernel is not linux-clear and we want to use it's current config. Our optimizations and changes will never be applied to that config, which is in some cases bad.

Also I think you didn't enable landlock correctly, it needs to be added to the CONFIG_LSM list

Oh, will take a look at that tomorrow (I'm in Germany btw.)

> But then we're just starting off from scratch every time, unless I'm missing something. We can in theory bring out the checks of modify_defconfig, but then we'd still need to check inside of it to know which util to call. Wouldn't be it better if that config overriding code would be executed every time? Let's say that our currently running kernel is not linux-clear and we want to use it's current config. Our optimizations and changes will never be applied to that config, which is in some cases bad. > Also I think you didn't enable landlock correctly, it needs to be added to the CONFIG_LSM list Oh, will take a look at that tomorrow (I'm in Germany btw.)
yarost12 commented 2024-11-24 00:30:35 +01:00
Author
Contributor
Copy link

I'm in the Baltics.

Our optimizations and changes will never be applied to that config, which is in some cases bad.

Well, I assume that people using these flags know what they're doing, otherwise they probably wouldn't be touching them. We can add a warning or an info message saying something like

By using config from /proc/config.gz you might miss out on some optimizations of the Linux Clear project, tread carefully

I don't think we should be forcing people to use linux clear flags, maybe they're here for the patches only. I personally always disable SELINUX due to some horrors that I went through getting it to work on the commercial projects.

I'm in the Baltics. > Our optimizations and changes will never be applied to that config, which is in some cases bad. Well, I assume that people using these flags know what they're doing, otherwise they probably wouldn't be touching them. We can add a warning or an info message saying something like >By using config from /proc/config.gz you might miss out on some optimizations of the Linux Clear project, tread carefully I don't think we should be forcing people to use linux clear flags, maybe they're here for the patches only. I personally always disable SELINUX due to some horrors that I went through getting it to work on the commercial projects.
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u YF-allow-modifying-current-config:yarost12-YF-allow-modifying-current-config
git checkout yarost12-YF-allow-modifying-current-config

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git checkout master
git merge --no-ff yarost12-YF-allow-modifying-current-config
git checkout yarost12-YF-allow-modifying-current-config
git rebase master
git checkout master
git merge --ff-only yarost12-YF-allow-modifying-current-config
git checkout yarost12-YF-allow-modifying-current-config
git rebase master
git checkout master
git merge --no-ff yarost12-YF-allow-modifying-current-config
git checkout master
git merge --squash yarost12-YF-allow-modifying-current-config
git checkout master
git merge --ff-only yarost12-YF-allow-modifying-current-config
git checkout master
git merge yarost12-YF-allow-modifying-current-config
git push origin master
Sign in to join this conversation.
Reviewers
No reviewers
JeremyStarTM
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: JeremyStarTM/aur-linux-clear#2
No description provided.
Delete branch "yarost12/aur-linux-clear:YF-allow-modifying-current-config"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?