Hi all!
We have run out of space on our temporary universal Build and ISO
machine HotelLux today. This is why TestCD creation has been failing.
I'm currently moving files away from the main disk to a temporary
storage. You should already be able to redo the failed builds.
Within this month, Aleksey and me will move the ISO storage back to our
actual storage server, upgraded with larger disks.
This one should be sufficient for quite some time.
Sorry for the inconveniences!
Cheers,
Colin
On 2017-03-04 17:02, ekohl(a)svn.reactos.org wrote:
> + Dacl = ExAllocatePool(PagedPool, AclLength);
Would you mind using ExAllocatePoolWithTag for new code please,
with no exceptions?
(I want to #define ExAllocatePool do_not_use_this_function at some point)
Thanks!
-Thomas
Hello,
Soon (tm) we will be retiring rapps in favor of rapps_new.
If you have any local patches in these regions, now is the time to
step forward (and convert them to rapps_new!).
regards,
Mark Jansen
Hi folks!
We just got the good news: ReactOS has been accepted and will be
participating in Google Summer of Code 2017!! :)
Next step is finishing the Ideas list. Our current version is at
https://reactos.org/wiki/Google_Summer_of_Code_2017_Ideas
More information will also follow shortly on our website.
Cheers,
Colin
These are so much more useful to read now we have a changelog to explain the patch.
Thanks Amine :)
-----Original Message-----
From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of akhaldi(a)svn.reactos.org
Sent: 26 February 2017 16:01
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [akhaldi] 73929: [CABINET] Sync with Wine Staging 2.2. CORE-12823 a663fe94 cabinet: Set index of folder in FDICopy callback. 1f7d144 cabinet: Make Extract fail on read-only files. af86bdc cabinet: ...
Author: akhaldi
Date: Sun Feb 26 16:00:58 2017
New Revision: 73929
URL: http://svn.reactos.org/svn/reactos?rev=73929&view=rev
Log:
[CABINET] Sync with Wine Staging 2.2. CORE-12823
a663fe94 cabinet: Set index of folder in FDICopy callback.
1f7d144 cabinet: Make Extract fail on read-only files.
af86bdc cabinet: Make Extract overwrite existing files.
3273dff cabinet: Properly initialize internal fci structure (Valgrind).
Modified:
trunk/reactos/dll/win32/cabinet/cabinet_main.c
trunk/reactos/dll/win32/cabinet/fci.c
trunk/reactos/media/doc/README.WINE
I think I'm going to upload two PDF files to prove my point.
On Thu, Feb 16, 2017 at 11:25 PM Hermès BÉLUSCA-MAÏTO <hermes.belusca(a)sfr.fr>
wrote:
> Hi ! Here are some thoughts as an answer to Ziliang's mail:
>
> > De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Zachary
> Gorden
> > Envoyé : jeudi 16 février 2017 23:03
> > À : ReactOS Development List
> > Objet : Re: [ros-dev] Microsoft switched to Git
>
> > The fact that git has problems maintain a large history is ONE of the
> limitations that prompted them to develop GVFS. There are several comments
> on the first page in the discussion of the ars technica article on GVFS
> that talk about git's issues with long histories:
> >
> https://arstechnica.com/information-technology/2017/02/microsoft-hosts-the-…
> > I can't link directly to the comments, but if you search by user name
> you jump right to them. Two especially relevant ones are by smengler and
> zaqzlea. The one by zaqzlea is also rather interesting if Linux itself has
> truncated its own commit history, which is more than a bit disturbing from
> > my perspective.
>
> I guess that this 'truncated history' story happened when Linus switched
> to his newly-created Git the 16. April, 2005 :
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=…
> because, if one believes what's written inside
> https://git.wiki.kernel.org/index.php/GraftPoint , "When Linus started
> using git for maintaining his kernel tree there didn't exist any tools to
> convert the old kernel history." Later on, when new features have been
> added to Git, people were able to create Git repositories of Linux' code
> before the 16/04/2005 Git transition, and then, to be able to see the whole
> Linux history, you need to use the so-called graft points. Examples are
> given here:
>
> http://stackoverflow.com/questions/3264283/linux-kernel-historical-git-repo…
> https://archive.org/details/git-history-of-linux
>
>
> > We also see a few remarks by a guy calling himself scuttle22 who claims
> that truncating history and dropping it is "common practice" and
> acceptable. His original posts have all been downvoted to oblivion,
> presumably because others take a less lackadaisical perspective
> > on preserving history for purposes of documentation and accountability.
>
> This is possibly "common practice", maybe in order to reduce the git
> repos... In there:
> http://stackoverflow.com/questions/4515580/how-do-i-remove-the-old-history-…
> , someone ask for example how to trim the history before a certain date,
> while the complete copy of history is kept in an archive repository....
>
>
> I also take the occasion to mention the peculiar possibility, with Git, to
> have a repository having multiple roots ("initial commits"): for example,
> someone did the error once in the linux kernel repo:
> http://lkml.iu.edu/hypermail/linux/kernel/1603.2/01926.html .
>
> Best,
> Hermès
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
--
Best regards,
Alex Ionescu