similar to: git.centos.org migration, please read

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/03/2015 12:52 PM, Fabian Arrotin wrote: > On 03/08/15 18:23, kunaal jain wrote: > >> Would start with the note that the basic project is complete. I >> would be releasing the prototype on a separate thread. But for >> the discussion sake the workflow will look like this : Authors >> contribute content in markdown

On Mon, Dec 11, 2017, at 10:41 AM, Fabian Arrotin wrote: > On 11/12/17 10:22, Thibaut Perrin wrote: > > Hello Fabien, > > > > First, thank you for even trying for what seems to be an impossible task :( > > > > Quick points :? > > - if it was decided not to continue, what would happen to the current > > wiki ? Dismantled or would it remain as read-only

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/08/15 18:23, kunaal jain wrote: > > Would start with the note that the basic project is complete. I > would be releasing the prototype on a separate thread. But for the > discussion sake the workflow will look like this : Authors > contribute content in markdown format, on github. The pull request > created gets mirrored to

From: Mircea C?rjaliu <mcirjaliu at bitdefender.com> The following two new mm exports are introduced: * mm_remote_map(struct mm_struct *req_mm, unsigned long req_hva, unsigned long map_hva) * mm_remote_unmap(unsigned long map_hva) * mm_remote_reset(void) * rmap_walk_remote(struct page *page, struct rmap_walk_control *rwc) This patch

On Thu, Jul 09, 2015 at 02:11:26AM +0530, kunaal jain wrote: > On Thu, Jul 9, 2015 at 1:19 AM, Brian (bex) Exelbierd <bex at pobox.com> > They have both a private git (with gerrit) and a github repo.A If you > open a PR on github it is closed by a bot with instructions to submit > the PR via gerrit to their private repo.A When the PR is resolved and >

On Thu, Jul 9, 2015 at 1:19 AM, Brian (bex) Exelbierd <bex at pobox.com> wrote: > Hi Lei, > > Hi, I am Kunaal the other GSoC student working on this toolchain. > On Jun 20, 2015, at 11:21 AM, Lei Yang <yltt1234512 at gmail.com> wrote: > > > I am sorry it has taken me so long to test this workflow. > Thanks a lot! We need testers and input from community.

Hi Lei, > On Jun 20, 2015, at 11:21 AM, Lei Yang <yltt1234512 at gmail.com> wrote: I am sorry it has taken me so long to test this workflow. > Hi, > > Kunaal and I have completed a prototype of the first part of our GSoC project (implement a new doc toolchain). Our goal is to implement a doc toolchain for short how-to docs and lower the barrier for new comers to contribute.

Hi, Kunaal and I have completed a prototype of the first part of our GSoC project (implement a new doc toolchain). Our goal is to implement a doc toolchain for short how-to docs and lower the barrier for new comers to contribute. This is the workflow of the prototype: 1. Contributor creates a new pull request on GitHub 2. A corresponding issue is automatically created on Pagure 3. Staff and

Dear users, I just started my first Gluster test volume using 3 servers (each server contains 12 hdd). I would like to create a "distributed disperse volume? but I?m a little bit confused about the right configuration schema that I should use. Should I use JBOD disks? How many bricks to be defined? Ideal redundancy value? Ideal disperse-data count value? 6x(4+2) or 3x(8+4) volume

On 11/12/17 10:22, Thibaut Perrin wrote: > Hello Fabien, > > First, thank you for even trying for what seems to be an impossible task :( > > Quick points :? > - if it was decided not to continue, what would happen to the current > wiki ? Dismantled or would it remain as read-only for documentation > purpose ? > - What about Sphinx

Hi Nithya, thank you very much for your support and sorry for the late. Below you can find the output of ?gluster volume info tier2? command and the gluster software stack version: gluster volume info Volume Name: tier2 Type: Distributed-Disperse Volume ID: a28d88c5-3295-4e35-98d4-210b3af9358c Status: Started Snapshot Count: 0 Number of Bricks: 6 x (4 + 2) = 36 Transport-type: tcp Bricks:

On 4 August 2015 at 14:21, kunaal jain <kunaalus at gmail.com> wrote: > Hi, > > The basic toolchain is up and running. I encourage community to test > this workflow once. It is an addition to the existing contributing > mediums. > > Site: http://clown-olga-13325.bitballoon.com/ > Contributing Docs repo : https://github.com/kunaaljain/test-centos-docs > > ==AIM==

I think it is safe to ignore it. The problem exists? due to the minor difference in file time stamps in the backend bricks of the same sub volume (for a given file) and during the course of tar, the timestamp can be served from different bricks causing it to complain . The ctime xlator[1] feature once ready should fix this issue by storing time stamps as xattrs on the bricks. i.e. all bricks

Hi Ravi, thank you very much for your support and explanation. If I understand, the ctime xlator feature is not present in the current gluster package but it will be in the future release, right? Thank you again, Mauro > Il giorno 02 gen 2018, alle ore 12:53, Ravishankar N <ravishankar at redhat.com> ha scritto: > > I think it is safe to ignore it. The problem exists due to the

Hi, For 3 days uptime serve about 40 client Windows workstation with traffic average 50 Mbps - 80 Mbps (Video streaming) running on FreeBSD system with 16 GB RAM already installed. # uname -smrv FreeBSD 12.1-STABLE FreeBSD 12.1-STABLE r364492 GENERIC amd64 # pkg info samba\* samba410-4.10.17 I got this produce error in /var/log/message, any clue for this problem? Sep 14 10:20:15 BEC-STG-P1

Hi All, any news about this issue? Can I ignore this kind of error message or I have to do something to correct it? Thank you in advance and sorry for my insistence. Regards, Mauro > Il giorno 29 dic 2017, alle ore 11:45, Mauro Tridici <mauro.tridici at cmcc.it> ha scritto: > > > Hi Nithya, > > thank you very much for your support and sorry for the late. > Below

> ? 2015?6?5????6:10?Karsten Wade <kwade at redhat.com> ??? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 06/04/2015 12:58 PM, Pete Travis wrote: > >> >> I'm tentatively planning on working pagure[0] into the Fedora Docs >> toolchain. It handles issue tracking, process >> documentation/contribution guidelines, and of course

Dear All: I have a question on using coxph for multiple genes: I have written code to loop through all 22283 genes in the Hgu-133A and apply coxph on survival data. However, I don't know how to work with the result for each gene: survtest<-coxph(Surv(pcc.primary.stg.3.cox[,'fup_interval'],pcc.primary.stg.

The Samba ports are not filtered. The firewall is between STG-DC and SAMBADC (both of them sync correctly). The sync problems happen in VIG-DC3, which is behind the same firewall of STG-DC. Here's nmap output (SAMBADC is 172.16.50.9): root at vig-dc3:~# nmap -Pn 172.16.50.9 Starting Nmap 7.93 ( https://nmap.org ) at 2024-05-23 08:22 UTC Nmap scan report for SAMBADC.ugt.ldap (172.16.50.9)

Hi Mauro, We would require complete log file to debug this issue. Also, could you please provide some more information of the core after attaching to gdb and using command "bt". --- Ashish ----- Original Message ----- From: "Mauro Tridici" <mauro.tridici at cmcc.it> To: "Gluster Users" <gluster-users at gluster.org> Sent: Monday, September 25,