Ros-dev

ros-dev@reactos.org

5789 discussions

by caemyr＠myopera.com

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

12 years, 8 months

Fwd: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test

by caemyr＠myopera.com

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

12 years, 8 months

(no subject)

by saeid

i cant make the code

12 years, 8 months

Re: [ros-dev] [ros-bugs] [Bug 6035] Abiword 2.8.6: confirmation messagebox without text

by thomas＠parker.iz34.com

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

12 years, 8 months

Re: [ros-dev] [ros-bugs] [Bug 6035] Abiword 2.8.6: confirmation messagebox without text

by thomas＠parker.iz34.com

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

12 years, 8 months

Re: [ros-dev] [ros-diffs] [tfaber] 57044: [LIBTIFF] - Fix a warning

by Timo Kreuzer

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; > > >

12 years, 8 months

Re: [ros-dev] [ros-diffs] [tkreuzer] 57009: [NTOSKRNL] Try to fix crash detection in sysreg

by Timo Kreuzer

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 && > > >

12 years, 8 months

MSVC build breakage

by caemyr＠myopera.com

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

12 years, 8 months

First Contract Issued

by Zachary Gorden

The ReactOS Project is proud to announce the first of the development contracts that will be funded by the recent donation campaign. Edijs Kolesnikovics joined the ReactOS development team very recently and has been working extensively with Amine Khaldi and Olaf Siejka to create an application test suite based around the AutoHotkey (AHK) automation system. AutoHotkey is a tool for scripting keyboard and mouse actions in order to automate running of programs on Windows. While the current test suites exercise a considerable amount of functionality, the true test for ReactOS remains when it is used to run applications. As such, Edijs has been working to create tests using AHK to run a variety of applications, starting with those on the Golden Apps list. The basic framework is already in place along with a few tests, but much more can be done to expand the selection of applications tested. As such, the Foundation has elected to grant Edijs a development contract to develop additional tests. The project congratulates Edijs on a job well done so far, and would also like to thank Amine, Olaf, and the AHK developers for their help mentoring and advising Edijs. Contract Details Time: 84 hours minimum Wage: €168 Expected Duration: 1 month Objective: Within the designated time period, develop as many AHK test scripts for applications to be used with the automated regression testing as possible. The intended goal is to have at least all remaining Golden Apps testable. This project seeks to help developers catch regressions more quickly so that stabilizing ReactOS for releases becomes less time consuming. This task will be monitored by Amine Khaldi. Sidenote: Due to a variety of circumstances unrelated to the donation campaign, Edijs' contract wage is significantly lower than what would be the standard contract wage for the project.

12 years, 8 months

Re: [ros-dev] [ros-diffs] [akhaldi] 56973: [CLASSPNP] * Explicitly mark the functions as stdcall (NTAPI).. -mrtd changes the default calling convention, but name-decoration isn't affected by this. The -mrtd feature has its ...

by Timo Kreuzer

While this works for us, we should consider trying to get this feature back. When it's considered for removal, then they obviously "fixed" something now that noone needs (and that makes absolutely no sense at all), while the feature as it was before is very useful to compile 3rd party code for Windows. One possibility (since we compile gcc ourselves anyway), is finding out where they "fixed" it and revert that revision for our builds. If they completely remove it, we rename the option and send the old code in as a new feature for MSVC compatibility ;-) Am 29.07.2012 03:49, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Sun Jul 29 01:49:24 2012 > New Revision: 56973 > > URL: http://svn.reactos.org/svn/reactos?rev=56973&view=rev > Log: > [CLASSPNP] > * Explicitly mark the functions as stdcall (NTAPI).. -mrtd changes the default calling convention, but name-decoration isn't affected by this. The -mrtd feature has its origin in some older linux-code-mode, and it's considered for removal in GCC 4.8. > * Fix some warnings. > > Modified: > trunk/reactos/drivers/storage/classpnp/CMakeLists.txt > trunk/reactos/drivers/storage/classpnp/autorun.c > trunk/reactos/drivers/storage/classpnp/class.c > trunk/reactos/drivers/storage/classpnp/classp.h > trunk/reactos/drivers/storage/classpnp/classwmi.c > trunk/reactos/drivers/storage/classpnp/clntirp.c > trunk/reactos/drivers/storage/classpnp/create.c > trunk/reactos/drivers/storage/classpnp/dictlib.c > trunk/reactos/drivers/storage/classpnp/lock.c > trunk/reactos/drivers/storage/classpnp/obsolete.c > trunk/reactos/drivers/storage/classpnp/power.c > trunk/reactos/drivers/storage/classpnp/retry.c > trunk/reactos/drivers/storage/classpnp/utils.c > trunk/reactos/drivers/storage/classpnp/xferpkt.c >

12 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev