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.
Just to announce you the availability of compat32pkg-1.2.110112 which includes some slight improvements,
and, especially, corrects a small, but annoying, bug introduced by previous version (ie 1.1.110107) :
Code:
------------------------------------------------------------------------
RELEASE NOTES for compat32pkg 1.2.110112
------------------------------------------------------------------------
*****************************************************************
* *
* This maintenance release supersedes the earlier (ie 1.1.110107) *
* which, unfortunately, has introduced a bug which downgrades *
* some compat32 packages while installing of 32-bit compatibility *
* layer. *
* *
*****************************************************************
1. PREAMBLE
This maintenance release includes two bug fixes, some little improvements,
and updates the list of packages that provide the 32-bit part of the
multilib (ie 32-bit compatibility layer).
Users of earlier versions, and especially users of 1.1.110107, are
encouraged to upgrade to this release.
2. BUG FIXES
a. The addition of package "aaa_elflibs" into the 32-bit compatibility
layers could lead to downgrading of some packages. Indeed, as this
package has to be processed first when installing Slackware, it also
has to be processed first in the case of the multilib. Otherwise,
this might lead to downgrading some libraries as this is clearly
explained here: http://connie.slackware.com/~mozes/docs/aaa_elflibs.txt
This has been corrected into 1.2.110112 by adding the baseref of
aaa_elflibs at the top of the packages precedence order given by
the variable PKGS_PRECEDENCE_ORDER in configuration's script
/etc/compat32pkg/compat32pkg.conf.
b. The reinstall of a package to format compat32 by a simple
"compat32pkg --install" seems to work, but, the package is not
reinstalled.
This has been corrected into 1.2.110112 by running upgradepkg with
its option "--reinstall".
3. IMPROVEMENTS
a. 1.2.110112 includes a full revision of the mechanism to preventing
incompatibilities. This mechanism has been improved and users have
now the ability to enable/disable it. To learn more about that, look
at the section "9. Preventing accidental incompatibilities" into the
file /usr/doc/compat32pkg-1.2.110112/README.
b. Since 1.2.110112, compat32pkg use the directory /tmp/compat32pkg to
store its temporary data. As a convenience, this temporary location
is shared with convertpkg-compat32, using his environment variable
TMP. This sharing aims to avoid the too many folders, of kind *-compat32-*,
created into /tmp when using compat32pkg as this was observed by
Drakeo :
http://www.linuxquestions.org/questions/slackware-14/slack64-13-1-multilib-skype-2-1-0-81-not-working-after-glibc-upgrade-851145/#post4197179
c. Since 1.2.110112, compat32pkg reports the rank of each package being
processed, which gives users an indication about the work done and
the remaining work.
4. UPDATES
This version of compat32pkg comes with a new version of the file that
describes the 32-bit part of the multilib (/etc/compat32pkg/multilib-32bit-packages.lst)
which includes the latest changes done by alienBob to the 32-bit compatibility
layer (ie adding of packages :a/aaa_elflibs, l/gdk-pixbuf2, l/libelf, xap/sane).
5. UPGRADING AND CONFIGURATION'S FILES
Once compat32pkg 1.2.110112 is installed, users should update the
configuration's files below using the new versions provided (.new) :
/etc/compat32pkg/compat32pkg.conf:
- The new version updates the variable PKGS_PRECEDENCE_ORDER to correct
the bug related to the addition of aaa_elflibs into the 32-bit layer,
and, includes the new variable PREVENT_INCOMPATIBILITIES which allows
users to enable/disable the mechanism to preventing incompatibilities.
/etc/compat32pkg/multilib-32bit-packages.lst:
- The new version includes the latest changes done by alienBob to the
"32-bit compatibility layer" (ie adding of packages :a/aaa_elflibs,
l/gdk-pixbuf2, l/libelf, xap/sane).
/etc/compat32pkg/blacklist:
- The package aaa_elflibs has been removed from this list following
its inclusion into the the 32-bit compatibility layer.
6. IMPORTANT NOTES TO USERS OF 1.1.110107
Even if all seems to work well, users of Slackware64-13.0/13.1 who have
installed the 32-bit compatibility layer using compat32pkg-1.1.110107
have a "broken" 32-bit compatibility layer.
Indeed, as compat32pkg-1.1.110107 does not install "aaa_elflibs" first,
some libraries are overwritten with outdated versions when install of
32-bit compatibility layer. Fortunately, only the packages below for
which a patch has been published are affected by this bug :
alsa-lib bzip2 cups
curl expat freetype
glib2 libidn libjpeg
libpng libtermcap libtiff
ncurses openldap-client popt
readline svgalib zlib
Thus, at the time of writing this document (Jan 14 2011), the bug have
only impacted the compat32 packages below :
-------------------------------------------------------------
! Slackware-13.0 ! Slackware-13.1 !
!------------------------------+------------------------------!
! bzip2 ! bzip2 !
! cups ! cups !
! libpng ! libpng !
! libtiff ! libtiff !
-------------------------------------------------------------
As this bug could lead to security issues, users who have installed
the 32-bit compatibility layer using compat32pkg-1.1.110107 can correct
that like this :
1. Reinstall the 32-bit compatibility layer :
$ compat32pkg --install layer-32
OR
2. Reinstall only the packages that might be impacted :
$ compat32pkg --install list:alsa-lib,bzip2,cups,curl,expat,\
freetype,glib2,libidn,libjpeg,libpng,libtermcap,libtiff,ncurses,\
openldap-client,popt,readline,svgalib,zlib
OR
3. Reinstall only the packages which have been impacted :
You will find the slackware's tarball, the source and the slackbuild here here.
I was in the process of creating script to check for changes in the compat32 libs, download them and install using my local mirror but put that on hold to update multilib after the compilers got upgraded in -current. Normally I use lftp to get the updates, install them and then run massconvert32 to grab, update the libraries from my local mirror. Today I decided to peruse through Alien's Wiki and noticed a reference to your scripts.
Why reinvent the wheel? After a quick review, I downloaded and installed both your compat32pkg and multilibpkg.
All I can say is THANKS! Works flawlessly! Upgraded the 64-bit side and then the 32-bit libs from my local mirror. Actually I did an --install layer-32 to make sure I picked up any added layer-32 files.
I couldn't be happier. Outstanding job and thank for the work in putting them together.
With the recent glibc updates, I used compat32pkg to check for updates to the layer-32 packages
I used --check-updates and --list-updates, and expected to see for example gdk-pixbuf2 among the files for conversion, but it did not find it. This could be user error, or maybe a bug?
A specific search did confirm that the file was missing:
/usr/sbin/compat32pkg: line 2047: [: too many arguments
[--search] Started on Tue Feb 22 20:26:07 2011
[--search] Using mirror ftp://ftp.heanet.ie/mirrors/ftp.slac...ckware-current
[--search] Local system is Slackware/x86_64 version current
13.2
[--search] Mirrored system is Slackware/i486 version current
[--search] 1 package(s) were found (0,074 sec.)
[ package-baseref ] [ version-build ] [ mult. ] [ Status of compat32''s version ]
slackware/l/gdk-pixbuf2 2.22.1-2 Not installed
[--search] Ended on Tue Feb 22 20:26:07 2011
Another question, now that util-linux-ng has been replaced by util-linux, should the multilib-32bit-packages.lst be modified to reflect this?
With the recent glibc updates, I used compat32pkg to check for updates to the layer-32 packages
I used --check-updates and --list-updates, and expected to see for example gdk-pixbuf2 among the files for conversion, but it did not find it. This could be user error, or maybe a bug?
Well, until now, it was the expected behavior. Indeed, by design, compat32pkg searches the updates
*only* for installed packages.
However, with the recent updates into the current development tree, and by extension into the 32-bit
layer, we are facing what I will call a (small but annoying) flaw .
If you look at slackpkg you will see that its "upgrade" feature works the same way. However, unlike
compat32pkg, slackpkg comes with another feature (ie "install-new") that allows to install newly added
packages automatically.
After thinking about that, the best way to correct this flaw is simply to change how the update mechanism
work when the layer-32 is explicitly specified (ie when user supply the keyword "layer-32" in argument of
--check-updates, --list-updates, --convert-updates,--upgrade). In the other cases (ie when user supply a
list (or a file) of patterns), the update mechanism will work as before, , otherwise this could lead to
some suprising things.
I hope to publish a new version of compat32pkg with this change really soon (this week-end at best, end
of next week at worst). Until then, users of compat32pkg under slackware64-current can workaround this
flaw by installing manually the missing packages as below :
To check whether the layer-32 is fully installed, users can do the following (do not forget
to provide a mirror if needed):
Code:
$ compat32pkg --search layer-32
If you find one or more entries with the status "Not installed" into the output of this execution
of compat32pkg, this means that the layer-32 is not fully installed. In that case, this can be
corrected by installing the missing packages manually.
Quote:
Originally Posted by tobyl
/usr/sbin/compat32pkg: line 2047: [: too many arguments
Oops ! what this ? Could you :
+ retry what you did with another mirror (current, 13.0 and 13.1)
+ give me the content of your /etc/slackware-version
Quote:
Originally Posted by tobyl
Another question, now that util-linux-ng has been replaced by util-linux, should the
multilib-32bit-packages.lst be modified to reflect this?
Simply add util-linux below util-linux-ng in this file.
Well, until now, it was the expected behavior. Indeed, by design, compat32pkg searches the updates
*only* for installed packages.
You are correct, I somehow assumed slackpkg install-new behaviour. However I had updated to the latest current, so gdk-pixbuf2-2.22.1-x86_64-2 was installed. Therefore since the packages.lst file contained gdk-pixbuf2, I thought it would look for it and check for changes.
In the case of util-linux, I did not expect it to be found as it is new, and I did already what you suggested, and modified the .lst file to include it. I guess I was just pointing out that there is a maintenance overhead to supplying the .lst file, if you support current. I don't know how you would go about automating that. On the other hand you could argue that us current users should be smart enough to work that out!
Quote:
Oops ! what this ? Could you :
+ retry what you did with another mirror (current, 13.0 and 13.1)
+ give me the content of your /etc/slackware-version
Don't worry, you gave me the clue I needed to fix that error...
my /etc/slackware-version file, having gone through many version upgrades contained a hashed out previous version due to a manual edit. When I removed that unnecessary entry, the 'too many arguments' warning went away.
I guess I was just pointing out that there is a maintenance overhead to supplying the .lst file,
if you support current. I don't know how you would go about automating that.
Indeed, each time that packages are added into the layer-32 I must publish a new version of
compat32pkg and users have to grab it prior to update their layer-32, and obviously, this is
not an efficient process. Even if the layer-32 is not often modified, I'm thinking to add
features to compat32pkg which will allow users to check updates, and to upgrade the file that
describes the 32-bit layer (ie the file multilib-32bit-packages.lst). This could look like this :
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.