Re: [hwloc-devel] Strange CPU topology numbering on dual socket ARM server with 2×ThunderX2 CN9975

[Jeff Squyres (jsquyres) via hwloc-devel]

On Sep 6, 2019, at 10:52 AM, Jirka Hladky 
mailto:jhla...@redhat.com>> wrote:

You should avoid physical numbering at any cost.

The trouble is that other Linux tools (like ps) are using the physical 
numbering. I will need to think about how to come around this.

Use hwloc for everything!  ;-)

(I'm only half-kidding, actually -- FWIW, I use hwloc for everything these 
days.  The logical ordering alone makes it worthwhile.  The simplicity of 
hwloc-bind's socket:X,core:Y is even more lovely.  ...etc.)

--
Jeff Squyres
jsquy...@cisco.com<mailto:jsquy...@cisco.com>

___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/hwloc-devel

Re: [hwloc-devel] Strange CPU topology numbering on dual socket ARM server with 2×ThunderX2 CN9975

[Jeff Squyres (jsquyres) via hwloc-devel]

FWIW / in addition to what Brice said: this is why hwloc also has "logical" 
ordering (in addition to the "physical" ordering).


On Sep 6, 2019, at 10:07 AM, Brice Goglin 
mailto:brice.gog...@inria.fr>> wrote:


Hello Jirka

I don't think there's a bug here.

physical_package_id don't have to be between 0 and N-1, they just have to be 
different to identify packages and cores between packages. Having other values 
is uncommon on x86 but quite common on POWER at least.

core_id is even worse. They are basically not used at all fortunately. They are 
often the same in both sockets. They are often discontigous inside sockets 
(maybe because CPU vendors disable specific cores in the middle of the CPU when 
your CPU doesn't have the max number of cores). On a dual-socket 20-core Xeon 
(Cascade Lake), both sockets have these core_ids: 
0,4,1,3,2,12,8,11,9,10,16,20,17,19,18,28,24,27,25,26 (5-7, 13-15 and 21-23 are 
missing).

PU and NUMA nodes often have contigous OS indexes, but not necessarily in order 
either.

FWIW, I get the same values as yours on a Gigabyte platform with 2x ThunderX2 
running RHEL7 4.14 kernel.

Brice



Le 06/09/2019 à 15:29, Jiri Hladky a écrit :
Hi all!

We are seeing strange CPU topology/numbering on a dual-socket ARM server with 
2×ThunderX2 CN9975 CPU [0].

Package IDs:
36 and 3180
cd /sys/devices/system/cpu
$ cat cpu0/topology/physical_package_id
36
Expected values: 0 and 1

Core IDs on the second socket:
256-283
$ cat cpu112/topology/core_id
256
$ cat cpu223/topology/core_id
283

Expected values for the second socket:
28 - 55

(On the first socket, the core numbering is OK - 0-27)

I assume this is Linux kernel bug. Have you seen anything like this in the 
past? What might a root cause? Linux kernel bug or perhaps a BIOS issue?

We see it on 5.3.0-0.rc7 and 4.18 kernels. I'm attaching lstopo and 
gather-topology output. I would appreciate any feedback on that.

Thank you!
Jirka


[0]
https://en.wikichip.org/wiki/cavium/thunderx2




___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org<mailto:hwloc-devel@lists.open-mpi.org>
https://lists.open-mpi.org/mailman/listinfo/hwloc-devel

___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org<mailto:hwloc-devel@lists.open-mpi.org>
https://lists.open-mpi.org/mailman/listinfo/hwloc-devel


--
Jeff Squyres
jsquy...@cisco.com<mailto:jsquy...@cisco.com>

___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/hwloc-devel

[hwloc-devel] Fwd: [OMPI commits] Commit emails

[Jeff Squyres (jsquyres) via hwloc-devel]

FYI -- same applies for hwloc commit emails.

Begin forwarded message:

From: "Jeff Squyres \(jsquyres\) via ompi-commits" 
mailto:ompi-comm...@lists.open-mpi.org>>
Subject: [OMPI commits] Commit emails
Date: April 26, 2019 at 10:28:30 AM EDT
To: "ompi-comm...@lists.open-mpi.org<mailto:ompi-comm...@lists.open-mpi.org>" 
mailto:ompi-comm...@lists.open-mpi.org>>
Cc: "Jeff Squyres (jsquyres)" mailto:jsquy...@cisco.com>>

I finally figured out why were weren't getting commit emails: GitHub updated 
the IP blocks where webhook API calls could (would) be delivered from.  This 
caused our web hooks to fail the IP address block verification (i.e., make sure 
it's really GitHub who is sending us this API call), and therefore the incoming 
webhook calls were discarded.

I have updated our IP blocks to match GitHub's new configuration and just 
tested it by re-delivering the last OMPI commit webhook (a commit from Mark 
Allen).

All appears to be well now.

--
Jeff Squyres
jsquy...@cisco.com<mailto:jsquy...@cisco.com>

___
ompi-commits mailing list
ompi-comm...@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/ompi-commits


--
Jeff Squyres
jsquy...@cisco.com<mailto:jsquy...@cisco.com>

___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/hwloc-devel

Re: [hwloc-devel] C99 will be back soon

[Jeff Squyres (jsquyres)]

On Sep 28, 2017, at 8:41 AM, Brice Goglin <brice.gog...@inria.fr> wrote:
> 
> Turns out Microsoft Visual Studio doesn't support most of C99
> (at least dynamic arrays and mixed declaration/code).

Good lord; they don't even support mixing declarations/code?  That... is 
unfortunate.

> I am using some glue for now. However I am not 100% sure
> I'll remain happy to restrict hwloc just to support such a
> dump compiler (MinGW doesn't have any issue with C99).

Yeah, I wonder if MVS was the reason we stayed out of C99 all those years ago.  
Open MPI stopped supporting MVS -- that may well have been the last sticking 
point that allowed us to move Open MPI to C99.

-- 
Jeff Squyres
jsquy...@cisco.com

___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/hwloc-devel

Re: [hwloc-devel] hwloc.m4: minor english fixes

[Jeff Squyres (jsquyres)]

The email script doesn't run on GitHub.

We have a GitHub web hook that fires out to the Open MPI hostgator instance 
(our web hosting provider). That fires up a PHP script (i.e., GitHub calls 
https://...open-mpi.org/...php) and funnels it the information about the 
commits that were just pushed to the branch.

The PHP script basically does:

git pull
git log ...
email << results_of_git_log

However, our HostGator instance is really tuned for *web hosting*, not *script 
hosting*.  I've seen cases where the PHP script timed out / Host Gator killed 
it because it took too long.

I wonder if that's happening here.

It might be time to move our gitdub.php script stuff to Open MPI's AWS 
infrastructure, where no such disk and time limits exist...


> On Feb 8, 2017, at 10:24 AM, Brice Goglin <brice.gog...@inria.fr> wrote:
> 
> FWIW, I didn't get the commit email either, and I am pretty sure it's
> not the first time it happens. There are no archives for this ML, do we
> have a way to see the logs of the emailing script that runs on github ?
> 
> Brice
> 
> 
> 
> Le 08/02/2017 16:19, Jeff Squyres (jsquyres) a écrit :
>> On Feb 7, 2017, at 12:12 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> 
>> wrote:
>>> Fair enough, but the test itself is just a switch/case statement -- it's 
>>> not an actual test to see if the system supports binding or not.  Hence, 
>>> hedging the warning message a little seemed reasonable.
>> I see you actually reverted my commit (somehow I didn't get an email about 
>> that -- I only noticed it by chance today on GitHub.com).
>> 
>> 1. You reverted an actual grammar fix: "support" -> "supported".
>> 
>> 2. I don't think that "likely" is bad to have.  Like I said above, the test 
>> itself is just a switch/case test based on a hard-coded list of OSs.  The 
>> test does not *actually* test to see if the system supports binding.  So 
>> weakening the language a little to say "likely" is not necessarily a bad 
>> thing.
>> 
>> Sure, in some (most? all?) cases, the likelihood of not supporting binding 
>> will be 100%.  But a) that doesn't mean the use of "likely" is incorrect, 
>> and b) allows for the possibility of not supporting binding to be less than 
>> 100% in some future / unpredicted system.
>> 
>> "Always" (and words/phrasing like it) is a very, very strong word.  It 
>> should be avoided when possible.
>> 
> 
> ___
> hwloc-devel mailing list
> hwloc-devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com

___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/hwloc-devel

Re: [hwloc-devel] hwloc.m4: minor english fixes

[Jeff Squyres (jsquyres)]

On Feb 7, 2017, at 11:48 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:
> 
>> -AC_MSG_WARN([*** and binding will not be support.])
>> +AC_MSG_WARN([*** and binding will likely not be supported.])
> 
> Well, it's not really "likely": unsupported systems really won't have
> binding support.  For getting the number of processors we have a couple
> of more or less generic ways, but for binding we don't have any.

Fair enough, but the test itself is just a switch/case statement -- it's not an 
actual test to see if the system supports binding or not.  Hence, hedging the 
warning message a little seemed reasonable.

-- 
Jeff Squyres
jsquy...@cisco.com

___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/hwloc-devel

Re: [hwloc-devel] Git: open-mpi/hwloc annotated tag hwloc-1.11.5 deleted. hwloc-1.11.5

[Jeff Squyres (jsquyres)]

On Nov 25, 2016, at 7:31 AM, Brice Goglin <brice.gog...@inria.fr> wrote:
> 
> FWIW, I am trying to remove github automatic "release" tarballs from
> the github page but it actually removes the corresponding git tag.
> 
> Those releases are not autogen'ed, do not contain the doc, etc.
> Users are confused when they download tarballs from github instead of
> from the hwloc website.
> 
> If anybody has a solution to hide or delete those github tarballs
> without removing git tags, please let me know.

I haven't found a way to disable github from providing those "release" 
tarballs, either.  :-\

Other projects (e.g., libfabric) actually put their release tarballs up on 
Github: https://github.com/ofiwg/libfabric/releases.  This still includes the 
un-bootstrapped tarballs, but the bootstrapped tarballs are more prominent, and 
it therefore diminishes the issue.

We haven't chosen to do this for most Open MPI projects, but it might be a 
possibility.  If nothing else, if it's a serious problem for your users, you 
could duplicate posting the hwloc tarballs to 
https://github.com/open-mpi/hwloc/releases.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/hwloc-devel

[hwloc-devel] Open MPI mail archives now back online

[Jeff Squyres (jsquyres)]

mail-archive.com now has all of the old Open MPI mail archives online.  Example:

https://www.mail-archive.com/users@lists.open-mpi.org/
https://www.mail-archive.com/devel@lists.open-mpi.org/

Note that there are two different ways you can permalink to messages on 
mail-archive:

1. Take the "main" URL of the message (i.e., the one shown in the address bar 
when you're viewing a message) -- e.g.

https://www.mail-archive.com/users@lists.open-mpi.org/msg28978.html

2. Use the message ID (which uniquely identifies a message) in the form:

http://mid.mail-archive.com/MESSAGE_ID
NOTE: http, not https!

e.g.


http://mid.mail-archive.com/1233038409.12589.1460577425350.JavaMail.yahoo@mail.yahoo.com

The index on each of the mailing lists is a sliding window that only lasts for 
a few thousand messages, but *all* messages are available (even if they're not 
listed on the index pages):

- via their permalinks
- via Google search (give Google a little while to finish indexing all the new 
messages we recently uploaded to mail-archive.com)
- via the mail-archive.com web site search box

Finally, all of the old Open MPI mail archives are still available under 
https://www.open-mpi.org/community/lists/ (so that we don't break lots of old 
links from around the web), but they are frozen.  No new messages have been 
added to the frozen archive since late July 2016 or so.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

___
hwloc-devel mailing list
hwloc-devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/hwloc-devel

Re: [hwloc-devel] This list is suspended while migrating

[Jeff Squyres (jsquyres)]

We unfortunately ran into major issues while trying to migrate these lists, and 
have therefore restored them back on the Indiana U servers until we try the 
migration again.

Sorry for the hassle folks; stay tuned!


> On Jul 20, 2016, at 10:28 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> 
> wrote:
> 
> We are beginning the list migration process; this list will be suspended 
> while it is in transit to a new home.
> 
> We can't predict the exact timing of the migration -- hopefully it'll only 
> take a few hours.
> 
> See you on the other side!
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] This list is suspended while migrating

[Jeff Squyres (jsquyres)]

We are beginning the list migration process; this list will be suspended while 
it is in transit to a new home.

We can't predict the exact timing of the migration -- hopefully it'll only take 
a few hours.

See you on the other side!

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] This list is migrating!

[Jeff Squyres (jsquyres)]

Short version
=

The server for this mailing list will be migrating sometime soon (the exact 
timing is not fully predictable).  Three things you need to know:

1. We'll send a "This list is now closed for migration" last message when the 
migration starts
2. We'll send a "This list is now open again" first message when the migration 
completes
3. The list email address will move from @open-mpi.org to @lists.open-mpi.org

More detail
===

The Open MPI hosting infrastructure is slowly moving away from its home of 10+ 
years: our gracious hosts at Indiana University (thank you for all the help and 
support, IU!).  The next pieces to migrate are the Open MPI project mailing 
lists (including this one).

The exact timing of the migration depends on our new hosting provider vendor; 
it's quite difficult to give an exact timeline.  The procedure will generally 
be something like this:

1. Send the final "This list is now closed!" email across this list
2. Shut off all incoming mail to the list
3. Shut down the web pages that allow users to make changes to the list
4. Bundle up all the list data and send it to our new hosting provider
5. Work with the provider to get the new lists online
6. Send a "This list is now open again!" email across the list

As noted above, we're changing the hostnames on the mailing lists to 
@lists.open-mpi.org so that we can de-couple the mailing lists from the rest of 
the web hosting infrastructure.  Please update your addressbook and mail 
filters appropriately.

Webified archives of the mailing lists will continue to be available:

1. Once the migration completes, the existing web archives (under, for example, 
https://www.open-mpi.org/community/lists/users/) will continue to be available, 
but they'll be frozen -- no new messages will be added there.  Specifically: 
links to old posts will continue to work.
2. New web archives for all the lists -- to include all the old posts -- will 
become available elsewhere.  Specifics will be included in the "The list is now 
open again!" mail.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Using Hwloc in LLVM OpenMP

[Jeff Squyres (jsquyres)]

On May 18, 2015, at 3:03 PM, Brice Goglin <brice.gog...@inria.fr> wrote:
> 
> (3) it won't replace autotools since we have autotools-projects embedding 
> hwloc. if we can have both autotools and cmake without too much trouble, I 
> guess it's ok

Since cmake likely won't be the main configure/build system for the core 
developers, it is going to be a challenge to keep the cmake build system 
up-to-date as changes are made in the autotools-based build system.

(I speak from experience: we had a cmake build system in Open MPI for a while 
for Windows support that was constructed / maintained along side the autotools 
configure/build system, and it was continually out of date :-( )

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Lhwloc1 duplicate symbol issue

[Jeff Squyres (jsquyres)]

On Mar 25, 2015, at 4:14 PM, Brice Goglin <brice.gog...@inria.fr> wrote:
> 
> Looks like I missed something in the OMPI discussion:
> When you say symbol, do you mean asm label?
> include/private/cpuid-x86.h: Assembler messages:
> include/private/cpuid-x86.h:40: Error: symbol `Lhwloc1' is already defined
> Like in the mail included at the end of
> http://www.open-mpi.org/community/lists/hwloc-users/2014/11/1119.php

(sorry it took me a few days to get back to this)

Yes, exactly like this.

> This is fixed by
> https://github.com/open-mpi/hwloc/commit/790aa2e1e62be6b4f37622959de9ce3766ebc57e
> (applied to all stable branches 4 month ago)

Got it.  Looks like we didn't grab it in OMPI because there was never an hwloc 
1.9.2.

> This is actually one of the reason why OMPI upgraded to hwloc v1.9. But
> I thought they were going to upgrade to hwloc v1.9 git HEAD, while they
> only went to v1.9.1, which does not contain this fix.

Makes sense.

> There's a stable release/branch issue here. hwloc updates stable
> *branches* up to what OMPI uses (hwloc v1.8), but usually we only
> publish stable *releases* on the last stable branch (v1.10). We need to
> clarify if OMPI wants official hwloc releases only, or if applying
> (possibly many) hwloc patches is OK.

Here's what I just did -- I grabbed all (relevant) hwloc 1.9 commits (including 
the dup symbol fix):

https://github.com/open-mpi/ompi/pull/498

We usually only grab actual releases, but the OMPI v1.8 series is coming to a 
close, so I think that this is ok.

This PR is actually for OMPI master; once it shakes out ok on master, we'll PR 
it over to OMPI v1.8.  Once that has all completed, we'll likely want to 
upgrade OMPI master to hwloc v1.10.1 (which includes this Lhwloc1 fix).

Howzat?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Coverity

[Jeff Squyres (jsquyres)]

On Feb 14, 2015, at 8:57 AM, Brice Goglin <brice.gog...@inria.fr> wrote:
>> Brice: do you have a nightly coverity submission script running somewhere?
> 
> No, I just run it manually from time to time.

Do you want it to run automated?  We can run the script at IU.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Coverity

[Jeff Squyres (jsquyres)]

I added a bunch of components into the hwloc coverity setup, as well as a dummy 
model file (so that coverity doesn't complain that hwloc is not fully 
configured).

Brice: do you have a nightly coverity submission script running somewhere?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Git: open-mpi/hwloc branch master updated. 85ea6e4acc456d398fa995d671960ccc0dff0d42

[Jeff Squyres (jsquyres)]

gt; pcidev->func;
> +
> +obj = hwloc_alloc_setup_object(HWLOC_OBJ_PCI_DEVICE, os_index);
> +obj->attr->pcidev.domain = domain;
> +obj->attr->pcidev.bus = pcidev->bus;
> +obj->attr->pcidev.dev = pcidev->dev;
> +obj->attr->pcidev.func = pcidev->func;
> +obj->attr->pcidev.vendor_id = pcidev->vendor_id;
> +obj->attr->pcidev.device_id = pcidev->device_id;
> +obj->attr->pcidev.class_id = device_class;
> +obj->attr->pcidev.revision = config_space_cache[PCI_REVISION_ID];
> +
> +obj->attr->pcidev.linkspeed = 0; /* unknown */
> +offset = hwloc_pci_find_cap(config_space_cache, PCI_CAP_ID_EXP);
> +
> if (offset > 0 && offset + 20 /* size of PCI express block up to link 
> status */ <= CONFIG_SPACE_CACHESIZE)
>   hwloc_pci_find_linkspeed(config_space_cache, offset, 
> >attr->pcidev.linkspeed);
> 
> 
> 
> ---
> 
> Summary of changes:
> hwloc/topology-pci.c | 41 ++---
> 1 file changed, 22 insertions(+), 19 deletions(-)
> 
> 
> hooks/post-receive
> -- 
> open-mpi/hwloc
> ___
> hwloc-commits mailing list
> hwloc-comm...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-commits


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] upcoming feature removal

[Jeff Squyres (jsquyres)]

On Nov 4, 2014, at 9:10 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

>> - pu_children
>> - io_children
>> - misc_children
> 
> OK but what does "pe" stand for? did you mean "pu" to match our PU objects?

I said "pu_children".  Really.  I didn't edit the text above and make it look 
like I didn't typo in the original email.  Really.  Trust me.

:-)

(yes, I meant "pu")

> Unfortunately, children are more than a single field in struct hwloc_obj :)
> 
>  unsigned arity;   /**< \brief Number of children */
>  struct hwloc_obj **children;  /**< \brief Children, \c children[0 .. 
> arity -1] */
>  struct hwloc_obj *first_child;/**< \brief First child */
>  struct hwloc_obj *last_child; /**< \brief Last child */
> 
> I'll review the code to see if we can easily remove first/last_child or so.

My 2 main points:

1. if we're going to have multiple lists, then we might as well call them -- 
and all the related data accompanying them (e.g., first/last_child) what they 
are.  Don't just have "children" and "misc" -- have specific names denoting 
what they are.

2. If we know we're going to have io devices, and we're going to separate them 
out from (pu_)children, then we might as well have a specific list for them.

> So on current x86 machines, we would have this?
> * one level with L1 object with cache attribute "Data"
> * one level with L1 object with cache attribute "Instruction"
> * one level with L2 object with cache attribute "Unified"
> * one level with L3 object with cache attribute "Unified"
> 
> Fortunately, instruction caches are disabled by default (unless somebody
> wants to change that?) so most application will see a single L1 level.

To be honest, I'm not sure what the Right answer is.  It would certainly be 
nice to be able to have a single switch/case to be able to identify all the 
different types of topology items, including the differences between the 
different caches.

Perhaps it would be sufficient to be able to combine the type and the cache 
type together somehow -- e.g., the cache type could be bit-shifted up above the 
type bits, and then you could switch/case on the combined value...?  (waving 
hands furiously...)

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] upcoming feature removal

[Jeff Squyres (jsquyres)]

On Nov 3, 2014, at 5:49 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> * don't put I/O objects in "normal" children since it confuses programs
> consulting the children list. rather place them under a dedicated child
> pointer special objects such as Misc may go there as well.

If you're going to separate them from the normal "children", then how about 
naming them for what they are?  E.g.:

- pe_children
- io_children
- misc_children

> * stop having 4 cpusets and 3 nodesets per object and just have 1 cpuset
> and 1 nodeset depending on topology flags (only allowed, or only online,
> etc). possibly with ways to switch between modes at runtime

No, please don't do this.  For big code bases like Open MPI, we don't know how 
the different consumers of hwloc will use the information.  So we get all of 
the topo information once, at the beginning of time.  Various different plugins 
and different parts of OMPI may want different information, and it would kinda 
defeat the point if they had to re-scan the topo because we didn't initially 
get the information that they needed.

> * stop having a CACHE type + data/instruction/unified + depth, and just
> have one type for each of them, such as HWLOC_OBJ_CACHE_L1d. the
> advantage is that you can switch (type) without special-casing the CACHE
> subtypes. One drawback is that there are many subtypes in existing
> machines (at least L1[id], L2[idu], L3[idu], L4u).

Samuel has a good point about "where will it end?".

But I also agree that it's pretty annoying (and Ralph has [rightfully] 
complained a bunch) to have to special-case the check for the various caches -- 
it has caused a bunch of code churn in OMPI.

How about making enums for L1 through L5?  That's more than any architecture 
has today, and gives us a bit of future-proofing.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] hwloc version number

[Jeff Squyres (jsquyres)]

Errr... I got the patch slightly wrong.  The one added line should include the 
".$HWLOC_RELEASE_VERSION" at the end.  You get the idea...


On Oct 1, 2014, at 8:50 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote:

> We just changed the version numbering scheme over in OMPI to always be 
> "a.b.c", even if c==0.  Do we want the same thing in hwloc?
> 
> Right now, hwloc uses the old OMPI versioning scheme -- it's "a.b.c", except 
> when c==0, and then the version is "a.b".
> 
> It's a pretty simple change:
> 
> diff --git a/config/hwloc_get_version.sh b/config/hwloc_get_version.sh
> index 45139f4..4a3d201 100755
> --- a/config/hwloc_get_version.sh
> +++ b/config/hwloc_get_version.sh
> @@ -43,12 +43,7 @@ else
>p" < "$srcfile"`
>eval "$ompi_vers"
> 
> -# Only include the release version if it isn't 0
> -if test $HWLOC_RELEASE_VERSION -ne 0 ; then
> -
> HWLOC_VERSION="$HWLOC_MAJOR_VERSION.$HWLOC_MINOR_VERSION.$HWLOC_REL
> -else
> -HWLOC_VERSION="$HWLOC_MAJOR_VERSION.$HWLOC_MINOR_VERSION"
> -fi
> +HWLOC_VERSION="$HWLOC_MAJOR_VERSION.$HWLOC_MINOR_VERSION"
> HWLOC_VERSION="${HWLOC_VERSION}${HWLOC_GREEK_VERSION}"
> 
> # If HWLOC_SNAPSHOT=1, then use HWLOC_SNAPSHOT_VERSION
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
> Searchable archives: 
> http://www.open-mpi.org/community/lists/hwloc-devel/2014/10/index.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] hwloc version number

[Jeff Squyres (jsquyres)]

We just changed the version numbering scheme over in OMPI to always be "a.b.c", 
even if c==0.  Do we want the same thing in hwloc?

Right now, hwloc uses the old OMPI versioning scheme -- it's "a.b.c", except 
when c==0, and then the version is "a.b".

It's a pretty simple change:

diff --git a/config/hwloc_get_version.sh b/config/hwloc_get_version.sh
index 45139f4..4a3d201 100755
--- a/config/hwloc_get_version.sh
+++ b/config/hwloc_get_version.sh
@@ -43,12 +43,7 @@ else
p" < "$srcfile"`
eval "$ompi_vers"
 
-# Only include the release version if it isn't 0
-if test $HWLOC_RELEASE_VERSION -ne 0 ; then
-HWLOC_VERSION="$HWLOC_MAJOR_VERSION.$HWLOC_MINOR_VERSION.$HWLOC_REL
-else
-HWLOC_VERSION="$HWLOC_MAJOR_VERSION.$HWLOC_MINOR_VERSION"
-fi
+HWLOC_VERSION="$HWLOC_MAJOR_VERSION.$HWLOC_MINOR_VERSION"
 HWLOC_VERSION="${HWLOC_VERSION}${HWLOC_GREEK_VERSION}"
 
 # If HWLOC_SNAPSHOT=1, then use HWLOC_SNAPSHOT_VERSION


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

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

[Jeff Squyres (jsquyres)]

On Sep 22, 2014, at 6:55 PM, Brice Goglin <brice.gog...@inria.fr> wrote:

>> HWLOC already provides similar info for processors and mother boards, so it 
>> seemed a natural extension of current capabilities to provide it for other 
>> system elements.
> 
> Disk vendor/model is easy to add from sysfs on Linux. I don't know where
> to find the serial number. Spindle speed may require more than just
> sysfs. Do you have more info on how to get these attributes?
> 
> For memory, we currently have a single memory object for all DIMMs of a
> single NUMA node. Adding multiple objects may not be useful, but adding
> many serials to a single NUMA object may be ugly.
> There are some information about physical memory in
> /sys/devices/system/node/node0/memory* but it doesn't correspond to
> DIMMs (I have 135 of them on my laptop for only 2 SODIMMs). dmidecode
> gets DIMM info somehow.

Back in Nehalem days, it wasn't possible to map Linux kernel "physical" memory 
back to individual DIMMs (because the BIOS could/would introduce another layer 
of kernel<-->DIMM mapping that the kernel might not be aware of).

Has that changed?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] One more Github-inspired change...

[Jeff Squyres (jsquyres)]

I forgot to mention: now that the hwloc-svn list was renamed to hwloc-commits, 
I have disallowed anyone from posting to it.  Only the gitdub mailer is allowed 
to post to that list.  Replied to such posts are automatically directed to 
hwloc-devel.

But note that github offers nice code annotation/review tools -- depending on 
the situation, you may want to use (e.g., for fine-grained, detailed replies) 
those instead of replying to hwloc-commits mails, anyway.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] hwloc now 100% at Github

[Jeff Squyres (jsquyres)]

hwloc's git repo has been at Github for a long now.  As of this morning:

- hwloc's tickets are now Github issues
  https://github.com/open-mpi/hwloc/issues

- hwloc's wiki is now on the Github wiki
  https://github.com/open-mpi/hwloc/wiki

- hwloc's git diff emails are being fired via gitdub (not cron)
  ***NOTE: the mailing list is now hwloc-commits (not hwloc-svn)

So I think we're finally 100% Github for hwloc.

Enjoy!

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Migrate Trac tickets -> Github issues

[Jeff Squyres (jsquyres)]

Cool.  I'm going to wait until I hear from Brice (I think he might be 
traveling?); I don't want to spam him with a zillion emails.


On Sep 12, 2014, at 7:58 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:

> Jeff Squyres (jsquyres), le Fri 12 Sep 2014 10:44:03 +, a écrit :
>> I did a test import of hwloc's Trac tickets to githib -- what do you think?
>> 
>>https://github.com/ompiteam/hwloc-test-ticket-import/issues
> 
> It looks good to me.
> 
> I have unwatched the github hwloc project.
> 
> Samuel
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/hwloc-devel/2014/09/4214.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Migrate Trac tickets -> Github issues

[Jeff Squyres (jsquyres)]

Samuel / Brice --

I did a test import of hwloc's Trac tickets to githib -- what do you think?

https://github.com/ompiteam/hwloc-test-ticket-import/issues

If you like it, I'll re-do the import over to the main hwloc repo, and we can 
then fully abandon Trac.  There will be one important difference between this 
import and the final/actual import: the tickets will be assigned to the proper 
IDs.

All tickets will still be created and updated by the "ompiteam" user for the 
initial import, because that's the user who is creating all these initial 
tickets.  But any future activity will obviously be by our own usernames.

NOTE: for me to do the final import on the hwloc repo, you *need* to "unwatch" 
the hwloc repo.  Otherwise, Github will send you a mail for *every single 
ticket and comment created*.  When the import is done (it only takes a few 
minutes because there's only a few dozen tickets), you can set your watching 
back to the normal level.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Stop updating Trac wiki (Github migration)

[Jeff Squyres (jsquyres)]

Yoinks!

Autocomplete in my email client sent this to the wrong list... hwloc conversion 
is already done.  This message was meant for the main Open MPI developers list, 
not the hwloc list.

Sorry for the noise...


On Sep 9, 2014, at 12:03 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote:

> As part of our migration to Github, there are three main things to convert:
> 
> 1. SVN -> Git
> 2. Trac wiki -> Github markdown
> 3. Track tickets -> Github issues
> 
> I have a good automated solution for #1; that can be run whenever we're ready 
> to switchover.
> 
> I used an 80% automated solution for #2 (i.e., a bunch of regexps), and then 
> did a bunch of manual fixups for what the regexps didn't catch.  You can see 
> the result here (temporarily):
> 
>https://github.com/jsquyres/ompi-test/wiki
> 
> *** PLEASE DO NOT UPDATE THE TRAC WIKI ANY MORE!  The trac wiki page 
> conversion is basically done, and I don't intend to do it again.
> 
> Meaning: if you make any updates to the Trac wiki, they won't be brought over 
> to the new github wiki.
> 
> Lastly, I'm just starting to see about converting Trac tickets to Github 
> issues.  I'll be working on that this week, and hope to have updated 
> information for everyone for next Tuesday's call.
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/hwloc-devel/2014/09/4208.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Stop updating Trac wiki (Github migration)

[Jeff Squyres (jsquyres)]

As part of our migration to Github, there are three main things to convert:

1. SVN -> Git
2. Trac wiki -> Github markdown
3. Track tickets -> Github issues

I have a good automated solution for #1; that can be run whenever we're ready 
to switchover.

I used an 80% automated solution for #2 (i.e., a bunch of regexps), and then 
did a bunch of manual fixups for what the regexps didn't catch.  You can see 
the result here (temporarily):

https://github.com/jsquyres/ompi-test/wiki

*** PLEASE DO NOT UPDATE THE TRAC WIKI ANY MORE!  The trac wiki page conversion 
is basically done, and I don't intend to do it again.

Meaning: if you make any updates to the Trac wiki, they won't be brought over 
to the new github wiki.

Lastly, I'm just starting to see about converting Trac tickets to Github 
issues.  I'll be working on that this week, and hope to have updated 
information for everyone for next Tuesday's call.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Fwd: [OMPI svn-full] svn:open-mpi r32675 - in trunk/opal/mca/hwloc/hwloc191/hwloc: include/hwloc src

[Jeff Squyres (jsquyres)]

R_SIZE:
> - diff->obj_attr.diff.uint64.oldvalue = strtoull(obj_attr_oldvalue_s, 
> NULL, 0);
> - diff->obj_attr.diff.uint64.newvalue = strtoull(obj_attr_newvalue_s, 
> NULL, 0);
> + diff->obj_attr.diff.ui64.oldvalue = strtoull(obj_attr_oldvalue_s, NULL, 
> 0);
> + diff->obj_attr.diff.ui64.newvalue = strtoull(obj_attr_newvalue_s, NULL, 
> 0);
>   break;
>   case HWLOC_TOPOLOGY_DIFF_OBJ_ATTR_INFO:
>   diff->obj_attr.diff.string.name = strdup(obj_attr_name_s);
> @@ -1154,11 +1154,11 @@
> 
>   switch (diff->obj_attr.diff.generic.type) {
>   case HWLOC_TOPOLOGY_DIFF_OBJ_ATTR_SIZE:
> - sprintf(tmp, "%llu", (unsigned long long) 
> diff->obj_attr.diff.uint64.index);
> + sprintf(tmp, "%llu", (unsigned long long) 
> diff->obj_attr.diff.ui64.index);
>   state.new_prop(, "obj_attr_index", tmp);
> - sprintf(tmp, "%llu", (unsigned long long) 
> diff->obj_attr.diff.uint64.oldvalue);
> + sprintf(tmp, "%llu", (unsigned long long) 
> diff->obj_attr.diff.ui64.oldvalue);
>   state.new_prop(, "obj_attr_oldvalue", tmp);
> - sprintf(tmp, "%llu", (unsigned long long) 
> diff->obj_attr.diff.uint64.newvalue);
> + sprintf(tmp, "%llu", (unsigned long long) 
> diff->obj_attr.diff.ui64.newvalue);
>   state.new_prop(, "obj_attr_newvalue", tmp);
>   break;
>   case HWLOC_TOPOLOGY_DIFF_OBJ_ATTR_NAME:
> ___
> svn-full mailing list
> svn-f...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] hwloc wiki on github

[Jeff Squyres (jsquyres)]

The hwloc wiki -- all 5 pages of it :-) -- is now officially on github:

   https://github.com/open-mpi/hwloc/wiki

