LinuxQuestions.org - [ANN] compat32pkg 1.2.110112

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - [ANN] compat32pkg 1.2.110112 (https://www.linuxquestions.org/questions/slackware-14/%5Bann%5D-compat32pkg-1-2-110112-a-856354/)

[ANN] compat32pkg 1.2.110112

Hello slackers,

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.

cheers.

--
SeB

phenixia2003,

I would like to thank you for the work you have put into this, it looks like hours of work.
I have been using it successfully.

many thanks
tobyl

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. :hattip:

Hi phenixia

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:

root@darkstar:/var/log/packages# compat32pkg --search list:gdk-pixbuf2

compat32pkg ver. 1.2.110112 (stable)

/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?

thanks!

tobyl

Hello,

Quote:

Originally Posted by tobyl (Post 4267684)

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 :

Code:



  $ compat32pkg --mirror @Worldwide-current --install list:util-linux,libmpc,libpcap,libsndfile

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 (Post 4267684)

/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 (Post 4267684)

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.

Cheers !

--
SeB

Hi SeB

Thanks for your comprehensive reply.

Quote:

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.

Thanks again,

tobyl

Hello,

Quote:

Originally Posted by tobyl (Post 4270045)

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 :

Code:



$ compat32pkg --check-layer-32-config

$ compat32pkg --upgrade-layer-32-config

... or that :

Code:



$ compat32pkg --layer-32-config check-update

$ compat32pkg --layer-32-config upgrade

Quote:

Originally Posted by tobyl (Post 4270045)

On the other hand you could argue that us current users should be smart enough to work that out!

No, no ! Yours feedback gives me the opportunity to improve compat32pkg as it has to be : something
useful for any users ! :)

Cheers.

--
SeB