All is down!
> Fixed.
>
> On 15/06/2014 00:56, Alexander Rechitskiy wrote:
>
>> https://code.reactos.org/ does NOT work
>> 15.06.2014, 02:40, "Pierre Schweitzer" <pierre(a)reactos.org>:
>>> As a side note, upgrade to Fisheye 3.4.4 didn't fix ONLINE-461 (which was the
>>> main reason behind the upgrade).
>>>
>>> On 15/06/2014 00:36, Zachary Gorden wrote:
>>>> Fisheye was upgraded successfully, Jira went off the rails and took us
>>>> about three hours to recover from. Please report any data loss as we had to
>>>> restore from backups.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ros-dev mailing list
>>>> Ros-dev(a)reactos.org <mailto:Ros-dev@reactos.org>
>>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>>>
>>> --
>>> Pierre Schweitzer<pierre at reactos.org>
>>> System Administrator
>>> ReactOS Foundation
>>> ,
>>>
>>> _______________________________________________
>>> Ros-dev mailing list
>>> Ros-dev(a)reactos.org <mailto:Ros-dev@reactos.org>
>>> http://www.reactos.org/mailman/listinfo/ros-dev
>>>
>> --
>> Best regards,
>>
>> _______________________________________________
>> Ros-dev mailing list
>> Ros-dev(a)reactos.org
>> http://www.reactos.org/mailman/listinfo/ros-dev
>
> --
> Pierre Schweitzer<pierre at reactos.org>
> System Administrator
> ReactOS Foundation
--
--
Best regards,
Fisheye was upgraded successfully, Jira went off the rails and took us
about three hours to recover from. Please report any data loss as we had to
restore from backups.
This helps find logic errors, mostly where the programmer thought the
variable was signed but it's actually unsigned, e.g. if (ret < 0) for a
function that returns (ULONG)-1.
I also don't see how the fix would be complicated in most cases.
(x <= 0) becomes (x == 0), (x < 0) becomes (x == (ULONG)-1) or whatever
(after a logic review).
I know that it'll be problematic if resulting from a macro... but I
think it's worth finding a workaround for those cases.
Most of the warnings I remember from our code base though (especially
ntoskrnl) didn't involve macros and were actually cases of questionable
logic... although maybe I recall incorrectly.
On 2014-05-31 23:26, tkreuzer(a)svn.reactos.org wrote:
> [CMAKE] Get rid of -Wtype-limits, it's noisy, it doesn't provide any reasonable benefit and it's almost impossible to "fix" these warnings without huge haxxory.
Hello,
Let me invite you to the monthly status meeting taking place first
Thursday of this month, 5th of June, 19:00 UTC. And this date is very
close to now! The meeting was rescheduled from the usual date because of
my trips and my illness. Sorry about that.
IRC service will only be started shortly before the meeting. Your
participation passwords and server address 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 Pierre before the meeting started to get one.
Please send agenda proposals to me before the meeting, so that we can
start with a proposed agenda. However the most demanded topic is ReactOS
fundraising campaign and its outcome :-)
Also all developers, please, may I so kindly ask you to prepare a very
brief one-two lines message containing two things:
1. What you did since the previous meeting
2. What you are going to do in the coming month
This is needed to understand who is working on what, to plan things,
etc. Thanks, I hope it's not that much to ask for.
Regards,
Aleksey Bragin
Hi,
I'm working on network virtualization support in ReactOS.
At this time, PoC works but I reach a point where I need a solution that would allow to add and remove TAP (TAP-Win32 from OpenVPN for exemple) Network Devices from kernel space, without user intervention.
The problem right now is that there seems to be impossible in ReactOS to have a proper way or tips and tricks to add/remove TAP devices without rebooting the system. What should be fixed/edit to instanciate of TAP device on the fly on the current implementation (r63193) ?
Thanks
--
Daniel Maxime
Linux version 3.6.9-maxux64 (emy) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) ) #3 SMP PREEMPT Wed Feb 19 16:40:22 CET 2014
17:15:01 up 1 day, 1:44, 1 user, load average: 0.29, 0.28, 0.35
On 2014-05-20 23:11, tkreuzer(a)svn.reactos.org wrote:
> --- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] Tue May 20 21:11:43 2014
> @@ -4593,8 +4593,8 @@
> // on the user input, and then compute the actual region size once all the
> // alignments have been done.
> //
> + EndingAddress = (((ULONG_PTR)PBaseAddress + PRegionSize - 1) | (PAGE_SIZE - 1));
> StartingAddress = (ULONG_PTR)PAGE_ALIGN(PBaseAddress);
> - EndingAddress = (((ULONG_PTR)PBaseAddress + PRegionSize - 1) | (PAGE_SIZE - 1));
> PRegionSize = EndingAddress - StartingAddress + 1;
>
> //
Can you explain this a bit? I don't see any logic change.
>[LSASRV]
>
>- Just run again the loop if LsarOpenAccount call failed (that also
>avoids a call to LsarClose on a NULL handle, that is trapped by the
>kdbg if one enabled "set condition * first always").
>
>- Free the memory and the opened handles before returning in case of
>failure of LsapAddPrivilegeToTokenPrivileges. Maybe this cleaning step
>can be done more elegantly.
>
>Eric, can you please review that? It should be good I think.
The change is OK!