Age | Commit message (Collapse) | Author |
|
|
|
This removal is part of a process to decomission Distribution channel.
---
The ultimate goal is to move useful code from Distribution channel to either Sovereign or Deployment channel.
Everything else will be deleted and ultimately will be removed from network.
---
Module (deployment systems aisaka) has a dangling import of (suweren update).
Module (deployment users id1000) uses update-commands from (suweren update).
Guix-channel file includes dependency on Distribution channel.
---
The dangling import of (suweren update) is deleted from (deployment systems aisaka).
The update-commands binding is replaced with a definition from Sovereign channel.
The dependency on Distribution channel is removed from the list.
---
With this change Deployment channel is completely independent of Distribution, which can be deleted now.
|
|
This removal is part of a process to decomission Distribution channel.
---
The ultimate goal is to move useful code from Distribution channel to either Sovereign or Deployment channels.
Everything else will be deleted and ultimately will be removed from network.
---
The (suweren system) module was imported in aisaka, akashi and ayase systems.
---
All these imports are deleted.
---
After this (suweren system) module can be deleted from Distribution channel.
|
|
This replacement is part of a process to decomission Deployment channel.
---
The ultimate goal is to move useful code from Deployment channel to either Sovereign or Deployment channels.
Everything else will be deleted and ultimately will be removed from network.
---
The replaced reference is a useless indirection.
---
The direct object from upstream Guix channel is used instead.
---
This is the last variable from (suweren system) module gone.
|
|
This replacement is part of a process to decomission Deployment channel.
---
The ultimate foal is to move useful code from Deployment channel to either Sovereign or Deployment channels.
Everything else will be deleted and ultimately the entire channel will be removed from network.
---
The replaced refences are already defined in Sovereign channel.
---
The definitions from Sovereign channel are used in place of the old ones.
---
The Sovereign definition is exactly the same as on in Distribution channel.
|
|
This replacement is part of a process to decomission Deployment channel.
---
The ultimate goal is to move useful code from Deployment channel to either Sovereign or Deployment channels.
Everything else will be deleted and ultimately the entire channel will be removed from network.
---
The replaced refences are already defined in Sovereign channel.
---
The definitions from Sovereign channel are used in place of the old ones.
---
The Sovereign definition is slightly more complete (with explicit charset field), but functionally the same as the old one.
|
|
This removal is part of a process to decommission Deployment channel.
---
The ultimate goal is to move useful code from Deployment channel to either Sovereign or Deployment channels.
Everything else will be deleted and ultimately the entire channel will be removed from the net.
---
The deleted reference contains in its definition variables from both upstream Guix and another Distribution module.
Record uid1000-home-environment is the only user of the deleted reference.
This definition is in outdated style.
The (suweren home) module, defining the deleted reference, is also still imported by (deployment systems aisaka).
---
The variables listed in the deleted reference are used directly in the modified record.
This record is also restructured to match the current style.
The imports of of (suweren home) module are deleted from all affected modules.
Appropriate imports are added in (deployment users id1000).
---
Nothing else depends on the deleted reference, so its definition can be safely deleted from Distribution channel.
As it is the last definition in the module, the entire file can be deleted from the channel.
|
|
This reverts commit 82a3d8b78629c66ebe2c0ace462d32532ac30e9f.
|
|
Akashi system needs to have fan control enabled and customized.
By default, the firmware fails to adequately cool the computer which results in thermal throttling.
---
The goal is to have the laptop fan run at high speed at all times, regardless of CPU temperature.
---
[x] Enable fan control in thinkpad_acpi module.
[x] Set fan speed to level 5.
---
This commit adds an appropriate entry to the kernel command line to set the fan speed level.
---
Akashi system will now adequately cool itself in most circumstances.
|
|
|
|
A recent update of GCC on Guix channel causes easyeffects to fail compilation due to a security error.
-----
The uninstallation of easyeffects is both the simplest and least impactful solution to the problem.
-----
Easyeffect was actually useful for one task only — duplication of a mono microphone signal into a stereo signal.
-----
This change removes easyeffects from the list of packages provided by default for user id1000.
-----
After this, Easyeffects program will no longer be available by default for user id1000.
|
|
|
|
Akashi system needs to have fan control enabled and customized.
By default, the firmware fails to adequately cool the computer which results in thermal throttling.
-----
The goal is to have the laptop fan run at high speed at all times, regardless of CPU temeperature.
-----
[X] Enable fan control in thinkpad_acpi module.
[ ] Set fan speed to level 5.
-----
This commit adds an appropriate entry to the kernel command line to enable fan control.
The goal of the series is now to set level 5 fan speed, as it is more pleasing to the ear.
-----
Akashi system will now allow fan control without havind to reload thinkpad_acpi module.
|
|
Akashi system needs to have fan control enabled and customized.
By default, the firmware fails to adequately cool the computer which results in thermal throttling.
-----
The goal is to have the laptop fan run at full throttle at all times, regardless of CPU temeperature.
-----
[ ] Enable fan control in thinkpad_acpi module.
[ ] Set fan speed to full throttle.
-----
This commit configures a custom guix configuration for Akashi system in order to set up a testing loop with a staging branch.
Additional modules need to be imported in order to facilitate this change.
-----
Akashi system will now pull the staging branch of Deployment channel during updates.
|
|
The (sovereign channels) defines a new, simpler guix channel.
|
|
|
|
All operating-system records are configured to prepend default labels with respective host names.
-----
Some minor adaptations had to performed.
|
|
The purpose of the test subdomain is to try out changes in nginx configuration.
As such, directories should not be created for the sake of the test subdomain.
Instead, the test subdomain should point to a subdomain currently needing testing.
|
|
|
|
|
|
|
|
The root user need access to openssl command in order to manipulate ca secrets.
|
|
Some ruby packages were moved from (gnu packages ruby) to (gnu packages ruby-check).
Some ruby packages were moved from (gnu packages ruby) to (gnu packages ruby-xyz).
|
|
No functional changes are introduced.
This is purely visual improvement.
|
|
|
|
The current system configuration of aisaka uses an old custom home environment from before a unified one was developed.
As it is no longer useful, the (home-services) procedure definition is removed from the module.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The prototype of the client certificate authentication is suboptimal.
The use of a private certificate authority for server authentication causes unnecessary security warnings when loading the subdomain with an unauthenticated browser.
Any browser in its default configuration has no right to understand the private certificate authority used for the client and server certificates.
It is possible to mix Let’s Encrypt certificates with a private certificate authority to implement the authentication.
None of the previously found client authentication guides mentioned that server authentication can use an authority chain different to client authentication.
This change takes advantage of this separation of concerns by using a Let’s Encrypt certificate for the test subdomain server, while keeping the private certificate for client authentication.
|