FAA Solution to Missing dependencies from USM?(2)

[goossbears]

Continued from the thread 'Missing dependencies from USM ?' http://forum.porteus.org/viewtopic.php?f=81&t=4529 and likely related to the thread 'Resolving Non-Slackware Dependencies' http://forum.porteus.org/viewtopic.php?f=75&t=4497 as well.
Assistance from someone more knowledgeable than me here for the below is most gratefully acknowledged
francois wrote:

If you are talking about installing the downloaded packages, the best thing is to have them transformed into modules (.xzm) at the same time that you download them (with the usm gui, command line usm does not have this option). This way there will be no need to install packages with installpkg removepkg if you have choosen within usm package manager to transform .txz to .xzm packages into modules. For the packages to become functional you will have transfer these into a dedicated folder which is /porteus/modules folder and reboot if there are many, or simply activate them one by one (installing them) by double clicking on them or using the right click contextual menu.

goossbears wrote:

I was given a recommendation (as a Porteus n00B) from someone more knowledgable than me to rather copy any required Slackware disksets locally from <slackware mirror>/slackware/slackware-14.1/slackware/<diskset> and then use installpkg or pkgtool on the locally-stored diskset pkg's instead of using the USM GUI and/or transforming them into .xzm modules.

A Solution to Missing dependencies from USM

1. Do copy any required Slackware disksets locally from <slackware mirror>/slackware/slackware-14.1/slackware/<diskset> as I described, and place them in the directory /mnt/sdXN/porteus/optional #where sdXN is the device and partition on which porteus is installed (please refer to http://www.porteus.org/tutorials/9-modu ... udies.html as much as is necessary)

2. Use the find command as follows with sudo to locate your particular <diskset>/pkg locally (here I am searching to install the geany pkg):

Code: Select all

sudo find -type f -name geany-* -print

In the case of geany, there was no geany*.txz in the Slackware-14.1 mirrors checked.
We instead found a slacky repository containing a working geany package at http://pkgs.org/slackware-14.1/slacky-i ... l.txz.html, and copied this slacky package directly to /mnt/sdXN/porteus/optional .
Once we've found the exact local location for our package or successfully downloaded it from an online repository, then we run pkgtool/installpkg as

Code: Select all

sudo installpkg /mnt/sdXN/porteus/optional/path-to-geany*txz

3. After using pkgtool/installpkg to install geany, try it out in your current X session by opening an xterminal window and simply typing 'geany' from the command line. Does it work exactly as expected? If so, then proceed through the instructions at http://www.porteus.org/tutorials/9-modu ... udies.html to convert the pkg into a persistent module, activate the new <pkg-name>.xzm, and then delete from /mnt/sdXN/porteus/optional/<diskset>/ the package you originally used to convert to .xzm.
Note that this is nearly identical to the steps francois mentions on top.
For geany, here's how it might work (pay careful attention to the target path!):

• Code: Select all

  sudo txz2xzm /mnt/sdXN/porteus/optional/path-to-geany*txz /mnt/sdXN/porteus/modules/geany*xzm

• activate /mnt/sdXN/porteus/modules/geany*xzm by by double clicking the module geany in /mnt/sdXN/porteus/modules

• Code: Select all

  sudo find /mnt/sdXN/porteus/optional -type f -name geany-* -exec rm -f {} \;

4. In the case of a package's unmet pkgtool/installpkg dependencies, there is a clumsy alternative to using francois's usm gui option and/or the case 2 slackyd instructions from http://www.porteus.org/tutorials/9-modu ... udies.html.
To demonstrate this alternative with an example, we'll use vim here.
We start by repeating step 2 by running

Code: Select all

sudo find /mnt/sdXN/porteus/optional -type f -name vim-* -print

, then running pkgtool/installpkg as

Code: Select all

sudo installpkg /mnt/sdXN/porteus/optional/path-to-vim*txz

, and then running vim from the command-line.
When we try to run vim, we unfortunately get the unmet dependency error

vim: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

.
This alternative is ridiculously clumsy, since when we look for libpython2.7.so.1.0 using

Code: Select all

sudo find /mnt/sdXN/porteus/optional -type f -name libpython* -print

, this file is nowhere to be found!
We can consider ourselves very fortunate, though, to find the python package containing libpython2.7.so.1.0 without excessive package dependency-hunting once we run

Code: Select all

sudo find /mnt/sdXN/porteus/optional -type f -name python* -print

.
Once we've found the python package providing our needed dependency (here it's /mnt/sdXN/porteus/optional/d/python-2.7.5-i486-1.txz), we can then install it via

Code: Select all

sudo installpkg /mnt/sdXN/porteus/optional/path-to-python-2.7.5-i486-1.txz

and then proceed through the rest of step 3 directly substituting python-* for geany-*.
But we're still not quite finished, as we're really out to install vim here, and the python-* package just provides the necessary dependency for vim.
We now have to repeat

Code: Select all

sudo find /mnt/sdXN/porteus/optional -type f -name vim-* -print

, then running pkgtool/installpkg as

Code: Select all

sudo installpkg /mnt/sdXN/porteus/optional/path-to-vim*txz

, and then running vim from the command-line just as we first did above.
Once vim runs acceptably, only then should step 3 be carried out, substituting vim-* for geany-* there.


Let us hope we all do not have to resort to manually installing packages with unmet dependencies, such as using pkgtool/installpkg for vim above.
Better yet is to fix the missing dependencies from USM and/or to fully resolve the non-Slackware dependencies as per http://forum.porteus.org/viewtopic.php?f=81&t=4529 and http://forum.porteus.org/viewtopic.php?f=75&t=4497 !!

[Bogomips]

@francois

FAA for brokenman?

[brokenman]

the best thing is to have them transformed into modules (.xzm) at the same time that you download them (with the usm gui, command line usm does not have this option).

Actually if you open the /etc/usm/usm.conf file and change:

MODULES=false to MODULES=true

all your downloaded packages will be converted to Porteus modules in text or gui mode.

In the case of geany, there was no geany*.txz in the Slackware-14.1 mirrors checked.

geany exists in the slackware repository and all dependencies are resolved. If you find otherwise let me know and I will add a manual file that will resolve all deps.

I don't see a need for downloading an entire slackware repository. USM spans across five different repositories giving you access to many more packages and only when you need them.
Also, the slacky repository (where geany was found) is a part of USM so any packages found therein should also appear in USM.

We can consider ourselves very fortunate, though, to find the python package containing libpython2.7.so.1.0 without excessive package dependency-hunting

A much easier way is using USM.

Code: Select all

usm -s libpython2.7.so.1.0

In short, if you find any missing dependencies for a package in USM please report it in the USM bugs section and I can add them to USm so it picks them up.
There shouldn't be a whole lot but sometimes python dependencies are missed. If I have misread this thread or there is extra info somewhere please point me to it.

Here is the output of vim:

Code: Select all

root@porteus:/home/guest# usm -g vim

 The following items were found.
 Choose an number to confirm. 
 ctrl+c to quit

1) vim-7.4.050-x86_64-1.txz	       3) vimprobable2-1.4.0-x86_64-1tjb.txz
2) vim-gvim-7.4.050-x86_64-1.txz
#? 1

Processing:   vim-7.4.050-x86_64-1.txz 
Ignored libraries: 

Libraries required:  12
Libraries found in system: 11
Libraries to resolve: 1

Processing library: libpython2.7.so.1.0


Processing:   python-2.7.5-x86_64-1.txz 
Ignored libraries: 

Libraries required:  23
Libraries found in system: 20
Libraries to resolve: 3

Processing library: libpython2.7.so.1.0
Processing library: libtcl8.6.so
Processing library: libtk8.6.so


Processing:   tcl-8.6.1-x86_64-1.txz 
Ignored libraries: 

Libraries required:  5
Libraries found in system: 4
Libraries to resolve: 1

Processing library: libtcl8.6.so


Processing:   tk-8.6.1-x86_64-1.txz 
Ignored libraries: 

Libraries required:  19
Libraries found in system: 17
Libraries to resolve: 2

Processing library: libtcl8.6.so
Processing library: libtk8.6.so


 The following packages are required. 
python-2.7.5-x86_64-1.txz [11868K] [not installed]
tcl-8.6.1-x86_64-1.txz [2500K] [not installed]
tk-8.6.1-x86_64-1.txz [1700K] [not installed]
vim-7.4.050-x86_64-1.txz [5952K] [not installed]

Total size: 22 MB

 Multiple packages were detected.
 Would you like to merge the packages into one module?

[goossbears]

Porteus's high-level, dependency-based USM package manager is certainly easier than having to use the manual tools pkgtool/installpkg and txz2xzm. 8) At the same time, the replies concerning USM are a bit incomplete.

brokenman wrote:

Actually if you open the /etc/usm/usm.conf file and change:

MODULES=false to MODULES=true

all your downloaded packages will be converted to Porteus modules in text or gui mode.

Although this may be one of the first actions to carry out when running USM, you probably want to login as the root user from a terminal to make these changes, as opposed to logging in as 'guest' and then running sudo.

While already logged into the terminal as the root user, you would then best run

Code: Select all

usm -u all

as per the USM thread http://forum.porteus.org/posting.php?mo ... =81&t=4532 **.

While still logged into the terminal as the root user, you would then run

Code: Select all

usm -g <packagename>

as per the recommendation just below for vim

brokenman wrote:

Here is the output of vim:

Code: Select all
root@porteus:/home/guest# usm -g vim

The following items were found.
Choose an number to confirm.
ctrl+c to quit

1) vim-7.4.050-x86_64-1.txz 3) vimprobable2-1.4.0-x86_64-1tjb.txz
2) vim-gvim-7.4.050-x86_64-1.txz
#? 1

Processing: vim-7.4.050-x86_64-1.txz
Ignored libraries:

brokenman wrote:

geany exists in the slackware repository and all dependencies are resolved. If you find otherwise let me know and I will add a manual file that will resolve all deps.

Actually, geany in particular really doesn't appear in any Slackware repository we've so far been able to find.
We checked several of the Slackware mirrors listed in http://mirrors.slackware.com/mirrorlist/, navigated to the slackware-14.1 directory in each mirror, and then performed simple searches for anything with 'geany' in it within this directory's FILELIST.TXT and PACKAGES.TXT text files. brokenman is in Brazil, so Brazilian Slackware mirrors we searched geany for included http://linorg.usp.br/slackware/,%20http ... slackware/, http://slackmirror.cbpf.br/pub/slackware/, and ftp://linorg.usp.br/slackware/. Again, in no case were we able to find a package containing 'geany' in it within the Slackware mirrors we were able to so far search.
We instead see that

Code: Select all

usm -g geany

only gave us the following decidedly non-Slackware-repository choices, of which we selected the slacky-specific geany-1.23.1-i486-1sl.txz:

root@porteus:~# usm -g geany

The following items were found.
Choose a number to confirm.
ctrl+c to quit

1) geany-1.23.1-i486-1gv.txz 3) geany-plugins-1.23-i486-2tjb.txz
2) geany-1.23.1-i486-1sl.txz
#? 2

Processing: geany-1.23.1-i486-1sl.txz
Ignored libraries:

Libraries required: 57
Libraries found in system: 57
Libraries to resolve: 0

** It is important to note here that the command

Code: Select all

usm -u all

isn't automatically performed for all Porteus users, so running this isn't completely obvious

[Bogomips]

** It is important to note here that the command

Code: Select all

usm -u all

isn't automatically performed for all Porteus users, so running this isn't completely obvious

Almost completely obvious :

Code: Select all

root@porteus:/home/guest# usm -g compositeproto

 The following items were found.
 Choose an number to confirm. 
 ctrl+c to quit

1) compositeproto-0.4.2-noarch-1.txz
#? 1

Processing:   compositeproto-0.4.2-noarch-1.txz 

 The following packages are required. 
compositeproto-0.4.2-noarch-1.txz [16K] [not installed]

Total size: 16 KB
 Would you like to install the package/s? (custom paths are supported) [y/n]

 Press [r] to remove packages, [q] to quit, or enter to start downloading.

 Updates are available. 
 Program update:   not required 
 Database update:  available 
 Please run:  usm -u all  and/or  usm -u usm 
 This message can be disabled in /etc/usm/usm.conf
 ############################### 
compositeproto-0.4.2-noarch-1.txz already exists

Granted, it could become universally obvious if the update prompt were to also come on running either of usm -s or usm -i

@brokenman
Is MODULES= also an environmental variable?

[brokenman]

The warning about the database is fairly obvious in both the GUI and the CLI. You will see it if you have something out of date. Regarding the missing geany, you are right goossbears, I should have said that it is available through USM in one of the slackware based repositories. Not the official slackware repository. In this case it is salix and slacky.

The MODULES= variable is not set by Porteus as a universal environment variable. When USM is run the config file is sourced and variables therein are temporarily used for the current USM session only. I am not aware of any other program that sets a universal environment variable as MODULES= so let me know if you have found one.

[francois]

@brokenman:
The MODULES= variable is not set by Porteus as a universal environment variable. When USM is run the config file is sourced and variables therein are temporarily used for the current USM session only. I am not aware of any other program that sets a universal environment variable as MODULES= so let me know if you have found one.

This sentence is a little criptic to me. Do you mean that you want usm to be used by the slackware community at large. If this is the case no problem, but maybe usm with porteus should be shipped with usm version with MODULES=true.

Just thinking about some issues with usm here. Maybe usm for porteus use should be more intuitive as we can deduce by numerous newcomers comments.

As we use modules with porteus, shouldn't it be set to MODULES=true, or else the impression is that we encourage mixed systems with txz and xzm?

And why not transfering and automatically activating (handy if there are a lot of dependencies) the new modules into some subfolder of /porteus/modules, something like /porteus/modules/date-of-download/package-subfolder automatically? This would give a functional installation of the downloaded package. After all, if one downloads a package it is because one would like to use it. This mode of functioning is universally the one with apt-get, pacman, etc.

[Ed_P]

@brokenman:

The MODULES= variable is not set by Por ... found one.

That quite a URL. LOL

After all, if one downloads a package it is because one would like to use it. This mode of functioning is universally the one with apt-get, pacman, etc.

Actually I have downloaded packages to try them. Some I found I didn't like and was glad they would be gone with the next reboot. Those that i liked I kept, by manually moving them to my porteus/modules fiolder.

[francois]

1) You know there is a function called erase. It is very efficient. 8)

2) In addition, there are arguments in the /etc/usm/usm.conf file:

Code: Select all

# Where packages will be downloaded to.
STORAGE=/tmp/usm
...
...
# The directory where your slackbuilds source files
# will be downloaded when building from source
SBOTMP=/tmp/usmsbo

An additional argument could be something like:

Code: Select all

# Transfering and activating modules to /porteus/modules folder 
ACTIVATINGtoMODULESfolder=

3) But your opinion is interesting nonetheless, and the opinion of others would be too. As much that of freshmen than that of senior forum members.

4) In the end, it will be up to brokenman to decide what he does with his beast.

[Bogomips]

Also gettiing this sort of message at the end

Code: Select all

usm -g vlc
...
1) vlc-2.1.2-i486-1sl.txz      3) vlc-2.2.0-i486-2alien.txz
2) vlc-2.1.2-i686-1dj.txz      4) vlc-qt-0.10.0-i486-1sl.txz
#? 3
Processing:   vlc-2.2.0-i486-2alien.txz 
....
Processing:   vlc-2.2.1-i486-1alien.txz 
          

==============================================================================
WARNING!        WARNING!        WARNING!        WARNING!        WARNING!
==============================================================================
One or more errors occurred while usm was running:                       
 
FATAL ERROR!
 resolve_deps 356
Brokenman needs to update database. Could not find: LIBS.TXT
 
============================================================================== 

