USM bug reports

[brokenman]

I posted in your other thread on slackyd. You indeed uncovered a bug. A nice one. So sorry, and thank you. I didn't look at the system dep resolution but this bug affected other functions. Will test usm -d right now. While I am on the sorry, Ed_P I tried the package you uploaded and the bundle is nowhere to be found when using GUI. In CLI it works fine. Don't even know why. It works here. Hopefully this is addressed in the latest update too.

EDIT: Looks like it is resolved:

Code: Select all

root@porteus:/home/guest# installpkg /tmp/usm/openjre-7u51_b31-x86_64-2gv.txz 
Verifying package openjre-7u51_b31-x86_64-2gv.txz.
Installing package openjre-7u51_b31-x86_64-2gv.txz:
PACKAGE DESCRIPTION:
# Java(TM) 2 Platform Standard Edition Runtime Environment.
#
# The J2SE(TM) Runtime Environment (JRE) is intended for software
# developers and vendors to redistribute with their applications.
# It contains the Java virtual machine, runtime class libraries, and
# Java application launcher that are necessary to run programs written
# in the Java programming language.
#
# If you need development tools, obtain the jdk from /extra, or see the
# web page:   http://openjdk.java.net/
#
Executing install script for openjre-7u51_b31-x86_64-2gv.txz.
Package openjre-7u51_b31-x86_64-2gv.txz installed.

root@porteus:/home/guest# usm -d /var/log/packages/openjre-7u51_b31-x86_64-2gv 

 Processing  openjre-7u51_b31-x86_64-2gv

Missing dependencies: 0

The latest version is on the server now.

[Ed_P]

While I am on the sorry, Ed_P I tried the package you uploaded and the bundle is nowhere to be found when using GUI.

So I'm not crazy. Thank you. FWIW This is what I used to create the package.

Code: Select all

#!/bin/bash
# http://forum.porteus.org/viewtopic.php?f=117&t=3205&start=15#p24861

mkdir -p /tmp/usm/usr/share/applications
mkdir -p /tmp/usm/usr/share/icons/hicolor/48x48/apps
mkdir -p /tmp/usm/usr/man/man8
mkdir -p /tmp/usm/etc/usm
mkdir -p /tmp/usm/var/usm

