Hi all,
Today, the motherboard in our Fezile server has finally failed after
many hick-ups over the year. This causes an outage for the following
services:
* doxygen.reactos.org
* cppcheck.reactos.org
* VMware Player Test slave
* VMware Player Patchbot
As this is not the first time we struggle with such problems,
iso.reactos.org is routed to a different server right now and not affected.
We have already ordered replacement hardware for this system and hope to
be able to get it back to a working state soon. Even if this machine is
from 2007, we have decided to revive it with replacement parts instead
of going for a brand-new one as this is much cheaper and quicker to
realize. Also there is a huge pile of replacement hardware available.
Sorry for the inconveniences!
Cheers,
Colin
On 2014-12-15 22:07, hbelusca(a)svn.reactos.org wrote:
> +1 stub -noname ShellGetUserList ; (long long long)
For future reference, you might as well write this kind of thing as
1 stdcall -stub -noname ShellGetUserList(long long long)
Then spec2def will create a stub that uses the correct calling
convention and also prints out the arguments. Plus it's easier to
change to the real thing when someone implements it ;)
On 24/01/2015 01:15, hbelusca(a)svn.reactos.org wrote:
> ==============================================================================
> --- trunk/reactos/tools/cdmake/dirhash.c [iso-8859-1] (original)
> +++ trunk/reactos/tools/cdmake/dirhash.c [iso-8859-1] Sat Jan 24 00:15:08 2015
> @@ -138,12 +138,14 @@
> hashcode = djb_hash(targetnorm);
> de = calloc(1, sizeof(*de));
> de->parent = parent_de;
> + de->head = NULL;
> + de->child = NULL;
de has been allocated few lines upper with calloc.
head & child CANNOT be different from NULL.
This is non sense.
> @@ -170,6 +172,7 @@
> tf->target_name = strdup(chop_filename(target));
> }
>
> +#if 0
> static struct target_dir_entry *
> dir_hash_next_dir(struct target_dir_hash *dh, struct target_dir_traversal *t)
> {
> @@ -200,13 +203,13 @@
> return t->it;
> }
> }
> +#endif
Once again, this is trunk, not your working copy.
If you 0 out, please add a comment explaining it's just unused and not
buggy.
And actually, because it's trunk & unusued, it would be better just to
remove them. svn history can help finding them back if really needed.
> ==============================================================================
> --- trunk/reactos/tools/cdmake/dirhash.h [iso-8859-1] (original)
> +++ trunk/reactos/tools/cdmake/dirhash.h [iso-8859-1] Sat Jan 24 00:15:08 2015
> @@ -26,11 +26,13 @@
> struct target_dir_entry root;
> };
>
> +#if 0
> struct target_dir_traversal
> {
> struct target_dir_entry *it;
> int i;
> };
> +#endif
See comment above.
Cheers,
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Hi all,
We're still preparing merchandising products for FOSDEM, and flyers are
probably most important here and still doable in time.
Can somebody please take the template from
https://svn.reactos.org/press-media/trunk/Events/2009%20-%20FOSDEM/Flyer/ and
alter it a bit to reflect current ReactOS state?
The best would be a flyer not including a certain ReactOS version
number, so that it is universally usable.
If you don't have InDesign to modify the file, just send me the modified
text here.
Thanks!
Colin
Dear all,
Just to make sure you read it: https://www.reactos.org/node/928
The SVN accounts are not affected.
Cheers,
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Hi all !
Our build system is now able to build so-called hybrid cds . What are
they?
They are boot+live-cd all-in-one. In addition it is now possible with them
to load the live cd as a ramdisk. For that the contents of the bootcd is
placed into a bootcd/ directory, the contents of the livecd is placed into a
livecd/ directory, and the livecd image itself is also included (this is the
one that is used for livecd ramdisk). You can notice that makes a lot of
redundancy, but its the best thing I could do for now. The best way would
be to build some kind of flat HDD image that is used as the livecd ramdisk
(and never use the livecd with reads from the cd as we currently do ) .
Anyways.
So here it is !
In addition you can add extra custom files via the build process: just place
your files into a <your_ROS_source>/modules/hybridcd_extras/ directory (this
directory doesnt exist by default, its up to you to create and populate
it; I think its better to create a directory somewhere else and then add a
symlink hybridcd_extras to this directory, inside the modules/ directory,
as you already do with rosapps and rostests).
After that you configure a build, build the host-tools and then ninja
hybridcd !!
If then you need to change the custom files, do it and then reconfigure a
build with the cmake . command (when youre inside
<your_ROS_builddir>/reactos/ ) so that cmake can build again the list of
files to be included into the hybridcd.
See https://jira.reactos.org/browse/CORE-9069 for few more details.
Cheers,
Hermès.