Created attachment 11293 [details]
screenie of errors message

I forgot to specify that I selected the various 32-bit sources as I'd seen some sort of problem with that and don't know whether or how I'm impacted:

[rolf@z170i ~]$ urpmq --list-media active
Core Release
Core Updates
Nonfree Release
Nonfree Updates
Tainted Release
Tainted Updates
Core 32bit Release
Core 32bit Updates
Nonfree 32bit Release
Nonfree 32bit Updates
Tainted 32bit Release
Tainted 32bit Updates

Thank you for the clear screenshot.
Can you clarify whether the whole upgrade failed because of these errors, or whether in spite of them you ended up with a Mageia 7 system which works - or not. You said:
> Only the one time of an otherwise successful upgrade, apparently.
Re your previous comment (2), in:
 https://wiki.mageia.org/en/Mageia_7_Release_Notes#Upgrading_from_Mageia_6 :
"If you want to upgrade a 64-bit system, it may contain 32-bit software. This is not a problem provided it does not include development libraries. You can identify these by the word "devel" in the name. To know if your system houses such libraries you can use the command:
    rpm -qa --queryformat "%{NAME}-%{version}-%{RELEASE}-%{ARCH}\n" |grep i586 |grep devel 
You must un-install these libraries before upgrading."
 It is, however, very unlikely that you have such packages. And all the php-pear packages are noarch.

Assigning globally, CC'ing ISO team.

CC: (none) => isobuild
Assignee: bugsquad => pkg-bugs

The machine is a Dell/WYSE D90D7 thin client that I use for a web server on Hiawatha.

$ rpm -q hiawatha
hiawatha-10.9-3.mga7  

System:    Host: d90d7 Kernel: 5.2.16-desktop-2.mga7 x86_64 bits: 64 Desktop: LXDE 0.10.0 Distro: Mageia 7 mga7

Chrome browser looks to be working to display the picture of an outdoor POE surveillance camera, the other main usage.  Boot, desktop, everything seems to work as before the upgrade except that my webpages are throwing 403 errors and error logs show:

66.249.64.190|Sat 28 Sep 2019 15:23:37 -0700|access denied via filesystem

I've checked permissions to the best of my ability.  It all worked in MGA6.  I read about selinux getting in the way, have never fooled with selinux, and have this:

[root@d90d7 ~]# rpm -qa --last | grep selinux
libselinux-utils-2.5-10.mga7.x86_64           Sat 28 Sep 2019 11:57:31 AM PDT
libselinux-python-2.5-10.mga7.x86_64          Sat 28 Sep 2019 11:51:35 AM PDT
lib64selinux1-2.5-10.mga7.x86_64              Sat 28 Sep 2019 11:46:39 AM PDT

One oddity that existed even in my initial MGA6 installation is, even though I set up  to allow root logins with a password, after some reboots it did not work.  Eventually, I just saved a copy of sshd_config that worked and copied it over when root logins stopped working.  I have no idea why and have plenty of things to fix, so I tend to look for an easy workaround and stick with it.

I have these files in case there is interest:

[root@d90d7 ~]# ls drakx/ -l
total 19594
-rw-r--r-- 1 root root    62574 Sep 28 12:25 auto_inst.cfg.pl
-rw-r--r-- 1 root root  2734889 Sep 28 12:26 ddebug.log
-rw-r--r-- 1 root root 12089711 Jun 10  2018 ddebug.log1
-rw-r--r-- 1 root root   594777 Sep 28 12:18 install.log
-rw-r--r-- 1 root root   390179 Jun 10  2018 install.log1
-rw-r--r-- 1 root root    58656 Sep 28 12:20 package_list.pl
-rw-r--r-- 1 root root      243 Sep 28 12:20 README
-rw-r--r-- 1 root root  3633501 Sep 28 12:20 report.bug
-rw-r--r-- 1 root root   448612 Jun 10  2018 report.bug.xz
-rw-r--r-- 1 root root     3109 Sep 28 12:26 stage1.log
-rw-r--r-- 1 root root     3163 Jun 10  2018 stage1.log1

However, I first amateurishly created my websites on an older 32-bit IGEL thin client running Puppy 4.31 and hiawatha some years ago.  I just copied files over to the D90D7, which I got in order to set up https with letsencrypt, not doable, in my world, on the IGEL.  In Puppy, everything was owned by root and I see, now, hiawatha files are nobody.nobody, as advised; I *thought* they used to be root.root.

I am about ready to install MGA7 plasma to the D90D7 and build hiawatha-10.10, which Hugo says contains a new letsencrypt he wrote for some API change in letsencrypt, or some such.  https://www.hiawatha-webserver.org/weblog/133  I need those websites.

I think all the pear* packages have scriplets that do basically the same thing, such as the following:

%post
pear install --nodeps --soft --force --register-only %{xmldir}/File_Iterator.xml

%postun
if [ "$1" -eq "0" ]; then
    pear uninstall --nodeps --ignore-errors --register-only pear.phpunit.de/File_Iterator
fi


I'm not sure exactly what those commands do or why they would fail.  Maybe while the system is in some partially upgraded state as urpmi goes through its transactions, the pear command temporarily doesn't work.

Created attachment 11326 [details]
Running `urpmq --whatrequires` on packages reported by error message

I don't know why these packages reported this error on this MGA6->7 upgrade:

php-pear-File_Iterator
php-pear-Text_Template
php-pear-channel-horde
php-pear-PHPUnit_MockObject
php-pear-PHP_TokenStream
php-pear-PHPUnit_Story
php-pear-PHP_Invoker
php-pear-PHP_Timer
php-pear-channel-symfony2
php-pear-Symfony2_Yaml
php-pear-DbUnit
php-pear-PHPUnit_Selenium
php-pear-PHP_CodeCoverage
php-pear-PHPUnit

Basically grasping at straws, I ran `urpmq --whatrequires` on the list and attach the results.  As hiawatha was installed and upgraded, albeit my websites stopped working as a result, I looked for a relationship.  I have since removed hiawatha and built a copy from Hugo Leisink's source code, which is working.

I noticed that phpmyadmin requires php-pear-File_Iterator as phpMyAdmin is part of Hugo's hiawatha.  However, I don't see it in the Mageia rpm or it's --requires.

Also,

[rolf@d90d7 ~]$ rpm -qa | grep pear
[rolf@d90d7 ~]$ rpm -qa | grep PEAR
[rolf@d90d7 ~]$

I can't explain why scripts for these pear packages entered into the upgrade.  Finally,

"Script errors

When you create a script that references PEAR, make sure to add these two lines at the very top of that script:

error_reporting(E_ALL ^ E_NOTICE ^ E_DEPRECATED ^ E_STRICT);
set_include_path("." . PATH_SEPARATOR . ($UserDir = dirname($_SERVER['DOCUMENT_ROOT'])) . "/pear/php" . PATH_SEPARATOR . get_include_path());

    The first line turns off any errors that may show.
    The second line allows the script to reference your PEAR installation.
..."

- https://help.dreamhost.com/hc/en-us/articles/214395118-Troubleshooting-PEAR-errors

Thanks.

Hi,
This bug is against our Installer DrakX.

@Developers/Packagers: Feel free to reassign to correct person.
Also, if you are working on this, please change the status of this bug to "Assigned".
Feel free to close this if already fixed.

@All
Thanks making DrakX even better.

This is a packaging issue, not an installer bug. Reassigning to the current maintainer of the php-pear packages.

Source RPM: (none) => php-pear-*
CC: isobuild => (none)
Component: Installer => RPM Packages
Assignee: pkg-bugs => mageia

it is possible we have an incomplete php installation during update. Sometimes a few modules are not updated immedeately and php shows an error like "unable to load module XXX ABI not matching" (sth. like this).
In this case, I assume the return code of the script is not 0, but the script was executed correctly.
I'm not sure if it is possible to tell rpm php-pear can only be run, if all modules are updated. Currently updating php-mysqli is basically equivalent to update pear-*. In mga8 I request all modules to require the same ABI version, which will hopefully request rpm to ensure all php-modules are updated, before pear packages can be updated.

I'll close this, as it never happend again.

Resolution: (none) => WONTFIX
Status: NEW => RESOLVED