[ITP] mtr

[ITP] mtr

[Brian Inglis]

I would like to offer to package mtr:

combines the function of 'traceroute' and 'ping' in one network
diagnostic tool.

Investigates the network connection between the host it runs on and a
user-specified destination host. After it determines the address of each
network hop between the machines, it sends a sequence of ICMP ECHO
requests to each one to determine the quality of the link to each
machine. As it does this, it prints running statistics about each
machine.

It is available under all RedHat, Debian, BSD, Arch, Slack, SuSE, and
other Linux flavours:
        https://pkgs.org/download/mtr

Control files, sources, and binaries are available under the mtr folder:
	https://drive.google.com/open?id=1jxeYZ10mYhmz8YhwE3EOXvd-lVwd176o

See the project home page for more information:
	http://www.bitwizard.nl/mtr/

Re: [ITP] mtr

[Jon Turney]

On 21/07/2019 00:15, Brian Inglis wrote:
> I would like to offer to package mtr:
> 
> combines the function of 'traceroute' and 'ping' in one network
> diagnostic tool.
> 
> Investigates the network connection between the host it runs on and a
> user-specified destination host. After it determines the address of each
> network hop between the machines, it sends a sequence of ICMP ECHO
> requests to each one to determine the quality of the link to each
> machine. As it does this, it prints running statistics about each
> machine.
> 
> It is available under all RedHat, Debian, BSD, Arch, Slack, SuSE, and
> other Linux flavours:
>          https://pkgs.org/download/mtr
> 
> Control files, sources, and binaries are available under the mtr folder:
> 	https://drive.google.com/open?id=1jxeYZ10mYhmz8YhwE3EOXvd-lVwd176o
> 
> See the project home page for more information:
> 	http://www.bitwizard.nl/mtr/

A couple of minor nits:

mtr is be built with a gtk+ interface for displaying results, if 
present, but you've omitted the from DEPENDS.

Not sure what you intend, so either (i) explicitly configure 
--without-gtk, or (ii) add the needed gtk devel package(s) to DEPENDS.

After I build this, 'mtr -v' reports 'mtr UNKNOWN'

Otherwise, looks good.

Re: [ITP] mtr

[Brian Inglis]

On 2019-07-21 06:59, Jon Turney wrote:
> On 21/07/2019 00:15, Brian Inglis wrote:
>> I would like to offer to package mtr:
>>
>> combines the function of 'traceroute' and 'ping' in one network
>> diagnostic tool.
>>
>> Investigates the network connection between the host it runs on and a
>> user-specified destination host. After it determines the address of each
>> network hop between the machines, it sends a sequence of ICMP ECHO
>> requests to each one to determine the quality of the link to each
>> machine. As it does this, it prints running statistics about each
>> machine.
>>
>> It is available under all RedHat, Debian, BSD, Arch, Slack, SuSE, and
>> other Linux flavours:
>>          https://pkgs.org/download/mtr
>>
>> Control files, sources, and binaries are available under the mtr folder:
>>     https://drive.google.com/open?id=1jxeYZ10mYhmz8YhwE3EOXvd-lVwd176o
>>
>> See the project home page for more information:
>>     http://www.bitwizard.nl/mtr/
> 
> A couple of minor nits:
> 
> mtr is be built with a gtk+ interface for displaying results, if present, but
> you've omitted the from DEPENDS.
> 
> Not sure what you intend, so either (i) explicitly configure --without-gtk, or
> (ii) add the needed gtk devel package(s) to DEPENDS.

I don't currently run X under Cygwin 32, and many will not, because of memory
limits, and did not know whether it might just fail on such systems.
I will bite the bullet, and see how rebase does.

> After I build this, 'mtr -v' reports 'mtr UNKNOWN'

Good catch - wondered what that was meant to be - tests pass!
Will look into that, and get back when updated to X and that.

> Otherwise, looks good.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

Re: [ITP] mtr

[Brian Inglis]

