Ros-dev

ros-dev@reactos.org

5791 discussions

ReactOS Services partial downtime
by Pierre Schweitzer 19 Aug '12

19 Aug '12

Hi, today, many of our services encountered a long downtime due to an air conditioning issue in the datacenter their running hypervisor is located (you can find more info there: http://hetzner-status.de/ - german). A safety shutdown has been done to preserve our server hardware integrity. The other hypervisor and the other services being in other datacenters, they were not concerned by the issue. Services being concerned: - Mail - SVN - git - web - build master They are now fully back online and operational. Sorry for the inconvenience. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 0

Bug 7247: msvcrt Should Uses SEH and crtdll Does Not
by James Tabor 18 Aug '12

18 Aug '12

Hi, Has anyone seen this bug report? James Bug 7247

1 0

Old bootcd ISO files
by caemyr＠myopera.com 16 Aug '12

16 Aug '12

Dear All Some time ago, due to lack of space on ROS servers, a large number of old ISO files for prebuilt revisions had to be deleted. I was only able to pull a limited number of them. Right now, while hunting a regression in late rev 3xxxx, i`m heavily limited due to lack of ISOs. For a long-term plan, i intend to add a legacy builder, containing all the previous, rbuild-based Build environments, allowing me to build some really old revs. Right now i need to ask for your assistance. If you have any older, OFFICIAL Bootcd ISO files, of revision earlier than 44000, please let me know, be it on irc or by forum PM. We need to compare the revisions first, to avoid duplicates, then i`ll pull them from you onto my server, which will effectively allow our Team to use them if needed. Thanks in advance. -- With best regards Caemyr

1 0

Fwd: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test
by caemyr＠myopera.com 16 Aug '12

16 Aug '12

It seems that any crash in APITESTS on vbox testbot is causing rosautotest to redo from start. We can see this in stdio log: http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/6323/s… (just search for "restarting" word). APITESTS are repated and such log as a whole is messing up testman, which is treating it like two submissions for the same revision. It accepts the first one (incomplete due to crash) and rejects the second one, reporting a duplicate: "ERROR! submit(13111, 518, ...) - We already have a result for this test suite in this test run! "Windows_AMD64_1 VBox-Test"" As we all know, we should expect tests to fail and even crash (this is what they are designed for), hence the error is in rosautotest and testman. Rosautotest, strangely, is affected only on vbox, on kvm the apitest crash is not causing a restart of test run. Winetests, if i recall correctly, were never affected in such way. Testman should not reject a submission after its saved up and revision - blocked. I am aware that some will be tempted to comment out the test in question, but this is not a proper solution to this situation. Other apitest will crash in the future, bringing the whole thing back. Same as with regressions, lack of tests due to such issue, will bite us back in the future, when least expected and most needed. This is why I humbly request this issue to be solved properly, once and for all. With best regards ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Subject: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test Date: Tue, 14 Aug 2012 00:23:24 +0000 The Buildbot has finished a build on builder Windows_AMD64_1 VBox-Test while building ReactOS. Full details are available at: http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/6324 Buildbot URL: http://build.reactos.org/ Buildslave for this Build: Windows_AMD64_2 Build Reason: Triggerable(Windows_AMD64_1 VBox-Test Trigger) Build Source Stamp: 57075 Blamelist: akhaldi BUILD FAILED: failed Cleanup sincerely, -The Buildbot -- With best regards Caemyr

4 7

(no subject)
by saeid 10 Aug '12

10 Aug '12

i cant make the code

4 3

Re: [ros-dev] [ros-bugs] [Bug 6035] Abiword 2.8.6: confirmation messagebox without text
by thomas＠parker.iz34.com 09 Aug '12

09 Aug '12

http://www.reactos.org/bugzilla/show_bug.cgi?id=6035 hbelusca <hermes.belusca(a)sfr.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |terminedijs(a)yahoo.com -- Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Ros-bugs mailing list Ros-bugs(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-bugs

1 0

Re: [ros-dev] [ros-bugs] [Bug 6035] Abiword 2.8.6: confirmation messagebox without text
by thomas＠parker.iz34.com 09 Aug '12

09 Aug '12

http://www.reactos.org/bugzilla/show_bug.cgi?id=6035 --- Comment #7 from hbelusca <hermes.belusca(a)sfr.fr> 2012-08-09 14:02:29 CET --- According to Edijs, the confirmation message box isn't in top-most position with respect to the Abiword's window : [15:57:09] <Edijus> hbelusca: When save changes dialog appears, change focus to explorer or some other window. http://www.reactos.org/bugzilla/show_bug.cgi?id=6035 [15:57:26] <Edijus> hbelusca: Save changes dialog is not top most. Report it, please. :) [15:59:47] <hbelusca> Edijus: you mean that the confirmation message box of Abiword can "disappear" (ie. go behind another window) ?! [16:00:25] <Edijus> hbelusca: Yeah. Check if it reported or not, before reporting. [16:00:32] <Edijus> Thanks. -- Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. _______________________________________________ Ros-bugs mailing list Ros-bugs(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-bugs

1 0

Re: [ros-dev] [ros-diffs] [tfaber] 57044: [LIBTIFF] - Fix a warning
by Timo Kreuzer 08 Aug '12

08 Aug '12

Hmm, this is not 64 bit safe. Also I don't understand the modification. It doesn't look right. libtiff uses this differently: http://tiff.sourcearchive.com/documentation/4.0.0~beta4/fax2tiff_8c-source.… #if defined(_WIN32) && defined(USE_WIN32_FILEIO) TIFFSetClientdata(faxTIFF, (thandle_t)_get_osfhandle(fileno(in))); #else TIFFSetClientdata(faxTIFF, (thandle_t)fileno(in)); #endif And we don't even seem to use that function at all. Can anyone explain this? Am 04.08.2012 20:19, schrieb tfaber(a)svn.reactos.org: > Author: tfaber > Date: Sat Aug 4 18:19:19 2012 > New Revision: 57044 > > URL: http://svn.reactos.org/svn/reactos?rev=57044&view=rev > Log: > [LIBTIFF] > - Fix a warning > > Modified: > trunk/reactos/dll/3rdparty/libtiff/rosdiff.patch > trunk/reactos/dll/3rdparty/libtiff/tif_open.c > > Modified: trunk/reactos/dll/3rdparty/libtiff/rosdiff.patch > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/3rdparty/libtiff/rosdi… > ============================================================================== > --- trunk/reactos/dll/3rdparty/libtiff/rosdiff.patch [iso-8859-1] (original) > +++ trunk/reactos/dll/3rdparty/libtiff/rosdiff.patch [iso-8859-1] Sat Aug 4 18:19:19 2012 > @@ -7,7 +7,7 @@ > { > thandle_t m = tif->tif_clientdata; > +#ifdef USE_WIN32_FILEIO > -+ newvalue = (thandle_t) _get_osfhandle(newvalue); > ++ newvalue = (thandle_t)_get_osfhandle((int)newvalue); > +#endif /* USE_WIN32_FILEIO */ > tif->tif_clientdata = newvalue; > return m; > > Modified: trunk/reactos/dll/3rdparty/libtiff/tif_open.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/3rdparty/libtiff/tif_o… > ============================================================================== > --- trunk/reactos/dll/3rdparty/libtiff/tif_open.c [iso-8859-1] (original) > +++ trunk/reactos/dll/3rdparty/libtiff/tif_open.c [iso-8859-1] Sat Aug 4 18:19:19 2012 > @@ -517,7 +517,7 @@ > { > thandle_t m = tif->tif_clientdata; > #ifdef USE_WIN32_FILEIO > - newvalue = (thandle_t) _get_osfhandle(newvalue); > + newvalue = (thandle_t)_get_osfhandle((int)newvalue); > #endif /* USE_WIN32_FILEIO */ > tif->tif_clientdata = newvalue; > return m; > > >

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 57009: [NTOSKRNL] Try to fix crash detection in sysreg
by Timo Kreuzer 01 Aug '12

01 Aug '12

Hi I don't exactly know how testman is supposed to detect kernel crashes, by hope was that the crash detection failed, because of the strange characters at the beginning of the line, but that was obviously not the case. Can someone look into it and fix it, we are wasting a lot of testing time due to this. Thanks, Timo Am 31.07.2012 22:58, schrieb tkreuzer(a)svn.reactos.org: > Author: tkreuzer > Date: Tue Jul 31 20:58:37 2012 > New Revision: 57009 > > URL: http://svn.reactos.org/svn/reactos?rev=57009&view=rev > Log: > [NTOSKRNL] > Try to fix crash detection in sysreg > > Modified: > trunk/reactos/ntoskrnl/kdbg/kdb.c > > Modified: trunk/reactos/ntoskrnl/kdbg/kdb.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kdbg/kdb.c?rev=57… > ============================================================================== > --- trunk/reactos/ntoskrnl/kdbg/kdb.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/kdbg/kdb.c [iso-8859-1] Tue Jul 31 20:58:37 2012 > @@ -1472,12 +1472,12 @@ > > if (BreakPoint->Type == KdbBreakPointSoftware) > { > - KdbpPrint("Entered debugger on breakpoint #%d: EXEC 0x%04x:0x%08x\n", > + KdbpPrint("\nEntered debugger on breakpoint #%d: EXEC 0x%04x:0x%08x\n", > KdbLastBreakPointNr, TrapFrame->SegCs & 0xffff, TrapFrame->Eip); > } > else if (BreakPoint->Type == KdbBreakPointHardware) > { > - KdbpPrint("Entered debugger on breakpoint #%d: %s 0x%08x\n", > + KdbpPrint("\nEntered debugger on breakpoint #%d: %s 0x%08x\n", > KdbLastBreakPointNr, > (BreakPoint->Data.Hw.AccessType == KdbAccessRead) ? "READ" : > ((BreakPoint->Data.Hw.AccessType == KdbAccessWrite) ? "WRITE" : > @@ -1545,7 +1545,7 @@ > return kdHandleException; > } > > - KdbpPrint("Entered debugger on unexpected debug trap!\n"); > + KdbpPrint("\nEntered debugger on unexpected debug trap!\n"); > } > } > else if (ExceptionCode == STATUS_BREAKPOINT) > @@ -1560,7 +1560,7 @@ > return kdHandleException; > } > > - KdbpPrint("Entered debugger on embedded INT3 at 0x%04x:0x%08x.\n", > + KdbpPrint("\nEntered debugger on embedded INT3 at 0x%04x:0x%08x.\n", > TrapFrame->SegCs & 0xffff, TrapFrame->Eip - 1); > } > else > @@ -1574,7 +1574,7 @@ > return ContinueType; > } > > - KdbpPrint("Entered debugger on %s-chance exception (Exception Code: 0x%x) (%s)\n", > + KdbpPrint("\nEntered debugger on %s-chance exception (Exception Code: 0x%x) (%s)\n", > FirstChance ? "first" : "last", ExceptionCode, ExceptionString); > > if (ExceptionCode == STATUS_ACCESS_VIOLATION && > > >

1 0

MSVC build breakage
by caemyr＠myopera.com 31 Jul '12

31 Jul '12

Its been over a day since http://build.reactos.org/builders/CMake_x86_MSVCWin%20Debug/builds/1672 Can someone please fix it or revert the guilty revision? Thanks in advance -- With best regards Caemyr

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev