Hello. php-sqlite3 obsoletes php-sqlite which is wrong since they can coexist. Additionally if I'm not mistaking roundcubemail due to its deps does not work with sqlite3. Proposed fix: --- php.spec 2012-10-24 17:09:23.000000000 +0200 +++ php.spec.oden 2012-11-20 14:56:49.548228079 +0100 @@ -1064,8 +1064,6 @@ Summary: SQLite database bindings for PHP Group: Development/PHP Requires: php-pdo >= %{epoch}:%{version} -Obsoletes: php-sqlite -Provides: php-sqlite = %{epoch}:%{version} Requires: %{libname} >= %{epoch}:%{version} %description sqlite3 (it was actually me who added this in the past to get rid of sqlite2 deps)
Keywords: (none) => PATCHAssignee: bugsquad => oliver.bgr
fixed in r319991 + r319992
as oliver seems not very active since some weeks, and if this is something to updates in mga2 maybe you can do it yourself.
5.3.19RC1 is out, so I propose we wait until 5.3.19 is released.
My research about this is that there may be work done to replace the sqlite2 support in roundcubemail with something else. But I can't find where this resides. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657092 http://trac.roundcube.net/ticket/1488332 Latest roundcubemail-0.8.4 still requires sqlite2 for the sqlite backend.
Oden, I see you're preparing a PHP update for Mageia 2. Make sure you also rebuild php-eaccelerator to go along with that.
CC: (none) => luigiwalser
Oh, also you should do the php-timezonedb update in Cauldron as well (ideally it should be built first there).
ok. i thought i updated php-timezonedb in cauldron, guess not.
done
Nice, thanks. I assume you'll be using this bug to push to QA. We just need an advisory. Source RPMs: php-5.3.19-1.mga2.src.rpm php-gd-bundled-5.3.19-1.mga2.src.rpm php-timezonedb-2012.10-1.mga2.src.rpm php-firebird-5.3.19-1.mga2.src.rpm php-pdo_firebird-5.3.19-1.mga2.src.rpm php-eaccelerator-0.9.6.1-10.5.mga2.src.rpm
Proposed advisory: This is a maintenance and bugfix release that upgrades php to the latest 5.3.19 version which resolves numerous upstream bugs in php. It was discovered that the php-sqlite3 package replaced the php-sqlite package which would break roundcubemail installations using the sqlite(v) backend (#8164). Additionally the php-timezonedb package has been upgraded to the latest version. The php-gd-bundled, php-firebird, php-pdo_firebird and php-eaccelerator packages has been rebuilt for the new php version. References: http://www.php.net/ChangeLog-5.php#5.3.19 https://bugs.mageia.org/show_bug.cgi?id=8164
Proposed advisory: This is a maintenance and bugfix release that upgrades php to the latest 5.3.19 version which resolves numerous upstream bugs in php. It was discovered that the php-sqlite3 package replaced the php-sqlite package which would break roundcubemail installations using the sqlite(v2) backend (#8164). Additionally the php-timezonedb package has been upgraded to the latest version. The php-gd-bundled, php-firebird, php-pdo_firebird and php-eaccelerator packages has been rebuilt for the new php version. References: http://www.php.net/ChangeLog-5.php#5.3.19 https://bugs.mageia.org/show_bug.cgi?id=8164
Thanks Oden. Assigning to QA. Advisory in Comment 11, Source RPMs in Comment 9.
Keywords: PATCH => (none)CC: (none) => oliver.bgrAssignee: oliver.bgr => qa-bugs
Testing with my usual testcases from https://bugs.mageia.org/show_bug.cgi?id=3895#c35 on i586. Looks good.
Whiteboard: (none) => MGA2-32-OK
I've confirmed php-sqlite and php-sqlite3 can both be installed now. Also testing with dokuwiki, phpmyadmin. Testing complete on Mageia 2 i586 and x86-64. Could someone from the sysadmin team push the srpms php-5.3.19-1.mga2.src.rpm php-gd-bundled-5.3.19-1.mga2.src.rpm php-timezonedb-2012.10-1.mga2.src.rpm php-firebird-5.3.19-1.mga2.src.rpm php-pdo_firebird-5.3.19-1.mga2.src.rpm php-eaccelerator-0.9.6.1-10.5.mga2.src.rpm from Mageia 2 Core Updates Testing to Core Updates. Advisory: This is a maintenance and bugfix release that upgrades php to the latest 5.3.19 version which resolves numerous upstream bugs in php. It was discovered that the php-sqlite3 package replaced the php-sqlite package which would break roundcubemail installations using the sqlite(v2) backend (#8164). Additionally the php-timezonedb package has been upgraded to the latest version. The php-gd-bundled, php-firebird, php-pdo_firebird and php-eaccelerator packages has been rebuilt for the new php version. References: http://www.php.net/ChangeLog-5.php#5.3.19 https://bugs.mageia.org/show_bug.cgi?id=8164 https://bugs.mageia.org/show_bug.cgi?id=8164
Keywords: (none) => validated_updateCC: (none) => davidwhodgins, sysadmin-bugsWhiteboard: MGA2-32-OK => MGA2-32-OK MGA2-64-OK
Update pushed: https://wiki.mageia.org/en/Support/Advisories/MGAA-2012-0240
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
This looks to be affected by bug 2317 The following packages have to be removed for others to be upgraded: task-lamp-1-4.mga2.noarch (due to missing task-lamp-php) task-lamp-php-1-4.mga2.noarch (due to missing php-sqlite) I only checked this one rpm so there could be other links required. Mageia release 2 (Official) for x86_64 Latest version found in "Core Release" is apache-mod_php-5.3.13-1.mga2 Latest version found in "Core Updates Testing" is apache-mod_php-5.3.19-1.mga2 ---------------------------------------- The following packages will require linking: lib64apr-util1_0-1.4.1-4.mga2 (Core Release) ----------------------------------------
Status: RESOLVED => REOPENEDDepends on: (none) => 2317Resolution: FIXED => (none)
It's still showing as being in updates_testing as I haven't updated that media since the push. Just to clarify though.. $ ./depcheck apache-mod_php "Core Release" "Core Updates" ---------------------------------------- Running checks for "apache-mod_php" using media "Core Release" and "Core Updates". ---------------------------------------- Mageia release 2 (Official) for x86_64 Latest version found in "Core Release" is apache-mod_php-5.3.13-1.mga2 Latest version found in "Core Updates" is apache-mod_php-5.3.19-1.mga2 ---------------------------------------- The following packages will require linking: lib64apr-util1_0-1.4.1-4.mga2 (Core Release) ----------------------------------------
Requirements have not changed, so 2317 should not be in play. Dave said on IRC that the media need to be in the other order for depcheck.
(In reply to comment #17) > It's still showing as being in updates_testing as I haven't updated that media > since the push. Just to clarify though.. > > $ ./depcheck apache-mod_php "Core Release" "Core Updates" > ---------------------------------------- > Running checks for "apache-mod_php" using media > "Core Release" and "Core Updates". > ---------------------------------------- > Mageia release 2 (Official) for x86_64 > Latest version found in "Core Release" is apache-mod_php-5.3.13-1.mga2 > Latest version found in "Core Updates" is apache-mod_php-5.3.19-1.mga2 > ---------------------------------------- > The following packages will require linking: > > lib64apr-util1_0-1.4.1-4.mga2 (Core Release) > ---------------------------------------- The script should normally be run as depcheck apache-mod_php "Core Updates Testing (distrib5)" "Core Updates (distrib3)" with the (distrib#) being required or not, depending on how repositories were added. That is, the repository with the new version first, and either updates, or release (if never updated before), second. Can't run the script (as is), to compare one version in updates with another version in updates. I forgot to run the script before it was pushed, so it's too late to use it now, to confirm no dependency changes.
No, it's run from release to updates or updates_testing Anybody installing from release and updating now will take that path.
Bug 2317 also affects updates made during installation btw. I've run depcheck over the list of rpm's (from the MGAA wiki page) lib(64)apr-util1_0 appears to be the only link required for bug 2317 Sysadmin could you please link lib(64)apr-util1_0 to Core Updates. Now for the bad news.. I already have lib64apr-util1_0 installed so there is more to this than bug 2317. Oden/David could you take another look please, there is a conflict here. The following packages have to be removed for others to be upgraded: task-lamp-1-4.mga2.noarch (due to missing task-lamp-php) task-lamp-php-1-4.mga2.noarch (due to missing php-sqlite) Thanks.
Seems to be a perl-URPM bug here too. installed task-lamp-php-1-4.mga2.noarch is conflicting because of unsatisfied php-sqlite Argument "48688|24100" isn't numeric in array element at /usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi/URPM/Resolve.pm line 1378. promoting php-sqlite-5.3.19-1.mga2.i586 because of conflict above chosen php-sqlite-5.3.19-1.mga2.x86_64 for php-sqlite|php-sqlite selecting php-sqlite-5.3.19-1.mga2.x86_64 requiring libsqlite.so.0()(64bit) for php-sqlite-5.3.19-1.mga2.x86_64 chosen lib64sqlite0-2.8.17-16.mga2.x86_64 for libsqlite.so.0()(64bit) selecting lib64sqlite0-2.8.17-16.mga2.x86_64 To satisfy dependencies, the following packages are going to be installed: (test only, installation will not be actually done) Package Version Release Arch (medium "Core Release") lib64sqlite0 2.8.17 16.mga2 x86_64 This could be bug 2317 after all. As php-sqlite is a new package which does not exist in release being introduced in updates, it will need any recursive requires and recursive requires of any suggests from release media, minus any installed by default in a minimal installation or linked already linking into updates. Luckily that seems to be only lib(64)sqlite0 $ ./depcheck php-sqlite "Core Updates" Check with php-sqlite and "Core Updates" Latest version found in "Core Updates" is php-sqlite-5.3.19-1.mga2 ---------------------------------------- lib64sqlite0 --------------------- Confirmed that once it is installed, the update proceeds as expected. So two links are required for bug 2317. lib(64)sqlite0 lib(64)apr-util1_0 Could sysadmin please make these asap as the update is currently broken. Thanks!
bug 8371 created for perl-URPM
php-sqlite did exist but was obsoleted by php-sqlite3. To clearify this, php-sqlite was indeed built but the build system removed the built binary package(s) because php-sqlite3 obsoleted php-sqlite. So, in a sense php-sqlite is a "new" package.
Additionally I recall we had this problem in Mandriva but it was fixed some time ago. I'm referring to the problem when something in core updates requires something in core release and that dependency didn't exist before, and urpmi/rpmdrake (or whatever software it is) can't handle it. I'm not sure exactly what fixed it, sorry. You would have to look at the Mandriva updates and in the Mandriva bugzilla to find the fix I guess.
Sysadmin, please make the links from comment 22. Thanks.
packages linked
Status: REOPENED => RESOLVEDResolution: (none) => FIXED