Slackware 14.0 RC4

guanx · 09-07-2012, 02:12 PM

Quote:

Originally Posted by cwizardone

...

Edit in: Actually, it doesn't really matter. I just re-installed the NM icon to the system tray and it looks just like the one on the panel, just smaller, of course. It would appear the solution to your problem is really a matter of picking the right combination of desktop "decorations" and "themes" to make the NM icon appear brighter against a dark background.
Here is another image of both the NM widget on the panel and the NM icon in the system tray.

You are right. This is what I intended to show with my screenshots.

My problem is: The "right theme" does not appear to be in the default installation. This is not the case in a previous slackware-current with KDE 4.8.4.

I will try the theme you suggested as soon as I've worked around the bug that additionally installed themes don't appear in system settings.

since2000 · 09-07-2012, 02:43 PM

Hi everyone,

New here but long time Slackware user (since2000). Since I'm new to posting, I hope this entry lands in the right spot! I'm having a problem that started after I moved from RC2 to RC4. Once I start either KDE or Xfce (and I haven't tried others), after a few moments my screen starts to flicker rapidly and the cpu spikes to around 85% where it stays. The X process is the highest at 22% of CPU, then others such as kworker and udevd are each at 10%. I usually can get no mouse or keyboard response and have to ctrl-alt-bs to get out of X. I've narrowed it down to whether power management settings are enabled for whichever desktop environment I am in. I tested it many times: setting Dim Display in KDE to one minute or Power Manager Monitor in Xfce, the issue occurs, and when these are set to Never the issue does not occur. This laptop is fairly new but has been running Slackware with updates as they appeared in -current since 13.37 without this issue occurring. Mostly wild guessing makes me think it's in the latest kernel, but I suppose this late in the game 3.2.28 isn't likely to be changed (as noted in changelog).

My laptop is a Samsung w/i3-2350M processor (intel graphics). I perform a clean install from -current (64-bit) after most any update to -current, as I did in this case. It seems I may be alone in having this issue, so perhaps it's a combination of my particular hardware or BIOS and the latest kernel (or other package from RC3 or RC4). I wanted to post something here to see whether anyone else has had this occur after RC2. Thanks.

guanx · 09-07-2012, 06:52 PM

Quote:

Originally Posted by guanx

When saving a file using mcedit, mcedit tries to create a temporary file "tmp/cooleditXXXXXX" which should actually be "/tmp/cooleditXXXXXX". So mcedit cannot save files unless there happened to be a "tmp" dir.

However, the "save as" function works as expected. And this bug is not there when I'm root.

Ok it's this one: https://www.midnight-commander.org/ticket/2832

So what about an update of mc?

bormant · 09-08-2012, 02:31 AM

From UPGRADE.TXT:

Quote:

7. IMPORTANT! *Before* attempting to reboot your system, you will need
to make sure that the bootloader has been updated for the new kernel!
First, be sure your initrd is up to date (if you use one). You can
build a new initrd automatically by running this command:

/usr/share/mkinitrd/mkinitrd_command_generator.sh | bash

If you use LILO, make sure the paths in /etc/lilo.conf point to a valid
kernel and then type 'lilo' to reinstall LILO. If you use a USB memory
stick to boot, copy the new kernel to it in place of the old one.

mkinitrd_command_generator.sh (mkinitrd) will use running kernel version, not new kernel.
Upgraded 13.37 system before reboot still run it's old kernel, so initrd will be not for new kernel from 14.0. And rebooting with generic kernel will fail.

To pack new kernel modules into initrd we need to pass explicit kernel version to script,
for Slackware64 we need:
/usr/share/mkinitrd/mkinitrd_command_generator.sh -k 3.2.28 | bash

for Slackware with -smp kernel we need:
/usr/share/mkinitrd/mkinitrd_command_generator.sh -k 3.2.28-smp | bash

for Slackware with non-smp kernel we need:
/usr/share/mkinitrd/mkinitrd_command_generator.sh -k 3.2.28 | bash

So, this part of UPGRADE.TXT needs some revision before release.

Sorry for my English.

aocab · 09-08-2012, 02:11 PM

From changelog:

Quote:

Fri Sep 7 20:27:46 UTC 2012
a/dcron-4.5-i486-4.txz: Rebuilt.
After following the discussion about it on LQ, it seems better to not
direct script output in run-parts to /dev/null, since the default crontab
does that already. That way if someone wants to get cron job output
mailed to them it's easy to do by editing the crontab. Thanks to NoStressHQ.

When removing the "1> /dev/null" from the crontab entry:
40 12 * * * /usr/bin/run-parts /etc/cron.daily
no message is sent to root because the scripts (in cron.daily)
do no output anything to stdout.

At some point in time there used to be an "echo $SCRIPT:" in run-parts.
If something got output to stdout and it was not redirected
to /dev/null in the crontab entry root would get a message:

Code:

/etc/cron.daily/certwatch:
/etc/cron.daily/logrotate:
/etc/cron.daily/slocate:

volkerdi · 09-08-2012, 03:02 PM

Quote:

Originally Posted by aocab

When removing the "1> /dev/null" from the crontab entry:
40 12 * * * /usr/bin/run-parts /etc/cron.daily
no message is sent to root because the scripts (in cron.daily)
do no output anything to stdout.

The provided scripts do not produce any output, but perhaps some that have been added by the admin do. The fix is intended to let that output escape from run-parts so that an edit to the crontab would allow mails to occur.

aocab · 09-08-2012, 05:29 PM

Quote:

Originally Posted by volkerdi

The provided scripts do not produce any output, but perhaps some that have been added by the admin do. The fix is intended to let that output escape from run-parts so that an edit to the crontab would allow mails to occur.

Thank you for the feedback.
That is kind of what I figured with all the recent changes.
I just liked the way it used to work.

Cheers

mats_b_tegner · 09-08-2012, 06:11 PM

I have an issue with the latest xine packages. (xine-lib 1.1.21 and xine-ui 0.99.7) Opening a file with Ctrl+o does not work. Opening a file with Open loaction (Alt+m) does work. Anybody else experiencing this?

Mats

PS. Sadly I have no error messages at all...
Opening a file from the command line also works BTW

andrew.46 · 09-08-2012, 06:29 PM

Quote:

Originally Posted by mats_b_tegner

I have an issue with the latest xine packages. (xine-lib 1.1.21 and xine-ui 0.99.7) Opening a file with Ctrl+o does not work. Opening a file with Open loaction (Alt+m) does work. Anybody else experiencing this?

Same here.......

willysr · 09-08-2012, 07:02 PM

It works here, both Alt+M and CTRL+O (-Current 32 bit)

andrew.46 · 09-08-2012, 07:24 PM

Quote:

Originally Posted by willysr

It works here, both Alt+M and CTRL+O (-Current 32 bit)

Interesting, I have just checked again and on 64bit -current CTRL+o definitely does not work. Curious...

willysr · 09-08-2012, 07:35 PM

All the basic shortcuts are working perfectly here
i tested all the basic operations prior sending it to Pat for inclusion to Slackware 14.0
Did you try it also on 32 bit machine? or only on 64bit?

PS: I'm thinking this might be a 64bit-spesific bug

mats_b_tegner · 09-08-2012, 07:39 PM

Quote:

Originally Posted by willysr

All the basic shortcuts are working perfectly here
i tested all the basic operations prior sending it to Pat for inclusion to Slackware 14.0
Did you try it also on 32 bit machine? or only on 64bit?

The shortcuts do work, but my problem is that the file(s) doesn't open at all...

willysr · 09-08-2012, 07:57 PM

I tried with some of my collections of movies and the files were opened just fine here

andrew.46 · 09-08-2012, 08:03 PM

Quote:

Originally Posted by willysr

All the basic shortcuts are working perfectly here
i tested all the basic operations prior sending it to Pat for inclusion to Slackware 14.0
Did you try it also on 32 bit machine? or only on 64bit?

PS: I'm thinking this might be a 64bit-spesific bug

I cranked up my old laptop before realising that it has a 64bit installation of -current as well

. Anyway on my 2nd 64bit machine the problem is the same: ctrl+o does not open the file. No great hints on the commandline but looks like ctrl+o uses a file://<filename> syntax and 'file://' is being read literally (as part of either the path or filename), thus the open fails.