New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Armbian desktop #2776
Armbian desktop #2776
Conversation
By adding uuid-runtime to the list of packages to install. Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
That way we can use ONE function that actually works for cleaning lists. This list cleanup function lets people format their packages lists like they want (spaces, tabs, carriage returns), making them easier to maintain. Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
Now, the code should start to be "readable" in configuration.sh, while providing the abilities to setup packages files with tabs, spaces, carriages returns and anything that can be recognized as a "space" character. Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
So now we have : * debootstrap * debootstrap/custom/boards/${BOARD} * debootstrap/config_${CONFIG_SELECTED} * debootstrap/config_${CONFIG_SELECTED}/custom/boards/${BOARD} * main * main/custom/boards/${BOARD} * main/config_${SELECTED_CONFIGURATION} * main/config_${SELECTED_CONFIGURATION}/custom/boards/${BOARD} Which is coherent with how board specific subdirs work with Desktop environments and appgroups. Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
The aggregation of Debootstrap packages list should not glue packages names together now. Also the PACKAGE_LIST_RM content will be added to the packages.remove files content, instead of being overwritten by them. Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
This is still quite untested, since each test take roughly an hour to execute. I'm currently retesting the addition of APT sources, since the functions used have been modified. Still, so far, it seems to works. Anyway, the system has been modified to avoid, at much as possible, the duplication of build related files, and put everything related to specific boards inside a directory located at config/optional, instead of putting this as a custom/boards subdirectory inside desktop environments and appgroups. So now, the base directories used to source build files are : ${SRC}/config ${SRC}/config/optional/_any_board/_configs ${SRC}/config/optional/architectures/${ARCH}/_config ${SRC}/config/optional/families/${LINUXFAMILY}/_config ${SRC}/config/optional/boards/${BOARD}/_config New subfolders have been added, to reduce the duplication : * desktop/_all_distributions, cli/_all_distributions Sourced for all distributions, which should make it easier to put build files that are directly linked to any distribution (wallpapers packages, for example) * desktop/${RELEASE}/environments/_all_environments, desktop/_all_distributions/environments/_all_environments When building for desktop, this is sourced for any desktop environment used. With these additions, if you're building a desktop image, with XFCE "base" as your default desktop environment, the system will look for 'packages' files in these different paths : config/desktop/_all_distributions/environments/_all_environments/packages config/desktop/_all_distributions/environments/xfce/packages config/desktop/_all_distributions/environments/xfce/config_base/packages config/desktop/focal/environments/_all_environments/packages config/desktop/focal/environments/xfce/packages config/desktop/focal/environments/xfce/config_base/packages config/optional/_any_board/_configs/desktop/_all_distributions/environments/_all_environments/packages config/optional/_any_board/_configs/desktop/_all_distributions/environments/xfce/packages config/optional/_any_board/_configs/desktop/_all_distributions/environments/xfce/config_base/packages config/optional/_any_board/_configs/desktop/focal/environments/_all_environments/packages config/optional/_any_board/_configs/desktop/focal/environments/xfce/packages config/optional/_any_board/_configs/desktop/focal/environments/xfce/config_base/packages config/optional/architectures/arm64/_config/desktop/_all_distributions/environments/_all_environments/packages config/optional/architectures/arm64/_config/desktop/_all_distributions/environments/xfce/packages config/optional/architectures/arm64/_config/desktop/_all_distributions/environments/xfce/config_base/packages config/optional/architectures/arm64/_config/desktop/focal/environments/_all_environments/packages config/optional/architectures/arm64/_config/desktop/focal/environments/xfce/packages config/optional/architectures/arm64/_config/desktop/focal/environments/xfce/config_base/packages config/optional/families/rockchip64/_config/desktop/_all_distributions/environments/_all_environments/packages config/optional/families/rockchip64/_config/desktop/_all_distributions/environments/xfce/packages config/optional/families/rockchip64/_config/desktop/_all_distributions/environments/xfce/config_base/packages config/optional/families/rockchip64/_config/desktop/focal/environments/_all_environments/packages config/optional/families/rockchip64/_config/desktop/focal/environments/xfce/packages config/optional/families/rockchip64/_config/desktop/focal/environments/xfce/config_base/packages config/optional/boards/nanopct4/_config/desktop/_all_distributions/environments/_all_environments/packages config/optional/boards/nanopct4/_config/desktop/_all_distributions/environments/xfce/packages config/optional/boards/nanopct4/_config/desktop/_all_distributions/environments/xfce/config_base/packages config/optional/boards/nanopct4/_config/desktop/focal/environments/_all_environments/packages config/optional/boards/nanopct4/_config/desktop/focal/environments/xfce/packages config/optional/boards/nanopct4/_config/desktop/focal/environments/xfce/config_base/packages That said, currently the configuration files that were put inside custom/boards subdirectories are still not transferred to the new directories. This will be done in the next commit. Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
The paths... are getting longer actually, which isn't a good thing. But I wanted to keep the same directory structure "config/desktop" and "config/cli" structure inside the arch, families and boards specific directories. Anyway, the scripts are now factorized in single specific locations, which reduce the amount of copy-paste and errors appearing here and there. That said, this remains to be actually tested, since I don't have a Pinebook Pro. Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
I don't have a Pinebook anyway, so yeah. Still, this works and this should allow maintainers to put all the files related to a specific board builds, in various specific folders, located in config/optional . Note that you can actually put any file in the various config/optional/{architectures,families,boards} subdirectories. The subdirectory _config is named like this to avoid any name conflict with other directories you might add. So, for example, inside config/optional/boards/nanopct4, you can add a subdirectory named 'desktop_skels' and copy you various desktop default configurations from this subdirectory. I still leave the layout of these subdirectories up to the various maintainers. The only subdirectory that is actually sampled by the build scripts is "_config". Additional package for appgroups, that are dependent of the selected desktop environment, are now sampled from : * desktop/_all_distributions/environments/${DESKTOP_ENVIRONMENT}/appgroups * desktop/${RELEASE}/environments/${DESKTOP_ENVIRONMENT}/appgroups This makes it easier to understand what packages will be installed when selecting a desktop environment, instead of having to check each individual appgroup subdirectory. So everything related to a specific desktop environment stays in its folder. This change leads to 'custom' subdirectories being entirely useless, which means that you should remove them now. Anyway, I'm sure there are still parts I haven't checked, so feel free to play with this and give it a try. Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
… armbian_desktop Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
The whole idea is to split the current Armbian desktop packages, in order to avoid having Board Specific data into the common Armbian desktop package. This avoids having to update the package, everytime a board needs a new desktop specific configuration file, or whatever. And it's cleaner anyway, desktop package should not contain configuration files for niche boards. Currently, this sample files from debian/armbian-bsp-desktop/ folders inside config/desktop/${RELEASE}/{appgroups,environments}/*/ . The next step will be to move every board specific script instruction, from the armbian-desktop preparation scripts, to the armbian-bsp-desktop-${BOARD} preparation script. Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
The whole idea will be to avoid sampling armbian-desktop preparation scripts from the config/optional folders, as much as possible, since the armbian-desktop package isn't supposed to contain any board specific data anyway. Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr>
The whole idea is to put all the "desktop" related board specific files in the following directories : * ${SRC}/packages * ${SRC}/config/optional/_any_board/_packages * ${SRC}/config/optional/architectures/${ARCH}/_packages * ${SRC}/config/optional/families/${LINUXFAMILY}/_packages * ${SRC}/config/optional/boards/${BOARD}/_packages The directories content are then copied, in order, inside the armbian-bsp package content, specific files overwriting more generic files when applicable. This should make the management of boards specific files easier. The packages are still customizable by placing : * debian/armbian-bsp-desktop/prepare.sh * debian/armbian-bsp-desktop/postinst files inside environments and appgroups configurations, just in case you need that extra level of customization. I hope not. The more you go "fine-grained" customization, the more difficult it is to manage the whole thing actually. Signed-off-by: Myy Miouyouyou <myy@miouyouyou.fr>
Thank you! Take your time to make it right.
Perhaps we should break this into two parts so we can solve at least one problem? First part - introducing cli bsp package naming seems like a reasonable small change which we can properly test, prepare upgrade path and merge into upcoming release @Heisath ? The rest is IMO too much complicated task for those busy times. I know its getting complicated and it's hard to follow. Already for me. How far do you understand those changes @Heisath @tparys @5kft @150balbes @lanefu @RichNeese @paolosabatino ? (it's more like a short survey, no need to dive in to answer, "little" or "nothing" is legit answer ;) |
I like the idea of splitting out the new package naming convention and getting that merged. My suggestion is that the remaining work is documented into tasks so that development can be shared and the burden does not remain soley on myy to finish. |
little. As the boards I'm interested in are only cli anyways and I dont really care for desktop on SBC tbh. Would also support merging only a part for the next release. Code freeze was planned for this sunday - afterwards only fixes. We can obv. move this a bit, but should have enough of a window before release to actually test & bugfix. |
Also little. I've not looked much into Armbian specific desktop bits, and anything board specific that would need to be set. |
I took a brief look into the code, I'm quite used to bash scripting, but never really dug into Armbian scripts. |
Should we have a desktop branch again and continue development on this there? |
Probably best, yes. I would say we move on this in a few weeks since merge window for 21.05 is closing, its not tested and clearly early wip. Renaming part can be merged, which is why I prepared a separate MR. |
* Renaming the BSP package to armbian-bsp Extracted from #2776 * Update naming * Create meta package for upgrade and remove deprecated mpv related config management * Probably we want to keep our internal release version in filename
Just made a little test - nothing exciting or complex, just followed the existing directory structure of NanoPi. I miss the possibility to read some debug output to understand what files are taken and from where they come. |
I do
I wants configure packages: I want only |
Nope. (best effort) support is on forums. |
You are using the wrong approach. The script that you created is needed for commands that are additionally executed for a specific device model. For example, to add specific settings only for this model, to add binary firmware and other things (or vice versa, to delete non-compatible components\files). The composition of the packages that are installed is described elsewhere. See the description of how to manage the composition of packages on the example of the desktop version. By analogy, you can do the same with adding packages for the CLI category (in the directory of their settings). Tip, take a ready-made minimal or server image, look at the composition of packages in the system, and make a list of packages that are missing. And you add only them. https://github.com/armbian/build/blob/master/config/cli/focal/main/packages https://github.com/armbian/build/blob/master/config/desktop/README.md |
Extracting from #2776 which can be closed after.
* Add support for desktop board support package Extracting from #2776 which can be closed after. * Desktop BSP creation is working, but need broader testing and some quick how-to * Create empty files as examples where we can put things. * Fixing Pinebook desktop bsp creation * We need to have information about ARCH in the desktop bsp package. This ain't universal.
So I can't exclude any default package from build/config/cli/hirsute/main/packages ? P.S. Wants to do it without crutch |
Closed with #2972 |
* Renaming the BSP package to armbian-bsp Extracted from armbian#2776 * Update naming * Create meta package for upgrade and remove deprecated mpv related config management * Probably we want to keep our internal release version in filename
* Add support for desktop board support package Extracting from armbian#2776 which can be closed after. * Desktop BSP creation is working, but need broader testing and some quick how-to * Create empty files as examples where we can put things. * Fixing Pinebook desktop bsp creation * We need to have information about ARCH in the desktop bsp package. This ain't universal.
* Renaming the BSP package to armbian-bsp Extracted from armbian#2776 * Update naming * Create meta package for upgrade and remove deprecated mpv related config management * Probably we want to keep our internal release version in filename
* Add support for desktop board support package Extracting from armbian#2776 which can be closed after. * Desktop BSP creation is working, but need broader testing and some quick how-to * Create empty files as examples where we can put things. * Fixing Pinebook desktop bsp creation * We need to have information about ARCH in the desktop bsp package. This ain't universal.
Description
This is still a WIP. The files need to be actually moved to the appropriate folders
Only the X11/xorg.conf.d files were tested at the moment.
Still, I'm extremely late and I barely have time to finish this, so I'll try to add appropriate documentation by the end of the month, so that people understand "what's going on" with these changes.
Jira reference number AR-713
How Has This Been Tested?
Brfiefly on NanoPC T4 systems. Testing still need to be intensively done on other platforms to test the reliability of the system.
I mainly checked that the files are actually copied, and the package actually installed on the system.
Checklist:
No. Some parts clearly need more documentation.
Not at the moment.
Unapplicable here.