Bug 7813

Summary:	Mageia Software Center wrong behaviour with wrong architecture
Product:	Mageia	Reporter:	ra oeai <oeai>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED INVALID	QA Contact:
Severity:	normal
Priority:	Normal	CC:	rwobben
Version:	Cauldron	Keywords:	NEEDINFO
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:	rpmdrake	CVE:
Status comment:
Attachments:	urpmi list urpmi config

Description ra oeai 2012-10-16 02:41:41 CEST

Well i'm not sure if this bug is not posted, since i've just sent it, but it's not on my bug list.
So i've been trying to install i586 kernel after installing x64, i thought to install both architectures on 1 hard. so i've checked kernel i586 but it says wrong arch to me, ok i've disabled component and tried to choose razor-qt package just wanted to look on it since it's not yet in official debian distros. after i've checked razor-desktop i've pushed apply but it told me again about that wrong arch error, i've tried few times and then restarted center all my razor marks was on their places but when i've pressed apply nothing happens - o_O
i've tried to dispell my casts and then checked list again - it's not working, i've tried to clear list from menu, but when i've been searching for razor all my marks was in place, then i've enabled another component - and download started but not for razor-desktop.
so i think that dependencies resolving is not clear for some array - are you using objects or string arrays?
and something is wrong with error function looks like you need to check exceptions resolving.

Comment 1 Manuel Hiebel 2012-10-27 23:27:41 CEST

can you attach the output of:
urpmq --dump-config
urpmq --list-media active

also in rpmdrake you should have both arch for most of packages

Source RPM: (none) => rpmdrake

Manuel Hiebel 2012-10-27 23:27:57 CEST

Keywords: (none) => NEEDINFO

Comment 2 roelof Wobben 2013-01-04 11:04:46 CET

Hello, 

Can you confirm this bug on Mageia 2 or Cauldron ?

Roelof

CC: (none) => r.wobben
Severity: critical => normal

Comment 3 ra oeai 2013-01-04 11:58:49 CET

srry i almost forgot about it, i'll try to reproduce just installing a new system 3beta, so it was less bugged and my clean system was not touched

Comment 4 roelof Wobben 2013-01-04 12:23:04 CET

NP, we look forward to your report.

Roelof

Comment 5 ra oeai 2013-01-04 17:03:40 CET

hehe =))
i've done this, but now i got installed the i586-rt kernel on the x64 system and of course i got panic on booting that kernel ; )

Comment 6 roelof Wobben 2013-01-04 17:31:22 CET

oke, 

Can you give us the information asked on comment 2 then.

Roelof

Comment 7 ra oeai 2013-01-04 18:12:06 CET

my old VM is not starting, not sure why
so i got only latest urpmi for now attached

Comment 8 ra oeai 2013-01-04 18:13:44 CET

Created attachment 3313 [details]
urpmi list

Comment 9 ra oeai 2013-01-04 18:14:05 CET

Created attachment 3314 [details]
urpmi config

Manuel Hiebel 2013-01-04 18:19:03 CET

Attachment 3313 mime type: application/octet-stream => text/plain

Manuel Hiebel 2013-01-04 18:19:07 CET

Attachment 3314 mime type: application/octet-stream => text/plain

Comment 10 Manuel Hiebel 2013-01-04 18:26:01 CET

so some comment, in cauldron it's a bad idea to enable any testing repo
in general you should have release and update which is not the case for 32bit
(yes updates are empty on cauldron like backport)

Then you should only take 64bits packages. 
Why is 32bits media enable ? because there are sometimes needed by crazy packages like skype or wine. and furthermore it can help for any people which make development.

So this is not a bug. You have 64 and 32 bits packages, but the priority is to 64 one.

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

Comment 11 ra oeai 2013-01-04 22:21:33 CET

well since i got some more bugs i see some linked themes really
https://bugs.mageia.org/show_bug.cgi?id=8596
https://bugs.mageia.org/show_bug.cgi?id=7830
but in the first post i was asking if there are strings or objects used for searching patterns in code, so i think that maybe there's something wrong, but there was another bug with dualarch CD that is closed now and i cannot find it, and there's no dualarch right now.
but i found the other solution, for the installation process of network-cd let's assume only 32bit software or 64bit, actually i was proposing to do that by adding "text --x32" setup for platforms that are capable to use x64, so by default they would use only x64 to install system and for x32 platforms there's no need to use x64 sources.
and if the platform is toght choosed then all i386compatible-cross-arch packages could be in one place that will not include all others packages that actually are available for x64. 
as for kernel i586 i would recommend to warn users that they cannot use the i586-kernel with x64-xompiled packages, but for this purpose they can use the kvm or xen to use it under the x64-kernel - well yeah this needs much more to do.