[AutoQA] #328: depcheck: should not test packages from both x86_64 and iX86 unless needed

fedora-badges

Tuesday, 10 May Tue, 10 May

2:21 a.m.

#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Future tasks Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by kparal): IIUC the problem is that we place all downloaded packages into a single repo and then depcheck tries to install all those packages. So it could be solved by: 1. instructing depcheck not to install all 32bit packages from the repo, but only those needed as dependencies or 2. not even placing those unnecessary 32bit packages into that repo Whether we actually download those packages or not (bandwidth concerns) is not strictly related to this ticket. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/328#comment:1> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

Reply

fedora-badges

4:03 p.m.

#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by tflink): Replying to [comment:1 kparal]:

...

IIUC the problem is that we place all downloaded packages into a single

repo and then depcheck tries to install all those packages. So it could be solved by: That's pretty much it. Depcheck tries to install every package that was downloaded, regardless of what architecture it is or if any conflicts exist.

...

1. instructing depcheck not to install all 32bit packages from the repo,

but only those needed as dependencies I don't think that this would be very difficult. We already have a loop that flags packages for update and we could just add some logic to test for the arch prior to flagging them for update. I don't think that would be more than a couple lines of code.

...

2. not even placing those unnecessary 32bit packages into that repo

This would also work. We could tell koji_utils to just download a specific arch and then not worry about the fact that everything is flagged for update.

...

Whether we actually download those packages or not (bandwidth concerns)

is not strictly related to this ticket. Agreed, bandwidth usage is a secondary concern. I'm more interested in getting the tests to function correctly ATM. The other thing I'm not clear on is what we want to do about multilib depcheck runs. How important is it to test multilib stuff in depcheck? If we could figure out a way to be more precise about what packages we're trying to install, I think that would be best in the long run. I'm thinking something along the lines of extending a fix for #325 to exclude only those iX86 packages that conflict with an x86_64 package but that's not a simple change. Ignoring any packages from a non-matching arch would be a quicker fix. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/328#comment:3> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

Reply

fedora-badges

Wednesday, 11 May Wed, 11 May

9:22 a.m.

#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by jlaska): A lot of this will probably be stuff you both have already decided on, I'm just coming up to speed on this issue and trying to understand the root cause. Replying to [comment:4 tflink]:

...

Actually, this looks even easier than I thought it was. If we decide to

go ahead with just disabling multilib tests, it's a matter of commenting out three lines in depcheck_lib.py (lines 245-247 on master head).

...

Not sure if we actually want to do this, though.

