Ros-dev

ros-dev@reactos.org

5790 discussions

Git Migration Newsletter #2
by Colin Finck 13 Sep '17

13 Sep '17

Hi all! Let me give a short update on the Git Migration: * The data from the committer table has been converted into an identity map for the SVN->Git conversion tool: https://github.com/ColinFinck/reactos-git-conversion-scripts/blob/master/re… Together with my hacked version of svn-all-fast-export (https://github.com/ColinFinck/svn2git), this results in a really nice and clean Git repo :) Further changes to your names or E-Mail addresses in that committer table won't be taken into account. Please add your GitHub usernames to that table though! * As you can imagine, our tree and tools need several changes to deal with the change from SVN revision numbers to Git commit hashes. My first patch for reporting the "Git revision" in our codebase is ready and open for discussion: https://github.com/ColinFinck/reactos-git-conversion-scripts/commit/0aaa6ff… More to follow! Cheers, Colin

1 0

Git Migration Newsletter
by Colin Finck 12 Sep '17

12 Sep '17

Hi all! Let me give a public update about our Git Migration Decisions after the last meeting: * The migration of our SVN repository "reactos" is going to happen in September/October. * https://github.com/reactos/reactos will become our master repository as we want to take advantage of GitHub's Pull Request features. This means, all developers must register for GitHub accounts now. * git.reactos.org will remain as a replication slave. If we ever have severe problems with GitHub, we can switch back to a self-hosted Git in no time. * We will enforce a linear history in the "master" branch through server-side GitHub settings. You may create and push as many branches as you want and do whatever you want there, but when you want to commit the changes back to "master", you can only do so over a "git rebase". * BuildBot builds will get a naming scheme like: reactos-bootcd-0.4.7-dev+344-5f3c53e2a-gcc.7z That means 344 commits after the tag "0.4.7-dev" has been created, with this particular commit having the short hash "5f3c53e2a". Whenever we branch for a release like "0.4.6", we will now not just create the branch, but also tag "master" with "0.4.7-dev" to make this naming scheme possible. More newsletters like this may follow when I have more information to share or get the impression that some decisions haven't reached all developers yet. Best regards, Colin

4 6

Re: [ros-dev] Git Migration Newsletter
by David Quintana (gigaherz) 10 Sep '17

10 Sep '17

The git repository data is compressed, and takes in the order of 100 mb. The checkout size will be somilar but the .git folder is much more compact than the .svn folder. On 10 Sep 2017 10:08 am, "Michael Fritscher" <michael(a)fritscher.net> wrote: Hi, are there estimation about the size of a git clone vs. a svn checkout? I'm afraid that I'll need to free much space beforehand... Best regards, Michael Fritscher > If you mean your local working copy: clone into a separate folder, and > copy > over the files. Subversion checkout is only the current commit data, while > git clones contain ALL THE HISTORY, so you can't "migrate" anything, > because the svn metadata doesn't contain any of the needed info. Even if > you could somehow migrate using a tool, the tool would still have to > perform a clone, and would just import the file status. > > On 6 September 2017 at 23:06, Thomas Mueller <mueller6723(a)twc.com> wrote: > >> from Colin Finck: >> >> > Let me give a public update about our Git Migration Decisions after >> the >> last >> > meeting: >> >> > * The migration of our SVN repository "reactos" is going to happen in >> > September/October. >> >> > * https://github.com/reactos/reactos will become our master repository >> as we >> > want to take advantage of GitHub's Pull Request features. >> > This means, all developers must register for GitHub accounts now. >> >> > * git.reactos.org will remain as a replication slave. If we ever have >> severe >> > problems with GitHub, we can switch back to a self-hosted Git in no >> time. >> >> > * We will enforce a linear history in the "master" branch through >> server-side >> > GitHub settings. You may create and push as many branches as you want >> and do >> > whatever you want there, but when you want to commit the changes back >> to >> > "master", you can only do so over a "git rebase". >> >> > * BuildBot builds will get a naming scheme like: >> >> > reactos-bootcd-0.4.7-dev+344-5f3c53e2a-gcc.7z >> >> > That means 344 commits after the tag "0.4.7-dev" has been created, >> with this >> > particular commit having the short hash "5f3c53e2a". >> > Whenever we branch for a release like "0.4.6", we will now not just >> create the >> > branch, but also tag "master" with "0.4.7-dev" to make this naming >> scheme >> > possible. >> >> >> > More newsletters like this may follow when I have more information to >> share or >> > get the impression that some decisions haven't reached all developers >> yet. >> >> Is there a convenient way to migrate an svn tree to git, or would it be >> necessary to git-clone to a separate tree? >> >> Will the boot CD images be in 7z (p7zip) format: >> >> What has kept me from trying ReactOS is not having a place to put it, >> considering ReactOS does not successfully boot from USB. >> >> My hard drives are partitioned GPT. >> >> Tom >> >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

2 3

Git Migration: The documentation, rossubsys and wallpapers directories
by Colin Finck 09 Sep '17

09 Sep '17

Hi all! As you know, we have to give up our "modules" directory concept when switching to Git, because Git doesn't support checking out an arbitrary directory into a subdirectory of a Git clone. Therefore, the first commit to the migrated repository will make the "reactos" directory the new root and move "rosapps" and "rostests" permanently into "modules". We can then introduce an environment variable/CMake variable/something else to enable or disable building of them on demand (suggestions are welcome!) But what will happen to the remaining directories in /trunk, namely "documentation", "rossubsys", and "wallpapers"? * Commits to "documentation" never had a relation to "reactos" commits, so nothing is lost if we put that directory into a separate repo "documentation.git" and remove all traces to it from the history of "reactos.git". I'd go this way if there are no objections. * I don't get the idea of that "rossubsys" directory created in 2014.. These subsystems are all stubs, never built with modern ReactOS, and no work has happened since "reviving" them. I would just go and remove them again. You can always find them in our repository history. * The "wallpapers" directory is a harder candidate. On the one hand, we don't want to bloat our ReactOS builds by including wallpapers in every build. Also the number of wallpapers may increase in the future, which could bloat the "reactos.git" repo even more. On the other hand, the wallpapers have always accompanied our release branches, so there is a value of having them tracked next to our code. I could put them in a separate repository "wallpapers.git" now and remove all traces to them in the "reactos.git" repo. But then again, how are they picked up by the build process in the future if we can't check them out into a subdirectory of "modules"? Another alternative is moving them to "modules/wallpapers_disabled". Then they are not picked up by the build process until they are renamed to "modules/wallpapers" for releases. What are your opinions on this? Cheers, Colin

8 15

un-official Builds of ReactOS 0.4.6 with USB support
by Alexander Rechitskiy 07 Sep '17

07 Sep '17

1 0

Bluetooth Stack
by Alexander T. 04 Sep '17

04 Sep '17

Hi all! I have to do a semester project on operating systems in my university. In GSoC 2017 ideas there is problem called «Bluetooth stack». So, is this problem already solved? If not, then could anyone tell me more about it? Sincerely, Alexandr Tsukanov

2 1

Status Meeting (August 2017)
by Colin Finck 31 Aug '17

31 Aug '17

Hi all! Let me invite you to the monthly status meeting taking place on Thursday, August 31, 19:00 UTC. As always, you will get credentials for our private IRC server shortly before the meeting. Agenda proposals so far include: - Short report from my side regarding the Hackfest - Git/GitHub migration in September/October - Finalizing the 0.4.6 release, possibly planning 0.4.7 Please post any additional agenda proposals here. Also don't forget that we're in the final week of GSoC :) Mentors, now that all code has been submitted, don't forget about evaluating your students! See you on Thursday! Colin

1 1

who is the administrator of ReactOS Facebook Group?
by Alexander Rechitskiy 30 Aug '17

30 Aug '17

4 3

Re: [ros-dev] [ros-diffs] [cfinck] 75630: [FS_REC] - Add a detection routine for CDFS (ISO-9660) volumes that verifies the Primary Volume Descriptor. - Use this to also detect CDFS on disks and load the CDFS driver if it ha...
by Pierre Schweitzer 22 Aug '17

22 Aug '17

