LinuxQuestions.org - Requests for -current (14.2-->15.0)

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Requests for -current (14.2-->15.0) (https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/)

Quote:

Originally Posted by upnort (Post 5897680)

My experience and observation is issues rarely surface immediately but tend to pop up days or weeks later. Tough to test that kind of thing. :)

That's why you hold onto the older versions manually.

Quote:

Originally Posted by upnort (Post 5897680)

Possibly that is how the main Slackware repo could be maintained. Actually, I think that is a great idea. :) Would be interesting if somebody tested whether slackpkg can handle multiple versions of the same package in /patches.

This would need to propagate out to all mirrors and everyone who syncs a mirror (I have 64bit -current and 14.2 synced on my machine and I'd rather not keep all those older packages chewing up all my space).

You could use Alien Bob's mirror-slackware-current.sh script and modify the rsync commands to not delete old content when they sync. This would allow you to keep your own local mirror that has all the extra packages without burdening everyone who maintains their own Slackware tree with all that extra space being chewed up for packages they're likely to never touch.

Quote:

Originally Posted by upnort (Post 5897680)

My experience and observation is issues rarely surface immediately but tend to pop up days or weeks later. Tough to test that kind of thing. :)

Can you please document even a single occurrence where a patch package in a stable release of Slackware caused an issue and the package had to be reverted?
Note: I am not talking about breakage caused by customization of a package (for instance by changing a configuration file in such a way that a newer version of the package stumbles over your custom settings).

Quote:

Can you please document even a single occurrence where a patch package in a stable release of Slackware caused an issue and the package had to be reverted?

I mentioned that in a previous post: a Samba package. I also mentioned that such occurrences are rare. :) I browsed through the change logs. I think the specific event I am recalling was in 10.2 (Jul 14/18, 2006). I seem to recall one or two other patches that broke something, but I do not remember them specifically. :(

Yet even in such rare events, there have been times when there is breakage with kernel updates and reverting helps debug issues. That happened with me recently. Another example of a kernel regression. Typically Slackware does not see frequent kernel patches. Thus, when a kernel update occurs, often there are significant jumps in what was patched in the kernel and sometimes things break despite Linus's hard rule about not breaking user space. :)

Quote:

Originally Posted by Alien Bob (Post 5897701)

Can you please document even a single occurrence where a patch package in a stable release of Slackware caused an issue and the package had to be reverted?

Not exactly, but yes.

I generally agree though and the above is a rare occurrence. :)

virtuoso rebuild needed

Hi, :D

I would like to report that virtuoso-ose needs rebuild because of the SSL version change, it seems to be looking for some old cipher, I found the problem on some KDE apps, for example dolphin and ark, when you want to replace a file on a remote file system lets say fish, smb or from ark to dolphin the app receives a segfault with message:

Code:

140478970582976:error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers:ssl/ssl_lib.c:2592:

Since I don't use nepomuk my solution was to remove virtuoso and the problem is gone, but I leave the comment in case someone else has this problem, I notice this issue a few weeks ago on all my KDE desktops.

Thank for your support! :hattip:

Note: For the people complaining about the Slackware way of doing things :rolleyes:, my :twocents: the good thing about it is that there is no impose way to do something, it is vanilla!

IMHO :p Slackware "stable" or "current" are both stable, I've been using Slackware for more than 10 years and I used to use stable releases on production servers and current on desktops, however since current usually offer new features when is getting ready I use current for my production servers.

Slackware is ready for enterprise, I have a Active Directory cluster with samba in slackware-current working perfectly and I just recompiled bind with krb5 and everything has been working fine (I read Samba official documentation and everything works as expected), I even let the server working by 3 years with no maintenance and it never had any issue, I also have MariaDB with galera and maxscale and postfix, dovecot, opendkim and some other things that make my life easier as an IT professional, so my recommendation is that if you want to try something new you need to be willing to learn! :study:

I tell you for me is difficult use another distro :confused: :banghead: (and I had tried a lot) where they have a "unique" way of do things, on Slackware I had used manuals and documentation for other distros and it still apply you only need to know your product! :cool:

Hope this helps!

Quote:

Originally Posted by orbea (Post 5897716)

Not exactly, but yes.

I generally agree though and the above is a rare occurrence. :)

That package you refer to (librsvg update in Slackware 14.2 on August 4) is not an example of what I asked:

Code:

+--------------------------+

Sat Aug  4 06:38:01 UTC 2018

patches/packages/librsvg-2.40.20-i586-1_slack14.2.txz:  Upgraded.

  This update fixes a regression when using libxml2-2.9.5 that causes some

  .svgz files to not be handled properly. Thanks to SeB.