On 2019-07-21 12:10, Brian Inglis wrote:
> On 2019-07-21 06:59, Jon Turney wrote:
>> On 21/07/2019 00:15, Brian Inglis wrote:
>>> I would like to offer to package mtr:
>>>
>>> combines the function of 'traceroute' and 'ping' in one network
>>> diagnostic tool.
>>>
>>> Investigates the network connection between the host it runs on and a
>>> user-specified destination host. After it determines the address of each
>>> network hop between the machines, it sends a sequence of ICMP ECHO
>>> requests to each one to determine the quality of the link to each
>>> machine. As it does this, it prints running statistics about each
>>> machine.
>>>
>>> It is available under all RedHat, Debian, BSD, Arch, Slack, SuSE, and
>>> other Linux flavours:
>>>          https://pkgs.org/download/mtr
>>>
>>> Control files, sources, and binaries are available under the mtr folder:
>>>     https://drive.google.com/open?id=1jxeYZ10mYhmz8YhwE3EOXvd-lVwd176o
>>>
>>> See the project home page for more information:
>>>     http://www.bitwizard.nl/mtr/
>>
>> A couple of minor nits:
>>
>> mtr is be built with a gtk+ interface for displaying results, if present, but
>> you've omitted the from DEPENDS.
>>
>> Not sure what you intend, so either (i) explicitly configure --without-gtk, or
>> (ii) add the needed gtk devel package(s) to DEPENDS.
> 
> I don't currently run X under Cygwin 32, and many will not, because of memory
> limits, and did not know whether it might just fail on such systems.
> I will bite the bullet, and see how rebase does.
> 
>> After I build this, 'mtr -v' reports 'mtr UNKNOWN'
> 
> Good catch - wondered what that was meant to be - tests pass!
> Will look into that, and get back when updated to X and that.
> 
>> Otherwise, looks good.

Built with gtk2.0-devel installed now requires libgdk_pixbuf2.0_0 libglib2.0_0
libgtk2.0_0 which probably drags a lot of X in.
Is there a standard way to offer subpackages with and without X in these cases?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

Re: [ITP] mtr

[Jon Turney]

On 21/07/2019 19:27, Brian Inglis wrote:
> On 2019-07-21 12:10, Brian Inglis wrote:
>> On 2019-07-21 06:59, Jon Turney wrote:
>>>
>>> Not sure what you intend, so either (i) explicitly configure --without-gtk, or
>>> (ii) add the needed gtk devel package(s) to DEPENDS.

My fractured grammar probably didn't help make clear that I consider 
either of these alternatives valid.

 From what you write, it seems you really intended to omit gtk support, 
so I'd suggest you consider alternative (i) i.e. explicitly configure 
--without-gtk, and potentially revisit this when someone demonstrates a 
need for mtr with gtk.

> Built with gtk2.0-devel installed now requires libgdk_pixbuf2.0_0 libglib2.0_0
> libgtk2.0_0 which probably drags a lot of X in.
> Is there a standard way to offer subpackages with and without X in these cases?

I guess you could add a mtr-gtk subpackage, to contain a mtr built with 
gtk support.

Unfortunately cygport can't create subpackages with conflicting files, 
and we can't mark packages as conflicting (yet), so you'd need to rename 
the mtr executable in that subpackage (e.g. as mtr-gtk)

Re: [ITP] mtr

[Henning]

On 21/07/2019 20:27, Brian Inglis wrote:

> Built with gtk2.0-devel installed now requires libgdk_pixbuf2.0_0 libglib2.0_0
> libgtk2.0_0 which probably drags a lot of X in.
> Is there a standard way to offer subpackages with and without X in these cases?

I usually do what I can to avoid X stuff. If I can afford it I decide to
not install packages. In this case I would probably try to compile
myself.

Henning

Re: [ITP] mtr

[Brian Inglis]

On 2019-07-22 05:36, Jon Turney wrote:
> On 21/07/2019 19:27, Brian Inglis wrote:
>> On 2019-07-21 12:10, Brian Inglis wrote:
>>> On 2019-07-21 06:59, Jon Turney wrote:
>>>>
>>>> Not sure what you intend, so either (i) explicitly configure --without-gtk, or
>>>> (ii) add the needed gtk devel package(s) to DEPENDS.
> 
> My fractured grammar probably didn't help make clear that I consider either of
> these alternatives valid.

