The issue is that gnome on wayland doesnt source the /etc/profile script so the LANG= variable doesn't get set properly in a gnome/wayland session. It needs to be set to a UTF locale like LANG=en_US.UTF-8 for gnome-terminal to work. You'll need a way to set it at login if you want to use gnome on wayland.

The simplest option is to use gnome on Xorg, which you can choose at the gdm screen by clicking the menu with the "gear" icon. The Xorg session sources /etc/profile so LANG is set properly.

The other option is "blocaled", which is BLFS's version of the systemd locale dbus service. The problem with it is that it looks for systemd config files that are not present on slackware, so I made a script to "generate" these files from their relevant profile scripts on slackware. I have a slackbuild and said script here, if you want to test it: https://github.com/0xBOBF/gnome-slac...uilds/blocaled

It isnt on slackbuilds.org, because I still would like to try testing some other methods. See this page for some more info: https://wiki.gnome.org/Initiatives/Wayland/SessionStart

2 members found this post helpful.

Also I should mention now. The intent of this post was to point out the slackbuilds for slackware 15.0 on slackbuilds.org.

The gnome-42 repo thats been mentioned here was not something I was planning on discussing or directing people toward, and those builds are not on slackbuilds.org.

My reason is that gnome-42 has problems in that slackware-15.0, and slackware-current come with libraries that are too old for the builds in gnome-42. This means that a number of core libraries need to be upgraded to even build gnome-42. This is problematic, particularly on current, which upgrades regularly from Pat and can overwrite/revert those libraries and break things. I wouldnt recommend trying gnome-42 from that repo unless you are very comfortable with managing packages, well versed with what comes with slackware and keeping an eye on the changelog, and enjoy big rebuilds of gnome software after each big update in -current. Just remember how often ktown would need rebuilds, except here the rebuild is on the user to do...

1 members found this post helpful.

Even though you didn't intend to, I appreciate sharing project link here. I did notice that some core packages will need to be replaced in -stable. That's okay with me though. I really do appreciate the work done here. Looking forward to how this project will evolve.

Another thing I wanted to add, your instructions taught me something new about how to add additional repos to sbopkg. So I am learning something new. I have tried building Gnome many times and I know how much of a pain it is. The fact that you have this so well documented is a testament to your dedication (and the rest of the team).

1 members found this post helpful.

I had started with the gnome-42 repo and the intention of submitting those to slackbuilds.org. However, that project ran into too many required library upgrades to make it viable for that purpose so I switched to the slackware-15.0 repo and built gnome around what software versions were available in slackware and slackbuilds.org.

I was using my repo combined with slackbuilds.org's repo to test if the full build would work before submitting. I wasnt planning on doing that type of build long term, since the idea was to submit the builds to SBo. Its fine for the guys developing there, but not something I was trying to get people to use.

Thanks for trying the build out though. I've been using the desktop on 15.0 for a few months now and its been running smooth, other than the odd thing like that locale issue in wayland. Always nice to have other people testing and verifying the software too.

2 members found this post helpful.

These are always learning experiences for me. This is one of the many things that I love about Slackware. Getting in there and building things from source always gives you a better understanding how things work. I have the ability to test things if you would like. I have a couple of robust servers that I use to build things with icecream.

1 members found this post helpful.

A bit of an update:

Setting environment variables before processing the build queue with 'sbopkg' is no longer required. The maintainer of those packages enabled building the introspection and vala bindings by default so the variables are not needed anymore. Now to build the gnome-all.sqf queue just requires downloading the queue file and running it with sbopkg (make sure sbopkg is refreshed with the latest versions using "sbopkg -r").

I updated the instructions on the first post so it is still relevant: https://www.linuxquestions.org/quest...0/#post6367607

Thanks to Ozan for making those changes and letting this build flow a little smoother.

2 members found this post helpful.

@0XBF

Excuse my ignorance, but I should assume that all packages are on slackbuilds org and all I have to do is to execute this queue file?

Secondly, how much /tmp storage space and system memory requires this build of yours?

It' enough 2GB on /tmp? I ask this because my /tmp is on a zram device, hence a tmpfs. I have also 4GB memory and an Intel Atom x5-Z8350 which is a quad core at 1.92GHz, but I'm not really picky about build time.

Yes that is the idea. The queue file builds the deps and main packages from slackbuilds.org to build a GNOME40/41 desktop. I skipped packaging some of the extra gnome software projects because that was too many things to take on, but the core desktop experience is there. The GNOME version is also a little older, that was intentional so it could be built on top of stock slackware libraries in 15.0.

One thing to note: You will have to make the users and groups noted in the first post before starting the build, since the colord and avahi SlackBuilds expect those users/groups and will exit if they are not detected.

At the end of processing the build queue my /tmp grew to 4.0GB in size. 3.8GB of that is in /tmp/SBo, the rest is the completed packages in /tmp. 4.0GB would be tight, I would suggest padding that with some extra space to be safe.

Build time with a low spec machine will definitely take a while, with webkit2gtk taking the longest by far, probably longer than 12 hours just for webkit2gtk. I used a higher powered build machine and distributed the packages to my weaker laptops after, but not everyone has that luxury.

HTH

3 members found this post helpful.

I did not used (yet) this particular Gnome4 build, but from what I know after my past experiments with Gnome4, to build those packages does not requires that much memory.

So, considering what @0XBF said regarding the space required for building this particular packages set and what I know regarding your Slackware-on-SD-card setup, I suggest you to temporary increase the size of ZRAM device which is mounted in /tmp to 5GB or 6GB - which is possible, because the data is compressed and real memory consumption would be less than 3GB, and to run the build in runlevel 3 to minimize other memory usages.

Probably once in runlevel 3, if you use a WiFi connect, before starting the build you will need to use NetworkManager's console utility /usr/bin/nmtui to connect to your WiFi access point.

To minimize even more the storage space used for building, you can build this on 2 steps, first building gnome-basic queue, clean the /tmp then building the full one skipping the packages already built, with the "-k" parameter on sbopkg call - there may be needed a confirmation from @0XBF (or other associated developer) , that gnome-basic is truly a subset of same packages which are built with gnome-full queue.

1 members found this post helpful.

You don't execute a queue file. You'll load it into sbopkg's default queue directory (/var/lib/sbopkg/queues/) and then you can use sbopkg to build that queue in the correct order.

I imagine you know this, but with how you asked it, I figured I'd clarify for any others who see this.

Another option is to either pass CLEANUP=yes to sbopkg or change that option in /etc/sbopkg/sbopkg.conf. This will cause sbopkg to delete the extracted source folder and packing directories (it will still keep the source and resulting package). Using this method, you might be able to keep it under 2GB, provided no programs have monstrous sized build directories.

7 members found this post helpful.

The "gnome-basic.sqf" queue is the minimum packages to get a functional desktop with gnome extensions. There are some differences between the queue file's ordering compared to gnome-all.sqf, so it will not be the same if you start with gnome-basic and then switch to gnome-all. If you want to split the build, just edit the gnome-all.sqf file into two queues and process it in two parts. Or, use the CLEANUP=yes option that bassmadrigal mentioned (I haven't tried that myself).

3 members found this post helpful.

WHAT? Where's the Gnome Media Player? And Gnome4 have a nice one!

@0XBF, you don't watch videos?

Monsieur, a Media Player is a fundamental application!

You know well, the people buys computers for music, videos and Facebook. And torrents - note that I do not talk about the Slackware ISOs here.

1 members found this post helpful.

You forgot Twitter and TikTok.

1 members found this post helpful.

Well, in other hand, this Gnome4 build works. Thanks to you guys for bringing this old pal of mine to Slackware.

I used the gnome-all queue and it did the job. Of course, I added manually all changes reccomented by @0XBF for users and rc scripts. So, now posting from Wayland/Gnome4 which is the default session, as I expected.

And good news for you @ZhaoLin1457, seems like the biggest /tmp storage consumption is around 1GB when is used CLEANUP option for sbopkg, and this one is the webkitgtk package.

However, two issues to report:

1. the gnome-terminal (Terminal) acts crazy (illegible console) unless you chose a custom color scheme for it.

2. I'm pretty sure that Gnome4 is fully capable to restore the previous open applications on sessions - both in Wayland and X11, both in Ubuntu and OpenSUSE. This Gnome build did NOT.

True, there's a little config change to activate the restoring the applications on sessions, and there's a guide:

https://vitux.com/how-to-automatical...ion-in-debian/

2 members found this post helpful.

I have increased the zram device to 3GB and I use the cleanup option for sbopkg. Until now, the build goes fine. My Atom x4 behaves surprising decently at full load, and I'm able to do a small browsing while this build runs.