OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: Dariusz Piatkowski on May 06, 2023, 04:08:29 pm
-
Just spotted that libc has been updated, so I figured I'd give this a go.
Firing up ANPM went just fine, but attempting to update that RPM consistently results in the following error (see attachment).
Went as far as to re-boot, still the same result...curious if anyone is seeing this as well?
Running ANPM in DEBUG mode produces the following:
...
[RunYum] Starting execution thread for command: yum_update_dep.py libc
[RunYum] -> Thread 10 started successfully.
[PyDone] Thread for "yum_update_dep.py libc" completed with status 0.
[PyDone] Processing exit logic for "YUM_UPDATE_DEP.PY".
[GetScalingFactor] Using font size 10 (scaling factor 1)
[DLLCheck] Checking 9 DLLs for conflicts
[CheckDllConflict] - LIBCN0.DLL
[CheckDllConflict] --> G:\USR\LIB\LIBCN0.DLL
[CheckDllConflict] - LIBC06.DLL
[CheckDllConflict] --> G:\USR\LIB\LIBC06.DLL
[CheckDllConflict] - LIBC061.DLL
[CheckDllConflict] --> G:\USR\LIB\LIBC061.DLL
[CheckDllConflict] - LIBC062.DLL
[CheckDllConflict] --> G:\USR\LIB\LIBC062.DLL
[CheckDllConflict] - LIBC063.DLL
[CheckDllConflict] --> G:\USR\LIB\LIBC063.DLL
[CheckDllConflict] - LIBC064.DLL
[CheckDllConflict] --> G:\USR\LIB\LIBC064.DLL
[CheckDllConflict] - LIBC065.DLL
[CheckDllConflict] --> G:\USR\LIB\LIBC065.DLL
[CheckDllConflict] - LIBC066.DLL
[CheckDllConflict] --> G:\USR\LIB\LIBC066.DLL
[CheckDllConflict] - LIBCN0.DLL
[CheckDllConflict] --> G:\USR\LIB\LIBCN0.DLL
[GetScalingFactor] Using font size 10 (scaling factor 1)
...
...so perhaps there is some sort of a scaling logic issue here? I do recall this is one of the changes that Alex rolled out in the last ANPM release.
BTW: nothing in POPUPLOG.OS2 and no TRP files.
-
Which architecture is the previous libc? If i686, try changing it to Pentium 4 and then retry upgrading. To change, right click libc in ANPM and choose get specific release.
-
Dave!
All my stuff has been moved to pentium4 some time ago, and given the choice I always make sure to select that option.
In this case, libc is a pentium4 package.
-
Just spotted that libc has been updated, so I figured I'd give this a go.
Firing up ANPM went just fine, but attempting to update that RPM consistently results in the following error (see attachment).
...so perhaps there is some sort of a scaling logic issue here? I do recall this is one of the changes that Alex rolled out in the last ANPM release.
BTW: nothing in POPUPLOG.OS2 and no TRP files.
Here is the full call stack until point of error:
Line 5 of RescaleObject in yumie.VRM:
+++ x = VRGet(object, 'Left');
*** Error 40 Incorrect call to routine
Line 47 of SW_CONFLICT_Init in yumie.VRM:
+++ Call RescaleObject 'DT_CONFLICT_IGNORE', factor;
Line 3 of SW_CONFLICT_Create in yumie.VRM:
+++ Call SW_CONFLICT_Init;
Line 80 of Main in yumie.VRM:
+++ Call SW_CONFLICT_Create;
Line 80 of Main in yumie.VRM:
+++ Interpret __vrlsEvent;
Line 4 of ConflictPopup in yumie.VRM:
+++ Call VRLoadSecondary 'SW_CONFLICT', 'W';
Line 29 of DLLCheck in yumie.VRM:
+++ action = ConflictPopup('dll');
Line 102 of SW_DOWNLOAD_Init in yumie.VRM:
+++ c_action = DLLCheck();
Line 3 of SW_DOWNLOAD_Create in yumie.VRM:
+++ Call SW_DOWNLOAD_Init;
Line 80 of Main in yumie.VRM:
+++ Call SW_DOWNLOAD_Create;
Line 80 of Main in yumie.VRM:
+++ Interpret __vrlsEvent;
Line 547 of PyDone in yumie.VRM:
+++ Call VRLoadSecondary 'SW_DOWNLOAD', 'W';
Line 51 of Main in yumie.VRM:
+++ Call PyDone;
Line 51 of Main in yumie.VRM:
+++ Interpret _VREEvent;
Maybe this has something to do with python (at least "yumie" is a python class), but I don't know. Let's hope that Alex will chime in.
-
A bug in the conflict dialog initialization. I'll fix it.
However, that won't fix your underlying problem, which is that yum is reporting a package dependency conflict. You can try looking examining the end of %LOGFILES%\anpm.log, which records the raw output from yum.
-
Hi Alex,
A bug in the conflict dialog initialization. I'll fix it...
Happy to test, just let me know...
...However, that won't fix your underlying problem, which is that yum is reporting a package dependency conflict. You can try looking examining the end of %LOGFILES%\anpm.log, which records the raw output from yum.
Well, that's the weird part, ANPM.LOG is the first place I went, but that only shows:
...
----------[ 6 May 2023 10:24:03 ]----------
Executing: @python2.7 G:\UTIL\ANPM\scripts\yum_update_dep.py libc
Enabling temporary repository arcanoae-sub
Enabling temporary repository arcanoae-exp
Enabling temporary repository arcanoae-stage
Enabling temporary repository arcanoae-arcaos
No argument pipe.
Return code: 0
Nothing here looks unusual compared to all the other successful updates before...weird, no?
I haven't tried the CLI update yet, although it does appear to correctly recognize that the matching libc update is out there:
[G:\]yum list libc
Loaded plugins: changelog, downloadonly, ps, replace, verify
Installed Packages
libc.pentium4 1:0.1.9-1.oc00 installed
Available Packages
libc.i686 1:0.1.9-1.oc00 netlabs-rel
libc.pentium4 1:0.1.10-1.oc00 netlabs-rel
I figured it would be best to investigate through ANPM first.
-
I have,
H:\tmp>yum list libc
Installed Packages
libc.pentium4 1:0.1.10-1.oc00 installed
Available Packages
libc.i686 1:0.1.9-1.oc00 netlabs-rel
I installed from netlabs-exp, wonder if I also updated Python or such first and so avoided the error.
You might have to open an issue at Bitwise's Github.
-
Alright, so for what its worth, I ran a CLI update, here is the output:
--> Running transaction check
---> Package libc.pentium4 1:0.1.9-1.oc00 will be updated
--> Processing Dependency: libc = 1:0.1.9-1.oc00 for package: 1:libc-devel-0.1.9-1.oc00.pentium4
---> Package libc.pentium4 1:0.1.10-1.oc00 will be an update
--> Running transaction check
---> Package libc-devel.pentium4 1:0.1.9-1.oc00 will be updated
---> Package libc-devel.pentium4 1:0.1.10-1.oc00 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Updating:
libc pentium4 1:0.1.10-1.oc00 netlabs-rel 1.0 M
Updating for dependencies:
libc-devel pentium4 1:0.1.10-1.oc00 netlabs-rel 3.1 M
Transaction Summary
================================================================================
Upgrade 2 Packages
Total download size: 4.1 M
Is this ok [y/N]: y
Downloading Packages:
(1/2): libc-0.1.10-1 | 1.0 MB 00:00 ] 462 kB/s | 388 kB 00:01 ETA
(2/2): libc-devel-0. | 3.1 MB 00:01 ===- ] 1.3 MB/s | 2.8 MB 00:00 ETA
--------------------------------------------------------------------------------
Total 1.6 MB/s | 4.1 MB 00:02
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Warning: RPMDB altered outside of yum.
** Found 1 pre-existing rpmdb problem(s), 'yum check' output follows:
pci-ids-2022.07.02-0.oc00.noarch is a duplicate with pci-ids-2019.09.18-0.oc00.noarch
Updating : 1:libc-0.1.10-1.oc00.pentium4 1/4
Updating : 1:libc-devel-0.1.10-1.oc00.pentium4 2/4
Cleanup : 1:libc-devel-0.1.9-1.oc00.pentium4 3/4
Cleanup : 1:libc-0.1.9-1.oc00.pentium4 4/4
Rpmdb checksum is invalid: dCDPT(pkg checksums): libc-devel.pentium4 1:0.1.10-1.
oc00 - u
The only unusual / concering issue would be this pci-ids remark:
"** Found 1 pre-existing rpmdb problem(s), 'yum check' output follows:
pci-ids-2022.07.02-0.oc00.noarch is a duplicate with pci-ids-2019.09.18-0.oc00.noarch"
...but I can't imagine how that's impacting ANPM?
Anyways, CLI update was successful.