The what should be updated in -current thread

Could we have a fix for the PyQt installation please? At the moment, make install does not correctly install the libpythonplugin.so file from the designer directory (although it is built correctly). This is because the designer/Makefile uses INSTALL_ROOT instead of DESTDIR. Since INSTALL_ROOT is not set, it means that libpythonplugin.so is (wrongly) installed to the host system instead $PKG. A potential fix for this would be for the PyQt.SlackBuild to set INSTALL_ROOT too, like:

make install DESTDIR=$PKG INSTALL_ROOT=$PKG || exit 1

chris

So where are we at against -Current in the update list?

Originally Posted by chris.willing Could we have a fix for the PyQt installation please? At the moment, make install does not correctly install the libpythonplugin.so file from the designer directory (although it is built correctly). This is because the designer/Makefile uses INSTALL_ROOT instead of DESTDIR. Since INSTALL_ROOT is not set, it means that libpythonplugin.so is (wrongly) installed to the host system instead $PKG. A potential fix for this would be for the PyQt.SlackBuild to set INSTALL_ROOT too, like: make install DESTDIR=$PKG INSTALL_ROOT=$PKG || exit 1

Alternatively, the following patch to PyQt-x11-gpl-4.9.6 will ensure the generated designer/Makefile respects the DESTDIR environment variable (so that INSTALL_ROOT doesn't need to be set when running make install).

--- a/designer/python.pro-in    2012-12-08 19:51:39.000000000 +1000
+++ b/designer/python.pro-in    2014-12-10 14:31:11.866281401 +1000
@@ -10,7 +10,7 @@
 HEADERS     = pluginloader.h
 
 # Install.
-target.path = @QTPLUGINDIR@
+target.path = /${DESTDIR}@QTPLUGINDIR@
 
 python.path = @QTPLUGINDIR@
 python.files = python

chris

I've already emailed Pat about these, but, I'd love to see a newer git in Slackware (2.2.0 is out now, maybe wait for 2.2.1). 2.1.2 built fine and ran fine on my machine (I tested my normal git workflow for a week with it), I did notice that this:

( cd $PKG/usr/doc/git-$VERSION/Documentation ; rm *.1 *.3 *.7 )

Spit out:

rm: cannot remove ‘*.1’: No such file or directory
rm: cannot remove ‘*.3’: No such file or directory
rm: cannot remove ‘*.7’: No such file or directory

I couldn't find where those files had moved by poking around (maybe they are gone entirely)?

Also, gptfdisk has been updated:
http://sourceforge.net/projects/gptf...tfdisk/0.8.10/

Lastly, I'd love to see the alsa* 1.0.28 stuff before 14.2.

In summary:

gptfdisk => 0.8.10
alsa* => 1.0.28
git => 2.2.*

Thanks!

Ooh!

python => 2.7.9

gptfdisk just hit the tree. git and the alsa stuff are in my pending queue already. I'll try to look at python soon.

I know it's only part of the Slackware installer but:

busybox-1.19.4 > busybox-1.22.1
dropbear-2012.55 > dropbear-2014.66
dhcpcd-3.2.3 > dhcpcd-6.6.5

Plus dhcpcd is also a standard package.

Originally Posted by ReaperX7 I know it's only part of the Slackware installer but: busybox-1.19.4 > busybox-1.22.1 dropbear-2012.55 > dropbear-2014.66 dhcpcd-3.2.3 > dhcpcd-6.6.5 Plus dhcpcd is also a standard package.

dhcpcd was upgraded to version 6 some time ago but it did not work in the installer (it would never obtain an IP, as I recall) and we could not figure out why, so it was reverted to version 3.
What is the compelling reason to update it? version 3 works fine for me.


busybox and dropbear are normally safe enough updates, but normally there's no reason to update them unless something doesn't work (normally it won't compile).

I didn't know about version 3.x being more compatible with BusyBox. I had no idea some stuff wouldn't compile.

I wonder if there could be an alternative to using dhcpcd on the installation disk like a combination of netplug, iana-etc, and a custom script to bring up the interfaces for IP.

I know CLFS for embedded systems uses udhcpc from BusyBox as described here: http://clfs.org/view/clfs-embedded/x...s/network.html

Even if not useful for Slackware, maybe it could help someone else looking for some answers, so I posted it anyway.

Originally Posted by ReaperX7 I wonder if there could be an alternative to using dhcpcd on the installation disk like a combination of netplug, iana-etc, and a custom script to bring up the interfaces for IP

If it ain't broken, why fix it... and a custom script that would need maintenance. Yeah.

Eric

Very true. Speaking of which, isn't the installation disk software created in a similar style to how you create something similar to a base LFS system like CLFS-embedded with a specialized user or chroot jail, or created in the standard system? I don't think this has ever been really discussed much.

Originally Posted by ReaperX7 I wonder if there could be an alternative to using dhcpcd on the installation disk like a combination of netplug, iana-etc, and a custom script to bring up the interfaces for IP.

Do we really need to break something that works?

You already know that Slackware upgrade some stuff only for security reasons and/or if there is a proven gain in doing so.

EDIT. Eric was faster More generally, I suggest that we accompany in this thread proposed upgrades with their rationales. And if something new is proposed, that the person who proposes it first tests it and preferably provides build material for it.

Originally Posted by ReaperX7 Very true. Speaking of which, isn't the installation disk software created in a similar style to how you create something similar to a base LFS system like CLFS-embedded with a specialized user or chroot jail, or created in the standard system? I don't think this has ever been really discussed much.

That would better be discussed in another thread as it's not this one's topic

With or without known patches? A confirmed "clean" build should at least be compiled and the make tests or checks ran before tinkering with a slackbuild script and then formally tested live.

Originally Posted by ReaperX7 With or without known patches?

Patches only if there's rationale for them IMHO

A confirmed "clean" build should at least be compiled and the make tests or checks ran before tinkering with a slackbuild script and then formally tested live.

Yes, still IMHO. Additionally, this can help to get you started, and the submissions guidelines @slackbuilds.org are also worth reading, adapted as need be.

The Slackbuild guidelines would apply mostly to new packages not updates, but yes, worth reading.