KLV-BspwmCE-1.5 Stable

[Sofiya]

KLV-BspwmCE-1.5 Stable
ISO: 720 ( Mib ) Kernel -6.1.38
https://mega.nz/file/fgUwRJYT#FmtS_g5Dx ... TezEi2sDGk

SHA1-MD5:
https://mega.nz/file/zg9l1DhD#h334LonMf ... nFpvco3Hnw

You can build it using a script "FR_minimal_void_bspwm_rc5.sh.FALSE.gz"

[Sofiya]

Code: Select all

qemu-system-x86_64 -enable-kvm -m 2G -vga std -smp 2 -device AC97 -cdrom /root/Downloads/KLV-BspwmCE-1.5.iso

[TerryH]

I'm not a big fan of tiling Window Managers. I have been using KLA-OT2baseCE 2.9 since it came out, which is an excellent release. Reading the KLV_BSPWM thread, I thought it would be well worth giving this release a spin. I downloaded the FR build script from the KLV_BSPWM 1.4 thread you have posted and built the release without issue.

After booting, I sat and stared at the screen and after some time I was reasonably comfortable running this release. The Panel Theme Switcher is a very nice touch. Everything runs smoothly. I don't think I'll switch to running it as a daily use, but will continue using to explore BSPWM further, maybe I'll end up liking tiling WM's.

Thank you for the contributions you have made to the Kennel Linux release choices. Well done.

[Sofiya]

Added right-click functions to Pcmanfm

Code: Select all

Graphical Disk Map
PCMANFM Search
Set As Wallpaper
sxivPlayGIF
Terminal Here

[Sofiya]

[geo_c]

I'm looking at your build script and gearing up to do a KLV-BspwmCE build.

You've got a plugfile which is downloaded and used in the script. If I want to add extra packages I should be adding them in the plug file correct? I assume it wouldn't be wise to add "xbps-install" commands to the main build script.

Is cups included in the build? I'll have to download the plug and take a look at it.

EDIT: I grabbed the plugfile from git and I'm looking at it now.

If I modify the plugfile, and comment out the line:

Code: Select all

wget -c https://gitlab.com/sofija.p2018/kla-ot2/-/raw/main/KLV-Bspwm/f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

where do I locate the plug file so that it's found by the build line:

Code: Select all

./build_firstrib_rootfs.sh void default amd64 f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

?

[Sofiya]

I'm looking at your build script and gearing up to do a KLV-BspwmCE build.

You've got a plugfile which is downloaded and used in the script. If I want to add extra packages I should be adding them in the plug file correct? I assume it wouldn't be wise to add "xbps-install" commands to the main build script.

Is cups included in the build? I'll have to download the plug and take a look at it.

EDIT: I grabbed the plugfile from git and I'm looking at it now.

If I modify the plugfile, and comment out the line:

Code: Select all

wget -c https://gitlab.com/sofija.p2018/kla-ot2/-/raw/main/KLV-Bspwm/f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

where do I locate the plug file so that it's found by the build line:

Code: Select all

./build_firstrib_rootfs.sh void default amd64 f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

?

Is cups included in the build?

Are the cups included in the assembly? yes they are included and the service is already enabled by default

where do I find the plugin file so it will be found in the build line:

in my plugin you won’t change anything since I have it. You can only add what you want to your additional sfs, calling it the name you like

[Sofiya]

EDIT: I grabbed the plugfile from git and I'm looking at it now.

If I modify the plugfile, and comment out the line:

Code: Select all

wget -c https://gitlab.com/sofija.p2018/kla-ot2/-/raw/main/KLV-Bspwm/f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

where do I locate the plug file so that it's found by the build line:

Code: Select all

./build_firstrib_rootfs.sh void default amd64 f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

?

If you comment on this line, then you won’t get anything. if you want to add something to my plugin, I assume that you downloaded it by running the build script
https://gitlab.com/sofija.p2018/kla-ot2 ... 20rc5.plug . в нём вы можете добавить то что хотите и продолжить сборку дальше . но за правильность работы я уже не отвечаю так как это будет уже ваш плагин

[Sofiya]

what packages do you want to add? maybe they are already in my plugin????

[geo_c]

If you comment on this line, then you won’t get anything. if you want to add something to my plugin, I assume that you downloaded it by running the build script

what packages do you want to add? maybe they are already in my plugin????

