Hello all,
The 64-bit flash-player from Adobe is now RC1 as of Sept. 6th.
Version RC 1 11.0.r1.129
Date Sep 6, 2011
http://labs.adobe.com/downloads/flashplayer11.html
--
Cheers!
Roman
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
In the past the snapshot repo was created (AFAIK) to reduce the number of
rebuilds triggered by changes in the Factory/standard repo.
However this is no longer the case. The snapshot repo seems to be updated as
soon as that the Factory/standard repo is being published and this causes an
big number of rebuilds.
Of course this is the way that things should work, but I wonder if it is
really necessary to have the snapshot repo updated at least once a day (if not
twice a day). This is causing that repo's that are building against it to be
triggered for a full rebuild again and bigger repo's will just keep on
building and building, without ever really coming to the point to be
published.
My question now is if we can lower the frequency of updating the snapshot repo
(and give somewhat more peace to OBS) or is there a way to setup a repository
to ignore those snapshot updates ?
Regards
Raymond
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
Hi,
opensuse 11.4 is getting to be a few cmake versions behind (2.8.3) and
my workarounds are growing for modules that have fixes upstream. How
about updating what's in, at least, tumbleweed? I'd be glad if it got
put into 11.4 updates but tumbleweed is a great start. I found a build
laying around in the tools:building repository but yet another
repository is undesirable, especially since I maintain alot of build
machines at my workplace.
Thoughts? Yay / Nay?
-Jason
--
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
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
The new branding is in the factory and looks cool... great work!
Now the things I found up to now
1. kdm login screen and kspashx on my desktop 1920x1080 seem to use
different resolution backgrounds.
the geeko changes slightly the position from kdm to ksplash. this may
be tough to fix, iirc ksplash is picky about what resolutions it
takes... kdm is not.
2. the susegreeter still has the old branding... and it seems the new
branding was not commited in git.
3. the sysinfo uses the old branding.
this is the offending file...
/usr/share/kde4/apps/sysinfo/about/images/background.png
I did not manage to see where is taken from ye.
Moreover... when in full-screen the background does not expand all
over the window width. see picture.
http://paste.opensuse.org/23951090
4. for factory versions... should we use for kde kickoff as start the
factory geeko instead of the green one? moving to the green one once
in rc or gm state?
Alin
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
I created delete requests , sorry for that ...
https://build.opensuse.org/request/show/85763https://build.opensuse.org/request/show/85764
IMHO Tuxguitar should be added to packman repo (again)
On Sat, Sep 24, 2011 at 4:08 PM, <embar(a)super.lt> wrote:
> Hi,
>
> I understand, that would be musch better to compile jar, and not use
> precompiled.
>
> I seems, that eclipse-swt package is build from source in
> home:decriptor:eclipse project, but it requires a lot of dependencies:
> https://build.opensuse.org/package/show?package=eclipse&project=home%3Adecr…
>
> I have a litte experience in RPM building.
> Maybe some one could somehow use home:decriptor:eclipse as base to build
> eclipse-swt? Or create eclipse-swt package "from zero" from
> http://www.eclipse.org/swt/ ?
>
> Regards,
> Mindaugas
>
>> tuxguitar doesn't contains precompiled jar file, it's the eclipse-swt
>> package (tuxguitar depends on it), which break packaging rules:
>> http://en.opensuse.org/openSUSE:Packaging_Java#Third_party_jars
>> I guess both packages should be dropped from Factory
>>
>> or did I missed something ?
>>
>> michal
>>
>> On Fri, Sep 23, 2011 at 1:08 AM, Kirill Kirillov
>> <kirill.kirillov(a)gmail.com> wrote:
>>> Hi!
>>>
>>> mucommander package was rejected due to precompiled jar files:
>>> https://build.opensuse.org/request/show/82152
>>>
>>> But I see packages in the Factory with precompiled jar files, e.g.:
>>> https://build.opensuse.org/package/show?package=tuxguitar&project=openSUSE%…
>>>
>>> Could you please clarify this?
>>>
>>> Thanks!
>>>
>>> --
>>> Kirill Kirillov
>>> <><
>>>
>>> --
>>> To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
>>> For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
>>>
>>>
>>
>
>
>
>
>
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
In case any packager is interested about VBox Guest Additions, I just
read this off of the vbox-dev mailing list.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hello Felix and all,
As an update to our discussion about how to reconcile distribution
versions of the Additions with Oracle's, I have taken care of both of
the points below. Any future 4.1 releases will have a modified
version notifier on non-Oracle builds which advise the user that if
their distribution/distributor no longer provides current versions of
the Additions they should remove the distribution version and install
ours. Distributors should feel free to customise the message. And we
have also fixed the only problem we could find which would cause
problems when 4.1 Additions were used with a 4.0 host - the Guest
Execution functionality was not working in this case. The 3D ABI is
compatible between 4.0 and 4.1, and we will try our best not to keep
it compatible in future. So as of any future 4.1 or later releases it
will be safe for distributions to supply the most recent version of
the Additions for use with any host version as of 4.0. (Just in case
there is any doubt, we will only be testing this for Linux guests,
although chances are good that it will apply for other guests too.)
Regards,
Michael
On 08/31/2011 11:17 AM, Michael Thayer wrote:
I have let this go through my head a bit and come to the conclusion that
two things might be helpful here. One would be if we (VirtualBox
upstream) could make the Additions officially compatible with (some)
previous releases of VirtualBox. With a big question mark over 3D
support (which I am less familiar with) I don't think that it would be a
major problem for 4.1 Additions to also support VirtualBox 4.0 and
possibly 3.2 in an optimal way, though I will have to take a look at
that. The other thing would be making use of the version notifier which
is built into the Additions and warns if they are older than the
VirtualBox version they are running on. The message could be changed
slightly in a distribution-specific way, to tell the user how to update
the distribution packages, and how to uninstall the packages so that
they can install our Additions if the right update is not available.
--
ORACLE Deutschland B.V. & Co. KG Michael Thayer
Werkstrasse 24 VirtualBox engineering
71384 Weinstadt, Germany mailto:michael.thayer@oracle.com
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org
FYI, I just sent this to the project list - in case you're not
reading it regularly.
Please post your answers/ideas there.
Greetings, Stephan
---------- Weitergeleitete Nachricht ----------
Betreff: ANNOUNCE: I call it a beta
Datum: Donnerstag, 29. September 2011, 22:22:53
Von: Stephan Kulow <coolo(a)suse.de>
An: opensuse-project(a)opensuse.org
Hi,
We had a short go/no-go meeting on #opensuse-factory and decided
that the fuser problem may be the cause of all evil and now that it's gone,
we can go forward and release beta1.
We even managed to get most of the artwork updated in the days slippage.
If you come around it, I will upload build315 to the mirrors tomorrow morning.
When to announce publically I leave to the marketing guys, I'll be mainly
off the internet till tuesday as monday is public holiday for me and I'm told
publishing news on friday is bad - but I'll make sure the ISOs are available
for interested testers. I hope that's ok for the team.
Now the interesting question is what about the RC1. We didn't really loose
time in development as we checked in almost everything that came in during
the time we waited for the fixes - this includes e.g. kernel 3.1rc7. But we
can't hold the schedule as it is - the original deadline for RC1 checkins is
october 7th - that's around 4 days after public announcment of the beta
and even before the pizza party.
With the new factory work flow we have some more flexibility in terms of
checkin deadlines, so let's make use of that. My proposal would be:
Move RC1 from October 13th to 21st for release date - checkin deadline
would be 18th.
Move RC2 from October 27th to November 3th - checkin deadline would be
October 28th (November 1st and the monday in front are blackout in Nuremberg
and we rely too much on Nuremberg to move the date where it's perfect ;( )
Move Final release from November 11th (who set that date anyway? :) to
November 16th. GM would be on 11th.
Note, that I don't want to move the final date too much and if we all agree to
some discipline, RC2 will already be perfect and we only apply some polishing
up to GM. I know that shuffles our usual weekdays for release a bit and I'm
pretty sure I made some mistakes in my proposal, so please feel free to
give ideas of yours.
Greetings, Stephan
-------------------------------------------------------------
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org