for this Build: Windows_AMD64_1
Build Reason: scheduler
Build Source Stamp: 56010
Blamelist: sir_richard
BUILD FAILED: failed building bootcd
sincerely,
-The Buildbot
--
Pierre Schweitzer pie...@reactos.org
Systems Administrator
ReactOS Foundation
smime.p7s
Description: S/MIME
Sysreg issue has been fixed today with r1381. New sysreg has been
already deployed on testbot.
This won't happen any more.
Le lundi 27 février 2012 à 19:24 +0100, Pierre Schweitzer a écrit :
This is due to an issue within both ReactOS and sysreg.
ReactOS appears not to boot any longer
messed up and
ran same tests several times;
Sorry for the issues caused by sysreg regression.
With my best regards,
--
Pierre Schweitzer pie...@reactos.org
Systems Administrator
ReactOS Foundation
smime.p7s
Description: S/MIME cryptographic signature
Hi,
to address an increasing ReactOS developers demand, you'll be able to
find regtest CDs used by KVM testbot at the URL:
http://iso.reactos.org/regtestcd/
I think I'll probably put the KVM testbot machine specifications on the
wiki to help as well.
Regards,
--
Pierre Schweitzer pie
,
-The Buildbot
--
Pierre Schweitzer pie...@reactos.org
Systems Administrator
ReactOS Foundation
smime.p7s
Description: S/MIME cryptographic signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
for this Build: Linux_AMD64_1
Build Reason: Triggerable(Linux_AMD64_1 KVM-CMake-Test Trigger)
Build Source Stamp: 55886
Blamelist: ion
BUILD FAILED: failed test
sincerely,
-The Buildbot
--
Pierre Schweitzer pie...@reactos.org
Systems Administrator
ReactOS Foundation
smime.p7s
Description: S
Feel free to revert.
At least, this removes an error message.
smime.p7s
Description: S/MIME cryptographic signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
. Its hardware was not able to properly handle a ReactOS
build, and was hardly upgradable.
Daily release builds should replace it any time soon.
With my best regards,
--
Pierre Schweitzer pie...@reactos.org
Systems Administrator
ReactOS Foundation
smime.p7s
Description: S/MIME cryptographic
Hey,
I won't handle this meeting. So, please contact Colin instead, he'll be
in charge of it.
Regards,
Pierre
Le mardi 21 février 2012 à 21:30 +0400, Aleksey Bragin a écrit :
Hello,
Let me invite you to the monthly status meeting taking place last
Thursday of this month, 23rd of February,
For the record, it also happens really often on KVM (see all the failed
tests recently).
Le mardi 21 février 2012 à 13:12 +0100, cae...@myopera.com a écrit :
Yet another CM fsckup:
*** Fatal System Error: 0x0019
(0x0005,0xE11FF880,0x00F0,0xE11FF798)
at
Hi,
due to popular request, a new ML is available (for read-only):
ros-builds. This ML will receive notifications sent by buildbot in case
of build breakge/tests breakage.
More notifications should be added any time soon.
For subscription, just go here:
Please, move this discussion to another thread.
Or at least, rename topic.
Thanks.
Le jeudi 16 février 2012 à 22:26 +0100, cae...@myopera.com a écrit :
Diablo (windows-based builder) is a 1st generation i7-920 with 12GB DDR3.
Building is done on SSD OCZ Vertex3, with storage on RAIDed Samsung
Hi,
looking into details shows that: ros-cis, ros-errors, ros-kernel,
ros-svn-diffs are already archived (no subscription is possible any
longer).
Only really remains ros-translate, ros-foundation.
Regards,
Pierre
Le mercredi 15 février 2012 à 00:49 +0400, Aleksey Bragin a écrit :
Hello,
Hi,
finally, we are getting closer and closer to CMake switch. RosBE-2.0
release brings supports for CMake and all the changes made in the tool
chain. You can find it here:
https://sourceforge.net/projects/reactos/files/RosBE-Unix/2.0/
To install it, simply extract the tar.bz2, and then run the
Hi,
I don't get the point in importing a 3rd party application which is
properly maintained into our code base. It's already big enough.
Adding a link to a binary in RAPPS sounds enough to me.
Regards,
Pierre
Le mercredi 01 février 2012 à 20:27 +0100, Javier Agustìn Fernàndez
Arroyo a écrit :
Hi,
On 01/27/2012 10:17 AM, Javier Agustìn Fernàndez Arroyo wrote:
* you may encounter stops at phase 2 at mshtml.dll
hasnt this been just (hack)fixed by Alex?
unfortunately, no.
Regards,
Pierre Schweitzer
smime.p7s
Description: S/MIME Cryptographic Signature
Hi,
a third release candidate of RosBE-Unix 2.0 is now available on
http://svn.reactos.org/RosBE-Temp/. Compared to second RC, it only comes
with changes to the installation script (letting you define more
precisely how you want to build it).
Once installed, it is the same RosBE that RC2.
Hi,
forgot to say in commit message that it also implements
RtlReleaseRelativeName
Regards,
Pierre
smime.p7s
Description: S/MIME cryptographic signature
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Le dimanche 15 janvier 2012 à 22:25 +, Andrew Faulds a écrit :
That actually redirects to:
http://download-eu.mozilla.org/?product=firefox-latest-euballotos=winlang=en-GB
which redirects to latest exe.
So we should use that URL. (removing the -euballot breaks it, it
seems, so it only
Hi,
with this mail, I propose we drop support for FireFox 2 releases in
rapps.
The motivation is crystal clear: with their new release plan, they are
releasing too often, and they don't maintain old links nor they provide
a symbolic link to latest version. So, FireFox links in rapps are too
Le dimanche 15 janvier 2012 à 16:51 +0100, Bernd Blaauw a écrit :
Op 15-1-2012 16:34, Andrew Faulds schreef:
Why not just drop support for FF entirely from rapps? I'd say better
no browser than a terribly outdated one.
If users want FF they can do this:
C:\ReactOS ftp
ftp open
Le dimanche 15 janvier 2012 à 18:16 +0100, Sven Barth a écrit :
At least on their high bandwidth FTP server releases.mozilla.org (see
the message when opening ftp.mozilla.org in a web browser) there is a
latest in their FireFox folder:
Le dimanche 15 janvier 2012 à 20:19 +0100, Bernd Blaauw a écrit :
Oops the link displayed by rapps includes a version number in the binary
instead of some
[ ftp://ftp.reactos.org/reactos/rapps/firefox-2in32.exe ]. Would it be
possible to replace the hosted binary by version 9.01 and create a
Le dimanche 15 janvier 2012 à 20:05 +0100, Sven Barth a écrit :
Btw: Mozilla wants to publish long term support releases in the next
time (based either on FF 8 or FF 9) which shall be supported around ~45
weeks. Maybe this will be a solution?
The main problem is not that they easily jump
Hi,
a second release candidate of RosBE-Unix 2.0 is now available on
http://svn.reactos.org/RosBE-Temp/. Compared to first RC, it comes with
CMake 2.8.7 (with Jérôme's patches), and binutils 2.22 (patched as
well).
Please try this BE and report any issues you may encounter. This will
help us to
Hi,
I've just sent the credentials for the coming meeting that will take
place in one hour.
The server will be brought up in 30 minutes. As usual, you'll be able to
find it at fezile.reactos.org port 6667. No SSL.
The meeting will be private, this means that if you don't have
credentials, you
Le lundi 19 décembre 2011 à 22:08 +1100, Adam a écrit :
So long as this isn't a blocker (ie. one can just use 128MB instead of
64MB to resolve this) then you may as well release it.
And when it doesn't work with 256MB, we try 512MB?
Your workaround appears not to work
Le lundi 19 décembre 2011 à 21:24 +0400, Aleksey Bragin a écrit :
On 19.12.2011 21:02, Cameron Gutman wrote:
The only problem I have with delaying the release is that we're getting
more and more out of date with Wine and some great patches are waiting on
the release. My vote would be to
Hi,
thanks for the report. Regarding first broken link, you should contact
Chinese language maintainer to report the issue.
Second broken link has been fixed. The change will be visible on next
doxygen generation (in ~ 5h).
Regards,
Pierre Schweitzer
Le vendredi 09 décembre 2011 à 03:11 +0800
Hi,
in case you were having issues for testing due to broken rapps links,
please retest now. They have been fixed.
Regards,
Pierre
Le mercredi 07 décembre 2011 à 00:40 +0400, Aleksey Bragin a écrit :
Hello testers,
your help is greatly needed.
Trunk needs to be tested using this template
19:00 UTC.
As usual: http://www.worldtimeserver.com/current_time_in_UTC.aspx
Regards,
Pierre
Le jeudi 01 décembre 2011 à 09:27 +0100, Javier Agustìn Fernàndez Arroyo
a écrit :
19.00 or 20.00 ?
On Thu, Dec 1, 2011 at 9:17 AM, Aleksey Bragin alek...@reactos.org
wrote:
A reminder that
Hi,
the credentials for the coming meeting have been sent. Please check your
reactos.org mail address to find them.
In case you didn't received them whereas you should, please contact me
as soon as possible.
Please check they work BEFORE the meeting starts. Otherwise it won't be
possible to
Server is finally online, after routing issues.
Le jeudi 01 décembre 2011 à 19:19 +0100, Pierre Schweitzer a écrit :
Hi,
the credentials for the coming meeting have been sent. Please check your
reactos.org mail address to find them.
In case you didn't received them whereas you should
for the disturbance.
Regards,
Pierre
On 11/27/2011 10:08 PM, Pierre Schweitzer wrote:
Hi,
due to connectivity issues with our servers in Sweden, I've taken our
rbuild debug buildslave our KVM testbot offline.
This doesn't affect ISOs storage for the moment.
Regards,
Pierre
Hi,
finally, everything is back to normal.
Sorry about that.
Regards,
Pierre
On 11/28/2011 01:18 PM, Pierre Schweitzer wrote:
Hi,
a side note: as one builder one tester are offline, and ISO storage
could be affected (ie, ISOs might not be delivered), I would HIGHLY
recommend that you
Let's please stop this drama. It won't bring anything good in the project.
I wouldn't like to see people leaving the project or questioning their
involvement in it. Especially for two constants change.
Eric motivated its changes. Olaf, you motivated your (and perhaps
others) grievances.
The
Hi,
due to connectivity issues with our servers in Sweden, I've taken our
rbuild debug buildslave our KVM testbot offline.
This doesn't affect ISOs storage for the moment.
Regards,
Pierre
___
Ros-dev mailing list
Ros-dev@reactos.org
Hi Eric,
this sounds good! Once you'll be done with it, I'll go through GPT test
to see if this has fixed the FstubEx GPT backup table issue.
Thank you!
Regards,
Pierre
Le lundi 21 novembre 2011 à 23:17 +0100, Eric Kohl a écrit :
Hi!
I plan to change the standard harddisk geometry from the
Hi,
those will be sent to the concerned people before the meeting begins.
Regards,
Pierre
Le mardi 22 novembre 2011 à 20:13 +0400, art1st...@yandex.ru a écrit :
I need the creditals
22.11.11, 19:16, Aleksey Bragin alek...@reactos.org:
Usual clarification, everyone from the team is
Hi,
we are glad to announce you that the Linux debug build slave has been
successfully relocated and is now completely back online.
Regards,
The ReactOS Sysadmins.
Le jeudi 20 octobre 2011 à 22:27 +0200, Pierre Schweitzer a écrit :
Hi,
the Linux build slave will be relocated (changing data
Hi,
the Linux build slave will be relocated (changing data center country)
starting tomorrow. It will, obviously, be offline during the meantime.
So, you will not have any Linux builds nor KVM tests.
We will do our best to get it back online as soon as possible.
Regards,
The ReactOS Sysadmins.
I've just run the said test. As you can see, no real difference:
http://img155.imageshack.us/img155/3831/debugdiablo.png
Le mardi 04 octobre 2011 à 18:53 +0200, Pierre Schweitzer a écrit :
Hi,
Le mardi 04 octobre 2011 à 18:49 +0200, Bernd Blaauw a écrit :
Did that test machine also choke
Hi,
answering inlined.
Le jeudi 29 septembre 2011 à 23:06 +0200, Matthias Kupfer a écrit :
- Hudson for automatic build and checking the source (see below)
Instead of using hudson, we're using buildbot here.
- cpplint.py (by Google) for some checking the source
I didn't know that tool, I
Hi,
today, after looking at the daily source analysis we have, I found out
that all that stuff could be improved by lightening trunk. We have huge
amount of unused code (even not linked in CMake) rotting in trunk.
I'm mainly talking about icu4ros. AFAIK it was an attempt from KJK for I
even don't
Hi,
small note to inform people who were having issues connecting to secured IServ
services due to wrong SSL certificate (issued for the wrong address) that the
certificate has been renewed today and the issues are gone.
Regards,
Pierre
___
Ros-dev
)
- Daniel Reimer (dreimer)
- Pierre Schweitzer (HeisSpiter)
- Samuel Serapion (encoded)
- Olaf Siejka (Caemyr)
- James Tabor (jimtabor)
- Christoph von Wittich (Christoph_vW)
- Art Yerkes (arty)
WBR,
Aleksey Bragin.
___
Ros-dev mailing list
Hi,
same thing that for r53402, but with structure: RPC_SID.
Cf: http://doxygen.reactos.org/d5/df6/structRPC__SID.html
Regards,
Pierre
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Hi,
There are no changes in the logic, it's just to avoid a crash
(internal compiler error: in vect_transform_stmt, at
tree-vect-stmts.c:4887). It's only in GCC versions 4.6.x.
I really don't get the logic behind the commit.
GCC is not supported yet by any of the BEs. Which implies that
FAT CDFS FSDs are not supposed to handle IRP_MN_KERNEL_CALL.
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Thanks for being that efficient for reverting.
Less than two days after message on ML. Congratz.
Next time I take days off, I won't take four days any longer, in case you would
question some other of my patches.
I'll also send you my next patches, that way you'll be able to commit them, or
just
Development List ros-dev@reactos.org wrote on Mon, June 6th, 2011,
8:35 PM:
Am 06.06.2011 19:06, schrieb Pierre Schweitzer:
Finally addressed in r52117.
Thanks!
Oops, looks like I reverted it :D
No, seriously: please read the discussion about this to the end.
Timo
Finally addressed in r52117.
Thanks!
ReactOS Development List ros-dev@reactos.org wrote on Fri, June 3rd, 2011,
1:24 PM:
Ah, I didn't see the caller.
There's still the issue of the missing volatile. It's required to make sure
there is strict ordering between the spinlock acquisition and
Hi,
The notification routine can change the list, as there is no lock involved.
List is locked by the caller. Have a look to: IoRegisterFsRegistrationChange().
Regarding all your remarks: thank you! They have been used to fix code and
commited in r52073.
Regards,
P. Schweitzer
Here, IPMI is a correct answer as well ;-).
ReactOS Development List ros-dev@reactos.org wrote on Thu, May 26th, 2011,
8:13 AM:
A KVM adapter or switch is what you're after for 'some sort of pre-BIOS
control system to be able to control it booting, shut-down and turn on from
the internet'
Okay guys...
Enough of it, not need to give such an image of the ReactOS project.
Victor, you've already been said several times (and not from Olaf only) that
some of your bug reports were lacking consistency, details, interest, whatever.
Or even some of your answers (let's think about bug
Participants
Adam Stachowicz
Aleksey Bragin
Amine Khaldi
Art Yerkes
Daniel Reimer
Gabriel Ilardi
Ged Murphy
Giannis Adamopoulos
Gregor Schneider
Hervé Poussineau
James Tabor
Javier Agustìn Fernàndez Arroyo
Johannes Anderwald
Maciej Białas
Matthias Kupfer
Olaf Siejka
Pierre
Kupfer (Collibri)
- Michael Martin (mjmartin)
- Victor Martinez (vicmarcal)
- Roel Messiant (Mephisto)
- Andrew Munger (WaxDragon)
- Ged Murphy (GedMurphy)
- Sylvain Petreolle (Usurp)
- Hervé Poussineau (hpoussin)
- Daniel Reimer (dreimer)
- Pierre Schweitzer (HeisSpiter)
- Samuel
Hi
After poking around more it is mentioned that plugplay storage
stack will be needed. which I'm guessing is no small task.
I would have liked to make a proposal to do it the proper way.
is there anyone who can tell me what plugplay storage stack would take?
Having a PnP storage stack
Hi,
both doxygen.reactos.org iso.reactos.org are down (which results in daily
builds isos not being uploaded).
Anyone able to fix them?
Regards,
P. Schweitzer
___
Ros-dev mailing list
Ros-dev@reactos.org
Hi and welcome here Guillaume,
the background you bring with you here just sounds really promising.
If you are interested in kernel security, you may also have a look to the
KSecDD driver which also provides security components at kernel mode level. You
can find some information in the paper
To those who may have missed the commit, I finally applied that idea:
For the rest, I had an other idea, to complete the changes you talked about:
getting the HAL entry point out of the libs.
It's working quite good. And doesn't force to rebuild the whole lib. HAL MP
entry point has now the
currently working on HAL and HAL targets (ACPI, MP, UP and so on), I
discovered a quite bad issue in our build process.
Just look at the function HalInitSystem@8 (halinit.c), depending on the
build target we don't add the same code (look at CONFIG_SMP, which is only
defined for HAL
Nice impressive work :-).
Thanks for your involvement!
___
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Hi,
currently working on HAL and HAL targets (ACPI, MP, UP and so on), I discovered
a quite bad issue in our build process.
Just look at the function HalInitSystem@8 (halinit.c), depending on the build
target we don't add the same code (look at CONFIG_SMP, which is only defined
for HAL MP).
Hi,
mIRC has already been discovered as a prominent failing application,
which just crashes upon connecting (see
http://www.reactos.org/bugzilla/show_bug.cgi?id=6005). I consider this a
release blocker bug, so some networking guy should look at it.
IIRC, it was working *not that long*
It's time to get serious
Then, rewrite the whole algorithm. Adding things that are already done is just
pointless. Mixing styles, algorithms is also pointless, not to say hazardous.
Being serious is also communicating with the code authors before thinking you
know better than them.
Being
Hi,
this commits just shows you didn't understand how that function works. If you
had, you wouldn't have said:
- Implement parameters checking in FsRtlIsNameInExpressionPrivate.
It's already done.
- Add two shortcuts for common wildcard invocations to make the function
faster.
If you look at
Some more information:
guilty rev seems to be r50851 (?!).
infinite loop in backtrace appears at the same place.
Those lines are also repeated periodically in the backtrace:
ntoskrnl.exe:1896a3 (lib/sdk/crt/math/i386/pow_asm.s:33 (wstreamout))
ntoskrnl.exe:189a03
Hi,
this debug wasn't supposed to be silent as it highlights a quite crappy
situation in ReactOS. And that's even what one would call: a hack.
That way, you could also silence IopParseDevice hack debug...
At least, you could have asked the author, I'm not that unreachable ;-).
Regards,
P.
End of monologue:
r50853 of James seems to have fixed the crash. Still that backtrace loop looks
quite weird to me...
Regards,
P. Schweitzer
Some more information:
guilty rev seems to be r50851 (?!).
infinite loop in backtrace appears at the same place.
Those lines are also repeated
Then, just remove the DPRINT.
Still, you could ask me ;-).
The correct way is to raise a bug and put a comment in the code with the
corresponding bug number.
This way it's always tracked and anyone who stumbles upon it when reading
the code can get information easily.
It doesn't seem to be
Hi,
I'd like to come back to this and suggest a procedure:
1. Officially announce feature freeze.
2. Address patches in bugzilla. we have 31 patches in bugzilla and we
should have each of them reviewed and hopefully a lot comitted.
3. Address regressions. We have 47 (!!!) bugs marked as
Hi,
recently amount of new features added to the trunk decreased, and
there were quite a lot of bugfixes coming in. In my opinion, it is a
very good time for a release. After release is branched, it would be
possible to sync wine shared code and continue with other changes.
Agreed.
Hi,
this is a bit tricky, but it is the way it works.
In case you still have doubts, enjoy that C program. You will never reach the
memset:
#include assert.h
#include string.h
void test_sizeof(unsigned long test[4], char c) {
assert(sizeof(test) == (4 * sizeof(unsigned long)));
Hi,
Whilst parts of our kernel try to target 5.2 changes, from a testing
perspective it should be
pretty much identical to 5.1.
IMO, unless you're a kernel dev interested in implementing some of the more
elegant kernel
features in 5.2, then anyone with a 5.1 box is more than adequately
For my information??
You need to start your sentences a little more politely
Wasn't aware it was that impolite (cf:
http://www.businessdictionary.com/definition/for-your-information-FYI.html).
So, s/For your information/If I may bring that point to you Sir.
You're talking about testing
Hi,
our main target is w2k3, so this is quite logical to use it.
I know user-mode may target any Windows release, but in such case, I guess that
more devs have some Windows 7 running than a w2k3. So, testing user-mode stuff
is quite easy. Kernel-mode tests are really harder.
Then, as I already
Indeed, explanations would be welcome.
James, talking about the issue would help addressing it.
Regards,
P. Schweitzer
Uuuh, what?
Can someone explain this comment?
___
Ros-dev mailing list
Ros-dev@reactos.org
Hi,
Author: cgutman
Date: Tue Dec 21 04:35:12 2010
New Revision: 50077
URL: http://svn.reactos.org/svn/reactos?rev=50077view=rev
Log:
[USBDRIVER]
- Fix a bug that resulted in us only copying half of the old keyboard data
- CID 10402
Modified:
Hi,
anyone (ie Colin or Christoph?) knows what's wrong with testbot? Since r49761
it can't reach 2nd stage more. This revision has been reverted in r49767 but
testbot keeps being broken. Any clue?
Regards,
P. Schweitzer
___
Ros-dev mailing list
Hi,
most of the justifications for r49691 have been included in the commit message.
But here are needed addings.
Olaf made buildbot rebuild r49662 and retest it. Testbot manages to pass 3rd
stage and to run tests. Then, Olaf retried with r49665, and it failed the same
way it was failing
And to prove that work wasn't that useless, testman finally has some tests for
last rev: http://www.reactos.org/testman/
But due to the issues described in previous mail, many have failed.
As it seems ros-diffs won't do its duty for that revision:
Hi,
finally this commit won't be reverted (unless someone explicitly asks for it)
as it brings testman back and shows quite important bugs.
Feel free to find a nice bugfix instead.
WBR,
P. Schweitzer
___
Ros-dev mailing list
Ros-dev@reactos.org
Hi,
I know that r49463 only added INIT_FUNCTION to HAL, but I reverted both, just
to be sure. I can get back ntoskrnl as they don't seem to be concerned.
Now, on other remarks, considering that:
- This has never be presented as a fix (but as a test)
- Win32k INIT_FUNCTION is not defined for GCC
Who the hell do you think you are?! The day I'll need lesson, don't worry I
know who you are and where to find you.
I won't waste my time answering. Understand whatever you want, imagine whatever
you want.
Just for your information:
Hi,
GCC is a compiler. CMAKE is a build system we use with... GCC (for the moment).
So no point in the question.
Best regards,
P. Schweitzer
...and what about cmake?
´cos we are moving from gcc to cmake
On Sat, Nov 13, 2010 at 7:44 PM, Colin Finck m...@colinfinck.de wrote:
Sven
I find combination of words Maya, project and active highly hilarious.
2010/9/14 Adam Kachwalla geekdun...@gmail.com
I'm sure Maya Posch has a highly active project called the ReactOS
Synthesis Project (http://sourceforge.net/projects/reactos-synth/) which
is supposed to patch a
Pierre Schweitzer wrote:
Hi,
while working on GPT handling for ReactOS, one thing appeared: Microsoft
(at least in Windows 2003 SP1) is using hardcoded partition entry size, ie
it assumes that every partition entry in GPT will be 128 bytes big. Even if
that assertion is largely right
Hi,
while working on GPT handling for ReactOS, one thing appeared: Microsoft (at
least in Windows 2003 SP1) is using hardcoded partition entry size, ie it
assumes that every partition entry in GPT will be 128 bytes big. Even if that
assertion is largely right, it might exist cases where it's
Hi!
Could you define how/why 2nd stage doesn't boot on your side?
With my rewritten ARC names handling, your patch brokes absolutely nothing. I
just successfully installed ReactOS.
Let me know if you want a patch to test your issue on your side.
Best regards,
P. Schweitzer
Hi!
This patch
Hi,
I just rerun a testcase using two 1024MB partitions on a 2GB disk. Both were
formatted to FAT32 using UBCD. Install worked (in spite of an error message
when displaying partitions list), 2nd stage as well, and finally 3rd stage too.
Perhaps is that due to my changes, I dunno. Could you try
Pushing the question (which was the real question in Ionescu's mail...).
http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-assembler/i386-syntax.html
Best regards,
Pierre
PS: Nice to see you back Alex ;).
What was the reason for the change?
It would be preferable to keep
To be more accurate, it appears it broke DNS resolution.
Could you please stop committing untested patches? This would help trunk going
better.
TYA
It looks like this change has caused some regressions in sysreg
http://www.reactos.org/testman/compare.php?ids=3934,3935
Selling Free Open Source Software... You'll go far in your life without a doubt!
Btw, small quote read on AndLinux website, you should think about it: You may
not sell andLinux, but are welcome to distribute it freely.
___
Ros-dev mailing list
Exactly!
Date: Fri, 17 Jul 2009 23:01:25 +0200
From: janderw...@reactos.org
To: ros-dev@reactos.org
Subject: [ros-dev] To all gurus out there
Hello,
It seems to have been come a ReactOS tradition, that every 2 / 3 weeks
somebody turns up on the mailing list and shows her / his
201 - 295 of 295 matches
Mail list logo
