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.
Did you use for real the Mesa Gallium i915g driver? I for one I do this.
Yes, it's visible faster than the classic i915 driver, BUT from my own experience, it's also visible more buggy than the classic one and some features seems to be yet to be implemented.
In other hand, i915g supports only GMA3100 and GMA3150 graphics, while the classic i915 supports also GMA900, GMA950 and previous Intel graphics.
Anyway, I am able to test this particular driver only in GMA3100 graphics, which are sported by a HP Elite dc7800 USDT box of mine. A quite decent box otherwise, with a Core2 Duo E8500 at 3,17 GHz and 4GB DDR2 800MHz memories in SODIMM format. And a 160GB laptop hard drive at 7200RPM. Believe or not, it runs quite acceptable the Plasma5 from Slackware 15.0. And XFCE rocks.
So, while I hate to say this, I confess that I believe that "i915g is not ready yet". For real. I will love it to be ready.
Last edited by LuckyCyborg; 12-15-2022 at 02:23 PM.
Introduce a new background monitoring service. This allows desktop environments to list applications that are running in background, that is, sandboxed applications running without a visible window. Desktop environments can display these background running applications in their interfaces, and allow users to control their execution.
Introduce the Global Shortcuts portal. This portal allows applications to register and receive keyboard shortcuts even when they're not focused. This was a highly requested feature, especially on Wayland desktops. There are improvements to come, but portal backends can now implement this new portal.
===============================================
NetworkManager-1.40.8
Overview of changes since NetworkManager-1.40.6
===============================================
* Fixed a bug that caused devices (MACsec in particular) to be stuck in
UNAVAILABLE state and not transition to DISCONNECTED if the carrier was
ready too early.
* Improved interoperability of MACsec with some Aruba switches by allowing
CKN shorter than 64 characters.
* Fixed an assertion failure when restarting NetworkManager with MACsec
links configured.
* Fixed a possible DHCP helper crash when handling failure to connect to
D-Bus.
* Corrected calculation of expiration time for items configured from IPv6
neighbor discovery messages.
* Various fixes for platforms that don't allow unaligned memory access.
Been in the process to moving from 14.2 server with lots of old and new stuff ...
First the default kconsole "appearance" profile should be "Linux Colors"
Man,that electric blue background on MC was blinding! ... at least start with the old deep blue ! Took me an hour to find that pita.
I now have Psensor 1.2.1 running on Slack15.0 ... that was fun building ...
(plus hddtemp00.3beta15-x86_64-4_Sbo )
Very nice when running ZFS 2.1.6 with BOD ( box of drives ) and want to look at the temps ..
also has remote server reading mode ...
| - - - -
I have the gpsd 3.24 ( symlink /usr/bin/python change to python3.9 )
add export pythonpath="/usr/local/lib64/python3.9/site-packages/"
works with timemaster linuxptp-3.1.1 for ntp plus ptp time keeping
Ksysguard (14.2 version) ... simple cpu / mem / network display (15.0 now is "system monitor history") but it has all the "overview/Tools thing I don't need to look at 99.9 percent of the time ... ! Oh collapse, the sidebar a million times !
| - - --
I am currently running a mutt of 14.2Plus15.0 for latest kernel with thunderbolt networking ... this is not maintainable . But this has worked out well for now running all the old software plus most new things I want to run.
I tried upgrading 14.2 -> 15.0 but it just couldn't work for this long modified system....
I've been running slackware since the 1990's , what a journey .
Its great that slackware has a future again !
Sorry to post this in this thread as it is not any request for the next Slackware version, only some advice and answers to another post... Please skip this message if you are only interested in requests!
Quote:
Originally Posted by dcb_tahoe
Been in the process to moving from 14.2 server with lots of old and new stuff ...
Been there, done that. To make things worse I also have multiple machines simultaneously running different versions of Slackware and sharing the same home directories on a network drive.
Quote:
Originally Posted by dcb_tahoe
I now have Psensor 1.2.1 running on Slack15.0 ... that was fun building ...
(plus hddtemp00.3beta15-x86_64-4_Sbo )
Quote:
Originally Posted by dcb_tahoe
Ksysguard (14.2 version) ... simple cpu / mem / network display (15.0 now is "system monitor history")
For similar purposes I use mrtg. It queries machines and other network equipment of things like temperatures, fan-speeds, CPU, memory, network and disk usage. Those queries are done using snmp and the results are presented as graphs on a web page. However, mrtg only samples data every 5 minute.
Quote:
Originally Posted by dcb_tahoe
I tried upgrading 14.2 -> 15.0 but it just couldn't work for this long modified system....
This is the tricky part and this piece of advice now comes a little late. All those modifications need to be documented at the time the modification is made and IMHO the best way to document modifications like extra software and configurations is to place them in custom Slackware packages which you keep somewhere to be able to quickly and easily reproduce your system. You will not make packages of home directories, so you will need some other backup routine for those.
When upgrading to a new version of Slackware, some of those packages can be reused as is, but most of them will need to be recompiled or reconfigured. But at least, you will know exactly what software you have used and what you want to use again.
Some of that software might have become unmaintained and suffer from bit rot which makes it not possible to compile on the new version of Slackware. If so, you might be able to apply some easy patches, reuse the old binary package, possible together with a new custom package with binary library files from the old version of Slackware or you might have to resort on giving up on that software and instead perhaps look for a replacement.
So all those custom Slackware packages that you make are useful both for backup purposes in a bare metal recovery situation and as documentation the day you want to upgrade to a newer version of Slackware. Many people might become tempted to use some kind of disk cloning software for backup purposes. Yes, it might work as a backup, but the day you want to upgrade you will be in the dark about all those custom additions and modifications.
Upgrading is the easy part as software mostly is backwards compatible. However, when running multiple versions of Slackware sharing the same home directory some software suddenly finds itself downgraded when you log in to an older version of Slackware. Some software are not forwards compatible with its configurations files. For such software as Wine and KDE I have custom Slackware packages with files like:
/etc/profile.d/wine.sh
Code:
#!/bin/sh
# Added by henca to allow different versions of wine to coexist
WINEPREFIX=$HOME/.wine_slack142
export WINEPREFIX
The above example however is not enough for wine if you have compiled both 32- and 64-bit versions of wine as those are not able to share the same ~/.wine directory.
Of course, this followed by a manually fixing of packages database, because of this issue, upgradepkg walking over packages and renaming files from /var/log/packages & Co. without doing nothing else.
However, this incident demonstrates that upgradepkg is capable to broke the packages database by trying installing a broken package.
So, there's my (additional) request for -current:
The upgradepkg to check the consistency of incoming package BEFORE renaming the /var/log/packages files, and eventually to add a switch to installpkg (executed 2 times by upgradepkg) to skip this check on calls by upgradepkg - this may also speedup the process of upgrading packages.
Last edited by LuckyCyborg; 12-18-2022 at 05:52 AM.
(maybe off-topic) Two days ago I installed OpenSUSE Leap 15.4 to see how they manage the BTRFS snapshots. They make snapshots too often for my taste but in such a case this would have helped, either restoring only the packages database from the most recent snapshot of (probably better in this case) restoring the full /. But for Slackware this disk layout (see the attached /etc/fstab) would need an adaptation as by default the subvolume /var has copy on write disabled and is not included in the snapsphots of / . This remind me the discussions about /var/lib vs /var/log in this forum a while ago.
Last edited by Didier Spaier; 12-18-2022 at 06:42 AM.
Again, as by aaa_libraries incident generated by XZ upgrading, as described in detail there: https://www.linuxquestions.org/quest...es-4175719905/, I started to believe that we have found an upgradepkg logic issue which must be cared:
the upgradepkg should check the consistency of incoming package BEFORE renaming the /var/log/packages files, and eventually to add a switch to installpkg (executed 2 times by upgradepkg) to skip this check on calls by upgradepkg - this may also speedup the process of upgrading packages.
Last edited by LuckyCyborg; 12-18-2022 at 07:40 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
