Here is a place for your projects which are not officially supported by the Porteus Team. For example: your own kernel patched with extra features; desktops not included in the standard ISO like Gnome; base modules that are different than the standard ISO, etc...

Continued from the thread 'Missing dependencies from USM ?' viewtopic.php?f=81&t=4529 and likely related to the thread 'Resolving Non-Slackware Dependencies' 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):

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

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!):

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

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

, 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 viewtopic.php?f=81&t=4529 and viewtopic.php?f=75&t=4497!!

Last edited by goossbears on 14 Apr 2015, 22:53, edited 1 time in total.

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

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.

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

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

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.

How do i become super user?
Wear your underpants on the outside and put on a cape.

@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.

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.

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.

francois wrote: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.

francois wrote: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)

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.

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.

How do i become super user?
Wear your underpants on the outside and put on a cape.

" 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.