Another unannounced soname bump: libseccomp

[Richard W.M. Jones]

DEBUG util.py:264:  Error: Package: 2:qemu-system-mips-1.3.0-5.fc19.x86_64 (build)
DEBUG util.py:264:             Requires: libseccomp.so.1()(64bit)
DEBUG util.py:264:  Error: Package: 2:qemu-system-or32-1.3.0-5.fc19.x86_64 (build)
DEBUG util.py:264:             Requires: libseccomp.so.1()(64bit)
DEBUG util.py:264:  Error: Package: 2:qemu-system-microblaze-1.3.0-5.fc19.x86_64 (build)
DEBUG util.py:264:             Requires: libseccomp.so.1()(64bit)
[etc]
full log: http://kojipkgs.fedoraproject.org//work/tasks/9474/4909474/root.log

This seems to have been caused by this build:

  http://koji.fedoraproject.org/koji/buildinfo?buildID=380981

Affected packages:

- libcacard-tools
- qemu

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Richard W.M. Jones]

On Mon, Jan 28, 2013 at 07:44:19PM +0000, Richard W.M. Jones wrote:
>  Affected packages:
>  
>  - libcacard
>  - qemu 
I have kicked off rebuilds for these two.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

[Richard W.M. Jones]

On Mon, Jan 28, 2013 at 07:47:26PM +0000, Richard W.M. Jones wrote:
>  On Mon, Jan 28, 2013 at 07:44:19PM +0000, Richard W.M. Jones wrote:
>  > Affected packages:
>  > 
>  > - libcacard
>  > - qemu
>  
>  I have kicked off rebuilds for these two. 
.. although it is a bit odd that we have a separate 'libcacard'
package, when at the same time the 'qemu' package builds 'libcacard-*'
RPMs.

https://admin.fedoraproject.org/pkgdb/acls/name/libcacard
http://koji.fedoraproject.org/koji/buildinfo?buildID=381007
http://koji.fedoraproject.org/koji/buildinfo?buildID=380082

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Michael Schwendt]

On Mon, 28 Jan 2013 20:20:03 +0000, Richard W.M. Jones wrote:

>  On Mon, Jan 28, 2013 at 07:47:26PM +0000, Richard W.M. Jones wrote:
>  > On Mon, Jan 28, 2013 at 07:44:19PM +0000, Richard W.M. Jones wrote:
>  > > Affected packages:
>  > > 
>  > > - libcacard
>  > > - qemu
>  > 
>  > I have kicked off rebuilds for these two.
>  
>  .. although it is a bit odd that we have a separate 'libcacard'
>  package, when at the same time the 'qemu' package builds 'libcacard-*'
>  RPMs.
>  
>  https://admin.fedoraproject.org/pkgdb/acls/name/libcacard
>  http://koji.fedoraproject.org/koji/buildinfo?buildID=381007
>  http://koji.fedoraproject.org/koji/buildinfo?buildID=380082 
Interesting. qemu's libcacard is at Epoch 2, so the other one won't
ever be installed anymore.

Review request: https://bugzilla.redhat.com/661810

2010-12-30 Fedora 14. qemu didn't build the lib at that time.

$ repoquery --whatrequires libcacard
libcacard-devel-0:0.1.2-3.fc18.i686
libcacard-devel-0:0.1.2-3.fc18.x86_64
libcacard-devel-2:1.3.0-5.fc19.i686
libcacard-devel-2:1.3.0-5.fc19.x86_64
libcacard-tools-0:0.1.2-3.fc18.x86_64
libcacard-tools-2:1.3.0-5.fc19.x86_64
spice-client-0:0.12.2-2.fc19.x86_64
spice-glib-0:0.16-1.fc19.i686
spice-glib-0:0.16-1.fc19.x86_64
spice-gtk-0:0.16-1.fc19.i686
spice-gtk-0:0.16-1.fc19.x86_64
spice-gtk-python-0:0.16-1.fc19.x86_64
spice-gtk-tools-0:0.16-1.fc19.x86_64
spice-gtk3-0:0.16-1.fc19.i686
spice-gtk3-0:0.16-1.fc19.x86_64

-- 
Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc4.git4.1.fc19.x86_64
loadavg: 0.50 0.18 0.13

libcacard can never be installed (was: Re: Another unannounced soname bump: libseccomp)

[Richard W.M. Jones]

I have a filed a bug about this:

https://bugzilla.redhat.com/show_bug.cgi?id=905345
"libcacard can never be installed"

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

libcacard can never be installed (was: Re: Another unannounced soname bump: libseccomp)

[Peter Robinson]

