Re: [OMPI devel] Conversion to GitHub: POSTPONED

On Sep 23, 2014, at 7:52 PM, Jed Brown wrote: > I don't have experience with GerritHub, but Bitbucket supports this > feature (permissions on branch names/globs) and we use it in PETSc. Thanks for the info. Paul Hargrove said pretty much the same thing to me, off-list.

[hwloc-devel] Create success (hwloc git 1.9.1-11-g6ec83e5)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc 1.9.1-11-g6ec83e5 Start time: Tue Sep 23 21:02:56 EDT 2014 End time: Tue Sep 23 21:04:19 EDT 2014 Your friendly daemon, Cyrador

[hwloc-devel] Create success (hwloc git dev-235-g415b593)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc dev-235-g415b593 Start time: Tue Sep 23 21:01:02 EDT 2014 End time: Tue Sep 23 21:02:46 EDT 2014 Your friendly daemon, Cyrador

Re: [OMPI devel] Conversion to GitHub: POSTPONED

"Jeff Squyres (jsquyres)" writes: > GerritHub claims to allow us to effectively have ACLs on branches. > I.e., everyone could commit on master, but only release managers can > commit on release branches. This would be nice, and would allow us to > avoid having the 2 repos,

Re: [hwloc-devel] Using hwloc to detect Hard Disks

True - but we intend to collect the inventory as root anyway. :-) On Sep 23, 2014, at 1:50 PM, Christopher Samuel wrote: > On 24/09/14 00:57, Ralph Castain wrote: > >> Memory info is available from lshw, though they are a GPL code: > > FWIW on this laptop (Intel

Re: [hwloc-devel] Using hwloc to detect Hard Disks

On 24/09/14 00:57, Ralph Castain wrote: > Memory info is available from lshw, though they are a GPL code: FWIW on this laptop (Intel Haswell) lshw only report DIMM info when run as root, which I suspect would point them to accessing DMI information via /dev/mem. Using strace supports this:

Re: [OMPI devel] Conversion to GitHub: POSTPONED

At just about at the last minute, a new contender showed up: GerritHub.io. GerritHub claims to allow us to effectively have ACLs on branches. I.e., everyone could commit on master, but only release managers can commit on release branches. This would be nice, and would allow us to avoid having

Re: [hwloc-devel] Using hwloc to detect Hard Disks

Le 23/09/2014 21:06, Pedaballe, Vineet a écrit : > 4a. Network Adapters (Ethernet) > a. Model > b. Speed Both supported and currently negociated link speed? On Linux, we'll have to use the ethtool interface. > c. Serial Number (if applicable) > d. MAC address > 4b.

Re: [OMPI devel] Need to know your Github ID

Sorry for the delay in response, somehow I missed this.  Those were SVN IDs. I have created a github id (vvenkatesan)   vvenkates is the currently active SVN ID. So vvenkates -> vvenkatesan Thanks Vish On Sep 18, 2014, at 10:58 AM, "Jeff Squyres (jsquyres)" wrote: On Sep

Re: [hwloc-devel] Using hwloc to detect Hard Disks

Thank you Ralph and Jeff. This was the list I was hoping to read through hwloc. 3. Memory a. Total memory b. Total DIMMS c. Individual DIMM's: (i) Serial numbers (ii) Vendor Name (iii) Model (iv) Memory

[OMPI devel] Conversion to GitHub: tomorrow (Sep 24, 2014)

REMINDER: The conversion of Open MPI's Subversion repository and Trac tickets will be happening tomorrow, Wednesday, September 24, 2014. SVN and Trac will be going read-only at 8am US Eastern tomorrow, and the conversion process will begin. I anticipate it taking all day. I'll send an "all

Re: [hwloc-devel] Using hwloc to detect Hard Disks

Le 23/09/2014 16:46, Brice Goglin a écrit : > Le 23/09/2014 16:38, Guy Streeter a écrit : >> I know that udev gathers this information: >> >> # ll /sys/block/sda/bdi >> lrwxrwxrwx. 1 root root 0 Sep 23 09:33 /sys/block/sda/bdi -> >> ../../../../../../../../virtual/bdi/8:0 >> # grep SERIAL

Re: [hwloc-devel] Using hwloc to detect Hard Disks

Memory info is available from lshw, though they are a GPL code: *-bank:0 description: DIMM Synchronous 1333 MHz (0.8 ns) product: M393B1K70DH0-YH9 vendor: 0x80CE physical id: 0 serial: 0x85B5FED3 slot: DIMM_A1 size: 8GiB

Re: [hwloc-devel] Using hwloc to detect Hard Disks

Le 23/09/2014 16:38, Guy Streeter a écrit : > I know that udev gathers this information: > > # ll /sys/block/sda/bdi > lrwxrwxrwx. 1 root root 0 Sep 23 09:33 /sys/block/sda/bdi -> > ../../../../../../../../virtual/bdi/8:0 > # grep SERIAL '/run/udev/data/b8:0' >

Re: [OMPI devel] opal components still #including OMPI header files

Rolf -- please add this to the agenda for today. On Sep 23, 2014, at 10:28 AM, Ralph Castain wrote: > ofacm needs to be updated to remove xoob and oob modules as those cannot be > used from the opal layer > > > On Sep 23, 2014, at 7:22 AM, Jeff Squyres (jsquyres)

Re: [OMPI devel] opal components still #including OMPI header files

ofacm needs to be updated to remove xoob and oob modules as those cannot be used from the opal layer On Sep 23, 2014, at 7:22 AM, Jeff Squyres (jsquyres) wrote: > From SVN trunk HEAD (r32772): > > - > mca/btl/ugni/btl_ugni_component.c > 20:#include

Re: [OMPI devel] race condition in oob/tcp

Thanks! I won't have time to work on it this week, but appreciate your effort. Also, thanks for clarifying the race condition vis 1.8 - I agree it is not a blocker for that release. Ralph On Sep 22, 2014, at 4:49 PM, Gilles Gouaillardet wrote: > Ralph, > >

Re: [hwloc-devel] Using hwloc to detect Hard Disks

On Sep 22, 2014, at 4:58 PM, Jeff Squyres (jsquyres) wrote: > On Sep 22, 2014, at 6:55 PM, Brice Goglin wrote: > >>> HWLOC already provides similar info for processors and mother boards, so it >>> seemed a natural extension of current capabilities