USM bug reports
- brokenman
- Site Admin
- Posts: 6105
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
Re: USM bug reports
grep: /etc/usm/mirrors-.txt: Nie ma takiego pliku ani katalogu
Looks like a variable is not being passed due to some customization. The distro is missing from the string. Will need to try to recreate here. Did you only change the database folder in the config file?
Looks like a variable is not being passed due to some customization. The distro is missing from the string. Will need to try to recreate here. Did you only change the database folder in the config file?
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.
-
- Contributor
- Posts: 686
- Joined: 26 Jun 2013, 14:03
- Distribution: x64 Openbox
- Location: Russia is causing the immense damage to humanity
- Contact:
Re: USM bug reports
Only these:
in rc.local
and in usm
Code: Select all
bdev=`grep -A1 "Booting" /var/log/porteus-livedbg|tail -n1|sed 's^//^/^g'`
pdat=${bdev}/data
ln -sf $pdat /mnt/data
and
Code: Select all
DBDIR=/mnt/data/appdata/usm-x86
Code: Select all
STORAGE=/mnt/data/apps-x86-packages
Code: Select all
MAKELINKS=true
-
- Full of knowledge
- Posts: 2564
- Joined: 25 Jun 2014, 15:21
- Distribution: 3.2.2 Cinnamon & KDE5
- Location: London
Re: USM bug reports
USM
SLACKYD
Code: Select all
####################################
Missing dependencies: 2
libcups.so.2
libgcrypt.so.20
Searching libcups.so.2: found 1 packages.
Searching libgcrypt.so.20: found 0 packages.
The following packages are ready to download:
aaa_elflibs-14.1-i486-3.txz [4.59 MB]
Press [r] to remove packages, [q] to quit, or enter to start downloading.
root@porteus:/home/guest# usm -s libcups.so.2
-----------------------------
Are you searching for a library file?
libcups.so.2, it seems a library.
Would you like to find the package for it? [y/n]
libcups.so.2 was found in aaa_elflibs-14.1-i486-3.txz
Code: Select all
Library libcups.so.2 is contained in 2 different packages:
--> aaa_elflibs-14.1-i486-3.txz
--> cups-1.5.4-i486-3.txz
Use aaa_elflibs-14.1-i486-3.txz [from slackware] ? [y/N]
Use cups-1.5.4-i486-3.txz [from slackware] ? [y/N
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
- Ed_P
- Contributor
- Posts: 8908
- Joined: 06 Feb 2013, 22:12
- Distribution: Cinnamon 5.01 ISO
- Location: Western NY, USA
Re: USM bug reports
LXQT 64bit ISO
Option to Open output file doesn't work with 3.1 final's LXQT PCmanFM.
Option to Merge Modules doesn't clear after module built thus next run it appears the option is selected when it's not.
Option to Open output file doesn't work with 3.1 final's LXQT PCmanFM.
Option to Merge Modules doesn't clear after module built thus next run it appears the option is selected when it's not.
- brokenman
- Site Admin
- Posts: 6105
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
Re: USM bug reports
Thanks. Will attend to this.
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.
- Ed_P
- Contributor
- Posts: 8908
- Joined: 06 Feb 2013, 22:12
- Distribution: Cinnamon 5.01 ISO
- Location: Western NY, USA
Re: USM bug reports
When USM GUI searches for dependencies it doesn't take into account the type of modules already installed may not all be the same type the module being built requires.
Confusing, I know.
For an example of what I am trying to say see this thread: http://forum.porteus.org/viewtopic.php?f=81&t=4136
When I initially did a build for kpat on my 64-bit system USM found that I had a libdbusmenu-qt-0.9.2-i486-2 installed and thus didn't add the libdbusmenu-qt-0.9.2-x86_64-2.xzm version to the dependencies for kpat. As such the kpat .xzm module USM built failed on my system.
I have Wine modules and they apparently use 32-bit files which confused USM when they were active.

For an example of what I am trying to say see this thread: http://forum.porteus.org/viewtopic.php?f=81&t=4136
When I initially did a build for kpat on my 64-bit system USM found that I had a libdbusmenu-qt-0.9.2-i486-2 installed and thus didn't add the libdbusmenu-qt-0.9.2-x86_64-2.xzm version to the dependencies for kpat. As such the kpat .xzm module USM built failed on my system.
I have Wine modules and they apparently use 32-bit files which confused USM when they were active.
- brokenman
- Site Admin
- Posts: 6105
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
Re: USM bug reports
Unfortunately I have no way to address this situation. If a user puts a 32bit package into a 64bit system, USM has no way of knowing this (when searching for packages) since it only searches the file names. Checking the integrity of every library on the system would severely effect process time. Can you give me an example of the 32bit files that wine uses?
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.
- Ed_P
- Contributor
- Posts: 8908
- Joined: 06 Feb 2013, 22:12
- Distribution: Cinnamon 5.01 ISO
- Location: Western NY, USA
Re: USM bug reports
brokenman wrote:Can you give me an example of the 32bit files that wine uses?

I suspect the files are in the Wine-1.7.26-x64-GeckoMono-1.xzm module that I downloaded months ago to support running 32-bit Window apps in Porteus.
- brokenman
- Site Admin
- Posts: 6105
- Joined: 27 Dec 2010, 03:50
- Distribution: Porteus v4 all desktops
- Location: Brazil
Re: USM bug reports
I don't completely understand the question. A user can list the contents of any module using: lsxzmDo you have a recommended way to analyse the contents of .xzm files for i486?
This won't tell you if each file is a 32 or 64 bit file, but the contents of var/log/packages will show you which packages belong to which arch.
How do i become super user?
Wear your underpants on the outside and put on a cape.
Wear your underpants on the outside and put on a cape.
- Ed_P
- Contributor
- Posts: 8908
- Joined: 06 Feb 2013, 22:12
- Distribution: Cinnamon 5.01 ISO
- Location: Western NY, USA
Re: USM bug reports
OK, thanks.
This is what lsxzm shows me.
This is what lsxzm shows me.
Code: Select all
guest@porteus:~$ lsxzm /mnt/sda5/porteus3.0/Modules/Wine-1.7.26-x64-GeckoMono-1.xzm
:
:
- many, many, many files -
:
:
/usr/share/wine/wine.inf
/var
/var/log
/var/log/packages
/var/log/packages/compat32-libraries-3.0-x86_64-1sl
/var/log/packages/wine-1.7.26-x86_64-1sg
/var/log/removed_packages
/var/log/removed_scripts
/var/log/scripts
/var/log/scripts/compat32-libraries-3.0-x86_64-1sl
/var/log/scripts/wine-1.7.26-x86_64-1sg
/var/log/setup
/var/log/setup/tmp
guest@porteus:~$
- francois
- Contributor
- Posts: 6497
- Joined: 28 Dec 2010, 14:25
- Distribution: xfce plank porteus nemesis
- Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.
Re: USM bug reports
@Ed, Jay:
Ed, why don't you refer to your kpat thread:
http://forum.porteus.org/viewtopic.php?f=81&t=4136
Ed, why don't you refer to your kpat thread:
http://forum.porteus.org/viewtopic.php?f=81&t=4136
Prendre son temps, profiter de celui qui passe.
- Ed_P
- Contributor
- Posts: 8908
- Joined: 06 Feb 2013, 22:12
- Distribution: Cinnamon 5.01 ISO
- Location: Western NY, USA
Re: USM bug reports
francois wrote:Ed, why don't you refer to your kpat thread:
http://forum.porteus.org/viewtopic.php?f=81&t=4136

Are you referring to any post in particular?Ed_P wrote:For an example of what I am trying to say see this thread: http://forum.porteus.org/viewtopic.php?f=81&t=4136
- francois
- Contributor
- Posts: 6497
- Joined: 28 Dec 2010, 14:25
- Distribution: xfce plank porteus nemesis
- Location: Le printemps, le printemps, le printemps... ... l'hiver s'essoufle.
Re: USM bug reports
You are right, you did, you really did. 
So /usr/doc/compat32-libraries-3.0/content/libdbusmenu-qt-0.9.2-i486-2 did came from the wine module. Isn't this the exact 32bit file that brokenman was talking about?
Brokenman quoted:
Can you give me an example of the 32bit files that wine uses?

So /usr/doc/compat32-libraries-3.0/content/libdbusmenu-qt-0.9.2-i486-2 did came from the wine module. Isn't this the exact 32bit file that brokenman was talking about?
Brokenman quoted:
Can you give me an example of the 32bit files that wine uses?
Prendre son temps, profiter de celui qui passe.
-
- Full of knowledge
- Posts: 2564
- Joined: 25 Jun 2014, 15:21
- Distribution: 3.2.2 Cinnamon & KDE5
- Location: London
Re: USM bug reports
Deficiencyor USM doesn't scan Slackware 14.0?Found in pkgs.org.
Code: Select all
root@porteus:/home/guest# usm -g ktikz-0.10-i486-5sl
Nothing found for: ktikz-0.10-i486-5sl
root@porteus:/home/guest# usm -s ktikz-0.10-i486-5sl
Nothing found for ktikz-0.10-i486-5sl
root@porteus:/home/guest# usm -s ktikz
Nothing was found in Slackware but i found this in slackbuilds.
NAME : ktikz
CATEG: academic
DESC :
VERS : 0.10
Would you like to attempt to build this from source? [y/n]
root@porteus:/home/guest#
root@porteus:/home/guest# usm -g ktikz
Nothing found for: ktikz
Code: Select all
Slackware 14.0 » Slacky i486 » ktikz-0.10-i486-5sl.txz
ktikz - Qt4 TikZ Diagrams
Distribution: Slackware 14.0
Repository: Slacky i486
Package name: ktikz
Package version: 0.10
Package architecture: i486
Package type: txz
Installed size: 1,46 MB
Download size: 697,00 KB
Binary package: ktikz-0.10-i486-5sl.txz
Source package: unknown
KtikZ is a small application helping you to create TikZ (from the LaTeX pgf package) diagrams for your publications. It requires qt4 libpoppler, LaTeX (pdflatex), the LaTeX preview-latex-style package and pgf itself
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB
-
- Samurai
- Posts: 116
- Joined: 10 Nov 2013, 12:02
- Distribution: LXDE3.5Manjaro, LXDE3.01-32bit
- Location: Sweden
Re: USM bug reports
Re-post, as this was Originally posted here:
viewtopic.php?f=113&t=4305 ,
as it prohibit me from find / do updates to the GHOST-bug in end of January 2015. (Not solved it yet. )
is this below a known USM-bug?
I was Looking for files for glibc-updates, (the "GHOST"-bug), see this first: https://www.linuxquestions.org/question ... ost5307499
. . . . . . . THE RE-POST, ABOUT USM: . . . . . . . . . .
Hmm,
Now when I try, I get this errors popping up in USM (GUI):
- - - - -
Processing:
Could not find: LIBS.TXT
- - - - -
and another window:
- - - -
Fatal error
LIBS.TXT
[OK]
- - - -
[Edit]
Hmm..
I found a possible USM-bug that probably prevented a correct function of usm.
I some time ago changed computer (or removed some usbs..) the active storage was therefore renamed from sdc to the sdb drive, but the settings of my used storage place in usm (GUI) seems to NOT have fixed *all* the lines that it should have done in the config file, after this re-config. Now "/sdb1/usm/" is the correct one, but I still see one line of "sdc" in the file.
And the thing is.. I dont have a physical "sdc" any more.
So I assume Porteus still holds this old drive "in ramdisk", as it still shows up here in /mnt/sdc1. Not sure why or how that works.
here is a snip from inside the usm-config file, where I spotted the possible bug/problem in the GUI-app:
AUTOCHECK=true
# Storage of database files (e.g PACKAGES.TXT)
DBDIR=/mnt/sdc1/usmsaker
THIS IS OLD! And I assume it also should have changed when GUI did change the storage place. This place "sdc1" dont exist IRL at all any more, but files are still there in the RAM-filesystem. (hmm , did I understand this correct ? I can go to /mnt/sdc1/usmsaker/local/libs.txt and open the file.., that one USM complains about(if I use low cases-letters), but as "sdc1" dont exists as real drive here any more..where ARE they now actually placed IRL then? Do I actually got an virtual sdc-"drive" with some (un-used) files stored inside my saves-modue at my sdb1 now? :-) A bit confusing sometimes. )
# usm works with the repositories of various slackware based distros.
# The variable below is used to find the mirror for each distro given.
# The mirror files are stored in ${DBDIR}/mirrors-distro.txt
DISTROS="slackware slackwarepatches slacky salix alien ponce"
# Where packages will be downloaded to.
STORAGE=/mnt/sdb1/usm
This is the new and "real" place at the flash memory that I have set in the GUI.
viewtopic.php?f=113&t=4305 ,
as it prohibit me from find / do updates to the GHOST-bug in end of January 2015. (Not solved it yet. )
is this below a known USM-bug?
I was Looking for files for glibc-updates, (the "GHOST"-bug), see this first: https://www.linuxquestions.org/question ... ost5307499
. . . . . . . THE RE-POST, ABOUT USM: . . . . . . . . . .
Hmm,
Now when I try, I get this errors popping up in USM (GUI):
- - - - -
Processing:
Could not find: LIBS.TXT
- - - - -
and another window:
- - - -
Fatal error
LIBS.TXT
[OK]
- - - -
[Edit]
Hmm..
I found a possible USM-bug that probably prevented a correct function of usm.
I some time ago changed computer (or removed some usbs..) the active storage was therefore renamed from sdc to the sdb drive, but the settings of my used storage place in usm (GUI) seems to NOT have fixed *all* the lines that it should have done in the config file, after this re-config. Now "/sdb1/usm/" is the correct one, but I still see one line of "sdc" in the file.
And the thing is.. I dont have a physical "sdc" any more.
So I assume Porteus still holds this old drive "in ramdisk", as it still shows up here in /mnt/sdc1. Not sure why or how that works.
here is a snip from inside the usm-config file, where I spotted the possible bug/problem in the GUI-app:
AUTOCHECK=true
# Storage of database files (e.g PACKAGES.TXT)
DBDIR=/mnt/sdc1/usmsaker
THIS IS OLD! And I assume it also should have changed when GUI did change the storage place. This place "sdc1" dont exist IRL at all any more, but files are still there in the RAM-filesystem. (hmm , did I understand this correct ? I can go to /mnt/sdc1/usmsaker/local/libs.txt and open the file.., that one USM complains about(if I use low cases-letters), but as "sdc1" dont exists as real drive here any more..where ARE they now actually placed IRL then? Do I actually got an virtual sdc-"drive" with some (un-used) files stored inside my saves-modue at my sdb1 now? :-) A bit confusing sometimes. )
# usm works with the repositories of various slackware based distros.
# The variable below is used to find the mirror for each distro given.
# The mirror files are stored in ${DBDIR}/mirrors-distro.txt
DISTROS="slackware slackwarepatches slacky salix alien ponce"
# Where packages will be downloaded to.
STORAGE=/mnt/sdb1/usm
This is the new and "real" place at the flash memory that I have set in the GUI.