On Tue, Jan 29, 2013 at 8:52 AM, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  I have a filed a bug about this:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=905345
>  "libcacard can never be installed" 
Is there a reason that qemu ships a bundled version of libcacard?
What's the difference between the two of them? Can qemu use the
unbundled version or are they essentially two completely different
libraries with the same name?

Peter

libcacard can never be installed (was: Re: Another unannounced soname bump: libseccomp)

[Richard W.M. Jones]

On Tue, Jan 29, 2013 at 08:57:11AM +0000, Peter Robinson wrote:
>  On Tue, Jan 29, 2013 at 8:52 AM, Richard W.M. Jones
> <rjones(a)redhat.com&gt; wrote:
>  > I have a filed a bug about this:
>  >
>  > https://bugzilla.redhat.com/show_bug.cgi?id=905345
>  > "libcacard can never be installed"
>  
>  Is there a reason that qemu ships a bundled version of libcacard?
>  What's the difference between the two of them? Can qemu use the
>  unbundled version or are they essentially two completely different
>  libraries with the same name? 
It looks as if the qemu source contains the one canonical copy of
libcacard.  The separate 'libcacard' package has the following sources
file:

$ cat sources 
189bc5b87281a72f8c72a0f7ebaa6d00  qemu-1.2.1.tar.bz2

So probably the 'libcacard' package should be removed.  I'm not
exactly sure why it exists in the first place.  Perhaps the library
was originally separate?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

libcacard can never be installed (was: Re: Another unannounced soname bump: libseccomp)

[Michael Schwendt]

On Tue, 29 Jan 2013 09:03:42 +0000, Richard W.M. Jones wrote:

>  It looks as if the qemu source contains the one canonical copy of
>  libcacard.  The separate 'libcacard' package has the following sources
>  file:
>  
>  $ cat sources 
>  189bc5b87281a72f8c72a0f7ebaa6d00  qemu-1.2.1.tar.bz2
>  
>  So probably the 'libcacard' package should be removed.  I'm not
>  exactly sure why it exists in the first place.  Perhaps the library
>  was originally separate? 
It seems so. Years ago:

  $ rpmls -p libcacard-0.1.2-1.fc15.src.rpm
  -rw-rw-r--  libcacard-0.1.2.tar.bz2
  -rw-r--r--  libcacard.spec

libcacard can never be installed

[Paolo Bonzini]

Il 29/01/2013 10:03, Richard W.M. Jones ha scritto:
>  On Tue, Jan 29, 2013 at 08:57:11AM +0000, Peter Robinson wrote:
> > On Tue, Jan 29, 2013 at 8:52 AM, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
> >> I have a filed a bug about this:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=905345
> >> "libcacard can never be installed"
> >
> > Is there a reason that qemu ships a bundled version of libcacard?
> > What's the difference between the two of them? Can qemu use the
> > unbundled version or are they essentially two completely different
> > libraries with the same name?
>  
>  It looks as if the qemu source contains the one canonical copy of
>  libcacard.  The separate 'libcacard' package has the following sources
>  file:
>  
>  $ cat sources 
>  189bc5b87281a72f8c72a0f7ebaa6d00  qemu-1.2.1.tar.bz2 
Yes, I noticed this a month ago and suggested that Alon would merge the
packages and orphan libcacard.  He forgot to do the second step
apparently. :)

Paolo

[Michael Cronenworth]

Richard W.M. Jones wrote:
>  DEBUG util.py:264:  Error: Package:
> 2:qemu-system-mips-1.3.0-5.fc19.x86_64 (build)
>  DEBUG util.py:264:             Requires: libseccomp.so.1()(64bit)
>  DEBUG util.py:264:  Error: Package: 2:qemu-system-or32-1.3.0-5.fc19.x86_64 (build)
>  DEBUG util.py:264:             Requires: libseccomp.so.1()(64bit)
>  DEBUG util.py:264:  Error: Package: 2:qemu-system-microblaze-1.3.0-5.fc19.x86_64 (build)
>  DEBUG util.py:264:             Requires: libseccomp.so.1()(64bit)
>  [etc]
>  full log: http://kojipkgs.fedoraproject.org//work/tasks/9474/4909474/root.log
>
>  This seems to have been caused by this build:
>
>    http://koji.fedoraproject.org/koji/buildinfo?buildID=380981
>
>  Affected packages:
>
>  - libcacard-tools
>  - qemu
>
>  Rich. 
You might have wanted to CC the package owner as he may not be signed up
for the devel list let alone aware of the soname bump policy.

http://fedoraproject.org/wiki/Updates_Policy

[Adam Williamson]

On Mon, 2013-01-28 at 19:44 +0000, Richard W.M. Jones wrote:
>  DEBUG util.py:264:  Error: Package:
> 2:qemu-system-mips-1.3.0-5.fc19.x86_64 (build)
>  DEBUG util.py:264:             Requires: libseccomp.so.1()(64bit)
>  DEBUG util.py:264:  Error: Package: 2:qemu-system-or32-1.3.0-5.fc19.x86_64 (build)
>  DEBUG util.py:264:             Requires: libseccomp.so.1()(64bit)
>  DEBUG util.py:264:  Error: Package: 2:qemu-system-microblaze-1.3.0-5.fc19.x86_64 (build)
>  DEBUG util.py:264:             Requires: libseccomp.so.1()(64bit)
>  [etc]
>  full log: http://kojipkgs.fedoraproject.org//work/tasks/9474/4909474/root.log
>  
>  This seems to have been caused by this build:
>  
>    http://koji.fedoraproject.org/koji/buildinfo?buildID=380981
>  
>  Affected packages:
>  
>  - libcacard-tools
>  - qemu 
So, just as a path for anyone who's interested to take a look down, I
think we could potentially Do Something about all these unannounced
soname bumps. We do have a test in autoqa that catches them, and doesn't
seem to have a huge amount of 'false positives'. The test case is
rpmguard, and here is it noticing this soname bump:

http://autoqa.fedoraproject.org/resultsdb/frontend/testrun?id_=956918
http://autoqa.fedoraproject.org/results/511987-autotest/virt02.qa/rpmguar...

N: Comparing libseccomp-1.0.1-0.fc19 and libseccomp-2.0.0-0.fc19 (archs:
i686) ...
W: provision-added libseccomp.so.2  
W: provision-removed libseccomp.so.1  

N: Comparing libseccomp-1.0.1-0.fc19 and libseccomp-2.0.0-0.fc19 (archs: x86_64) ...
W: provision-added libseccomp.so.2()(64bit)  
W: provision-removed libseccomp.so.1()(64bit)  

now rpmguard does various other things, so we'd need to filter out the
provision-removed (especially) results for this case. But we do at least
have this information being captured by autoqa, I think.

That's all I got!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Adam Williamson]

On Mon, 2013-01-28 at 17:24 -0800, Adam Williamson wrote:

>  now rpmguard does various other things, so we'd need to filter
> out the
>  provision-removed (especially) results for this case. But we do at least
>  have this information being captured by autoqa, I think. 
Erm, by 'filter out' (terrible choice of words) what I really meant is
that, to catch unannounced dependency bumps but not anything else, we
should look *only* at 'provision-removed' and 'provision-added' results,
and ignore everything else. You could further process the results and
look only for results with .so.[0-9] in them, I suppose.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Andrey Ponomarenko]

Adam Williamson wrote:
>  On Mon, 2013-01-28 at 19:44 +0000, Richard W.M. Jones wrote:
> > DEBUG util.py:264:  Error: Package: 2:qemu-system-mips-1.3.0-5.fc19.x86_64 (build)
> > DEBUG util.py:264:             Requires: libseccomp.so.1()(64bit)
> > DEBUG util.py:264:  Error: Package: 2:qemu-system-or32-1.3.0-5.fc19.x86_64 (build)
> > DEBUG util.py:264:             Requires: libseccomp.so.1()(64bit)
> > DEBUG util.py:264:  Error: Package: 2:qemu-system-microblaze-1.3.0-5.fc19.x86_64
> (build)
> > DEBUG util.py:264:             Requires: libseccomp.so.1()(64bit)
> > [etc]
> > full log: http://kojipkgs.fedoraproject.org//work/tasks/9474/4909474/root.log
> >
> > This seems to have been caused by this build:
> >
> >    http://koji.fedoraproject.org/koji/buildinfo?buildID=380981
> >
> > Affected packages:
> >
> > - libcacard-tools
> > - qemu
>  So, just as a path for anyone who's interested to take a look down, I
>  think we could potentially Do Something about all these unannounced
>  soname bumps. We do have a test in autoqa that catches them, and doesn't
>  seem to have a huge amount of 'false positives'. 
FYI

http://upstream-tracker.org/versions/libseccomp.html

>  The test case is
>  rpmguard, and here is it noticing this soname bump:
>
>  http://autoqa.fedoraproject.org/resultsdb/frontend/testrun?id_=956918
>
> http://autoqa.fedoraproject.org/results/511987-autotest/virt02.qa/rpmguar...
>
>  N: Comparing libseccomp-1.0.1-0.fc19 and libseccomp-2.0.0-0.fc19 (archs:
>  i686) ...
>  W: provision-added libseccomp.so.2
>  W: provision-removed libseccomp.so.1
>
>  N: Comparing libseccomp-1.0.1-0.fc19 and libseccomp-2.0.0-0.fc19 (archs: x86_64) ...
>  W: provision-added libseccomp.so.2()(64bit)
>  W: provision-removed libseccomp.so.1()(64bit)
>
>  now rpmguard does various other things, so we'd need to filter out the
>  provision-removed (especially) results for this case. But we do at least
>  have this information being captured by autoqa, I think.
>
>  That's all I got! 
-- 
Andrey Ponomarenko, ROSA Lab.

[Tom Callaway]

On 01/29/2013 02:24 AM, Adam Williamson wrote:
>  So, just as a path for anyone who's interested to take a look
> down, I
>  think we could potentially Do Something about all these unannounced
>  soname bumps. 
Really, what we should do is this:

* When a rawhide build results in new broken dependencies, we should
immediately (and automatically):
 - Increment the release on each of the deps, commit, and try a rebuild

Surely, there will be cases which will need maintainer intervention, but
I believe there is ample evidence that the majority of these cases just
need a rebuild. Fedmsg should make this possible to do.

I brought this up in the infrastructure room at FUDCon Lawrence, and
there seemed to be general consensus that this was not only possible,
but will be done, so I hope we will actually see this soon. :)

~tom

==
Fedora Project

[Kevin Fenzi]

On Sat, 02 Feb 2013 16:10:34 +0100
Tom Callaway <tcallawa(a)redhat.com&gt; wrote:

>  On 01/29/2013 02:24 AM, Adam Williamson wrote:
>  > So, just as a path for anyone who's interested to take a look down,
>  > I think we could potentially Do Something about all these
>  > unannounced soname bumps.
>  
>  Really, what we should do is this:
>  
>  * When a rawhide build results in new broken dependencies, we should
>  immediately (and automatically):
>   - Increment the release on each of the deps, commit, and try a
>  rebuild
>  
>  Surely, there will be cases which will need maintainer intervention,
>  but I believe there is ample evidence that the majority of these
>  cases just need a rebuild. Fedmsg should make this possible to do.
>  
>  I brought this up in the infrastructure room at FUDCon Lawrence, and
>  there seemed to be general consensus that this was not only possible,
>  but will be done, so I hope we will actually see this soon. :) 
Yep. I think we can get there, but just we aren't there yet. ;) 

We need to: 

- Add messages to the broken deps report. (should be trivial). 

- Setup a process to look for these and do the bump/rebuild. It would
  need some smarts to make sure that it didn't do this every single day
  when it fails, etc. Possibly it could check for it's changelog and if
  it was the last thing to try building it, bypass. 

- Ideally it would have some way to do a scratch build first and see if
  the deps were fixed, but checking broken deps is not at all easy, so
  that might be too much gravy. 

I think we can get there. ;) 

kevin

[Bruno Wolff III]

On Sat, Feb 02, 2013 at 13:47:44 -0700,
   Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
> - Setup a process to look for these and do the bump/rebuild. It would
>   need some smarts to make sure that it didn't do this every single day
>   when it fails, etc. Possibly it could check for it's changelog and if
>   it was the last thing to try building it, bypass. 
Arguably you wouldn't want to try new builds were the git repo had changed 
since the last successful build. And this would catch this case if 
after the first try, the rebuild rebuild failed.

[Kevin Fenzi]

On Sat, 2 Feb 2013 15:05:53 -0600
Bruno Wolff III <bruno(a)wolff.to&gt; wrote:

>  On Sat, Feb 02, 2013 at 13:47:44 -0700,
>     Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  >
>  >- Setup a process to look for these and do the bump/rebuild. It would
>  >  need some smarts to make sure that it didn't do this every single
>  > day when it fails, etc. Possibly it could check for it's changelog
>  > and if it was the last thing to try building it, bypass.
>  
>  Arguably you wouldn't want to try new builds were the git repo had
>  changed since the last successful build. And this would catch this
>  case if after the first try, the rebuild rebuild failed. 
Yep. Makes sense. ;) 

If someone wants to work on such a script, let me know. 

kevin

[Björn Persson]

Kevin Fenzi wrote:
>  We need to: 
>  
>  - Add messages to the broken deps report. (should be trivial). 
>  
>  - Setup a process to look for these and do the bump/rebuild. It would
>    need some smarts to make sure that it didn't do this every single day
>    when it fails, etc. Possibly it could check for it's changelog and if
>    it was the last thing to try building it, bypass.  
I note that that wouldn't cover the case where library A's soname
changes, library B depends on A, and program C depends on both A and B.
Rebuilding C would fail unless a rebuilt B has had time to get into the
buildroot, and the next day it wouldn't be retried.

>  - Ideally it would have some way to do a scratch build first and see
> if
>    the deps were fixed, but checking broken deps is not at all easy, so
>    that might be too much gravy.  
If it would do that, and retry the scratch build once a day, then it
would eventually work its way through dependency chains.

Björn Persson