would seem to be somewhat offputting for newcomers. Can not something be done to flag this at the usm-u all stage?

[francois]

Concerning modtools in usm gui:
It would be nice to be able to have a merge modules from directory into a bundle. This would be a nice feature when afterwards you realize that there are finally so many dependencies.

Maybe a new thread should be started as a wishlist for usm.

[Bogomips]

Concerning modtools in usm gui:
It would be nice to be able to have a merge modules from directory into a bundle. This would be a nice feature when afterwards you realize that there are finally so many dependencies.

And for other reasons, like having tested as a module, one wishes to combine dependencies in directory with other dependencies, not necessarily USM based.

Maybe a new thread should be started as a wishlist for usm.

Go on francois, you have it within your remit , to move relevant posts here into a new thread under the heading of your choice. 8)

[brokenman]

This has gone quite a bit off topic. Can someone confirm that the OP's original query has been satisfied? I will answer the other questions briefly here but Francois please do start a relevant thread.

This sentence is a little criptic to me. Do you mean that you want usm to be used by the slackware community at large. If this is the case no problem, but maybe usm with porteus should be shipped with usm version with MODULES=true.

Yes slackware users are welcome to use USM too although it is only compatible with 14.1 at the moment. I am open to more conversation (pros/cons) about setting MODULES=true as default in porteus.

Just thinking about some issues with usm here. Maybe usm for porteus use should be more intuitive as we can deduce by numerous newcomers comments.

Again I am always open to suggestions and will implement what I can (time permitting) if it is generally agreed as a good idea.

As we use modules with porteus, shouldn't it be set to MODULES=true, or else the impression is that we encourage mixed systems with txz and xzm?

I see no problem using slackware packages. I frequently do. Again, I am open to discussion on this point.

And why not transfering and automatically activating (handy if there are a lot of dependencies) the new modules into some subfolder of /porteus/modules
This presents some other hurdles like discovering the location of this folder, people that use non-writable media, people that boot from an ISO etc.

# Transfering and activating modules to /porteus/modules folder
ACTIVATINGtoMODULESfolder=

In the CLI there is an option to install the downloaded packages (even to a temp location) but not to move them into the porteus folder as it is stored on the install media.

Also gettiing this sort of message at the end would seem to be somewhat offputting for newcomers. Can not something be done to flag this at the usm-u all stage?

Agreed. The issue is that the database is updated every three days, and if a slackware repository updates something in between this 3 day routine there is a mismatch and when a user searches for the package that was updated they will receive this message. It does look like the computer is about to explode though. Perhaps I should change the wording and apparent urgency of the message. Suggestions welcome.

It would be nice to be able to have a merge modules from directory into a bundle.

I decided at the outset of writing USM not to support bundling. In the end it is not such a big deal as individual packages are not managed by USM locally. I will consider writing this into the GUI when I get time. My main problem at the moment is time. I have quite a few real life projects taking up more and more of my time so tinker when time permits.

[fanthom]

" The issue is that the database is updated every three days, and if a slackware repository updates something in between this 3 day routine there is a mismatch and when a user searches for the package that was updated they will receive this message. It does look like the computer is about to explode though. Perhaps I should change the wording and apparent urgency of the message. Suggestions welcome."
what about this approach:
every 6 hours the script on the server downloads latest time stamps from every repo changelog and compares them with latest saved.
if there is a mismatch then updates database, if not then skips.

this should be more flexible approach that force an update every 3 days.

[tome]

Or maybe replace last field(s) of package path:
For example searching 'vlc':
1. 'http://taper.alienbase.nl/mirrors/peopl ... 1alien.txz' doesn't exist so
2. cut 'http://taper.alienbase.nl/mirrors/peopl ... 1/x86/vlc/'
3. wget 'http://taper.alienbase.nl/mirrors/peopl ... 1/x86/vlc/'
4. find >vlc*.txz< in index.html
5. remove > and <
6. bring together 'http://taper.alienbase.nl/mirrors/peopl ... 1/x86/vlc/' and vlc*.txz

This would not require database update frequently.