LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   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/)

USUARIONUEVO 02-21-2021 01:59 PM

Quote:

Originally Posted by gmgf (Post 6222888)
hplip-3.21.2:

https://developers.hp.com/hp-linux-imaging-and-printing

the hplip.SlackBuild contain:

# Needed because Makefile.am was patched:
autoreconf -vif || exit 1

CFLAGS="$SLKCFLAGS -I/usr/include/python3.8" \

maybe it's better with python3.9 ;)

CFLAGS="$SLKCFLAGS -I/usr/include/python3.9" \

To no lost the branch changing every time ..is better make a variable

Code:

PY3=python$(python3 -c 'import sys; print("{}.{}".format(sys.version_info.major, sys.version_info.minor))')
Code:

CFLAGS="$SLKCFLAGS -I/usr/include/python$PY3

ZhaoLin1457 02-21-2021 03:55 PM

The Slackware -current have a fine Wayland support and my favorite way to run Plasma5 is on Wayland sessions.

Particularly, the Wayland/Plasma5 looks acting more fluid, with absolutelly no tearing and somehow it feels faster on my MinisForum Z83-F mini-PC driven by an Atom Z8350 with 4 cores and 4GB RAM.

BUT, I noticed that on Slackware is a single Wayland desktop solution right now: this Wayland/Plasma5.

I think that there is a lack of a lighter desktop alternative/solution for Wayland, let's say... the equivalent of what is FluxBox or FVWM for X11.

So, there's my proposal for -current for addition of reference (and minimalist) compositor of Wayland: Weston.

It's repository is there: https://gitlab.freedesktop.org/wayland/weston/

It looks like this: https://gitlab.freedesktop.org/wayla...screenshot.jpg

And we have already a SlackBuild for it: https://slackbuilds.org/repository/14.2/desktop/weston/

upnort 02-21-2021 04:44 PM

Register with the Linux counter project
 
Pat,

The Linux counter project is closed. Perhaps update the default emails sent to root?

chris.willing 02-21-2021 05:25 PM

ffmpeg-4.3.2

https://ffmpeg.org/releases/ffmpeg-4.3.2.tar.bz2

gsl 02-21-2021 05:50 PM

Quote:

Originally Posted by chris.willing (Post 6222972)

Code:

Sun Feb 21 20:02:02 UTC 2021
...
l/ffmpeg-4.3.2-x86_64-1.txz:  Upgraded.


guanx 02-21-2021 07:49 PM

Quote:

Originally Posted by FlinchX (Post 6222708)
While Tor is a third party app not bundled with vanilla Slackware, it would be nice if /etc/rc.d/rc.M would try to execute an existing executable /etc/rc.d/rc.tor, before all network daemons that do name resolving. I'm asking for this since I've been using Tor as DNS resolver for years, to avoid censorship, and this would spare me for modifying rc.M by hand.

The deed alone of using Tor will trigger investigation when censorship is a concern. Plus the security problems of Tor itself, it would be better not to officially encourage its use.

If some such things are to be launched, a better place is at the beginning of rc.inet2. I fact, it'd be much better to also move the call to rc.firewall to the beginning.

chris.willing 02-21-2021 09:21 PM

Quote:

Originally Posted by gsl (Post 6222985)
Code:

Sun Feb 21 20:02:02 UTC 2021
...
l/ffmpeg-4.3.2-x86_64-1.txz:  Upgraded.


Ah, you must be using a more up to date mirror than I.

LuckyCyborg 02-22-2021 08:32 AM

Please consider applying the KWin patch shown bellow for permitting running Wayland/Plasma5 sessions as root:

https://invent.kde.org/plasma/kwin/-/merge_requests/679

https://invent.kde.org/plasma/kwin/-...ests/679/diffs
Code:

