I've been testing Beta 1, and it seems that this KDE4 bug is still
haunting the KDE desktop: https://bugs.kde.org/show_bug.cgi?id=275469
It is not a show-stopper, but... it is really annoying. I haven't
seen anyone complaining about it on Factory though (although I may
have missed it)... it's been around (for me at least) since KDE4.7.0.
There seems to be no movement on getting it fixed from the upstream
KDE side (if the bug comments are to be believed). Is there anything
"we" can do to correct it? Is it worth opening an openSUSE bug
against it? (I'm guessing not, but worth asking)
C.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi,
This week, a group of Hack week participants have sat together and
bootstrapped openSUSE Factory for ARM, namely for armv5tel (soft floating
point with thumbs) and for armv7hl (hard floating point with aapcs-linux ABI).
This seems to be the common cross-distro standard, the recent Fedora15 porting
activities also targetted armv7hl.
The status is at the moment:
- We have at the moment over 1700 packages succeeded. A test on real hardware
shows that the packages are running fine. Many more packages should come over
the next few hours, as low-level dependencies are finally building and now
will enable the build of the rest of the distro.
- We have one hard issue: gcc 4.6 seems to miscompile on armv5tel something
that causes the rpm database to corrupt very quickly, which means that no
packages can build in a regular chroot, which sets up the rpm database but
corrupts it, so the rpmbuild then fails.
As a workaround, we're building armv5tel with gcc 4.4, which works fine. Thiis
is not a permanent solution yet, we need to find the actual problem.
- We have a few failures in packages. Looking at them, most of them are caused
by threading issues (e.g. failing testsuites), because building under usermode
qemu does not have a good thread emulation, and it often fails or simply
crashes. This seems to be a hard issue, we can only solve that by building
either in system qemu (which seems to be too slow to use) or by building with
real hardware. We currently plan to use real hardware.
At the moment, problematic parts can be disabled with a
%if !%qemu_user_space_build
...
%endif
section.
Everyone is invited to take a look at the failures and help fixing them.
building packages locally is easy, if you have "qemu" installed. we recommend
to use the qemu from openSUSE:Tools:Unstable, as it has a couple of fixes we
noticed that we need for proper building. These fixes are hopefully soon in
the factory version.
We document status + common problems + how to particpate here:
http://en.opensuse.org/How_To_Work_On_openSUSE_ARM_Distribution
Please join!
Thanks,
Adrian, Alexander, Dirk and Reinhard.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Sorry for the cross posting, but I thought it worth the extra noise ;-)
One of the things that came out of the recent Geeko Love-In for me was a
new project to immerse myself in within openSUSE. Yeah I know, we have
enough existing projects already so why create a new one? Simples!
Believe it or not but openSUSE is behind the curve in a specific
segment, and that segment has yet to explode to its full potential. That
segment is ARM. No I'm not talking about your upper body appendages, but
the architecture that powers most of your little devices (and some
bigger ones too). Almost all smartphones, tablets and many other
consumer devices are powered by ARM from one of the numerous licensees.
Didn't openSUSE do something about this a while ago? Yes we did.
Unfortunately the effort seems to have bitrotted somewhat, there were
numerous reasons and I don't even prophesise to know the all either.
As such I'm going to try and kickstart things, and see it through and
hopefully see it grow. As I mentioned, this idea came up at the
conference when I was talking to numerous people (I forget how it all
started, but that doesn't really matter). There was an overwhelmingly
positive view on the matter, and that for me was all that counts. Now
let me be crystal clear here, *THIS WILL NOT BE A ONE MAN SHOW!!* I
mentioned previously that my view is that we as a community are pretty
lazy at times with getting our hands dirty. As such if you think things
are going slow or not going in the direction you would like, don't moan.
Get your hands dirty and help make a difference.
The process will not be an easy one either, so don't expect a port to
magically appear over night. If we're lucky we might be able to have a
working port in 6 months. Maybe longer, maybe shorter; ultimately that
lies with us as a community.
Stage one has begun already thanks to Adrian Schroeter, Alex Graf and
Dirk Mueller. Stage one comprises of getting the boot strap process to
work. At a cursory level this means getting the packages required for
setting up a build chroot environment and for building these packages on
the target ARM architecture. This will possibly take a fair amount of
time, and no I won't give any timelines for this - how long is a piece
of string?
openSUSE has a couple of advantages here, 1) we have the OBS which can
cross build and if need be cross compile packages for numerous
architectures (ARM included) so we are going to make a start with that;
2) SUSE are going to be doing another HackWeek (I think it is next week)
which means Adrian, Alex, Dirk and anyone else that has knowledge,
experience or interest can join in the fun and pain almost full time for
a week - let's not kid ourselves here there is a high probability for
lots of pain, but also fun ;-) Thing is HackWeek is not just for SUSE
staff, it is also for the community. You can join in and spend some
quality time on the project with those that know a whole heap of stuff,
and learn from them and maybe even teach them something too.
We are going to be targeting ARMv7 nothing older I'm afraid this means
CORTEX-A8 and above (looking at A9 primarily and then the new A15 when
it's available), it gets too messy otherwise and it is already messy
enough.If you have knowledge and experience, please help out. If you
don't take part you have no justification to complain - you've got to be
in it to win it ;-)
So I'm basically just giving you all a heads up on this effort, and will
update you as regularly as possible (I'm hoping to do something weekly
maybe). In the meantime, if you're interested join #opensuse-arm on
Freenode and the opensuse-arm mailing list. *DO NOT HARRASS* for
updates, if there is something to say it will be said. If you've got a
question, ask and *WAIT* for an answer. If you want to help out but want
to know how ask and *WAIT* for an answer. I will try and get something
on the wiki soon, with a todo list etc.
Thanks and here's to getting our Geeko some ARMs.
Regards,
Andy
--
Andrew Wafaa
IRC: FunkyPenguin
GPG: 0x3A36312F
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Say I want to submit styles or icon sets. Is active upstream still needed for such packages?
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hello,
I just notice the factory last vesion (with the new login screen)
starts kde extremely fast, nearly instatly, when the 11.4 one is
pretty long (as where all the olders)
is that just because I have less installed daemons, or is that a new
feature about wich we can speak? it's very impressive
thanks
jdd
--
http://www.dodin.nethttp://www.dailymotion.com/video/xgxog7_clip-l-ombre-et-la-lumiere-3-bad-pi…http://www.youtube.com/watch?v=FGgv_ZFtV14
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
hi:
Currently libtheora fails to build in armv7hl with an ICE
mathops.c:296:1: error: insn does not satisfy its constraints:
(insn 943 942 944 10 (set (subreg:SI (reg:DI 1047) 0)
(ior:SI (ashift:SI (subreg:SI (reg/v:DI 238 [ y ]) 4)
(const_int -8 [0xfffffffffffffff8]))
(subreg:SI (reg:DI 1047) 0))) mathops.c:290 251 {*arith_shiftsi}
(nil))
mathops.c:296:1: internal compiler error: in
extract_constrain_insn_cached, at recog.c:2024
Can someone check it out ?
Cheers.
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