What I was referring to, is that there is no occurrence where a patch-package in a stable release of Slackware had to be reverted because it broke some functionality. The case with librsvg is not a revert. It is the logical consequence of an earlier package upgrade in Slackware 14.2 patch section:

Code:

+--------------------------+

Sat Sep 23 01:02:32 UTC 2017

patches/packages/libxml2-2.9.5-i586-1_slack14.2.txz:  Upgraded.

  This release fixes some security issues

... after which librsvg needed to be upgraded as well to fix some compatibility issues.
Nothing was reverted to an earlier patch package release. Just updates here. Reverts would only occur in the unstable tree (slackware-current) and even that does not happen often. And we were not talking about -current in the context of this discussion.

I don't disagree with you, but I pointed it out because it is an example of a regression caused by upgraded patch-package (libxml). Reverting libxml like you said was not necessary since upgrading librsvg worked fine instead.

--Off-topic--
Here is my R$ 0,02 (R$ 1 ~ US$ 0.24):
What about to create another topic called "Discussion about -current (14.2-->15.0)", and move there all posts that are not exactly "requests for -current"?
To be honest, I like the fact that people are asking for a lot of things that are not part of the Slackware way. IMHO, it is a kind of feedback from users. And Patrick can use it any way he wants, if he wants.

Pat,

How about a policy that all updated /etc files -- including rc.d scripts -- get installed as *.new files? Currently there is no consistency or policy. Sometimes users need to change the rc.d scripts. Several doinst.sh scripts clobber those changes.

Along with that is moving all rc.d script parameters and variables to /etc/default files. Doing that would much reduce the need to modify rc.d scripts.

I am ready to help and test if you like the ideas.

Thanks. :)

Quote:

Originally Posted by Fellype (Post 5897989)

There has been a bit of noise in here, yes, but I don't see starting another thread as helpful. I'm fine with everything in one place.

Add some of the nifty slackware scripts like slack-script, slack-utils, slackchlog to the extra folder (That is if the maintainer OKs it). Alternatively a contrib folder. This would make these useful utilities more available than now to users and possibly inspire to produce more external contribution scripts.

Quote:

Alternatively a contrib folder.

A /contrib tree sounds interesting. That would distinguish what Pat officially supports in /extra from other useful community utilities. Conversely, the idea ties into the overall discussion in other threads about how to consolidate third-party repos and utilities. :)

Quote:

Originally Posted by jostber (Post 5898074)

For those curious like I was:

I couldn't find anything on slack-script (my google-fu failed me).

Quote:

Originally Posted by bassmadrigal (Post 5898106)

For those curious like I was:

I couldn't find anything on slack-script (my google-fu failed me).

The slack-scripts are here:

http://dawoodfall.net/scripts/slackware/

Also available as a slackbuild:

https://slackbuilds.org/repository/1...slack-scripts/

Hey Pat. I'd be happy to help update the vulkan-sdk SlackBuild, but first I have questions about how you want the source prepared. Do you just need it to be buildable offline (easy), or do you need each source to be a separate archive (more annoying)?

And do you still need SPIRV to be a separate source archive? If so, that would be extra challenging.

Also: adding jq to Slackware has the potential to make some of this a lot easier.

Quote:

Originally Posted by dugan (Post 5898266)

Don't we already have the latest release?

Quote:

Also: adding jq to Slackware has the potential to make some of this a lot easier.

Really?

Quote:

Originally Posted by dugan (Post 5898266)

Ideally sources shouldn't be prepared, they should be how upstream distributes them. It's the same with the current script. All "fetch-sources.sh" does is help figuring out which sources we need to fetch.

Quote:

Originally Posted by dugan (Post 5898266)

And do you still need SPIRV to be a separate source archive? If so, that would be extra challenging.

What sources we need is largely dictated by how upstream wants us to build. Currently the headers are separate because that's how upstream structured it.

Quote:

Originally Posted by dugan (Post 5898266)

Also: adding jq to Slackware has the potential to make some of this a lot easier.

I'm assuming you're referring to the json data extraction in "fetch-sources.sh". I don't think we need to add a new package just to add more convenience to a convenience script.

Quote:

Originally Posted by volkerdi (Post 5898291)

Don't we already have the latest [vulkan-sdk] release

Nope. It's at 11.8.2.0 now (that's also what the binary package is at) and the source code repository has been restructured.

They've split their old repo (info about that is at their old repo):

https://github.com/KhronosGroup/Vulk...lidationLayers

It's pretty much moved here:

https://github.com/KhronosGroup/Vulkan-ValidationLayers

Quote:

How about a policy that all updated /etc files -- including rc.d scripts -- get installed as *.new files? Currently there is no consistency or policy. Sometimes users need to change the rc.d scripts. Several doinst.sh scripts clobber those changes.

In a directory containing all the doinst.sh files in the source for Slackware64-current

Code:

grep -rL md5sum > /tmp/list; while read aline; do grep -q "\.new" $aline && echo $aline; done < /tmp/list

returns

Quote:

ap/texinfo/doinst.sh
ap/alsa-utils/doinst.sh
a/bash/doinst.sh

To me, these are the only scripts that install .new files that do not contain code like

Code:

config() {

  NEW="$1"

  OLD="$(dirname $NEW)/$(basename $NEW .new)"

  # If there's no config file by that name, mv it over:

  if [ ! -r $OLD ]; then

    mv $NEW $OLD

  elif [ "$(cat $OLD | md5sum)" = "$(cat $NEW | md5sum)" ]; then # toss the redundant copy

    rm $NEW

  fi

  # Otherwise, we leave the .new copy for the admin to consider...

}

I do not see any clobbering.

Quote:

Originally Posted by jostber (Post 5898179)

The slack-scripts are here:

http://dawoodfall.net/scripts/slackware/

Also available as a slackbuild:

https://slackbuilds.org/repository/1...slack-scripts/

Thanks! I'm not sure why that google search didn't turn anything up. I'll have to look into these.

Quote:

Originally Posted by allend (Post 5898476)

To me, these are the only scripts that install .new files that do not contain code like
[...]
I do not see any clobbering.

What about these:

httpd:

Code:

# Keep same perms when installing rc.httpd.new:

preserve_perms etc/rc.d/rc.httpd.new

# Always install the new rc.httpd:

mv etc/rc.d/rc.httpd.new etc/rc.d/rc.httpd

openssh:

Code:

preserve_perms etc/rc.d/rc.sshd.new

if [ -e etc/rc.d/rc.sshd.new ]; then

  mv etc/rc.d/rc.sshd.new etc/rc.d/rc.sshd

fi

dbus:

Code:

#config etc/rc.d/rc.messagebus.new

# No, just install the thing.  Leaving it as .new will only lead to problems.

if [ -r etc/rc.d/rc.messagebus.new ]; then

  mv etc/rc.d/rc.messagebus.new etc/rc.d/rc.messagebus

fi

eudev:

Code:

# There's no reason for a user to edit rc.udev, so overwrite it:

if [ -r etc/rc.d/rc.udev.new ]; then

  mv etc/rc.d/rc.udev.new etc/rc.d/rc.udev

fi

Personally I don't have a problem with dbus and eudev, but I'm using modified rc files for httpd and openssh that I have to restore after every update. :(

The only doinst.sh scripts that do not create /etc/rc.d/rc.*.new are:
ap/sysstat/doinst.sh (# There's no reason for a user to edit rc.sysstat, so overwrite it:)
ap/alsa-utils/doinst.sh
a/dbus/doinst.sh (# No, just install the thing. Leaving it as .new will only lead to problems.)
a/eudev/doinst.sh (# There's no reason for a user to edit rc.udev, so overwrite it:)
n/openssh/doinst.sh
n/httpd/doinst.sh

So, should we have?
httpd:

Code:

# Always install the new rc.httpd:

mvconfig etc/rc.d/rc.httpd.new etc/rc.d/rc.httpd

openssh:

Code:

mvconfig etc/rc.d/rc.sshd.new etc/rc.d/rc.sshd

and alsa-utils/doinst.sh updated to allow for the 'config' treatment.

While we're on a subject of initscripts - I'd love if steps in them were factored out to separate scripts with the order enforced by naming convention (kinda like you had in CentOS5 days), so for example the way rc.M does things now:

Code:

...

start pcmcia

start syslog

update font cache

start udev again

start haveged

start rngd

...

it would be something like

Quote:

20Spcmcia -> /etc/rc.d/rc.pcmcia
25Ssyslog -> /etc/rc.d/rc.syslog
30Sfccache -> /etc/rc.d/rc.fc-cache
35Sudev -> /etc/rc.d/rc.udev
40Shaveged -> /etc/rc.d/rc.haveged
40Srngd -> /etc/rc.d/rc.rngd

This would help with local customizations to the boot process - ie. I have a 3rd-party service that should be best started in the middle of rc.M. My choice now is either to add it to rc.local instead (and then always remove rc.local.new on sysvinit-scripts update), or put it where it should be, in rc.M, but then every time sysvinit-scripts is updated I need to merge my changes.
It would also help maintaining Slackware inside LXC containers, where you don't want to run certain parts of "normal" startup sequence - and you can't simply chmod -x things, because they're not separate rc scripts.

@shastah

For using your custom scripts you have yet another option: to use the SYSV init support shipped by Slackware. ;)

BUT, yes. Also myself I hit on this need to start a custom init script in the middle of boot flow, and the perfect solution will be a move of boot-scripts to SYSV method, where you control the position where the script is started/stopped for every runlevel.

However, I do not think that Slackware will ever move fully to SYSV method because here will be street riots. :p

Quote:

Originally Posted by shastah (Post 5898617)

My choice now is either to add it to rc.local instead (and then always remove rc.local.new on sysvinit-scripts update)

Just a thought, but maybe it would be better if rc.local.template was installed instead of rc.local.new and users would simply copy it once instead of remove rc.local.new everytime?

In a previous post in this thread I suggested some kind of change that would help users revert to previous packages. Today an example appeared in this forum.

This is not "I told you so." :) Only an example of why finding access to previous packages should be easier from within the Slackware package tree and not third-party repos or web sites. I like the idea of moving previous /patches packages to /pasture.

This also raises the point discussed elsewhere about updating the kernel. Updating the kernel should not be all-or-nothing or do-or-die. At least one previous kernel should always be retained and the boot loader config updated to boot to the newer kernel but allow booting to previous kernels.

While there are several forum discussions recommending users use installpkg to install new kernels rather than upgradepkg, and that updating kernels should be disabled in slackpkg, this current practice is part of the recent discussions about how to improve Slackware. Most (probably all) other distros retain at least one previous kernel when updating. Most if not all allow configuring how many previous kernels to retain. If Slackware is going to cater to enterprise users then I think directly supporting the retention of previous kernels is a sane practice and policy to adopt within Slackware. :)

Quote:

So, should we have?....

Yes. Many people modify the default rc.d scripts. My original point was not how many doinstall.sh scripts need updating but that a policy should be adopted where a *.new file is not automtically moved. Let the user compare changes and let the user control the system.

Quote:

This would help with local customizations to the boot process - ie. I have a 3rd-party service that should be best started in the middle of rc.M.

I too have had occasions for modifying rc.d scripts in that manner. I don't have a solution to propose but my leaning is that users should rarely have to modify the original scripts. I much like the simplicity of the Slackware init script design, but other options should support modifying the boot/shutdown sequence and rc.local[_shutdown] is not always optimal. :)

Quote:

Just a thought, but maybe it would be better if rc.local.template was installed instead of rc.local.new

A nice idea. :) I also would like to see rc.firewall.template and inside that script would be a link to http://www.slackware.com/~alien/efg/.

Just to remember that not long time ago I proposed two solutions for improving the handling of kernels - as in keeping the previous kernels alive:

1. To use in the kernel packages the concept of "incoming" folder to store the essential files (and moving them from the sight of removepkg), then them to be moved on final place by post-install script.

This proposal was refused because it complicate the life of our honorable Gurus, who eventually should remove in a manual way those files.

2. To modify the upgradepkg to actively refuse to upgrade the "kernel-X" packages, and just to install them. A small change on upgradepkg with advantage that later the user can uninstall the old kernel packages with "removepkg"

This proposal was refused by our BDFL, as it being out of scope of "upgradepkg" for now and ever.

Quote:

Originally Posted by orbea (Post 5898712)

Just a thought, but maybe it would be better if rc.local.template was installed instead of rc.local.new and users would simply copy it once instead of remove rc.local.new everytime?

No need for a .template, really. Instead, in doinst.sh, simply skip copying rc.local.new if rc.local already exists.

Anyway - handling rc.local.new is trivial, I know I can *always* remove it when upgrading sysvinit-scripts. It's the other .new files I have problems with :)

Quote:

Originally Posted by upnort (Post 5898762)

This would be almost trivial if slackpkg could handle >1 repo... :)

Code:

current-main http://mirror.example.com/slackware/slackware64-current/

current-pasture http://mirror.example.com/slackware/slackware64-current/

and then implementing something like

Code:

# downgrade to previous ("N-1") version - or a dialog menu with selection of all prior versions

root@host:~# slackpkg downgrade <pkgname>



# downgrade to specific version

root@host:~# slackpkg downgrade <pkgname>-<version>-<arch>-<build>

Here's my contribution for a vulkan-sdk update to 1.1.82.0. I've put it through a reasonable amount of testing (I've built RetroArch against it, set it to use Vulkan and a slang shader, ran a game, and made sure the shader effect was applied. I've also confirmed that it builds on a clean system).

Here's fetch-sources.sh

Code:

#!/bin/sh



# Copyright 2017  Patrick J. Volkerding, Sebeka, Minnesota, USA

# All rights reserved.

#

# Redistribution and use of this script, with or without modification, is

# permitted provided that the following conditions are met:

#

# 1. Redistributions of this script must retain the above copyright

#    notice, this list of conditions and the following disclaimer.

#

#  THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED

#  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF

#  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO

#  EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,

#  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,

#  PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;

#  OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,

#  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR

#  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF

#  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.



# Call this script with the version of the Vulkan-LoaderAndValidationLayers-sdk

# that you would like to fetch the sources for. This will fetch the SDK from

# github, and then look at the revisions listed in the external_revisions

# directory to fetch the proper glslang, SPIRV-Headers, and SPIRV-Tools.

#

# Example:  VERSION=1.1.82.0 ./fetch-sources.sh



VERSION="1.1.82.0"



rm -rf Vulkan-*-*.tar.gz glslang* SPIRV-Tools* SPIRV-Headers*



lftpget https://github.com/KhronosGroup/Vulkan-Headers/archive/sdk-${VERSION}/Vulkan-Headers-sdk-${VERSION}.tar.gz

lftpget https://github.com/KhronosGroup/Vulkan-ValidationLayers/archive/sdk-${VERSION}/Vulkan-ValidationLayers-sdk-${VERSION}.tar.gz

lftpget https://github.com/KhronosGroup/Vulkan-Loader/archive/sdk-${VERSION}/Vulkan-Loader-sdk-${VERSION}.tar.gz

lftpget https://github.com/KhronosGroup/Vulkan-Tools/archive/sdk-${VERSION}/Vulkan-Tools-sdk-${VERSION}.tar.gz





GLSLANG_COMMIT=$(python3 - << EOF

import json

import tarfile

with tarfile.open('Vulkan-ValidationLayers-sdk-$VERSION.tar.gz') as layers:

        known_good = layers.extractfile('Vulkan-ValidationLayers-sdk-1.1.82.0/scripts/known_good.json')

        known_good_info = json.loads(known_good.read())

glslang = next(repo for repo in known_good_info['repos'] if repo['name'] == 'glslang')

print(glslang['commit'])

EOF

)



git clone https://github.com/KhronosGroup/glslang.git

cd glslang || exit

git checkout "$GLSLANG_COMMIT"

GLSLANG_VERSION=$(git rev-parse --short HEAD)

rm -rf .git

cd ..



mv glslang "glslang-$GLSLANG_VERSION"



SPIRV_TOOLS_COMMIT=$(python3 - << EOF

import json

with open('glslang-$GLSLANG_VERSION/known_good.json') as f:

        known_good = json.load(f)

tools = next(commit for commit in known_good['commits'] if commit['name'] == 'spirv-tools')

print(tools['commit'])

EOF

)



git clone https://github.com/KhronosGroup/SPIRV-Tools.git

cd SPIRV-Tools || exit

git checkout "$SPIRV_TOOLS_COMMIT"

SPIRV_TOOLS_VERSION="$(git rev-parse --short HEAD)"

rm -rf .git

cd - || exit

mv SPIRV-Tools "SPIRV-Tools-$SPIRV_TOOLS_VERSION"

tar -cvvf "SPIRV-Tools-$SPIRV_TOOLS_VERSION.tar" "SPIRV-Tools-$SPIRV_TOOLS_VERSION"

rm -rf "SPIRV-Tools-$SPIRV_TOOLS_VERSION"

plzip "SPIRV-Tools-$SPIRV_TOOLS_VERSION.tar"



SPIRV_HEADERS_COMMIT=$(python3 - << EOF

import json

with open('glslang-$GLSLANG_VERSION/known_good.json') as f:

        known_good = json.load(f)

name = 'spirv-tools/external/spirv-headers'

headers = next(commit for commit in known_good['commits'] if commit['name'] == name)

print(headers['commit'])

EOF

)



git clone https://github.com/KhronosGroup/SPIRV-Headers.git

cd SPIRV-Headers || exit

git checkout "$SPIRV_HEADERS_COMMIT"

SPIRV_HEADERS_VERSION="$(git rev-parse --short HEAD)"

rm -rf .git

cd - || exit

mv SPIRV-Headers "SPIRV-Headers-$SPIRV_HEADERS_VERSION"

tar -cvvf "SPIRV-Headers-$SPIRV_HEADERS_VERSION.tar" "SPIRV-Headers-$SPIRV_HEADERS_VERSION"

rm -rf "SPIRV-Headers-$SPIRV_HEADERS_VERSION"

plzip "SPIRV-Headers-$SPIRV_HEADERS_VERSION.tar"



tar -cvvf "glslang-$GLSLANG_VERSION.tar" "glslang-$GLSLANG_VERSION"

rm -rf "glslang-$GLSLANG_VERSION"

plzip "glslang-$GLSLANG_VERSION.tar"

And here's vulkan-sdk.SlackBuild:

Code:

#!/bin/bash



set -e



# Slackware build script for vulkan-sdk



# Copyright 2016, 2017  Heinz Wiesinger, Amsterdam, The Netherlands

# Copyright 2016, 2017, 2018  Patrick J. Volkerding, Sebeka, MN, USA

# All rights reserved.

#

# Redistribution and use of this script, with or without modification, is

# permitted provided that the following conditions are met:

#

# 1. Redistributions of this script must retain the above copyright

#    notice, this list of conditions and the following disclaimer.

#

# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ''AS IS'' AND ANY EXPRESS OR IMPLIED

# WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF

# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO

# EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,

# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,

# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;

# OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,

# WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR

# OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF

# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.



cd $(dirname $0) ; CWD=$(pwd)



PKGNAM=vulkan-sdk

VERSION=${VERSION:-$(echo Vulkan-ValidationLayers-sdk-*.tar.?z | rev | cut -f 3- -d . | cut -f 1 -d - | rev)}

BUILD=${BUILD:-1}



NUMJOBS=${NUMJOBS:--j7}



# Automatically determine the architecture we're building on:

MARCH=$( uname -m )

if [ -z "$ARCH" ]; then

  case "$MARCH" in

    i?86)    export ARCH=i586 ;;

    armv7hl) export ARCH=$MARCH ;;

    arm*)    export ARCH=arm ;;

    # Unless $ARCH is already set, use uname -m for all other archs:

    *)      export ARCH=$MARCH ;;

  esac

fi



# If the variable PRINT_PACKAGE_NAME is set, then this script will report what

# the name of the created package would be, and then exit. This information

# could be useful to other scripts.

if [ ! -z "${PRINT_PACKAGE_NAME}" ]; then

  echo "$PKGNAM-$VERSION-$ARCH-$BUILD.txz"

  exit 0

fi



if [ "$ARCH" = "i586" ]; then

  SLKCFLAGS="-O2 -march=i586 -mtune=i686"

  LIBDIRSUFFIX=""

elif [ "$ARCH" = "s390" ]; then

  SLKCFLAGS="-O2"

  LIBDIRSUFFIX=""

elif [ "$ARCH" = "x86_64" ]; then

  SLKCFLAGS="-O2 -fPIC"

  LIBDIRSUFFIX="64"

elif [ "$ARCH" = "armv7hl" ]; then

  SLKCFLAGS="-O2 -march=armv7-a -mfpu=vfpv3-d16"

  LIBDIRSUFFIX=""

else

  SLKCFLAGS="-O2"

  LIBDIRSUFFIX=""

fi



TMP=${TMP:-/tmp}

PKG=$TMP/package-vulkan-sdk



GLSLANG_VERSION=$(echo glslang-*.tar.?z | rev | cut -f 3- -d . | cut -f 1 -d - | rev)

SPIRV_HEADERS_VERSION=$(echo SPIRV-Headers-sdk-*.tar.?z | rev | cut -f 3- -d . | cut -f 1 -d - | rev)

SPIRV_TOOLS_VERSION=$(echo SPIRV-Tools-*.tar.?z | rev | cut -f 3- -d . | cut -f 1 -d - | rev)



rm -rf $PKG

mkdir -p $TMP $PKG

cd $TMP

rm -rf Vulkan-ValidationLayers-sdk-$VERSION Vulkan-Headers-sdk-$VERSION glslang-$GLSLANG_VERSION



tar xvf $CWD/glslang-${GLSLANG_VERSION}.tar.?z || exit 1

cd glslang-$GLSLANG_VERSION/External

tar xvf $CWD/SPIRV-Tools-$SPIRV_TOOLS_VERSION.tar.lz

mv SPIRV-Tools-$SPIRV_TOOLS_VERSION spirv-tools

cd spirv-tools/external

tar xvf $CWD/SPIRV-Headers-$SPIRV_HEADERS_VERSION.tar.lz

mv SPIRV-Headers-$SPIRV_HEADERS_VERSION spirv-headers



cd $TMP/glslang-${GLSLANG_VERSION}



chown -R root:root .

find . \

  \( -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \

  -exec chmod 755 {} \; -o \

  \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \

  -exec chmod 644 {} \;



# Fix LIBDIRSUFFIX

for i in $(find . -name CMakeLists.txt); do

  sed -i "s|DESTINATION lib|DESTINATION \${CMAKE_INSTALL_LIBDIR}|" "$i"

done



mkdir -p build

cd build

cmake \

  -DCMAKE_C_FLAGS:STRING="$SLKCFLAGS" \

  -DCMAKE_CXX_FLAGS:STRING="$SLKCFLAGS" \

  -DCMAKE_INSTALL_PREFIX=$PKG \

  -DCMAKE_INSTALL_LIBDIR=lib$LIBDIRSUFFIX \

  -DCMAKE_BUILD_TYPE=Release \

  ..

cmake .. -DCMAKE_INSTALL_PREFIX=/usr

make

make install DESTDIR=$PKG



cd $TMP



tar xvf $CWD/Vulkan-Headers-sdk-$VERSION.tar.gz

cd Vulkan-Headers-sdk-$VERSION



chown -R root:root .

find . \

  \( -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \

  -exec chmod 755 {} \; -o \

  \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \

  -exec chmod 644 {} \;



mkdir -p build

cd build

cmake \

  -DCMAKE_C_FLAGS:STRING="$SLKCFLAGS" \

  -DCMAKE_CXX_FLAGS:STRING="$SLKCFLAGS" \

  -DCMAKE_INSTALL_PREFIX=/usr\

  -DCMAKE_INSTALL_LIBDIR=lib$LIBDIRSUFFIX \

  -DCMAKE_BUILD_TYPE=Release \

  ..

make

make install DESTDIR=$PKG

cd $TMP



tar xvf $CWD/Vulkan-Loader-sdk-$VERSION.tar.?z || exit 1

cd $TMP/Vulkan-Loader-sdk-$VERSION



chown -R root:root .

find . \

  \( -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \

  -exec chmod 755 {} \; -o \

  \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \

  -exec chmod 644 {} \;



mkdir -p build

cd build

  cmake \

    -DCMAKE_C_FLAGS:STRING="$SLKCFLAGS" \

    -DCMAKE_CXX_FLAGS:STRING="$SLKCFLAGS" \

    -DCMAKE_INSTALL_PREFIX=/usr \

    -DGLSLANG_INSTALL_DIR=$PKG/usr \

    -DVULKAN_HEADERS_INSTALL_DIR=$PKG/usr \

    -DBUILD_WSI_WAYLAND_SUPPORT=Off \

    -DBUILD_WSI_MIR_SUPPORT=Off \

    ..



  make $NUMJOBS VERBOSE=1 || make || exit 1

  make install DESTDIR=$PKG || exit 1



cd $TMP



tar xvf $CWD/Vulkan-ValidationLayers-sdk-$VERSION.tar.?z || exit 1

cd $TMP/Vulkan-ValidationLayers-sdk-$VERSION



chown -R root:root .

find . \

  \( -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \

  -exec chmod 755 {} \; -o \

  \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \

  -exec chmod 644 {} \;



mkdir -p build

cd build

  cmake \

    -DCMAKE_C_FLAGS:STRING="$SLKCFLAGS" \

    -DCMAKE_CXX_FLAGS:STRING="$SLKCFLAGS" \

    -DCMAKE_INSTALL_PREFIX=/usr \

    -DCMAKE_INSTALL_SYSCONFDIR=/etc \

    -DCMAKE_INSTALL_DATADIR=/share \

    -DCMAKE_SKIP_RPATH=True \

    -DBUILD_TESTS=Off \

    -DBUILD_WSI_XLIB_SUPPORT=On \

    -DBUILD_WSI_XCB_SUPPORT=On \

    -DBUILD_WSI_WAYLAND_SUPPORT=Off \

    -DBUILD_WSI_MIR_SUPPORT=Off \

    -DCMAKE_BUILD_TYPE=Release \

    -DGLSLANG_INSTALL_DIR=$PKG/usr \

    -DVULKAN_HEADERS_INSTALL_DIR=$PKG/usr \

    -DVULKAN_LOADER_INSTALL_DIR=$PKG/usr \

    ..



  make $NUMJOBS VERBOSE=1 || make || exit 1

  make install DESTDIR=$PKG || exit 1



cd $TMP



tar xvf $CWD/Vulkan-Tools-sdk-$VERSION.tar.?z || exit 1

cd $TMP/Vulkan-Tools-sdk-$VERSION



chown -R root:root .

find . \

  \( -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \

  -exec chmod 755 {} \; -o \

  \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \

  -exec chmod 644 {} \;



mkdir -p build

cd build

  cmake \

    -DCMAKE_C_FLAGS:STRING="$SLKCFLAGS" \

    -DCMAKE_CXX_FLAGS:STRING="$SLKCFLAGS" \

    -DCMAKE_BUILD_TYPE=Release \

    -DCMAKE_INSTALL_PREFIX=/usr \

    -DVULKAN_HEADERS_INSTALL_DIR=$PKG/usr \

    -DGLSLANG_INSTALL_DIR=$PKG/usr \

    -DVULKAN_LOADER_INSTALL_DIR=$PKG/usr \

    -DBUILD_WSI_WAYLAND_SUPPORT=Off \

    -DBUILD_WSI_MIR_SUPPORT=Off \

    ..



  make $NUMJOBS VERBOSE=1 || make || exit 1

  make install DESTDIR=$PKG || exit 1



cd $TMP



find $PKG -print0 | xargs -0 file | grep -e "executable" -e "shared object" | grep ELF \

  | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null || true



mkdir -p $PKG/usr/doc/$PKGNAM-$VERSION

cp -a \

  Vulkan-Loader-sdk-$VERSION/*.txt \

  Vulkan-Loader-sdk-$VERSION/loader/LoaderAndLayerInterface.md \

  $PKG/usr/doc/$PKGNAM-$VERSION



mkdir -p $PKG/install

cat $CWD/slack-desc > $PKG/install/slack-desc



cd $PKG

/sbin/makepkg -l y -c n $TMP/$PKGNAM-$VERSION-$ARCH-$BUILD.txz

Quote:

Originally Posted by upnort (Post 5898762)

In a previous post in this thread I suggested some kind of change that would help users revert to previous packages.

I started doing such a thing last year. You're welcome to clone it and finish it off. https://github.com/idlemoor/heresy

gdk-pixbuf, glib-networking, libsoup etc. are coming out these days brand new :) I hope we are still in time to get all those gtk/gnome stuff updated.

Thanks
Saxa

How about enabling of CONFIG_ZRAM_WRITEBACK withing kernel?

Code:

CONFIG_ZRAM_WRITEBACK=y

This option is exceptionally useful for creating a "super-swap", in the form of a ZRAM device (compressed SWAP device in memory) backed up with a real SWAP partition.

The end result is ability to create a really fast and efficient memory SWAP design, doing something like

Code:

modprobe zram



echo 1 > /sys/block/zram0/reset



echo lz4 > /sys/block/zram0/comp_algorithm



echo /dev/sdb1 > /sys/block/zram0/backing_dev



echo 8G > /sys/block/zram0/disksize



mkswap /dev/zram0



swapon -p 100 /dev/zram0

To note that my example assumes that /dev/sdb1 is also itself an 8GB SWAP partition.

---------------------------------------------------------

In other hand, how about also enabling of ZSWAP options?

That ZSWAP also (alternatively) helps on getting a super-fast SWAP design and from my own experience it works exceptionally well.

Is there a reason for non enabling it at all?

Quote:

Originally Posted by saxa (Post 5899473)

gdk-pixbuf, glib-networking, libsoup etc. are coming out these days brand new :) I hope we are still in time to get all those gtk/gnome stuff updated.

I noticed several of the new gtk stack had releases out, but there were still quite a few lagging behind, so I thought I'd give them a few days to settle out.

Sometimes the stray cat from installpkg complains about broken pipe. It is quite visible in terse mode. Sending it to /dev/null wont hurt.

/sbin/installpkg

Code:

# The stray cat reduces the frequency of the lack of reported size.

# If it still fails, we hit it with a bigger hammer down below.

cat $package | $packagecompression -dc | LC_ALL=C dd 2> $TMP/tmpsize${MCOOKIE} | cat 2>/dev/null | tar tf - 2> /dev/null 1> $TMP/tmplist${MCOOKIE}

Cheers

Quote:

Originally Posted by rworkman (Post 5899620)

I noticed several of the new gtk stack had releases out, but there were still quite a few lagging behind, so I thought I'd give them a few days to settle out.

Robby, yeah, all is comeing out step by step, since gnome is scheduled for end of month. So i wanted just to advise since its good
if we can have the latest stuff. More, I think we can safely upgrade all that stuff from what we already have since the changes
usually are not very disruptive. Thanks !

Another 2>/dev/null. In rc.cpufreq. /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver doesn't exist in qemu VM.

Code:

# For CPUs using intel_pstate, always use the performance governor. This also

# provides power savings on Intel processors while avoiding the ramp-up lag

# present when using the powersave governor (which is the default if ondemand

# is requested on these machines):

if [ "$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver 2>/dev/null)" = "intel_pstate" ]; then

  SCALING_GOVERNOR="performance"

fi

Cheers