diff --git a/main_wayland.cpp b/main_wayland.cpp
index 0abe4bee46602ef9cf36a2794a58a886c0d4d6a9..cbd5a1845f0f4aba08bbc8cffc14ee55f6502f87 100644
--- a/main_wayland.cpp
+++ b/main_wayland.cpp
@@ -463,10 +463,6 @@ void dropNiceCapability()
 
 int main(int argc, char * argv[])
 {
-    if (getuid() == 0) {
-        std::cerr << "kwin_wayland does not support running as root." << std::endl;
-        return 1;
-    }

    KWin::disablePtrace();
    KWin::Application::setupMalloc();
    KWin::Application::setupLocalizedString();

Essentially, it removes a hard lock of kwin_wayland on running as root and I use it since several days without problems, in a local patched build of KWin.

I think that the KDE developers opinions about root account aren't news to anyone, as they in the past blocked various programs to run as root for "user own protection" , for example Kate or Dolphin.

With Wayland/Plasma5 they blocked the entire desktop session, by refusal of kwin_wayland to run as root.

However, I believe that considering the nazi security of Wayland, even running as root a Wayland/Plasma5 session, it will be way more secure than its X11/Plasma5 counterpart.

In other hand, we already remove those root blockings for Dolphin and Kate, and unblocking also Kwin_wayland, will permit to have on Wayland/Plasma5 a alternative on pair with X11/Plasma5.

Didier Spaier 02-22-2021 10:53 AM

LuckyCyborg: what can you do starting the whole graphical environment as root that you couldn't do otherwise? Why not run applications individually as root when needed instead? This a genuine question, use cases or practical examples welcome. X can be started as root indeed, but I never felt a need to do that, hence the question.

PS I am a bit surprised that the lock be at the windows manager level. What if user replaces Kwin by another one in a session or permanently. Isn't it possible with Plasma 5?

PPS. I just tried: in Mate "kwin --replace" works as "compiz --replace". In KDE4 marco --replace works as well as compiz --replace (to some extent as the windows manager is not supposed to be the last component started when opening a desktop session).

andygoth 02-22-2021 10:56 AM

Quote:

Originally Posted by ljb643 (Post 6222502)
Revert isolinux/README.TXT to using mkisofs not xorriso

In the Slackware-current distribution area in the isolinux directory, README.TXT has instructions on how to make a bootable DVD or USB flash drive for installing Slackware. Unfortunately, the instructions rely on the 'xorriso' package, which was added after Slackware-14.2. So a person trying to upgrade from Slackware-14.2 to -current or a future 15.0 is unable to follow these instructions.

My suggestion is to revert to the older instructions which use mkisofs and isohybrid. This will allow making bootable upgrade media when using Slackware-14.2. Post-15.0, you can switch to using commands from the xorriso package.

The old mkisofs instructions given in the 14.2 README.TXT do not create an EFI-bootable disc image. See here for some guidance on how to possibly make it work, then report back with mkisofs and isohybrid command lines that will do the job.

Not exclusive to what you are suggesting, I'd like to see the instructions go the other way and fully adopt xorriso's native syntax without relying on the mkisofs emulation. But that's homework for me as well, which I've not completed. For the moment I'm relying on the -graft-points feature (or the emulation thereof) to get what I want. xorriso has -cd and -cdx and -cpr and such to manipulate the filesystem image under construction, which provides additional flexibility that may come in handy. Though for now, -graft-points is sufficient.

drgibbon 02-22-2021 11:08 AM

I'd personally hope not to see root login patches in the main distribution: In the majority of cases it's good to discourage/disallow full root GUI use (e.g., it's actually helpful to new users), for the cases where it's wanted (maybe some kind of GUI rescue/repair kit?), special customization can be done for the purpose. :twocents:

LuckyCyborg 02-22-2021 11:13 AM

Quote:

Originally Posted by Didier Spaier (Post 6223259)
LuckyCyborg: what can you do starting the whole graphical environment as root that you couldn't do otherwise? Why not run applications individually as root when needed instead? This a genuine question, use cases or practical examples welcome. X can be started as root indeed, but I never felt a need to do that, hence the question.

Believe or not, until Plasma 5.21 the single way to run as root applications was console applications in a konsole tab, via su(do) because it lacked the support for XAuthority (aka xhost commands) so no graphical application was capable to run as another whatever user.

OK, there was that openSUSE patch which added support for XAuthority on Wayland, BUT it was not used by Slackware, even I proposed it.

My intention is to bring the Wayland/Plasma5 on pair with X11/Plasma5 so the ability of running as root is a feature which is needed for a fine user experience.

Quote:

Originally Posted by Didier Spaier (Post 6223259)
PS I am a bit surprised that the lock be at the windows manager level. What if user replaces Kwin by another one in a session or permanently. Isn't it possible with Plasma 5?

Believe or not, on Wayland/Plasma5 the KWin_wayland is not only windowa manager, BUT also the Wayland server/composer which instruments both pure Wayland and XWayland features, so makes no sense to think of replacing it because it is very integrated on the desktop environment. Even the clipboard management is instrumented by KWin(_wayland)

However, this is not a KDE invention, as Wayland/Gnome3 has Mutter as Wayland server/composer and even Weston has, well... the Weston.

Essentially, the Wayland itself contains just a library to write Wayland servers, so every desktop environment writes one as they likes and with features as they likes.

For example Wayland/Gnome3 has a session management on pair with X11/Gnome3 while Wayland/Plasma5 is capable right now to restore only the applications running on X11 mode via XWayland.

BTW, there's the first RC of standalone XWayland 21.1.0 : https://lists.freedesktop.org/archiv...ry/060615.html

Did you understand what they intend to do - not that they keep it secret? The single maintained part from the Xorg sever will be soon the XWayland, so in several years you can kiss goodbye to XFCE, FVWM, BlackBox, FluxBox and any WhateverBox.

And we, we are on verge to remain with a single desktop solution: Wayland/Plasma5 so we like or not, we should tame it. Accepting constrains like "not running at all as root" , will result on restraints of our freedom to use our own box as we like.

saxa 02-22-2021 12:29 PM

You will still be able to compile xorg server and other desktops by yourself.

LuckyCyborg 02-22-2021 12:33 PM

Quote:

Originally Posted by saxa (Post 6223323)
You will still be able to compile xorg server and other desktops by yourself.

Same you can do with XFree86 server. Or at least you can try, because I seriously doubt that it still compiles on Slackware 15.0 alpha1... ;)

However, how much useful will be that XFree86 server, even you manage to compile it, with its code rotten by many years passing over it?

Same will happen sooner or later with the Xorg server code, which now is basically on "preservation" and IF we ignore this, we risk to have the surprise that someday Slackware will have a single functional desktop environment: Wayland/Plasma5 and that also we are gracious locked away from the root account. For our own protection.

LuckyCyborg 02-22-2021 02:57 PM

Quote:

Originally Posted by drgibbon (Post 6223263)
I'd personally hope not to see root login patches in the main distribution: In the majority of cases it's good to discourage/disallow full root GUI use (e.g., it's actually helpful to new users), for the cases where it's wanted (maybe some kind of GUI rescue/repair kit?), special customization can be done for the purpose. :twocents:

Excuse me, BUT the X11/Plasma5 works fine as root and there are already root login patches for Kate and Dolphin which are deemed too dangerous to be run as root by the KDE developers. Also XFCE and any other windows manager shipped by Slackware works fine as root.

My proposed patch is for Wayland/Plasma5 which is now fully locked for root and the main intention is to make it to behave similar with the better known X11/Plasma5.

However, I have no intention to rehash that old thread of Darth Vader about "admins on Pampers" BUT I agree regarding one thing: let's do not consider the users some idiots who need to be protected from themselves.

An user who legit have the root credentials can mess already in many ways with the system, even without logging graphically as root.

BUT, the ability to run a desktop as root has its merits, for example I use this way on my rescue systems who are full Slackware installations on external USB hard drives. I have two and their purpose is full access to other systems. Read: administration.

Another legit usage of a root desktop could be when the encrypted /home refuses to mount. This could happen and happened, and not so long ago to someone forum member. What should do that particular user who have at disposition only the root account? To post on LQ for help from console with Links?

I believe that there are many cases of legit usage of a root desktop, that's WHY we should NOT agree with those blunt lockdowns of root account.

And BTW, how many threads you seen on this forum from people who damaged their systems because they ran desktops as root? I am there on the last 10 years but I do not remember to seen one, if any.

Maybe this happens because the Slackware users are particularly smarter and they do not need a babysitter?

SCerovec 02-22-2021 03:19 PM

Quote:

Originally Posted by ZhaoLin1457 (Post 6211259)
[snip]
Maybe this happens because the Slackware users are particularly smarter and they do not need a babysitter?

True, considering our average age around here we'd more likely need a granpasitter :D

LuckyCyborg 02-22-2021 03:22 PM

Quote:

Originally Posted by SCerovec (Post 6223385)
True, considering our average age around here we'd more likely need a granpasitter :D

And WHY you claim that @ZhaoLin1457 said that phrase, when just I've written it?

atelszewski 02-22-2021 04:20 PM

nvme, overlay, mkinitrd
 
Hi,

1. Please add nvme-cli (nvme) and overlay.ko to setup's initrd.
2. When running mkinitrd -h it loops forever (probably in args parsing loop).

Cheers! :-)

--
Best regards,
Andrzej Telszewski

slac 02-22-2021 06:26 PM

Grub is not working since the latest upgrade (build 3) for bios legacy installations (it may also affect mbr), it just cannot be installed.

When executing: "grub-install /dev/sdX" the error says:

Code:

Decompressor is too big
Reverting to build 2 of grub helps to install (temp fix) grub but still that does not fix the problem that is present in the most recent build: 3 (currently being used).

You may want to take a look at: https://www.linuxquestions.org/quest...ml#post6221162

... And also: https://www.linuxquestions.org/quest...ml#post6221247

saxa 02-22-2021 07:18 PM

@LuckyCyborg, I think that all this is not much relevant, also because for example there is Gnome3 which also compiles with Wayland. I think also step by step other desktops will move toward this direction if it shows that Xserver is really out of the game, in any case
it is not so much relevant imho. At the end we talk about few years in the future.
So I think that if you start today with a slackware 15 you will have a usable platform for many of the softwares out there. I am still writing this from a Slackware 14.2 and running my business mostly on it, so for me it works quite well. Although I have to admit it, that this slackware release cycle took a really long path and not expected it would took so long at least few years ago not.

But lets take it positivley, we will still have many options in the future. ;)

