On Apr 27, 2012, at 1:41 PM, Paul H. Hargrove wrote:
>> Ok let's put a X server inside hwloc then.
>
> No, Xlstopo should be for showing me the logical->physical layout of screens
> on a multi-headed X server, right?
Is there an iOS/android app in progress, too?
;-)
--
Jeff Squyres
On 4/27/2012 10:39 AM, Brice Goglin wrote:
Le 27/04/2012 19:22, Samuel Thibault a écrit :
Brice Goglin, le Fri 27 Apr 2012 19:09:47 +0200, a écrit :
Le 25/04/2012 15:42, Jiri Hladky a écrit :
I would vote to make lstopo ASCII only and introduce new GUI binary
"lstopo-gui" in the version 1.5
Le 27/04/2012 19:22, Samuel Thibault a écrit :
> Brice Goglin, le Fri 27 Apr 2012 19:09:47 +0200, a écrit :
>> Le 25/04/2012 15:42, Jiri Hladky a écrit :
>>> I would vote to make lstopo ASCII only and introduce new GUI binary
>>> "lstopo-gui" in the version 1.5
>> I'll commit that during the
Brice Goglin, le Fri 27 Apr 2012 19:09:47 +0200, a écrit :
> Le 25/04/2012 15:42, Jiri Hladky a écrit :
> > I would vote to make lstopo ASCII only and introduce new GUI binary
> > "lstopo-gui" in the version 1.5
>
> I'll commit that during the weekend unless somebody comes with a better
>
Le 25/04/2012 15:42, Jiri Hladky a écrit :
> I would vote to make lstopo ASCII only and introduce new GUI binary
> "lstopo-gui" in the version 1.5
I'll commit that during the weekend unless somebody comes with a better
solution.
Of course, distros are free to add symlinks as Xlstopo then :)
On 26/04/2012 08:11, Christopher Samuel wrote:
On 26/04/12 02:35, Brice Goglin wrote:
I think I would vote for lstopo (no X/cairo) and lstopo so
that completion helps.
Not sure if that's an option with Debian given the policy; the hwloc
package would have to have lstopo with X enabled and
On 26/04/12 02:35, Brice Goglin wrote:
> I think I would vote for lstopo (no X/cairo) and lstopo so
> that completion helps.
Not sure if that's an option with Debian given the policy; the hwloc
package would have to have lstopo with X enabled and then a nox
package would install that variant of
On 25/04/12 23:44, Jeffrey Squyres wrote:
> FWIW: Having lstopo plugins for output would obviate the need for
> having two executable names.
IIRC that's generally handled via the alternatives system (or
diversions if you don't like alternatives) in Debian/Ubuntu.
--
Christopher Samuel -
On 04/25/2012 04:38 AM, Brice Goglin wrote:
> Hello,
>
> We recently got some complains from redhat/centos users that wanted to install
> hwloc on their cluster but couldn't because it brought so many X libraries
> that they don't care about.
>
> Debian solves this by having two hwloc packages:
On Apr 25, 2012, at 11:18 AM, Samuel Thibault wrote:
> But it still seems overkill to me to use approach 1 while approach 2
> just works. Yes, that conflicts with the original issue of the thread.
> It happens that on Debian we can actually make hwloc and hwloc-nox
> co-installable, by just
Jeff Squyres, le Wed 25 Apr 2012 17:11:28 +0200, a écrit :
> Yes: the lstopo user gets whatever the sysadmin chose to install.
> No: the system is not flexible for binary distributions
>
> Meaning: I see 2 ways to have binary packages that have X/cairo support and
> don't have X/cairo support:
>
On Apr 25, 2012, at 11:04 AM, Samuel Thibault wrote:
>> Yes, understood, but my point here is that there could be multiple hwloc
>> packages -- one that installs the core and some base set of lstopo plugins
>> (probably not cairo and X). And then secondary packages install lstopo's
>> cairo
Jeff Squyres, le Wed 25 Apr 2012 17:03:01 +0200, a écrit :
> On Apr 25, 2012, at 10:58 AM, Samuel Thibault wrote:
>
> > It already adapts itself, here. The issue is that the user has to
> > install an X version to get potential for X support. Which brings X.
> > If you do this with plugins, and
On Apr 25, 2012, at 10:58 AM, Samuel Thibault wrote:
> It already adapts itself, here. The issue is that the user has to
> install an X version to get potential for X support. Which brings X.
> If you do this with plugins, and you want automatic adaptation to
> whether X is there, you'll have
Brice Goglin, le Wed 25 Apr 2012 16:58:16 +0200, a écrit :
> On 25/04/2012 16:55, Jeff Squyres wrote:
> >On Apr 25, 2012, at 10:48 AM, Samuel Thibault wrote:
> >
> >>>FWIW: Having lstopo plugins for output would obviate the need for having
> >>>two executable names.
> >>Well, it seems overkill to
Jeff Squyres, le Wed 25 Apr 2012 16:55:23 +0200, a écrit :
> On Apr 25, 2012, at 10:48 AM, Samuel Thibault wrote:
>
> >> FWIW: Having lstopo plugins for output would obviate the need for having
> >> two executable names.
> >
> > Well, it seems overkill to me. It makes sense to me to have both
On 25/04/2012 16:55, Jeff Squyres wrote:
On Apr 25, 2012, at 10:48 AM, Samuel Thibault wrote:
FWIW: Having lstopo plugins for output would obviate the need for having two
executable names.
Well, it seems overkill to me. It makes sense to me to have both
xlstopo and lstopo.
Ick. FWIW, I
On Apr 25, 2012, at 10:48 AM, Samuel Thibault wrote:
>> FWIW: Having lstopo plugins for output would obviate the need for having two
>> executable names.
>
> Well, it seems overkill to me. It makes sense to me to have both
> xlstopo and lstopo.
Ick. FWIW, I dislike having two executables.
FWIW: Having lstopo plugins for output would obviate the need for having two
executable names.
On Apr 25, 2012, at 9:42 AM, Jiri Hladky wrote:
> Hello,
>
> I would strongly vote to split the hwloc package to the core (ASCII only,
> including ASCII only version of lstopo ) package and GUI
On Wednesday 25 April 2012 19:38:00 Brice Goglin wrote:
> How do people feel about this?
It sounds like what you have is a conflict between the policies of
Debian (and hence Ubuntu) and the expectations of RHEL/CentOS users.
Debian Policy is fairly clear on this matter:
# 11.8.1 Providing X
I don't have a strong opinion, but the historical "standard practice" for
Linux/Unix has always been to default to cmd line, non-graphical interfaces.
Graphical output was optional. Of course, that stemmed from the days before
everyone had a graphical display, but it is still generally
21 matches
Mail list logo