Hi,
the Linux builder RosBE has been upgraded to latest 2.1. It keeps using ninja for builds.
With my best regards,
--
Pierre Schweitzer <pierre(a)reactos.org>
System Administrator
ReactOS Foundation
Hi guyz!
I've been reviewing our current Blacklisted suites at Testman. A lot of those unstable testsuites now are reliable, maybe because ReactOS stability has increased or better Winetests.
The following blacklisted suites in the past should go into whitelist:
Gdi32:SetMapMode. Now scores: 51-0
Gdi32:SetSysColors. Now scores: 44-0
Gdiplus:graphicspath. Now scores: 434-32
Gdiplus:region. Now scores: 803-6
Kernel32:pipe. Now scores: 33895-124
user32:trackmouseevent. Now scores: 177-12
wininet:urlcache. Now scores: 186-16
The following suites look reliable but from time to time they score different.So they should be kept as Blacklisted:
user32:msg
user32:win
In the other hand two new candidates should go into Blacklisted:
msxml3:domdoc
ntdll:info
Not bad, 7 to whitelist, 2 almost reliable and just 2 into Blacklist.
My proposal is to update the lists and check during the following days that these new changes are reliable.
If testsuites are a sign of stability, I should say..ReactOS is really stable. Bugged as always.But stable. :)
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 28th of March, 19:00 UTC. And that's tomorrow!
The meeting will be at irc://dev.reactos.org (Port 6667, no SSL) in the
channel #meeting, or as Pierre says. Note that the IRC service will only
be started shortly before the meeting. Your participation passwords will
be emailed to you shortly before the meeting starts, and they are going
to be different once again as they are not stored in any database.
Hopefully it's not much of inconvenience.
If someone still is not getting passwords sent before a meeting - please
email Colin or Pierre before the meeting started to get one.
The agenda will be posted shortly before the meeting, suggestions are
welcome (send them to my email as usual).
Regards ,
Aleksey Bragin
---------- Forwarded message ----------
From: Zachary Gorden <drakekaizer666(a)gmail.com>
Date: Thu, Mar 28, 2013 at 9:47 AM
Subject: Do NOT attempt to translate Book pages
To: ReactOS General List <ros-general(a)reactos.org>, ReactOS Web List <
ros-web(a)reactos.org>
The development guide is using Drupal "Books" as a way of organizing
content. Drupal's localization has a major hole wherein books cannot be
translated. As such, do NOT attempt to translate the development guide or
any other content that uses books.
Hi,
due to a maintenance on the server running them, the following services,
Jira & Fisheye, will be down on the 20th of March 2013, starting at 9h30
CET. This means that the URLs: http://jira.reactos.org &
http://code.reactos.org will be unreachable during the meantime.
The server (and its services) should be back online before midday.
We are sorry for the caused inconvenience.
With my best regards,
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
Hello everybody !
About two or three weeks ago I translated in French the "ReactOS Downloads"
page of our new website, and I was very surprised (and very angry, too)
yesterday to see that it was turned back into English. According to the
history it was done 4 days ago. Do you know what happened there, and how can
this be reverted, if possible ?
Thanks in advance,
Hermès BÉLUSCA - MAÏTO
Hey,
Amine informed me about yet another case of Vista APIs being used in
wine code. This problem is going to increase and we need a solution, the
sooner the better.
My plan to address this is to use lower layer DLLs that contain the
actual implementations, while the upper layer DLLs (kernel32, advapi32,
msvcrt*) are just forwarders to the lower layer DLLs. The lower layer
DLLs can contain whatever we want and wine dlls can link to them, while
applications continue to see version consistent exports of the standard
winapi dlls.
For the exports of kernel32 and advapi32, a possible way to organize
this is to follow MS API reorganisation on Win7, where these APIs are
separated into the API-MS-Win-core-* etc dlls. In fact on Windows the
implementation still stays in either Kernel32 or kernelbase and the
API-MS-* dlls are just "virtual" dlls. How these APIs are organized can
be seen here:
http://www.nirsoft.net/articles/windows_7_kernel_architecture_changes.html
While from a logical perspective it might make sense to organize our
implementations physically into these API DLLs, it comes with an
overhead, since a bunch of extra dlls would need to be loaded and
initialized on every process creation.
We can avoid that by organizing our code in static libraries and merge
them all together to 2 core dlls.
The division like on Windows 7: kernelbase + kernel32 + advapi32,
doesn't work for us, since kernel32 and advapi32 would still need to
contain Vista+ APIs.
Therefore I suggest to divide it into kernelbase.dll and kernelsup.dll,
the latter containing the code that remains in kernel32 and advapi32 on
Windows.
Additional advantage:
For the various CRT modules this can be done as well and would provide
the benefit of having a single full featured CRT, which we can use from
our own code, while still providing a (limited) version specific MSVCRT.
And all other MSVCR* can forward to that core DLL, so we only need to
load CRT code once.
We would have another benefit, when we decide to implement
Windows-Version specific API layers. These can be implemented as
different versions of kernel32.dll etc. which export whatever they do on
a specific Windows Version and contain version specific hacks, if
required. These Version specific DLLs would be placed into subfolders on
system32, having the loader use them, whenever a link/pif/registry
setting asks for a specific (non-default) version.
If someone has doubts and fears this could cause compatibility issues:
Yes it could, but those only apply to extremely special system tools,
which wouldn't work on Windows 7 either.
Since we simply cannot be 100% compatible (unless we copy the MS
binaries and call them ours), we need to make a compromise at certain
points. We really have other problems than some crazy XP/2003 only
system tools not working. The benefits far outweight the problems.
Otherwise MS would never have fiddled with their DLLs.
If someone prefers a different system of organization, I'd be happy to
hear about it.
If there are no objections, I will create a branch and work on that
together with Amine.
Thanks,
Timo
Fix from r58530 deployed on release build slave. Next build will use it.
On 17/03/2013 00:31, buildbot(a)reactos.org wrote:
> The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Release while building ReactOS.
> Full details are available at:
> http://build.reactos.org/builders/Trunk_x86_GCCLin%20Release/builds/384
>
> Buildbot URL: http://build.reactos.org/
>
> Buildslave for this Build: Linux_AMD64_1B
>
> Build Reason: The web-page 'force build' button was pressed by 'spetreolle':
>
> Build Source Stamp: 58530
> Blamelist:
>
> BUILD FAILED: failed compile_3
>
> sincerely,
> -The Buildbot
>
>
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
Hi,
Just for the record, release build is broken.
With my best regards,
On 16/03/2013 13:52, buildbot(a)reactos.org wrote:
> The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Release while building ReactOS.
> Full details are available at:
> http://build.reactos.org/builders/Trunk_x86_GCCLin%20Release/builds/383
>
> Buildbot URL: http://build.reactos.org/
>
> Buildslave for this Build: Linux_AMD64_1B
>
> Build Reason: The Periodic scheduler named 'release' triggered this build
> Build Source Stamp: HEAD
> Blamelist:
>
> BUILD FAILED: failed compile_3
>
> sincerely,
> -The Buildbot
>
>
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
I get an error 500 when attempting to use the result diff mechanism see
http://reactos.org/sites/all/modules/reactos/testman/diff.php?id1=4131230&i…
example
This is an excellent utility in testman, please don't take it away.
I would also like to take this oportunity to thank everyone involved in the
hard work of keeping ReactOS and related services alive, functioning
properly and implementing new features!