USUARIONUEVO 02-22-2021 07:32 PM

I post a patch for grub problem , but i test and not works here , i remove message , sorry.

drgibbon 02-22-2021 11:34 PM

@LuckyCyborg You are excused :D I'm not too interested in a big back and forth on the issue, but I stand by disqualifying graphical root logins as basically a good thing™. Up to the Slackware people what they want to do about it.

teoberi 02-23-2021 03:50 AM

Quote:

Originally Posted by USUARIONUEVO (Post 6223454)
I post a patch for grub problem , but i test and not works here , i remove message , sorry.

Have you tried the patch (incomplete) from here?
See here.
Complete solution here.

gmgf 02-23-2021 04:34 AM

why last 'grub-2.04-x86_64-3.txz' package, contain these files, in /usr/lib64/grub/i386-pc/

boot.img, cdboot.img, kernel.img, lzma_decompress.img,
boot_hybrid.img, diskboot.img, lnxboot.img, pxeboot.img,

i think, these files are not part of grub !?

these files break the command 'grub-install /dev/sda'

grub-install*: erreur*: Le décompresseur est trop grand.

these files are no present in the precedent, 'grub-2.04-x86_64-2.txz' package, and probably are not part of grub.

the old 'grub-2.04-x86_64-2.txz' package, work fine here, and no contain these files.