The Trac wiki is now deprecated.

(...conversion of Trac tickets is still in the works...)

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Migrating Trac wiki and tickets to Github

[Jeff Squyres (jsquyres)]

As part of moving the final OMPI SVN repo to Github, we're also converting the 
Trac wiki and tickets.

I have a first attempt at converting the hwloc trac wiki to Github's Markdown:

https://github.com/jsquyres/hwloc-test/wiki

If this looks good (from a conversion standpoint -- at least some of the 
content needs to be updated for Github), I can move it to the real hwloc Github 
wiki.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] --enable-plugins broken

[Jeff Squyres (jsquyres)]

Good enough; thanks for the refresher. :)

Sent from my phone. No type good. 

> On Aug 18, 2014, at 2:07 PM, "Brice Goglin" <brice.gog...@inria.fr> wrote:
> 
> Le 18/08/2014 20:37, Jeff Squyres (jsquyres) a écrit :
>> I notice that --enable-plugins seems to be broken -- it always ends in:
>> 
>> configure: WARNING: Plugin support requested, but could not find ltdl.h
>> configure: error: Cannot continue
>> 
>> if you don't have libltdl installed.  Is this intentional?  I.e., have we 
>> already relied on an external libltdl?  Or have we previously embedded 
>> libltdl (via LT_CONFIG_LTDL_DIR), and it has just bit-rotted?
> 
> We had both external and embedded ltdl support in the beginning. We
> removed embedded in 1.7.1.
> Brice
> 
> 
> commit 7491172a4754b0e198f699cb31b7c65c59ac4df6
> Author: Brice Goglin <brice.gog...@inria.fr>
> Date:   Wed May 15 08:15:49 2013 +
> 
>Stop embedding libltdl, always use the system-wide libltdl
> 
>The ltdl embedding caused problems to the hwloc embedding such as
>  http://www.open-mpi.org/community/lists/hwloc-devel/2013/04/3659.php
>We fixed the embedding AM_CONDITIONAL problem in
>  https://svn.open-mpi.org/trac/hwloc/changeset/5605
>but the generated tarballs now (sometimes) miss libltdl,
>causing configure to break.
>The patch in the first link above worked around that issue but...
> 
>* Embedding ltdl is useful when you rely on recent ltdl features,
>  while ltdl 1.5 (couldn't test earlier) looks OK for hwloc,
>  and that version is very old and available everywhere.
>* the ltdl embedding ability isn't perfect in "recursive" mode
>  (we had a hack for its config.h file in our configure
>   see http://lists.gnu.org/archive/html/libtool/2012-08/msg00016.html)
>* we only need ltdl when --enable-plugins (not by default)
> 
>That's enough reasons to consider not embedding ltdl anymore.
>We now require people to install libltdl-dev/libtool-ltdl-dev
>if they want plugins.
> 
>This commit was SVN r5618.
> 
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/hwloc-devel/2014/08/4176.php

[hwloc-devel] --enable-plugins broken

[Jeff Squyres (jsquyres)]

I notice that --enable-plugins seems to be broken -- it always ends in:

configure: WARNING: Plugin support requested, but could not find ltdl.h
configure: error: Cannot continue

if you don't have libltdl installed.  Is this intentional?  I.e., have we 
already relied on an external libltdl?  Or have we previously embedded libltdl 
(via LT_CONFIG_LTDL_DIR), and it has just bit-rotted?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] patch to execute command when using hwloc-bind --get

[Jeff Squyres (jsquyres)]

How about displaying a warning if --get is specified but a command to execute 
is also specified?

Sent from my phone. No type good. 

> On Aug 13, 2014, at 5:22 AM, "John Donners"  wrote:
> 
> Hi Brice,
> 
>> On 13-08-14 10:46, Brice Goglin wrote:
>> Hello,
>> 
>> Can you elaborate how you would use this?
>> 
>> The intend of the current behavior is:
>> 1) if the target task already runs, use "hwloc-bind --pid  --get"
>> without any command since you have pid already
> this behaviour stays the same with the patch.
>> 2) you just want to check whether the upcoming binding works, so you
>> just do something like "mpirun  hwloc-bind --get" or "srun ...
>> hwloc-bind --get"
>> 
>> Do you want a mode that creates a new task and displays it binding?
> indeed.
>> Looks similar to passing "hwloc-bind --get ; newtask" to srun or mpirun ?
> the syntax would then be something like:
> 
> mpirun -n 2 bash -c "hwloc-bind --get ; newtask"
> 
> it's possible, but quite ugly.
> 
> With regards,
> John
>> 
>> Brice
>> 
>> 
>> 
>> Le 13/08/2014 10:38, John Donners a écrit :
>>> Hi,
>>> 
>>> I was somewhat surprised to notice that hwloc-bind doesn't
>>> execute the command if the --get option is used. This could
>>> come in handy to check the binding set by other programs,
>>> e.g. SLURM, mpirun or taskset. The following patch would
>>> change this.
>>> 
>>> --- hwloc-1.9/utils/hwloc-bind.c2014-03-17 16:42:36.0 +0100
>>> +++ hwloc-1.9/utils/hwloc-bind.c.getproc2014-08-13
>>> 10:24:17.832682576 +0200
>>> @@ -301,7 +301,9 @@
>>>  else
>>>printf("%s\n", s);
>>>  free(s);
>>> -return EXIT_SUCCESS;
>>> +if (get_last_cpu_location) {
>>> +  return EXIT_SUCCESS;
>>> +}
>>>}
>>>  if (got_membind) {
>>> 
>>> Please consider this change for the next release of hwloc.
>>> 
>>> With regards,
>>> John
>>> 
>>> 
>>> | John Donners | Senior adviseur | Operations, Support & Development |
>>> SURFsara | Science Park 140 | 1098 XG Amsterdam | Nederland |
>>> T (31)6 19039023 | john.donn...@surfsara.nl | www.surfsara.nl |
>>> 
>>> Aanwezig op | ma | di | wo | do | vr
>>> 
>>> ___
>>> hwloc-devel mailing list
>>> hwloc-de...@open-mpi.org
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>>> Link to this post:
>>> http://www.open-mpi.org/community/lists/hwloc-devel/2014/08/4171.php
>> ___
>> hwloc-devel mailing list
>> hwloc-de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/hwloc-devel/2014/08/4172.php
> 
> 
> -- 
> Probeer de SURFsara app! Beschikbaar voor iOS en Android.
> 
> | John Donners | Senior adviseur | Operations, Support & Development | 
> SURFsara | Science Park 140 | 1098 XG Amsterdam | Nederland |
> T (31)6 19039023 | john.donn...@surfsara.nl | www.surfsara.nl |
> 
> Aanwezig op | ma | di | wo | do | vr
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/hwloc-devel/2014/08/4172.php

[hwloc-devel] PATCH: Mark fd as close-on-exec

[Jeff Squyres (jsquyres)]

Any objections to this patch?  In OMPI, we're seeing this fd leak into child 
processes.

diff --git a/src/topology-linux.c b/src/topology-linux.c
index e934d4c..8c5fba1 100644
--- a/src/topology-linux.c
+++ b/src/topology-linux.c
@@ -4601,6 +4601,13 @@ hwloc_linux_component_instantiate(struct hwloc_disc_compo
 data->is_real_fsroot = 0;
   }
 
+  /* Since this fd stays open after hwloc returns, mark it as
+ close-on-exec so that children don't inherit it */
+  if (fcntl(root, F_SETFD, FD_CLOEXEC) == -1) {
+  close(root);
+  root = -1;
+  goto out_with_data;
+  }
 #else
   if (strcmp(fsroot_path, "/")) {
 errno = ENOSYS;

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Slowly moving to git

[Jeff Squyres (jsquyres)]

As many of you have noticed, we've been moving more repositories from SVN to 
git.  This email is a summary of where we are and what the (current) overall 
plan is. 

So far, the following repos are hosted in the Open MPI community at github:

1. hwloc (integrated with Trac at IU)
2. hwloc-debian
3. netloc (integrated with Trac at IU)
4. OMPI user-level documentation
5. ompi-www

The last one was just moved yesterday.  All have diff emails sent from IU 
(because github will not send diff emails).

In short: we are slowly moving all of our SVN repos to git because git has some 
nicer features than SVN (we've discussed these reasons ad nauseam; I won't 
repeat them here).

We're moving them to github instead of hosting them at IU because github 
*focuses* on git hosting.  They have far more resources dedicated to making 
slick git/web collaboration tools than IU.  IU has actually been pretty awesome 
to the Open MPI community over the years, but asking them to build up an 
entirely new git-hosting/collaboration infrastructure seems like asking for too 
much.  Github already exists and is pretty good.

Keep in mind that we're doing this migration fairly slowly.  We're trying to 
learn with the smaller sub-projects first.  ***Remember that it's not just 
about migrating from SVN to git, but also migrating a fair amount of 
infrastructure, too: SVN history, Trac data, automated tarball building, 
...etc.  And don't forget that the repo history and Trac data all needs to be 
selectively edited during the conversion to replace things like "r1234" in 
commit messages and trac comments to a git hash.

The hwloc SVN->git conversion was a major learning point; we have a bunch of 
conversion scripts that resulted from that effort.  Those scripts will play a 
large part in converting the remaining SVN repos to git.

As part of this overall effort, I've listed all the parts of infrastructure 
that the overall Open MPI project uses on a wiki page:

https://svn.open-mpi.org/trac/ompi/wiki/infrastructure

Upcoming plans:

1. IU is working to upgrade the Trac/Github integration (probably next week).

2. Ralph is going to populate an orcm github repo in the Open MPI github 
community (later this week/next week); that will be repo #6.

3. IU is also working to upgrade the Github diff email integration (probably 
next week).

4. The MTT SVN repo is probably the next target for conversion.  The ompi-www 
repo didn't have a Trac, and we didn't bother to import any of the SVN history, 
so the conversion was "relatively simple".  But MTT will be another full-blown 
conversion (history and Trac and all), and will help us refine the scripts / 
procedures we used from the hwloc conversion.

5. After that, the ompi-tests SVN repo is a good target for conversion.  This 
repo has the property of being private, however, and private repos cost money 
on github ($300/year is the lowest tier).  We'll have to talk about/figure out 
who is going to pay for that.

6. Perhaps by this summer we'll be able to start talking about converting the 
main OMPI SVN to git.  This repo is, by far, the biggest of the OMPI repos (in 
terms of number of commits), and will likely take the most time/effort to 
convert.  We'll also need to talk about:

- how to handle permissions on release branches (git doesn't have the same kind 
of directory-based permissions that we do in SVN)
- end-of-life the bitbucket/hg mirror

Hope this helps explain the current direction.  Please feel free to reply with 
questions / comments / offers to help.  :-)

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] GIT: hwloc branch master updated. 0e6fe307c10d47efee3fb95c50aee9c0f01bc8ec

[Jeff Squyres (jsquyres)]

How about this:

diff --git a/config/distscript.sh b/config/distscript.sh
index d7bdfa4..9f05a2f 100755
--- a/config/distscript.sh
+++ b/config/distscript.sh
@@ -69,7 +69,7 @@ fi
 # Trivial helper function
 doit() {
 echo $*
-$*
+eval $*
 }
 
 echo "*** Copying doxygen-doc tree to dist..."
@@ -77,7 +77,26 @@ echo "*** Directory: srcdir: $srcdir, distdir: $distdir, pwd:
 doit mkdir -p $distdir/doc/doxygen-doc
 doit chmod -R a=rwx $distdir/doc/doxygen-doc
 doit rm -rf $distdir/doc/doxygen-doc
-doit cp -rpf $srcdir/doc/doxygen-doc $distdir/doc
+
+# We want to copy the entire directory tree to the distdir.  In some
+# cases, doxygen-doc may be a sym link, so we want the copy to follow
+# the sym links.  It's a bit of a portability nightmare, so try a few
+# different ways...
+# This seems to work on OS X and Linux (but not Solaris)
+doit "tar c -C $srcdir -h -f - doc/doxygen-doc | tar x -C $distdir -f -"
+if test ! -d $distdir/doc/doxygen-doc; then
+# This seems to work on Linux and Solaris
+doit cp -rpf $srcdir/doc/doxygen-doc/ $distdir/doc
+fi
+if test ! -d $distdir/doc/doxygen-doc; then
+# This seems to work on OS X (probably redundant, but we know it works)
+doit cp -rpf $srcdir/doc/doxygen-doc $distdir/doc
+fi
+# If we still failed, just error out
+if test ! -d $distdir/doc/doxygen-doc; then
+echo "ERROR: Cannot seem to copy a directory to the distdir :-("
+exit 1
+fi
 
 echo "*** Copying new README"
 ls -lf $distdir/README







On Apr 7, 2014, at 6:04 PM, Brice Goglin <brice.gog...@inria.fr>
 wrote:

> My jenkins does make distcheck on some Linux and only make check on
> others, so it should be fine on my side.
> 
> Brice
> 
> 
> 
> 
> Le 08/04/2014 00:01, Jeff Squyres (jsquyres) a écrit :
>> Do we care about "make dist" on Solaris?
>> 
>> 
>> On Apr 7, 2014, at 5:57 PM, Brice Goglin <brice.gog...@inria.fr> wrote:
>> 
>>> Same error.
>>> Brice
>>> 
>>> 
>>> 
>>> Le 07/04/2014 23:43, Jeff Squyres (jsquyres) a écrit :
>>>> How about:
>>>> 
>>>> tar c -C /home/ci/hwloc-gitclone -h -f - doc/doxygen-doc | tar x -C 
>>>> /home/ci/hwloc-gitclone/build/hwloc-gitclone -f -
>>>> 
>>>> 
>>>> 
>>>> On Apr 7, 2014, at 5:36 PM, Brice Goglin <brice.gog...@inria.fr>
>>>> wrote:
>>>> 
>>>>> Works on my Linux but fails on Solaris:
>>>>> tar -c -C /home/ci/hwloc-gitclone -h -f - doc/doxygen-doc | tar -x -C
>>>>> /home/ci/hwloc-gitclone/build/hwloc-gitclone -f -
>>>>> tar: /dev/rmt/0: No such file or directory
>>>>> 
>>>>> 
>>>>> 
>>>>> Le 07/04/2014 23:29, Jeff Squyres (jsquyres) a écrit :
>>>>>> --- a/config/distscript.sh
>>>>>> +++ b/config/distscript.sh
>>>>>> @@ -69,7 +69,7 @@ fi
>>>>>> # Trivial helper function
>>>>>> doit() {
>>>>>>   echo $*
>>>>>> -$*
>>>>>> +eval $*
>>>>>> }
>>>>>> 
>>>>>> echo "*** Copying doxygen-doc tree to dist..."
>>>>>> @@ -77,7 +77,7 @@ echo "*** Directory: srcdir: $srcdir, distdir: 
>>>>>> $distdir, pwd: 
>>>>>> doit mkdir -p $distdir/doc/doxygen-doc
>>>>>> doit chmod -R a=rwx $distdir/doc/doxygen-doc
>>>>>> doit rm -rf $distdir/doc/doxygen-doc
>>>>>> -doit cp -rpf $srcdir/doc/doxygen-doc $distdir/doc
>>>>>> +doit "tar -c -C $srcdir -h -f - doc/doxygen-doc | tar -x -C $distdir -f 
>>>>>> -"
>>>>>> 
>>>>>> echo "*** Copying new README"
>>>>>> ls -lf $distdir/README
>>>>> ___
>>>>> hwloc-devel mailing list
>>>>> hwloc-de...@open-mpi.org
>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>>> ___
>>> hwloc-devel mailing list
>>> hwloc-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>> 
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] GIT: hwloc branch master updated. 0e6fe307c10d47efee3fb95c50aee9c0f01bc8ec

[Jeff Squyres (jsquyres)]

How about:

tar c -C /home/ci/hwloc-gitclone -h -f - doc/doxygen-doc | tar x -C 
/home/ci/hwloc-gitclone/build/hwloc-gitclone -f -



On Apr 7, 2014, at 5:36 PM, Brice Goglin <brice.gog...@inria.fr>
 wrote:

> Works on my Linux but fails on Solaris:
> tar -c -C /home/ci/hwloc-gitclone -h -f - doc/doxygen-doc | tar -x -C
> /home/ci/hwloc-gitclone/build/hwloc-gitclone -f -
> tar: /dev/rmt/0: No such file or directory
> 
> 
> 
> Le 07/04/2014 23:29, Jeff Squyres (jsquyres) a écrit :
>> --- a/config/distscript.sh
>> +++ b/config/distscript.sh
>> @@ -69,7 +69,7 @@ fi
>> # Trivial helper function
>> doit() {
>> echo $*
>> -$*
>> +eval $*
>> }
>> 
>> echo "*** Copying doxygen-doc tree to dist..."
>> @@ -77,7 +77,7 @@ echo "*** Directory: srcdir: $srcdir, distdir: $distdir, 
>> pwd: 
>> doit mkdir -p $distdir/doc/doxygen-doc
>> doit chmod -R a=rwx $distdir/doc/doxygen-doc
>> doit rm -rf $distdir/doc/doxygen-doc
>> -doit cp -rpf $srcdir/doc/doxygen-doc $distdir/doc
>> +doit "tar -c -C $srcdir -h -f - doc/doxygen-doc | tar -x -C $distdir -f -"
>> 
>> echo "*** Copying new README"
>> ls -lf $distdir/README
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] GIT: hwloc branch master updated. 0e6fe307c10d47efee3fb95c50aee9c0f01bc8ec

[Jeff Squyres (jsquyres)]

On Apr 7, 2014, at 5:06 PM, "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> 
wrote:

> Ok, lemme look at tar -- there's a canonical way to copy dir trees with tar; 
> let me look it up...

Does this work for you?  It seems to do the Right Thing for me on OS X and 
Linux.


diff --git a/config/distscript.sh b/config/distscript.sh
index d7bdfa4..68f1f8a 100755
--- a/config/distscript.sh
+++ b/config/distscript.sh
@@ -69,7 +69,7 @@ fi
 # Trivial helper function
 doit() {
 echo $*
-$*
+eval $*
 }
 
 echo "*** Copying doxygen-doc tree to dist..."
@@ -77,7 +77,7 @@ echo "*** Directory: srcdir: $srcdir, distdir: $distdir, pwd: 
 doit mkdir -p $distdir/doc/doxygen-doc
 doit chmod -R a=rwx $distdir/doc/doxygen-doc
 doit rm -rf $distdir/doc/doxygen-doc
-doit cp -rpf $srcdir/doc/doxygen-doc $distdir/doc
+doit "tar -c -C $srcdir -h -f - doc/doxygen-doc | tar -x -C $distdir -f -"
 
 echo "*** Copying new README"
 ls -lf $distdir/README


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] GIT: hwloc branch master updated. 0e6fe307c10d47efee3fb95c50aee9c0f01bc8ec

[Jeff Squyres (jsquyres)]

On Apr 7, 2014, at 5:05 PM, Brice Goglin <brice.gog...@inria.fr> wrote:

> So you just broke my make dist :/

Really?  Doh!  :-(

> I don't have MacOS to test things. If rsync or tar or whatever can
> dereference symlinks, that'll work for me.

Ok, lemme look at tar -- there's a canonical way to copy dir trees with tar; 
let me look it up...

> 
> commit 0ebeff689e9414d5eedbf53e7c8697a3af5e4b72
> Author: Brice Goglin <brice.gog...@inria.fr>
> Date:   Fri Mar 21 18:51:14 2014 +0100
> 
>dist: fix support for doc/doxygen-doc being a symlink
> 
>make dist works when building out-of-source if $srcdir/doc/doxygen-doc
>is a symlink to builddir/doc/doxygen-doc.
>But it actually fails to copy the doxygen-doc tree because it
>doesn't dereference the symlink. Fix that.
> 
> Brice
> 
> 
> 
> 
> Le 07/04/2014 22:59, Jeff Squyres (jsquyres) a écrit :
>> On Apr 7, 2014, at 4:33 PM, Brice Goglin <brice.gog...@inria.fr> wrote:
>> 
>>> So you're (always?) getting tarballs without any doc/doxygen-doc
>>> subdirectories?
>> That's correct -- doc/doxygen-doc is in the source tree, but does not end up 
>> in the tarball.
>> 
>>> Does "make dist" say that it's copying the doxygen-doc
>>> subdirectory? Any idea who's removing it later?
>> Mmm... good point... 
>> 
>> /me investigates
>> 
>> Ah, I see the issue.  On OS X, this:
>> 
>> doit cp -rpf $srcdir/doc/doxygen-doc/ $distdir/doc
>> 
>> Does not actually copy the doxygen-doc directory to $distdir.  If I remove 
>> the trailing slash, it works:
>> 
>> doit cp -rpf $srcdir/doc/doxygen-doc $distdir/doc
>> 
>> (i.e., doxygen-doc ends up in $distdir and distcheck works properly)
>> 
>> There's probably a reason for this, but I'm not too interested in tracking 
>> it down.  I just removed the trailing slash...
>> 
>> I note that the OS X man page for cp says:
>> 
>> Historic versions of the cp utility had a -r option.  This implementation
>> supports that option; however, its use is strongly discouraged, as it
>> does not correctly copy special files, symbolic links, or fifo's.
>> 
>> Instead, the OS X cp supports -R (Linux cp does, too).
>> 
>> I guess we should be using something better than cp -r to copy the directory 
>> over -- perhaps tar?
>> 
>>> I managed to get such a tarball without doc only once, but it
>>> disappeared after I added some debug commands to config/distscript.sh to
>>> see where doc/doxygen-doc was being deleted. Strange.
>>> 
>>> Brice
>>> 
>>> 
>>> 
>>> Le 07/04/2014 22:05, Jeff Squyres (jsquyres) a écrit :
>>>> Right -- I've done that (i.e., if I do "make doc" again, it does nothing 
>>>> because it's already done).  And "make dist" works fine.  
>>>> 
>>>> But "make distcheck" fails when it runs "make dist" in the subdir of the 
>>>> expanded tarball fails because doc/doxygen-doc doesn't exist in there.
>>>> 
>>>> 
>>>> On Apr 7, 2014, at 3:57 PM, Brice Goglin <brice.gog...@inria.fr> wrote:
>>>> 
>>>>> In v1.9+, you need make doc before make dist or make distcheck. It may
>>>>> explain your problem?
>>>>> I changed this a couple weeks ago to make things much easier to
>>>>> understand/maintain (but a little bit harder to use :))
>>>>> 
>>>>> Brice
>>>>> 
>>>>> 
>>>>> Le 07/04/2014 21:37, Jeff Squyres (jsquyres) a écrit :
>>>>>> I just pushed 143e27248f928797e2e8532747386c67c9f8d873, which converted 
>>>>>> distscript.csh to distscript.sh.
>>>>>> 
>>>>>> If it works well on master, we can pull it to the v1.9 branch.
>>>>>> 
>>>>>> I notice that "make distcheck" is broken, however -- when it goes to 
>>>>>> "make dist" in the expanded tarball, I get the following message:
>>>>>> 
>>>>>> -
>>>>>> *** The srcdir does not already have a doxygen-doc tree built.
>>>>>> *** hwloc's config/distscript.csh requires the docs to be built
>>>>>> *** in the srcdir before executing 'make dist'.
>>>>>> make[3]: *** [dist-hook] Error 1
>>>>>> make[2]: *** [distdir] Error 2
>>>>>> make[1]: *** [dist] Error 2
>>>>&

Re: [hwloc-devel] GIT: hwloc branch master updated. 0e6fe307c10d47efee3fb95c50aee9c0f01bc8ec

[Jeff Squyres (jsquyres)]

On Apr 7, 2014, at 4:33 PM, Brice Goglin <brice.gog...@inria.fr> wrote:

> So you're (always?) getting tarballs without any doc/doxygen-doc
> subdirectories?

That's correct -- doc/doxygen-doc is in the source tree, but does not end up in 
the tarball.

> Does "make dist" say that it's copying the doxygen-doc
> subdirectory? Any idea who's removing it later?

Mmm... good point... 

/me investigates

Ah, I see the issue.  On OS X, this:

doit cp -rpf $srcdir/doc/doxygen-doc/ $distdir/doc

Does not actually copy the doxygen-doc directory to $distdir.  If I remove the 
trailing slash, it works:

doit cp -rpf $srcdir/doc/doxygen-doc $distdir/doc

(i.e., doxygen-doc ends up in $distdir and distcheck works properly)

There's probably a reason for this, but I'm not too interested in tracking it 
down.  I just removed the trailing slash...

I note that the OS X man page for cp says:

 Historic versions of the cp utility had a -r option.  This implementation
 supports that option; however, its use is strongly discouraged, as it
 does not correctly copy special files, symbolic links, or fifo's.

Instead, the OS X cp supports -R (Linux cp does, too).

I guess we should be using something better than cp -r to copy the directory 
over -- perhaps tar?

> I managed to get such a tarball without doc only once, but it
> disappeared after I added some debug commands to config/distscript.sh to
> see where doc/doxygen-doc was being deleted. Strange.
> 
> Brice
> 
> 
> 
> Le 07/04/2014 22:05, Jeff Squyres (jsquyres) a écrit :
>> Right -- I've done that (i.e., if I do "make doc" again, it does nothing 
>> because it's already done).  And "make dist" works fine.  
>> 
>> But "make distcheck" fails when it runs "make dist" in the subdir of the 
>> expanded tarball fails because doc/doxygen-doc doesn't exist in there.
>> 
>> 
>> On Apr 7, 2014, at 3:57 PM, Brice Goglin <brice.gog...@inria.fr> wrote:
>> 
>>> In v1.9+, you need make doc before make dist or make distcheck. It may
>>> explain your problem?
>>> I changed this a couple weeks ago to make things much easier to
>>> understand/maintain (but a little bit harder to use :))
>>> 
>>> Brice
>>> 
>>> 
>>> Le 07/04/2014 21:37, Jeff Squyres (jsquyres) a écrit :
>>>> I just pushed 143e27248f928797e2e8532747386c67c9f8d873, which converted 
>>>> distscript.csh to distscript.sh.
>>>> 
>>>> If it works well on master, we can pull it to the v1.9 branch.
>>>> 
>>>> I notice that "make distcheck" is broken, however -- when it goes to "make 
>>>> dist" in the expanded tarball, I get the following message:
>>>> 
>>>> -
>>>> *** The srcdir does not already have a doxygen-doc tree built.
>>>> *** hwloc's config/distscript.csh requires the docs to be built
>>>> *** in the srcdir before executing 'make dist'.
>>>> make[3]: *** [dist-hook] Error 1
>>>> make[2]: *** [distdir] Error 2
>>>> make[1]: *** [dist] Error 2
>>>> make: *** [distcheck] Error 1
>>>> -
>>>> 
>>>> Is this expected / has this been broken for a while?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Mar 31, 2014, at 1:42 AM, Brice Goglin <brice.gog...@inria.fr> wrote:
>>>> 
>>>>> Le 31/03/2014 00:57, Christopher Samuel a écrit :
>>>>>> On 30/03/14 02:04, Ralph Castain wrote:
>>>>>> 
>>>>>>> turns out that some linux distro's automatically set LS_COLORS in
>>>>>>> your environment when running old versions of csh/tcsh via their
>>>>>>> default dot files
>>>>>> For example RHEL6 does this..
>>>>> Looks like it's a 10 years old conflict between csh and coreutils. It's
>>>>> crary hwloc has to work around this very old issue, we should just stop
>>>>> using csh and distros that haven't fixed this :)
>>>>> 
>>>>> Brice
>>>>> 
>>>>> ___
>>>>> hwloc-devel mailing list
>>>>> hwloc-de...@open-mpi.org
>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>>> ___
>>> hwloc-devel mailing list
>>> hwloc-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>> 
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] GIT: hwloc branch master updated. 0e6fe307c10d47efee3fb95c50aee9c0f01bc8ec

[Jeff Squyres (jsquyres)]

Right -- I've done that (i.e., if I do "make doc" again, it does nothing 
because it's already done).  And "make dist" works fine.  

But "make distcheck" fails when it runs "make dist" in the subdir of the 
expanded tarball fails because doc/doxygen-doc doesn't exist in there.


On Apr 7, 2014, at 3:57 PM, Brice Goglin <brice.gog...@inria.fr> wrote:

> In v1.9+, you need make doc before make dist or make distcheck. It may
> explain your problem?
> I changed this a couple weeks ago to make things much easier to
> understand/maintain (but a little bit harder to use :))
> 
> Brice
> 
> 
> Le 07/04/2014 21:37, Jeff Squyres (jsquyres) a écrit :
>> I just pushed 143e27248f928797e2e8532747386c67c9f8d873, which converted 
>> distscript.csh to distscript.sh.
>> 
>> If it works well on master, we can pull it to the v1.9 branch.
>> 
>> I notice that "make distcheck" is broken, however -- when it goes to "make 
>> dist" in the expanded tarball, I get the following message:
>> 
>> -
>> *** The srcdir does not already have a doxygen-doc tree built.
>> *** hwloc's config/distscript.csh requires the docs to be built
>> *** in the srcdir before executing 'make dist'.
>> make[3]: *** [dist-hook] Error 1
>> make[2]: *** [distdir] Error 2
>> make[1]: *** [dist] Error 2
>> make: *** [distcheck] Error 1
>> -
>> 
>> Is this expected / has this been broken for a while?
>> 
>> 
>> 
>> 
>> On Mar 31, 2014, at 1:42 AM, Brice Goglin <brice.gog...@inria.fr> wrote:
>> 
>>> Le 31/03/2014 00:57, Christopher Samuel a écrit :
>>>> On 30/03/14 02:04, Ralph Castain wrote:
>>>> 
>>>>> turns out that some linux distro's automatically set LS_COLORS in
>>>>> your environment when running old versions of csh/tcsh via their
>>>>> default dot files
>>>> For example RHEL6 does this..
>>> Looks like it's a 10 years old conflict between csh and coreutils. It's
>>> crary hwloc has to work around this very old issue, we should just stop
>>> using csh and distros that haven't fixed this :)
>>> 
>>> Brice
>>> 
>>> ___
>>> hwloc-devel mailing list
>>> hwloc-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>> 
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] GIT: hwloc branch master updated. 0e6fe307c10d47efee3fb95c50aee9c0f01bc8ec

[Jeff Squyres (jsquyres)]

I just pushed 143e27248f928797e2e8532747386c67c9f8d873, which converted 
distscript.csh to distscript.sh.

If it works well on master, we can pull it to the v1.9 branch.

I notice that "make distcheck" is broken, however -- when it goes to "make 
dist" in the expanded tarball, I get the following message:

-
*** The srcdir does not already have a doxygen-doc tree built.
*** hwloc's config/distscript.csh requires the docs to be built
*** in the srcdir before executing 'make dist'.
make[3]: *** [dist-hook] Error 1
make[2]: *** [distdir] Error 2
make[1]: *** [dist] Error 2
make: *** [distcheck] Error 1
-

Is this expected / has this been broken for a while?




On Mar 31, 2014, at 1:42 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> Le 31/03/2014 00:57, Christopher Samuel a écrit :
>> On 30/03/14 02:04, Ralph Castain wrote:
>> 
>>> turns out that some linux distro's automatically set LS_COLORS in
>>> your environment when running old versions of csh/tcsh via their
>>> default dot files
>> 
>> For example RHEL6 does this..
> 
> Looks like it's a 10 years old conflict between csh and coreutils. It's
> crary hwloc has to work around this very old issue, we should just stop
> using csh and distros that haven't fixed this :)
> 
> Brice
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Use of

[Jeff Squyres (jsquyres)]

Sweet; thanks.

On Jan 10, 2014, at 12:25 PM, Brice Goglin <brice.gog...@inria.fr> wrote:

> Looks like we're good.
> Brice
> 
> 
> 
> Le 10/01/2014 18:05, Jeff Squyres (jsquyres) a écrit :
>> K, will do.
>> 
>> On Jan 10, 2014, at 12:00 PM, Brice Goglin <brice.gog...@inria.fr>
>> wrote:
>> 
>>> Push it to master, we'll what regression testing at 
>>> https://ci.inria.fr/hwloc/job/master-1-check/ thinks about it
>>> Brice
>>> 
>>> 
>>> 
>>> "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> a écrit :
>>> Brice / Samuel --
>>> 
>>> In http://www.open-mpi.org/community/lists/devel/2014/01/13619.php, Paul 
>>> Hargrove found this compiler warning:
>>> 
>>> -
>>> On OpenBSD the header malloc.h exists, but is NOT intended to be used:
>>> -bash-4.2$ grep -B2 'is obsolete' make.log 
>>> CC   bind.lo
>>> In file included from 
>>> /home/phargrov/OMPI/openmpi-1.7-latest-openbsd5-amd64/openmpi-1.7.4rc2r30168/opal/mca/hwloc/hwloc172/hwloc/src/bind.c:17:
>>> /usr/include/malloc.h:4:2: warning: #warning " is obsolete, use 
>>> "
>>> -
>>> 
>>> What do you think of this patch (or something like it)?
>>> 
>>> diff --git a/src/bind.c b/src/bind.c
>>> index 046b7cf..37921bc 100644
>>> --- a/src/bind.c
>>> +++ b/src/bind.c
>>> @@ -13,8 +13,9 @@
>>> #ifdef HAVE_SYS_MMAN_H
>>> #  include 
>>> #endif
>>> -#ifdef HAVE_MALLOC_H
>>> -
>>> # 
>>> include 
>>> 
>>> +/*  is only needed if we don't have posix_memalign() */
>>> +#if defined(hwloc_getpagesize) && !defined(HAVE_POSIX_MEMALIGN) && 
>>> defined(HAVE_MEMALIGN) && defined(HAVE_MALLOC_H)
>>> +#include 
>>> #endif
>>> #ifdef HAVE_UNISTD_H
>>> #include 
>>> 
>>> ___
>>> hwloc-devel mailing list
>>> hwloc-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>> 
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Use of

[Jeff Squyres (jsquyres)]

K, will do.

On Jan 10, 2014, at 12:00 PM, Brice Goglin <brice.gog...@inria.fr>
 wrote:

> Push it to master, we'll what regression testing at 
> https://ci.inria.fr/hwloc/job/master-1-check/ thinks about it
> Brice
> 
> 
> 
> "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> a écrit :
> Brice / Samuel --
> 
> In http://www.open-mpi.org/community/lists/devel/2014/01/13619.php, Paul 
> Hargrove found this compiler warning:
> 
> -
> On OpenBSD the header malloc.h exists, but is NOT intended to be used:
> -bash-4.2$ grep -B2 'is obsolete' make.log 
> CC   bind.lo
> In file included from 
> /home/phargrov/OMPI/openmpi-1.7-latest-openbsd5-amd64/openmpi-1.7.4rc2r30168/opal/mca/hwloc/hwloc172/hwloc/src/bind.c:17:
> /usr/include/malloc.h:4:2: warning: #warning " is obsolete, use 
> "
> -
> 
> What do you think of this patch (or something like it)?
> 
> diff --git a/src/bind.c b/src/bind.c
> index 046b7cf..37921bc 100644
> --- a/src/bind.c
> +++ b/src/bind.c
> @@ -13,8 +13,9 @@
> #ifdef HAVE_SYS_MMAN_H
> #  include 
> #endif
> -#ifdef HAVE_MALLOC_H
> -
>  # 
> include 
> 
> +/*  is only needed if we don't have posix_memalign() */
> +#if defined(hwloc_getpagesize) && !defined(HAVE_POSIX_MEMALIGN) && 
> defined(HAVE_MEMALIGN) && defined(HAVE_MALLOC_H)
> +#include 
> #endif
> #ifdef HAVE_UNISTD_H
> #include 
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Use of

[Jeff Squyres (jsquyres)]

Brice / Samuel --

In http://www.open-mpi.org/community/lists/devel/2014/01/13619.php, Paul 
Hargrove found this compiler warning:

-
On OpenBSD the header malloc.h exists, but is NOT intended to be used:
-bash-4.2$ grep -B2 'is obsolete' make.log 
  CC   bind.lo
In file included from 
/home/phargrov/OMPI/openmpi-1.7-latest-openbsd5-amd64/openmpi-1.7.4rc2r30168/opal/mca/hwloc/hwloc172/hwloc/src/bind.c:17:
/usr/include/malloc.h:4:2: warning: #warning " is obsolete, use 
"
-

What do you think of this patch (or something like it)?

diff --git a/src/bind.c b/src/bind.c
index 046b7cf..37921bc 100644
--- a/src/bind.c
+++ b/src/bind.c
@@ -13,8 +13,9 @@
 #ifdef HAVE_SYS_MMAN_H
 #  include 
 #endif
-#ifdef HAVE_MALLOC_H
-#  include 
+/*  is only needed if we don't have posix_memalign() */
+#if defined(hwloc_getpagesize) && !defined(HAVE_POSIX_MEMALIGN) && 
defined(HAVE_MEMALIGN) && defined(HAVE_MALLOC_H)
+#include 
 #endif
 #ifdef HAVE_UNISTD_H
 #include 


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] GIT: hwloc branch master updated. c05fc46fa58d792b13b6b4aec30d7a81877185f4

[Jeff Squyres (jsquyres)]

I'll investigate.

On Nov 7, 2013, at 12:37 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> Jeff,
> This mail looks strange. The actual diff and commit message is missing.
> Also we got a commit mail for HEAD for some reason.
> Brice
> 
> 
> 
> Le 07/11/2013 09:35, MPI Team a écrit :
>> The branch, master has been updated
>>   via  c05fc46fa58d792b13b6b4aec30d7a81877185f4 (commit)
>>  from  e37cb23f5aa93ae4123ce5dfad37ac0cf56ce4f1 (commit)
>> 
>> Those revisions listed above that are new to this repository have
>> not appeared on any other notification email; so we list those
>> revisions in full, below.
>> 
>> - Log -
>> ---
>> 
>> Summary of changes:
>> utils/test-hwloc-diffpatch.sh.in | 2 ++
>> 1 file changed, 2 insertions(+)
>> 
>> 
>> hooks/post-receive
> 
> _______
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Git branch emails

[Jeff Squyres (jsquyres)]

Ok, sorry for the bazillion emails you just got, but the email script should 
now send out notices for all commits on all branches now.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] late git commit email

[Jeff Squyres (jsquyres)]

Oy; I see what's happening.  I think I can go manually generate those mails 
now; I'll need to think about how to solve this properly (i.e., consult with 
Dave G).

On Nov 6, 2013, at 9:29 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> The v1.8 branch commit emails are missing? Do you have to explicit
> enable them on github?
> 
> Brice
> 
> 
> 
> Le 06/11/2013 15:30, Jeff Squyres (jsquyres) a écrit :
>> There was a disk problem on the IU server where the git commit message came 
>> from.
>> 
>> It was just fixed, which is why we got the commit email so late.
>> 
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] late git commit email

[Jeff Squyres (jsquyres)]

There was a disk problem on the IU server where the git commit message came 
from.

It was just fixed, which is why we got the commit email so late.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Relationship between Cario and X11

[Jeff Squyres (jsquyres)]

On Nov 1, 2013, at 11:54 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:

> We could avoid Xutil.h and keysym.h by disabling the case KeyPress part,
> but I'd rather not: people will wonder why they don't have keyboard
> shortcut, and finding out from ./configure output will not be easy.
> When one has Xlib.h, having Xutil.h and keysym.h is not really far
> anyway.


Ok -- so you're saying we *require* all 3, right?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Relationship between Cario and X11

[Jeff Squyres (jsquyres)]

There's some funny m4 logic in the CHECK_HEADERS for X11.  Let me make sure I 
understand the intent:

- X11/Xlib.h: this file is required for X11 support
- X11/Xutil.h X11/keysym.h: these files are optional for X11 support (i.e., we 
can still build X11 support without them, but if we have them, there's extra 
X11 goodies that can be used)

Is that correct?  Or do we *require* all 3 header files for X11 support?



On Nov 1, 2013, at 11:20 AM, "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> 
wrote:

> Ya -- working on a new patch, too.
> 
> 
> On Nov 1, 2013, at 11:10 AM, Brice Goglin <brice.gog...@inria.fr> wrote:
> 
>> Can you first find out which header and library contains XOpenDisplay()
>> on your Mac?
>> 
>> Brice
>> 
>> 
>> 
>> Le 01/11/2013 16:01, Jeff Squyres (jsquyres) a écrit :
>>> Ah; I missed that because we have the X11 checking stuff done in hwloc.m4 
>>> already -- I thought the ones in the Cairo were actually redundant.
>>> 
>>> It looks like this logic isn't quite correct, anyway -- the X11 checks are 
>>> embedded in the Cairo and GL sections.  Should they moved out to be 
>>> independent of Cairo and GL (and therefore only once, and include the 
>>> AC_DEFINE for HWLOC_HAVE_X11)?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Nov 1, 2013, at 10:53 AM, Samuel Thibault <samuel.thiba...@inria.fr> 
>>> wrote:
>>> 
>>>> Jeff Squyres (jsquyres), le Fri 01 Nov 2013 15:12:31 +0100, a écrit :
>>>>> Cool.  Does the following patch look ok?  If so, I'll commit to master 
>>>>> and v1.7:
>>>> Err, no, we really need to have HWLOC_HAVE_X11 defined when X11 is
>>>> available, otherwise we won't get the graphical lstopo.
>>>> 
>>>> Samuel
>>>> _______
>>>> hwloc-devel mailing list
>>>> hwloc-de...@open-mpi.org
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>>> 
>> 
>> ___
>> hwloc-devel mailing list
>> hwloc-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Relationship between Cario and X11

[Jeff Squyres (jsquyres)]

Ya -- working on a new patch, too.


On Nov 1, 2013, at 11:10 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> Can you first find out which header and library contains XOpenDisplay()
> on your Mac?
> 
> Brice
> 
> 
> 
> Le 01/11/2013 16:01, Jeff Squyres (jsquyres) a écrit :
>> Ah; I missed that because we have the X11 checking stuff done in hwloc.m4 
>> already -- I thought the ones in the Cairo were actually redundant.
>> 
>> It looks like this logic isn't quite correct, anyway -- the X11 checks are 
>> embedded in the Cairo and GL sections.  Should they moved out to be 
>> independent of Cairo and GL (and therefore only once, and include the 
>> AC_DEFINE for HWLOC_HAVE_X11)?
>> 
>> 
>> 
>> 
>> 
>> On Nov 1, 2013, at 10:53 AM, Samuel Thibault <samuel.thiba...@inria.fr> 
>> wrote:
>> 
>>> Jeff Squyres (jsquyres), le Fri 01 Nov 2013 15:12:31 +0100, a écrit :
>>>> Cool.  Does the following patch look ok?  If so, I'll commit to master and 
>>>> v1.7:
>>> Err, no, we really need to have HWLOC_HAVE_X11 defined when X11 is
>>> available, otherwise we won't get the graphical lstopo.
>>> 
>>> Samuel
>>> ___
>>> hwloc-devel mailing list
>>> hwloc-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>> 
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Relationship between Cario and X11

[Jeff Squyres (jsquyres)]

Ah; I missed that because we have the X11 checking stuff done in hwloc.m4 
already -- I thought the ones in the Cairo were actually redundant.

It looks like this logic isn't quite correct, anyway -- the X11 checks are 
embedded in the Cairo and GL sections.  Should they moved out to be independent 
of Cairo and GL (and therefore only once, and include the AC_DEFINE for 
HWLOC_HAVE_X11)?





On Nov 1, 2013, at 10:53 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:

> Jeff Squyres (jsquyres), le Fri 01 Nov 2013 15:12:31 +0100, a écrit :
>> Cool.  Does the following patch look ok?  If so, I'll commit to master and 
>> v1.7:
> 
> Err, no, we really need to have HWLOC_HAVE_X11 defined when X11 is
> available, otherwise we won't get the graphical lstopo.
> 
> Samuel
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Relationship between Cario and X11

[Jeff Squyres (jsquyres)]

Cool.  Does the following patch look ok?  If so, I'll commit to master and v1.7:

diff --git a/config/hwloc_internal.m4 b/config/hwloc_internal.m4
index b0ac041..bfc3f36 100644
--- a/config/hwloc_internal.m4
+++ b/config/hwloc_internal.m4
@@ -255,31 +255,6 @@ EOF
   HWLOC_PKG_CHECK_MODULES([CAIRO], [cairo], [cairo_fill],
   [hwloc_cairo_happy=yes],
   [hwloc_cairo_happy=no])
-  if test "x$hwloc_cairo_happy" = "xyes"; then
-AC_PATH_XTRA
-   CFLAGS_save=$CFLAGS
-   LIBS_save=$LIBS
-
-   CFLAGS="$CFLAGS $X_CFLAGS"
-   LIBS="$LIBS $X_PRE_LIBS $X_LIBS $X_EXTRA_LIBS"
-AC_CHECK_HEADERS([X11/Xlib.h], [
-  AC_CHECK_HEADERS([X11/Xutil.h X11/keysym.h], [
-AC_CHECK_LIB([X11], [XOpenDisplay], [
-  enable_X11=yes
-  AC_SUBST([HWLOC_X11_LIBS], ["-lX11"])
-  AC_DEFINE([HWLOC_HAVE_X11], [1], [Define to 1 if X11 libraries ar
-])]
-  )],,
-  [[#include ]]
-)
-if test "x$enable_X11" != "xyes"; then
-  AC_MSG_WARN([X11 headers not found, Cairo/X11 back-end disabled])
-  hwloc_cairo_happy=no
-fi
-
-   CFLAGS=$CFLAGS_save
-   LIBS=$LIBS_save
-  fi
 fi
 
 if test "x$hwloc_cairo_happy" = "xyes"; then



On Nov 1, 2013, at 10:07 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:

> Hello,
> 
> Jeff Squyres (jsquyres), le Fri 01 Nov 2013 14:59:03 +0100, a écrit :
>> I notice that we have an explicit dependency between Cairo and X11 in 
>> configure:
>> 
>> Is there any reason for this?
> 
> I think if there was any it's now gone.
> 
>> Indeed, I manually disabled this extra check in configure, and I can still 
>> seem to use Cairo in lstopo (e.g., generate PDFs and PNGs).
> 
> So the source code is already fine with it, good!
> 
>> Are there some platforms where linking Cairo depends on X11?
> 
> Possibly, but I believe it is hidden, or at least all handled by
> pkg-config, and so we don't care. Of course we need X11 for our x11
> backend (which also happens to be using cairo).
> 
> Samuel
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Relationship between Cario and X11

[Jeff Squyres (jsquyres)]

I notice that we have an explicit dependency between Cairo and X11 in configure:

-
if test "x$enable_X11" != "xyes"; then
  AC_MSG_WARN([X11 headers not found, Cairo/X11 back-end disabled])
  hwloc_cairo_happy=no
fi
-

Is there any reason for this?

I ask because my Mac (Lion) has Cairo installed via MacPorts, but it doesn't 
find XOpenDisplay in -lX11, and so it disables X11 support (which is fine), but 
that also disables Cairo support (which is a bummer).

Indeed, I manually disabled this extra check in configure, and I can still seem 
to use Cairo in lstopo (e.g., generate PDFs and PNGs).

Are there some platforms where linking Cairo depends on X11?  If so, is there a 
way we can discover that in configure?  (because Cairo doesn't seem to need X11 
on OS X for just outputting PDFs and PNGs)

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] [open-mpi/hwloc] f21cd7: linux/mic: add a MICSerialNumber info attribute wh...

[Jeff Squyres (jsquyres)]

Yeah; we're working on it.

Github's emails kinda suck.  Brice sent me his openmx git email script today; 
I'm going to try to get that hosted at IU.


On Oct 17, 2013, at 1:17 PM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:

> Brice Goglin, le Thu 17 Oct 2013 19:10:05 +0200, a écrit :
>>  Branch: refs/heads/master
>>  Home:   https://github.com/open-mpi/hwloc
>>  Commit: f21cd78ae135e7ded8c61f7f29d4c4109f0b1a71
>>  
>> https://github.com/open-mpi/hwloc/commit/f21cd78ae135e7ded8c61f7f29d4c4109f0b1a71
>>  Author: Brice Goglin <brice.gog...@inria.fr>
>>  Date:   2013-10-17 (Thu, 17 Oct 2013)
>> 
>>  Changed paths:
>>M NEWS
>>M doc/hwloc.doxy
>>M src/topology-linux.c
>> 
>>  Log Message:
>>  ---
>>  linux/mic: add a MICSerialNumber info attribute when running inside the MIC
>> 
>> OMPI people want an easy way to recognize MICs and nodes using hwloc.
>> We already have MICSerialNumber inside OS devices in the host topology,
>> add the same to the root object of MIC topologies.
>> Unfortunately, we couldn't find anything better than parsing /proc/elog
>> to find that number.
> 
> Mmm, we don't have the commit diff any more?  I found that useful, to be
> able to quickly see what happened exactly.
> 
> Samuel
> _______
> hwloc-svn mailing list
> hwloc-...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-svn


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] github hwloc repo reset

[Jeff Squyres (jsquyres)]

I chatted w/ Brice in IM: the github/open-mpi/hwloc repo ***has been completely 
reset*** and now reflects all the correct information.

If you have any clones of the original githib/open-mpi/hwloc repo, either be 
*exceedingly* careful in pulling down new stuff, or, probably simpler/better: 
just rm -rf your local clone and pull down a fresh one.

Big apologies to everyone for all this hassle; it was my mistake that caused 
this kerfuffle (bonus to everyone: use kerfuffle in a sentence today).

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] New git repo attempt

[Jeff Squyres (jsquyres)]

On Oct 3, 2013, at 12:31 PM, Brice Goglin <brice.gog...@inria.fr> wrote:

> The master branch looks good to me, and the list of branches looks fine too.

Good.

> v1.7 misses the last git commits, but I guess you didn't update it yet.


Yes; I replayed on the master, but not v1.7 yet.  I'll go do that now...

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] New git repo attempt

[Jeff Squyres (jsquyres)]

I did the conversion again, and then added the commits that we've put on github 
since the original conversion (but I squashed most of them).  I put the 
resulting repo here:

https://github.com/jsquyres/hwloc-convert-again

Does this look ok to everyone?  If so, I can kill the existing 
githib/open-mpi/hwloc and replace it with this one.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] nightly snapshot tarballs now available

[Jeff Squyres (jsquyres)]

On Oct 3, 2013, at 6:41 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> It was likely moved to the attic. If svn2git doesn't find it, that's
> fine, I still have it in my archives in case we ever want it (very
> unlikely).


Ah, ok.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] nightly snapshot tarballs now available

[Jeff Squyres (jsquyres)]

On Oct 2, 2013, at 12:47 PM, Brice Goglin <brice.gog...@inria.fr> wrote:

> I can do it (assuming the "hwloc-svn-conversion" git tree it uptodate).
> But I need somebody to create the ompi/hwloc-debian repo on github and
> give us credentials.

Done.

> The only important one is "cuda".
> Most other branches were merged, or manually applied to trunk, or are
> obsolete. Maybe just keep "json" and "valarray" in case we ever need to
> revive them.

I just sent a mail to Dave; let's see what he says.

I don't see a valarray branch in SVN -- where is that?

> Looks like we're also missing stable branches v0.9, v1.0 and v1.1 for
> some reason.


#$@%@#%$#@$%

I'm re-running the svn->git conversion on my laptop to see if I can figure out 
why these branches didn't make it over.

In the worst case, we can re-seed the hwloc git repo because nothing 
tremendously important has happened since the conversion (we can just replay 
the script update commits -- it'll be a little painful, but do-able).

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] git / nightly builds

[Jeff Squyres (jsquyres)]

Sorry for the delay in replying.


On Sep 29, 2013, at 10:32 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> Now why do we still need a call to git-describe in get_version.sh? Isn't
> this script supposed to just read what distscript.csh did? (which would
> mean that "if test -z "$HWLOC_SNAPSHOT_VERSION" is useless). Or do you
> need that as a fallback for when we compile instead of doing make dist?
> In one case, we force the snapshot by modifying VERSION (make dist), in
> the other case we git describe at runtime (make). It would be good to
> merge these two cases somehow.

Basically, there's a (possibly artificial?) disparity between:

1. running "make dist" from a developer clone
2. pre-processing VERSION to put in the describe version and then running "make 
dist" (i.e., the make_*_tarball scripts)

Specifically, VERSION in the repo has:

snapshot=1
snapshot_version=

Ie., snapshot_version is blank.  Which is why get_version.sh will fill in the 
current "git describe" value if snapshot_version is blank.

But you're right -- this is putting "git describe" in two places.  What if 
VERSION in the repo has:

snapshot=1
snapshot_version=gitclone

And therefore get_version.sh always just uses the snapshot_version value 
(because it will never be blank).  

The downside of this is that "make dist" from a dev clone won't accurately 
represent the tree, but that's probably ok.  

*** If you're kosher with this, I'll remove that extra logic from 
get_version.sh.  Maybe I'll make it error if "snapshot_version" is empty, or 
something.

>> 2. contrib/nightly/make_snapshot_tarball:
>>   - Invoked via cron on the build machine
>> [snip]
> 
> Ok I didn't know that there was so website-specific things in that
> script. I assumed it was mainly a make distcheck (if so, I would have
> tried to reuse it in the regression testing tool).

K.  I think "make dist[check]" is the heart of everything (and the thing that 
is "re-used", so to speak everywhere); the rest is processing that we do for 
whatever reason that the tarball is being built.

Any other thoughts on how we can simplify things?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] nightly snapshot tarballs now available

[Jeff Squyres (jsquyres)]

On Sep 28, 2013, at 10:05 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> The only things that we're still missing as far as I know are:
> * the debian repository as explained above (by the way, beware that
> branches are not under branches/ in there)

Sorry for the delay in replying -- I suck at inbox management.  :-(

No, I think that one was not converted because I think Dave+me thought you were 
going to move that to a separate repo outside of this conversion process.

> * some missing branches on github (mainly the cuda branch)

Yow -- WTF happened there?  :-(

Tell me which SVN branches you want to keep -- just the cuda branch? -- and let 
me chat with Dave to see how to get that back.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] git / nightly builds

[Jeff Squyres (jsquyres)]

On Sep 28, 2013, at 4:47 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:

> I am watching with intense interest, as GASNet will be moving to git on Nov 1.
> Could you give me a pointer to where I can get copies all the scripts that 
> you guys use for nightly tarballs, commit emails and such?
> I'll want to have look after you have all the wrinkles ironed out to your 
> satisfaction.

FWIW, I think we're generally reviewing these scripts mainly because they seem 
to have become too complicated.  Moving to adapt them to use git was probably 
the catalyst for the review; not really the reason.

But the 3 scripts are located in the hwloc master branch (I just described them 
in my prior mail):

  config/distscript.csh
  contrib/nightly/make_snapshot_tarball
  contrib/dist/make_dist_tarball

> FWIW: a viewpoint from somebody who has yet to actually try to implement his 
> ideas:
> 
> We have PLANNED to script our nightlies to be named with a date stamp and 6 
> or 8 chars of the SHA1.
> The format would be something like PROJECT-BRANCH-20130928-12abcdef.tar.gz
> Where BRANCH=v. for the UPCOMING release in most scenarios (but 
> could be a named feature branch like "oshmem")
> That way directory listings would sort by branch and date (simple for mere 
> humans) while the SHA1 would allow fetching the corresponding version from 
> git.  The full SHA1 would, of course, also be in a file in the tarball 
> (actual filename TBD).

FWIW: I talked to Dave Goodell about this quite a bit before going with "git 
describe".  I think I mentioned that our prior tarballs used the SVN r number, 
which therefore made it quite easy to order the tarballs; the git hash 
obviously doesn't provide this ordering.

"git describe" provides a convenient mechanism, IMHO, and does all the work for 
you. It tells you exactly how many commits you are beyond the last tag on that 
branch.  hwloc's tags conveniently imply exactly which branch you're on, so it 
all worked out (i.e., each release series has its own branch -- the 1.7.x 
releases are on the v1.7 branch, the 1.6.x releases are on the v1.6 branch, and 
so on).

The only branch that didn't have any tags at all was master, so I just created 
a "dev" tag on master, and that was sufficient.

Two other minor points contributed to my decision:

1. Dave indicated that both MPICH and other open source projects use the "git 
describe" scheme for their nightly tarballs
2. Using "git describe", I didn't have to muck with the date, branch, etc.

> I don't think we consider "git describe" to be a useful naming mechanism for 
> nightlies, though for other snapshots it might be useful.
> For RCs, we pan to tag something like "1.7.3RC" at the start of the RC cycle 
> to get "git describe" to give names containing "1.7.3RC--" which 
> make some sense at a glance, even though N is incremented with every commit 
> and may grow much higher than a contentional RC number would.  Again, "1.7.3" 
> in this example is the UPCOMING release rather than the previous one.
> 
> For a developer's "make dist" from a developer's clone, however, I think we 
> agree "git describe" is as good as anything else readily available.
> 
> So, in short: I think our plan aligns with yours on scenarios #1 ("make dist" 
> by Jane Developer) and #3 (official releases), but we wanted something more 
> people-friendly for #2 (nightly tarballs).

Fair enough.

That being said, when we tell users to get a nightly tarball (e.g., to get a 
bug fix), my experience is that they don't know/care about the nightly tarball 
numbering scheme: they always just get the most recent version.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] git / nightly builds

[Jeff Squyres (jsquyres)]

ditional accounting surrounding "make dist"
- make_snapshot_tarball is some additional (different) accounting surrounding 
"make dist"

All that being said, I think 2 immediate improvements/simplifications are:

- have make_snapshot_tarball not set "git describe" in VERSION
- remove the config.guess/config.sub fetching from distscript.csh

I'll commit those now.

However, for the other cases, I think that doxygen is our main culprit for 
complexity.  :-\  Meaning: I'm now not sure how to make them simpler...

Thoughts?

> By the way, maybe move that script back from nightly to dist.

Sure; I don't have much of an opinion here.

>> Do you have a favorite git commit emailing script?  We can probably use the 
>> generic github "WebHook URLs" hook (at the top of the list) and host the 
>> diff-emailing script at IU (or anywhere, actually).
> 
> I use the attached one for Open-MX and KNEM. Not sure I tried many of
> them, but this one worked fine so far. It generates messages such as:
> 
> http://lists.gforge.inria.fr/pipermail/knem-commits/2013-July/000465.html
> I don't think it truncates the diff yet. We may want some separators
> between commits too. All this shouldn't be hard to configure.

It looks like github sends an HTTP post with the following information in it:

https://help.github.com/articles/post-receive-hooks

Do you have an easy place to host your script to try it out?  Or do you want to 
wait for IU to host it (i.e., tomorrow)?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] commit messages

[Jeff Squyres (jsquyres)]

I pinged IU.  We ran into this problem during the svn->git transition, but I 
thought DongInn fixed it.  Sorry...


On Sep 28, 2013, at 8:23 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> I can't login on Trac. Requested a new password, doesn't work either.
> 
> Brice
> 
> 
> Le 28/09/2013 14:19, Jeff Squyres (jsquyres) a écrit :
>> This sounds good.  Can you add this to the trac wiki?  
>> 
>> (e.g., MPICH did something like this when they converted to git)
>> 
>> 
>> On Sep 28, 2013, at 8:15 AM, Brice Goglin <brice.gog...@inria.fr> wrote:
>> 
>>> Let's discuss some rules for commit messages. I used svn propedit often
>>> in the past, that's not possible anymore once pushed to the main git repo.
>>> 
>>> 1) Obviously we should follow the commit log convention:
>>> 
>>> one short line description (less than 80 chars)
>>> 
>>> full description
>>> 
>>> 
>>> 2) When backporting patches between public branches, use git cherry-pick
>>> *-x* so that the old commit ID is recorded is the new commit log. If
>>> you're working in your private branches, this may not be needed (if the
>>> old commit ID may change before you actually push it).
>>> 
>>> 3) Configure your username and email properly before commtting.
>>> 
>>> git config user.email <foo@bar>
>>> git config user.name "First Last"
>>> 
>>> This goes into .git/config. Add --global to make these global for all
>>> your git repos (goes into ~/.gitconfig)
>>> 
>>> What else?
>>> 
>>> Brice
>>> 
>>> _______
>>> hwloc-devel mailing list
>>> hwloc-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>> 
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] commit messages

[Jeff Squyres (jsquyres)]

This sounds good.  Can you add this to the trac wiki?  

(e.g., MPICH did something like this when they converted to git)


On Sep 28, 2013, at 8:15 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> Let's discuss some rules for commit messages. I used svn propedit often
> in the past, that's not possible anymore once pushed to the main git repo.
> 
> 1) Obviously we should follow the commit log convention:
> 
> one short line description (less than 80 chars)
> 
> full description
> 
> 
> 2) When backporting patches between public branches, use git cherry-pick
> *-x* so that the old commit ID is recorded is the new commit log. If
> you're working in your private branches, this may not be needed (if the
> old commit ID may change before you actually push it).
> 
> 3) Configure your username and email properly before commtting.
> 
> git config user.email <foo@bar>
> git config user.name "First Last"
> 
> This goes into .git/config. Add --global to make these global for all
> your git repos (goes into ~/.gitconfig)
> 
> What else?
> 
> Brice
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] git / nightly builds

[Jeff Squyres (jsquyres)]

On Sep 28, 2013, at 4:41 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> I am having lots of problems when switching the regression testing stuff
> (jenkins) to git, mostly because of make dist. Actually it worked 2 days
> ago, no it breaks because hwloc-unknown.tar.* remain after make distcheck.

This means the versions junk still isn't right yet.  :-\

> 1) There's something I don't understand in the dist scripts.
> config/distscript.csh is only called the top-level Makefile.am, with 4th
> argument = HWLOC_SVN_R, which is never set. So we always fallback to
> git-describe. When building from a tarball, you get "unknown". That
> seems to break make distcheck. We need to pass something in that
> argument, but I don't see what.

Good catch; sorry about that.  HWLOC_SVN_R no longer exists (as you noted).  I 
just removed that 4th argument to distscript.csh.  Now, distscript (on master 
and v1.7) only edits VERSION if snapshot=1 and snapshot_version is empty (i.e., 
if you do "make dist" in a git clone instead of running 
contrib/nightly/make_nightly_snapshot, which will edit VERSION before running 
"make distcheck").

> 2) VPATH dist support is more fragile than before (I always build under
> $srcdir/build). In the past, we could do a VPATH make dist by just
> symlinking srcdir/doc/doxygen-doc to builddir/doc/doxygen-doc. This now
> generates "unknown" tarballs because we check for .git existence
> explicitly. I fixed my own case by checking for ../.git as well but
> that's not satisfying.

Mmm.  I preserved your ../.git check in 
https://github.com/open-mpi/hwloc/commit/c2b7f3d3c713feadb1d2c5a7ccd747cb6673d249.

I don't think I knew/realized you were doign VPATH dist builds by doing the sym 
link.

> It looks like we can fix this by checking for $srcdir/.git instead. If
> we want VPATH support where $builddir isn't a child of $srcdir, we'll
> have to set GIT_DIR=$srcdir/.git before calling git-describe too.
> 
> I think this is becoming way too complicated. Nobody won't be able to
> maintain that code in a couple years. Worse, what if you leave Cisco and
> stop working on hwloc one day? In my other projects, I would just
> override the VERSION makefile variable on the make command-line to
> change the tarball name (you won't get that VERSION in lstopo --version,
> but you would still see 1.8a1 from configure). We should rethink what we
> actually need here.

Yes, these are good points.  I agree: the system is too complicated right now.  
:-\

Let's go through the use cases of what we want:

1. "make dist" in a developer's git clone.  This should make a "hwloc-.tar.*.

2. make a nightly snapshot tarball.  The more I think about this, the more I 
think it's the same as #1, right?

3. make a release tarball, "hwloc-major.minor.releasegreek.tar.*".

Are these the three (or two, if #2 is the same as #1) use cases we want?  If 
so, I can see about making the code simpler -- e.g., I didn't know about 
overriding the VERSION Makefile macro trick...

> For instance if we can simpify things by not
> building 1.8-final when we build 1.8-rcX, that'd be fine with me.

I think that part is actually fairly simple; it just runs "make dist", strips 
out the greek value from VERSION, and runs "make dist" again.

> Random other questions:
> * where do you configure commit emails? can we drop/change the
> open-mpi/hwloc subject prefix? I removed the hwloc-svn prefix from
> mailman to avoid double-prefixing for now
> * can we get commit diffs in email, with some truncation limit to 50kB
> or so?

Yeah, I'm a bit disappointed by the github email service hook (the config is 
here: https://github.com/open-mpi/hwloc/settings/hooks; scroll down to 
"Email").  There's *very* little configuration available:

- the address to send to
- an email address secret
- what address to send from

There's no option for diffs (!), and no option to customize the mail/subject.  
:-\

Do you have a favorite git commit emailing script?  We can probably use the 
generic github "WebHook URLs" hook (at the top of the list) and host the 
diff-emailing script at IU (or anywhere, actually).

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] nightly snapshot tarballs now available

[Jeff Squyres (jsquyres)]

Ok, the infrastructure is now updated.  I've generated the first snapshot 
tarballs in http://www.open-mpi.org/software/hwloc/nightly/.  Nightly snapshots 
for <=v1.6 have all been removed.

Git is fully open for business.  Enjoy.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] git / nightly builds

[Jeff Squyres (jsquyres)]

On Sep 27, 2013, at 9:43 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> I don't think so. I am planning to only update the regression testing
> for v1.7 as well.

K.

> BUT what if the stable OMPI 1.6 needs a hwloc fix? Should we keep the
> hwloc v1.5 branch open?

E... let's cross that bridge when/if we need to.  :-)

>> 2. With SVN, adding the r number in the tarball version was sufficient to 
>> observe ordering of the tarballs.  For example:
>> [snip]
>> I think that this is ok (other projects use this "git describe" kind of 
>> behavior for their nightly snapshots), but this is a change from what we 
>> used to do, so I wanted to call it out specifically.
>> 
>> Are you guys ok with this?
> 
> That'll work for me.
> 
> What about when we are actually doing a release where we don't want a
> git-describe suffix ? Does the above apply to contrib/make_dist_tarball
> in general? Or only to when it runs at night (in make dist only?) ?

There are actually 2 scripts:

contrib/dist/make_dist_tarball
contrib/nightly/make_snapshot_tarball (currently called create_tarball.sh)

The former works largely as it did before: it'll make hwloc-.tar.*.

The latter is being heavily updated to basically use "git describe".

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] git / nightly builds

[Jeff Squyres (jsquyres)]

I'd say that git and the new Trac are now fully open for business.  I might 
still do some shifting around of tags (see below), but otherwise, I think 
everything is just about ready.

I'm revamping make_dist_script and the nightly build script; I should finally 
be able to commit those today, if all goes well.  However, I had to make some 
changes to VERSION and some other surrounding infrastructure to make it all 
work.  Specifically: git just does some things *differently* than SVN, so it 
required some changes in the way that hwloc does things, infrastructure-wise.  

Two things:

1. I'm not excited about back-porting these changes all the way back to 
hwloc-1.0 just so that we can make nightly tarballs for these branches which 
aren't used any more.  I'm thinking that I should definitely make these changes 
for master and the v1.7 branch.  Should I also do the v1.6 branch?  

I'm thinking that back-porting further is useless; we should just stop making 
nightlies for all the older branches.

