%post(php-pear-Text_Template-1.2.0-6.mga8.noarch) scriptlet failed, exit status 1 php-pear-Text_Template-1.2.0-6.mga8.noarch %post(php-pear-File_Iterator-1.3.4-7.mga8.noarch) scriptlet failed, exit status 1 %post(php-pear-PHP_Timer-1.0.5-7.mga8.noarch) scriptlet failed, exit status 1 php-pear-PHP_Timer-1.0.5-7.mga8.noarch %post(php-pear-PHP_Invoker-1.1.3-7.mga8.noarch) scriptlet failed, exit status 1 php-pear-PHP_Invoker-1.1.3-7.mga8.noarch %post(php-pear-PHP_TokenStream-1.2.2-6.mga8.noarch) scriptlet failed, exit status 1 php-pear-PHP_TokenStream-1.2.2-6.mga8.noarch %post(php-pear-PHPUnit_Story-1.0.2-7.mga8.noarch) scriptlet failed, exit status 1 php-pear-PHPUnit_Story-1.0.2-7.mga8.noarch -- %post(php-pear-channel-horde-1.0-22.mga8.noarch) scriptlet failed, exit status 1 php-pear-channel-horde-1.0-22.mga8.noarch %post(php-pear-PHPUnit_MockObject-1.2.3-7.mga8.noarch) scriptlet failed, exit status 1 php-pear-PHPUnit_MockObject-1.2.3-7.mga8.noarch %post(php-pear-DbUnit-1.3.1-7.mga8.noarch) scriptlet failed, exit status 1 php-pear-DbUnit-1.3.1-7.mga8.noarch %post(php-pear-PHPUnit_Selenium-1.3.3-7.mga8.noarch) scriptlet failed, exit status 1 php-pear-PHPUnit_Selenium-1.3.3-7.mga8.noarch %post(php-pear-PHP_CodeCoverage-1.2.17-7.mga8.noarch) scriptlet failed, exit status 1 php-pear-PHP_CodeCoverage-1.2.17-7.mga8.noarch %post(php-pear-PHPUnit-3.7.34-5.mga8.noarch) scriptlet failed, exit status 1
Assignee: bugsquad => pkg-bugs
Assignee: pkg-bugs => mageiaCC: (none) => pkg-bugs
Increasing priority for upgrade problems to release blocker
CC: (none) => davidwhodginsPriority: Normal => release_blocker
Ping me for errata if it get no fix
CC: (none) => fri
technically it's not an release_blocker, it's an upgrade_blocker :) we always delay the update api for some time so we have time to fix stuff like this found by early upgraders
Blocks: (none) => 28393
looks like a dependancy issue. I assume we don't have output of post scripts? My guess is, php is not fully installed, e.g. some modules have not been upgraded, so pear fails. But without output this is only guessing. To be honest, it does not do any harm, if the scriplets fail, everything will work. Still I'll have a look at it.
Priority: release_blocker => High
(In reply to Thomas Backlund from comment #3) > technically it's not an release_blocker, it's an upgrade_blocker :) > > we always delay the update api for some time so we have time to fix stuff > like this found by early upgraders We also describe in release notes how to proceed if update applet do not offer it, and we also describe processes to upgrade without it. So a user that reads Mageia 8 is released and wants to upgrade immediately, will.
I'm not sure if I can reproduce this. I can only guess that the problem lies here: php-pear-* does only require php-pear without any specific version (which is "quite fine"). During update it might happen php is not fully updated and complains at startup about an old module still present. But this is only a guess. The "scriptlet" is just some registration stuff: pear install --register-only In case of upgrade, the package is already registered, so no harm is done.
Is this visible to the user? (without looking in logs) I think that if it is, we should note it in Errata, else not.
Hi, Thus, I presume that the problem was that the update was in three steps and that the second one was without online repositories. I'm OK to close this report for php-pear-*. However, I find that the installer is not clear of why the cycle was started again and that the repositories shouldn't change at this step.
I just completed an upgrade test with the packages mediawiki, roundcubemail, and task-lamp installed prior to starting the upgrade (using mgaapplet --testing). After the upgrade, the following php-pear packages are installed ... # rpm -qa|grep php-pear|sort php-pear-1.10.12-5.mga8 php-pear-Auth_SASL-1.1.0-2.mga8 php-pear-channel-horde-1.0-22.mga8 php-pear-channel-symfony2-1.0-8.mga8 php-pear-Console_Color2-0.1.2-8.mga8 php-pear-Console_CommandLine-1.2.2-3.mga8 php-pear-Console_Getargs-1.4.0-3.mga8 php-pear-Console_Table-1.3.1-3.mga8 php-pear-Crypt_GPG-1.6.4-1.mga8 php-pear-DbUnit-1.3.1-7.mga8 php-pear-Event_Dispatcher-1.1.0-11.mga8 php-pear-File_Find-1.3.3-6.mga8 php-pear-File_Iterator-1.3.4-7.mga8 php-pear-HTML_Common-1.2.5-10.mga8 php-pear-HTML_CSS-1.5.4-13.mga8 php-pear-HTML_Table-1.8.4-3.mga8 php-pear-HTTP_Request2-2.4.2-1.mga8 php-pear-Mail_Mime-1.10.9-1.mga8 php-pear-Net_IDNA2-0.2.0-3.mga8 php-pear-Net_LDAP2-2.2.0-2.mga8 php-pear-Net_Sieve-1.4.4-2.mga8 php-pear-Net_SMTP-1.9.0-2.mga8 php-pear-Net_Socket-1.2.2-3.mga8 php-pear-Net_URL2-2.2.1-3.mga8 php-pear-PEAR_PackageFileManager-1.7.2-3.mga8 php-pear-PEAR_PackageFileManager2-1.0.4-7.mga8 php-pear-PEAR_PackageFileManager_Plugins-1.0.4-3.mga8 php-pear-PHP_CodeCoverage-1.2.17-7.mga8 php-pear-PHP_CompatInfo-1.9.0-14.mga8 php-pear-PHP_Invoker-1.1.3-7.mga8 php-pear-PHP_Timer-1.0.5-7.mga8 php-pear-PHP_TokenStream-1.2.2-6.mga8 php-pear-PHPUnit-3.7.34-5.mga8 php-pear-PHPUnit_MockObject-1.2.3-7.mga8 php-pear-PHPUnit_Selenium-1.3.3-7.mga8 php-pear-PHPUnit_Story-1.0.2-7.mga8 php-pear-Services_W3C_CSSValidator-0.2.3-8.mga8 php-pear-Symfony2_Yaml-2.4.4-6.mga8 php-pear-Text_Diff-1.2.2-3.mga8 php-pear-Text_Template-1.2.0-6.mga8 php-pear-XML_Parser-1.3.7-3.mga8 php-pear-XML_Serializer-0.21.0-3.mga8 The upgrade completed without any scriptlet errors, so closing as worksforme. I escalated the priority as I misremembered the impact of scriptlet errors. I was thinking it would cause the transaction it was part of to fail, possibly leading to a cascade error.
Resolution: (none) => WORKSFORMEStatus: NEW => RESOLVED