Summary of broken packages (by owner):
alexl AT users.sourceforge.net blam
berrange AT redhat.com perl-Test-AutoBuild
debarshi.ray AT gmail.com anjuta
dhuff AT redhat.com appliance-tools
ebmunson AT us.ibm.com libhugetlbfs lsvpd
fedora AT deadbabylon.de kcoloredit kiconedit
gauret AT free.fr basket grisbi
katzj AT redhat.com livecd-tools
lxtnow AT gmail.com gspiceui
matthias AT rpmforge.net pigment-python
nigjones AT redhat.com mediawiki-SpecialInterwiki
oliver AT linux-kernel.at syck
orion AT cora.nwra.com paraview
phuang AT redhat.com scim-bridge
roozbeh AT farsiweb.info translate-toolkit
wart AT kobold.org cyphesis sear
====================================================================== Broken packages in fedora-9-i386:
cyphesis-selinux-0.5.15-6.fc9.i386 requires cyphesis = 0:0.5.15-6.fc9 grisbi-0.5.9-5.fc9.i386 requires tetex-unicode pigment-python-0.3.3-1.fc9.i386 requires libpigment-0.3.so.4 pigment-python-0.3.3-1.fc9.i386 requires libpigment-gtk-0.3.so.4 sear-0.6.3-10.fc9.i386 requires libmercator-0.2.so.4 syck-php-0.61-4.3.fc9.i386 requires php = 0:5.2.5
====================================================================== Broken packages in fedora-9-ppc:
cyphesis-selinux-0.5.15-6.fc9.ppc requires cyphesis = 0:0.5.15-6.fc9 grisbi-0.5.9-5.fc9.ppc requires tetex-unicode libhugetlbfs-test-1.1-6.fc9.ppc requires libhugetlbfs = 0:1.1-6.fc9 paraview-3.2.1-6.fc9.ppc64 requires paraview-data = 0:3.2.1-6.fc9 paraview-mpi-3.2.1-6.fc9.ppc64 requires paraview-data = 0:3.2.1-6.fc9 pigment-python-0.3.3-1.fc9.ppc requires libpigment-0.3.so.4 pigment-python-0.3.3-1.fc9.ppc requires libpigment-gtk-0.3.so.4 scim-bridge-qt-0.4.15-5.fc9.ppc64 requires scim-bridge = 0:0.4.15-5.fc9 sear-0.6.3-10.fc9.ppc requires libmercator-0.2.so.4 syck-php-0.61-4.3.fc9.ppc requires php = 0:5.2.5
====================================================================== Broken packages in fedora-9-ppc64:
cyphesis-selinux-0.5.15-6.fc9.ppc64 requires cyphesis = 0:0.5.15-6.fc9 grisbi-0.5.9-5.fc9.ppc64 requires tetex-unicode libhugetlbfs-test-1.1-6.fc9.ppc64 requires libhugetlbfs = 0:1.1-6.fc9 perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pigment-python-0.3.3-1.fc9.ppc64 requires libpigment-gtk-0.3.so.4()(64bit) pigment-python-0.3.3-1.fc9.ppc64 requires libpigment-0.3.so.4()(64bit) sear-0.6.3-10.fc9.ppc64 requires libmercator-0.2.so.4()(64bit) syck-php-0.61-4.3.fc9.ppc64 requires php = 0:5.2.5
====================================================================== Broken packages in fedora-9-x86_64:
cyphesis-selinux-0.5.15-6.fc9.x86_64 requires cyphesis = 0:0.5.15-6.fc9 grisbi-0.5.9-5.fc9.x86_64 requires tetex-unicode libhugetlbfs-test-1.1-6.fc9.x86_64 requires libhugetlbfs = 0:1.1-6.fc9 paraview-3.2.1-6.fc9.i386 requires paraview-data = 0:3.2.1-6.fc9 paraview-mpi-3.2.1-6.fc9.i386 requires paraview-data = 0:3.2.1-6.fc9 pigment-python-0.3.3-1.fc9.x86_64 requires libpigment-gtk-0.3.so.4()(64bit) pigment-python-0.3.3-1.fc9.x86_64 requires libpigment-0.3.so.4()(64bit) scim-bridge-qt-0.4.15-5.fc9.i386 requires scim-bridge = 0:0.4.15-5.fc9 sear-0.6.3-10.fc9.x86_64 requires libmercator-0.2.so.4()(64bit) syck-php-0.61-4.3.fc9.x86_64 requires php = 0:5.2.5
====================================================================== Broken packages in fedora-updates-9-i386:
basket-kontact-1.0.3.1-2.fc9.i386 requires kontact blam-1.8.5-2.fc9.i386 requires gecko-libs = 0:1.9.0.2 cyphesis-0.5.15-8.fc9.i386 requires libmercator-0.2.so.4 lsvpd-1.6.4-1.fc9.i386 requires libvpd_cxx-2.0.so.1 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch requires mediawiki < 0:1.11
====================================================================== Broken packages in fedora-updates-9-ppc:
basket-kontact-1.0.3.1-2.fc9.ppc requires kontact blam-1.8.5-2.fc9.ppc requires gecko-libs = 0:1.9.0.2 cyphesis-0.5.15-8.fc9.ppc requires libmercator-0.2.so.4 lsvpd-1.6.4-1.fc9.ppc requires libvpd_cxx-2.0.so.1 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch requires mediawiki < 0:1.11
====================================================================== Broken packages in fedora-updates-9-ppc64:
basket-kontact-1.0.3.1-2.fc9.ppc64 requires kontact cyphesis-0.5.15-8.fc9.ppc64 requires libmercator-0.2.so.4()(64bit) gspiceui-0.9.65-2.fc9.ppc64 requires gwave livecd-tools-017.1-1.fc9.ppc64 requires yaboot lsvpd-1.6.4-1.fc9.ppc64 requires libvpd_cxx-2.0.so.1()(64bit) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch requires mediawiki < 0:1.11
====================================================================== Broken packages in fedora-updates-9-x86_64:
basket-kontact-1.0.3.1-2.fc9.x86_64 requires kontact blam-1.8.5-2.fc9.x86_64 requires gecko-libs = 0:1.9.0.2 cyphesis-0.5.15-8.fc9.x86_64 requires libmercator-0.2.so.4()(64bit) lsvpd-1.6.4-1.fc9.x86_64 requires libvpd_cxx-2.0.so.1()(64bit) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc9.noarch requires mediawiki < 0:1.11
====================================================================== Broken packages in fedora-updates-testing-9-i386:
1:anjuta-2.4.2-2.fc9.i386 requires libglade2 >= 0:2.6.2-6 1:anjuta-devel-2.4.2-2.fc9.i386 requires libglade2-devel >= 0:2.6.2-6 kcoloredit-4.1.3-1.fc9.i386 requires kdelibs4 >= 0:4.1.3 kiconedit-4.1.3-1.fc9.i386 requires kdelibs4 >= 0:4.1.3
====================================================================== Broken packages in fedora-updates-testing-9-ppc:
1:anjuta-2.4.2-2.fc9.ppc requires libglade2 >= 0:2.6.2-6 1:anjuta-2.4.2-2.fc9.ppc64 requires libglade2 >= 0:2.6.2-6 1:anjuta-devel-2.4.2-2.fc9.ppc requires libglade2-devel >= 0:2.6.2-6 1:anjuta-devel-2.4.2-2.fc9.ppc64 requires libglade2-devel >= 0:2.6.2-6 kcoloredit-4.1.3-1.fc9.ppc requires kdelibs4 >= 0:4.1.3 kiconedit-4.1.3-1.fc9.ppc requires kdelibs4 >= 0:4.1.3 translate-toolkit-1.2.0-1.fc9.noarch requires python-psyco
====================================================================== Broken packages in fedora-updates-testing-9-ppc64:
1:anjuta-2.4.2-2.fc9.ppc64 requires libglade2 >= 0:2.6.2-6 1:anjuta-devel-2.4.2-2.fc9.ppc64 requires libglade2-devel >= 0:2.6.2-6 appliance-tools-002.6-1.fc9.noarch requires qemu-img kcoloredit-4.1.3-1.fc9.ppc64 requires kdelibs4 >= 0:4.1.3 kiconedit-4.1.3-1.fc9.ppc64 requires kdelibs4 >= 0:4.1.3 translate-toolkit-1.2.0-1.fc9.noarch requires python-psyco
====================================================================== Broken packages in fedora-updates-testing-9-x86_64:
1:anjuta-2.4.2-2.fc9.i386 requires libglade2 >= 0:2.6.2-6 1:anjuta-2.4.2-2.fc9.x86_64 requires libglade2 >= 0:2.6.2-6 1:anjuta-devel-2.4.2-2.fc9.i386 requires libglade2-devel >= 0:2.6.2-6 1:anjuta-devel-2.4.2-2.fc9.x86_64 requires libglade2-devel >= 0:2.6.2-6 kcoloredit-4.1.3-1.fc9.x86_64 requires kdelibs4 >= 0:4.1.3 kiconedit-4.1.3-1.fc9.x86_64 requires kdelibs4 >= 0:4.1.3 translate-toolkit-1.2.0-1.fc9.noarch requires python-psyco
Michael Schwendt wrote:
Broken packages in fedora-updates-testing-9-ppc64:
appliance-tools-002.6-1.fc9.noarch requires qemu-img
To address this I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch", to the spec [1] which matches the qemu package. I was told that this would prevent the compose tools form adding the appliance-tools rpm to the ppc64 tree.
-D
[1] http://cvs.fedoraproject.org/viewvc/rpms/appliance-tools/F-9/appliance-tools...
On Fri, 14 Nov 2008 14:45:57 -0500, David Huff wrote:
Michael Schwendt wrote:
Broken packages in fedora-updates-testing-9-ppc64:
appliance-tools-002.6-1.fc9.noarch requires qemu-imgTo address this I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch", to the spec [1] which matches the qemu package. I was told that this would prevent the compose tools form adding the appliance-tools rpm to the ppc64 tree.
Why not "ExcludeArch: ppc64"?
Michael Schwendt wrote:
On Fri, 14 Nov 2008 14:45:57 -0500, David Huff wrote:
Michael Schwendt wrote:
Broken packages in fedora-updates-testing-9-ppc64:
appliance-tools-002.6-1.fc9.noarch requires qemu-imgTo address this I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch", to the spec [1] which matches the qemu package. I was told that this would prevent the compose tools form adding the appliance-tools rpm to the ppc64 tree.
Why not "ExcludeArch: ppc64"?
b/c qemu is also not in s390 and s390x.
-D
On Fri, 14 Nov 2008 15:37:30 -0500, David Huff wrote:
Michael Schwendt wrote:
On Fri, 14 Nov 2008 14:45:57 -0500, David Huff wrote:
Michael Schwendt wrote:
Broken packages in fedora-updates-testing-9-ppc64:
appliance-tools-002.6-1.fc9.noarch requires qemu-imgTo address this I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch", to the spec [1] which matches the qemu package. I was told that this would prevent the compose tools form adding the appliance-tools rpm to the ppc64 tree.
Why not "ExcludeArch: ppc64"?
b/c qemu is also not in s390 and s390x.
"ExcludeArch: ppc64 s390 s390x" is still shorter than your ExclusiveArch list, ... but I see qemu also doesn't use ExcludeArch.
Michael Schwendt wrote:
On Fri, 14 Nov 2008 14:45:57 -0500, David Huff wrote:
Michael Schwendt wrote:
Broken packages in fedora-updates-testing-9-ppc64:
appliance-tools-002.6-1.fc9.noarch requires qemu-imgTo address this I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch", to the spec [1] which matches the qemu package. I was told that this would prevent the compose tools form adding the appliance-tools rpm to the ppc64 tree.
Why not "ExcludeArch: ppc64"?
Just to offer an outside perspective... IMO ExcludeArch makes sense when a package is generically expected to work, but is known to have problems on specific architectures (i.e. not working is the exception, not the rule). For things like qemu (or valgrind, to give another example) that are highly arch-specific, it makes more sense to list the arches that are supported, even if that results in a longer list.
IOW, use whichever is more likely to DTRT when built on a totally novel arch (e.g. arm, sparc, whatever) ;-).
Matthew Woehlke wrote:
Michael Schwendt wrote:
On Fri, 14 Nov 2008 14:45:57 -0500, David Huff wrote:
Michael Schwendt wrote:
Broken packages in fedora-updates-testing-9-ppc64:
appliance-tools-002.6-1.fc9.noarch requires qemu-imgTo address this I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch", to the spec [1] which matches the qemu package. I was told that this would prevent the compose tools form adding the appliance-tools rpm to the ppc64 tree.
Why not "ExcludeArch: ppc64"?
Just to offer an outside perspective... IMO ExcludeArch makes sense when a package is generically expected to work, but is known to have problems on specific architectures (i.e. not working is the exception, not the rule). For things like qemu (or valgrind, to give another example) that are highly arch-specific, it makes more sense to list the arches that are supported, even if that results in a longer list.
either way, it was my understanding that both ExclusinveArch and ExcludeArch would work, ie the compose tools will check the srpm and not include the package in a tree if specified in either of these feilds.
Im not sure if switching form ExclusinveArch to ExcludeArch will fix the issue at had.
Any comments, as I would like to run a new build to try and resolve this issue.
-D
On Fri, 2008-11-14 at 16:44 -0500, David Huff wrote:
either way, it was my understanding that both ExclusinveArch and ExcludeArch would work, ie the compose tools will check the srpm and not include the package in a tree if specified in either of these feilds.
That is correct.
Im not sure if switching form ExclusinveArch to ExcludeArch will fix the issue at had.
Any comments, as I would like to run a new build to try and resolve this issue.
Er, what exactly is the issue at hand?
Jesse Keating wrote:
Er, what exactly is the issue at hand?
I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch" to the spec file however it is still reporting broken dep of qemu for ppc64.
So either the rpm *is* being pulled in to the tree eventhough ExclusiveArch is set, or whatever is checking for broken deops is reporting incorrectly.
-D
I know this is an old thread however I just got two more notifications for two new RPMs:
Michael Schwendt wrote:
Your following packages in the repository suffer from broken
dependencies:
package: appliance-tools-003.9-1.fc10.noarch from fedora-updates-10-ppc64 unresolved deps: qemu-img
Your following packages in the repository suffer from broken
dependencies:
package: appliance-tools-002.8-1.fc9.noarch from
fedora-updates-testing-9-ppc64
unresolved deps: qemu-img
On Mon, 01 Dec 2008 10:57:39 -0500, David Huff wrote:
Jesse Keating wrote:
Er, what exactly is the issue at hand?
I added "ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch" to the spec file however it is still reporting broken dep of qemu for ppc64.
So either the rpm *is* being pulled in to the tree eventhough ExclusiveArch is set, or whatever is checking for broken deops is reporting incorrectly.
Explain how you think the broken deps checker would be broken! The package _is_ in the ppc64 tree, isn't it?
http://download.fedora.redhat.com/pub/fedora/linux/updates/10/ppc64/applianc...
Btw:
$ rpm -qp --qf '[%{exclusivearch} ]' appliance-tools-003.9-1.fc10.src.rpm i386 i486 i586 i686 pentium3 pentium4 athlon geode x86_64 ppc alpha sparc armv4l
I leave the 2nd part of the exercise to you. Find out whether "mash" evaluates %exclusivearch.
-D
I know this is an old thread however I just got two more notifications for two new RPMs:
Michael Schwendt wrote:
Your following packages in the repository suffer from broken
dependencies:
package: appliance-tools-003.9-1.fc10.noarch from fedora-updates-10-ppc64 unresolved deps: qemu-img
Your following packages in the repository suffer from broken
dependencies:
package: appliance-tools-002.8-1.fc9.noarch from
fedora-updates-testing-9-ppc64
unresolved deps: qemu-img
On Mon, 2008-12-01 at 17:37 +0100, Michael Schwendt wrote:
Explain how you think the broken deps checker would be broken! The package _is_ in the ppc64 tree, isn't it?
http://download.fedora.redhat.com/pub/fedora/linux/updates/10/ppc64/applianc...
Btw:
$ rpm -qp --qf '[%{exclusivearch} ]' appliance-tools-003.9-1.fc10.src.rpm i386 i486 i586 i686 pentium3 pentium4 athlon geode x86_64 ppc alpha sparc armv4l
Looking at the spec itself, I see:
ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch
I think that 'noarch' is throwing mash off when it's trying to determine if a noarch package is suitable for an arch. Please remove that and try again (trying it in rawhide should be suitable to test mash before pushing an update).
Jesse Keating wrote:
On Mon, 2008-12-01 at 17:37 +0100, Michael Schwendt wrote:
Explain how you think the broken deps checker would be broken! The package _is_ in the ppc64 tree, isn't it?
http://download.fedora.redhat.com/pub/fedora/linux/updates/10/ppc64/applianc...
Btw:
$ rpm -qp --qf '[%{exclusivearch} ]' appliance-tools-003.9-1.fc10.src.rpm i386 i486 i586 i686 pentium3 pentium4 athlon geode x86_64 ppc alpha sparc armv4l
Looking at the spec itself, I see:
ExclusiveArch: %{ix86} x86_64 ppc alpha sparc armv4l noarch
I think that 'noarch' is throwing mash off when it's trying to determine if a noarch package is suitable for an arch. Please remove that and try again (trying it in rawhide should be suitable to test mash before pushing an update).
If I take out noarch in the ExclusiveArch list the build will fail: "error: Architecture is not included: noarch"
more info: https://koji.fedoraproject.org/koji/taskinfo?taskID=968280
-D
On Mon, 2008-12-01 at 16:39 -0500, David Huff wrote:
If I take out noarch in the ExclusiveArch list the build will fail: "error: Architecture is not included: noarch"
more info: https://koji.fedoraproject.org/koji/taskinfo?taskID=968280
Hrm, I'm looking through everything that was successfully excluded in the last compose, everything seems to be using ExcludeArch instead of ExclusiveArch. It's possible our treatment of ExclusiveArch isn't correct, again because we have to add noarch to the list. What's the reasoning for your use of Exclusive vs ExcludeArch ?
Jesse Keating wrote:
Hrm, I'm looking through everything that was successfully excluded in the last compose, everything seems to be using ExcludeArch instead of ExclusiveArch. It's possible our treatment of ExclusiveArch isn't correct, again because we have to add noarch to the list. What's the reasoning for your use of Exclusive vs ExcludeArch ?
I used ExclusiveArch to match qemu, which is what it depends on, however qemu is an arch specific rpm.
Building with ExcludeArch does build. I'll throw it against rawhide and see if mash picks it up or not.
-D
On Fri, 14 Nov 2008 16:44:16 -0500, David Huff wrote:
either way, it was my understanding that both ExclusinveArch and ExcludeArch would work, ie the compose tools will check the srpm and not include the package in a tree if specified in either of these feilds.
That's somewhat unrelated. Checking the src.rpm is only necessary for noarch builds. For binary builds, the buildsys (= koji) evaluates these two fields already and requests the right arch-specific build-jobs. Then, with no ppc64 build done, the compose tools have nothing they can push to the ppc64 repo.
Im not sure if switching form ExclusinveArch to ExcludeArch will fix the issue at had.
Rule of thumb: prefer ExcludeArch (selectively excluding archs that are known to be broken/unsupported -- with the Fedora guideline to add a bugzilla ticket for each arch that's excluded). Second choice is ExclusiveArch for software where you can start with a list of what archs the software is made for, e.g. due to explicitly non-portable features.
Broken packages in fedora-updates-testing-9-i386:
1:anjuta-2.4.2-2.fc9.i386 requires libglade2 >= 0:2.6.2-6 1:anjuta-devel-2.4.2-2.fc9.i386 requires libglade2-devel >= 0:2.6.2-6
[...]
Broken packages in fedora-updates-testing-9-ppc:
1:anjuta-2.4.2-2.fc9.ppc requires libglade2 >= 0:2.6.2-6 1:anjuta-2.4.2-2.fc9.ppc64 requires libglade2 >= 0:2.6.2-6 1:anjuta-devel-2.4.2-2.fc9.ppc requires libglade2-devel >= 0:2.6.2-6 1:anjuta-devel-2.4.2-2.fc9.ppc64 requires libglade2-devel >= 0:2.6.2-6
[...]
Broken packages in fedora-updates-testing-9-ppc64:
1:anjuta-2.4.2-2.fc9.ppc64 requires libglade2 >= 0:2.6.2-6 1:anjuta-devel-2.4.2-2.fc9.ppc64 requires libglade2-devel >= 0:2.6.2-6
[...]
Broken packages in fedora-updates-testing-9-x86_64:
1:anjuta-2.4.2-2.fc9.i386 requires libglade2 >= 0:2.6.2-6 1:anjuta-2.4.2-2.fc9.x86_64 requires libglade2 >= 0:2.6.2-6 1:anjuta-devel-2.4.2-2.fc9.i386 requires libglade2-devel >= 0:2.6.2-6 1:anjuta-devel-2.4.2-2.fc9.x86_64 requires libglade2-devel >= 0:2.6.2-6
Now that the libglade2 update has been pushed in Bodhi, this is taken care of.
Cheerio, Debarshi
-
David Huff -
Debarshi Ray -
Jesse Keating -
Matthew Woehlke -
Michael Schwendt