Sunday night I will remove the svn.reactos.com DNS entry, please use
svn.reactos.org in the future. If you currently have a working copy checked
out from svn://svn.reactos.com you can tell svn to use svn.reactos.org in
the future by:
> From: WaxDragon
>
> Say you have a checkout in ~/src/reactos that was originally checked
> out from svn://svn.reactos.com/trunk/reactos. from the root of the
> checkout (~src/reactos) issue:
>
> svn switch --relocate svn://svn.reactos.com/trunk/reactossvn://svn.reactos.org/trunk/reactos
If you're using Tortoise:
> From: Maarten Bosma
>
> Just right click in root dir, chosse "TortiseSVN > Relocate..." and then
> enter svn://svn.reactos.org/trunk/reactos into the dialog.
Or if you have no local changes you could just delete your working copy and
check out a new one from reactos.org.
If you insist on using svn.reactos.com, add a line "213.173.252.2
svn.reactos.com" to your hosts file (/etc/hosts for Linux/Unix,
%SystemRoot%\System32\drivers\etc\hosts on Windows).
Gé van Geldorp.
gedmurphy(a)svn.reactos.org wrote:
> + CONTROL "Automatically synchronize with an Internet time server", IDC_AUTODAYLIGHT,
> + "Button", BS_AUTOCHECKBOX | WS_GROUP | WS_TABSTOP,11,7,241,10
>
oops, ignore the IDC_AUTODAYLIGHT typo, I'll fix it when I get round to
putting the rest of the code in :)
Ged.
Does anyone mind if I import libjpeg for jpg support ? The License is
not a problem, but the patent might be. Sorry that ask so late (did
already a vendor import). I asked 2 times on IRC and thought that would
be enough, but GreatLord convinced me that I have to asked here too.
Maarten Bosma
PS: The size of the files that would go into reactos/lib is 694 KB.
A while ago, when it was mentioned that ROS 2.9 is soon to be released I
proposed to put out a VMWare image of it - never got a reply though, or
missed it. It has been mentioned multiple times that VMWare is used by some
ROS-devs, so this shouldn't be a problem in the first place.
Since the authors of VMWare have released a so-called VMWare-Player (see
http://www.vmware.com/products/player/ ), it is easy for anyone to get both
(given that they don't have VMWare, yet). VMWare is certainly faster than
QEMU or Bochs for several reasons and thus would be a better "experience"
for potential ROS testers and users.
And please don't tell me that is a kind of endorsement of VMWare, since the
link on the website already is. There is at least one (much cheaper)
alternative to VPC and VMWAre, called Parallels which is not mentioned on
the website at all ( http://www.parallels.com/en/products/workstation/ ).
I just wanted to remind all of you of this idea for (re)consideration.
Cheers,
Oliver
Hi,
I've fixed Alex' win32k changes. First, I try to commit the original
changes. I've used 'svn merge -r20366:20368
svn://svn.reactos.org/trunk/reactos' to get the changes and I'm using
'svn commit' to commit the changes again. I get an error message:
I:\Sandbox\ros_work\reactos>svn commit
Lösche include\win32k\bitmaps.h
<snip>
Sende w32api\include\wingdi.h
Übertrage Daten ................svn: Übertragen fehlgeschlagen (Details
folgen):
svn: Source url
'svn://svn.reactos.org/trunk/reactos/include/win32k/ntgdibad.h' is from
different repository
svn: Ihre Log-Meldung wurde in einer Temporärdatei abgelegt:
svn: 'I:/Sandbox/ros_work/reactos/svn-commit.2.tmp'
Usually, I get all error messages in german. What do I make wrong?
- Hartmut
ion(a)svn.reactos.org wrote:
> + /* Value changed... wait until it's locked */
> + while (*SpinLock == 1) YieldProcessor();
This might be optimized away since SpinLock was not defined as volatile
KSPIN_LOCK*
- Thomas
greatlrd(a)svn.reactos.org wrote:
> some case from win32k can call to RtlClearAllBits with NULL pointer. and check for null pointer after RtlClearAllBits. This take care of those case for moment.
This change is wrong, please revert it and fix win32k instead.
- Thomas
ion(a)svn.reactos.com wrote:
> - Also made the boot-up screen black, not blue, since that's the actual color it's been after NT4. If booting without NOGUIBOOT, this results in a much nicer transition to the boot screen (especially if using the NTLDR theme)
>
This changes the 'blue screen of death' to a 'black screen of death'. I
don't like it if you change every and any thing to the real windows
implementation. I see no reason for this cloning.
- Hartmut
Why was this done? Having these bugs listed as blockers to 399 allows
devs to find the old bugs easier in case of regressions. I don't see
any downsize to keeping them listed.
On 12/28/05, ReactOS.Bugzilla(a)reactos.org <ReactOS.Bugzilla(a)reactos.org> wrote:
> http://www.reactos.org/bugzilla/show_bug.cgi?id=399
>
>
> greatlord(a)reactos.com changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> BugsThisDependsOn|398, 400, 937 |
>
>
>
>
> ------- Additional Comments From greatlord(a)reactos.com 2005-12-28 17:54 CET -------
> Bug 398 are fixed, Bug 400 are fixed, Bug 937 are fixed
> I remove tuse from Bug depends on.
>
>
>
> --
> Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
> You are the QA contact for the bug, or are watching the QA contact.
> _______________________________________________
> Ros-bugs mailing list
> Ros-bugs(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-bugs
>
WD
--
<Russell> argh
<Russell> iterator shenanigans :/