Ensure sqlite3-tools lib(64)sqlite3_0 lib(64)sqlite3-devel are installed priori to installing these packages from Testing so they are not installed from Testing with the nss updates.

Testing complete mga3 32

Details are still embargoed. Just testing firefox, chromium, iceape with https, flash over https & Thunderbird ssl connection to gmail.

$ urpmq --whatrequires libnss3

Whiteboard: MGA3TOO => MGA3TOO has_procedure mga3-32-ok

Testing complete mga3 64

Whiteboard: MGA3TOO has_procedure mga3-32-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok

(In reply to claire robinson from comment #1)
> Ensure sqlite3-tools lib(64)sqlite3_0 lib(64)sqlite3-devel are installed
> priori to installing these packages from Testing so they are not installed
> from Testing with the nss updates.

Wait, what?  Do the new nss builds require the sqlite3 in testing?  If so I'll have to redo them.

I'm testing that now. I installed them accidentally on mga4 64 and it's difficult to downgrade but mga3 is fine with existing sqlite. Checking mga4 32 next.

(In reply to David Walser from comment #4)
> (In reply to claire robinson from comment #1)
> > Ensure sqlite3-tools lib(64)sqlite3_0 lib(64)sqlite3-devel are installed
> > priori to installing these packages from Testing so they are not installed
> > from Testing with the nss updates.
> 
> Wait, what?  Do the new nss builds require the sqlite3 in testing?  If so
> I'll have to redo them.


It's probably just urpmi/rpmdrake selecting the latest available versions to satisfy deps...

CC: (none) => tmb

Seems it does on mga4

# rpm -qa | grep sqlite3
sqlite3-tools-3.8.0.2-2.mga4
libsqlite3_0-3.8.0.2-2.mga4
libsqlite3-devel-3.8.0.2-2.mga4

# ecupdt
Enabling Core Updates Testing

# urpmi nss nss-doc libnss3
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Updates Testing")
  libnss3                        3.17.1       1.mga4        i586    
  libsqlite3-devel               3.8.4.2      1.mga4        i586    
  libsqlite3_0                   3.8.4.2      1.mga4        i586    
  nss                            3.17.1       1.mga4        i586    
  nss-doc                        3.17.1       1.mga4        noarch  
  sqlite3-tools                  3.8.4.2      1.mga4        i586    
41KB of additional disk space will be used.
2.9MB of packages will be retrieved.
Proceed with the installation of the 6 packages? (Y/n) n

In nss.spec:

[...]
%define sqlite3_version %(pkg-config --modversion sqlite3 &>/dev/null && pkg-config --modversion sqlite3 2>/dev/null || echo 0)
[...]

%package -n %{libname}
[...]
Requires: %{mklibname sqlite3_ 0} >= %{sqlite3_version}
[...]

Due to: https://qa.mandriva.com/show_bug.cgi?id=58754

And the end result is:

$ rpm -qp --requires /mnt/BIG/mirror/mageia/mga3/x86_64/media/core/updates_testing/lib64nss* | grep sqlite
lib64sqlite3_0 >= 3.7.17

Due to lib64nss3-3.17.0-1.mga3

CC: (none) => oe

Oh, the problem was for mg4. Then you have to nuke sqlite3 3.8.4.2 from updates testing and resubmit nss, or push the new sqlite3 version.

Yes, we've had this problem in the past when sqlite3 was in updates_testing and things built against it.

Thomas, can you remove sqlite3 and nss from Mageia 4 updates_testing?

As said by tmb in comment 6, I understand this as a simple consequence of urpmi choosing the most up to date version of sqlite to satisfy the dependency. If you install sqlite from Core Release or Core Updates beforehand, you shouldn't have any issue when doing:
urpmi libnss3 nss nss-doc --searchmedia "testing"

with the testing repos disabled.

CC: (none) => remi

See comment 7 Rémi :)

But I think it wouldn't happen if the testing repos were disabled and you used:
urpmi libnss3 nss nss-doc --searchmedia "testing"

I'm not 100% sure though, maybe it also uses the testing repo to resolve the dependencies in such a case. It works in other cases, but here according to comment 8 the version requirement is a bit aggressive.

The package requires the sqlite3 version it's built against.  Whether there's a valid technical reason for that or not, I'm not sure.

Yes, look at comment 8.

(In reply to David Walser from comment #10)
> Yes, we've had this problem in the past when sqlite3 was in updates_testing
> and things built against it.
> 
> Thomas, can you remove sqlite3 and nss from Mageia 4 updates_testing?


Done.

And I see doktor5000 just pushed sqlite3 again to updates_testing :/

Maybe the proper solution would be to fix the Requires in libnss3?

Or use buildconflicts to force the older sqlite3 version

(In reply to Thomas Backlund from comment #20)
> Or use buildconflicts to force the older sqlite3 version

Yeah that could do, but if nss works with older versions of sqlite3, why use such a versioning that forces it to use a version newer than the one it was built against?

Testing complete mga4 32 and mga4 64 with new nss build

Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok

Validating. Advisory uploaded.

Could sysadmin please push to 3 & 4 updates

Thanks

Keywords: (none) => validated_update
Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok
CC: (none) => sysadmin-bugs

I just tried to install it from mirrors.kernel.org and got this:
error: Failed dependencies:
        libsqlite3_0 >= 3.8.4.2 is needed by libnss3-2:3.17.1-1.mga4.i586

I see sqlite3's RPMs are still in updates_testing.

Thomas or someone, can you remove sqlite3 and nss and its associated RPMs again from Mageia 4 updates_testing?

Keywords: validated_update => (none)
Whiteboard: MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok

OK,

sqlite3 nuked again.

mga4 nss is rebuilt, and I bumped subrel to make it easier for those that already installed 3.17.1-1 for testing
(and cauldron rel is bumped to keep upgrade path)

so new mga4 rpms:

SRPM:
nss-3.17.1-1.1.mga4.src.rpm

i586:
libnss3-3.17.1-1.1.mga4.i586.rpm
libnss-devel-3.17.1-1.1.mga4.i586.rpm
libnss-static-devel-3.17.1-1.1.mga4.i586.rpm
nss-3.17.1-1.1.mga4.i586.rpm
nss-doc-3.17.1-1.1.mga4.noarch.rpm

x86_64:
lib64nss3-3.17.1-1.1.mga4.x86_64.rpm
lib64nss-devel-3.17.1-1.1.mga4.x86_64.rpm
lib64nss-static-devel-3.17.1-1.1.mga4.x86_64.rpm
nss-3.17.1-1.1.mga4.x86_64.rpm
nss-doc-3.17.1-1.1.mga4.noarch.rpm

CC'ing Florian, so that he knows why his sqlite3 update gets nuked :-)

CC: (none) => doktor5000

(In reply to David Walser from comment #24)
> I just tried to install it from mirrors.kernel.org and got this:
> error: Failed dependencies:
>         libsqlite3_0 >= 3.8.4.2 is needed by libnss3-2:3.17.1-1.mga4.i586
> 

I didn't get that here, that's strange. I'll check the new new ones too but you'd better do the same, to double check.

Testing complete mga4 32

# rpm -qa | grep sqlite3
sqlite3-tools-3.8.0.2-2.mga4
libsqlite3_0-3.8.0.2-2.mga4
libsqlite3-devel-3.8.0.2-2.mga4

# ecupdt
Enabling Core Updates Testing

# urpmi nss nss-doc libnss3
...               
installing nss-doc-3.17.1-1.1.mga4.noarch.rpm libnss3-3.17.1-1.1.mga4.i586.rpm nss-3.17.1-1.1.mga4.i586.rpm from /var/cache/urpmi/rpms
Preparing...                     ##########
      1/3: nss                   ##########
      2/3: libnss3               ##########
      3/3: nss-doc               ##########
      1/3: removing nss-2:3.17.1-1.mga4.i586
                                 ##########
      2/3: removing libnss3-2:3.17.1-1.mga4.i586
                                 ##########
      3/3: removing nss-doc-2:3.17.1-1.mga4.noarch
                                 ##########

Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok

Testing complete mga4 64

# rpm -qa | grep sqlite3
libsqlite3_0-3.8.0.2-2.mga4
lib64sqlite3_0-3.8.0.2-2.mga4
lib64sqlite3-devel-3.8.0.2-2.mga4
php-sqlite3-5.5.16-1.mga4
sqlite3-tools-3.8.0.2-2.mga4
ruby-sqlite3-1.3.8-4.mga4

# urpmi nss nss-doc lib64nss3
         
installing lib64nss3-3.17.1-1.1.mga4.x86_64.rpm nss-doc-3.17.1-1.1.mga4.noarch.rpm nss-3.17.1-1.1.mga4.x86_64.rpm from /var/cache/urpmi/rpms
Preparing...                     ##########
      1/3: nss                   ##########
      2/3: lib64nss3             ##########
      3/3: nss-doc               ##########
      1/3: removing nss-2:3.17.1-1.mga4.x86_64
                                 ##########
      2/3: removing lib64nss3-2:3.17.1-1.mga4.x86_64
                                 ##########
      3/3: removing nss-doc-2:3.17.1-1.mga4.noarch
                                 ##########

Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok => MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok

Advisory updated..

Index: 14168.adv
===================================================================
--- 14168.adv   (revision 1973)
+++ 14168.adv   (working copy)
@@ -8,7 +8,7 @@
      - nss-3.17.1-1.mga3
   4:
    core:
-     - nss-3.17.1-1.mga4
+     - nss-3.17.1-1.1.mga4
 description: |
   Updated nss packages fix security vulnerability:

Whiteboard: MGA3TOO has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok => MGA3TOO has_procedure advisory mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok

I'd have preferred we didn't use a subrel.

It looks like something has gone wrong in the mirroring process as well, as mirrors.kernel.org still has the ones I installed last night.

mageia.c3sl.ufpr.br has the new ones and they install fine.

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2014-0391.html

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