Summary: | app-office/kspread-2.1.0 - kspread-2.1.0/kspread/tests/BenchmarkHelper.h:46: error: unknown register name ‘edx’ in ‘asm’ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Current packages | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | hppa |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 295884 | ||
Attachments: | app-office:kspread-2.1.0:20091207-092815.log.gz [hppa,fail] |
Description
Jeroen Roovers (RETIRED)
2009-12-07 18:37:01 UTC
Created attachment 212374 [details]
app-office:kspread-2.1.0:20091207-092815.log.gz [hppa,fail]
looks like sane approach. Feel free to patch it for you to make it work. I dont want to do it myself cause i cant test it anyway :] Also note that most koffice fails test and upstream is aware, but not going to fix it. I have no idea how to tell cmake to not build these kspread/tests targets... Ok i spoke with upstream guys: [23:08] -*- ThomasZ thinks Qt does't even support hppa anymore. [23:10] <pinotree> scarabeus: afaik we don't have anyone working directly on pa-risc [23:10] <-> ThomasZ je nyní znám jako ThomasZzZ [23:10] <pinotree> so the best (or the only thing?) you can do to fix those is provide a patch to fix them [23:11] <ThomasZzZ> scarabeus: you got to ask; how many people will we dissapoint if kspread doesn't run well on haap So question is do you want to fix it or should i just make those test disappear? I don't quite get that snippet of conversation. You said that "most koffice fails test and upstream is aware, but not going to fix it." I assumed that to mean tests are broken widely and on many platforms. I also assumed that to mean that the problem isn't hppa specific at all. So I don't get why the conversation you quoted is centred around hppa, or Qt for that matter. The real problem is that the tests fail to build at all (probably because they've been written to work on x86 only). Conditionally running the asm or some generic code might help, but since upstream apparently isn't interested in fixing that, we only need to find a way to disable building the tests, let alone running them, let alone hoping to find that they "succeed". Not relevant any more, bug #304363. |