SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I was 2 minutes faster, but you're one package ahead
--
Best regards,
Andrzej Telszewski
Yes you did but i had it written for a while before i posted since i think some scripts should be updated but said to myself "i do it later" instead, but since an release is getting closer i did it now.
Thanks for your post that motivated me to do it now
mesa.slackbuild i think it should be possible to pass VERSION= to this script since mesa i something that many tests newer versions of, and the capital M:s i an relic from old mesa packaging and doesn't make sense anymore and only brings an inconsistency between package naming and doc path.
Instead of only changeing from M to m i think it's better to use PKGNAM for consistency.
Code:
--- b/mesa.SlackBuild 2015-11-23 22:19:21.000000000 +0100
+++ a/mesa.SlackBuild 2015-12-10 03:49:47.722195055 +0100
@@ -21,8 +21,8 @@
# ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
PKGNAM=mesa
-VERSION=11.0.6
-DEMOVERS=8.2.0
+VERSION=${VERSION:-11.0.7}
+DEMOVERS=${DEMOVERS:-8.3.0}
BUILD=${BUILD:-1}
NUMJOBS=${NUMJOBS:--j7}
@@ -173,12 +173,12 @@
gzip -9 $PKG/usr/info/*
fi
-mkdir -p $PKG/usr/doc/Mesa-$VERSION/html
+mkdir -p $PKG/usr/doc/$PKGNAM-$VERSION/html
cp -a \
docs/COPYING* docs/relnotes/relnotes-${VERSION}*.html docs/README* docs/GL* \
- $PKG/usr/doc/Mesa-$VERSION
-cp -a docs/*.html $PKG/usr/doc/Mesa-$VERSION/html
-rm -f $PKG/usr/doc/Mesa-$VERSION/html/relnotes*.html
+ $PKG/usr/doc/$PKGNAM-$VERSION
+cp -a docs/*.html $PKG/usr/doc/$PKGNAM-$VERSION/html
+rm -f $PKG/usr/doc/$PKGNAM-$VERSION/html/relnotes*.html
mkdir -p $PKG/install
cat $CWD/slack-desc > $PKG/install/slack-desc
The get-mesa.sh needs an update as well since it package the git sources as the old tarballs and is there for inconsistent with the mesa.slackbuild
Code:
--- b/get-mesa.sh 2015-12-10 02:52:06.934162071 +0100
+++ a/get-mesa.sh 2015-12-10 03:03:31.512168596 +0100
@@ -1,5 +1,5 @@
# Pull a stable branch + patches
-BRANCH=7.10
+BRANCH=${BRANCH:-7.10}
rm -rf mesa
git clone git://anongit.freedesktop.org/git/mesa/mesa
@@ -11,10 +11,10 @@
# Cleanup. We're not packing up the whole git repo.
( cd mesa && find . -type d -name ".git*" -exec rm -rf {} \; 2> /dev/null )
DATE=$(date +%Y%m%d)
-mv mesa Mesa-${BRANCH}_${HEADISAT}
-tar cf MesaLib-${BRANCH}_${HEADISAT}.tar Mesa-${BRANCH}_${HEADISAT}
-xz -9 MesaLib-${BRANCH}_${HEADISAT}.tar
-rm -rf MesaLib-${BRANCH}_${HEADISAT}
+mv mesa mesa-${BRANCH}_${HEADISAT}
+tar cf mesa-${BRANCH}_${HEADISAT}.tar mesa-${BRANCH}_${HEADISAT}
+xz -9 mesa-${BRANCH}_${HEADISAT}.tar
+rm -rf mesa-${BRANCH}_${HEADISAT}
echo
-echo "Mesa branch $BRANCH with HEAD at $HEADISAT packaged as MesaLib-${BRANCH}_${HEADISAT}.tar.xz"
+echo "Mesa branch $BRANCH with HEAD at $HEADISAT packaged as mesa-${BRANCH}_${HEADISAT}.tar.xz"
echo
Maybe Pat wants us to edit the script but i for one likes to be able to pass a variable to the script instead of editing when testing different versions.
In /etc/rc.d/rc.S there is 3 second delay before mounting non-root file systems.
Since I migrated to SSD, my boot time is 14 seconds, 3 of which are the 3 second pre delay
Could we make it configurable? Something like:
Code:
if [ -f /etc/NON_ROOT_MOUNT_DELAY ]; then
sleep $(cat /etc/NON_ROOT_MOUNT_DELAY)
else
sleep 3
fi
I would favor continue letting the admins in concern (you, in this case) edit the script as they see fit over adding a new config task for all users.
In the (unlikely) case a new sysvinit-scripts package would be released for a stable release, you would get a rc.S.new to consider, so you will be able to decide what to do if that happens.
Last edited by Didier Spaier; 12-10-2015 at 01:04 PM.
@Didier Spaier I know all of that, for that reason, what I proposed brings no change or need to tweak for those who don't want it. And as I said, for me it's no big deal at all. I rarely reboot my machine The boot just look more consistent without pausing
I wonder if replacing that "sleep 3" with something like "udevadm settle || sleep 3" (to account for the two people who still refuse to install udev) would be sufficient.
USB is tricky beast, you can never be sure when the device becomes available. I understand that 3 seconds seem to work most of the time, but when I was doing an embedded device with Tegra T20, I had to make it 6 seconds, otherwise it was unreliable. Well, one thing is that I used Buildroot, which boots faster, another thing is that, I didn't use udev. I don't know how well udev settle would work in that situation. Something to be aware of.
All of these CVEs were already patched in Slackware 14.0+ (before they had CVEs, actually), but we'll probably take this as an upgrade for current anyway.
Im only posting some i486 remaining packages with updates availables.
Im not sure if , for final version goes with full i586 packages or some mixed with remanent i486 , because no upgrade available , no build in i586 , or another reasons.
Thanks, one more time to all slackware developers.
If we're talking about managing parameters for rc.* files, then I'd rather see a rc.conf/rc.conf.local mechanism than the addition of arbitrarily named files littering /etc.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
