Alien Pastures

My thoughts on Slackware, life and everything

Chromium source tarball availability

Someone asked how I am creating Chromium (also -ungoogled) packages these days? When you download my SlackBuild script and attempt to build the package yourself, the script will error out because it cannot download the sources.

For weeks now, the Google automation is broken with regards to creating Chromium source tarballs. Apparently some bug prevents their CI/CD pipelines from succeeding. This is reportedly fixed for the Chromium 132.x releases (currently their Beta versions) but Chromium 130 and now also 131 releases are announced without their accompanying source tarballs.
I have therefore created a script which fetches the needed stuff from git and packs that into a “chromium-$VERSION.tar.xz” tarball. You will find it in the “build” directory and it’s called “fetch-chromium-release.sh“. You run that script with a Chromium official version number, wait a long long time, and you end up with the 6+ GB source tarball which you can then move into your local “build” directory.

Hope that clarifies things and helps you compile chromium or chromium-ungoogled yourself.
Have fun! Eric

How I setup cgit for a browsable liveslak repository

I received a request to document how I configured the backend for https://git.liveslak.org/ . This is where my git repository for liveslak is accessible and browseable using cgit as the engine.
Of course the server is also running an actual git repository service which people use to clone the liveslak files and for me to upload changes.
Setting up git is not hard, but it’s beyond the scope of this blog article. Also, setting up Let’s Encrypt to create a secure (https) web site is not in the scope of this article but you can read my Let’s Encrypt article of course.

I’ll explain the steps that are needed to create a cgit webserver in the text below.
First we build and install cgit as well as its dependencies; then we create the cgit configuration and add some customization. Lastly we configure Apache httpd so that it knows what to serve.

Let’s start with building the required packages in order. In case you are running Slackware -current (i.e. newer than 15.0) then the lua package is already included in the core distro, so you can skip compiling it now:

  • lua
  • luacrypto
  • lua-md5
  • highlight
  • cgit

You can find build scripts for all of them on the SlackBuilds.org (SBo) web site.
The lua* and highlight packages are needed for syntax highlighting, and lua is also needed for gravatar support.
The cgit package has customization added by the SBo admins which we are going to use, notably support for displaying the committers’ gravatar images.

Once you have built and installed the above packages, create a new directory to hold our custom cgit stuff:

# mkdir -p /home/www/cgit

Create some symlinks to the files that were installed by the Slackware cgit package:

# ln -s /var/www/cgi-bin/cgit.cgi /home/www/cgit/
# ln -s /var/www/cgi-bin/cgit.js /home/www/cgit/
# ln -s /var/www/cgi-bin/cgit.png /home/www/cgit/

But make a copy, not a symlink, of the CSS file:

# cp -ia /var/www/cgi-bin/cgit.css /home/www/cgit/

Some additional CSS code needs to be added to cgit.css to make the committer avatars hover properly. Here’s the lines to append to the file copy we just made (you will find this same code in the file /usr/doc/cgit-*/email-gravatar-sbo-additions.css which is part of the Slackware cgit package):

div#cgit span.gravatar img.onhover {
    display: none;
    border: 1px solid gray;
    padding: 0px;
    -webkit-border-radius: 4px;
    -moz-border-radius: 4px;
    border-radius: 4px;
    width: 128px;
    height: 128px;
}
div#cgit span.gravatar img.inline {
    -webkit-border-radius: 3px;
    -moz-border-radius: 3px;
    border-radius: 3px;
    width: 13px;
    height: 13px;
    margin-right: 0.2em;
    opacity: 0.8;
}
div#cgit span.gravatar:hover > img.onhover {
    display: block;
    position: absolute;
    margin-left: 1.5em;
    background-color: #eeeeee;
    box-shadow: 5px 5px 3px #bbb;
}

We also need to tweak the syntax-highlighting.sh script (part of the cgit package) a bit so it works better for us Slackers.
Make a copy of it, removing all comments:

# grep -Ev '(#$|^ *#)' /usr/share/cgit/filters/syntax-highlighting.sh > /home/www/cgit/syntax-highlighting.sh
# chmod +x /home/www/cgit/syntax-highlighting.sh

And then add these lines right before the final ‘exec’ line of the script:

# map SlackBuild to .sh
[ "$EXTENSION" == "SlackBuild" ] && EXTENSION=sh

To make the git.liveslak.org website stand out from others, I substituted my own frontpage image and a custom favicon image. These are created as /home/www/cgit/eric_hameleers.png (link) and /home/www/cgit/erichameleers_favicon.ico (link) and both filenames are referenced further down in the cgit configuration.
By default, cgit will look for a file called “/etc/cgitrc” to read its configuration, but I am running multiple sites on a single Slackware host (git.slackware.nl for instance), therefore I create a separate cgit configuration file for each site. For liveslak, it is called “/etc/cgitrc.git.liveslak.org” and then I instruct Apache httpd to look for that particular filename.

/etc/cgitrc.git.liveslak.org

# For more options, see cgitrc.5.txt in the docs folder
root-title=Alien BOB's
root-desc=Web interface to liveslak git repository
virtual-root=/
snapshots=tar.gz tar.xz

summary-branches=10
summary-log=10
summary-tags=10

repository-sort=date
commit-sort=date
branch-sort=age

enable-blame=1
enable-index-links=1
enable-commit-graph=1
enable-follow-links=1
enable-log-filecount=1
enable-log-linecount=1
max-stats=quarter

mimetype-file=/etc/httpd/mime.types
mimetype.rss=application/rss+xml
enable-html-serving=1

css=/cgit.css
logo=/eric_hameleers.png
favicon=/erichameleers_favicon.ico

about-filter=/usr/share/cgit/filters/about-formatting.sh

# for this to work you have to build cgit against lua
# and install luacrypto too
email-filter=lua:/usr/share/cgit/filters/email-gravatar-sbo.lua

# For this to work, you need lua and highlight packages:
source-filter=/home/www/cgit/syntax-highlighting.sh

repo.url=liveslak
repo.path=/path/to/repositories/liveslak.git
repo.desc=Slackware Live Edition by AlienBOB
repo.owner=alien@slackware.com
repo.clone-url=git://liveslak.org/liveslak.git
repo.readme=:README.txt

The actual definition for the git repository is the lines at the end starting with “repo.“.

Lastly, the Apache web server needs to be configured to serve our cgit stuff whenever someone visits git.liveslak.org.
These are the files used to accomplish that:

/etc/httpd/extra/git.liveslak.org.conf

(just an example filename, you will know how and where to add the content for your specific Apache configuration):

<VirtualHost *:80>
    ServerName git.liveslak.org
    ServerAdmin alien@slackware.com

    CustomLog /var/log/httpd/git.liveslak.org_access_log combined
    ErrorLog /var/log/httpd/git.liveslak.org_error_log

    # Include Let's Encrypt configuration:
    Include /etc/httpd/extra/letsencrypt.conf

    # Include the site definition (AFTER Let's Encrypt configuration!!):
    Include /etc/httpd/extra/git.liveslak.org_content.conf
</VirtualHost>
<VirtualHost *:443>
    ServerName git.liveslak.org
    ServerAdmin alien@slackware.com

    CustomLog /var/log/httpd/git.liveslak.org-ssl_access_log combined
    ErrorLog /var/log/httpd/git.liveslak.org-ssl_error_log

    # Include Let's Encrypt configuration:
    Include /etc/httpd/extra/letsencrypt.conf

    # Include web server generic SSL configuration for vhosts:
    Include /etc/httpd/extra/ssl_vhost.conf

    # Include the site definition (AFTER Let's Encrypt configuration!!):
    Include /etc/httpd/extra/git.liveslak.org_content.conf
</VirtualHost>

The file “git.liveslak.org_content.conf” is included twice in the above VirtualHost definition file for Apache. Using these “Include” lines prevents some duplication of code.
Here is the content of that included file:

/etc/httpd/extra/git.liveslak.org_content.conf

DocumentRoot /home/www/cgit
Options FollowSymlinks

# Use a custom name for the configuration - default is /etc/cgitrc:
SetEnv CGIT_CONFIG /etc/cgitrc.git.liveslak.org

DirectoryIndex cgit.cgi
AllowOverride none
Require all granted

SetHandler cgi-script

Options ExecCGI
Require all granted

Alias /cgit.css /home/www/cgit/cgit.css
Alias /cgit.png /home/www/cgit/cgit.png
Alias /erichameleers_favicon.ico /home/www/cgit/erichameleers_favicon.ico
Alias /eric_hameleers.png /home/www/cgit/eric_hameleers.png
Alias /robots.txt /home/www/cgit/robots.txt
Alias / /home/www/cgit/cgit.cgi/

I hope that this story may help some of you with getting your own browseable git repository online.

Good luck, Eric

Slackware-current has absorbed my multilib gcc and glibc packages

Ever since the birth of 64-bit Slackware in 2009, I have been maintaining a multilib repository. Today, 15 years later, things are changing!

You may know it or not, depending on your age, but I have created 64-bit Slackware from scratch late 2008 and early 2009 as a project to deal with an inguinal hernia which was really painful, and the subsequent surgery caused me to be stuck to a bed for a while. I re-wrote the SlackBuild for every package in Slackware, and created SlackBuild scripts for a whole lot of other packages that had nothing more than a ‘build’ script. I also wrote all scripts in such a way that they were capable of building 32-bit and 64-bit Slackware from the same source. Pat would not have accepted the burden of having to maintain two trees instead of one.

Not everybody needs a multilib setup, but historically there has been a need, particularly to be able to run old proprietary programs that were available only as 32-bit binaries. And then there’s the whole Microsoft Windows ecosystem of 32-bit commercial programs and games, to be run in emulators such as Wine and a platform like Steam.

