Slackware 14 RC 2 Announced

tomac.pl · 08-21-2012, 01:51 PM

Upgraded to RC2, so far everything looks fine. I've noticed a small bug in "About Audacious" dialog box in Audacious 3.3.1 - the contents of "Credits" tab are:

Unable to load /usr/share/audacious/AUTHORS; check your installation.

and under "License" tab there is:

Unable to load /usr/share/audacious/COPYING; check your installation.

tpreitzel · 08-21-2012, 08:17 PM

Quote:

Originally Posted by tomac.pl

Upgraded to RC2, so far everything looks fine. I've noticed a small bug in "About Audacious" dialog box in Audacious 3.3.1 - the contents of "Credits" tab are:

Unable to load /usr/share/audacious/AUTHORS; check your installation.

and under "License" tab there is:

Unable to load /usr/share/audacious/COPYING; check your installation.

Personally, I compiled these packages myself before suggesting to Pat that he replace 3.2 with 3.3 so I can't confirm your problem with the OFFICIAL package since I'm using mine. However, I don't have those missing files as you allegedly do. I doubt that Pat's package lacks those two files, but I could be wrong. If I were you, I'd recheck your installation of audacious-3.3.1 until someone can either confirm or refute the problem with your particular installation. On my computer, the installation of audacious v3.3.1 is apparently flawless and it certainly runs like it so far.

guanx · 08-21-2012, 09:47 PM

Quote:

Originally Posted by tomac.pl

Upgraded to RC2, so far everything looks fine. I've noticed a small bug in "About Audacious" dialog box in Audacious 3.3.1 - the contents of "Credits" tab are:

Unable to load /usr/share/audacious/AUTHORS; check your installation.

and under "License" tab there is:

Unable to load /usr/share/audacious/COPYING; check your installation.

Yes, pretty clear.

I took 10 seconds to checked the contents of the audacious 32-bit slackware package. There are no such files.

bnguyen · 08-21-2012, 09:59 PM

Is there a chance PowerTOP be upgraded? Version 2.1 comes with various bug-fixes, some new nice features, and the manpage and translations are back.

The SlackBuild needs a small addition to build though.

Code:

--- ./powertop.SlackBuild.orig	2012-05-24 02:02:46.000000000 +0700
+++ ./powertop.SlackBuild	2012-08-22 09:51:21.594004601 +0700
@@ -74,6 +74,7 @@
   \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \
   -exec chmod 644 {} \;
 
+LDFLAGS="-lz -lresolv" \
 CFLAGS="$SLKCFLAGS" \
 CXXFLAGS="$SLKCFLAGS" \
 ./configure \

tomac.pl · 08-21-2012, 11:53 PM

Quote:

Originally Posted by tpreitzel

Personally, I compiled these packages myself before suggesting to Pat that he replace 3.2 with 3.3 so I can't confirm your problem with the OFFICIAL package since I'm using mine. However, I don't have those missing files as you allegedly do. I doubt that Pat's package lacks those two files, but I could be wrong. If I were you, I'd recheck your installation of audacious-3.3.1 until someone can either confirm or refute the problem with your particular installation. On my computer, the installation of audacious v3.3.1 is apparently flawless and it certainly runs like it so far.

Sorry for this, you are right - I should have checked at least contents of the package before posting this bug report.

Like guanx, I've checked the contents of the package which I installed (64-bit version) and it does not contain these files in /usr/share/audacious directory - however, I've found these files in /usr/doc/audacious-3.3.1. I've checked slackbuild used for Audacious, and found the following code it it:

Code:

# Add a documentation directory:
mkdir -p $PKG/usr/doc/${PKGNAM}-$VERSION
cp -a \
  AUTHORS COPYING INSTALL Mercurial-Access NEWS README doc/* \
  $PKG/usr/doc/${PKGNAM}-$VERSION

# ...

# We got these already, thanks.
rm -f $PKG/usr/share/audacious/{AUTHORS,COPYING}

I think that the simplest solution would be to add symlinks to these files in /usr/share/audacious directory, so we don't have them duplicated, and Audacious still works correctly.

kabamaru · 08-22-2012, 07:24 AM

So... I'm testing RC2 on VirtualBox and I noticed this weird behavior: when I plug-in a usb stick and double-click on its icon (on Xfce's desktop), it gets mounted not in /media/<volume_name>, but in /run/media/<username>/<volume_name> and of course I haven't write permissions there.

Any ideas? Or can anybody reproduce this?

kwll · 08-22-2012, 07:39 AM

Quote:

Originally Posted by tpreitzel

Remember THAT bug? Well, it's nearly 3 years later and the bug remains. I'm unsure if the bug is specifically related to Slackware or GNU/Linux in general since my solitary distribution of GNU/Linux is Slackware. I suspect a combination of problems.

For those members who aren't familiar with this bug, the main symptom is read or mount failure of a newly inserted disc. If the disc is inserted in the drive at boot, the disc can generally be read, mounted, and written without error. If the disc is inserted into the drive AFTER the operating system is booted, then the failures to read and mount begin. If a user manually reloads udev's rules and ejects the disc and then reinserts the disc, then it's generally possible to read and mount the disc without error ... but not always. In my experience the only method of ensuring an accurate read, mount, or write to an optical disc REQUIRES the disc to be inserted into the drive BEFORE the operating system is booted. The motherboard is a 5 year old M2N68-LA (Ivy) with nForce 430 chipset.

I have been experiencing this same issue as well for a long time, and always thought it was because of my hardware or the way Slackware was installed (since I am only using that at home). Where can I find more information about it, and possible workarounds?

mats_b_tegner · 08-22-2012, 09:33 AM

Apache 2.4.3 which was released 2012-08-21 closes two security holes:
https://www.apache.org/dist/httpd/Announcement2.4.txt

Also, If you want to build a httpd package using the SlackBuild-script from /source, comment out the following line since a Slackware configuration has been added to config.layout:

Code:

zcat $CWD/config.layout.diff.gz | sed -e "s#lib/httpd#lib${LIBDIRSUFFIX}/httpd#" | patch --verbose -p1 || exit 1

tomac.pl · 08-22-2012, 01:06 PM

Quote:

Originally Posted by kabamaru

So... I'm testing RC2 on VirtualBox and I noticed this weird behavior: when I plug-in a usb stick and double-click on its icon (on Xfce's desktop), it gets mounted not in /media/<volume_name>, but in /run/media/<username>/<volume_name> and of course I haven't write permissions there.

Any ideas? Or can anybody reproduce this?

In my case, it also mounts USB sticks in /run/media/<username>/<volume_name> directory (I'm running Xfce as a regular user, not root) and I have read/write access to it. I have both "udisks" and "udisks2" packages installed (it also worked for me when only "udisks2" was installed).

The only idea that comes to my mind is maybe the USB stick with which you have tested it is formatted with some filesystem which cannot be mounted in read/write mode (like NTFS, if "ntfs-3g" package is not installed) - this is just a blind guess.

kabamaru · 08-22-2012, 01:24 PM

Quote:

Originally Posted by tomac.pl

The only idea that comes to my mind is maybe the USB stick with which you have tested it is formatted with some filesystem which cannot be mounted in read/write mode (like NTFS, if "ntfs-3g" package is not installed) - this is just a blind guess.

Actually it's an ext2 formatted stick. The same happens with a fat32 one. Maybe there's a new group I have to add my user to? (besides 'plugdev')

kabamaru · 08-22-2012, 01:39 PM

Yep, it was a matter of adding my user to group 'disk'. I thought plugdev was responsible for removable media...

Anyway, I still find it strange this is mounted in a new directory. What's wrong with good ol' /media/bla ?

volkerdi · 08-22-2012, 01:47 PM

Quote:

Originally Posted by kabamaru

Yep, it was a matter of adding my user to group 'disk'. I thought plugdev was responsible for removable media...

It is, and being in group "disk" isn't needed (here, at least).

Group disk is powerful. Any member of group disk can read, write, or erase entire hard drives. Be careful who you allow in the group... it's basically root.

Quote:

Anyway, I still find it strange this is mounted in a new directory. What's wrong with good ol' /media/bla ?

Yeah, me too.

Linux.tar.gz · 08-22-2012, 02:09 PM

I also have trouble with mounting medias under Xfce, but only with ARMedslack.

I've also done that manually:

Code:

udisksctl mount -b /dev/mmcblk1p1 
Error mounting /dev/mmcblk1p1: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code15: Adding read ACL for uid 1000 to `/run/media/me' failed: Operation not supported

---BTW i use startx.

kabamaru · 08-22-2012, 02:52 PM

Quote:

Originally Posted by volkerdi

...being in group "disk" isn't needed (here, at least).

Thanks. After you confirmed that it's not needed, I removed my user from 'disk', re-logged-in, and the problem vanished. Weird, but I'll take it.

rpedrica · 08-22-2012, 04:06 PM

Linux kernel 3.4 has just been indicated as an LTS kernel - I wonder if this could be default in Slack 14? Too late in the dev process?