Hi Colin, Thanks for your work. This commit is likely breaking UDFS recognition when media has a protective CDFS partition with UDFS afterwards, while both FSD are unloaded. You'll first match the CDFS recognizer and not the UDFS recognizer. I would suggest you modify FsRecRegisterFs() so that you can register low priority FS. Cheers, Pierre Le 20/08/2017 à 17:30, cfinck(a)svn.reactos.org a écrit : > Author: cfinck > Date: Sun Aug 20 15:30:59 2017 > New Revision: 75630 > > URL: http://svn.reactos.org/svn/reactos?rev=75630&view=rev > Log: > [FS_REC] > - Add a detection routine for CDFS (ISO-9660) volumes that verifies the Primary Volume Descriptor. > - Use this to also detect CDFS on disks and load the CDFS driver if it has not been loaded yet (e.g. when a bootcd/livecd flashed USB drive is inserted at boot of an installed ReactOS). > - Fix a comment in udfs.c. > > Added: > trunk/reactos/drivers/filesystems/fs_rec/cdfs.h (with props) > Modified: > trunk/reactos/drivers/filesystems/fs_rec/cdfs.c > trunk/reactos/drivers/filesystems/fs_rec/fs_rec.c > trunk/reactos/drivers/filesystems/fs_rec/udfs.c > > Modified: trunk/reactos/drivers/filesystems/fs_rec/cdfs.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fs_rec… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fs_rec/cdfs.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fs_rec/cdfs.c [iso-8859-1] Sun Aug 20 15:30:59 2017 > @@ -1,10 +1,10 @@ > /* > - * COPYRIGHT: See COPYING in the top level directory > - * PROJECT: ReactOS File System Recognizer > - * FILE: drivers/filesystems/fs_rec/cdfs.c > - * PURPOSE: CDFS Recognizer > - * PROGRAMMER: Alex Ionescu (alex.ionescu(a)reactos.org) > - * Eric Kohl > + * PROJECT: ReactOS File System Recognizer > + * LICENSE: GPL-2.0 (https://spdx.org/licenses/GPL-2.0) > + * PURPOSE: CDFS Recognizer > + * COPYRIGHT: Copyright 2002 Eric Kohl > + * Copyright 2007 Alex Ionescu <alex.ionescu(a)reactos.org> > + * Copyright 2017 Colin Finck <colin(a)reactos.org> > */ > > /* INCLUDES *****************************************************************/ > @@ -14,13 +14,60 @@ > #define NDEBUG > #include <debug.h> > > +#include "cdfs.h" > + > /* FUNCTIONS ****************************************************************/ > + > +BOOLEAN > +NTAPI > +FsRecIsCdfsVolume(IN PDEVICE_OBJECT DeviceObject, > + IN ULONG SectorSize) > +{ > + BOOLEAN bReturnValue = FALSE; > + LARGE_INTEGER Offset; > + PVD_HEADER pVdHeader = NULL; > + PAGED_CODE(); > + > + // Read the Primary Volume Descriptor. > + Offset.QuadPart = VD_HEADER_OFFSET; > + if (!FsRecReadBlock(DeviceObject, &Offset, sizeof(VD_HEADER), SectorSize, (PVOID*)&pVdHeader, NULL)) > + { > + // We cannot read this block, so no reason to let the CDFS driver try it. > + goto Cleanup; > + } > + > + // Verify the fields. > + if (pVdHeader->Type != VD_TYPE_PRIMARY) > + goto Cleanup; > + > + DPRINT("pVdHeader->Type verified!\n"); > + > + if (RtlCompareMemory(pVdHeader->Identifier, VD_IDENTIFIER, VD_IDENTIFIER_LENGTH) != VD_IDENTIFIER_LENGTH) > + goto Cleanup; > + > + DPRINT("pVdHeader->Identifier verified!\n"); > + > + if (pVdHeader->Version != VD_VERSION) > + goto Cleanup; > + > + DPRINT("pVdHeader->Version verified! This is a CDFS volume!\n"); > + > + bReturnValue = TRUE; > + > +Cleanup: > + if (pVdHeader) > + ExFreePool(pVdHeader); > + > + return bReturnValue; > +} > > NTSTATUS > NTAPI > FsRecCdfsFsControl(IN PDEVICE_OBJECT DeviceObject, > IN PIRP Irp) > { > + PDEVICE_OBJECT MountDevice; > + ULONG SectorSize; > PIO_STACK_LOCATION Stack; > NTSTATUS Status; > PAGED_CODE(); > @@ -31,8 +78,21 @@ > { > case IRP_MN_MOUNT_VOLUME: > > - /* We don't validate */ > - Status = STATUS_FS_DRIVER_REQUIRED; > + /* Assume failure */ > + Status = STATUS_UNRECOGNIZED_VOLUME; > + > + /* Get the device object and request the sector size */ > + MountDevice = Stack->Parameters.MountVolume.DeviceObject; > + if (FsRecGetDeviceSectorSize(MountDevice, &SectorSize)) > + { > + /* Check if it's an actual CDFS (ISO-9660) volume */ > + if (FsRecIsCdfsVolume(MountDevice, SectorSize)) > + { > + /* It is! */ > + Status = STATUS_FS_DRIVER_REQUIRED; > + } > + } > + > break; > > case IRP_MN_LOAD_FILE_SYSTEM: > > Added: trunk/reactos/drivers/filesystems/fs_rec/cdfs.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fs_rec… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fs_rec/cdfs.h (added) > +++ trunk/reactos/drivers/filesystems/fs_rec/cdfs.h [iso-8859-1] Sun Aug 20 15:30:59 2017 > @@ -0,0 +1,24 @@ > +/* > + * PROJECT: ReactOS File System Recognizer > + * LICENSE: GPL-2.0 (https://spdx.org/licenses/GPL-2.0+) > + * PURPOSE: CDFS Recognizer > + * COPYRIGHT: Copyright 2017 Colin Finck <colin(a)reactos.org> > + */ > + > +// Information from http://wiki.osdev.org/ISO_9660#Volume_Descriptors > + > +// Structures > +typedef struct _VD_HEADER > +{ > + char Type; > + char Identifier[5]; > + char Version; > +} > +VD_HEADER, *PVD_HEADER; > + > +// Constants > +#define VD_HEADER_OFFSET 32768 // Offset of the VD Header > +#define VD_IDENTIFIER "CD001" // Identifier that must be in the Volume Descriptor > +#define VD_IDENTIFIER_LENGTH 5 // Character count of VD_IDENTIFIER > +#define VD_TYPE_PRIMARY 1 // Type code for Primary Volume Descriptor > +#define VD_VERSION 1 // Volume Descriptor Version > > Propchange: trunk/reactos/drivers/filesystems/fs_rec/cdfs.h > ------------------------------------------------------------------------------ > svn:eol-style = native > > Modified: trunk/reactos/drivers/filesystems/fs_rec/fs_rec.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fs_rec… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fs_rec/fs_rec.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fs_rec/fs_rec.c [iso-8859-1] Sun Aug 20 15:30:59 2017 > @@ -316,6 +316,7 @@ > { > ULONG DeviceCount = 0; > NTSTATUS Status; > + PDEVICE_OBJECT CdfsObject; > PDEVICE_OBJECT UdfsObject; > PAGED_CODE(); > > @@ -340,14 +341,24 @@ > DriverObject->MajorFunction[IRP_MJ_FILE_SYSTEM_CONTROL] = FsRecFsControl; > DriverObject->DriverUnload = FsRecUnload; > > - /* Register CDFS */ > - Status = FsRecRegisterFs(DriverObject, > - NULL, > - NULL, > + /* Register CDFS for CDs */ > + Status = FsRecRegisterFs(DriverObject, > + NULL, > + &CdfsObject, > L"\\Cdfs", > L"\\FileSystem\\CdfsRecognizer", > FS_TYPE_CDFS, > FILE_DEVICE_CD_ROM_FILE_SYSTEM); > + if (NT_SUCCESS(Status)) DeviceCount++; > + > + /* Register CDFS for HDDs */ > + Status = FsRecRegisterFs(DriverObject, > + CdfsObject, > + NULL, > + L"\\CdfsHdd", > + L"\\FileSystem\\CdfsHddRecognizer", > + FS_TYPE_CDFS, > + FILE_DEVICE_DISK_FILE_SYSTEM); > if (NT_SUCCESS(Status)) DeviceCount++; > > /* Register UDFS for CDs */ > > Modified: trunk/reactos/drivers/filesystems/fs_rec/udfs.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fs_rec… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fs_rec/udfs.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fs_rec/udfs.c [iso-8859-1] Sun Aug 20 15:30:59 2017 > @@ -125,7 +125,7 @@ > MountDevice = Stack->Parameters.MountVolume.DeviceObject; > if (FsRecGetDeviceSectorSize(MountDevice, &SectorSize)) > { > - /* Check if it's an actual FAT volume */ > + /* Check if it's an actual UDF volume */ > if (FsRecIsUdfsVolume(MountDevice, SectorSize)) > { > /* It is! */ > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

2 1

Re: [ros-dev] undelate
by Magnus Johnsson 21 Aug '17

21 Aug '17

1. Send a mail to the list unsubscribe address, which will be of the form LISTNAME-leave@DOMAIN. The subject and body of this message will be ignored, so it doesn't matter what you put there. not sure if you found out this yet. Quick google for mailman, which seems to be what is used :) 2017-08-20 19:39 GMT+02:00 gmusume <gmusume(a)correo.ugr.es>: > > hi I want undelate of the group > thank > > > Enviado desde mi smartphone Samsung Galaxy. > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev