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
Is there any documentation available for where ReactOS stores its
logfiles? For a phase 2/3 installation to harddisk, obviously it gets
stores on drive C: somewhere. For phase 1, screen and debugport
(com/rs232) seem to be the only options. Same goes for the BootCD and
LiveCD.
As I'm experiencing massive issues with getting ReactOS to boot on
USB-enabled real-hardware systems, I'd like to boot from the CD and have
ReactOS automatically write logfile to whichever first FAT filesystem it
can find. Irrelevant if it's USB stick or ATA hdd-partition. Is this
possible or even already done?
If above is not possible, which exact configuration settings would I
need for Bochs or QEMU (so I get debug log file) to add:
* USB optical device (ISO file on host)
* USB harddisk (hdd-imagefile on host)
* USB mouse
* USB keyboard
Lacking a 2nd system and photocamera device, all that remains for
obtaining logfiles is using an emulator, which usually configure their
hdd/cd as ATAPI devices and input as PS/2 devices
I'm hoping an emulator will show same issues as on real hardware, and
that the logfiles can add to bugreports already present.
Bernd
PS: tested 58013 and searched
http://jira.reactos.org/secure/IssueNavigator.jspa for USB
PPS: Haiku happily boots up on this machine from my isostick device.
Hi All,
Newbie here (2 days). I would like to know the who-is-doing-what for the ARM
port. It seems that, with the current lock-down of all three major mobile
platforms (iOS/Android/Windows Phone 8), as well as the impending surge in
2013 of ultra-cheap mobile devices like tablets based on ARM, and of course,
the loveable Raspberry Pi, a truly open Windows-oriented platform is more
needed than ever.
J.C.
Hello!
Due to Christmas and New Year holidays this month's status meeting makes
little sense. Preliminary it's rescheduled to January, exact dates will
be proposed after speaking to our team members.
Thank you all for your work in 2012, and bright future awaits us in
2013, I'm sure.
Best regards,
Aleksey Bragin
I think that in the spec files semantics, destination strings are just
buffers and should be considered as pointers.
hbelusca(a)svn.reactos.org a écrit :
> Author: hbelusca
> Date: Wed Dec 26 19:26:08 2012
> New Revision: 58016
>
> URL: http://svn.reactos.org/svn/reactos?rev=58016&view=rev
> Log:
> [MSVCRT]
> Export __crtLCMapStringW and correct __crtLCMapStringA: their prototypes are :
>
> int CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t *src,
> int srclen, wchar_t *dst, int dstlen, unsigned int codepage, int xflag)
>
> and
>
> int CDECL __crtLCMapStringA(LCID lcid, DWORD mapflags, const char* src,
> int srclen, char* dst, int dstlen, unsigned int codepage, int xflag)
>
> Needed by SVN.
>
> Modified:
> trunk/reactos/dll/win32/msvcrt/msvcrt.spec
>
> Modified: trunk/reactos/dll/win32/msvcrt/msvcrt.spec
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt/msvcrt.sp…
> ==============================================================================
> --- trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] (original)
> +++ trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] Wed Dec 26 19:26:08 2012
> @@ -143,8 +143,8 @@
> @ cdecl __crtCompareStringW(long long wstr long wstr long) kernel32.CompareStringW
> @ cdecl __crtGetLocaleInfoW(long long ptr long) kernel32.GetLocaleInfoW
> @ cdecl __crtGetStringTypeW(long long wstr long ptr)
> -@ cdecl __crtLCMapStringA(long long str long ptr long long long)
> -# stub __crtLCMapStringW
> +@ cdecl __crtLCMapStringA(long long str long str long long long)
> +@ cdecl __crtLCMapStringW(long long wstr long wstr long long long)
> @ cdecl __daylight() __p__daylight
> @ cdecl __dllonexit(ptr ptr ptr)
> @ cdecl __doserrno()
>
>
Hello,
starting now a new debug testbot slave is available. It is running VMware Player 5.0.1 under Linux x64.
It will run all the ISOs built by the Linux builder.
Its results are available at the usual place: http://www.reactos.org/testman with the name: CMake_x86_GCCLin (VMPlayer).
With my best regards,
--
Pierre Schweitzer <pierre(a)reactos.org>
System Administrator
ReactOS Foundation
Hello and Merry Christmas!
I know there are people from various technical universities around the
world subscribed to this list.
If you work there, please reply to me, as I'm looking for some
collaboration related to Operating Systems theory course and ReactOS.
Thank you,
Aleksey Bragin
P.S. Crossposting to both ros-dev and ros-general is a bad idea, but I'm
doing this to reach out all our subscribers. Sorry for inconvinience.
Are you planning on resurrecting this branch Thomas?
On 23/12/2012 10:25, "tfaber(a)svn.reactos.org" <tfaber(a)svn.reactos.org>
wrote:
>Author: tfaber
>Date: Sun Dec 23 10:25:19 2012
>New Revision: 57976
>
>URL: http://svn.reactos.org/svn/reactos?rev=57976&view=rev
>Log:
>[EXPLORER_NEW]
>- Add a manifest file to support theming
>- Formatting fixes
>- Based on Andrew Green's GSoC branch
>
>Added:
> trunk/reactos/base/shell/explorer-new/explorer.exe.manifest (with
>props)
>Modified:
> trunk/reactos/base/shell/explorer-new/explorer.rc
> trunk/reactos/base/shell/explorer-new/taskswnd.c
> trunk/reactos/base/shell/explorer-new/trayntfy.c
Fixed as well.
Forgot that one, sorry.
Le samedi 15 décembre 2012 à 12:48 +0000, buildbot(a)reactos.org a écrit :
> 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/289
>
> 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_1
>
> sincerely,
> -The Buildbot
>
>
--
Pierre Schweitzer <pierre(a)reactos.org>
Systems Administrator
ReactOS Foundation