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.
Regarding veusz, I was able to build 3.2.1 with the current PyQT packages by changing this line in the SlackBuild:
changing 'python' to 'python3'.
After that I had no trouble building veusz.
that's a good news!
as python-2.x is deprecated I suppose the veusz maintainer should be interested in this and might change the script on SBo too: please report this to him.
Another request for a newer version of poppler...preferably >=0.82, as that's apparently required for using a modern-and-maintained version of Frescobaldi.
Sorry to interrupt the profound meditation, but I got hit (again) by a -current (ARM) breakage and would like to ask (again), if the one(s) that are/is composing the changelog could be so kind, to add some "anesthetics" in the description of the updates that might break the system, that's before getting hit with the baseball bat - kind of a warning sentence.
I must admit, I'm able to fix such things on my own, after a certain bitching amount, but it just sucks to have it delivered like that for other, maybe not so savvy, users.
Basically, after the 28th Feb 2020 update I got two processes not launching anymore, because their default path for the pid files was somewhere in /var/run/subfolders/ and the update was mounting /run over /var/run, making the those pid folders unavailable.
I understand the background and frankly, didn't know about it until now: https://refspecs.linuxfoundation.org...s/ch05s13.html
My simple proposal for such future "hits" would be, for example, to change the actual:
Code:
Tue Feb 25 08:08:08 UTC 2020
....
a/sysvinit-scripts-2.1-noarch-24.txz: Rebuilt.
rc.S: make /var/run a bind mount to /run. Thanks to Robby Workman.
+ and f*** everyone and everything else :)
to
Code:
Tue Feb 25 08:08:08 UTC 2020
....
a/sysvinit-scripts-2.1-noarch-24.txz: Rebuilt.
rc.S: make /var/run a bind mount to /run. Thanks to Robby Workman.
+ do move your crap from /var/run/subfolders to /run if you still want (all of) your processes launching
Sorry to interrupt the profound meditation, but I got hit (again) by a -current (ARM) breakage and would like to ask (again), if the one(s) that are/is composing the changelog could be so kind, to add some "anesthetics" in the description of the updates that might break the system, that's before getting hit with the baseball bat - kind of a warning sentence.
I must admit, I'm able to fix such things on my own, after a certain bitching amount, but it just sucks to have it delivered like that for other, maybe not so savvy, users.
It would be nice to warn about breakage ahead of time, but generally we don't know about it until problems are reported. Otherwise we'd fix them before the updates shipped.
If an update is dangerous, and the danger can't be avoided (and is known in advance), I warn about it. One example would be when the .la files were removed.
Quote:
Basically, after the 28th Feb 2020 update I got two processes not launching anymore, because their default path for the pid files was somewhere in /var/run/subfolders/ and the update was mounting /run over /var/run, making the those pid folders unavailable.
I understand the background and frankly, didn't know about it until now: https://refspecs.linuxfoundation.org...s/ch05s13.html
My simple proposal for such future "hits" would be, for example, to change the actual:
Code:
Tue Feb 25 08:08:08 UTC 2020
....
a/sysvinit-scripts-2.1-noarch-24.txz: Rebuilt.
rc.S: make /var/run a bind mount to /run. Thanks to Robby Workman.
+ and f*** everyone and everything else :)
to
Code:
Tue Feb 25 08:08:08 UTC 2020
....
a/sysvinit-scripts-2.1-noarch-24.txz: Rebuilt.
rc.S: make /var/run a bind mount to /run. Thanks to Robby Workman.
+ do move your crap from /var/run/subfolders to /run if you still want (all of) your processes launching
In this instance, /run doesn't get bind mounted over /var/run until the next reboot, so it makes no sense to try to move anything from /var/run to /run. It could only make things worse since the daemons aren't looking in /run and it isn't yet duplicated in /var/run.
Once you do reboot, /run is a tmpfs, so anything you tried to move there from /var/run is going to be gone anyway. This is why the fixes had to happen in the init scripts.
Anyway, sorry about that. I suspected that particular change might cause some issues but hadn't run into any yet myself.
In this instance, /run doesn't get bind mounted over /var/run until the next reboot, so it makes no sense to try to move anything from /var/run to /run. It could only make things worse since the daemons aren't looking in /run and it isn't yet duplicated in /var/run.
Once you do reboot, /run is a tmpfs, so anything you tried to move there from /var/run is going to be gone anyway. This is why the fixes had to happen in the init scripts.
Anyway, sorry about that. I suspected that particular change might cause some issues but hadn't run into any yet myself.
You're right and thanks for clarifying this for other users as my technical recommendation with "moving" was wrong and misleading.
I'm creating the required /run/process_subfolder/ in the rc. file used to launch the processes, in the start section, just before launching the actual process.
I only have two packages that I compiled on my own (not from SlackBuilds) and didn't bother to specify where to put the pid files during the package configuration - configure script, not sure such flags are available, nor did I care too much about pid files location in the processes configuration files, but will definitely check the next time I upgrade them.
Distribution: Slackware64 15.0 (started with 13.37). Testing -current in a spare partition.
Posts: 934
Rep:
Thanks
Code:
Sat Mar 28 05:48:42 UTC 2020
xap/audacious-4.0-x86_64-3.txz: Rebuilt.
Also support GTK+ interface, including a .desktop file for it.
xap/audacious-plugins-4.0-x86_64-3.txz: Rebuilt.
Rebuilt with --enable-gtk.
and it seems that audacious is smart enough to save qt skin state
separately from gtk skin state, e.g. running qt with qt gui and gtk with Winamp skin.
(but volume and playlist remain the same).
Last edited by Paulo2; 03-28-2020 at 09:27 AM.
Reason: s/remains/remain/
man: can't open /usr/man/./version: No such file or directory
No manual entry for lsof
Doing a bit of digging I see that the first line in the roff source, in Lsof.8, is causing the error. The first line has:
Quote:
.so ./version
Which is a request to read in a file, in this case, ./version, and that file does not exist in the packaged version hence the error. The contents of this file are:
Quote:
.ds VN 4.93.2
I checked the buildscripts and source files and this problem only seems to affect -current. The version in 14.2 does not make a request to read this file (but I don't have earlier versions to test if this problem exists there).
Here is a possible patch to lsof.SlackBuild that should fix this as well as another request later.
Apparently, with man-db, MANPATH needs to be empty, and /etc/profile.d/java.sh still sets it.
According to man page for manpath if $MANPATH is prefixed with a colon, ends with a colon, or has a double colon "::" then the variable is combined with the list determined by man_db.conf. See the full man-db path list from the "manpath" command (where you may notice the duplicate java path entries).
The java profile files are setting $MANPATH with a prefixed colon. So the $MANPATH value will get appended to the list from man-db.
The profile files for java under /etc/profile.d probably do not need to set $MANPATH at all. It is causing a duplicate entry for java's man directory as the /etc/man_db.conf already includes a list entry for java.
According to man page for manpath if $MANPATH is prefixed with a colon, ends with a colon, or has a double colon "::" then the variable is combined with the list determined by man_db.conf. See the full man-db path list from the "manpath" command (where you may notice the duplicate java path entries).
The java profile files are setting $MANPATH with a prefixed colon. So the $MANPATH value will get appended to the list from man-db.
The profile files for java under /etc/profile.d probably do not need to set $MANPATH at all. It is causing a duplicate entry for java's man directory as the /etc/man_db.conf already includes a list entry for java.
This report was not about a duplicate entry. It' annoying, but harmless. What is worse is that IF manpath is set, most applications who use man pages, rely on it, and at the moment it only contains the java stuff. However, if manpath is _not_ set, other applications are using the default (correct) path.
You can verify this with "xman" with and without $MANPATH set.
I request this again , cause i encounter another asrock motherboard , with same problem explained some time ago and ingored.
In a HUGE kernel , we have
BLK_DEV_FD=y
SOME MOTHERBOARDS , when boot a cd/dvd or usb , have problems with the device order , as example
when plug a usb stick
usb = sda
hdd = sdb
install from usb to sdb , but , when remove the usb device , then
hdd = sda
and boot fails , then my request is change in the huge config
Quote:
BLK_DEV_FD=y to BLK_DEV_FD=m
That solve the problems under asrock extreme 4 , and other asrock motherboards.
Than problem i detect using grub , im not sure if lilo/elilo fails , but probably YES , cause device change position.
@USUARIONUEVO. When booting a removable device, always name it by UUID.
In /etc/default/grub, check that this line be not commented:
GRUB_DISABLE_LINUX_UUID=false
But *not* GRUB_DISABLE_LINUX_UUID=true
I try to test uncommenting that.
I need edit fstab , when plug or unplug some devices sdX changing positions, only i fix, rebuilding kernel , and change yes to module under BLK_DEV_FD option.
Last edited by USUARIONUEVO; 03-29-2020 at 04:34 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