teoberi 02-23-2021 04:56 AM

Quote:

Originally Posted by gmgf (Post 6223538)
why last 'grub-2.04-x86_64-3.txz' package, contain these files, in /usr/lib64/grub/i386-pc/

boot.img, cdboot.img, kernel.img, lzma_decompress.img,
boot_hybrid.img, diskboot.img, lnxboot.img, pxeboot.img,

i think, these files are not part of grub !?

these files break the command 'grub-install /dev/sda'

grub-install*: erreur*: Le décompresseur est trop grand.

these files are no present in the precedent, 'grub-2.04-x86_64-2.txz' package, and probably are not part of grub.

the old 'grub-2.04-x86_64-2.txz' package, work fine here, and no contain these files.

https://www.linuxquestions.org/quest...ml#post6221162

alex14641 02-23-2021 05:47 AM

Bluez 5.56
Source: https://mirrors.edge.kernel.org/pub/...ez-5.56.tar.xz
Change log: https://git.kernel.org/pub/scm/bluet...tree/ChangeLog

414N 02-23-2021 07:52 AM

This is a pretty minor thing, however on every package update it is easy to overlook it: would it be possible to add a bash completion symlink creation step to the git package?
Something on the line of:
Code:

ln -s /usr/doc/git-VERSION/contrib/completion/git-completion.bash /etc/bash_completion.d/

TurboBlaze 02-23-2021 07:53 AM

libinput 1.17.0
https://lists.freedesktop.org/archiv...ry/041733.html

saxa 02-23-2021 11:24 AM

gtk+-3.24.26
https://download.gnome.org/sources/g...3.24.26.tar.xz

gtkmm-3.24.4
https://download.gnome.org/sources/g...-3.24.4.tar.xz

gexiv2-0.12.2
https://download.gnome.org/sources/g...-0.12.2.tar.xz

ponce 02-23-2021 11:38 AM

binutils 2.36 breaks "ar clq"

https://bugs.debian.org/cgi-bin/bugr...cgi?bug=981072

I just hit this trying to build nx-libs...

niksoggia 02-23-2021 01:10 PM

bug: lrzip and minicom share usr/bin/lrz
 
1 Attachment(s)
Hello,
lrzip and minicom both install usr/bin/lrz but the two commands are very different and should be kept away from each other.
I fixed the minicom slackbuild, but my patch may be too drastic.
Regards,

SCerovec 02-23-2021 03:04 PM

Quote:

Originally Posted by LuckyCyborg (Post 6223388)
And WHY you claim that @ZhaoLin1457 said that phrase, when just I've written it?

I have no idea what happened there - i made the [snip] and fired the [enter] key and now its there - I am amazed and confused the same as you :confused:

But, yeah, I don't like where the whole Open Source/Free Software community is heading to - lack of sanity and too much self confidence for my taste on way too many places.

Perhaps that comes for a reason - back in the day one had to do quite substantial amount of footwork before even standing a chance to make any reasonable code - nowdyas all one has to do is install a suite; enable few plugins mirror a repo out there and just start tweaking/twiddling an half baked project on and on...

Back in the day people started from the ground - nowdays it seems as if newbies stat from high above the clouds already, and it shows IMHO.

ZhaoLin1457 02-23-2021 05:30 PM

Quote:

Originally Posted by drgibbon (Post 6223489)
@LuckyCyborg You are excused :D I'm not too interested in a big back and forth on the issue, but I stand by disqualifying graphical root logins as basically a good thing™. Up to the Slackware people what they want to do about it.

Excuse my ignorance, but what happened with that old adagio, how it was?

"Slackware makes absolutely no assumptions about how you use the system"

From this to fully blocking the most powerful user to use a particular desktop environment as he/her likes is a long way, isn't?

I think that's one thing to recommend, to explain, to educate that some actions may be dangerous and it is entirely another thing to lock down software.

I've just tested "startkwayland" as root. This Wayland/Plasma5 did not even start as root, even it works well as a regular user.

So, I ask you:

who is the owner of my own computer? Me or Slackware?

bassmadrigal 02-23-2021 05:48 PM

Quote:

Originally Posted by ZhaoLin1457 (Post 6223803)
Excuse my ignorance, but what happened with that old adagio, how it was?

"Slackware makes absolutely no assumptions about how you use the system"

I have no horse in this race (I don't start WMs/DEs as root, but don't really care if other people want to), but there's also the Slackware tries to ships packages as upstream intends and as such, Pat tries to minimize patching the source.

Yes, he's patched kate and konqueror (or was it dolphin or both, I can't remember) to allow root usage, but opening single GUI applications as root are a far cry from a whole WM/DE. The potential security implications are far higher running everything as root compared to a single program here or there.

Quote:

Originally Posted by ZhaoLin1457 (Post 6223803)
who is the owner of my own computer? Me or Slackware?

You definitely are the owner of your computer, which means that if Pat decides to not patch Plasma5 for this, you're welcome to do it yourself.

upnort 02-23-2021 06:05 PM

Pat,

Please consider a built-in Slackware way for a user ~/.xsession-errors file. I think Slackware is the only distro I have used not directly supporting the log file. Perhaps the file could be user-defined and enabled/disabled in /etc/default/xsession-log or something similar. Possibly using /etc/xprofile. Or in an /etc/X11/Xsession file.

Would be nice, that's all. Thanks.

upnort 02-23-2021 07:29 PM

Pat,

Proposed patch for the hplip package:

Code:

diff -urN hplip-3.20.6/hp-uiscan.desktop.in hplip-3.20.6.new/hp-uiscan.desktop.in
--- hplip-3.20.6/hp-uiscan.desktop.in        2020-06-09 06:20:52.000000000 -0500
+++ hplip-3.20.6.new/hp-uiscan.desktop.in        2021-02-23 21:14:20.126071184 -0600
@@ -3,6 +3,7 @@
 Version=1.0
 Type=Application
 Terminal=false
-Name=hp-uiscan
+Name=HP Scan Utility
 Exec=/usr/bin/hp-uiscan
-Icon=/usr/share/icons/Humanity/devices/48/printer.svg
+Categories=Application;Utility;
+Icon=@abs_datadir@/hplip/data/images/128x128/hp_logo.png

Without the patch the hp-uiscan.desktop file appears in the 'Other' menu option.

Thanks.

ArTourter 02-23-2021 08:00 PM

Quote:

Originally Posted by upnort (Post 6223832)
Pat,

Proposed patch for the hplip package:

Code:

diff -urN hplip-3.20.6/hp-uiscan.desktop.in hplip-3.20.6.new/hp-uiscan.desktop.in
--- hplip-3.20.6/hp-uiscan.desktop.in        2020-06-09 06:20:52.000000000 -0500
+++ hplip-3.20.6.new/hp-uiscan.desktop.in        2021-02-23 19:27:05.806212983 -0600
@@ -3,6 +3,7 @@
 Version=1.0
 Type=Application
 Terminal=false
-Name=hp-uiscan
+Name=HP Scan Utility
 Exec=/usr/bin/hp-uiscan
 Icon=/usr/share/icons/Humanity/devices/48/printer.svg
+Categories=Application;Utility;

Without the patch the hp-uiscan.desktop file appears in the 'Other' menu option.

Thanks.

Actually, there is another change that probably needs to happen: the icon file doesn't exist.

rworkman 02-23-2021 08:10 PM

Quote:

Originally Posted by 414N (Post 6223583)
This is a pretty minor thing, however on every package update it is easy to overlook it: would it be possible to add a bash completion symlink creation step to the git package?
Something on the line of:
Code:

ln -s /usr/doc/git-VERSION/contrib/completion/git-completion.bash /etc/bash_completion.d/

Perhaps this?
Code:

ln -s /usr/doc/git-$VERSION/contrib/completion/git-completion.bash $PKG/usr/share/bash-completion/completions/git

upnort 02-23-2021 08:33 PM

Quote:

Actually, there is another change that probably needs to happen: the icon file doesn't exist.
Fixed in original proposed patch. Thanks.

franzen 02-23-2021 09:53 PM

S-nail bugfix release
https://lists.sdaoden.eu/pipermail/s...ry/001401.html
https://ftp.sdaoden.eu/s-nail-14.9.22.tar.xz

This addresses some issues which came up after everything was rebuild here against glibc 2.33.

drgibbon 02-24-2021 12:39 AM

Quote:

Originally Posted by ZhaoLin1457 (Post 6223803)
I've just tested "startkwayland" as root. This Wayland/Plasma5 did not even start as root, even it works well as a regular user.

Sounds like it's functioning as intended then :p
Quote:

Originally Posted by ZhaoLin1457 (Post 6223803)
who is the owner of my own computer? Me or Slackware?

You're free to run whatever you like, and we have the benefit of free software too so you can make whatever changes you want, yada yada.

I think we already added too much noise to this thread, but for what it's worth, I don't even want to see patches enabling root for Dolphin/Kate, I'm totally fine with upstream's stance on it. But then again, it's not that big of a deal what gibbons think either!

mats_b_tegner 02-24-2021 03:07 AM

CMake 3.19.6
https://blog.kitware.com/cmake-3-19-...-for-download/
https://github.com/Kitware/CMake/rel...-3.19.6.tar.gz

GNU Nano 5.6
https://www.nano-editor.org/news.php
https://www.nano-editor.org/dist/v5/nano-5.6.tar.xz

Thunderbird 78.8.0
https://www.thunderbird.net/en-US/th.../releasenotes/
https://www.mozilla.org/en-US/securi...s/mfsa2021-09/
https://ftp.mozilla.org/pub/thunderb....source.tar.xz

Edit:
Are now available in -current according to the latest ChangeLogs:
Quote:

Wed Feb 24 20:34:08 UTC 2021
ap/nano-5.6-x86_64-1.txz: Upgraded.
d/cmake-3.19.6-x86_64-1.txz: Upgraded.
xap/mozilla-thunderbird-78.8.0-x86_64-1.txz: Upgraded.

mats_b_tegner 02-24-2021 03:08 AM

...please disregard. Got duplicate posts yesterday.

GazL 02-24-2021 04:09 AM

Quote:

Originally Posted by upnort (Post 6223812)
Pat,

Please consider a built-in Slackware way for a user ~/.xsession-errors file. I think Slackware is the only distro I have used not directly supporting the log file. Perhaps the file could be user-defined and enabled/disabled in /etc/default/xsession-log or something similar. Possibly using /etc/xprofile. Or in an /etc/X11/Xsession file.

Would be nice, that's all. Thanks.

The shipped /etc/X11/xdm/Xsession file already supports this logfile. I can't speak to kdm though as I don't install it.

franzen 02-24-2021 12:13 PM

Quote:

Originally Posted by franzen (Post 6222737)
My intention is to have the kde.SlackBuild work better ...

For the record, i needed to change the following to make kde compile from scratch. That may be of interest if compiling a new release to avoid compiling
against packages which on the same run will be replaced.
For me it would feel better if extra-cmake-modules would be moved to d/, as phonon was already moved out of kde/ and needs extra-cmake-modules as build requirement.
Code:

--- /source/kde/kde/kde.SlackBuild      2021-01-08 01:59:19.329008936 +0100
+++ /root/kdebuild/kde/kde.SlackBuild  2021-02-24 08:16:38.672318780 +0100
@@ -515,10 +515,11 @@
 # Build/install libktorrent before compiling kget:
 KDEMODS=" \
  kde4 \
+  frameworks:extra-cmake-modules \
+  plasma-extra:plasma-wayland-protocols \
  frameworks \
  applications-extra:kdiagram \
  kdepim \
-  plasma-extra:plasma-wayland-protocols \
  plasma \
  plasma-extra \
  applications:libktorrent \
--- /source/kde/kde/modules/kdepim      2020-12-10 21:19:57.074104379 +0100
+++ /root/kdebuild/kde/modules/kdepim  2021-02-21 15:48:42.987268923 +0100
@@ -7,6 +7,8 @@
 kidentitymanagement
 kcalutils
 libkgapi
+libkleo
+grantleetheme
 kmime
 ksmtp
 kimap
@@ -21,8 +23,6 @@
 kalarmcal
 kmailtransport
 akonadi-calendar
-libkleo
-grantleetheme
 libkdepim
 pimcommon
 libgravatar


gmgf 02-24-2021 01:39 PM

Quote:

Originally Posted by franzen (Post 6224129)
For the record, i needed to change the following to make kde compile from scratch. That may be of interest if compiling a new release to avoid compiling
against packages which on the same run will be replaced.
For me it would feel better if extra-cmake-modules would be moved to d/, as phonon was already moved out of kde/ and needs extra-cmake-modules as build requirement.
Code:

--- /source/kde/kde/kde.SlackBuild      2021-01-08 01:59:19.329008936 +0100
+++ /root/kdebuild/kde/kde.SlackBuild  2021-02-24 08:16:38.672318780 +0100
@@ -515,10 +515,11 @@
 # Build/install libktorrent before compiling kget:
 KDEMODS=" \
  kde4 \
+  frameworks:extra-cmake-modules \
+  plasma-extra:plasma-wayland-protocols \
  frameworks \
  applications-extra:kdiagram \
  kdepim \
-  plasma-extra:plasma-wayland-protocols \
  plasma \
  plasma-extra \
  applications:libktorrent \
--- /source/kde/kde/modules/kdepim      2020-12-10 21:19:57.074104379 +0100
+++ /root/kdebuild/kde/modules/kdepim  2021-02-21 15:48:42.987268923 +0100
@@ -7,6 +7,8 @@
 kidentitymanagement
 kcalutils
 libkgapi
+libkleo
+grantleetheme
 kmime
 ksmtp
 kimap
@@ -21,8 +23,6 @@
 kalarmcal
 kmailtransport
 akonadi-calendar
-libkleo
-grantleetheme
 libkdepim
 pimcommon
 libgravatar


I have already posted twice this problem:

https://www.linuxquestions.org/quest...ml#post6205270

upnort 02-24-2021 03:56 PM

Pat,

Proposed rc.6/rc.K patch:

Code:

diff -urN sysvinit-scripts/scripts/rc.6 sysvinit-scripts.new/scripts/rc.6
--- sysvinit-scripts/scripts/rc.6        2020-12-19 19:52:37.323990000 -0600
+++ sysvinit-scripts.new/scripts/rc.6        2021-02-24 16:13:41.185259375 -0600
@@ -71,9 +71,9 @@
  fi
 fi
 
-# Run any local shutdown scripts:
+# Run the local shutdown script:
 if [ -x /etc/rc.d/rc.local_shutdown ]; then
-  /etc/rc.d/rc.local_shutdown stop
+  /etc/rc.d/rc.local_shutdown
 fi
 
 # Stop the Apache web server:
@@ -132,6 +132,7 @@
 done
 # If fuser was run, let it have some delay:
 if [ ! -z "$FUSER_DELAY" ]; then
+  echo "Allowing time for fuser to complete."
  sleep $FUSER_DELAY
 fi
 
diff -urN sysvinit-scripts/scripts/rc.K sysvinit-scripts.new/scripts/rc.K
--- sysvinit-scripts/scripts/rc.K        2020-01-13 12:56:53.458373000 -0600
+++ sysvinit-scripts.new/scripts/rc.K        2021-02-24 16:14:50.289405627 -0600
@@ -42,9 +42,9 @@
  /sbin/accton off
 fi
 
-# Run any local shutdown scripts:
+# Run the local shutdown script:
 if [ -x /etc/rc.d/rc.local_shutdown ]; then
-  /etc/rc.d/rc.local_shutdown stop
+  /etc/rc.d/rc.local_shutdown
 fi
 
 # Stop the Apache web server:
@@ -73,6 +73,7 @@
 done
 # If fuser was run, let it have some delay:
 if [ ! -z "$FUSER_DELAY" ]; then
+  echo "Allowing time for fuser to complete."
  sleep $FUSER_DELAY
 fi
 
@@ -81,7 +82,7 @@
 /bin/umount -v -a -l -f -r -t nfs,nfs4,smbfs,cifs | tr -d ' ' | grep successfully | sed "s/:successfullyunmounted/ has been successfully unmounted./g"
 
 # Shut down PCMCIA devices:
-if [ -x /etc/rc.d/rc.pcmcia ] ; then
+if [ -x /etc/rc.d/rc.pcmcia ]; then
  /etc/rc.d/rc.pcmcia stop
  # The cards might need a little extra time here to deactivate:
  sleep 5


upnort 02-24-2021 04:44 PM

Pat,

Some people might want sysctl stdout spew during the boot and some might not. Having an /etc/default file allows easier administration without editing the rc.S script. Proposed patches:

Code:

# /etc/default/sysctl

# Parameters to support /etc/rc.d/rc.S.
# Use this file to override defaults.

# -e Use this option to ignore errors about unknown keys.
# --system Load settings from all system configuration files.
# -q Use this option to not display the values to stdout.

SYSCTL_OPTIONS="-e --system"

Code:

diff -urN sysvinit-scripts/scripts/rc.S sysvinit-scripts.new/scripts/rc.S
--- sysvinit-scripts/scripts/rc.S        2020-12-19 19:53:30.841987000 -0600
+++ sysvinit-scripts.new/scripts/rc.S        2021-02-24 16:37:05.286250754 -0600
@@ -330,13 +330,17 @@
 fi
 
 # Configure kernel parameters:
+SYSCTL_OPTIONS="-e --system"
+if [ -r /etc/default/sysctl ]; then
+  . /etc/default/sysctl
+fi
 if [ -x /sbin/sysctl -a -r /etc/sysctl.conf ]; then
-  echo "Configuring kernel parameters:  /sbin/sysctl -e --system"
-  /sbin/sysctl -e --system
+  echo "Configuring kernel parameters:  /sbin/sysctl $SYSCTL_OPTIONS"
+  /sbin/sysctl $SYSCTL_OPTIONS
 elif [ -x /sbin/sysctl  ]; then
-  echo "Configuring kernel parameters:  /sbin/sysctl -e --system"
+  echo "Configuring kernel parameters:  /sbin/sysctl $SYSCTL_OPTIONS"
  # Don't say "Applying /etc/sysctl.conf" or complain if the file doesn't exist
-  /sbin/sysctl -e --system 2> /dev/null | grep -v "Applying /etc/sysctl.conf"
+  /sbin/sysctl $SYSCTL_OPTIONS 2> /dev/null | grep -v "Applying /etc/sysctl.conf"
 fi
 
 # Check all the non-root filesystems:


upnort 02-24-2021 05:23 PM

Pat, Proposed rc.httpd patch:

Code:

--- rc.httpd        2021-02-24 17:21:50.145953292 -0600
+++ rc.httpd.new        2021-02-24 17:22:05.193746418 -0600
@@ -12,9 +12,11 @@
 
 case "$1" in
  'start')
+    echo "Starting the Apache web server:  /usr/sbin/apachectl -k start"
    /usr/sbin/apachectl -k start
  ;;
  'stop')
+    echo "Stopping the Apache web server."
    /usr/sbin/apachectl -k stop
    pkill -f /usr/sbin/httpd
    # Remove both old and new .pid locations:
@@ -29,12 +31,15 @@
    /usr/sbin/apachectl -k start
  ;;
  'restart')
+    echo "Restarting the Apache web server:  /usr/sbin/apachectl -k restart"
    /usr/sbin/apachectl -k restart
  ;;
  'graceful')
+    echo "Starting the Apache web server:  /usr/sbin/apachectl -k graceful"
    /usr/sbin/apachectl -k graceful
  ;;
  'graceful-stop')
+    echo "Stopping the Apache web server."
    /usr/sbin/apachectl -k graceful-stop
  ;;
  *)


upnort 02-24-2021 05:47 PM

Pat,

Proposed rc.inet2/rc.sshd patches for consistency with other rc.d scripts:

Code:

--- rc.sshd        2021-02-24 17:38:04.400663336 -0600
+++ rc.sshd.new        2021-02-24 17:40:17.676860312 -0600
@@ -7,6 +7,7 @@
 fi
 
 sshd_start() {
+  echo "Starting the SSH daemon:  /usr/sbin/sshd"
  # Create host keys if needed.
  if [ ! -f /etc/ssh/ssh_host_dsa_key ]; then
    /usr/bin/ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''
@@ -27,6 +28,7 @@
 }
 
 sshd_stop() {
+  echo "Stopping the SSH daemon."
  killall sshd
 }

Code:

--- rc.inet2        2021-02-24 17:41:55.646537017 -0600
+++ rc.inet2.new        2021-02-24 17:45:55.863299565 -0600
@@ -15,6 +15,8 @@
 
 # At this point, we are (almost) ready to talk to The World...
 
+# Tell the viewers what's going to happen.
+echo "Launching network daemons."
 
 # If there is a firewall script, run it before enabling packet forwarding.
 # See the HOWTOs on http://www.netfilter.org/ for documentation on
@@ -56,7 +58,7 @@
  # to mount them. If they are not running, attempting to mount an NFS
  # partition will cause mount to hang, or at least result in unreliable
  # operation. Keep this in mind if you plan to mount unlisted NFS
-  # partitions...
+  # partitions...
  # If you have uncommented NFS partitions in your /etc/fstab, rc.rpc is run
  # whether it is set as executable or not. If you don't want to run it,
  # comment the NFS partitions out in /etc/fstab or erase/rename rc.rpc.
@@ -109,7 +111,6 @@
 
 # Start the OpenSSH SSH daemon:
 if [ -x /etc/rc.d/rc.sshd ]; then
-  echo "Starting OpenSSH SSH daemon:  /usr/sbin/sshd"
  /etc/rc.d/rc.sshd start
 fi
 
@@ -150,3 +151,5 @@
 #  echo "Starting system status server:  /usr/sbin/rwhod"
 #  /usr/sbin/rwhod
 # fi
+
+echo "Finished launching network daemons."



All times are GMT -5. The time now is 11:29 PM.