So both would be good, as folks like Henning would not need to drag X into their
installs, and others on Win x86 running X could select and use the GUI.

> From what you write, it seems you really intended to omit gtk support, so I'd
> suggest you consider alternative (i) i.e. explicitly configure --without-gtk,
> and potentially revisit this when someone demonstrates a need for mtr with gtk.
> 
>> Built with gtk2.0-devel installed now requires libgdk_pixbuf2.0_0 libglib2.0_0
>> libgtk2.0_0 which probably drags a lot of X in.
>> Is there a standard way to offer subpackages with and without X in these cases?
> 
> I guess you could add a mtr-gtk subpackage, to contain a mtr built with gtk
> support.
> 
> Unfortunately cygport can't create subpackages with conflicting files, and we
> can't mark packages as conflicting (yet), so you'd need to rename the mtr
> executable in that subpackage (e.g. as mtr-gtk)

What about mtr-ncurses and mtr-gtk packages and primary mtr... exes?
I have to look into whether there is any significant difference between
mtr-packet exes also requiring renaming.
Then a postinstall symlink(s) creation or update-alternatives run to base names.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

Re: [ITP] mtr

[Brian Inglis]

On 2019-07-22 07:43, Henning wrote:
> On 21/07/2019 20:27, Brian Inglis wrote:
>> Built with gtk2.0-devel installed now requires libgdk_pixbuf2.0_0 libglib2.0_0
>> libgtk2.0_0 which probably drags a lot of X in.
>> Is there a standard way to offer subpackages with and without X in these cases?
> 
> I usually do what I can to avoid X stuff. If I can afford it I decide to
> not install packages. In this case I would probably try to compile
> myself.

Understood and appreciated: until now I did not run Cygwin 32 X, but run
everything under Cygwin 64 X; I have added X to my Cygwin 32 install, but will
look at providing both alternatives in packages to allow those on Cygwin 32 to
keep "Running Light Without Overbyte" (DDJ).

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

Re: [ITP] mtr

[Henning]

On 23/07/2019 14:03, Brian Inglis wrote:

> What about mtr-ncurses and mtr-gtk packages and primary mtr... exes?
> I have to look into whether there is any significant difference between
> mtr-packet exes also requiring renaming.
> Then a postinstall symlink(s) creation or update-alternatives run to base names.

On 23/07/2019 14:04, Brian Inglis wrote:
 > look at providing both alternatives in packages to allow those on
 > Cygwin32 to keep "Running Light Without Overbyte" (DDJ).

sounds promising.

Henning

Re: [ITP] mtr

[Brian Inglis]

On 2019-07-23 07:37, Henning wrote:
> On 23/07/2019 14:03, Brian Inglis wrote:
>> What about mtr-ncurses and mtr-gtk packages and primary mtr... exes?
>> I have to look into whether there is any significant difference between
>> mtr-packet exes also requiring renaming.
>> Then a postinstall symlink(s) creation or update-alternatives run to base names.
> On 23/07/2019 14:04, Brian Inglis wrote:
>> look at providing both alternatives in packages to allow those on
>> Cygwin32 to keep "Running Light Without Overbyte" (DDJ).
> sounds promising.

Summarizing the distro offerings: Fedoras/SuSE offer mtr/-gtk (X),
Debians offer mtr (X)/-tiny, FreeBSD offers mtr (X)/-nox11, and
NetBSD offers mtr only without X.
So mtr is ambiguous as it may mean with/without X.
Alternatives mtr-tiny/nox11 and mtr-gtk have the advantages of being
unambiguous and already in use elsewhere, unless there are reasons
to prefer to follow Fedora for consistency in naming?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

Re: [ITP] mtr

[Henning]

On 24/07/2019 14:25, Brian Inglis wrote:

> Alternatives mtr-tiny/nox11 and mtr-gtk have the advantages of being
> unambiguous and already in use elsewhere, unless there are reasons
> to prefer to follow Fedora for consistency in naming?

I really don't care that much about naming. However, if it were an issue
I would prefer the unambiguous version.

Henning