Description of problem:don't launch Version-Release number of selected component (if applicable): How reproducible:don't launch on GUI and shell Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
Keywords: (none) => TriagedAssignee: bugsquad => petosSummary: don't launch : "Instruction non permise" on shell => darktable don't launch : "Instruction not on allowed" on shell
CC: (none) => mageia
FWIW, here's the original error message: [doktor5000@Mageia4 ~]$ export LC_ALL=C [doktor5000@Mageia4 ~]$ darktable Illegal instruction This is normal when SSE2 support is not available, which is definitely NOT the case here (even SSE3 and 4_1 available) so this is just broken. Please fix.
CC: (none) => doktor5000
Yes, I agree, this is an error in build obviously. But not able to find the parametr causing this... After rebuild on fresh install from the SRPM it works as expected. Florian, is it possible it was not builded on our MGA build-system properly? Petos
Status: NEW => ASSIGNED
(In reply to Petos Safarik from comment #2) > After rebuild on fresh install from the SRPM it works as expected. Florian, > is it possible it was not builded on our MGA build-system properly? Well, not sure. You could try to push it after disabling parallel build via replacing %make with make, as %make will use as much threads as cores are found, so probably 16 on our buildsystem. FWIW, I got the same result, rebuild locally on Mageia 4 installation, and it works as intended. Here %make expands to two threads: [doktor5000@Mageia4 SPECS]$ rpm -E %make make -O -j2 Output when running darktable: [doktor5000@Mageia4 SPECS]$ darktable [defaults] found a 64-bit system with 4015072 kb ram and 1 cores (0 atom based) [defaults] setting very conservative defaults
I notice a whole section of CMakeLists.txt related to SSE is commented out. It seems to have been for testing the SSE capability of the machine used for building, which is of no use for a package build as the package needs to run on all machines. I would guess that the SSE capability detection has been moved to runtime (hence the commented section in CMakeLists.txt), but that it's implementation is incomplete/broken. Just a guess, I may be totally wrong ;)
CC: (none) => zen25000
Some news on the prob?
CC: (none) => magnus.mud
I've just submitted a update candidate to 4 core/updates_testing which disables parallel build, as there's no upstream report about a similar issue (or only from 3 years ago which have been fixed since). Please test if that helps darktable-1.2.3-4.1.mga4 should appear soon on your favorite mirror.
Thanks, will test tonight
No success, same error I think sse2 i there on my machine: [root@edge magnus]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Turion(tm) II Neo K685 Dual-Core Processor stepping : 3 microcode : 0x10000c8 cpu MHz : 800.000 cache size : 1024 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv svm_lock nrip_save bogomips : 3591.20 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate
Shouldn't it better to backport version 1.4.1? On my cauldron it`s running
After solving some other probs with my Cauldron there is the same error with version 1.4.2
Version: 4 => Cauldron
I`m very interested in solving the problem, because I cannot update my MGA3 before. Can I give any information to help? I have a MGA4 and a Cauldron for testing
I've pushed darktable-1.4.2-2.mga5 to cauldron, only change is not using parallel make as that fixed it fore me before, at least when rebuilding the package locally. Should be available on your favorite mirror in a few hours.
Same error :( Will try it with my second Cauldron in the evening. In the moment there is a prob with aria.
barja mentioned he could also reproduce it with parallel and non-parallel build. Somebody should report this upstream at http://darktable.org/redmine/projects/darktable/issues I've only found two issues that look a bit similar on a quick search: http://darktable.org/redmine/issues/9994 And a much older one: http://darktable.org/redmine/issues/8427
(In reply to Florian Hubold from comment #14) Somebody should report this upstream at > http://darktable.org/redmine/projects/darktable/issues This is a good idea, but I`m not able to give the darktable-team effetive technical informations (of the Mageia build options etc). If some other will do it I will look on this issue and will confirm this error. If possible i will give also informations of my machines and tests.
I had a chat with upstream and have just pushed a new build to Cauldron with this change: Index: SPECS/darktable.spec =================================================================== --- SPECS/darktable.spec (revision 639063) +++ SPECS/darktable.spec (working copy) @@ -74,8 +74,8 @@ rm -rf src/external/osm-gps-map/ %build -%cmake -make +%cmake -DBINARY_PACKAGE_BUILD=On +%make %install %makeinstall_std -C build Please test.
Thanks :) I will test tonight.
@ Petos If the above change works, and an update to Mga4 is done then please apply the clean-up that I did to the summary and description etc. in Cauldron at the same time :) http://svnweb.mageia.org/packages?view=revision&revision=639063
(In reply to Magnus Rasche from comment #17) > Thanks :) > I will test tonight. Good - the minimum requirement for darktable-1.4.2 is sse2 so you should be OK. darktable-5.x.x when released will require a minimum of sse3 - so I suppose we should also mention this in the description of each package.
I meant 1.5.x of course not 5.x.x :\
Well done :) no more error!
(In reply to Magnus Rasche from comment #21) > Well done :) > no more error! \o/ I have pushed darktable-1.2.3-4.2.mga4 in Mageia 4 core/updates_testing. Please test this too if you can.
Thanks I will test tonight
Same procedure as yesterday :) Well done, no more error
################### Update Advisory: darktable-1.2.3-4.2.mga4 is now in Mageia 4 core/updates_testing This update adds a build directive to cmake (suggested by upstream) to allow the program to run on various processors with sse2 and above available. Affected packages: darktable-1.2.3-4.2.mga4.src.rpm darktable-1.2.3-4.2.mga4.<arch>.rpm darktable-debuginfo-1.2.3-4.2.mga4.<arch>.rpm Testing: This bug only affects older cpus with nothing higher than sse2 available, so it's not easy to test unless you have this hardware. Note sse2 is the minimum requirement for this software - it won't run with less. On affected machines the program fails to run and the error in a terminal is "Illegal instruction" This update has fixed the issue for the reporter in Mga4 and in Cauldron where the same change has been applied to the current release.
Version: Cauldron => 4Assignee: petos => qa-bugs
You can check with .. $ cat /proc/cpuinfo | grep sse flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dtherm tpr_shadow vnmi flexpriority
For the reference I was able (a week ago or so) to reproduce the bug in a Mageia 4 VM (even though my CPU has sse2 and more). Maybe because it was in a VM?
CC: (none) => remi
(In reply to Rémi Verschelde from comment #27) > For the reference I was able (a week ago or so) to reproduce the bug in a > Mageia 4 VM (even though my CPU has sse2 and more). Maybe because it was in > a VM? Interesting, I had not tried this in a VM, but yes in Mga4 in VBox the current version does exhibit the bug and the update fixes it :)
Testing Mageia 4 x86_64 in VBox. I could reproduce the bug from comment 1. The update candidate fixes it, and basic functionalities work as expected: - importing .NEF and .JPG photos - apply various effects - browse the modification history - click randomly on some menus :-) - export modified image
Whiteboard: (none) => MGA4-64-OK
Note: I tested Mageia 4 i586 in VBox and could not reproduce the bug. The update candidate also seems to work fine there but I did not test thoroughly. A Mageia 4 i586 test on an older CPU would be nice.
(In reply to Rémi Verschelde from comment #30) > Note: I tested Mageia 4 i586 in VBox and could not reproduce the bug. The > update candidate also seems to work fine there but I did not test > thoroughly. A Mageia 4 i586 test on an older CPU would be nice. FWIW A comment about 32bit and darktable from upstream: "32bit machines are tricky in the first place, so using a very old one is probably not a good idea"
I can start to test this,now i'm part of qa team.
CC: (none) => ozkyster
Mageia 4 32bit testing ok no issues found.
Adding the corresponding tag on the whiteboard then, thanks Otto!
Whiteboard: MGA4-64-OK => MGA4-32-OK MGA4-64-OK
Validating the update. The advisory has been uploaded. Please push darktable to Mageia 4 core/updates.
Keywords: (none) => validated_updateWhiteboard: MGA4-32-OK MGA4-64-OK => MGA4-32-OK MGA4-64-OK advisoryCC: (none) => sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGAA-2014-0140.html
Status: ASSIGNED => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED