ANPM - libc upgrade error...?

[Dariusz Piatkowski]

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:

Code: [Select]

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

[Dave Yeo]

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.

[Dariusz Piatkowski]

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.

[Lars]

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:

Code: [Select]

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.

[Alex Taylor]

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.

[Dariusz Piatkowski]

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:

Code: [Select]

...
----------[ 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:

Code: [Select]

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

[Dave Yeo]

I have,

Code: [Select]

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.

[Dariusz Piatkowski]

Alright, so for what its worth, I ran a CLI update, here is the output:

Code: [Select]

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