To clarify: with SVN, we still checked all the older branches every night and 
would make a new tarball if there was ever a change.  We never made changes in 
those older branches, so we never made new nightlies.  But we *would have*, if 
a change had every been committed on those branches.

2. With SVN, adding the r number in the tarball version was sufficient to 
observe ordering of the tarballs.  For example:

   hwloc-1.8r1234.tar.bz2
   hwloc-1.8r1240.tar.bz2
   hwloc-1.8r1255.tar.bz2
   ...etc.

With git, we only have a hash number.  So there's no obvious ordering of the 
tarballs.  For example:

   hwloc-1.8git11223344.tar.bz2
   hwloc-1.8git00aa3344.tar.bz2
   hwloc-1.8git99aa2277.tar.bz2
   ...etc.

However, there is "git describe" functionality which, in our case, can show you 
how many commits you are beyond a given tag.  For example, I added a "dev" tag 
on the master branch for the first pure-git commit (i.e., 1 beyond the last SVN 
commit).  For example:

$ git clone g...@github.com:open-mpi/hwloc.git
...clone completes successfully...
$ cd hwloc
$ git checkout master
$ git describe --always
dev-3-g51efdd1

Where the "3" represents that we're 3 commits beyond the "dev" tag.  The "g" 
just means "git", and the "51efdd1" is the hash of that commit.

Hence, if we use that as our version string, we get tarballs named something 
like this:

hwloc-dev-3-g51efdd1.tar.bz2
hwloc-dev-10-gf50a385.tar.bz2
...etc.

For the master branch, I think that's fine.  However, note that ***THIS IS 
DIFFERENT THAN WHAT WE HAVE PREVIOUSLY DONE ON RELEASE BRANCHES!***

For example, if you checkout the v1.7 branch:

$ git checkout v1.7
$ git describe --always
hwloc-1.7.2-4-g3a6f84c

*** NOTE THE DIFFERENCE HERE:

a) The last SVN nightly snapshot on the v1.7 branch was named 
   hwloc-1.7.3rc1r5779.tar.bz2.
b) The first git nightly snapshot on the v1.7 branch will be named 
   hwloc-1.7.2-4-g3a6f84c.tar.bz2.

Note "1.7.3rc1..." vs. "1.7.2...".  I.e., the git name will say "we're X 
commits beyond the 1.7.2 tag", but the old SVN name was "we're at this 
*upcoming* version".

I think that this is ok (other projects use this "git describe" kind of 
behavior for their nightly snapshots), but this is a change from what we used 
to do, so I wanted to call it out specifically.

Are you guys ok with this?

(note: I'm still mucking with the final tag names, so some of the above may 
change slightly)

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Git status

[Jeff Squyres (jsquyres)]

The conversion to the new git repo is done, as is the conversion of Trac:

https://github.com/open-mpi/hwloc
https://git.open-mpi.org/trac/hwloc/timeline

Commit messages have been edited to include new Git hashes for each old SVN "r" 
reference (e.g., 
https://git.open-mpi.org/trac/hwloc/changeset/be50022d23d6936ac19abd7deed0663d6d562531).

SVN is available in a read-only mode (we'll probably take it down a month or 
three from now).  The old Trac is no longer available.

Pushes to github will result in more-or-less immediate updates to the Trac 
timeline, and your favorite commit message tags will still affect Trac tickets.

However, the nightly tarball script is still broken.  I got close today, but 
then realized I was handling git tags incorrectly with how we make snapshot 
tarball filenames.

So there will be no nightly tarballs tonight; I'll continue working on the 
nightly tarball script tomorrow.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Quiet time for github/trac conversion

[Jeff Squyres (jsquyres)]

DongInn and I are set to do the final SVN -> git (i.e., github) hwloc 
transition.

Here's what will happen:

1. Everyone immediately ceases all hwloc SVN and trac activity (i.e., now)
2. DongInn will set hwloc SVN and trac to read-only
3. Jeff will do the final SVN -> git (github) conversion
4. DongInn will use the new hwloc github to convert to a new hwloc github trac
5. We'll do some sanity checking to make sure it's all working
6. We'll send an "all clear" email, and we'll move on in life using github+trac

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Git testing of hwloc

[Jeff Squyres (jsquyres)]

Ok.  Do you want us to schedule some "quiet time" for the hwloc SVN and trac to 
do the final conversion?


On Sep 23, 2013, at 3:26 PM, Brice Goglin <brice.gog...@inria.fr> wrote:

> I looked at your tests and everything looked OK so I figured there was
> no need for additional tests.
> 
> Brice
> 
> 
> 
> Le 23/09/2013 20:36, Jeff Squyres (jsquyres) a écrit :
>> Did you guys want to try to git commits and see them affect trac, etc.?
>> 
>> I'm thinking that getting you 2 guys happy with the github <--> trac 
>> interaction is the last step we need to do before re-doing the svn-->git 
>> conversion and fully moving over to github.
>> 
>> 
>> On Sep 9, 2013, at 10:07 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> 
>> wrote:
>> 
>>> Added both of you.
>>> 
>>> On Sep 7, 2013, at 2:52 AM, Samuel Thibault <samuel.thiba...@inria.fr> 
>>> wrote:
>>> 
>>>> Jeff Squyres (jsquyres), le Sat 07 Sep 2013 00:04:13 +0200, a écrit :
>>>>> What are your github IDs?
>>>> sthibaul
>>>> 
>>>> Samuel
>>>> ___
>>>> hwloc-devel mailing list
>>>> hwloc-de...@open-mpi.org
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>>> 
>>> -- 
>>> Jeff Squyres
>>> jsquy...@cisco.com
>>> For corporate legal information go to: 
>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>> 
>>> ___
>>> hwloc-devel mailing list
>>> hwloc-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>> 
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Nightly tarballs

[Jeff Squyres (jsquyres)]

The nightly tarballs were broken for a few days after IU moved the build 
machine to a different server.  

They should now be fixed -- the OMPI 1.9 tarball was generated a few minutes 
ago; the others are being built right now.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Git testing of hwloc

[Jeff Squyres (jsquyres)]

Did you guys want to try to git commits and see them affect trac, etc.?

I'm thinking that getting you 2 guys happy with the github <--> trac 
interaction is the last step we need to do before re-doing the svn-->git 
conversion and fully moving over to github.


On Sep 9, 2013, at 10:07 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote:

> Added both of you.
> 
> On Sep 7, 2013, at 2:52 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:
> 
>> Jeff Squyres (jsquyres), le Sat 07 Sep 2013 00:04:13 +0200, a écrit :
>>> What are your github IDs?
>> 
>> sthibaul
>> 
>> Samuel
>> ___
>> hwloc-devel mailing list
>> hwloc-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] nightly builds failed

[Jeff Squyres (jsquyres)]

IU moved the nightly build cron jobs to a new machine today, and they failed.  
I'm manually running the build cron jobs on the old build machine (eddie) right 
now.

I've alerted IU to what I think the error was in the move; hopefully they'll be 
able to fix it over the weekend.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Git testing of hwloc

[Jeff Squyres (jsquyres)]

Added both of you.

On Sep 7, 2013, at 2:52 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:

> Jeff Squyres (jsquyres), le Sat 07 Sep 2013 00:04:13 +0200, a écrit :
>> What are your github IDs?
> 
> sthibaul
> 
> Samuel
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Git testing of hwloc

[Jeff Squyres (jsquyres)]

Brice / Samuel --

We seem to be in pretty good shape:

- github commits work as expected
- we're getting emails sent upon pushes to github
- DongInn got the "refs #X" and "closes #X" stuff working (i.e., putting tokens 
in git commit messages affects Trac tickets -- see 
http://trac.edgewall.org/wiki/CommitTicketUpdater)

Do you want to do some testing?  What are your github IDs?

The test Trac instance is located here:

https://git.open-mpi.org/trac/hwloc/

Once we're happy with all this setup, we can do the conversion for real and 
start working forward with github and leave SVN behind.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] [mpich-core] hwloc-1.6.x tainted with GPL?

[Jeff Squyres (jsquyres)]

On Sep 6, 2013, at 10:50 AM, Pavan Balaji <bal...@mcs.anl.gov> wrote:

> Aha!  I was never happier to be wrong.  :-)  Woohoo!
> 
> Thanks for the clarification.

No problem.  Go smack your partner for not doing their due diligence properly. 
:-)

> FWIW, I said that you guys have LGPL-2.1 code, so technically it's still 
> correct ;-).  But I blame Fortran for this oversight.

LOL!

(that was an MPI Forum/inside joke for those of you wondering WTF it meant :-) )

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] hwloc-1.6.x tainted with GPL?

[Jeff Squyres (jsquyres)]

On Sep 6, 2013, at 10:30 AM, Pavan Balaji <bal...@mcs.anl.gov> wrote:

> The mpich-3.0.x series was released with hwloc-1.6.x.  One our of partners 
> just brought it to our attention that this version of hwloc has LGPL-2.1 code 
> in src/libltdl.

Because GPL violations are quite serious, I want to be totally clear: ***your 
statement is totally incorrect***.

libltdl distributed in hwloc is not LGPL.

I cite the comments in src/libltdl/ltdl.h:

-
As a special exception to the GNU Lesser General Public License,
if you distribute this file as part of a program or library that
is built using GNU Libtool, you may include this file under the
same distribution terms that you use for the rest of that program.
-

This special exception is included in every single file under src/libltdl 
except README and COPYING.LIB.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Migrating www.open-mpi.org

[Jeff Squyres (jsquyres)]

All --

Our hosting provider will be migrating 
www.open-mpi.org<http://www.open-mpi.org> to a new machine on Wednesday.  See 
message below for details.


Begin forwarded message:

From: DongInn Kim <di...@cs.indiana.edu<mailto:di...@cs.indiana.edu>>
Subject: Migrating www.open-mpi.org<http://www.open-mpi.org> from milliways to 
lion
List-Post: hwloc-devel@lists.open-mpi.org
Date: August 5, 2013 11:53:38 AM PDT

Dear Open MPI developers and users,

We are planning to move all the services under 
www.open-mpi.org<http://www.open-mpi.org/> to the new server on Wednesday, Aug 
7th, 2013.
This migration may need some outage time of web services (e.g., 
http://www.open-mpi.org<http://www.open-mpi.org/>) and mailing list services 
(e.g., us...@open-mpi.org<mailto:us...@open-mpi.org>, 
de...@open-mpi.org<mailto:de...@open-mpi.org>, …).

The migration schedule is following:
- Date: Wednesday, Aug 7th, 2013
- Time:
6:00am-8:00am Pacific US time
7:00am-9:00am Mountain US time
8:00am-10:00am Central US time
9:00am-11:00am Eastern US time
1:00pm-3:00pm GMT

The following services would not be available during the migration.

- Web services (e.g., www.open-mpi.org<http://www.open-mpi.org/>)
- mailing lists:
  ad...@open-mpi.org<mailto:ad...@open-mpi.org>
  announce
  bugs
  devel
  devel-core
  docs
  ft
  hwloc-announce
  hwloc-bugs
  hwloc-devel
  hwloc-svn
  hwloc-users
  llamas
  mtt-announce
  mtt-bugs
  mtt-devel
  mtt-devel-core
  mtt-results
  mtt-svn
  mtt-users
  ompi-user-docs-bugs
  ompi-user-docs-svn
  svn
  svn-docs
  svn-docs-full
  svn-full
  svn-private
  svn-private-full
  users
- Mail archives
  http://www.open-mpi.org/community/lists/
- Mercurial mirror
  Will disappear (it has long-since moved out to Bitbucket)

I hope that we will not lose any mails sent to the above mailing lists even 
during the migration but it would be really appreciated if you hold up sending 
emails and svn commit until the migration is done.

Please let me know if you have any questions or issues about this migration.

Regards,

--
- DongInn
---
CREST System administrator
Indiana University
Bloomington, IN


--
Jeff Squyres
jsquy...@cisco.com<mailto:jsquy...@cisco.com>
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] upcoming cleaning of headers and doc sections

[Jeff Squyres (jsquyres)]

Just to throw in a wildcard...

You could also make hwloc.h be pretty minimal, and #include a bunch of others.  
You could divide sub-.h files by:

- types
- section / functionality
- ...?


On Jul 18, 2013, at 8:09 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> FYI, I recently got a lot of feedback about our function lists and
> documentation sections.
>http://www.open-mpi.org/projects/hwloc/doc/v1.7.1/modules.php
> Several of these sections have confusing names, so I am going to
> reorganize all this.
> 
> Non-inline functions were initially considered the main hwloc functions,
> they went in hwloc.h. Others were inlines and considered less important,
> they went in hwloc/helper.h. That doesn't work anymore because many
> inlines should rather be documented just near their non-inline friends.
> So I'll move things where they belong to create unique and consistent
> sections for each topic.
> 
> The problem with moving many inlines into hwloc.h is that it'll make
> that main header very long and less readable. Ways to improve that:
> * only put the prototypes in hwloc.h and keep the inline code somewhere else
> * if some sections are obviously less important, keep these out of
> hwloc.h (just like the ones in hwloc/helper.h currently)
> * only keep the strict minimum (types?) in hwloc.h ?
> 
> Brice
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] [hwloc-svn] [open-mpi/hwloc] 3ae99c: Fix a memory leak of the info array when mergin...

[Jeff Squyres (jsquyres)]

This was a test email post from github (we're exploring various options for 
migrating hwloc from svn to git).

There might be more test emails over time; bear with us.


On Jul 11, 2013, at 9:06 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:

>  Branch: refs/heads/master
>  Home:   https://github.com/open-mpi/hwloc
>  Commit: 3ae99c0d0f44d24c326258146e0401a03a167522
>  
> https://github.com/open-mpi/hwloc/commit/3ae99c0d0f44d24c326258146e0401a03a167522
>  Author: Brice Goglin <brice.gog...@inria.fr>
>  Date:   2013-05-30 (Thu, 30 May 2013)
> 
>  Changed paths:
>M src/topology.c
> 
>  Log Message:
>  ---
>  Fix a memory leak of the info array when mergin...
> 
> Fix a memory leak of the info array when merging objects
> 
> Not sure it ever occured since most objects merged in this code
> have no infos.
> 
> This commit was SVN r5654.
> 
> 
>  Commit: 061f16d78a334dbaa6280d7c675646b4f72c7ebc
>  
> https://github.com/open-mpi/hwloc/commit/061f16d78a334dbaa6280d7c675646b4f72c7ebc
>  Author: Brice Goglin <brice.gog...@inria.fr>
>  Date:   2013-05-30 (Thu, 30 May 2013)
> 
>  Changed paths:
>M src/topology.c
> 
>  Log Message:
>  ---
>  Fix a memory leak of the distance array when me...
> 
> Fix a memory leak of the distance array when merging objects
> 
> Likely never occured...
> 
> This commit was SVN r5655.
> 
> 
>  Commit: a9c1ac48877fb98f603a2e7a5f32db50effa7cb9
>  
> https://github.com/open-mpi/hwloc/commit/a9c1ac48877fb98f603a2e7a5f32db50effa7cb9
>  Author: Samuel Thibault <samuel.thiba...@inria.fr>
>  Date:   2013-06-06 (Thu, 06 Jun 2013)
> 
>  Changed paths:
>M doc/Makefile.am
> 
>  Log Message:
>  ---
>  Add rule to remove spurious qualifiers (inline,...
> 
> Add rule to remove spurious qualifiers (inline, unused, etc.) from the 
> generated html files.
> 
> This commit was SVN r5659.
> 
> 
> Compare: https://github.com/open-mpi/hwloc/compare/c30565e852eb...a9c1ac48877f
> ___
> hwloc-svn mailing list
> hwloc-...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-svn


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Move to git?

[Jeff Squyres (jsquyres)]

Go ahead and push now.

I started my git discussions with Dave, but haven't finished them yet.  I don't 
think DongInn has done his part at IU yet.  I think this will take a short 
while to get done; it won't happen immediately.


On Jun 12, 2013, at 1:52 PM, Brice Goglin <brice.gog...@inria.fr> wrote:

> Do you have any svn/git plan in the very near future? I will have a
> couple fixes to push in the next days. So if you're going to switch to
> git soon, please let me know, I'll wait and commit later.
> 
> Brice
> 
> 
> 
> Le 04/06/2013 12:14, Jeff Squyres (jsquyres) a écrit :
>> Ok.  This is kinda what I assumed your response would be.  :-)
>> 
>> Let me talk to Dave Goodell later today, who just recently went through 
>> converting MPICH from SVN -> Git, and see what kinds of things we need to do 
>> to get the ball rolling here, and what kinds of dragons we should expect to 
>> encounter along the way.
>> 
>> 
>> On Jun 3, 2013, at 11:17 PM, Brice Goglin <brice.gog...@inria.fr> wrote:
>> 
>>> +1000 !
>>> I already use git-svn for most of my hwloc work. But I still need svn for 
>>> backports, and that wastes a lot of my time.
>>> Brice
>>> 
>>> 
>>> "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> a écrit :
>>> We're having a discussion (again :-) ) about moving OMPI to a DVCS.
>>> 
>>> The short conclusion of the long conversation is: the OMPI dev community 
>>> would be much more comfortable moving to a DVCS if they could see some 
>>> success with other OMPI projects (e.g., hwloc and/or MTT).
>>> 
>>> Would hwloc be interested in moving to git?  This would mean:
>>> 
>>> 1. converting the existing svn to git
>>> --> including all historical log messages that refer to "r"
>>> 2. converting the existing trac to git
>>> --> including all trac tickets, comments, and wiki pages that refer to 
>>> "r"
>>> 
>>> The OMPI devs -- who are mostly unfamiliar with git -- would like to see 
>>> some close-to-home successes with git over a period of time that don't 
>>> require heavy administrative maintenance over time (one of the pushback 
>>> issues was that some organizations have hired full-time people to
>>> maintain/fix git repositories when they break/become unusable).
>>> 
>>> 
>>> Interested?
>> 
> 


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] First plugin namespace issue report