I downloaded the plugfile from git manually. And I kind of thought that once the build script fetches the plug then the following line uses it from the build directory perhaps. So I was thinking of just modifying the plug and copying it to the build directory (maybe by adding a cp command in place of the wget)

Code: Select all

./build_firstrib_rootfs.sh void default amd64 f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

I just want to add a bunch of terminal apps and some audio apps:

xbps-install xfe gpick cpupower ranger calcurse lilypond musikcube micro lynx elinks w3m w3m-img neomutt newsboat ardour hplip (maybe a couple of others)

I could always do this with a script after building, or just do Psuedo-Full-Install, and resquash rootfs, but if I could learn to make a basic addition to the plug, then I can build it custom out-of-the-box.

[Sofiya]

If you comment on this line, then you won’t get anything. if you want to add something to my plugin, I assume that you downloaded it by running the build script

what packages do you want to add? maybe they are already in my plugin????

I downloaded the plugfile from git manually. And I kind of thought that once the build script fetches the plug then the following line uses it from the build directory perhaps. So I was thinking of just modifying the plug and copying it to the build directory (maybe by adding a cp command in place of the wget)

Code: Select all

./build_firstrib_rootfs.sh void default amd64 f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

I just want to add a bunch of terminal apps and some audio apps:

xbps-install xfe gpick cpupower ranger calcurse lilypond musikcube micro lynx elinks w3m w3m-img neomutt newsboat ardour hplip (maybe a couple of others)

I could always do this with a script after building, or just do Psuedo-Full-Install, and resquash rootfs, but if I could learn to make a basic addition to the plug, then I can build it custom out-of-the-box.

Code: Select all

./build_firstrib_rootfs.sh void default amd64 f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

--- this is not a plugin this is a build startup script

here is a plugin in which you need to add programs after line 113 :

Code: Select all

xbps-install -y xfe cpupower ranger calcurse lilypond musikcube micro lynx elinks w3m w3m-img neomutt newsboat ardour hplip

Code: Select all

wget -c https://gitlab.com/sofija.p2018/kla-ot2/-/raw/main/KLV-Bspwm/f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

and continue building with this plugin without changing its name, my plugin will no longer be downloaded since you put the plugin in. When building, it should already be in the folder in which you are building

[geo_c]

Code: Select all

./build_firstrib_rootfs.sh void default amd64 f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

--- this is not a plugin this is a build startup script

Right, that's the line in the build script that loads the plug file And I downloaded the plugin by opening gitlb address below in a browser. So I believe I have the correct file. In that plug file I can add my packages after line 113, and as long as the plugin file is present in the build directory it should work, but I need to comment out the line below from the build script so that it doesn't overwrite my modified plug, correct?

Code: Select all

wget -c https://gitlab.com/sofija.p2018/kla-ot2/-/raw/main/KLV-Bspwm/f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

and continue building with this plugin without changing its name, my plugin will no longer be downloaded since you put the plugin in. When building, it should already be in the folder in which you are building

[Sofiya]

Code: Select all

./build_firstrib_rootfs.sh void default amd64 f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

--- this is not a plugin this is a build startup script

Right, that's the line in the build script that loads the plug file And I downloaded the plugin by opening gitlb address below in a browser. So I believe I have the correct file. In that plug file I can add my packages after line 113, and as long as the plugin file is present in the build directory it should work, but I need to comment out the line below from the build script so that it doesn't overwrite my modified plug, correct?
[/code]

Code: Select all

wget -c https://gitlab.com/sofija.p2018/kla-ot2/-/raw/main/KLV-Bspwm/f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

and continue building with this plugin without changing its name, my plugin will no longer be downloaded since you put the plugin in. When building, it should already be in the folder in which you are building

there is no need to comment if the plugin is already in the folder, it is no longer downloaded by the build script and is not overwritten

[Sofiya]

Code: Select all

./build_firstrib_rootfs.sh void default amd64 f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

--- this is not a plugin this is a build startup script

Right, that's the line in the build script that loads the plug file And I downloaded the plugin by opening gitlb address below in a browser. So I believe I have the correct file. In that plug file I can add my packages after line 113, and as long as the plugin file is present in the build directory it should work, but I need to comment out the line below from the build script so that it doesn't overwrite my modified plug, correct?

But if you’re so afraid that it will be overwritten, then comment out line 15 in “FR_minimal_void_bspwm_rc5.sh”

do not touch this line 39 " ./build_firstrib_rootfs.sh void default amd64 f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug "

but do not forget that your modified plugin with the name "f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug" must be located in the build folder. Otherwise the build will not start
line 39 is responsible for starting the build

Code: Select all

./build_firstrib_rootfs.sh void default amd64 f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug

[geo_c]

But if you’re so afraid that it will be overwritten, then comment out line 15 in “FR_minimal_void_bspwm_rc5.sh”

do not touch this line 39 " ./build_firstrib_rootfs.sh void default amd64 f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug "

but do not forget that your modified plugin with the name "f_00_Void_amd64_noXsimple00_sofiya-120rc5.plug" must be located in the build folder. Otherwise the build will not start

I'm not worried. I believe you when you say that if the plug file is in the build directory, the wget line won't overwrite it. I'll back up the modified plug file to another location of course.

and I would never consider modifying the build startup line!

Now suppose I wanted to added a few more things to the plug file, like copying some application config files to the rootfs, or creating symlinks within the rootfs to files outside the install directory. Is there a particular point in the plugfile you recommend placing these?

[Sofiya]

Now suppose I wanted to added a few more things to the plug file, like copying some application config files to the rootfs, or creating symlinks within the rootfs to files outside the install directory. Is there a particular point in the plugfile you recommend placing these?

mmm.. your files should already be on
your server or on https://gitlab.com. and accordingly, you need to write all this into the plugin in the form of code

[geo_c]

mm it should already be your file is on
your server or on https://gitlab.com. and accordingly, you need to write all this into the plugin in the form of code

Well the plug file will be run locally from my build directory. I'm suggesting that in the plugfile I add lines like these:

Code: Select all

mkdir /root/.config/xfe
cp /mnt/sda1/geo-personal-configs/xferc /root/.config/xfe

But now the logic, or my lack of it is becoming clear. When running the build script /root is not actually in the rootfs being built, but it's in the Distro from which the script is being run, which is why @williwaw is suggesting it be done after chroot.

I'm very ignorant of such matters, as I have never used chroot in my life, and also why I'm late to the script-build party.

edit: it appears @williwaw's suggestion has disappeared from the forum

[Sofiya]

mm it should already be your file is on
your server or on https://gitlab.com. and accordingly, you need to write all this into the plugin in the form of code

Well the plug file will be run locally from my build directory. I'm suggesting that in the plugfile I add lines like these:

Code: Select all

mkdir /root/.config/xfe
cp /mnt/sda1/geo-personal-configs/xferc /root/.config/xfe

But now the logic, or my lack of it is becoming clear. When running the build script /root is not actually in the rootfs being built, but it's in the Distro from which the script is being run, which is why @williwaw is suggesting it be done after chroot.

I'm very ignorant of such matters, as I have never used chroot in my life, and also why I'm late to the script-build party.

edit: it appears @williwaw's suggestion has disappeared from the forum

let's simplify the task, you have not yet converted "07firstrib_rootfs" to sfs, go to the folder and place the necessary files in the necessary folders, if there are no folders with the desired name, create them manually and place the configuration files there

[williwaw]

sorry, I deleted it because I didnt want to complicate too much..
working in chroot is one of many ways to make mods, but not neccesary or neccesarly the easiest

[geo_c]

let's simplify the task, you have not yet converted "07firstrib_rootfs" to sfs, go to the folder and place the necessary files in the necessary folders, if there are no folders with the desired name, create them manually and place the configuration files there

Well this gives me some things to think about.

Yes simply adding the files to the unsquashed sfs would be easiest.

I do like to understand the whole automated build process, so I will look closely at the build script and the plugfile and see what insights I get before asking any more questions.

[Sofiya]

let's simplify the task, you have not yet converted "07firstrib_rootfs" to sfs, go to the folder and place the necessary files in the necessary folders, if there are no folders with the desired name, create them manually and place the configuration files there

Well this gives me some things to think about.

Yes simply adding the files to the unsquashed sfs would be easiest.

I do like to understand the whole automated build process, so I will look closely at the build script and the plugfile and see what insights I get before asking any more questions.

To create a project, you need to have a server on which certain files of your project will be stored that will be included in the assembly, good knowledge of Linux as such. the location of the file system, knowledge of writing Bash -shell script . And in general, know how Linux works with a certain graphical environment

It goes like this. an assembly is created, naturally it looks ugly, after which everything is configured. Wallpaper, cursors, and other configuration files that will ultimately be used for the assembly. I can say one thing: all this takes a lot of time, in the end you see a beautiful assembly on which a lot of time was spent

you can, of course, just add the necessary packages to the script and the assembly will be assembled, but it will look just terrible, I don’t take XFCE into account since they have everything already configured

[geo_c]

you can, of course, just add the necessary packages to the script and the assembly will be assembled, but it will look just terrible, I don’t take XFCE into account since they have everything already configured

Which is why I'm not even considering trying to build from scratch, rather, I was thinking I can stand on the shoulders of people like yourself, and start with your desktop build, but adding slight modifications to the plug for my own purposes, or which could be shared as a modified build script at some future point when I understand the process better, of course any files used needing to be available on a server.

So in other words, not planning to produce a script for the public any time soon.

[wiak]

But now the logic, or my lack of it is becoming clear. When running the build script /root is not actually in the rootfs being built, but it's in the Distro from which the script is being run, which is why @williwaw is suggesting it be done after chroot.

Seems you are confused in your thinking geo_c.

If using the frontend script Sofiya provides in first post (FR_minimal_void_bspwm_rc5.sh) that involves the actual build script, build_firstrib_rootfs.sh (which that frontend downloads for you). If you want to add some of your own apps and configs first, all you need is to FIRST manually download Sofiya's f_plug file and modify that in an editor adding whatever packages you want that will later be used in the actual build.

Then run the actual frontend build script Sofiya provided (which includes the actual build_firstrib_rootfs.sh commandline); the f_plug will not be re-downloaded since you already have existing one, but your new apps and configs of the f_plug file will simply be used in the new build. Simple as that.

You don't need to do any chroot yourself, you don't even need to understand chroot... The chroot is done automatically by that build_firstrib_rootfs.sh script whilst it is doing all the commands provided by the f_plugin.

Yes, there are alternative ways of adding new apps and configs to the build after it is made and that would involve doing a chroot yourself (and FirstRib provides a script for automating the chroot for you called mount_chroot_umount.sh) BUT that is an alternative mechanism that you DO NOT NEED TO USE.

SUMMARY: Just modify the existing f_plug text file of Sofiya and then run the FR_minimal_void_bspwm_rc5.sh frontend script and that does the chroot for you and will build what you want. Don't worry about chroot - you don't need to understand that to do this build!

Don't give up and just use someone else's build. Well worth making a build yourself then you will realise later how easy it is! So well worth your effort downloading Sofiya's f_plug, editing it, and then running FR_minimal_void_bspwm_rc5.sh, which does the build_firstrib_rootfs.sh void default amd64 f_plugXXXX commandline for you...

[wiak]

To create a project, you need to have a server on which certain files of your project will be stored that will be included in the assembly

Well, come on Sofiya, you do not need a server! You just need an f_plug file and if you want special graphics and so on added to build, you can just store these on your own system and added to the f_plugin build commands. Yes, it is nice to have a server (or use gitlab) to store bits and pieces you can download, via f_plugin commands, during a build, but you don't NEED that. Nor do you need to understand chroot since build_firstrib_chroot.sh does all that internally. Nice to later understand how it all works of course, but no need really.

Certainly, if you want someone else to be able to build from a f_plug you created, you need to supply them with any extra files so could either provide these via your own gitlab site or similar, OR simply provide a tar.xz or suchlike of any extra files, graphics and so on the f_plug wants to include. But if you are doing your own build, on your own, machine, you have all the files on your local machine anyway so that is easy.

[wiak]

I was thinking I can stand on the shoulders of people like yourself, and start with your desktop build, but adding slight modifications to the plug for my own purposes, or which could be shared as a modified build script at some future point when I understand the process better, of course any files used needing to be available on a server.

Absolutely!!! That's exactly how the whole system works - including the parts I create:

I create and maintain the main actual build root filesystem scriipt, which is build_firstrib_rootfs.sh (and that does the tricky chroot stuff for the user), and
the FR skeleton initrd, which provides all the overlayfs frugal install functionality, and
in the build_firstrib_rootfs I provide a 'hook' in the form that during its internal chroot it looks for and processes the:

f_plug, which is something the user/builder/distro-creator needs to provide.

And, yes, the f_plug can be very complicated so we learn from each other; start with simple f_plug and gradually add commands and configs to it, which can include wget fetching of other assets, or copying-in other assets such as themes/graphics and so on from your local system (or from a server like github or gitlab provides). Yes, we learn from each other and build on what is already available and provided. Like everything in open-source world in fact.