If we aren't installing i386 *and* x86_64 packages ... do we lose the ability to verify deps for multilib packages? Assuming mash is doing the right thing, and including the expected multilib packages for us ... disabling multi-lib seems like a big loss. In the wine-wow example sited in the previous ticket, both arch packages are available for install to a x86_64 system. If they are available for install together from the repos, and `yum install` of both packages doesn't complain, the test should be including them both, right? {{{ Available Packages wine-wow.i686 1.3.19-1.fc15 updates- testing wine-wow.x86_64 1.3.19-1.fc15 updates- testing }}} If I'm reading ticket#284 correctly, it sounds like the spec file intends that the two packages cannot be installed together? {{{ %ifarch x86_64 <snip> Requires: wine-wow(x86-64) = %{version}-%{release} Conflicts: wine-wow(x86-32) = %{version}-%{release} %endif }}} Which confuses me ... shouldn't ''yum install wine-wow.i686 wine- wow.x86_64'' honor that conflicts and complain, or at least not attempt to install the i686 version? (see full output at http://fpaste.org/1Vc5/)? {{{ ========================================================================================= Package Arch Version Repository Size ========================================================================================= Installing: wine-wow i686 1.3.19-1.fc15 updates- testing 218 k wine-wow x86_64 1.3.19-1.fc15 updates- testing 221 k Installing for dependencies: cdparanoia-libs i686 10.2-10.fc15 fedora 46 k gd i686 2.0.35-12.fc15 fedora 141 k gstreamer i686 0.10.32-4.fc15 fedora 861 k gstreamer-plugins-base i686 0.10.32-2.fc15 fedora 1.0 M libXpm i686 3.5.8-3.fc15 fedora 58 k libXv i686 1.0.6-2.fc15 fedora 23 k libXxf86vm i686 1.1.1-2.fc15 fedora 21 k libdrm i686 2.4.25-1.fc15 fedora 71 k libexif i686 0.6.20-1.fc15 fedora 317 k libgphoto2 i686 2.4.10.1-1.fc15 fedora 1.0 M libtheora i686 1:1.1.1-1.fc15 fedora 130 k libtool-ltdl i686 2.4-4.fc15 fedora 44 k libusb i686 1:0.1.3-7.fc15 fedora 17 k libusb1 i686 1.0.8-7.fc15 fedora 59 k libvisual i686 0.4.0-10.fc15 fedora 135 k libxml2 i686 2.7.8-6.fc15 fedora 795 k mesa-libGL i686 7.11-0.9.20110509.0.fc15 fedora 145 k mesa-libGLU i686 7.11-0.9.20110509.0.fc15 fedora 176 k nss-mdns i686 0.10-9.fc15 fedora 23 k nss-mdns x86_64 0.10-9.fc15 fedora 22 k orc i686 0.4.14-1.fc15 fedora 147 k wine-common noarch 1.3.19-1.fc15 updates- testing 100 k wine-core i686 1.3.19-1.fc15 updates- testing 13 M wine-core x86_64 1.3.19-1.fc15 updates- testing 13 M Transaction Summary ========================================================================================= Install 26 Package(s) Total download size: 32 M Installed size: 204 M Is this ok [y/N]: N Exiting on user Command Complete! }}} -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/328#comment:5> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

Reply

fedora-badges

12:25 p.m.

#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Hot issues Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Comment (by tflink): I was digging into this and from what I can tell, yum relies on rpm to tell it what packages have conflicts. With this in mind, I wondered what rpm said about wine-wow. If I download pacakges for: * [http://kojipkgs.fedoraproject.org/packages/zabbix/1.8.5/1.fc14/x86_64 /zabbix-server-mysql-1.8.5-1.fc14.x86_64.rpm zabbix-server- mysql-1.8.5-1.fc14] * This is a reference since I know yum finds the conflict between this and zabbix-server-sqlite3 * [http://kojipkgs.fedoraproject.org/packages/wine/1.3.19/1.fc14/x86_64 /wine-wow-1.3.19-1.fc14.x86_64.rpm wine-wow-1.3.19-1.fc14] And run 'rpm --conflicts -qp <rpm file>' (I'm using F14 x86_64) on the packages, I get the following for zabbix-server-mysql: {{{ $ rpm --conflicts -qp zabbix-server-mysql-1.8.5-1.fc14.x86_64.rpm zabbix-server-pgsql zabbix-server-sqlite3 }}} But when I do the same to wine-wow: {{{ $ rpm --conflicts -qp wine-wow-1.3.19-1.fc14.x86_64.rpm }}} I get nothing. I would have expected a conflicts on wine-wow It turns out that the Conflicts is within wine, not wine-wow. So wine.x86_64 conflicts with wine-wow.i686 but there are no issues between the different arches of wine-wow. Running 'yum install wine wine.i686' confirms this. The only way I can think of for us to work around this is to check for conflicts on all packages and their parents in order to keep from installing conflicting packages. I wonder what would happen if the installation of wine-wow.x86_64 and wine-wow.i386 was allowed to continue since that's pulling in both arches of wine-core. -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/328#comment:7> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

Reply

fedora-badges

Monday, 18 July Mon, 18 Jul

5:46 a.m.

#328: depcheck: should not test packages from both x86_64 and iX86 unless needed --------------------+------------------------------------------------------- Reporter: tflink | Owner: Type: defect | Status: new Priority: major | Milestone: Depcheck Component: tests | Resolution: Keywords: | --------------------+------------------------------------------------------- Changes (by kparal): * milestone: Hot issues => Depcheck -- Ticket URL: <https://fedorahosted.org/autoqa/ticket/328#comment:9> AutoQA <http://autoqa.fedorahosted.org> Automated QA project

Reply

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009