Requests for -current (14.2-->15.0)

2slguevH · 04-28-2021, 10:10 AM

In case the preview swap support patch was overlooked, I'm
updating the patch file from the recent updates and re-request the
support of hibernation to the swap file for mkinitrd/initrd.

The current slackware(both 14.2 and -current) might be regarded as
'hibernation to swap file ready', the only change to the vanilla initrd
when resuming from the swap file is the necessary file
'/sys/power/resume_offset'.

I'm not sure how to send patch file via linuxquestions forum, here is
the patch file:
https://paste.debian.net/plainh/66ce9334

The patch is created using following commands:

Code:

LC_ALL=C diff -Naur mkinitrd.orig mkinitrd

mkinitrd.orig refers to the vanilla 'source/a/mkinitrd' directory;
mkinitrd refers to the modified version.

To apply the patch, 'cd' into 'source/a/mkinitrd' and run

Code:

patch -Np1 -i mkinited-s2disk-swap-file.patch

, then rebuild the a/mkinitrd package.

Didier Spaier · 04-28-2021, 11:21 AM

I am about to upgrade python3 in Slint as it includes an old, now unsupported version.

I assume that I can safely upgrade to python3.9. However in case Slackware15 ends up shipping python3.10 I would follow suite thus would have to rebuild many packages twice and so would have to do our users using third party packages built against python3, which I'd prefer to avoid.

As the 3.10.0 schedule indicates Monday, 2021-10-04 as ETA for 3.10.0 I don't expect 3.10 to be shipped in Slackware, but I'd be grateful for a confirmation that it will ship 3.9.x instead.

Didier Spaier · 04-28-2021, 04:23 PM

Unless there's is a major inconvenience doing that other than the added build time and a small increase of the packages size, which are not significant? A quick Internet search didn't find any recently reported. I just rebuilt using the SlackBuild from Slackware64-current in a Slint64-14.2 VM python 3.9.4 with the --enable-optimizations added to the configure command with no obvious issue. I've also inserted this before ./configure :

Code:

  mkdir build
  # https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
  CFLAGS="${CFLAGS/-O2/-O3} -fno-semantic-interposition"
  LDFLAGS="$LDFLAGS -fno-semantic-interposition"

'mkdir build' is just to remove a non blocking error displayed without it (but this directory seems otherwise unused this early in the build process):

Code:

Running code to generate profile data (this can take a while):
# First, we need to create a clean build with profile generation
# enabled.
make profile-gen-stamp
make[1]: Entering directory '/repo/upcoming/python3optimized/Python-3.9.4'
make clean
make[2]: Entering directory '/repo/upcoming/python3optimized/Python-3.9.4'
find . -depth -name '__pycache__' -exec rm -rf {} ';'
find . -name '*.py[co]' -exec rm -f {} ';'
find . -name '*.[oa]' -exec rm -f {} ';'
find . -name '*.s[ol]' -exec rm -f {} ';'
find . -name '*.so.[0-9]*.[0-9]*' -exec rm -f {} ';'
find . -name '*.lst' -exec rm -f {} ';'
find build -name 'fficonfig.h' -exec rm -f {} ';' || true
find: 'build': No such file or directory
find build -name '*.py' -exec rm -f {} ';' || true
find: 'build': No such file or directory
find build -name '*.py[co]' -exec rm -f {} ';' || true
find: 'build': No such file or directory
rm -f pybuilddir.txt
rm -f Lib/lib2to3/*Grammar*.pickle
rm -f Programs/_testembed Programs/_freeze_importlib
find build -type f -a ! -name '*.gc??' -exec rm -f {} ';'
find: 'build': No such file or directory
Makefile:1829: recipe for target 'clean-retain-profile' failed
make[2]: [clean-retain-profile] Error 1 (ignored)

The other added lines are borrowed from this PKGBUILD from Arch.

PS The only caveat of adding the flag -fno-semantic-interposition, mentioned by Fedora, is:

Quote:

As a negative side effect, it disables the LD_PRELOAD feature: it's no longer possible to override symbols in libpython with LD_PRELOAD.

semiprime · 04-28-2021, 05:06 PM

A small suggestion originating from my thought in this other thread: https://www.linuxquestions.org/quest...ml#post6242857

I think defaulting to mounting the efi partition with the "sync" option should make the partition more resistant to corruption - it's a vfat partition, so a crash/power loss between when the user thinks the partition has been written and when the bits hit the hardware can leave it in a broken state. Using sync would shorten that time window. A downside is that reading/writing the partition is slower for the user, but since this is typically only done when updating the boot settings, it shouldn't be a problem (anyway the user can always change their fstab manually).

I've not tested, and I'm not knowledgeable about the installer, but I guess the change would be to the SeTEFI install script:

Code:

  
  # Add the EFI System Partition to /etc/fstab:
- printf "%-16s %-16s %-11s %-16s %-3s %s\n" "$PREFERRED_EFI_PARTITION" "/boot/efi" "vfat" "defaults" "1" "0" > $TMP/SeTEFI
+ printf "%-16s %-16s %-11s %-16s %-3s %s\n" "$PREFERRED_EFI_PARTITION" "/boot/efi" "vfat" "sync" "1" "0" > $TMP/SeTEFI
  cat << EOF > $TMP/tempmsg

gbschenkel · 04-28-2021, 08:42 PM

Quote:

Originally Posted by gbschenkel

Hey Pat, any chance to enable Automatic Process Group Scheduling(SCHED_AUTOGROUP=y) on Kernel? Cheers.

Code:

Automatic process group scheduling (SCHED_AUTOGROUP)

CONFIG_SCHED_AUTOGROUP:

This option optimizes the scheduler for common desktop workloads by
automatically creating and populating task groups. This separation
of workloads isolates aggressive CPU burners (like build jobs) from
desktop applications. Task group autogeneration is currently based
upon task session.

Symbol: SCHED_AUTOGROUP [=y]
Type : bool
Defined at init/Kconfig:1205
Prompt: Automatic process group scheduling
Location:
-> General setup
Selects: CGROUPS [=y] && CGROUP_SCHED [=y] && FAIR_GROUP_SCHED [=y]

I am using it a few day with Kernel 5.12 recompiled just with that option on, and no issues until now, just for you guys know.

Nobby6 · 04-28-2021, 09:34 PM

bind update available

Our April maintenance releases of BIND are available and can be downloaded
from the ISC software download page, https://www.isc.org/download

In addition to bug fixes and feature improvements, these releases also contain
fixes for several security vulnerabilities, CVE-2021-25214, CVE-2021-25215,
and CVE-2021-25216, about which more information is provided in these
Security Advisories

https://kb.isc.org/docs/cve-2021-25214
https://kb.isc.org/docs/cve-2021-25215
https://kb.isc.org/docs/cve-2021-25216

###

Apache httpd-2.4.47 is also now released

Nobby6 · 04-28-2021, 09:40 PM

Quote:

Originally Posted by volkerdi

In short, what you're demanding runs contrary to the documentation and doesn't even work. I suspect if the sample file were to be left alone in /etc/postfix, people would try to edit it there and wonder why it doesn't work. Plus it would get overwritten. I'm not about to .new protect something that's not a functional config file (the /etc/aliases file *is* currently .new protected).

It doesnt work for you because its governed by main.cf which as I already said years ago used to use /etc/postfix this is where we started and our configs carry on all the way through just adding required new options.

forget it, I can see you rather sit here and type out 500 lines rather than take onboard what i'm suggesting a simple check to see if a file exists and if so leave it, else over write it, that would help those old long time postfix users and existing ones so no one has to change a dman thing.

you've mad eit clear youre not interested, so this is my final word to you or anyone else about it, I give up.

we will just exclude your postfix packages from now on and use the source

Petri Kaukasoina · 04-29-2021, 12:43 AM

Quote:

Originally Posted by gbschenkel

I am using it a few day with Kernel 5.12 recompiled just with that option on, and no issues until now, just for you guys know.

So, did you notice the overhead of SCHED_AUTOGROUP in your benchmarks?

mats_b_tegner · 04-29-2021, 02:56 AM

less 581.2
https://www.greenwoodsoftware.com/less/news.581.html
https://www.greenwoodsoftware.com/le...s-581.2.tar.gz

opty · 04-29-2021, 03:23 AM

Quote:

Originally Posted by 2slguevH

The patch is created using following commands:

Code:

LC_ALL=C diff -Naur mkinitrd.orig mkinitrd

mkinitrd.orig refers to the vanilla 'source/a/mkinitrd' directory;
mkinitrd refers to the modified version.

man patch:

Quote:

Originally Posted by man patch

Avoid sending patches that compare backup file names like README.orig, since this might confuse patch into patching a backup file instead of the real file. Instead, send patches that compare the same base file names in different directories, e.g. old/README and new/README.

LuckyCyborg · 04-29-2021, 03:44 AM

That's exactly what he did. It's a diff over two top-level directories.

jwoithe · 04-29-2021, 04:33 AM

In Slackware64 current as of the Tue Apr 27 ChangeLog entry, the following is reported when running gtk2 programs under the XFCE environment when the Greybird theme is in use:

Code:

Gtk-WARNING **: Unable to locate theme engine in module_path: "murrine"

I'm not all that familiar with the way GTK themes work, but it appears that on start up the selected theme under /usr/share/themes/ is processed. The Greybird theme (provided by the xfce/Greybird package) provides a gtk2 theme which can be found in /usr/share/themes/Greybird/gtk-2.0/. The gtkrc file therein contains several references to

Code:

engine "murrine"

so this might be the cause of the error. It seems the murrine theme is not currently included in Slackware64-current since I can find none of its files mentioned in the MANIFEST.bz2 file (such as "libmurrine").

The error does not prevent programs from starting, but it may indicate something which should be resolved. There are two obvious approaches:

Provide the murrine theme engine that's required by Greybird.
Remove Greybird from Slackware64 current and replace it with a similar theme which uses the engines which are present in Slackware64 current.

Personally I would prefer option 1 since Greybird seems to be one of few themes which has a strong and clear contrast between the appearance of focused and unfocused windows.

MDKDIO · 04-29-2021, 05:10 AM

Quote:

Originally Posted by jwoithe

In Slackware64 current as of the Tue Apr 27 ChangeLog entry, the following is reported when running gtk2 programs under the XFCE environment when the Greybird theme is in use:

Code:

Gtk-WARNING **: Unable to locate theme engine in module_path: "murrine"

I'm not all that familiar with the way GTK themes work, but it appears that on start up the selected theme under /usr/share/themes/ is processed. The Greybird theme (provided by the xfce/Greybird package) provides a gtk2 theme which can be found in /usr/share/themes/Greybird/gtk-2.0/. The gtkrc file therein contains several references to

Code:

engine "murrine"

so this might be the cause of the error. It seems the murrine theme is not currently included in Slackware64-current since I can find none of its files mentioned in the MANIFEST.bz2 file (such as "libmurrine").

The error does not prevent programs from starting, but it may indicate something which should be resolved. There are two obvious approaches:

Provide the murrine theme engine that's required by Greybird.
Remove Greybird from Slackware64 current and replace it with a similar theme which uses the engines which are present in Slackware64 current.

Personally I would prefer option 1 since Greybird seems to be one of few themes which has a strong and clear contrast between the appearance of focused and unfocused windows.

Is there anything that prevents it from being built with gtk3 instead?

opty · 04-29-2021, 05:45 AM

Quote:

Originally Posted by LuckyCyborg

That's exactly what he did. It's a diff over two top-level directories.

*facepalm* at myself.

Nobby6 · 04-29-2021, 06:49 AM

wonder what all these maketag and tagfile files are in dirs, never noticed them before, our local mirror is first time fetching them tonight by the logs, theyve never been synced before today, probably upstream mirror had an acl and they changed it I guess