So I'd say that it is very important to try making a build, but of course the way to do that is to start with someone else's already constructed and working f_plug file and then you add to it. In fact if you look back at FirstRib history you will see that I provided exemplar f_plugs for Void Linux to start the process off and to provide a reasonable initial f_plug start point. That was the 'seed' process.

[geo_c]

I create and maintain the main actual build root filesystem scriipt, which is build_firstrib_rootfs.sh (and that does the tricky chroot stuff for the user), and
the FR skeleton initrd, which provides all the overlayfs frugal install functionality, and
in the build_firstrib_rootfs I provide a 'hook' in the form that during its internal chroot it looks for and processes the:

f_plug, which is something the user/builder/distro-creator needs to provide.

Thanks, let's see if I have it straight:

At the point that the f_plug is envoked in the build script, the build script has already done the chroot, so references that I make to /root are pointing to the buildrootfs/root, and not the host distro where the build is taking place.

Assuming I have it correct, that raises the question of copying files to the chroot/rootfs, if those files I want to copy into the build chroot/rootfs using a command in the f_plug like

Code: Select all

cp /mnt/sda1/GEO'sFILES/somefile /root/.config/

will /mnt/sda1 be a valid location in the chroot?

[Sofiya]

To create a project, you need to have a server on which certain files of your project will be stored that will be included in the assembly

Well, come on Sofiya, you DO NOT NEED a server! You just need an f_plug file and if you want special graphics and so on added to build, you can just store these on your own system and added to the f_plugin build commands. Yes, it is nice to have a server (or use gitlab) to store bits and pieces you can download, via f_plugin commands, during a build, but you don't NEED that. Nor do you need to understand chroot since build_firstrib_chroot.sh does all that internally. Nice to later understand how it all works of course, but no need really.

Certainly, if you want someone else to be able to build from a f_plug you created, you need to supply them with any extra files so could either provide these via your own gitlab site or similar, OR simply provide a tar.xz or suchlike of any extra files, graphics and so on the f_plug wants to include. But if you are doing your own build, on your own, machine, you have all the files on your local machine anyway so that is easy.

Let's just say I look at this from the point of view that @geo_c will write a plugin to provide to other users, then they will not be able to download his files from his local computer if he writes just such a file download script. Therefore, he needs either a server or gitlab.com anyway

[Sofiya]

I create and maintain the main actual build root filesystem scriipt, which is build_firstrib_rootfs.sh (and that does the tricky chroot stuff for the user), and
the FR skeleton initrd, which provides all the overlayfs frugal install functionality, and
in the build_firstrib_rootfs I provide a 'hook' in the form that during its internal chroot it looks for and processes the:

f_plug, which is something the user/builder/distro-creator needs to provide.

Thanks, let's see if I have it straight:

At the point that the f_plug is envoked in the build script, the build script has already done the chroot, so references that I make to /root are pointing to the buildrootfs/root, and not the host distro where the build is taking place.

Assuming I have it correct, that raises the question of copying files to the chroot/rootfs, if those files I want to copy into the build chroot/rootfs using a command in the f_plug like

Code: Select all

cp /mnt/sda1/GEO'sFILES/somefile /root/.config/

will /mnt/sda1 be a valid location in the chroot?

Will

[geo_c]

Let's just say I look at this from the point of view that @geo_c will write a plugin to provide to other users, then they will not be able to download his files from his local computer if he writes just such a file download script. Therefore, he needs either a server or gitlab.com anyway

Yes I eventually figured out what you were saying. And this has all been very helpful in my quest to do the build.

I'm choosing to start with your build of Bspwm because I like it so much, it's so developed to be complete on it's own, and your script is very concise with clear instructions in the comments. So I appreciate all you are doing!

[williwaw]

will /mnt/sda1 be a valid location in the chroot?

the chroot is most useful for running the package manager. for instance xbps when you are working from a host that does not use void or have xbps installed.

if you are running klv, and you run xbps normally, it will of course install something in your host filesystem.
if you are running klv as a host and chroot into a directory, (presumably the rootfs for the build), and run xbps, it will install to that directory/rootfs, a container of sorts but with rudimentary isolation such that container is a poor choice of description.

without being in the chroot shell, the rootfs in your build directory is just like any other directory on the host, so if the path is correct on your host for the source directory, and you copy it to the correct path for your build in the rootfs dir, then making the edit to your build is just like any other operation.

so, if you run the scripts, but then decide to further modify the rootfs, (but say for instance, you are not able to yet boot or wish to get online) you can use chroot manually from the host at will.