[Jeff Squyres (jsquyres)]

On Jun 4, 2013, at 11:12 PM, Brice Goglin <brice.gog...@inria.fr> wrote:

> This code has to be in the plugin for real, it obviously cannot be
> shared in the hwloc core, but putting it in a static inline in
> hwloc/plugins.h may still be OK?


I've written a Haiku in honor of the occasion:

Linkers are your friends
like a bully at recess
takes your lunch money.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] First plugin namespace issue report

[Jeff Squyres (jsquyres)]

On Jun 4, 2013, at 9:55 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

>> One option might be to try to lt_dlsym one of the hwloc symbols that you 
>> know you'll need in the plugin (or any public hwloc symbol, for that 
>> matter).  If ltdl_sym gets NULL back for the hwloc global symbol, then the 
>> plugin should disqualify itself and have itself unloaded (perhaps with some 
>> way of reporting what/why it did that).
> 
> lt_dlsym doesn't seem to accept special handles such as RTLD_DEFAULT
> like dlsym does, and we don't have a handle on hwloc. I don't see how to
> do that with lt_dlsym?


Can we lt_dlopen(NULL) to get a handle to this process?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] First plugin namespace issue report

[Jeff Squyres (jsquyres)]

On Jun 4, 2013, at 5:22 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> I take that back. Topology flags come too late, plugins are loaded
> during the first topology_init().

Bummer.

> We're back to things like "export HWLOC_PLUGINS_PATH=/none"

Perhaps add a pre-init API to set flags like this...?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] First plugin namespace issue report

[Jeff Squyres (jsquyres)]

On Jun 4, 2013, at 5:11 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> 2) custom test with ltdl: The program just silently fails to load hwloc
> symbols. Equivalent to passing the topology flag above.


One option might be to try to lt_dlsym one of the hwloc symbols that you know 
you'll need in the plugin (or any public hwloc symbol, for that matter).  If 
ltdl_sym gets NULL back for the hwloc global symbol, then the plugin should 
disqualify itself and have itself unloaded (perhaps with some way of reporting 
what/why it did that).

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Move to git?

[Jeff Squyres (jsquyres)]

On Jun 4, 2013, at 3:38 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

>> I'd like to explore converting all the old SVN log message mentions of 
>> "r" to git hashes.  git-svn doesn't do that, right?
> 
> No it doesn't afaik, and that would be nice.


I know that MPICH went through this (converting all old messages -- both in SVN 
and trac -- from "r" to git hashes).  Let me talk to Dave later today and 
see what they did.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Move to git?

[Jeff Squyres (jsquyres)]

On Jun 4, 2013, at 3:23 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> When I switched Open-MX and KNEM from SVN to GIT, I basically just
> pushed my git-svn clone. But I had to manually convert some svn
> tags/branches. IIRC, the main reason is that git-svn has a strange way
> to name svn branches in git.

I'd like to explore converting all the old SVN log message mentions of "r" 
to git hashes.  git-svn doesn't do that, right?

> We may also have to pass --authors-file to git svn clone so that SVN
> logins are converted into proper git author names.

K.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] plugins inside plugin broken, as expected

[Jeff Squyres (jsquyres)]

On Jun 3, 2013, at 11:11 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:

> If only plugins and the core use these functions, the application does
> not have to use -lhwloc-helper at all. If the application uses them
> (e.g. bitmap functions), then it would have to use -lhwloc-helper,
> but we can probably as well simply provide the symbols in both
> libhwloc-helper and libhwloc, so the application only needs -lhwloc.

I don't think you want to go that route -- you can end up with duplicate 
symbols, and there be dragons there.

> We
> can probably do that for the helpers we know for sure they have no
> state, such as bitmap functions.


I don't know if all these elaborate workarounds will be a Good Thing.  You'll 
basically explore the dynamic linker space, in all of its glory/ugliness, and 
end up coming up with horrid, confusing workarounds.

The short version is: issues like this are the nature of DSOs.

Hwloc has a solution for this problem: build without DSO support, and all works 
fine.  That should be the advertised solution, IMNSHO.

Until someone comes up with a more general, system-level solution to the 
problems of plugins loading plugins (e.g., some kind of flexible runtime linker 
namespace solution), individual user-level software packages cannot hope to 
sanely work around what is currently defined as the system model.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] Move to git?

[Jeff Squyres (jsquyres)]

Ok.  This is kinda what I assumed your response would be.  :-)

Let me talk to Dave Goodell later today, who just recently went through 
converting MPICH from SVN -> Git, and see what kinds of things we need to do to 
get the ball rolling here, and what kinds of dragons we should expect to 
encounter along the way.


On Jun 3, 2013, at 11:17 PM, Brice Goglin <brice.gog...@inria.fr> wrote:

> +1000 !
> I already use git-svn for most of my hwloc work. But I still need svn for 
> backports, and that wastes a lot of my time.
> Brice
> 
> 
> "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> a écrit :
> We're having a discussion (again :-) ) about moving OMPI to a DVCS.
> 
> The short conclusion of the long conversation is: the OMPI dev community 
> would be much more comfortable moving to a DVCS if they could see some 
> success with other OMPI projects (e.g., hwloc and/or MTT).
> 
> Would hwloc be interested in moving to git?  This would mean:
> 
> 1. converting the existing svn to git
> --> including all historical log messages that refer to "r"
> 2. converting the existing trac to git
> --> including all trac tickets, comments, and wiki pages that refer to "r"
> 
> The OMPI devs -- who are mostly unfamiliar with git -- would like to see some 
> close-to-home successes with git over a period of time that don't require 
> heavy administrative maintenance over time (one of the pushback issues was 
> that some organizations have hired full-time people to
> maintain/fix git repositories when they break/become unusable).
> 
> 
> Interested?


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

[hwloc-devel] Move to git?

[Jeff Squyres (jsquyres)]

We're having a discussion (again :-) ) about moving OMPI to a DVCS.

The short conclusion of the long conversation is: the OMPI dev community would 
be much more comfortable moving to a DVCS if they could see some success with 
other OMPI projects (e.g., hwloc and/or MTT).

Would hwloc be interested in moving to git?  This would mean:

1. converting the existing svn to git
   --> including all historical log messages that refer to "r"
2. converting the existing trac to git
   --> including all trac tickets, comments, and wiki pages that refer to 
"r"

The OMPI devs -- who are mostly unfamiliar with git -- would like to see some 
close-to-home successes with git over a period of time that don't require heavy 
administrative maintenance over time (one of the pushback issues was that some 
organizations have hired full-time people to maintain/fix git repositories when 
they break/become unusable).

Interested?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] hwloc embedding vs libltdl

[Jeff Squyres (jsquyres)]

On May 9, 2013, at 8:55 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> +Although hwloc plugins may be used in embedded mode, the embedder
> +project will have to manually setup libltdl in its build system so
> +that hwloc can load its plugins.
> +Also, embedders should avoid using their own plugins and hwloc plugins
> +simultaneously because of possible issues with public and private
> +namespaces when using libltdl.
> +The embedder project is strongly advised not to use libltdl.

Tweaked:

Although hwloc dynamic shared object plugins may be used in embedded mode, the 
embedder project will have to manually setup libltdl in its build system so
that hwloc can load its plugins at run time.  Also, embedders should be aware 
of complications that can arise due to public and private linker namespaces 
(e.g., if the embedded project is loaded into a private namespace and then 
hwloc tries to dynamically load its plugins, such loading may fail since the 
hwloc plugins can't find the hwloc symbols they need).  The embedder project is 
*strongly* advised not to use hwloc's dynamically loading plugins / libltdl 
capability.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r5606 - trunk

[Jeff Squyres (jsquyres)]

Does this patch fix it?  It's not clear to me from the LT docs whether you're 
supposed to call LT_LANG multiple times or LT_LANG with multiple languages, but 
this patch below seems to run the libtool C++ configury:

Index: configure.ac
===
--- configure.ac(revision 5609)
+++ configure.ac(working copy)
@@ -168,6 +168,7 @@
 AM_DISABLE_STATIC
 AM_PROG_LIBTOOL([dlopen win32-dll])
 LT_LANG([C])
+LT_LANG([C++])
 LT_CONFIG_LTDL_DIR([src/libltdl])
 LTDL_INIT([recursive convenience])
 AC_CONFIG_FILES([src/libltdl/Makefile])

(I couldn't generate the make check failure on my Mac with or without the 
additional LT_LANG, so I can't confirm if this is the correct fix or not)


On May 8, 2013, at 2:28 AM, Brice Goglin <brice.gog...@inria.fr> wrote:

> We actually used C++ during make check (we test the C++ build of
> doc/hwloc-hello.c)
> (got a build failure report from https://ci.inria.fr/hwloc/)
> 
> Brice
> 
> 
> 
> Le 08/05/2013 02:27, svn-commit-mai...@open-mpi.org a écrit :
>> Author: jsquyres (Jeff Squyres)
>> Date: 2013-05-07 20:27:25 EDT (Tue, 07 May 2013)
>> New Revision: 5606
>> URL: https://svn.open-mpi.org/trac/hwloc/changeset/5606
>> 
>> Log:
>> Revert r5604 -- it's redundant with LT_LANG([C]).
>> 
>> Text files modified: 
>>   trunk/configure.ac | 4 
>>   1 files changed, 0 insertions(+), 4 deletions(-)
>> 
>> Modified: trunk/configure.ac
>> ==
>> --- trunk/configure.ac   Tue May  7 20:18:05 2013(r5605)
>> +++ trunk/configure.ac   2013-05-07 20:27:25 EDT (Tue, 07 May 2013)  
>> (r5606)
>> @@ -166,10 +166,6 @@
>> # Compiler support -- we don't need that stuff.
>> AM_ENABLE_SHARED
>> AM_DISABLE_STATIC
>> -# Tell libtool that we don't need Fortran or C++ support.
>> -FC=no
>> -F77=no
>> -CXX=no
>> AM_PROG_LIBTOOL([dlopen win32-dll])
>> LT_LANG([C])
>> LT_CONFIG_LTDL_DIR([src/libltdl])
>> ___
>> hwloc-svn mailing list
>> hwloc-...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-svn
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] hwloc embedding vs libltdl

[Jeff Squyres (jsquyres)]

On May 8, 2013, at 4:16 PM, Brice Goglin <brice.gog...@inria.fr> wrote:

> But this issue is only in the embedders (OMPI), not in the embeddee
> (hwloc), right?

Yes.

> I can get plugins to work in tests/embedded by adding 2 lines to its
> configure.ac (see the attached patch, which also removes your error
> message and creates a shared lib containing libhwloc_embedded).
> 
> In short, I don't really see what risk we would be taking on the hwloc
> side if we keep embedding+plugins possible (and still don't enable
> plugins by default).

Ok.  It's probably worth documenting, though.  In the OMPI case, for example, 
OMPI cannot be opened in a private namespace (e.g., as a python plugin) and 
then have hwloc also opened in a private namespace; hwloc must be opened in a 
public namespace.  This has caused unhappiness in certain cases where 
upper-layer application authors were trying to open all plugins in private 
namespaces but couldn't.  The same will be true with hwloc: those who embed 
hwloc should be *strongly advised* to not use libltdl (even though it's not the 
default) because of the private/public namespace issue.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] hwloc embedding vs libltdl

[Jeff Squyres (jsquyres)]

I don't think libltdl has a .pc. :(

Sent from my phone. No type good.

On May 8, 2013, at 2:26 AM, "Brice Goglin" 
<brice.gog...@inria.fr<mailto:brice.gog...@inria.fr>> wrote:

Le 08/05/2013 02:47, Jeff Squyres (jsquyres) a écrit :

How's this patch?

The only question I have is: how do we figure out what libraries to put in the 
.pc file in the --disable-shared --enable-static case?

There should be a ltdl.pc for this. But I don't see any. Is there a standard 
way to extract this line from ltdl.la ?
dependency_libs=' -ldl'

How about we do not support plugins when --enable-static is given?

Brice







On May 7, 2013, at 8:24 PM, Samuel Thibault 
<samuel.thiba...@inria.fr><mailto:samuel.thiba...@inria.fr> wrote:



Jeff Squyres (jsquyres), le Wed 08 May 2013 02:21:02 +0200, a écrit :


On May 7, 2013, at 6:25 PM, Brice Goglin 
<brice.gog...@inria.fr><mailto:brice.gog...@inria.fr> wrote:



I don't have anything against this. What was the reason for not using
the default/system libltdl in OMPI? libtool was buggy when you started
using it?



I neglected to answer this.

Yes, plus libltdl grew new functionality that we needed (global/local symbol 
visibility).

We might be getting to the point soon where we can rely on the installed 
libltdl to be new enough everywhere, but we haven't had that conversation.


We could already check that the installed version is new enough for our
needs.

Samuel
___
hwloc-devel mailing list
hwloc-de...@open-mpi.org<mailto:hwloc-de...@open-mpi.org>
http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel







___
hwloc-devel mailing list
hwloc-de...@open-mpi.org<mailto:hwloc-de...@open-mpi.org>
http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel

___
hwloc-devel mailing list
hwloc-de...@open-mpi.org<mailto:hwloc-de...@open-mpi.org>
http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel

Re: [hwloc-devel] hwloc embedding vs libltdl

[Jeff Squyres (jsquyres)]

1.  Ok. 
2.  My thoughts were preventing hwloc from going thru some of the pain that 
OMPI went thru w embedding. Libibverbs has the same problem. If you have 
middleware that uses plugins that, in turn, uses plugins, it's a bit 
complicated to support fully static builds  properly (OMPI and hwloc do, but 
libibverbs doesn't easily, but still, it may require a rebuild of hwloc with 
enable-static). Also, the problem with opening DSOs in private namespaces still 
exists; there's no good solution for that (when both the middleware and hwloc 
use plugins).  

>From hwlocs perspective, the middleware author can fix the static build 
>option, but I figured: why even go here?

3. Open MPI also get flack for embedding lib ltdl and libevent. Although 
libltdl now has the built in options for using an external libltdl (which is 
what the distros use), why go down this road if we don't need to embed libltdl?

Sent from my phone. No type good. 

On May 8, 2013, at 2:53 AM, "Brice Goglin"  wrote:

> Actually, are we going too far here?
> 
> 1) The original problem was that embedding couldn't build (it couldn't
> even autoreconf) because of the embedded ltdl. Not because of plugins
> being enabled. That's fixed with my patch and with yours.
> tests/embedded/ runs fine now.
> 
> 2) Now, we're disallowing plugins entirely in the embedded case too.
> That's kind of orthogonal to (1). I don't think we currently have a
> single line of code to support this. If people want plugins and
> embedded, thay will need to setup ltdl in their own configure. I don't
> see any reason to prevent this. We may have users wanting this one day,
> so I think we should remove the current error message.
> 
> 3) And we're disallowing included ltdl too. I am actually not against
> this one. We don't use advanced ltdl features, and I don't plan to
> change the plugin management code. So the installed ltdl should be fine.
> But now that (1) is fixed, there's no direct reason to do (3) immediately.
> 
> Brice
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel

Re: [hwloc-devel] hwloc embedding vs libltdl

[Jeff Squyres (jsquyres)]

How's this patch?

The only question I have is: how do we figure out what libraries to put in the 
.pc file in the --disable-shared --enable-static case?


On May 7, 2013, at 8:24 PM, Samuel Thibault <samuel.thiba...@inria.fr> wrote:

> Jeff Squyres (jsquyres), le Wed 08 May 2013 02:21:02 +0200, a écrit :
>> On May 7, 2013, at 6:25 PM, Brice Goglin <brice.gog...@inria.fr> wrote:
>> 
>>> I don't have anything against this. What was the reason for not using
>>> the default/system libltdl in OMPI? libtool was buggy when you started
>>> using it?
>> 
>> 
>> I neglected to answer this.
>> 
>> Yes, plus libltdl grew new functionality that we needed (global/local symbol 
>> visibility).
>> 
>> We might be getting to the point soon where we can rely on the installed 
>> libltdl to be new enough everywhere, but we haven't had that conversation.
> 
> We could already check that the installed version is new enough for our
> needs.
> 
> Samuel
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/


no-embed-libltdl.diff
Description: no-embed-libltdl.diff