[SOLVED] Requests for -current (20151216)

DarkVision · 06-11-2016, 05:23 AM

A safe package to upgrade would be hicolor-icon-theme, version 0.15 is available since last year with some new icon directories added.

slalik · 06-11-2016, 05:50 AM

wget 1.18

In particular, it fixes a security vulnerability (CVE-2016-4971) present in all old versions:
http://lists.gnu.org/archive/html/in.../msg00004.html

GazL · 06-11-2016, 08:28 AM

Quote:

Originally Posted by kjhambrick

Patch that could fix NULL pointers in vsf_sysdep_check_auth( ) and elsewhere too:

Code:

diff -Naur vsftpd-3.0.3-orig/sysutil.c vsftpd-3.0.3/sysutil.c
--- vsftpd-3.0.3-orig/sysutil.c 2012-09-16 02:07:38.000000000 -0500
+++ vsftpd-3.0.3/sysutil.c      2016-06-11 04:13:32.942385706 -0500
@@ -1087,6 +1087,14 @@
 int
 vsf_sysutil_strcmp(const char* p_src1, const char* p_src2)
 {
+  if ( p_src1 == NULL )
+  {
+    return -1 ;  // first string is NULL ???
+  }
+  if ( p_src2 == NULL )
+  {
+    return  1 ;  // second string is NULL ???
+  }
   return strcmp(p_src1, p_src2);
 }

Nah, I don't care for that approach in general as it could potentially mask an error elsewhere in the code. Much better to check your return values after you make the call rather than rely on subseqent functions to pick them up. At least when you get a segfault you know you're doing something wrong.

Anyway, we're getting way off-topic and this thread is not the place for such discussions, so suffice to say there's a lot in the vsftp codebase that I don't like, and leave it at that.

aaazen · 06-11-2016, 11:33 AM

I have a couple of possible updates to the pkgtools, setup.80.make-bootdisk scripts.

1) There is a possible bug in setup.80.make-bootdisk:

https://www.linuxquestions.org/quest...8/#post5559379

2) There is a new version of setup.80.make-bootdisk which creates a usb stick more like a hard disk called setup.81.make-mbr-bootdisk. Maybe it can be tested and incorporated in pkgtools somehow?

https://www.linuxquestions.org/quest...7/#post5559212

franzen · 06-12-2016, 02:32 AM

Already mentioned, freeglut 3.0.0 is available since over a year. For building cmake is used now, the buildinstructions from lfs may be used. Packages that may need recompilation are
jasper, libcaca, libtiff, and mesa(circular dependency), as far i can see.

libcaca-0.99.beta18 in current comes from 14.1., libcaca-0.99.beta19 is available since 2.5 years.

Mentioning how long these are out now is no critisism, but a hint that these are no bleeding versions.

DarkVision · 06-12-2016, 06:53 AM

OK, about the systemd stuff... i did some testing.

gvfs 1.26 has the --disable-libsystemd-login switch but it will still install the systemd files, so this switch will not work for 1.26. I tested the SlackBuild from -current with the 1.28.2 source package and there the --disable-libsystemd-login switch works. So there must have been some changes between 1.26 and 1.28.

I created a patch to simply delete the files after the build. Same for hplip.

I have an additional patch for geeqie which is using a hard coded path to /usr/lib/geeqie to install some helper scripts. These scripts are platform independent but since they will be installed in /usr/lib i suggest to use /usr/lib64 for x86_64.

Didier Spaier · 06-12-2016, 07:23 AM

Quote:

Originally Posted by DarkVision

I created a patch to simply delete the files after the build. Same for hplip.

Thanks, but why would I worry for these files? There are a lot of small files in my systems that I won't ever use, but spotting and removing them would just be a waste of time as I see it.

PS I don't see a need to to put the geequie scripts in /usr/lib64 in case of x86_64. What would be the benefit of doing that?

DarkVision · 06-12-2016, 07:42 AM

Quote:

Originally Posted by Didier Spaier

Thanks, but why would I worry for these files? There are a lot of small files in my systems that I won't ever use, but spotting and removing them would just be a waste of time as I see it.

I agree, but it's just a small fix and will remove unused files. Note that there are some other packages in Slackware that do already disable building systemd stuff. For me it doesn't matter if these fixes will be applied by the devs or not since i replace those packages after 14.2 is out anyway. I just wanted to share my thoughts.

kjhambrick · 06-12-2016, 07:50 AM

Quote:

Originally Posted by Didier Spaier

Thanks, but why would I worry for these files? There are a lot of small files in my systems that I won't ever use, but spotting and removing them would just be a waste of time as I see it.

I dunno ... maybe just me, but I kinda do like to have the /usr/lib/systemd/ files on my system so I can see how the upstream developers intended the package to be run.

OTOH, I wonder what are the side-effects of the --disable-libsystemd-login on gvfs version 1.28 ?

Maybe it will eliminate the annoying `lsof` messages on stderr for each regular user's $HOME/.gvfs/ directory when I invoke lsof as root ???

Code:

$ lsof > /dev/null    # invoke lsof as a plain-ole-user

  <<no output>>

$ su -                # become root
# lsof > /dev/null

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /home/konrad/.gvfs
      Output information may be incomplete.

-- kjh

p.s. [edit] these are the perms on /home/konrad/.gvfs/

Code:

$ ls -la /home/konrad/.gvfs
total 12
dr-x------  2 konrad users     0 Jun  9 15:58 ./
drwx--x--x 59 konrad users 12288 Jun 11 11:55 ../

55020 · 06-12-2016, 08:34 AM

IMO it's helpful to keep systemd files in the expected places for the benefit of people who are running Dlackware. Let's show the other side how to be tolerant and flexible and magnanimous and respectful of other peoples' setups.

DarkVision · 06-12-2016, 10:28 AM

Quote:

Originally Posted by 55020

IMO it's helpful to keep systemd files in the expected places for the benefit of people who are running Dlackware. Let's show the other side how to be tolerant and flexible and magnanimous and respectful of other peoples' setups.

Good point. But since Dlackware seem to replace gvfs anyway (and many other packages) why bother non-GNOME-users with unneeded files?

Really... if more people like those files to be there... keep it, i don't care.

kjhambrick · 06-12-2016, 11:07 AM

Quote:

Originally Posted by comet.berkeley

I have a couple of possible updates to the pkgtools, setup.80.make-bootdisk scripts.

1) There is a possible bug in setup.80.make-bootdisk:

https://www.linuxquestions.org/quest...8/#post5559379

2) There is a new version of setup.80.make-bootdisk which creates a usb stick more like a hard disk called setup.81.make-mbr-bootdisk. Maybe it can be tested and incorporated in pkgtools somehow?

https://www.linuxquestions.org/quest...7/#post5559212

comet-berkeley --

I've tested setup.81.make-mbr-bootdisk on a 'no name' 2GB USB Drive ( a giveaway from a BIRT Conference several years ago ).

Works great and the partition table looks 'normal' to me

Thanks !

if only I had figured out why my 'test USB' ( USB ID = 0781:5561 SanDisk Corp 4GB USB Drive ) wasn't being detected by EITHER setup.81... OR setup.80..., I'd have tested and replied sooner

This is why: https://aussiestorageblog.wordpress....rosofts-fault/

-- kjh

Code:

# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
Bus 001 Device 002: ID 1c7a:0603 LighTuning Technology Inc. 
Bus 001 Device 004: ID 0cf3:e300 Atheros Communications, Inc. 
Bus 001 Device 003: ID 5986:066d Acer, Inc 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# tail /var/log/messages
Jun 12 10:50:34 kjhlt6 mtp-probe: bus: 1, device: 5 was not an MTP device 
Jun 12 10:50:34 kjhlt6 kernel: [  351.576499] usb-storage 1-6:1.0: USB Mass Storage device detected
Jun 12 10:50:34 kjhlt6 kernel: [  351.576672] scsi host8: usb-storage 1-6:1.0
Jun 12 10:50:34 kjhlt6 kernel: [  351.576852] usbcore: registered new interface driver usb-storage
Jun 12 10:50:34 kjhlt6 kernel: [  351.577494] usbcore: registered new interface driver uas
Jun 12 10:50:36 kjhlt6 kernel: [  352.953280] scsi 8:0:0:0: Direct-Access                               1100 PQ: 0 ANSI: 0 CCS
Jun 12 10:50:36 kjhlt6 kernel: [  352.954158] sd 8:0:0:0: [sde] 3792896 512-byte logical blocks: (1.94 GB/1.81 GiB)
Jun 12 10:50:36 kjhlt6 kernel: [  352.954757] sd 8:0:0:0: [sde] Write Protect is off
Jun 12 10:50:36 kjhlt6 kernel: [  352.958801]  sde: sde1
Jun 12 10:50:36 kjhlt6 kernel: [  352.961124] sd 8:0:0:0: [sde] Attached SCSI removable disk

# fdisk -l /dev/sde
Disk /dev/sde: 1.8 GiB, 1941962752 bytes, 3792896 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xafd8f6a0

Device     Boot Start   End Sectors Size Id Type
/dev/sde1  *     2048 34815   32768  16M  6 FAT16

gmgf · 06-12-2016, 02:04 PM

on x86_64 NetworkManager package install udev rules in /usr/lib instead /lib

same on i586 package

DarkVision · 06-12-2016, 02:11 PM

Quote:

Originally Posted by gmgf

on x86_64 NetworkManager package install udev rules in /usr/lib instead /lib

I suggest the following patch:

Code:

diff -U3 -d -r -N NetworkManager.orig/NetworkManager.SlackBuild NetworkManager/NetworkManager.SlackBuild
--- NetworkManager.orig/NetworkManager.SlackBuild	2016-05-11 18:37:43.000000000 +0200
+++ NetworkManager/NetworkManager.SlackBuild	2016-06-12 21:08:48.722451387 +0200
@@ -93,6 +93,7 @@
   --localstatedir=/var \
   --mandir=/usr/man \
   --docdir=/usr/doc/$PKGNAM-$VERSION \
+  --with-udev-dir=/lib/udev \
   --with-pppd-plugin-dir=/usr/lib${LIBDIRSUFFIX}/pppd/$PPPD \
   --with-crypto=nss \
   --enable-more-warnings=no \

P.S. Sorry for that... had that fix for more then one year in my repo... no idea why i did not forward that upstream

Anyway, for me it seem to work, i mean having the udev-rules in /lib instead of /usr/lib...

gmgf · 06-12-2016, 02:44 PM

binutils has two symlink in the package

usr/x86_64-slackware-linux/bin/readelf
usr/x86_64-slackware-linux/bin/dlltool

readel and dlltool are present in two dir /usr/x86_64-slackware-linux/bin/ and in /usr/bin