I had setup the 64-bit Slackware to be “multilib-ready”. It was a pure 64-bit system but by swapping a few packages (glibc and gcc) and adding a 32-bit compatibility layer, the 64-bit Slackware would be able to run and compile 32-bit binaries. That process has always been reversible too.
Pat was clear about his own goals: he wanted the new platform to be a pure 64-bit Slackware when he was going to publish it. I had no problem with that,  and thus alien’s multilib repository was born.

As said, this worked extremely well for the past 15 years. Pat would give me a heads-up whenever he was planning an upgrade to either the gcc or glibc packages, so that I would have time to prepare my own multilib versions and could release those on the heels of the official Slackware update.
Lately, Pat and me discussed our multilib collaboration occasionally and I saw his opinion shift bit-wise 🙂
Today, Pat has pushed an update to Slackware-current which effectively merges my multlib versions of gcc and glibc SlackBuild scripts with the official distro versions. This means that my own gcc and glibc multilib packages are obsolete, and I have removed them from the ‘current’ directory of the multilib repository.

In 64-bit Slackware-current you finally have multilib-capable gcc and glibc packages! All you need to add to Slackware64 now is my collection of ‘compat32’ packages. And if you want, use the massconvert32.sh script in my compat32-tools package to create these ‘compat32’ packages yourself. It does not involve any compilation – all that happens is that some official Slackware 32-bit packages are downloaded, cleaned-up a bit and then re-packaged into ‘-compat32’ versions.

Thanks Pat!

Respect all little bits

I finally figured out how to successfully compile the 32bit version of Chromium (and its un-Googled sibling) on Slackware, now that this requires the Rust compiler to build it. Pat added the final bits that I needed to the rust.SlackBuild script in Slackware recently.

Why did it take so long? Basically ‘real life’ intervened and I did not have time left to investigate.

I assume there may be one or two users left who use my 32bit Chromium package, the rest of you simply don’t care whether I can produce these 32bit packages or not. No one reached out and asked, can I help?
Prime example of slackers, right? It is what it is, and I respect that, and honestly I understand; there’s no fun in having to deal with all these Chromium developer assumptions that everyone uses Ubuntu. Kudos to the Ungoogled-chromium team however – they have been really helpful whenever I got stuck.

The bottom-line is, that I will resume my builds of a 32bit version of Ungoogled Chromium, once per month, for Slackware 15.0 and -current, until the process breaks again and then it’s goodbye to 32bit Ungoogled Chromium.
In any case, there will not be further 32bit packages for the regular Chromium browser going forward. I will remove the existing 32bit chromium packages from my repository because I want to prevent people downloading a vulnerable browser.

Eric

Update – I have uploaded 32bit packages:

+--------------------------+
Mon Aug 12 20:13:12 UTC 2024
chromium-ungoogled: updated 32bit to 127.0.6533.99 (Slackware 15.0 & onwards).
  If your browser keeps crashing with seccomp errors, add this as startup
  parameter: "--disable-seccomp-filter-sandbox".
  For reference: https://alien.slackbook.org/blog/chromium-90-packages-again-32bit-related-issues/

VLC 3.0.21 packaged for Slackware

largeVLCI received reports that my vlc.SlackBuild script failed to create a package on Slackware-current.

So I took the opportunity to not just fix the build failure but also to update the VLC version and that of several internal libraries (libbluray, dav1d, ffmpeg, matroska and libvpx).
And now I have uploaded packages for VLC 3.0.21, targeting Slackware 15.0 and -current.

A note about dependencies for the new package:

My Slackware packages for VLC are mostly self-contained with many of the supporting libraries compiled into the package. This makes for a minimal dependency on external libraries/packages; a full installation of Slackware covers it all.
Apart from having no external dependencies, the other reason for statically compiling libraries into VLC that are also present in regular Slackware (specifically ffmpeg, lame, speex, theora, libvpx) is to avoid the risk of breakage of my vlc package due to incompatible library updates in a Slackware release (that happens once in a while on Slackware-current for instance).

A note on compiling:

When you want to compile VLC 3 yourself, be sure to install java11 (or newer) and apache-ant or your build will fail.

Where to find the new VLC packages:

Rsync access is offered by the mirror servers.
The patent-safe packages are found at rsync://slackware.nl/mirrors/people/alien/slackbuilds/vlc/ and rsync://us.slackware.nl/mirrors/people/alien/slackbuilds/vlc/ .
The restricted versions that support AAC encoding and encrypted DVD playback are available from rsync://slackware.nl/mirrors/people/alien/restricted_slackbuilds/vlc/

For BluRay support, read a previous article for hints about the aacs keys that you’ll need.

Enjoy! Eric

« Older posts

© 2024 Alien Pastures

Theme by Anders NorenUp ↑