cp -a --parents /usr/bin/usm*                 /tmp/usm/ 
cp -a --parents /usr/bin/packagetools         /tmp/usm/ 
cp -a --parents /usr/share/applications/usm.* /tmp/usm/
cp -a --parents /usr/share/icons/hicolor/48x48/apps/usm*.* /tmp/usm/
cp -a --parents /usr/share/usm/*              /tmp/usm/
cp -a --parents /usr/man/man8/usm*.*          /tmp/usm/
cp -a --parents /etc/usm                      /tmp/usm/
cp -a --parents /var/usm                      /tmp/usm/

echo
echo Press Enter to create module, Ctrl+C to end.
read

dir2xzm /tmp/usm /tmp/usm.xzm

rm -dir -f /tmp/usm

The download/update to 3.1.3 worked OK but after restarting USM and doing an Update All the Optimizing Manifests all failed with a:

Code: Select all

/usr/share/usm/funcupdateDatabase: line 296: [: 14-729: unary operator expected

error.

Wish there was an easy way to copy & paste text from the USM terminal window.

ah hah

Code: Select all

 Starting sbo database update 
SLACKBUILDS.TXT.gz
Downloading: SLACKBUILDS.TXT.gz  DONE
/usr/share/usm/funcupdateDatabase: line 296: [: 140729: unary operator expected
 sbo  database updated.  

[Bogomips]

EDIT: Looks like it is resolved:

Code: Select all

root@porteus:/home/guest# usm -d /var/log/packages/openjre-7u51_b31-x86_64-2gv 
 Processing  openjre-7u51_b31-x86_64-2gv
Missing dependencies: 0

The latest version is on the server now.

1. Code: Select all

   root@porteus:/home/guest# usm -u usm
   Downloading: vercheck.txt  DONE
   
    An update is available for the usm database files.
    Please run:  usm -u all 
   
    A new version of USM is available.
    Would you like to download it now? [y/n]
   Downloading: usm-latest-0.0-noarch-1.txz  DONE
    Would you like to install it now? [y/n]
   
   Removing package /var/log/packages/usm-3.1.0-noarch-2...
   Removing files:
     --> /install/slack-desc was found in another package. Skipping.
   ...
   Executing install script for usm-latest-0.0-noarch-1.txz.
   Generating VLC plugins cache data...
   Package usm-latest-0.0-noarch-1.txz installed.
   
   root@porteus:/home/guest# vi /etc/usm/usm.conf
   root@porteus:/home/guest# activate p10/Por/Java/openjre-7u51_b31-i486-2gv.xzm
   Adding 10 new loop devices
   Updating shared library links:  /sbin/ldconfig
   root@porteus:/home/guest# usm -d /var/log/packages/openjre-7u51_b31-i486-2gv
   
    Processing  openjre-7u51_b31-i486-2gv
   
   Missing dependencies: 0
   

2. Code: Select all

   guest@porteus:~$ ldd /usr/lib/java/jre/lib/i386/libjawt.so
           linux-gate.so.1 (0xb76e5000)
           libawt.so => /usr/lib/java/jre/lib/i386/libawt.so (0xb762d000)
           libmawt.so => not found
           libjava.so => /usr/lib/java/jre/lib/i386/libjava.so (0xb75f6000)
           libjvm.so => /usr/lib/libjvm.so (0xb6958000)
           libc.so.6 => /lib/libc.so.6 (0xb67cc000)
           libm.so.6 => /lib/libm.so.6 (0xb678a000)
           libdl.so.2 => /lib/libdl.so.2 (0xb6785000)
           libverify.so => /usr/lib/java/jre/lib/i386/libverify.so (0xb6779000)
           libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6691000)
           libpthread.so.0 => /lib/libpthread.so.0 (0xb6676000)
           /lib/ld-linux.so.2 (0xb76e6000)
           libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb665a000)
   

[brokenman]

ldd /usr/lib/java/jre/lib/i386/libjawt.so

Can't do much about badly linked libraries. USM knows the file exists though.

Thanks Ed_P, I will fix this error. It won't affect functionality. It comes from trying to update the version number in usm.conf when it is already updated. Will add some quotes around it.

[Ed_P]

3.1.3 produces a samba bundle in Always fresh mode.

But still the line 296 error.

[Ed_P]

And somethings never change.

After updating to 3.1.3 and building a samba module and rebooting. USM GUI fails to open and in terminal mode we have:

Code: Select all

guest@porteus:~$ su
Password: 
root@porteus:/home/guest# usm -v
awk: fatal: cannot open file `/etc/usm/usm.conf' for reading (No such file or directory)
/usr/bin/usm: line 61: /etc/usm/usm.conf: No such file or directory
/usr/bin/usm: line 62: /share/usm/funcelementCreate: No such file or directory
/usr/bin/usm: line 63: /share/usm/funccleanup: No such file or directory
/usr/bin/usm: line 64: /share/usm/funcsystemSetup: No such file or directory
/usr/bin/usm: line 65: /share/usm/funccli: No such file or directory
/usr/bin/usm: line 66: /share/usm/funcgtkDialogs: No such file or directory
/usr/bin/usm: line 67: /share/usm/functxtStatic: No such file or directory
/usr/bin/usm: line 68: /share/usm/funcpackageSearch: No such file or directory
/usr/bin/usm: line 69: /share/usm/funcpackageInfo: No such file or directory
/usr/bin/usm: line 70: /share/usm/funcchecks: No such file or directory
/usr/bin/usm: line 71: /share/usm/funcpackageGet: No such file or directory
/usr/bin/usm: line 72: /share/usm/funcupdateDatabase: No such file or directory
/usr/bin/usm: line 73: /share/usm/funcchangelogs: No such file or directory
/usr/bin/usm: line 74: /share/usm/funcslackbuilds: No such file or directory
/usr/bin/usm: line 75: /share/usm/funcsystemDeps: No such file or directory
/usr/bin/usm: line 76: /share/usm/funcworkhorse: No such file or directory
/usr/bin/usm: line 146: help_check: command not found
/usr/bin/usm: line 158: system_setup: command not found

You are using USM version: 
/usr/bin/usm: line 282: cleanup: command not found
/usr/bin/usm: line 672: cleanup: command not found
root@porteus:/home/guest# 

[Ed_P]

I will fix this error. It won't affect functionality. It comes from trying to update the version number in usm.conf when it is already updated. Will add some quotes around it.

Will the fix be in 3.1.3.1 or 3.1.4?

BTW it appears that line 296 is already using quotes.

[brokenman]

And somethings never change.

It seems so. We already established (long ago) that this is not a bug of USM. It has to do with your whiteout files. Once again at least try in fresh mode before posting a bug.

The unimportant error message will be fixed in a quick update. There are no quotes around the offender, hence the error message.

[Ed_P]

We already established (long ago) that this is not a bug of USM.

Not according to the red text posted here: http://forum.porteus.org/viewtopic.php? ... 697#p24697


BTW Would a solution be not deleting the usm.conf file but rather simply have the update replace the old one?

try in fresh mode before posting a bug.

It can't be tested in fresh mode, fresh mode doesn't save the changes so rebooting doesn't have the updated files and their whiteout deletes.

The unimportant error message will be fixed in a quick update.

Ok, thanks.

[brokenman]

Not according to the red text posted here: viewtopic.php?f=75&t=3040&p=24697#p24697

Yes. Don't use the script with changes=. That's why it is there in big red text.
Remove your whiteout files from your changes file manually as you did in the past, and then keep away from the script. Just update using the USM function. The script is NOT a part of USM. It was only posted because someone requested it. I use it in development (fresh mode)

BTW Would a solution be not deleting the usm.conf file but rather simply have the update replace the old one?

Yes, that's what the update function in USM does. It uses removepkg from pkgtools. If you have already run that other script (with changes=) then the whiteout files already exist and are loaded at each boot so it doesn't matter how you install USM after this, the whiteout file will take precedence.

It can't be tested in fresh mode, fresh mode doesn't save the changes so rebooting doesn't have the updated files and their whiteout deletes.

Precisely my point. The problem is the whiteout files not USM. This is not a USM bug.

[Ed_P]

Just update using the USM function.

I did use the USM GUI's Update function. I didn't use the script or terminal mode.

It can't be tested in fresh mode, fresh mode doesn't save the changes so rebooting doesn't have the updated files and their whiteout deletes.

Precisely my point. The problem is the whiteout files not USM. This is not a USM bug.

But USM is creating the whiteout files. USM's GUI, not a script.

Firefox creates whiteout files every day and it stills runs ok after booting. Same with Java and Flash and things that I manually delete. Only USM is having a problem with the files it is creating.

What would happen if you renamed the usm.conf file to something like oldusm.conf then deleted it?

[Blaze]

What about support proxy settings for USM?

[brokenman]

But USM is creating the whiteout files. USM's GUI, not a script.

Ok, let me check it out and get back to you.

Good to see you here Blaze. It is already implemented is USM but nobody has reported using it yet. Edit the /etc/usm/usm.conf file to test it.
EDIT:
Found some flaws in the way proxies are used. Will release fix in next version. Will support proxy with authentication. At the moment only straight proxy with no authentication is supported.

[brokenman]

Add support for authenticated proxy. Still working on GUI for setting proxy that will encode password. Don't like holding it in plain text. Latest version is available on github.

https://github.com/brokenman/usm

EDIT:
Sorry Ed_P. I couldn't reproduce your error with changes enabled. I booted to a fresh porteus and set up changes. Rebooted and verified that changes were working. Updated USM. Rebooted and everything was working as expected. No problems created with whiteout files when they are left alone. Here is the file list of the pertinent whiteout files.

Code: Select all

ls -1 -a /mnt/sda8/changes/change
./
../
.wh..wh.aufs
.wh..wh.orph/
.wh..wh.plnk/
dev/
etc/
home/
mnt/
opt/
root/
tmp/
usr/
var/

ls -1 -a /mnt/sda8/changes/change
./
../
.wh..wh..opq
extra-deps.txt
files.conf
mirrors-alien.txt
mirrors-ponce.txt
mirrors-salix.txt
mirrors-sbo.txt
mirrors-slackware.txt
mirrors-slackwarepatches.txt
mirrors-slacky.txt
suppliment-libs.txt
suppliment-optifest.txt
usm.conf

The wh.aufs file is a whiteout base file. Important not to delete.
wh..opq tells aufs which directories are opaque
Not too sure on the plnk whiteout but I suspect it handles links.

[Ed_P]

I am definitely not seeing what you're seeing brokenman.

Code: Select all

guest@porteus:~$ ls -l -a /mnt/sda5/porteus/changes/porteussave.dat
-rwxrwxrwx 1 root root 268435456 Jul 31 18:07 /mnt/sda5/porteus/changes/porteussave.dat*
guest@porteus:~$ 

In order to see inside the save.dat file I have to mloop it. To see inside the live changes file I use the find command:

Code: Select all

guest@porteus:~$ su
Password: 
root@porteus:/home/guest# find /mnt/live/memory/images/changes -name .wh.*
/mnt/live/memory/images/changes/home/guest/.mozilla/firefox/c3pp43bg.default/bookmarkbackups/.wh.bookmarks-2014-07-27.json
/mnt/live/memory/images/changes/home/guest/.mozilla/firefox/c3pp43bg.default/bookmarkbackups/.wh.bookmarks-2014-07-26.json
/mnt/live/memory/images/changes/home/guest/.cache/mozilla/firefox/c3pp43bg.default/safebrowsing/.wh..wh..opq
/mnt/live/memory/images/changes/home/guest/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys/.wh..wh..opq
root@porteus:/home/guest# 

And if you recall, I am not the only one who has had problems with USM due to whiteout files. http://forum.porteus.org/viewtopic.php? ... 613#p25883

With your change file did you use the changes=EXIT cheatcode?